Cursor AI 모델 선택: Composer 2·2.5는 언제 쓸까?

Cursor AI에서 명확하고 검토하기 쉬운 코드 변경을 시작할 때 Composer 2는 좋은 출발점입니다. 다만 Cursor가 안내하는 현재 Composer 버전은 Composer 2.5입니다. 구현 과정을 대화하며 조율하려면 Composer 계열을, 시스템이 어떻게 동작해야 할지 결정하는 일이 더 어렵다면 계획 수립 능력이 더 뛰어난 모델을 선택하면 됩니다. 기준은 수정할 파일 수보다 작업의 명확성입니다.

2026년 11월 14일 검증했습니다. Cursor의 최신 모델 문서, 출시 발표, 기술 보고서를 기준으로 작성했습니다. Composer 2는 후속 모델의 기반이 된 학습 방식을 이해하는 데 여전히 의미가 있습니다. 이 글은 문서를 바탕으로 실무적인 선택 기준을 정리한 평가이며, 직접 실행한 벤치마크는 아닙니다.

Cursor AI의 Composer 2는 어떤 일을 하나요?

Composer 2는 Cursor의 에이전트 환경에서 소프트웨어 작업을 수행하도록 학습한 코딩 모델입니다. 에이전트는 모델에 저장소 탐색, 파일 수정, 결과 확인을 위한 툴을 결합한 시스템입니다. 모델이 다음 행동을 결정하면 주변 소프트웨어가 실행하고 결과를 돌려줍니다.

모델 선택 목록에서 Composer를 볼 때 이 차이를 알아 두면 좋습니다. 별도 에디터를 열거나 자동 완성 기능으로 전환하는 것이 아니라, 에이전트의 판단을 맡길 모델을 고르는 것입니다. Cursor는 작업 공간이고, Composer는 그 안에서 사용할 수 있는 모델 중 하나입니다.

엔지니어링 작업실에 빗대어 볼 수 있습니다. 모델은 어느 연결 부위를 점검할지 판단하는 엔지니어입니다. 파일 검색, 편집, 터미널 툴은 작업 장비에 해당합니다. 테스트는 변경이 제대로 이루어졌는지 알려 주는 측정값입니다. 역량이 뛰어난 엔지니어라면 판단도 더 정확하겠지만, 명세가 빠진 상태를 엔지니어나 장비만으로 끝없이 메울 수는 없습니다.

예를 들어 기존 계정 상태 필드를 설정 화면에 추가하려면 컴포넌트, 데이터 매핑, 테스트를 수정해야 할 수 있습니다. 여러 파일에 걸친 작업이지만 원하는 동작은 분명합니다. Composer에 맡기기 적절한 일입니다. 반면 결제, 접근 제어, 마이그레이션 로직 전반에서 계정 상태의 의미를 새로 정의하는 작업은 다릅니다. 구현 전에 먼저 내려야 할 결정이 있습니다.

지금 평가할 버전은 Composer 2.5입니다

새로 도입을 검토한다면 Composer 2.5를 평가해야 합니다. Cursor는 2026년 3월 19일 Composer 2를 출시한 뒤, 2026년 5월 18일 Composer 2.5를 선보였습니다. Composer 2.5 발표에서는 작업을 오래 이어 가는 능력, 복잡한 지시를 안정적으로 따르는 능력, 협업 방식이 개선됐다고 설명합니다.

Cursor에 따르면 후속 모델은 답변 전에 얼마나 작업할지 조절하는 능력을 개선했으며, 학습 과정에 특정 문제를 겨냥한 텍스트 피드백을 도입했습니다. 최종 성공 점수에만 의존하는 대신 사용할 수 없는 툴을 고르는 식의 구체적인 실수를 교정할 수 있습니다. 실제 코드베이스를 바탕으로 기능을 삭제한 다음 테스트를 통과하도록 복원하게 하는 등 더 어려운 합성 과제도 만듭니다.

