Cursor가 Composer 2를 공개하면서 팀들이 에이전트를 늘리기 시작했다. Kimi K2.5 파인튜닝 기반으로 Anthropic·OpenAI 모델에 맞먹는 코딩 성능을 훨씬 저렴하게 제공한다는 포지셔닝은 매력적이다. 가성비가 좋으면 더 많이 쓰게 된다. 에이전트를 하나 더 띄우는 데 망설임이 줄어든다. 그런데 바로 여기서 함정이 시작된다.
에이전트를 늘릴수록 왜 더 느려지나
에이전트 하나를 쓸 때는 마법처럼 느껴진다. 다섯, 여섯 개를 동시에 돌리는 순간 병목 지점이 바뀐다. 코드 생성이 느린 게 아니다. 조율이 느리다. dev.to에 SAMAMS(Sentinel Automated Multiple AI Management System) 구축 경험을 공개한 개발자는 이 현상을 정확하게 짚었다. 같은 파일을 여러 에이전트가 동시에 건드리고, 작업이 중복되고, 결과물이 충돌하고, 한 에이전트가 조용히 이탈해서 토큰을 태우는 동안 사람이 전체를 수동으로 감시해야 했다. 에이전트를 추가할수록 생산성이 아니라 관리 오버헤드가 쌓인 것이다.
이 문제의 본질은 우리가 오래전에 팀 조직에서 이미 풀었던 문제다. 소유권, 경계, 작업 분해, 검증. SAMAMS는 이 원칙을 에이전트 레이어에 그대로 적용한다. Proposal → Milestone → Task 3단계 계층 구조로 작업을 분해하고, 각 에이전트에게 DDD(Domain-Driven Design) 방식의 바운디드 컨텍스트를 부여한다. 더 중요한 건 git worktree로 물리적 격리를 구현한다는 점이다. 개념적 경계만으로는 부족하다. 에이전트가 실제로 다른 워크스페이스에서 작업해야 충돌이 사라진다.
토큰 비용은 모델 가격표가 아니라 세션 구조가 결정한다
Composer 2의 가격이 싸다고 안심하면 안 된다. 진짜 비용은 다른 곳에서 온다. Claude Code 38개 세션, 총 4,290만 토큰을 분석한 데이터가 이걸 명확하게 보여준다. 실제 코드 출력은 전체 토큰의 0.6%에 불과했다. 나머지 99.4%는 Claude가 응답 전에 대화 히스토리 전체를 다시 읽는 데 썼다.
이게 왜 문제인가. 복리 구조이기 때문이다. 메시지 50번째에는 1~49번 히스토리를 전부 재독한다. 메시지 100번째에는 1~99번을 전부 재독한다. 해당 분석에서 가장 나쁜 세션은 API 비용 환산 기준 6.30달러가 나왔고, 중앙값은 0.41달러였다. 차이는 딱 하나, 5시간 넘게 /clear 없이 세션을 방치했느냐 아니냐였다. Cursor를 쓰든 Claude Code를 쓰든 동일한 원리가 적용된다.
팀이 지금 당장 바꿔야 할 세 가지 구조
첫째, 에이전트에 바운디드 컨텍스트를 부여하라. 파일 단위, 모듈 단위로 소유권을 명시적으로 정의하지 않으면 에이전트들은 필연적으로 충돌한다. SAMAMS의 'frontier' 문서처럼, 에이전트가 무엇을 해야 하고 무엇을 건드리지 말아야 하는지를 지시 문서로 고정하는 것이 출발점이다.
둘째, 세션을 태스크 단위로 잘라라. 연관 없는 작업 사이에 컨텍스트를 공유할 이유가 없다. 테스트 작성 에이전트는 직전 디버깅 히스토리가 필요 없다. 세션을 60분 이내로 유지하고, 독립적인 태스크 사이에는 반드시 초기화하는 것이 비용과 품질 양쪽에 영향을 미친다.
셋째, 실패 복구를 사람 개입 없이 처리할 구조를 만들어라. 에이전트 하나가 실패했을 때 사람이 멈춰서 상태를 점검하고 다음 행동을 결정하는 구조는 에이전트 수가 늘어날수록 확장되지 않는다. SAMAMS의 'strategy meeting' 개념처럼, 실패 감지 → 상태 수집 → 재시도/취소 결정을 시스템이 자동으로 처리하는 흐름이 필요하다.
모델 경쟁보다 조율 설계가 먼저다
Composer 2가 Kimi K2.5 파인튜닝 기반이라는 사실이 커뮤니티에서 논란이 됐지만, 오히려 이 사건이 보여주는 건 다른 메시지다. AI 시장의 경쟁축이 '처음부터 모델을 만드는 것'에서 '공개된 모델을 특정 도구에 얼마나 잘 최적화하느냐'로 이동하고 있다. Cursor는 Kimi K2.5의 25%를 기반으로, 나머지 75%를 자체 강화학습으로 채웠다. 베이스 모델보다 파인튜닝 설계가 성능을 결정하는 시대다.
팀 워크플로우도 같은 논리가 적용된다. 어떤 모델을 쓰느냐보다 그 모델을 어떤 구조 위에서 돌리느냐가 결과를 결정한다. Composer 2가 싸고 빠르다는 건 에이전트를 더 많이 쓸 수 있다는 의미지, 아무렇게나 써도 된다는 의미가 아니다. 병렬 에이전트의 병목은 항상 조율에 있었고, 앞으로도 그럴 것이다.
전망: 오케스트레이션 레이어가 다음 경쟁 지점이다
SAMAMS는 아직 초기 프로토타입이고 프로덕션 수준의 완성도는 아니다. 하지만 이 프로젝트가 가리키는 방향은 분명하다. 에이전트 수가 늘어날수록 오케스트레이션 레이어의 필요성은 선형이 아니라 기하급수적으로 커진다. Cursor나 GitHub Copilot 같은 도구들이 이 레이어를 직접 내재화할지, 아니면 서드파티 솔루션이 채울지는 아직 열려 있다. 하지만 팀 단위에서 지금 당장 할 수 있는 건 명확하다. 에이전트를 늘리기 전에 조율 구조를 먼저 설계하고, 토큰 복리 비용을 세션 단위로 관리하는 규칙을 팀 컨벤션으로 고정하는 것. 도구가 싸질수록 구조 설계의 가치는 올라간다.