개발자가 직접 경험한 LLM 코딩의 현실과 가능성

그동안 제품 개발, 사이드 프로젝트, 보고용 스낵 프로그램을 만들면서 Cline과 Cursor, Claude Code를 사용하며 느낀 점을 정리해보았습니다.

1. 간단한 데모 프로그램이나 스크립트와 같은 스낵 프로그램은 거의 직접 코딩하지 않고도 바이브코딩으로 충분히 가능했습니다.
최근에 만든 프로그램은 메모와 이미지의 메타데이터를 조회하고, 검색(retrieval) 알고리즘의 결과를 비교할 수 있는 웹페이지였습니다. 이 프로젝트를 장고로 개발했는데, Cursor가 코딩의 90%를 담당했고, 나머지 10% 정도만 직접 수정하여 반나절 만에 완성했습니다. 그 10%도 지시를 조금 더 명확하게 했다면 아마 전체를 바이브코딩으로 충분히 마무리할 수 있었을 것 같습니다.

2. 알고리즘이나 함수 단위의 코딩에서는 저보다 LLM이 훨씬 뛰어났습니다. 때로는 스스로 코딩하는 것이 의미가 있나 싶을 정도로 LLM이 뛰어났습니다. 예를 들어 커스텀 청커를 만들기 위해 문자열 처리 알고리즘을 반나절 고민했지만 결국 퇴근길에 챗GPT와의 간단한 대화로 바로 해결되었습니다.

3. LLM을 활용한 코딩의 핵심은 명확한 지시라고 느꼈습니다.
모호한 지시를 내리면 LLM이 스스로 판단해 코드 작성을 시도하지만, 제가 생각한 로직과 다르게 구현될 때가 있습니다. 실제 사례로 Cursor Agent에게 "메타정보 데이터에서 메모 키워드들을 가져와 flat 하게 임베딩하는 로직을 만들어줘"라고 요청했는데, 제가 의도한 "키워드1 키워드2 …" 형태가 아니라 첫 번째 키워드만으로 임베딩하는 로직을 구현했습니다. "Flat"이라는 용어에 대한 해석이 저와 LLM 사이에서 달랐던 것입니다. 또한, 지시를 디테일하게 작성하지 않으면 제가 요청하지 않은 추가 기능까지 넣어줄 때도 있습니다. 예를 들어, 저는 검색에 하이라이트 기능을 요청한 적 없지만 더 좋은 기능이라며 추가해주었습니다. (Cursor 이전 버전에서 경험한 내용임을 참고하시길 바랍니다.)

4. 또한, 코드 베이스가 클 때 Agent가 생성한 코드를 수락한 후 다시 되돌리기가 어렵다는 점도 있습니다. 예를 들어, 아키텍처나 패키지 구조가 A 형태에서 B 형태로 변경되거나, 특정 기능을 추가한 후 다시 제거할 때 문제가 발생했습니다. 특히 기능을 제거할 때 LLM이 자신이 작성한 코드의 컨텍스트를 잃어버려서 빌드가 깨지는 일이 발생했습니다. 저는 하이라이트 기능을 추가한 뒤 다시 제거를 요청했는데, 제대로 제거되지 않았습니다. 이는 Cursor의 이전 버전(Claude Sonnet 3.7 Max 이전 버전)에서 겪었던 문제로, 여러 차례 세심한 검토가 필요했습니다.

5. 이런 방식으로 세부적인 지시를 내리는 게 생각보다 번거롭습니다. 마치 순서도를 설명하거나 신입사원에게 코드 리뷰를 하듯 상세히 타이핑하다 보면, 차라리 직접 짜는 게 낫지 않을까 하는 생각이 들 때도 많았습니다.

6. 큰 프로젝트의 경우, LLM이 잘 이해할 수 있도록 작업을 작은 단위로 쪼개거나, 네이밍을 명확히 하고, 주석을 꼼꼼히 작성하거나 Cursor 노트북, Claude.md 파일 등을 활용해 패키지나 클래스에 대한 설명과 지시를 명확히 해두면 컨텍스트 혼동을 줄일 수 있습니다.

7. 결론적으로 작은 규모의 프로그램이라면 바이브코딩만으로 충분합니다. 그러나 큰 규모의 프로그램에서는 아직 바이브코딩만으로 한계가 있습니다. 따라서 큰 소스코드를 모듈 단위로 잘 분리하는 것이 좋은 것 같습니다. (약간 DDD나 마이크로서비스 형태가 유리할지 고민이 되었습니다.) 좋은 품질의 코드, 그리고 개발자의 의도가 정확히 담긴 코드를 얻으려면 프롬프트를 정확하고 자세히 작성해야 합니다. 당연히 검토 과정도 필요하며, 결국 개발자의 내공이 중요하다는 의미입니다. 또한, LLM에게 의도를 정확히 전달할 수 있는 커뮤니케이션 능력도 중요한 것 같습니다.