"Claude Code 쓰면 진짜 생산성 올라가요?" 이 질문에 제대로 답하려면 허니문 기간이 끝난 뒤의 이야기를 해야 한다. 설치 직후 감탄사가 나오는 건 당연하다. 진짜 질문은 30일째 되는 날, 프로덕션에서 버그가 터졌을 때 어떤 일이 벌어지는가다.
도구는 인상적이다. 단, 조건부로
dev.to에 올라온 30일 실사용 경험담은 솔직하다. 그린필드 코드 생성, 스코프가 명확한 디버깅, 낯선 레거시 코드베이스 파악—이 세 영역에서 Claude Code는 실제로 80% 정도를 뚝딱 해낸다. 200K 컨텍스트 윈도우 덕분에 뒤엉킨 모듈 전체를 삼키고 읽을 수 있는 요약을 뱉어내는 건 인상적이다. 47개 태스크 중 8시간을 절약했다는 수치는, AI 코딩 도구가 분명히 생산성에 기여한다는 사실을 보여준다.
그런데 실패 패턴이 더 흥미롭다. 멀티 파일 리팩토링을 시키면 한 파일만 바꾸고 나머지와의 정합성을 잃는다. 테스트는 통과하지만 잘못된 동작을 검증하는 테스트를 작성한다. 그리고 세션이 3시간을 넘어가면 '컨텍스트 블리딩'이 시작된다—현재 최선이 아니라 자신이 이미 쓴 것에 기반해 판단하기 시작하는 것이다. 이 세 가지 실패 패턴은 사실 하나의 공통 원인을 가리킨다: 단일 에이전트의 컨텍스트 한계.
해결책은 더 좋은 프롬프트가 아니다
많은 사람이 이 한계를 프롬프트 개선으로 돌파하려 한다. 더 정교하게, 더 상세하게, 더 구조적으로. 하지만 같은 에이전트에게 다섯 번 묻는 것보다 다른 에이전트에게 한 번 묻는 게 빠를 때가 있다. 모델마다 블라인드 스팟이 다르기 때문이다.
dev.to의 멀티 에이전트 협업 아티클은 이 지점을 정확히 짚는다. Claude는 아키텍처 추론에 강하지만 단순한 수정을 과하게 생각하는 경향이 있고, Codex는 빠르고 실용적이지만 엣지 케이스를 놓친다. Gemini는 리서치에 강하지만 코드베이스 컨벤션을 모를 수 있다. 이걸 수동으로 조율하는 건—컨텍스트 복사, 붙여넣기, 번역—느리고 고통스럽다.
agent-link-mcp는 이 수동 조율을 자동화한다. Claude Code가 MCP 서버를 통해 Codex나 Gemini를 CLI 서브프로세스로 직접 호출하는 구조다. WebSocket 재연결 핸들러 디버깅 사례가 구체적이다—Claude가 같은 방향으로 세 번 실패하자 Codex에게 넘겼고, Codex는 20초 만에 원인을 찾았다. 재연결 로직에 집중하느라 Claude가 놓쳤던 이벤트 리스너 누수 문제였다. '두 번 실패하면 다른 에이전트에게 물어봐라'는 Two-Strike Rule은, CLAUDE.md에 한 줄 추가하는 것만으로 워크플로우에 내재화된다.
모델 전쟁이 끝난 자리에 남은 것
더 큰 맥락에서 보면, 이 모든 실전 경험이 가리키는 방향이 있다. "The Model Wars Are Over. Now Comes the Hard Part."라는 제목의 아티클이 이 흐름을 잘 포착한다—GPT-4급 추론은 이제 기본값이 됐고, 어떤 주요 모델 API에 잘 짜인 프롬프트를 던져도 쓸 만한 결과가 나온다. '어떤 모델이 더 똑똑한가'는 더 이상 흥미로운 질문이 아니다.
진짜 흥미로운 질문은 그 다음에 있다. 한 팀이 RAG 시스템 정확도를 높이기 위해 3개월 동안 모델을 바꿔가며 실험했는데, 결국 문제는 청킹 전략과 재랭킹이었다는 사례가 이를 방증한다. 모델 교체로 얻은 개선은 미미했지만, 리트리벌 레이어를 고쳤을 때 정확도가 40% 뛰었다. 모델은 병목이 아니었다.
AI 코딩 에이전트 맥락에서도 마찬가지다. Claude Code가 멀티 파일 리팩토링에서 실패하는 건 Claude가 나빠서가 아니다. 단일 에이전트에게 모든 걸 맡기는 아키텍처의 한계다. 해결책은 더 좋은 모델이 아니라—한 태스크, 한 세션 원칙으로 컨텍스트를 관리하고, 막혔을 때 다른 에이전트에게 위임하는 시스템을 설계하는 것이다.
지금 당장 써먹을 수 있는 것
세 기사를 종합하면 실전에서 바로 적용 가능한 패턴이 나온다. 첫째, 세션은 짧게—긴 세션은 컨텍스트 블리딩을 유발하고, 한 태스크가 끝나면 새 세션을 시작하는 게 낫다. 둘째, 테스트는 결과가 아니라 로직을 검토하라—통과하는 테스트가 올바른 테스트는 아니다. 셋째, 같은 문제로 두 번 막혔다면 다른 모델에게 넘겨라—멀티 에이전트 협업은 거창한 인프라가 아니라 CLAUDE.md 한 줄에서 시작된다.
그리고 가장 중요한 것: 모델 선택에 쓰는 에너지를 평가 시스템 구축에 써라. 어떤 태스크에서 에이전트가 실패하는지, 컨텍스트가 어디서 드리프트되는지, 어떤 종류의 버그가 리뷰를 통과하는지—이 데이터 없이 하는 모델 비교는 그냥 느낌이다.
앞으로의 흐름
멀티 에이전트 협업 패턴은 아직 초기다. agent-link-mcp 같은 도구가 오픈소스로 풀리고 있고, MCP 생태계가 확장되면서 에이전트 간 통신의 마찰은 점점 줄어들 것이다. 동시에 '복잡성을 위한 복잡성'의 함정도 경계해야 한다—일곱 개 에이전트를 체이닝하기 전에, 좋은 프롬프트 하나로 해결되는 문제인지 먼저 물어보는 게 맞다.
AI 코딩 도구의 성숙도는 이제 '얼마나 인상적인가'에서 '얼마나 예측 가능하게 실패하는가'로 측정 기준이 옮겨가고 있다. 한 달을 써봐야 보이는 것들이 있다. 그리고 그것들을 시스템으로 다루기 시작할 때, 도구는 비로소 인프라가 된다.