개발자에게 중요한 점은 실용성입니다. 벤치마크 점수가 크게 뛰지 않더라도 불필요한 행동이 줄고 설명이 명확해지면 모델의 활용 가치는 높아질 수 있습니다. 개발 조직의 리더라면 정확성뿐 아니라 이런 행동도 평가해야 합니다. 결과물 때문에 추가로 필요한 확인 질문, 수정, 검토 작업까지 살펴보면 됩니다.

Composer 2.5는 여전히 Composer 2와 같은 기반 체크포인트에서 출발합니다. 추가 학습을 거친 후속 모델이라는 뜻이지, 과거 Composer에 대한 모든 주장을 현재 모델에도 그대로 적용할 수 있다는 뜻은 아닙니다.

Composer 2 기술 보고서로 보는 Cursor의 학습 방식

Cursor는 기존 모델을 코딩에 특화한 뒤, 개발자가 실제로 쓰는 환경에서 작업을 완수하도록 학습시켰습니다. Cursor의 학습 개요에 따르면 코드 비중이 높은 데이터로 추가 사전학습을 진행한 다음, 배포된 툴과 에이전트 구성을 갖춘 실제적인 Cursor 세션에서 강화학습을 수행했습니다.

추가 사전학습은 기본 모델에 데이터를 더 학습시켜 코딩 지식을 강화하는 과정입니다. 강화학습은 모델이 과제를 시도하게 하고 결과의 품질에 따라 행동을 조정하는 방식입니다. 앞 단계는 지식을 늘리고, 다음 단계는 그 지식을 활용하는 행동을 개선합니다.

기술 보고서 전문에는 긴 컨텍스트 학습, 특정 목표에 맞춘 지도학습 예시, 의사소통과 툴 사용을 유도하는 보상 설계가 설명돼 있습니다. 쉬운 요청에 과도한 노력을 들이지 않도록 페널티를 주면서도 어려운 작업에는 더 많은 노력을 허용하는 방식도 다룹니다. 대화하며 작업할 수 있는 속도로 유용한 코딩 지능을 제공하려는 제품 목표가 드러나는 대목입니다.

Composer 2와 Kimi는 어떤 관계인가요?

Composer 2는 Moonshot의 Kimi K2.5 체크포인트에서 출발합니다. Cursor의 자체 모델이라고 해서 최초 기반 모델까지 Cursor가 처음부터 사전학습했다는 뜻은 아닙니다. Cursor는 이 출발점을 명시하고, 그 위에 어떤 추가 학습을 수행했는지 설명합니다.

같은 체크포인트에서 출발했다고 배포된 시스템을 서로 바꿔 써도 된다는 뜻도 아닙니다. 추가 학습은 행동을 바꾸고, 에이전트 환경은 모델이 할 수 있는 행동의 범위를 바꿉니다. 자신의 저장소에서 중요한 질문은 전체 시스템이 정확하고 검토하기 쉬운 결과를 내느냐입니다. 모델의 계보는 기술을 이해하는 데 도움이 되지만, 평가의 결론까지 대신해 주지는 않습니다.

따라서 단순히 “코드로 학습했다”는 설명만으로는 부족합니다. Composer의 특화 학습에는 툴을 고르고, 실행 결과에 대응하며, 작업을 지속하는 능력도 포함됩니다. 채팅 답변으로 그럴듯한 함수를 만드는 데 그치지 않습니다.

컨텍스트와 툴 사용에도 한계가 있습니다

현재 Composer 2.5 제품 문서에 명시된 컨텍스트 윈도는 200k 토큰입니다. 토큰은 모델이 처리하는 텍스트와 코드의 조각이며, 컨텍스트는 요청을 처리할 때 사용하는 작업 공간입니다. 현재 Composer 모델 문서에는 Agent와 Thinking 기능, 파일 검색·읽기·편집, 셸 명령과 기타 에이전트 툴에 대한 접근이 나와 있습니다.

