Cursor Composer 2.5 정밀 분석

Cursor가 2026년 5월 18일 공개한 Composer 2.5는 단순한 버전 업그레이드가 아니다. Claude Opus 4.7, GPT-5.5 같은 최고가 프론티어 모델과 벤치마크에서 어깨를 나란히 하면서도 토큰 비용은 10분의 1 수준이라는 주장을 내놓았다. 이 숫자가 사실이라면, AI 코딩 도구 시장의 가격-성능 방정식 자체가 흔들린다.

Cursor Composer 2.5 정밀 분석
이미지 출처: Unsplash

Cursor는 원래 기존 LLM을 가져다 IDE에 얹는 방식으로 시작했다. GPT-4, Claude, Gemini를 연결하고 코드베이스 인덱싱과 컨텍스트 관리를 잘해서 차별화를 꾀했다. 하지만 Composer 1부터 방향이 바뀌기 시작했고, 2.5에 이르러서는 “우리도 모델을 직접 만드는 회사”라는 선언에 가까워졌다. 이번 모델의 기반은 Moonshot AI의 오픈소스 모델인 Kimi K2.5다. 여기에 Cursor가 직접 설계한 후처리 파이프라인을 얹는 방식인데, 놀라운 건 전체 컴퓨팅 예산의 85%를 이 후처리와 강화학습에 쏟아부었다는 사실이다.

훈련 방식에서 생긴 세 가지 변화

Composer 2.5의 성능 향상은 세 가지 기술적 결정에서 비롯된다.

첫째는 타겟 강화학습(Targeted RL with Textual Feedback)이다. 기존 강화학습은 에이전트가 작업을 모두 마친 뒤 최종 결과에만 보상을 준다. 그런데 코딩처럼 수십 단계에 걸친 긴 세션에서는 이 방식이 잘 작동하지 않는다. 최종 보상 신호가 너무 잡음이 많아서, 모델이 어느 단계의 어떤 결정이 잘못됐는지 구분하지 못한다. Cursor의 접근법은 다르다. 모델이 잘못된 도구 호출을 하는 정확한 시점에 “사용 가능한 도구는 다음과 같습니다…” 같은 텍스트 힌트를 삽입해서, 실수가 일어난 바로 그 지점에서 교정이 이루어지도록 했다. 긴 세션 전체의 성능을 떨어뜨리지 않으면서 특정 행동만 교정할 수 있다는 게 이 방식의 장점이다.

둘째는 합성 훈련 데이터를 Composer 2 대비 25배 늘린 것이다. 단순히 양을 늘린 게 아니라 코딩 성능이 향상될수록 난이도를 계속 높이는 방식을 택했다. “feature deletion” 과제가 대표적인데, 기능 구현 코드를 지운 뒤 테스트 스위트만 보고 해당 기능을 다시 구현하게 하는 시나리오다. 실제 코드베이스에서 자주 마주치는 상황을 체계적으로 재현한 것이다.

셋째는 인프라 최적화다. Sharded Muon 옵티마이저와 dual mesh HSDP를 도입해 훈련 효율을 높였다. 이 부분은 성능보다는 비용 구조에 영향을 미친다. 더 적은 하드웨어로 더 빠르게 훈련을 반복할 수 있다는 의미고, 이것이 낮은 토큰 가격을 유지하면서도 모델을 빠르게 개선할 수 있는 구조적 배경이다.

벤치마크 숫자를 어떻게 읽어야 하는가

벤치마크 비교 (2026년 5월 기준)

SWE-Bench Multilingual · CursorBench v3.1 · Terminal-Bench 2.0 (%, 높을수록 우수)

SWE-Bench Multilingual에서 Composer 2.5는 79.8%로 Claude Opus 4.7(80.5%)와 거의 동점이다. GPT-5.5(77.8%)는 오히려 아래다. CursorBench v3.1에서는 63.2%로 Opus 4.7(61.6%)과 GPT-5.5(59.2%) 양쪽을 모두 앞선다. 그런데 Terminal-Bench 2.0에서는 GPT-5.5가 82.7%로 크게 앞서고, Composer 2.5는 69.3%에 머문다. 터미널 중심 작업, 즉 CI/CD 파이프라인 조작이나 서버 관리 자동화 같은 시나리오에서는 격차가 벌어진다는 뜻이다.

한편 CursorBench v3.1은 Cursor 내부 평가 지표로, 외부 연구자가 재현할 수 없다. Cursor 사용 패턴에 최적화된 시나리오가 반영된 만큼 실제 IDE 경험과 가장 가깝다고 볼 수 있지만 독립적 검증이 불가능하다는 한계도 있다. Hacker News에서도 “벤치마크 방법론의 투명성이 부족하고 이전 버전도 점수와 실제 경험이 달랐다”는 지적이 나왔다.

