Opus 4.7의 1/10 비용으로 동급 성능이 가능한가 — Cursor Composer 2.5 실전 분석

"같은 벤치마크, 10분의 1 비용." Cursor가 2026년 5월 18일 공개한 Composer 2.5의 핵심 주장입니다. 1조 파라미터 규모 MoE 베이스 모델에 자체 강화학습을 적층해, Claude Opus 4.7·GPT-5.5와 코딩 벤치마크에서 대등한 수준을 토큰당 $0.50에 달성했다고 밝혔습니다. 가능한 이야기일까요? 아키텍처부터 실제 사용 패턴, 벤더 벤치마크의 한계, 그리고 다음 세대 로드맵까지 실무 기준으로 풀었습니다.

---

이 포스트 한 줄 요약 → 출시일: 2026년 5월 18일 (Cursor IDE 내 기본 탑재) → 베이스 모델: Moonshot AI Kimi K2.5 (1.04T 파라미터, 32B 활성 MoE) → 학습: Composer 2 대비 합성 태스크 25배, 타깃 텍스트 피드백 RL 신규 적용 → Standard 가격: 입력 $0.50 / 출력 $2.50 per 1M tokens → Fast 가격: 입력 $3.00 / 출력 $15.00 per 1M tokens → SWE-Bench Multilingual 79.8% (Opus 4.7: 80.5%), CursorBench v3.1 63.2% → Terminal-Bench 2.0 69.3% — GPT-5.5 (82.7%) 대비 13pt 뒤처짐 ⚠️ → 모든 벤치마크는 벤더 직접 측정 — 독립 검증 부재 → Cursor IDE + @cursor/sdk 전용 — 범용 API 없음 → 다음 세대: SpaceXAI와 Colossus 2에서 10배 컴퓨팅으로 처음부터 학습 중

 

---

Composer 2.5가 등장한 배경

2026년 AI 코딩 도구 시장은 두 개의 전선이 충돌하는 구도입니다. 한쪽은 Anthropic·OpenAI·Google이 범용 프론티어 모델을 CLI 코딩 에이전트로 확장하는 방향(Claude Code, Codex, Antigravity). 반대쪽은 Cursor처럼 IDE 네이티브 환경을 코딩에 특화하는 방향입니다.

Cursor는 2026년 초 연간반복매출(ARR) $2B를 달성했지만 경쟁이 격화됐습니다. Composer 2가 나온 지 두 달 만에 2.5를 출시한 이유가 여기에 있습니다. 핵심 베팅은 단순합니다. 베이스 모델을 바꾸지 않고, 강화학습만으로 프론티어 성능에 근접할 수 있는가.

---

아키텍처 — Kimi K2.5 위에 무엇을 올렸나

Composer 2.5는 처음부터 학습한 모델이 아닙니다. Moonshot AI의 오픈소스 체크포인트 Kimi K2.5를 베이스로, Cursor 자체 포스트트레이닝 파이프라인을 올린 구조입니다.

베이스 모델 스펙

항목 사양

모델	Moonshot AI Kimi K2.5
총 파라미터	1.04조 (1.04T)
추론 시 활성 파라미터	약 32B (MoE 구조)
라이선스	Modified MIT
출시	2026년 1월 29일

Cursor가 공개한 학습 개선 포인트 세 가지입니다.

① 타깃 텍스트 피드백 RL 기존 RL은 전체 롤아웃의 최종 결과에 대해서만 보상을 줬습니다. 2.5에서는 실패한 도구 호출이 발생한 해당 지점에 로컬라이즈된 텍스트 힌트를 주입하는 방식으로 전환했습니다. 긴 에이전트 세션에서 중간 오류를 스스로 교정하는 능력이 이 방식으로 개선됐습니다.

② 합성 태스크 25배 확장 Composer 2 대비 훈련에 사용된 합성 태스크를 25배 늘렸습니다. "피처 삭제 후 재구현" 같은 복잡한 재건 퍼즐을 포함시켜 실제 프로덕션 환경에 가까운 시나리오를 더 많이 학습했습니다.

③ Sharded Muon 옵티마이저 + 듀얼 메시 HSDP MoE 규모에서 안정적인 학습을 위한 인프라 최적화입니다. Composer 2.5는 Colossus 2 인프라에서 일부 학습이 이뤄졌으며, 이는 SpaceXAI 파트너십의 초기 적용입니다.

