에이전트 전쟁이 본격화됐다
이제 AI 코딩 도구를 고르는 일이 IDE 선택보다 복잡해졌다. Cursor가 Composer 2.5를 출시하면서 '에이전트 인프라 전쟁'의 윤곽이 선명해졌고, Claude Code와 OpenCode는 서로 다른 철학으로 같은 시장을 겨냥하고 있다. 문제는 기능 비교표만 보고 도입 결정을 내리면, 나중에 청구서를 보고 �멘붕이 온다는 것이다.
Cursor Composer 2.5: 에이전트 인프라 베팅
dev.to의 분석에 따르면, Composer 2.5의 핵심은 더 나은 자동완성이 아니다. Cursor가 진짜 베팅하는 건 장기 실행 에이전트(long-horizon agent) 영역이다. 멀티 파일 수정, 인프라 마이그레이션, 몇 시간짜리 리팩터링—기존 코딩 모델이 맥락을 잃고 루프에 빠지던 바로 그 지점을 타깃으로 한다.
기술적으로는 실제 소프트웨어 엔지니어링 환경(터미널, 툴 체인, 멀티스텝 실행 체인) 안에서 강화학습(RL)을 돌리는 방식이다. 벤치마크 점수가 아니라 실제 에이전트 워크플로우에서 최적화된 모델을 만들겠다는 전략이다. Composer 2가 Moonshot AI의 Kimi K2.5 기반임을 뒤늦게 공개해 논란이 됐던 것처럼, Cursor의 차별화 포인트는 기반 모델 자체가 아니라 RL 인프라와 에이전트 트레이닝 환경에 있다.
이 방향이 중요한 이유는 하나다. AI 코딩 시장이 '파운데이션 모델 레이어'와 '에이전트 오케스트레이션 레이어'로 분리되고 있고, Cursor는 후자에 방어선을 치고 있다. 모델은 빠르게 상품화되지만, 오케스트레이션 품질—툴 신뢰성, 메모리 처리, 실행 복구—은 훨씬 천천히 따라잡힌다.
Claude Code vs. OpenCode: 통제권의 트레이드오프
두 도구의 아키텍처는 표면적으로 비슷하다. 레포를 읽고, 파일을 수정하고, 커맨드를 실행하는 기본 에이전트 루프는 동일하다. 차이는 누가 하네스를 통제하느냐에 있다.
Claude Code는 Anthropic이 하네스를 통제한다. 프롬프트 캐싱, 네이티브 툴 콜, Claude의 롱 컨텍스트 동작이 긴밀하게 통합돼 있다. CLAUDE.md의 시스템 프롬프트와 툴 정의가 턴 사이에 캐시되면서 장시간 세션의 비용과 속도가 최적화된다. 단점은 명확하다—Claude 하나에 종속되고, 헤비 유저는 월 $200짜리 Max 플랜도 벽에 부딪힌다.
OpenCode는 개발자가 하네스를 직접 구성한다. Claude, GPT, Gemini, 로컬 모델 포함 75개 이상의 프로바이더를 연결할 수 있고, AGENTS.md는 벤더 종속 없이 팀 전체가 공유 가능한 포터블 메모리 파일이다. 유연성이 장점이지만, 프로바이더별로 다른 툴 콜 ID, 캐시 지원 방식, 컨텍스트 한계를 직접 노멀라이즈해야 한다는 운영 비용이 따른다.
팀 관점에서 판단 기준은 단순하다. Anthropic 모델에 대한 신뢰와 낮은 운영 복잡도를 원하면 Claude Code, 모델 유연성과 커스터마이징 수준이 중요하다면 OpenCode다. 단, 어느 쪽이든 토큰 비용 구조를 이해하지 못하면 예산이 날아간다.
숨겨진 청구서: 토큰 비용의 진짜 구조
dev.to의 토큰 이코노믹스 분석이 이 문제를 정면으로 다룬다. AI 코딩 에이전트의 비용은 프리픽스 캐싱(prefix caching) 의 작동 방식에 따라 최대 46배까지 차이 난다.
대부분의 에이전트가 쓰는 '트랜스크립트 방식'은 매 턴마다 전체 대화 이력을 모델에 전달한다. 세션이 살아있는 동안은 90% 이상이 캐시 히트되면서 턴당 비용이 극히 낮게 유지된다. 좋아 보이지만, 함정이 있다.
- 캐시 TTL: 5~10분 비활성이면 캐시 소멸
- 컨텍스트 한계: 세션이 길어지면 컴팩션(compaction)이 발생하면서 다음 요청은 풀 비용
- 품질 저하: 디버깅 잡음, 막다른 툴 출력이 쌓이면서 프롬프트 품질도 떨어짐
실제 측정값을 보면 현실이 명확해진다. 오전 9시 20분 신규 세션에서 257K 토큰 요청이 $0.4455였던 반면, 오후 4시 20분 같은 세션 내 300K 토큰 요청은 $0.0096이었다. 캐시 히트 여부가 가격을 46배 벌려놓은 것이다.
대안은 '구조화된 상태(structured state)' 방식이다. 전체 대화 이력 대신 핵심 상태만 추출해서 전달한다. 실제 44턴 디버깅 세션에서 트랜스크립트 3,777 토큰을 상태로 압축하면 740 토큰—80.4% 감소다. 비용뿐 아니라 코드 품질도 개선됐다는 게 주목할 만하다. 세션 간 컨텍스트가 지속되니 매번 새로 시작하는 비용도 없다.
팀 도입 전에 따져야 할 것들
세 가지 분석을 교차하면 실용적인 결론이 나온다.
에이전트 선택 기준은 기능 목록이 아니라 두 가지다. 첫째, 팀이 통제권과 유연성 중 무엇을 더 필요로 하는가. 둘째, 장시간 세션과 크로스 세션 워크플로우에서 비용 구조가 예측 가능한가.
숨겨진 비용 체크리스트도 필요하다. 캐시 TTL 내에서 세션을 유지할 수 있는 워크플로우인지, 컨텍스트 한계에 도달했을 때 컴팩션 비용을 산정했는지, 구조화된 상태 방식으로 크로스 세션 비용을 통제할 수 있는지.
Cursor Composer 2.5가 보여주는 방향—에이전트 오케스트레이션 레이어가 모델 자체보다 빠르게 경쟁력이 되는 세계—에서, 도구 선택의 실제 기준은 벤치마크 점수가 아니다. 실제 팀 워크플로우에서 세션이 무너졌을 때 비용이 얼마나 튀는지, 그 구조를 설계로 통제할 수 있는지가 진짜 질문이다.
지금 해야 할 결정
AI 코딩 에이전트 시장은 빠르게 오케스트레이션 레이어 경쟁으로 이동하고 있다. 내일 당장 도구를 고른다면 이 순서로 접근하길 권한다.
- 팀의 세션 패턴을 파악하라. 단기 집중 세션인가, 몇 시간짜리 장기 실행인가.
- 트랜스크립트 방식의 캐시 의존도를 계산하라. 캐시 미스가 46배 비용 스파이크를 의미한다면, 그건 예산 리스크다.
- 모델 종속성 허용 범위를 팀과 합의하라. Claude Code의 통합 최적화를 택할 것인가, OpenCode의 멀티 프로바이더 유연성을 택할 것인가.
에이전트가 IDE에서 인프라로 진화하는 지금, 도구 선택은 기술 결정이 아니라 운영 비용 설계다.