Composer 2 Fast/Standard
Terminal-Bench 2.0 기준
Cursor Composer 2, 벤치마크 1위라는 말이 사실일까요?
2026년 3월 19일, Cursor가 자체 개발 코딩 모델 Composer 2를 출시했습니다. 공식 블로그는 “Claude Opus 4.6을 Terminal-Bench 2.0에서 이겼다”고 발표했습니다. 그런데 같은 벤치마크의 공식 리더보드를 열어보면 얘기가 달라집니다.
Cursor 공식 제출
(Standard 기준)
실사용 속도 (추정)
Composer 2가 뭔지부터
Cursor Composer 2는 Cursor가 처음 만든 자체 에이전트형 코딩 모델로, 2026년 3월 19일 공식 출시됐습니다. 외부 모델을 API로 연결하는 방식이 아니라 Cursor가 직접 학습시킨 모델입니다. 다만 기반 모델이 중국 Kimi K2.5라는 점은 출시 직후부터 커뮤니티에서 논란이 됐습니다. Cursor 팀원인 lrobinson2011은 Reddit에서 “단순 파인튜닝이 아니라 계속 사전학습(continued pretraining)과 고연산 강화학습(high-compute RL)을 거쳤다”고 직접 밝혔습니다.
Composer 1, 1.5와의 가장 큰 차이는 세 가지입니다. 첫째, 학습 중 자기 요약(self-summarization) 기술을 적용해 장시간 작업에서 맥락을 잃지 않도록 설계됐습니다. 둘째, Fast 변형과 Standard 변형으로 나뉘어 속도·비용 트레이드오프를 선택할 수 있습니다. 셋째, 에디터 내 도구 사용, 파일 편집, 터미널 작업에 특화되어 Cursor 환경에서의 에이전트 작업에 최적화됐습니다.
Pro 플랜 개인 사용자는 Composer 전용 사용량 풀(usage pool)이 적용돼 API 요금을 직접 내지 않습니다. 반면 팀·엔터프라이즈 플랜은 아래 토큰당 요금이 그대로 청구됩니다. 이 차이가 실제 비용 계산에서 생각보다 큽니다.
벤치마크 숫자, 공식 리더보드와 비교해봤습니다
💡 공식 발표문과 동일 벤치마크의 리더보드를 같이 놓고 보니 이런 차이가 보였습니다.
Cursor 공식 블로그는 “Composer 2가 Terminal-Bench 2.0에서 61.7%를 기록했고, Claude Code + Opus 4.6의 58.0%를 앞섰다”고 밝혔습니다. 숫자 자체는 사실입니다. 문제는 이게 전체 리더보드에서 어느 위치냐는 거입니다. (출처: Cursor 공식 블로그 cursor.com/blog/composer-2, 2026.03.19)
Terminal-Bench 2.0 공식 리더보드(tbench.ai, 2026.03.23 기준)를 직접 열어보면, Cursor 제출 결과(61.7%)는 전체 120개 항목 중 30위권에 위치합니다. 1위는 ForgeCode + Claude Opus 4.6 조합으로 81.8%입니다. Cursor가 비교한 Claude Code + Opus 4.6(58.0%)는 39위였고, 같은 Opus 4.6라도 어떤 에이전트를 쓰느냐에 따라 최대 23.8%포인트 차이가 납니다.
| 모델 / 에이전트 조합 | Terminal-Bench 2.0 | 출력 $1M당 |
|---|---|---|
| ForgeCode + Claude Opus 4.6 (1위) | 81.8% | $25 |
| Composer 2 (Cursor 공식 제출) | 61.7% | $2.50 |
| Claude Code + Opus 4.6 (Cursor가 비교 대상으로 제시) | 58.0% | $25 |
| Kimi K2.5 + Terminus 2 (기반 모델) | 43.2% | – |
Cursor는 Claude Code + Opus 4.6 조합만 골라서 비교했습니다. 같은 Opus 4.6에 더 강한 에이전트를 붙이면 20%p 이상 차이가 납니다. 비교 조건이 Composer 2에 유리하게 선택된 셈입니다.
가격 구조, Pro 플랜이라면 다릅니다
공식 문서에 나온 토큰당 가격은 Standard 기준 입력 $0.50/M, 출력 $2.50/M입니다. Fast 변형은 입력 $1.50/M, 출력 $7.50/M로 3배 더 비쌉니다. (출처: cursor.com/docs/models/cursor-composer-2) 같은 출력 성능의 다른 Fast 모델보다는 저렴하다고 공식 문서에 나와 있습니다.
여기서 중요한 분기점이 하나 있습니다. 월 $20짜리 Pro 플랜 개인 사용자는 이 API 가격이 직접 청구되지 않습니다. 플랜에 포함된 Composer 전용 사용량 풀(usage pool)이 따로 잡혀 있고, 소진 전까지는 추가 요금이 없습니다. 반면 팀·엔터프라이즈 플랜 사용자는 위 API 요금이 그대로 청구됩니다. 팀 플랜에서 개발자 10명이 하루 평균 1M 토큰씩 출력을 쓰면, 월 출력 비용만 약 $750이 나옵니다(10명 × 30일 × $2.50). 개인 Pro와 팀 플랜의 실질 비용 구조는 완전히 다릅니다.
Cursor는 제품 기본값을 Fast 변형으로 설정해뒀습니다. 즉, 아무 설정 없이 쓰면 Standard가 아닌 Fast로 돌아가고 있다는 뜻입니다. 비용에 민감하다면 모델 설정에서 Standard로 바꾸는 것이 첫 번째 확인 사항입니다.
실제로 써본 사람들은 뭐라고 했나
Reddit r/cursor 커뮤니티(구독자 약 128,000명)에서 출시 직후 3일간 쌓인 후기들을 정리하면 패턴이 보입니다. 긍정적인 경우는 대부분 “빠르다”는 공통점이 있었고, 부정적인 경우는 “복잡한 백엔드 로직에서 방향을 잃는다”로 수렴됩니다.
사용자 Arindam_200(2026.03.21)은 풀스택 Reddit 클론 빌드 실험을 했는데, 프론트엔드와 배포는 잘 됐지만 인증 로직에서 멈췄다고 했습니다. 두 번째 프롬프트에서 결국 수정됐지만, Opus 4.6이나 GPT-5.4만큼 복잡한 작업의 신뢰도가 나오진 않는다고 봤습니다. 속도는 Opus 4.6 대비 5~7배 빠른 것으로 체감했다고 했습니다(추정치, 공식 수치 아님).
반면 사용자 RafeSacks는 23개 호출 지점을 수정하는 단순한 getLabel() 함수 리팩토링에서 Composer 2가 총 5.8M 토큰을 소모했다고 기록을 남겼습니다. 같은 작업을 Opus 4.6으로 하면 원샷으로 끝났을 거라는 표현도 있었습니다. 속도가 빠른 대신 정밀도가 낮아 결국 반복 횟수가 늘고 총 토큰 사용량이 역전되는 경우입니다. 결국 Composer 2가 진짜 빠른지는 작업 복잡도에 따라 달라집니다.
캐시 토큰 가격이 조용히 비싼 이유
💡 공식 FAQ와 커뮤니티 피드백을 같이 보니, 캐시 구조가 생각보다 비용에 큰 영향을 줬습니다.
AI 코딩 도구를 쓸 때 실제 청구 비용의 상당 부분은 캐시 토큰에서 나옵니다. 반복 작업에서 같은 컨텍스트가 재사용되면 캐시 가격이 적용되는 구조입니다. 일반적으로 다른 모델은 캐시 토큰 가격을 입력 가격의 1/10 수준으로 책정합니다.
Cursor 공식 포럼에서 사용자 rettinem은 “Composer 2의 캐시 토큰 가격이 입력의 1/2.5 수준이고, 이건 경쟁사의 4배”라고 지적했습니다(forum.cursor.com, 2026.03.19). 공식 문서는 이 부분에 대해 별도 이유를 밝히지 않았습니다. 입력 $0.50/M에서 캐시 할인이 1/10이라면 캐시는 $0.05/M이어야 하는데, 1/2.5라면 $0.20/M이 됩니다. 장시간 반복 에이전트 작업에서 이 차이는 무시하기 어렵습니다.
이 문제는 특히 팀·엔터프라이즈 플랜 사용자에게 직접 영향을 줍니다. Pro 플랜 개인 사용자는 풀 방식이라 크게 체감하기 어렵지만, API 요금이 직접 청구되는 플랜이라면 캐시 토큰 구조를 반드시 확인해야 합니다.
어떤 작업에 쓰면 되고, 어떤 작업엔 위험한가
출시 직후 3일간 커뮤니티 피드백과 공식 문서를 교차해보면 패턴이 나옵니다. Composer 2가 잘 하는 작업은 UI 컴포넌트 생성, 보일러플레이트 코드 작성, 반복 리팩토링처럼 정답이 비교적 명확한 작업입니다. 실제로 UI 품질에 대해서는 커뮤니티에서 긍정 평가가 많았습니다.
반대로 믿기 어려운 작업은 복잡한 백엔드 인증 로직, 크로스파일 의존성이 깊은 리팩토링, 대형 코드베이스 전체 이해가 필요한 작업입니다. 사용자 vvrider는 “큰 코드베이스에서 빠르게 처리해줬는데 결과를 확인해보니 틀렸다. 속도가 품질을 떨어뜨렸다”고 했습니다. Bulky-Peach-2500은 “특정 코드 패턴에만 훈련되어 있어서 다른 패턴을 알려줘도 고집을 부린다”는 표현을 썼습니다.
커뮤니티에서 실제로 굳어지고 있는 활용 패턴은 ‘복잡한 설계는 Opus 4.6, 빠른 실행은 Composer 2’입니다. Composer 2로 80%를 빠르게 쌓고, 나머지 민감한 부분만 더 강한 모델로 검토하는 방식입니다. 이게 현재로서는 가장 합리적인 조합으로 보입니다.
| 작업 유형 | Composer 2 | Opus 4.6 |
|---|---|---|
| UI 컴포넌트 생성 | ✅ 빠르고 품질 양호 | ✅ 정밀하나 느림 |
| 보일러플레이트·반복 코드 | ✅ 최적 | 🔶 과하다 |
| 복잡한 인증·보안 로직 | ⚠️ 방향 잃을 수 있음 | ✅ 신뢰도 높음 |
| 크로스파일 대형 리팩토링 | ⚠️ 토큰 낭비 위험 | ✅ 안정적 |
| MCP 서버 연동 작업 | ⚠️ 재시작 필요 보고 있음 | ✅ 안정적 |
자주 묻는 것들 Q&A
마치며 — 솔직한 총평
Composer 2는 나쁜 모델이 아닙니다. Composer 1.5 대비 CursorBench 기준 38.0 → 61.3으로 올라갔고, 실사용자들의 속도 피드백은 대체로 긍정적입니다. 가성비만 따지면 같은 급의 다른 빠른 모델들 중에서 가격 경쟁력이 있습니다.
그런데 “Claude Opus 4.6을 이겼다”는 표현에는 조건이 필요합니다. Claude Code라는 특정 에이전트와 Opus 4.6을 묶었을 때의 비교이고, 더 강한 에이전트를 쓴 조합들은 여전히 20%p 이상 앞서 있습니다. 벤치마크 숫자는 같은 Terminal-Bench 2.0이지만 에이전트 선택에 따라 결과가 크게 달라진다는 점을 발표문에서 강조하지 않은 부분이 좀 아쉬웠습니다.
결론은 간단합니다. 프로토타입 속도를 올리고 싶다면 Composer 2는 지금 당장 시도해볼 가치가 있습니다. 복잡한 프로덕션 코드베이스나 보안에 민감한 로직은 아직 더 강한 모델 옆에 두고 쓰는 편이 낫습니다.
본 포스팅 참고 자료
- Cursor 공식 블로그 — Composer 2 출시 발표 (cursor.com/blog/composer-2)
- Cursor 공식 문서 — Composer 2 모델 스펙 및 요금 (cursor.com/docs/models/cursor-composer-2)
- Terminal-Bench 2.0 공식 리더보드 (tbench.ai/leaderboard/terminal-bench/2.0)
- Cursor 커뮤니티 포럼 — Composer 2 사용 경험 공유 (forum.cursor.com)
- Reddit r/cursor — Composer 2 실사용 후기 (reddit.com/r/cursor)
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다.
모든 수치는 2026.03.23 기준이며, 가격·사용량 정책은 Cursor 공식 사이트에서 최신 정보를 확인하세요.
벤치마크 수치는 공개된 공식 자료 기준이며, 실제 사용 환경에 따라 결과가 다를 수 있습니다.
댓글 남기기