LLM과 에이전트 개발에 대한 소고

지금 LLM 개발 환경에 대해서 느낀 바들을 성기게나마 정리해본다.

내가 LLM을 남들에 비해서 더 잘 쓴다거나 많이 써봤다고 하지는 못하겠지만, 그래도 오랫동안 써오기는 했다.
초창기 Github Copilot이 베타테스트 시작했을때부터 써봤고, 계속해서 변화하고 발전하는 것을 체감했다.
이래저래 쓰면서 느낀 에이전트 개발의 현재와 가능성/한계에 대해서 대강 정리해본다.

Agent의 시작: 자동완성

LLM 기반으로 개발 보조 기능을 처음으로 제공한 것은 Github의 Copilot일 것이다.

현재 에디터에서, 개발자가 작성할 것이라고 예상되는 코드를 미리 완성해서 제시하는 형태다.
코파일럿은 LLM 수준이 저열하던 당시에도 꽤 괜찮은 퀄리티를 보여줬다. 애초에 기능 자체가 단순했기 때문이다.
지금에 와서는 여러모로 개선되긴 했지만, 그래도 2배 넘게 똑똑해지고 그런 정도는 아니다.

이 방법은 LLM 기반 개발의 시발점이 되었다. 현재도 에디터 기반으로 제공되는 LLM 툴링 도구들은 공통적으로 제공하는 기능이기도 하다.
Cursor, Windsurf, Zed 등 AI 메인 에디터들은 모두 이러한 기능을 기본적으로 제공한다.

이건 현재 열려있는 파일만 읽으며, 위에 작성된 코드를 토대로 아래에 코드를 append하는 식으로 동작한다.
별거 아닌것처럼 보이지만, 반복적인 패턴에 대해서는 놀랍도록 훌륭한 결과물을 내기도 한다. 특히 반복적인 보일러플레이트가 많다면 더 그렇다.
하지만 요구사항을 LLM에 전달하지도 못하고, 빠른 반응성을 요구하기 때문인지 많은 컨텍스트를 읽지 못해서 멍청한 판단을 할 때가 많다는 단점이 있다. 조금만 반복성이 떨어지거나 예측하기가 어려우면 오히려 방해가 될 때도 있고.

Agent Tooling: Vibe Coding

vibe 코딩은 여기서 개념을 좀 더 확장한 단계다.
이건 Cursor가 유행을 선도했다고 볼 수 있는데, 요구사항을 텍스트의 형태로 전달해서 원하는 코드를 작성하도록 하는 방법론이다.

여기에도 2가지 파벌이 있다.
에디터에 강력하게 통합된 형태로 제공되는 Cursor, Copilot Chatting, Windsurf, Cline 등이 있고, 약간 독자적으로 출현한 CLI 기반 변종인 Claude Code, Gemini CLI, GPT Codex 등이 있다.

대부분의 Vibe Coding 도구들은 내부적으로 계속해서 자체적인 에이전트 루프를 돌리면서 작성->피드백의 과정을 거친다. 그래서 몇분-몇십분 수준으로 꽤 오래 걸리기도 하고, 토큰을 과도하게 먹을 수도 있다.

내 경험상 가성비 면에서 압도적인 것은 Github Copilot이다.
연 100달러로 가장 저렴하고, 사용량도 꽤 넉넉하며, 모델 선택 범위도 매우 넓기 때문이다. 게다가 기능의 다양성과 범위도 매우 넓다.

순수한 체감 지능/성능은 Claude Code가 가장 뛰어난 것 같긴 하다.
근데 월 20달러로 비싸고, 사용량도 빡빡해서 여러가지 생각이 들게 하는 녀석이다.

IDE와 통합된, 일체화된 경험을 원한다면 Cursor도 좋은 선택이긴 하다.
체감 기능은 Github Copilot보다는 좀 더 나은 것 같기도...?
근데 개인적으로 VSCode 기반인데도 호환되지 않는 VSCode 기능이 많아서 좀 불호였다.

여러가지 모델을 조합해서 사용하고 싶다면 VSCode의 Cline 확장도 좋은 선택이다.
존재하는 거의 모든 모델을 붙여서 쓸 수 있다.

