코딩 에이전트 전쟁이 "더 똑똑한가?"에서 "같이 일할 만큼 싸고 빠른가?"로 옮겨가고 있습니다. Cursor가 새 모델 Composer 2를 공개하며, OpenAI·Anthropic급 코딩 모델과 비슷한 체감 성능을 훨씬 낮은 비용으로 맞추겠다고 선언한 게 이번 뉴스의 핵심입니다.1
도입부만 요약하면 이렇습니다. Composer 2는 코드 작업에 특화된(in code-only) 자체 모델이고, 벤치마크 점수는 크게 끌어올렸으며, 가격은 공격적으로 낮췄습니다. 그리고 이 조합이 "에이전트 모드"를 자주 쓰는 개발자에게 직접적인 체감 차이를 만든다는 점이 포인트입니다.
Composer 2 가격: "토큰 요금"이 체감 생산성을 바꾼다
Cursor가 내세우는 한 문장은 간단합니다. "비슷한 지능을 더 싸게." Composer 2의 요금은 입력 100만 토큰당 $0.50, 출력 100만 토큰당 $2.50입니다.2 같은 지능을 유지하면서 더 빠른 Composer 2 Fast도 제공하는데, 이쪽은 $1.50/$7.50로 3배 수준입니다.2
왜 이게 중요할까요? 코딩 에이전트는 보통 한 번에 끝내지 않습니다. 파일 여러 개 읽고, 수정하고, 터미널 돌리고, 에러 나면 다시 고치고... 이 과정에서 출력 토큰이 특히 빠르게 늘어납니다. 즉 "모델이 조금 더 똑똑하냐"보다 "여러 번 시켜도 지갑이 안 아프냐"가 실전에서 더 크게 느껴집니다.
경쟁 모델과 단순 비교를 해보면, Claude Opus 4.6는 $5/$25, GPT-5.4는 $2.5/$15 수준으로 알려져 있습니다.3 Cursor가 '대항마' 프레임을 잡는 이유가 여기에 있습니다.
코딩 벤치마크 성적표: Opus 4.6은 넘고, GPT-5.4는 추격
가격만 싸면 "싼 게 비지떡"이 되기 쉬운데, Cursor는 점수로 반박합니다. Cursor가 공개한 수치에서 Composer 2는 Terminal-Bench 2.0 61.7, SWE-bench Multilingual 73.7, CursorBench 61.3을 기록했습니다.2
여기서 눈여겨볼 대목은 "상승폭"입니다. Composer 1.5에서 Composer 2로 오면서 Terminal-Bench 2.0이 47.9 → 61.7로 크게 뛰었습니다.2 Terminal 작업은 에이전트 코딩의 현장감(실행·디버깅·환경 수정)을 대표하는데, 이 점수가 오른 건 "그럴듯한 코드"보다 "끝까지 마무리하는 능력"을 더 의식했다는 신호로 읽힙니다.
다만 Cursor도 모든 1등을 주장하진 않습니다. 공개 수치 기준 GPT-5.4의 Terminal-Bench 2.0은 75.1로 더 높습니다.4 현실적인 결론은 이겁니다. Composer 2는 "최강"이라기보다, 일상 업무를 커버할 만큼 충분히 강해졌는데 비용이 확 내려간 모델에 가깝습니다.
'롱 호라이즌(장기 작업)'이 진짜 무기: 자기 요약으로 안 잊어버리기
에이전트 코딩이 어려운 이유는 똑똑함보다 기억력입니다. 작업이 길어질수록 대화·로그·수정 내역이 쌓이고, 모델은 문맥 한계에 부딪혀 "아까 고친 걸 다시 고치거나" "중요한 요구사항을 잊는" 순간이 옵니다.
Composer 2가 강조하는 개선점은 이 긴 작업을 버티는 훈련입니다. Cursor는 지속 사전학습(continued pretraining)로 기반 체력을 올린 뒤, 강화학습을 장기 코딩 작업에 맞춰 확장했다고 설명합니다.2 여기에 더해 'self-summarization(자기 요약)'을 훈련 루프에 넣어, 문맥이 길어질 때 모델이 스스로 중요한 정보만 압축해 들고 가게 만든 접근도 공개됐습니다.5 요약하자면, "기억을 외주(별도 요약기) 주는" 게 아니라 모델이 기억 압축을 직업 능력으로 배우게 한 셈입니다.
이런 접근은 특히 리팩터링, 마이그레이션, 테스트 실패 반복 수정처럼 "몇 십~몇 백 번의 액션"이 필요한 작업에서 효율이 납니다. 결국 개발자가 원하는 건 화려한 한 방이 아니라, 끝까지 같이 달리는 러너니까요.
시사점: Cursor를 쓰는 사람에게 Composer 2는 '기본값'이 될까?
Composer 2의 의미를 한 줄로 정리하면 "IDE가 모델 업체와 정면승부를 시작했다"입니다.1 Cursor는 여전히 여러 모델을 붙여 쓸 수 있는 '모델 선택형' 전략을 유지하지만, 자체 모델이 강해질수록 기본값이 자사 쪽으로 기울 가능성이 큽니다.
실용적으로는 이렇게 가져가면 좋습니다. 일상적인 기능 추가·버그 수정·중간 규모 리팩터링은 Composer 2(혹은 Fast)를 기본으로 두고, 초대형 코드베이스 분석이나 최고 수준의 터미널 수행 능력이 필요할 때만 GPT/Claude 같은 상위 모델을 스위치하는 방식이 비용 대비 효율이 좋습니다. 특히 에이전트 모드를 자주 켜는 팀이라면, "우리 작업은 출력 토큰이 얼마나 나가나"를 한 달만 측정해도 어떤 모델이 기본이어야 하는지 감이 잡힙니다.
결국 2026년의 코딩 AI 선택 기준은 하나로 수렴합니다. 성능이 아니라 '성능×속도×비용'의 곱입니다. Composer 2는 그 곱셈에서 꽤 강한 답안을 들고 온 모델입니다.
참고
3Cursor's Composer 2 beats Opus 4.6 on coding benchmarks at a fraction of the price
4Cursor's new coding model Composer 2 is here: It beats Claude Opus 4.6 but still trails GPT-5.4
5Cursor's Composer 2 beats Opus 4.6 on coding benchmarks at a fraction of the price
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.