같은 페이지에는 브라우저와 이미지 생성 툴도 소개돼 있습니다. 이는 에이전트 환경에서 제공하는 툴이지, 기반 모델이 모든 유형의 입력을 처리한다는 증거는 아닙니다. 특히 공통 파일 읽기 설명에서는 비전 기능이 있는 모델만 이미지를 읽을 수 있다는 조건을 둡니다. 공통 툴 목록만 보고 모델 자체에 비전 기능이 있다고 판단해서는 안 됩니다.

큰 저장소를 다룬다고 해서 코드베이스 전체가 작업 컨텍스트에 영구적으로 올라가는 것은 아닙니다. 관련 파일을 검색하고 읽는 일도 작업의 일부입니다. 컨텍스트가 크면 더 많은 근거를 담을 수 있지만, 필요한 근거를 잘 고르는 일은 여전히 중요합니다.

Composer 보고서는 자기 요약(self-summarization) 기법을 설명합니다. 모델이 긴 작업을 이어 가기 위해 지금까지의 작업 이력을 압축하는 방식입니다. 학습 과정에서는 최종 해결에 도움이 되는 요약에 보상을 주고, 중요한 정보를 잃는 요약에는 페널티를 줍니다. 모든 대화를 책상 위에 계속 펼쳐 놓는 것보다는 엔지니어가 인수인계 메모를 갱신하는 모습에 가깝습니다.

진짜 한계는 단순한 공간 부족보다 핵심 제약 조건의 유실입니다. 긴 리팩터링 도중 기존 API가 계속 작동해야 한다는 조건을 잊으면, 수정을 거듭할수록 문제가 더 커질 수 있습니다. 호환성 요구사항과 인수 검증 항목은 계속 참조할 수 있는 프로젝트 지침이나 작업 명세에 적어 두세요. 대화가 본래 목표에서 벗어나면 제약 조건을 다시 명시하고, 에이전트를 계속 실행하기 전에 diff를 확인해야 합니다.

Composer 2 벤치마크 점수로 알 수 있는 것은 무엇인가요?

Cursor의 결과는 이전 Composer 모델 대비 코딩 성능이 크게 개선됐음을 뒷받침합니다. 모든 최상위 모델을 언제나 앞선다는 뜻은 아닙니다. Composer 2 출시 발표에서 제시한 점수는 CursorBench 61.3, Terminal-Bench 2.0 61.7, SWE-bench Multilingual 73.7입니다. 이 수치는 Cursor의 측정값이며, 이 글에서 독립적으로 측정한 결과가 아닙니다.

CursorBench는 Cursor 엔지니어들의 코딩 세션을 바탕으로 구성됐습니다. Terminal-Bench는 터미널 환경의 에이전트 작업을, SWE-bench Multilingual은 여러 언어로 된 저장소의 이슈 해결을 평가합니다. 과제, 채점 방식, 에이전트 구성이 각각 다릅니다. 이 점수를 다음 마이그레이션의 성공 확률로 바꿔 해석할 수는 없습니다.

출시 발표에서는 비교 대상마다 모델 주변의 소프트웨어, 즉 에이전트 구성이 다를 수 있다고도 설명합니다. 이는 중요한 제약입니다. 툴과 실행 방식이 다르면 모델 자체의 점수와 전체 에이전트의 점수를 명확히 분리하기 어렵습니다.

Composer 2.5 벤치마크와는 구분해야 합니다

Composer 2의 공개 점수를 Composer 2.5의 점수로 볼 수는 없습니다. Cursor는 후속 모델 발표에서 지능과 행동이 개선됐다고 설명하며 별도의 평가 자료를 제공합니다. 지금 모델을 선택하려면 이 근거를 이전 버전의 수치와 구분해서 봐야 합니다.

가장 유용한 평가는 통과 조건이 정해진 대표적인 저장소 작업입니다. 다른 곳에서 점수가 높더라도 결과물의 의도를 다시 추적해야 하는 모델보다는, 이해하기 쉬운 테스트와 깔끔한 수정안을 내놓는 모델이 더 가치 있습니다. 이는 평가 방법에 대한 권고이며, 이 글에서 해당 평가를 직접 실행했다는 뜻은 아닙니다.