windsurf는 잘 모르겠다. 2등 같은 이미지다.

Agent Tooling: Vibe Coding (remote background)

저 Vibe 코딩 방법론에는 조금 한계가 있다.
로컬에서 로컬 파일 수정하면서 작업하는 것이다보니, 동시에 거의 1가지의 작업밖에 하지 못한다는 것이다.

물론 git worktree같은거 써서 프로젝트 여러개 띄워놓고 작업 시켜도 되긴 하는데... 이런건 솔직히 관리하기 편하진 않다.
그래서 일부 서비스들은 이런 멀티태스크를 용이하게 하기 위한 기능을 제공한다.

인프라와 통합된 것이라 그런지 현재로서는 선택지가 많진 않다.
Github Copilot의 Coding Agent가 가장 잘 만들어진 것 같다.
https://blog.naver.com/sssang97/223878738229
Github Copilot의 태스크 에이전트의 경우에는, 거의 전체 프로젝트를 읽기 때문에 컨텍스트를 좀 더 잘 파악한다는 장점이 있다. 물론 이것도 한계는 있다.

구글에서 만든 jules?라는 것도 있는데, 조용히 뭍힌 것 같더라.

모델별 성능

에이전트 개발에 중요한 것 중 하나는 모델이다. 어떤 모델을 쓰는지에 따라서도 성능이 천차만별이 될 수 있다.

현재 시점에서 개발 품질이 가장 좋다고 판단되는 것은 Anthropic의 Claude 모델들이다.
요즘 여론이나 평가, 개인적인 감상으로 줄을 세워보면, 대충 성능 순서는 이런 느낌이다.
Claude > GPT >= Gemini

Claude가 가장 뛰어나긴 한데, 비싸기도 하고, 압도적으로 몇배 좋고 한건 아니라서 선택의 여지는 있다.
GPT는 요즘 이름값에 비해 좀 후달리는 느낌이고, Gemini는 가성비는 정말 좋은데 실성능이 부족할 때도 많다.

Vibe Coding 개발의 장점

당연하지만, 속도다.
zero-base에서 시작하는 것은 물론이고, 중소규모 프로젝트에서도 놀라운 생산성을 끌어낼 수 있다.

웹서비스나 앱 같은 일반적인 사용사례에서는 충분하다못해 훌륭한 결과물을 내는 경우도 부지기수다.

내 경우에 가장 큰 생산성 향상을 느꼈던 사례는 내부 관리용 백오피스를 만들 때였다.
이런 내부 업무용 시스템이나 자동화 도구 같은, 복잡한 요구사항이나 빈번한 수정이 필요하지 않은 경우에는 가볍게 찍어내서 사용하기에 정말 좋다.

그리고, 멀티태스킹을 하기에도 좋다. 작업이 좀 오래 걸린다면 맡겨놓고 다른 사소한 잡무들을 하면서 인간 병렬처리를 해볼 수도 있다.

현 시점 에이전트 개발의 한계

그럼에도 현 시점에서 한계는 아직 많다.
기존 시스템에 에이전트를 돌린다고 해서 당장 개발 생산성이 몇배 늘고 그러기는 어렵다. 그건 내가 볼때 아직은 망상에 가깝다.

일단, 컨텍스트 관리가 어렵다.
서비스 수준의 컨텍스트, 시스템 수준의 복잡한 히스토리, 아키텍쳐 설계로 인한 결정들, 암묵적으로 발생한 코드 작성 패턴들까지를 전부 LLM에게 인지시키는 것이 쉽지 않기 때문이다.
이것도 사전 프롬프트에 넣어서 개선할 여지는 있지만, 그것도 정도가 있다.

그리고 요구사항을 LLM이 알아들을 수 있도록 "완전하게" 제공하는 것도 간단한 일은 아니다.
맥락상 "당연히" 해야하는 것도 부분적으로 빼먹거나 왜곡해서 작업을 할 수도 있기 때문이다. 사전 프롬프트로 어느 정도는 개선하고 보완할 수 있지만, 사소하고 잡다한 것까지 다 쓸 수도 없는 노릇이다.