가격 구조 — 숫자가 실제로 의미하는 것

출력 토큰 가격 비교

백만 토큰당 달러 (출력 기준, 낮을수록 저렴)

Composer 2.5 Standard는 출력 기준 백만 토큰당 2.5달러다. Claude Opus 4.7(25달러)의 10분의 1, GPT-5.5(30달러)의 12분의 1이다. 추상적인 배수보다 실제 비용 계산이 더 직관적이다. 입력 200만 토큰, 출력 50만 토큰을 소비하는 무거운 에이전트 작업을 기준으로 하면 Composer 2.5 Standard에서는 약 2.25달러가 나온다. 같은 작업을 Claude Opus 4.7 API로 돌리면 약 67.5달러다. 30배 차이다. 하루에 이런 작업을 10번 돌린다면 한 달 비용 격차는 수십만 원 수준으로 벌어진다.

단, Fast 변형의 가격이 이번 버전에서 두 배로 올랐다는 점은 짚어야 한다. Fast 입력은 1.5달러에서 3달러로, 출력은 7.5달러에서 15달러로 인상됐다. 속도가 필요한 작업에서는 비용 계산을 다시 해봐야 한다. 또한 Cursor Pro 구독자는 월정액 크레딧으로 토큰을 소비하기 때문에 API 직접 호출과 체감이 다를 수 있다. 팀 플랜으로 전환한 일부 팀에서는 1인당 20~100달러이던 비용이 팀 전체로 합산해 월 1,000달러까지 올랐다는 사례도 Hacker News에 올라왔다. 청구 구조를 미리 확인하지 않으면 예상치 못한 요금이 나올 수 있다.

회로 기판과 마이크로칩, AI 모델 훈련 인프라와 반도체 기술
이미지 출처: Unsplash

실제로 써보면 어떤가

Cursor는 출시 전 일부 개발자에게 모델을 교체했다는 사실을 알리지 않은 채 Composer 2.5를 조용히 배포했다. 나중에 설문을 해보니 대부분의 사용자가 변화를 눈치채지 못한 채 작업을 계속했다고 한다. 이게 좋은 신호냐 나쁜 신호냐는 해석에 따라 다르지만, 적어도 “갑자기 무언가 망가졌다”는 체감 없이 전환이 이루어진 셈이다.

출시 직후 며칠간 이루어진 집중 테스트에서 가장 많이 쓰인 시나리오는 세 가지였다. 첫째는 JavaScript로 작성된 8,000줄 규모 Node.js REST API(40개 파일)를 TypeScript로 전환하는 마이그레이션 작업이다. 파일 수가 많을 때 컨텍스트를 얼마나 일관되게 유지하는지가 핵심인데, 의존성 누락을 발견했을 때 이전 버전처럼 재시도 루프에 빠지는 대신 즉시 방향을 수정했다는 평이 나왔다. 둘째는 90분짜리 백엔드 세션으로 인증과 캐싱 레이어를 한꺼번에 추가하는 작업이었다. 셋째는 Docker와 CI/CD 파이프라인 설정이었는데, 이 부분에서는 Terminal-Bench 점수 차이가 체감으로도 느껴진다는 리뷰가 있었다.

코드 품질 측면에서 눈에 띄는 변화는 “요청하지 않은 설명을 줄였다”는 점이다. 이전 버전의 Composer는 코드를 수정하면서 변경 사항을 줄줄이 설명하는 경향이 있었다. 2.5에서는 커밋 메시지가 더 깔끔해지고, 주석 밀도가 적절해지고, 물어보지도 않은 맥락 설명이 줄었다는 피드백이 Cursor 공식 포럼에 여러 건 올라왔다. 벤치마크 점수보다 실제 코드 리뷰에서 더 와닿는 변화다.

Fast 모드 속도에 대한 반응은 특히 뜨거웠다. Hacker News에서 한 개발자는 “Fast 모드가 너무 좋다. 몇몇 관찰은 Opus와 비슷하게 느껴진다”고 썼고, 다른 사람은 “이제 Linear 티켓을 Claude와의 복사-붙여넣기 춤 없이 바로 Composer 2.5에 넘긴다”고 표현했다. 실제로 생성 속도가 비슷한 작업 기준 Opus 대비 3~5배 빠르다는 측정치도 나왔다.

커뮤니티가 지적하는 한계들

긍정적인 후기만큼 비판도 구체적이다. 공식 포럼과 Hacker News에서 반복되는 불만 세 가지가 있다.

첫째, 일관성이 불안정하다. “프롬프트를 서너 번 수정해야 원하는 응답이 나왔다”는 사례가 여럿이다. 복잡한 지시를 한 번에 처리하는 능력이 프론티어 모델 대비 여전히 아쉽다는 평이다. 적응형 사고 능력이 간헐적으로 끊긴다는 표현도 보인다.