Composer 2와 Composer 2 Fast는 무엇이 다른가요?

Cursor에 따르면 Fast는 더 똑똑한 모델이 아니라 응답 제공 속도에 관한 선택입니다. Composer 2 발표와 현재 Composer 문서는 모두 빠른 변형 모델의 지능이 동일하다고 설명합니다. 상호작용 사이의 대기 시간이 문제일 때 선택하면 됩니다. 응답이 빠르다는 이유만으로 부족한 추론 능력까지 해결될 것으로 기대해서는 안 됩니다.

당시 속도 비교에는 2026년 3월 18일 Cursor 트래픽의 스냅샷을 사용했습니다. Cursor는 제공업체의 처리 여력과 시간에 따라 속도가 달라진다고 밝힙니다. 출시 당시의 초당 토큰 수를 지금 세션의 속도 보장으로 받아들이기 어려운 이유입니다.

출시 당시 Fast가 기본이라는 안내에도 현재 제품에서는 예외가 있습니다. Plus에서는 Fast가 꺼진 상태로 고정됩니다. 계정 설정을 확인할 때는 과거 발표보다 Cursor의 현재 모델 및 요금제 안내를 우선해야 합니다. 유료 요금제에서는 포함된 Cursor 모델 사용량에서 Composer 사용량이 차감됩니다. Claude와 GPT 접근은 이용 가능한 요금제와 별도 사용 규칙에 따라 달라집니다.

현재 계정과 레거시 계정의 차이를 포함한 전반적인 접근 권한 변경은 10월 변경 이후의 Cursor 모델에서 확인할 수 있습니다. 여기서 할 일은 모든 Composer 세션이 같다고 가정하기 전에 선택한 변형 모델과 계정에서 제공하는 설정을 확인하는 것입니다.

Composer, Claude, GPT는 언제 선택해야 하나요?

수정할 내용이 명확하면 Composer를, 불확실성을 해소하는 일이 더 크다면 계획 수립 능력이 뛰어난 모델을 선택합니다. Cursor의 모델 선택 가이드도 같은 방향을 제시합니다. Composer는 대화형 코딩용으로, 복잡한 다단계 작업에는 Anthropic Claude Opus와 OpenAI GPT-5.6 Sol을 권장합니다.

여러 파일을 빠르게 수정한다면 Composer부터 시작합니다

API가 이미 반환하는 필드를 화면에 표시하면서 기존 검증 로직을 유지하고 관련 테스트를 갱신해야 한다고 가정해 보겠습니다. 어떤 동작을 바꾸고, 어떤 동작은 유지하며, 완료 여부를 어떻게 확인할지 Composer에 알려 주세요. 파일 이름을 모두 추측해서 지정하기보다는 영향받는 파일을 직접 찾게 하면 됩니다.

장점은 짧은 피드백 주기입니다. 제안된 변경을 확인하고, 잘못된 가정을 바로잡은 뒤, 작업을 이어 갈 수 있습니다. 여러 파일을 건드리는 작업이라도 아키텍처가 불명확한 것은 아닐 수 있습니다. 모델 선택 기준으로는 파일 수보다 아직 해결되지 않은 의사결정이 더 적절합니다.

같은 실패가 반복되면 프롬프트만 계속 강화하지 마세요. 요구사항은 명확한데 모델이 의존 관계를 자꾸 놓친다면 재현 방법과 현재 diff를 다른 모델에 전달하세요. 요구사항이 불분명하다면 모델을 바꾸기 전에 먼저 명확히 해야 합니다.

어려운 아키텍처 변경은 Claude Opus나 GPT로 계획합니다

여러 곳에 흩어진 계정 권한 검사를 공통 인가 계층으로 옮겨야 한다고 가정해 보겠습니다. 위험한 부분은 헬퍼 함수를 작성하는 일이 아닙니다. 각 서비스가 어떤 신원 정보를 신뢰하는지 파악하고, 마이그레이션 중 기존 동작을 보존하며, 롤백 방법을 결정하는 일이 더 중요합니다.