테스트코드 작성도 잘 못하는 편이었다. 요즘에는 조금 나아지긴 했는데, 지금도 이상하게 만들거나 망가뜨리는 경우가 자주 관측된다.

그리고 프로그램 개발이 "일반적인" 경우를 벗어나면 급속도로 멍청해지거나 오류를 뱉기 시작한다. 일반적인 코드들을 기반으로 학습된 것이라서 그런지, 조금만 특수한 영역으로 들어서면 보통 품질이 떨어지는 것을 느꼈다.
복잡한 형태의 동시성 프로그램을 개선/최적화하는 것이라든지, 데이터베이스를 만든다든지, 마이너한 라이브러리, 기술을 쓴다든지... 이럴 때는 지시사항을 세세하게 전부 지정하거나, 직접 짜는게 빠를 때도 많다.

게다가 프로젝트의 규모나 복잡도가 어느 임계점을 넘어서면 한계를 보여주기 시작한다.
코드라인을 아무리 짧게 줄이고 파일을 쪼개더라도 극복할 수 없는 한계가 분명이 존재한다. 잠재적인 코드 수정 포인트가 수천줄-만줄을 넘어서면 단순하고 반복적인 수정 작업도 빼먹거나 실수하는 일이 매우 잦다.

그냥 파일을 깨뜨리거나 날려먹어서 처음부터 다시 해야 하는 경우도 부지기수다.

개발자

그럼에도 불구하고, 에이전트는 매우 강력한 보조도구다. 때로는 역량이 낮은 주니어급 개발자의 역할을 무력하게 만들 수도 있다.

그러면 개발자는 이 환경에 맞춰서 어떻게 길을 잡아야 할까?

향후에는 어떨지 모르지만, 지금 AI 기반의 에이전트 개발은 혼자 능동적으로 기술 결정을 하고 개발을 하고, 유지보수를 하진 못한다. 지속적인 책임을 가지지도 못한다. 모든 것을 해내지도 못한다.

일단 중요한 것은 1차적으로는 에이전트가 코드를 잘 작성하고 관리할 수 있도록 구조를 잡고, 가이드라인을 짜는 것이다. 여기엔 여러가지가 있을 수 있다.
프로젝트 레이아웃이나 컨벤션을 잘 잡아서 일관적으로 작성할 수 있게 세팅하고, 코드를 잘 파악할 수 있도록 코멘트를 잘 달고, 코드가 너무 커지면 파일 단위로 분리하는 것 등이 포함될 수 있겠다.

그리고 지금 시점에서는 에이전트가 확실히 효율적인 경우가 있고, 아닌 경우가 있다. 그걸 판단하고 실행해서 리소스를 적절하게 사용하는 것도 꽤 중요하다 본다.

시스템을 큰 그림에서 설계하고, 기술 결정을 할 수 있는 역량은 여전히 필수적일 것 같다.
에이전트에게 물어보면 여러가지 가능한 기술 목록을 제시할 수는 있지만, 대신 선택해주지는 않는다.
현재와 미래, 자원을 고려해서 tradeoff를 판단할 수 있는 역량은 예나 지금이나 중요하다.

시스템의 운영이나 모니터링 등은 한동안은 개발자의 책임으로 남을 것이다. 지속적인 추적, 트러블슈팅, 최적화, 개선 등.
LLM을 활용해서 메트릭 분석이나 정보의 획득을 빠르게 할 수는 있지만, 이런걸 자동화하기에는 어려운 점이 많다.

번외: 코드리뷰

내가 볼때, 일반적인 vibe 코딩보다도 전반적인 생산성을 강력하게 개선할 수 있는 것은 코드리뷰다.
https://blog.naver.com/sssang97/224035641654
복잡하게 터져서 역류한 버그는, 단순 코드 작성보다 긴 시간을 잡아먹을 경우가 많기 때문이다.

위험성이 있는 코드를 잡는 것은 어느 정도 정형화된 부분이 있고, 코드 컨벤션을 미리 잘 정의해두면 실수를 잡기에도 좋다. 컨텍스트가 좀 있는 부분이 아니라면 이런건 사람보다 꼼꼼하게 잘 잡아준다.

내 경우에도 이걸로 많은 실수와 버그들을 빠르게 찾아서 해결할 수 있었다.