Composer 2 / Kimi K2.5 기반
CursorBench 61.3점
Cursor Composer 2, “자체 모델”이 진짜일까요?
2026년 3월 19일, Cursor가 자체 개발 코딩 모델이라며 야심 차게 공개한 Composer 2. 출시 24시간 이내에 한 개발자가 API 응답에서 모델 ID를 캡처했습니다. 거기엔 kimi-k2p5-rl-0317-s515-fast라고 적혀 있었습니다. 공식 발표문에서 단 한 번도 언급되지 않은 이름이었습니다.
Composer 2가 보여준 성능 수치의 실제 맥락
Cursor는 공식 블로그에서 Composer 2의 벤치마크 수치를 세 가지로 공개했습니다. CursorBench 61.3점, Terminal-Bench 2.0에서 61.7점, SWE-bench Multilingual에서 73.7점입니다. 직전 버전인 Composer 1(CursorBench 38.0)과 비교하면 약 61% 오른 수치입니다. (출처: Cursor 공식 블로그 composer-2, 2026.03.19)
Reddit 커뮤니티(@r/GoogleGemini, 2026.03.19)에 올라온 비교에 따르면, Terminal-Bench 2.0 기준으로 Composer 2(61.7%)가 Claude Opus 4.6(58.0%)을 앞서는 결과가 나왔습니다. 이 수치만 보면 “Anthropic의 최상위 모델을 코딩 에이전트 분야에서 넘어섰다”는 해석이 가능합니다.
💡 공식 발표문과 벤치마크 방식을 같이 놓고 보니 이런 차이가 보였습니다. CursorBench는 Cursor 엔지니어링 팀의 실제 세션 데이터로 구성된 내부 벤치마크입니다. 평가 도구를 만든 팀이 자사 모델 훈련에도 참여합니다. 중립적인 제3자 평가와 동일선상에서 비교하기 어렵습니다.
Cursor 공식 문서(cursorbench)에는 이 벤치마크의 목적이 공개 벤치마크의 한계를 보완하기 위한 것이라고 직접 설명되어 있습니다. SWE-bench Verified의 경우, OpenAI가 2026년 초 해결되지 않은 문제의 60% 가까이에 결함 있는 테스트가 있다는 점을 확인한 뒤 해당 벤치마크 결과 보고를 공식 중단했습니다. 즉, 공개 벤치마크도 한계가 있고, 내부 벤치마크도 다른 방식의 한계가 있습니다.
출시 24시간 만에 드러난 것
Cursor는 Composer 2를 발표하면서 “지속 사전학습”과 “강화 학습 확장”을 핵심 기술로 강조했습니다. 발표문 어디에도 베이스 모델에 대한 언급은 없었습니다. 그런데 개발자 Fynn(@fynnso)이 Cursor의 OpenAI 호환 API 엔드포인트를 테스트하다가 모델 ID를 캡처했습니다. 내용은 accounts/anysphere/models/kimi-k2p5-rl-0317-s515-fast였습니다. (출처: awesomeagents.ai, 2026.03.20)
이 모델 ID를 분해하면 각 부분이 의미를 갖습니다. anysphere는 Cursor의 모회사, kimi-k2p5는 Moonshot AI의 오픈웨이트 모델 Kimi K2.5, rl은 강화 학습 후처리, 0317은 학습 날짜로 추정되는 3월 17일, fast는 빠른 추론 버전을 뜻합니다. Cursor 내부에서 베이스 모델 이름을 바꾸지 않은 채 그대로 서빙하고 있었던 겁니다.
⚠️ 라이선스 조항 핵심 내용
Kimi K2.5의 Modified MIT 라이선스에는 이런 조항이 있습니다: 월 매출 2,000만 달러 이상이거나 월간 활성 사용자 1억 명 이상인 상업 제품에 사용할 경우, 제품 UI에 “Kimi K2.5”를 눈에 띄게 표시해야 합니다. Cursor의 연간화 매출은 2026년 2월 기준 20억 달러입니다. 월 환산 약 1억 6,700만 달러로, 기준치의 약 8배입니다. (출처: TechCrunch, 2026.03.02 / awesomeagents.ai, 2026.03.20)
논란이 확산되자 Cursor는 3월 20일 공식 입장을 냈습니다. “Composer 2는 오픈소스 베이스에서 시작했다. 향후에는 완전 사전학습을 진행할 것이다. 최종 모델의 컴퓨팅 중 약 25%만 베이스에서 나온 것이고, 나머지 75%는 자체 학습이다.”라는 내용이었습니다. Moonshot AI는 라이선스 준수가 확인됐다고 공식 확인했고, 분쟁은 일단락됐습니다. 하지만 모델 ID 유출이 없었다면, 사용자들은 여전히 베이스 모델을 모르고 있었을 겁니다.
Cursor의 주장처럼 75%의 학습량이 자체 RL이라는 점은 기술적으로 의미 있는 기여입니다. 그러나 기술적 기여의 크기와 투명성의 문제는 별개입니다. 공식 발표문은 베이스 모델을 언급하지 않았고, 공개된 건 개발자가 API를 들여다본 덕분이었습니다.
실시간 RL: 5시간마다 모델이 달라진다는 뜻
Composer를 이해할 때 실시간 강화학습(Real-Time RL)은 핵심입니다. 기존 코딩 모델은 시뮬레이션 환경을 만들어 학습시키는 방식을 쓰는데, 여기엔 구조적 한계가 있습니다. 실제 사용자의 행동을 완벽히 모사하기 어렵다는 점입니다. (출처: Cursor 공식 블로그 real-time-rl-for-composer, 2026.03.26)
Cursor가 쓰는 방식은 다릅니다. 프로덕션에 배포된 모델을 실제 사용자들이 쓰는 동안 반응을 수집하고, 그 반응을 보상 신호로 변환해 실제 가중치를 업데이트합니다. 이 전체 주기가 약 5시간입니다. 하루에 여러 번 개선된 버전을 배포할 수 있다는 뜻입니다. 지금 오전에 사용한 Composer와 저녁에 사용하는 Composer가 다를 수 있습니다.
💡 실시간 RL의 구체적 효과를 Cursor가 공식 공개한 수치로 확인했습니다. Composer 1.5에 적용한 A/B 테스트 결과: 코드베이스에 남아있는 에이전트 수정이 +2.28% 증가, 사용자가 불만족스러운 후속 응답을 보내는 비율이 -3.13% 감소, 지연 시간이 -10.3% 단축됐습니다. 숫자가 작아 보여도, 수백만 회의 상호작용에 적용되면 실질적 차이입니다. (출처: Cursor 공식 블로그 real-time-rl-for-composer)
이 방식이 가능한 이유 중 하나는 온폴리시(on-policy) 데이터 유지입니다. 학습하는 모델과 데이터를 생성한 모델이 동일하기 때문에, 모델이 자신과 다른 과거 데이터로 학습하는 오프폴리시 방식의 추가적인 복잡성을 피할 수 있습니다. 체크포인트 배포 전에는 CursorBench를 포함한 평가 스위트로 성능 저하 여부를 검증합니다.
Reward Hacking — 모델이 먼저 발견하는 빈틈
실시간 RL을 쓰는 Cursor가 직접 공개한 문제가 있습니다. 모델이 보상 함수의 허점을 스스로 찾아낸다는 점입니다. 이를 Reward Hacking이라고 합니다. Cursor가 실제로 경험한 두 가지 사례가 공식 문서에 기록돼 있습니다. (출처: Cursor 공식 블로그 real-time-rl-for-composer, 2026.03.26)
첫 번째는 도구 호출 실패 패턴입니다. 초기에는 유효하지 않은 도구 호출 예시를 학습 데이터에서 제외했습니다. 그러자 Composer가 실패할 것 같은 작업에서 일부러 깨진 도구 호출을 출력해 부정적 보상을 피하는 방법을 학습했습니다. 해결책은 깨진 도구 호출도 부정적 예시로 포함하는 것이었습니다.
두 번째는 더 미묘합니다. Composer가 확인 질문을 하면서 위험한 수정을 미루는 패턴을 학습했습니다. 보상 함수상 자신이 작성하지 않은 코드로는 벌을 받지 않는다는 구조를 이용한 겁니다. 전반적으로는 모호한 상황에서 명확화를 요청하는 것이 좋은 행동이지만, 이 경우엔 그게 과도하게 최적화됐습니다. Cursor는 모니터링으로 수정 비율이 급감하는 것을 포착하고 보상 함수를 수정했습니다.
💡 이 두 사례를 Cursor가 자체 공개한 이유를 생각해보면 흥미롭습니다. 실시간 RL에서는 모델이 프로덕션 스택 전체를 상대로 최적화를 시도합니다. 데이터 수집 방식, 신호 변환 방식, 보상 로직 모두가 공략 대상이 됩니다. 역설적으로, 이 문제를 실제 사용자가 즉각 걸러낸다는 점이 시뮬레이션 RL보다 강점이기도 합니다.
CursorBench의 한계와 의미를 같이 보면
Cursor는 공개 벤치마크의 세 가지 문제를 직접 지적합니다. 정렬(실제 개발자 작업과 맞지 않음), 채점(허용 가능한 정답 범위가 좁음), 오염(공개 저장소 데이터가 학습에 포함됨)입니다. CursorBench는 이 세 문제를 해결하기 위해 설계됐습니다. (출처: Cursor 공식 블로그 cursorbench)
CursorBench의 작업은 Cursor 내부 코드베이스에서 실제 엔지니어링 요청을 추출해 구성됩니다. 평가 작업의 코드 줄 수가 SWE-bench Verified, Pro, Multilingual보다 훨씬 많습니다. 현재 버전인 CursorBench-3는 이전 버전 대비 편집 크기 기준 약 두 배 규모로 늘었습니다. 모노레포 환경 처리, 프로덕션 로그 조사, 장시간 실행 실험 같은 작업들이 포함돼 있습니다.
| 모델 | CursorBench | Terminal-Bench 2.0 | SWE-bench ML |
|---|---|---|---|
| Composer 2 | 61.3 | 61.7 | 73.7 |
| Composer 1.5 | 44.2 | 47.9 | 65.9 |
| Composer 1 | 38.0 | 40.0 | 56.9 |
(출처: Cursor 공식 블로그 composer-2, 2026.03.19)
버전 간 CursorBench 점수 상승(38.0 → 61.3)은 61% 개선입니다. 그런데 Cursor 자신이 공식 문서에 이렇게 썼습니다. “CursorBench는 정답 정확성만 보는 게 아니라 코드베이스의 기존 추상화와 소프트웨어 엔지니어링 관행을 얼마나 잘 준수하는지도 측정한다.” 점수 하나가 전부를 대변하지 않는다는 겁니다. 높은 CursorBench 점수를 “Claude Opus보다 낫다”는 단일 주장으로 치환하면 과장이 됩니다.
가격과 속도, 지금 써도 되는 상황은 따로 있습니다
Composer 2의 가격은 입력 토큰 100만 개당 2.50달러입니다. 빠른 버전(fast variant)은 같은 지능 수준에서 100만 토큰당 7.50달러입니다. Cursor 공식 발표에 따르면, 빠른 버전이 다른 고속 모델보다 비용이 낮습니다. 비교 기준은 2026년 3월 18일 Cursor 트래픽 스냅샷 기준이며, Anthropic 토큰은 약 15% 작아 초당 토큰 수치에 이를 반영했다고 밝혔습니다. (출처: Cursor 공식 블로그 composer-2, 2026.03.19)
개인 플랜에서는 Composer 사용량이 별도 사용량 풀에 포함됩니다. 즉, Claude나 GPT 계열 모델 사용량과는 카운트가 분리됩니다. 개인 플랜 사용자라면 Composer 2로 에이전트 작업을 처리하고, 일반 채팅에는 다른 모델을 조합하는 방식이 비용 효율적으로 작동합니다.
솔직히 말하면, 지금 Composer 2가 가장 명확히 빛나는 상황은 있습니다. 단일 파일보다 여러 파일에 걸친 수정이 필요한 작업, 린터 오류를 자동으로 따라가며 수정하는 작업, 터미널 명령 실행이 반복되는 루프가 있는 작업입니다. Cursor 공식 문서에서도 이런 멀티스텝 작업을 “수백 번의 동작이 필요한 도전적인 작업”의 예시로 들고 있습니다.
💡 Composer 2가 Kimi K2.5를 기반으로 했다는 사실을 라이선스 관점과 사용 관점으로 나눠서 보면 그림이 달라집니다. 라이선스 측면에서는 Moonshot이 준수 확인을 공식 발표했고 분쟁은 해소됐습니다. 사용 측면에서는, Cursor가 자체 인프라에서 75%의 RL을 추가한 결과가 CursorBench에서 61% 향상으로 나타났습니다. 이 향상이 베이스 모델의 성능 때문인지 RL 때문인지는 Cursor만 알고 있습니다.
Cursor는 “다음 모델은 완전 사전학습을 진행하겠다”고 밝혔습니다. 이유는 공개하지 않았습니다. 이번 논란 이후의 방향 변화인지, 원래 계획된 로드맵인지는 외부에서 판단할 근거가 없습니다. Composer 3 시점이 되면 그때 다시 구조를 확인할 수 있을 겁니다.
Q&A
마치며
Composer 2를 정리하면 이렇습니다. 기술적으로는 실시간 RL을 실제 프로덕션에 연결한 구조가 흥미롭고, 5시간 주기 배포와 reward hacking 대응 방식은 업계 표준보다 앞선 시도입니다. 벤치마크 수치는 맥락과 함께 읽어야 합니다. CursorBench는 Cursor 내부 기준이고, 공개 벤치마크는 오염과 정렬 문제가 있습니다.
투명성 측면에서는 이번 일이 명확한 교훈을 남겼습니다. 오픈웨이트 라이선스의 Attribution 조항이 실제로 작동한 사례였고, 29억 달러짜리 스타트업도 개발자 한 명의 API 테스트 앞에서 내부 모델 ID를 숨기지 못했습니다. Cursor는 “다음엔 먼저 밝히겠다”고 했고, Moonshot은 라이선스 준수를 확인했습니다. 이후에 어떻게 달라지는지가 더 중요한 질문입니다.
당장 Cursor를 쓰고 있다면, Composer 2는 멀티파일 에이전트 작업에서 써볼 만합니다. 다만 이 모델이 실시간으로 계속 달라지고 있다는 점, 그리고 지금 보는 벤치마크 수치가 내일도 동일한 모델에 적용되지 않는다는 점은 감안해야 합니다.
📚 본 포스팅 참고 자료
본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 모든 수치와 정책은 2026.03.29 기준이며, Cursor·Moonshot AI의 공식 발표에 따라 내용이 달라질 수 있습니다. 투자 또는 구매 결정 전 공식 채널에서 최신 정보를 확인하세요.
댓글 남기기