수정을 시작하기 전에 계획 수립 능력이 더 뛰어난 모델로 의존 관계를 정리하고 마이그레이션 설계를 검토하세요. Cursor의 Claude Opus 5.5 문서는 기본 컨텍스트 300k, 최대 1M을 명시하고, high-thinking 변형 모델을 권장합니다. 많은 근거를 한꺼번에 비교해야 할 때 이 모델을 고려할 만한 문서상 용량 근거입니다. Cursor는 복잡한 다단계 작업에 GPT-5.6 Sol도 제시합니다.

이런 모델을 권장하는 상황은 불확실성의 비용이 크거나, 의존 관계가 길게 이어지거나, 설계 검토가 필요한 경우입니다. 어떤 저장소 작업에서도 항상 더 낫다는 뜻은 아닙니다. 계획이 정해지면 범위가 한정된 구현 작업에 Composer를 다시 평가해 볼 수 있습니다.

Cursor 안에서 Claude 모델을 선택하는 것과 Claude Code 제품을 선택하는 것은 별개입니다. 작업 방식 자체를 고르는 문제는 Claude Code와 Cursor 비교에서 다룹니다. 지금 쓰는 에디터 안에서 판단을 맡길 모델을 바꾸기 위해 에디터까지 바꿀 필요는 없습니다.

과장해서 받아들이기 쉬운 점: 빠른 출력이 곧 작업 완료는 아닙니다

속도, 긴 컨텍스트, 벤치마크 우위를 변경 사항을 바로 병합해도 된다는 근거로 삼으면 오해가 생깁니다. Cursor도 이 모델이 어려운 작업을 위해 학습됐다고 설명합니다. 그렇더라도 자신의 구체적인 요구사항이 충족됐는지 확인하는 과정은 필요합니다.

명세에 빠뜨린 동작이 잘못돼 있어도 테스트는 통과할 수 있습니다. 긴 컨텍스트에 호환성 요구사항이 들어 있어도 에이전트가 이를 일관되게 적용하지 않을 수 있습니다. 자신감 있는 요약에서 실패한 명령이 빠질 수도 있습니다. 마지막 설명만 읽지 말고 실제 변경 내용과 근거를 검토해야 합니다.

실무의 병목은 코드 작성에서 의사결정 검토로 옮겨 가는 경우가 많습니다. 혼자 개발한다면 결과 diff를 직접 설명할 수 있을 만큼 작업 범위를 좁게 잡으세요. 개발 조직의 리더라면 완료된 작업에 포함할 근거를 정해야 합니다. 영향받는 동작, 실행한 테스트, 해결되지 않은 실패, 사람이 결정해야 할 가정이 여기에 해당합니다.

다음 업무부터 어떻게 적용하면 좋을까요?

개발자는 지금 현재 Composer로 범위가 한정된 티켓을 처리해 보고, 리더는 실제 저장소에서 근거를 확보한 뒤 팀 전체의 표준으로 삼는 편이 좋습니다. 대표적인 작업에서 바꿀 만한 구체적인 이유가 확인되기 전까지는 잘 돌아가는 구성을 유지하세요.

1. 1

   선택한 모델을 확인합니다

   Cursor의 채팅 또는 에이전트 패널에서 모델 선택기를 여세요. 현재 Composer 항목을 선택했는지 확인하고 사용할 수 있는 속도 설정도 살펴보세요. 선택은 대화가 바뀌어도 유지되므로 새 채팅을 열면 초기화된다고 가정해서는 안 됩니다.

2. 2

   작업의 완료 조건을 정합니다

   내용이 명확한 백로그 항목을 고르세요. 기대하는 동작, 호환성을 유지해야 하는 부분, 성공 여부를 입증할 검증 항목을 설명합니다. 실행하지 못한 검증이 있다면 에이전트가 보고하도록 요청하세요.