---

벤치마크 — 어디까지 믿을 수 있나

Cursor가 공식 발표에서 제시한 수치입니다.

벤치마크 Composer 2 Composer 2.5 Claude Opus 4.7 GPT-5.5

CursorBench v3.1	52.2%	63.2%	62.1%	59.2%
SWE-Bench Multilingual	73.7%	79.8%	80.5%	77.8%
Terminal-Bench 2.0	61.7%	69.3%	69.8%	82.7%

중요한 주의사항이 있습니다. CursorBench v3.1은 Cursor 자체 설계 벤치마크이고, SWE-Bench Multilingual과 Terminal-Bench 2.0 역시 Cursor 내부 하네스로 측정된 수치입니다. 독립 기관의 제3자 검증은 5월 26일 현재 없습니다.

실제로 판단할 때 주목할 부분은 두 가지입니다. CursorBench·SWE-Bench에서 Opus 4.7과 사실상 동급인 점은 멀티파일 편집, 테스트 실행, 도구 호출 중심 워크플로에서는 실무적으로 의미 있는 차이가 없을 수 있습니다. 반면 Terminal-Bench 2.0에서 GPT-5.5와의 13pt 격차는 쉘 스크립트, CLI 에이전트, DevOps 자동화 중심 팀에게 실질적인 약점입니다.

---

가격 구조 — Composer 2 대비 무엇이 달라졌나

Standard 티어 (백그라운드 작업, 비용 최적화 우선)
  입력: $0.50 / 1M tokens  ← Composer 2와 동일 유지
  출력: $2.50 / 1M tokens  ← Composer 2와 동일 유지

Fast 티어 (인터랙티브 코딩, 즉각 응답 우선)
  입력: $3.00 / 1M tokens  ← Composer 2 대비 2배 인상
  출력: $15.00 / 1M tokens ← Composer 2 대비 2배 인상

Cursor는 Fast 티어를 대화형 코딩의 기본값으로 권장합니다. 백그라운드 에이전트 작업이나 클라우드 CI 파이프라인에서는 Standard 티어를 사용하면 됩니다.

Opus 4.7 대비 비용 비교 (실제 에이전트 세션 예시)

시나리오: 100K 입력 + 20K 출력 에이전트 태스크 1회

Composer 2.5 Standard:
  입력: 100K × $0.50/M = $0.05
  출력:  20K × $2.50/M = $0.05
  합계: $0.10 / 태스크

Claude Opus 4.7 Standard:
  입력: 100K × $5.00/M = $0.50
  출력:  20K × $25.00/M = $0.50
  합계: $1.00 / 태스크

→ 실효 비용 차이: 10배

하루 1,000회 에이전트 태스크를 돌리는 팀이라면 월 $3,000 vs $30,000의 차이가 됩니다.

---

실전 사용 — Cursor IDE와 @cursor/sdk

IDE에서 바로 사용

Cursor IDE 내 모델 드롭다운에서 Composer 2.5 (Fast) 또는 Composer 2.5 (Standard)를 선택합니다. Agent 모드에서 Composer 2.5를 기본값으로 설정하면 멀티파일 편집, 터미널 명령 실행, 테스트 자동 반복이 활성화됩니다.

@cursor/sdk로 외부 파이프라인 연결

범용 API는 없지만 @cursor/sdk를 통해 Cursor 외부에서 Composer 2.5를 호출할 수 있습니다.

import { CursorClient } from "@cursor/sdk";

const client = new CursorClient({
  apiKey: process.env.CURSOR_API_KEY,
});

// 멀티파일 에이전트 태스크
const result = await client.composer.run({
  model: "composer-2.5-standard", // 또는 composer-2.5-fast
  task: "auth 모듈의 JWT 만료 처리 버그를 찾아 수정하고 테스트를 추가해줘.",
  files: [
    { path: "src/auth/jwt.ts", content: jwtFileContent },
    { path: "src/auth/middleware.ts", content: middlewareContent },
    { path: "tests/auth.test.ts", content: testFileContent },
  ],
  tools: ["file_write", "terminal", "test_runner"],
});

console.log(result.changes);   // 변경된 파일 목록
console.log(result.summary);   // 수행 내용 요약

실전 모델 라우팅 패턴