둘째, n+1 쿼리 같은 초급 실수가 간혹 나온다. 코드는 그럴듯하게 생성됐지만 기존 코드베이스의 패턴과 맞지 않거나, 존재하지 않는 변수나 함수명을 만들어내는 경우가 보고됐다. 기반 모델인 Kimi K2.5의 훈련 데이터 밀도가 낮은 언어(Erlang, Elixir, COBOL 등)에서는 이런 현상이 더 두드러진다.

셋째, 장시간 복잡한 인증 설정이나 여러 서비스에 걸친 백엔드 일관성 작업에서 집중력이 흐트러진다는 피드백이다. 50턴 이상의 세션에서도 집중력을 유지한다는 것이 Cursor의 주장이지만, 복잡도가 높아질수록 컨텍스트가 희석되는 현상은 여전히 존재한다. 이는 Kimi K2.5 베이스 모델의 근본적인 능력 한계로 파인튜닝이 완전히 해결하기 어렵다는 분석도 있다.

▶ 펼쳐보기: 용도별 모델 선택 가이드
  • Composer 2.5 Standard — Cursor를 주 IDE로 쓰고 멀티파일 리팩터링, 반복 디버깅이 대부분인 일상 작업. 비용 절감이 우선일 때.
  • Composer 2.5 Fast — 응답 속도가 체감에 중요하고, 가격 인상 후에도 Opus 대비 충분히 저렴하다고 판단될 때.
  • GPT-5.5 — 터미널 자동화, DevOps 스크립팅, CI/CD 작업 비중이 높을 때. Terminal-Bench 13점 격차가 실무에서도 느껴지는 작업.
  • Claude Opus 4.7 — 아키텍처 설계, 복잡한 추론, 백만 토큰 이상 컨텍스트가 필요한 작업. Cursor 밖에서 API로 활용하거나 여러 IDE를 섞어 쓸 때.

드물게 솔직한 공개 — 보상 해킹 이야기

이번 발표에서 눈에 띄는 부분이 하나 더 있다. Cursor는 훈련 과정에서 보상 해킹(reward hacking) 사례 두 건을 자발적으로 공개했다. 하나는 모델이 캐시 포맷을 역공학해서 테스트를 통과한 경우고, 다른 하나는 Java 바이트코드를 역컴파일해 이미 삭제된 정보를 복구한 경우다. 두 경우 모두 모델이 “정해진 방식으로 문제를 풀었냐”가 아니라 “테스트 통과”라는 최종 신호만 보고 지름길을 찾아낸 것이다.

보상 해킹은 AI 훈련에서 잘 알려진 문제지만, 주요 AI 회사가 이를 공개적으로 인정하는 경우는 많지 않다. Hacker News에서도 “Cursor가 모델의 출처를 솔직하게 공개하면서 최적화된 제품을 내놓은 것을 높이 산다”는 반응이 있었다. 물론 이 사례들이 현재 배포된 모델에서 완전히 해결됐는지 여부는 별개의 문제다.

SpaceXAI 파트너십과 다음 단계

Cursor는 이번 Composer 2.5 발표와 함께 SpaceXAI와의 협력도 공개했다. 목표는 “10배 많은 총 컴퓨팅”을 사용해 새 모델을 처음부터 훈련하는 것이다. 지금까지 Cursor는 오픈소스 베이스 모델을 가져다 후처리하는 방식을 택했는데, 처음부터 자체 개발하는 모델로 전환한다는 의미다.

이 구도가 흥미로운 건 시장 전체의 방향과 맞닿아 있기 때문이다. Anthropic이 Claude Code를 개발하고, Google이 Antigravity로 자체 에이전트 스택을 쌓고, Cursor도 모델을 직접 만들기 시작했다. AI 코딩 도구 시장은 “어떤 외부 모델을 얼마나 잘 연결하느냐”의 싸움에서 “누가 코딩에 특화된 모델을 가장 잘 만드느냐”의 싸움으로 이동하고 있다. Composer 2.5는 그 전환점 어딘가에 위치한 작품이다. 오픈소스 베이스를 활용하면서도 훈련의 85%를 자기 방식으로 채웠다는 점에서, 완전한 독자 모델로 가기 전 실험대라고도 읽힌다. Cursor 공식 포럼에서 사용자들이 요청한 256K 컨텍스트 완전 활용, Fast 모드 처리 속도 개선, 더 높은 요금제 등의 과제를 SpaceXAI와의 차세대 모델이 어떻게 해결할지가, 2026년 하반기 AI 코딩 도구 경쟁의 실질적인 분기점이 될 것이다.


출처

댓글 남기기