3. 3

   불확실한 문제는 계획 단계로 넘깁니다

   작업 중 아직 결정되지 않은 설계 문제가 드러나면 구현을 멈추고 적절한 계획 수립 모델과 함께 검토하세요. 막연히 더 잘해 보라고 지시하기보다는 재현 방법, 제약 조건, diff를 전달해야 합니다.

4. 4

   최종 변경 사항을 평가합니다

   diff와 테스트 근거를 검토하세요. 감당할 만한 수정으로 수용 가능한 결과가 나오는 작업에서는 Composer를 기본으로 유지하면 됩니다. 설계 문제나 반복되는 실패로 다른 접근이 필요한 작업을 위해 모델을 전환할 경로도 마련하세요.

자주 묻는 질문

Cursor의 Composer는 무엇인가요?

모델 선택기에 있는 Composer는 Cursor의 자체 코딩 모델 계열입니다. Cursor 안에서 에이전트 작업을 이끕니다. 현재 문서에 명시된 Composer 버전은 Composer 2.5입니다.

Composer 버전은 어떻게 확인하나요?

채팅 또는 에이전트 패널에 표시된 선택 모델의 이름을 읽고 현재 모델 문서와 비교하세요. Auto는 라우팅 방식이며 턴마다 다른 모델을 사용할 수 있으므로, Auto를 선택했다는 사실만으로 Composer를 쓰고 있다고 볼 수는 없습니다.

Composer 2.5는 코딩에 적합한가요?

Cursor는 대화형 코딩을 위해 설계했으며 작업을 지속하는 능력을 개선했다고 설명합니다. 성공 여부를 확인할 수 있는 과제부터 시작하세요. 아키텍처 변경이 모호하다면 구현을 평가하기 전에 설계부터 확정해야 합니다.

Composer는 무엇이고 왜 사용하나요?

이 글에서 Composer는 Cursor의 코딩 모델을 뜻합니다. 에이전트의 툴로 저장소 작업을 수행하기 위해 선택하며, 특히 구현 방향을 대화하며 조율하고 싶을 때 사용합니다.

Composer는 어떻게 사용하나요?

Cursor의 에이전트 패널에서 현재 Composer 모델을 선택하고, 원하는 변경과 인수 검증 항목을 전달하세요. 작업을 수락하기 전에 수정 내용과 툴 실행 결과를 확인해야 합니다.

Composer 소프트웨어는 어디에 쓰나요?

Cursor의 Composer는 소프트웨어 엔지니어링에 사용합니다. 작업을 이해하고, 파일을 살펴보고, 변경을 적용한 뒤 에이전트 툴로 결과를 확인합니다. 이름이 같은 다른 소프트웨어는 이 가이드의 범위에 포함되지 않습니다.

Composer는 어떤 원리로 작동하나요?

모델이 행동을 고르면 툴이 실행하고, 그 결과가 다음 행동의 근거가 됩니다. Cursor는 이에 맞는 에이전트 환경의 코딩 과제로 Composer를 학습시켰으며, 긴 작업을 이어 갈 수 있도록 자기 요약도 학습시켰습니다.

무료로 쓸 수 있는 Composer 앱이 있나요?

Cursor의 코딩 모델을 뜻한다면, Cursor의 Free 요금제는 자체 모델을 사용하는 Agent와 Chat 기능을 제한적으로 제공합니다. Composer를 무제한으로 사용할 수 있다는 뜻은 아닙니다. 이 가이드는 작곡 앱을 비교하지 않습니다.

composer install은 무엇에 쓰나요?

설치 명령어를 찾는 것과 Cursor의 코딩 모델을 고르는 것은 별개의 문제입니다. 여기서 다루는 모델은 Cursor의 모델 선택기에서 고르면 됩니다. 이 가이드는 설치 명령어 참고 문서가 아닙니다.

코딩 모델과 맡길 작업에 대한 실용적인 가이드는 뉴스레터 구독으로 받아 보세요.