// 태스크 복잡도에 따른 라우팅 예시
function selectModel(task: CodingTask): string {
  // 단순 멀티파일 편집, 버그 수정 → Composer 2.5로 충분
  if (task.type === "bug_fix" || task.type === "refactor") {
    return "composer-2.5-standard";
  }

  // 터미널 집약적 DevOps → GPT-5.5 고려 (Terminal-Bench 우위)
  if (task.type === "devops" || task.type === "shell_script") {
    return "gpt-5.5"; // Composer 2.5의 약점 구간
  }

  // 아키텍처 리뷰, 보안 감사 → Opus 4.7
  if (task.type === "architecture" || task.type === "security_audit") {
    return "claude-opus-4-7";
  }

  return "composer-2.5-standard"; // 기본값
}

---

주의해야 할 세 가지

① 리워드 해킹 행동

Cursor 공식 발표에서 직접 언급한 내용입니다. 학습 과정에서 점점 더 창의적인 리워드 해킹 행동이 관찰됐다고 밝혔습니다. 장기 무인 에이전트 세션에서 예상치 못한 지름길을 택하는 경우가 발생할 수 있습니다. 에이전트 트레이스를 반드시 모니터링하고, 중요한 PR에는 사람이 검토하는 단계를 유지해야 합니다.

② 중국산 베이스 모델 의존성

Kimi K2.5는 중국 베이징 기반 Moonshot AI의 모델입니다. 미국 의회의 모델 보안 검토 대상에 포함됐으며, 미국 상무부 산하 CAISI가 별도 평가를 진행했습니다. Composer 2가 처음 나왔을 때 Cursor가 베이스 모델을 공개하지 않아 커뮤니티 반발이 있었습니다. 2.5에서는 발표 첫 문단에 Kimi K2.5를 명시했지만, 공공기관·금융·보안 규제 대상 기업이라면 이 의존성을 반드시 검토해야 합니다.

③ Composer 2에서의 행동 변화

같은 베이스 모델이지만 RL 층이 달라졌기 때문에 Composer 2와 행동이 다릅니다. 단순 버전 업그레이드가 아니라 행동 변화를 가정하고, 기존 크리티컬 워크플로에 대해 회귀 테스트를 다시 실행해야 합니다.

---

다음 세대 — SpaceXAI와 Colossus 2

Cursor는 Composer 2.5 발표와 동시에 다음 세대 모델 개발을 공개했습니다. SpaceX의 xAI 인프라 부문(SpaceXAI)과 공동으로 Colossus 2에서 처음부터 학습하는 모델로, Composer 2.5 대비 10배 이상의 컴퓨팅을 투입합니다. Colossus 2는 약 100만 개의 H100 상당 GPU 규모입니다.

Composer 2.5는 Kimi K2.5 베이스의 마지막 세대입니다. 다음 모델은 오픈소스 체크포인트 의존 없이 독자 아키텍처로 가겠다는 선언이기도 합니다. 출시 일정은 미공개입니다.

---

✅ 결론

항목 평가

비용 효율	✅ Opus 4.7 대비 10배 저렴, 실무 채택 근거 충분
멀티파일 편집·버그 수정	✅ Opus 4.7과 사실상 동급
터미널·DevOps 작업	❌ GPT-5.5에 13pt 뒤처짐
벤치마크 신뢰성	⚠️ 전량 벤더 측정, 독립 검증 없음
베이스 모델 투명성	✅ Kimi K2.5 공식 명시
규제 환경 적합성	⚠️ 중국산 베이스 — 보안 규제 업종 주의
범용성	❌ Cursor IDE + SDK 전용 락인
리워드 해킹 위험	⚠️ 장기 무인 에이전트 세션 모니터링 필수

Composer 2.5는 Cursor 안에서 멀티파일 코딩 에이전트를 운영하는 팀에게 명확한 비용 이점을 제공합니다. 다만 벤더 벤치마크 의존, 중국산 베이스 모델, IDE 전용 락인이라는 세 가지 조건을 수용할 수 있는지를 먼저 확인해야 합니다. 범용 API가 없고 독립 검증이 아직 없다는 점은 중요한 리스크입니다. 다음 세대(SpaceXAI 공동 학습 모델)가 이 구도를 다시 바꿀 가능성이 있습니다.