Composer 모델 시작하기

Composer는 Cursor 자체의 최전선 에이전트 코딩 모델로, 사내에서 학습되었으며 한 가지에 최적화되어 있습니다: 실제 코딩 작업을 빠르게 완수하는 것입니다. 계획을 세우고, 여러 파일을 편집하고, 터미널 명령을 실행하며, 대형 최전선 모델의 일부 비용으로 비정상적으로 낮은 지연 시간으로 도구를 반복 실행합니다. 이 가이드는 Composer가 무엇인지, 선택하는 방법, 어디서 빛을 발하는지, 여전히 Claude 또는 GPT 계열 모델을 사용해야 하는 곳, 그리고 일상 작업에서 최대한 활용하는 방법을 설명합니다.

Composer 모델이란 무엇인가요?

Composer는 제3자로부터 라이선스가 아니라 Cursor 팀이 직접 구축한 사용자 정의 모델 제품군입니다. 코드베이스를 읽고, 계획을 세우고, 도구를 호출하고, 파일 전반에 걸쳐 편집을 적용하고, 결과를 검증하는 에이전트 코딩을 위해 특별히 학습되었습니다. 코딩에 맞게 조정된 범용 채팅 모델과 달리, Composer는 처음부터 에이전트 루프에 최적화되었습니다.

모델 라인의 설계 목표는 다음과 같습니다:

• 낮은 지연 시간: 응답이 빠르게 시작되고 도구 호출이 긴 공백 없이 실행되므로 편집-테스트 루프가 즉각적으로 느껴집니다.
• 에이전트 효율성: 모델은 각 단계를 미세 관리하도록 요구하는 대신 도구 호출을 합리적으로 연결하도록 조정되었습니다.
• 가격 효율성: Composer는 최상위 최전선 모델보다 요청당 상당히 저렴하며, 이는 긴 에이전트 세션에서 중요합니다.
• 실용적 추론: 확장 사고 모델보다 훨씬 빠르면서도 다단계 변경을 계획할 만큼 충분히 강력합니다.

편집기에서 다른 모델처럼 동작합니다: 모델 선택기에서 선택하면 Chat, Agent 모드, 인라인 편집 및 백그라운드 에이전트를 지원합니다. 차이는 처리량에서 느껴집니다. 최전선 모델이 1분간 사고하는 작업이 Composer로는 종종 몇 초 만에 완료되며, 대다수의 일상적인 코딩 작업에서 품질이 잘 유지됩니다.

Composer는 2024년 Composer 기능이 아닙니다

Composer 모델을 2024년에 Cursor가 출시한 레거시 "Composer" 다중 파일 편집 기능과 혼동하지 마세요. 그 초기 도구는 여러 파일에 걸쳐 변경을 적용하기 위한 UI 워크플로였고, 나중에 지금의 Agent 모드로 통합되었습니다. 이 가이드에서 논의하는 Composer는 Claude 및 GPT와 같은 선택기에서 선택하는 모델 자체입니다. Composer를 별도의 패널이나 키보드 단축키로 취급하는 오래된 튜토리얼을 읽는다면, 그것은 이 모델이 아니라 폐기된 기능을 설명하는 것입니다.

Composer가 제3자 모델과 다른 점

Claude, GPT, Gemini 모델은 Cursor가 네트워크를 통해 라우팅하는 범용 최전선 모델입니다. Composer는 다른 종류입니다: Cursor가 에이전트 루프를 위해 특별히 구축한 모델입니다. 정확한 내부 구조는 공개되지 않았더라도 그 차이는 동작에서 드러납니다.

기반 모델 계보 vs 라우팅된 최전선 모델

Cursor에서 제3자 모델을 선택하면, 매우 광범위한 분포로 학습된 다음 Cursor의 에이전트 하네스로 감싸진 대형 범용 모델을 호출하는 것입니다. Composer를 선택하면, 처음부터 코드베이스 탐색, 도구 사용 및 빠른 반복을 중심으로 설계 목표가 형성된 모델을 호출하는 것입니다. 실제로 이는 다음을 의미합니다:

• 제3자 모델은 막대한 폭과 깊은 추론을 제공하지만 지연 시간과 요청당 가격을 대가로 치릅니다.
• Composer는 속도와 낮은 비용을 제공하며, 일반 추론 벤치마크보다 코딩 작업의 구체적인 형태에 맞게 조정되었습니다.
• 어느 쪽이든 하네스가 중요합니다. Cursor의 도구(파일 읽기, 편집, 터미널, 검색)는 둘 모두 앞에 놓이므로, 비교는 실제로 그 하네스 내에서의 모델 동작에 관한 것입니다.

속도 vs 깊이 트레이드오프

"좋음"과 "나쁨"의 이분법이 아니라 깊이와 처리량 사이의 다이얼로 생각하세요:

• 깊이 편향 모델은 내부적으로 계획과 추론에 더 많은 시간을 쓰며, 이는 모호하고 광범위한 문제에서 이득이 됩니다.
• Composer와 같은 처리량 편향 모델은 더 일찍 행동하고, 속도가 시사하는 것보다 덜 추측하며, 범위가 잘 정해진 작업에서 빠르게 수렴합니다.
• 대부분의 실제 작업은 혼합입니다. 처리량 편향 쪽을 기본으로 하고 작업이 깊이를 필요로 하는 것으로 드러나면 에스컬레이션하세요.

예시 지연 시간 수치

트레이드오프를 구체화하기 위해 대략적인 예시 수치를 제시합니다. 지연 시간은 작업 크기, 컨텍스트 길이 및 부하에 크게 의존하므로 측정된 벤치마크가 아닌 대략적인 어림값으로 간주하세요.

시나리오	Composer (대략)	최전선 모델 (대략)
첫 의미 있는 토큰	1초 훨씬 이하	1초 이상
짧은 단일 파일 편집	몇 초	10~30초
다중 파일, 도구 집약적 작업	수십 초	1분~수 분

수치는 방향성일 뿐, 계약이 아닙니다

위 수치는 차이의 형태를 전달하기 위해서만 존재합니다: Composer는 일관되게 더 빠르고, 도구 집약적 루프에서 격차가 벌어집니다. 이를 확정 수치로 인용하지 마세요. 정밀도가 중요하면 자체 워크로드에서 측정하세요.

모델 선택기에서 Composer 선택하기

Composer는 모델을 선택할 수 있는 모든 곳에서 사용 가능합니다: Chat, Agent 모드, 그리고 Agent 내부의 Composer 스타일 인라인 워크플로입니다. 전환하려면:

1. 평소의 패널 단축키로 Chat 또는 Agent 모드를 엽니다.
2. 입력 상자 옆의 모델 선택기를 클릭합니다.
3. 모델 목록에서 Composer를 찾습니다. Cursor의 자체 모델은 제3자 모델과 별도로 그룹화됩니다.
4. Composer 항목을 선택하고 평소처럼 프롬프트를 보냅니다.

Settings > Models에서 Composer를 기본 모델로 설정할 수도 있어 모든 새 채팅이 Composer로 시작됩니다. 많은 개발자는 Composer를 기본으로 유지하고 작업이 진정으로 더 깊은 추론을 필요로 할 때만 수동으로 더 무거운 모델로 전환합니다.

Composer는 백그라운드 에이전트의 모델 목록에도 나타나므로, 지연 시간을 직접 지켜보지는 않지만 비용과 총 소요 시간은 신경 쓰는 원격 작업에 자연스러운 선택입니다.

Composer를 사용할 수 있는 곳

표면	Composer 사용 방법	일반적인 비용 모델
Chat	모델 선택기에서 선택	요청당, 플랜에 대해 과금
Agent 모드	동일한 선택기, 다단계 작업에 사용	요청당
Cmd-K / 인라인 편집	빠른 단일 지점 편집에 사용 가능	요청당
백그라운드 에이전트	작업 시작 시 Composer 선택	요청당, 긴 세션은 더 많은 비용
Tab 완성	선택기 선택이 아님, Tab은 자체 모델 사용	모델 요청과 다르게 과금

요청당 vs 토큰당 비용

Cursor의 플랜 사용량은 일반적으로 순전히 토큰당이 아니라 요청당으로 과금되므로, Composer처럼 요청당 저렴한 모델은 원시 토큰 가격만으로 시사하는 것보다 플랜을 훨씬 더 오래 늘려줍니다. 두 가지 실질적 함의:

• 많은 도구 호출을 연결하는 긴 세션에서 Composer의 이점이 가장 큽니다. 각 추가 단계가 비교적 저렴하기 때문입니다.
• 원시 API 용어로 토큰 비용을 생각하는 데 익숙하다면, Cursor는 사용량을 플랜 소비로 표시하므로 보는 숫자는 플랜 미터이지 달러 금액이 아님을 기억하세요.

강점과 트레이드오프

모든 것을 이기는 단일 모델은 없습니다. Composer가 일반적으로 번갈아 사용하게 될 최전선 모델과 어떻게 비교되는지 살펴봅니다.

기능	Composer	Claude 계열 모델	GPT 계열 모델
응답 지연 시간	매우 빠름	보통~느림	보통
요청당 비용	낮음	높음	높음~보통
다중 파일 편집	강력함, 이를 위해 특별 제작	탁월함	매우 좋음
터미널 명령 유창성	강력함	탁월함	매우 좋음
깊은 아키텍처 추론	좋음	탁월함	탁월함
길고 모호한 리팩터링	명확한 지침이 있으면 좋음	최고	매우 좋음
빠른 반복 루프	최고	보통	보통

패턴은 명확합니다: Composer는 약간의 최고 추론 깊이를 속도와 비용의 큰 이득과 맞바꿉니다. 일상 작업의 상당 부분, 예를 들어 명세가 잘 된 컴포넌트 구현, 실패하는 테스트 수정, 마이그레이션 스크립트 작성, 인터페이스가 명확한 모듈 리팩터링에서 Composer는 최전선 모델이 계획을 마치기도 전에 작업을 끝냅니다.

Composer와 더 큰 모델 중 선택하기

실용적인 경험 법칙은 Composer를 기본으로 하고 작업이 더 깊은 추론을 필요로 하는 징후를 보일 때 에스컬레이션하는 것입니다. 다음 경우에 Composer를 선택하세요:

• 작업이 잘 명세되어 있을 때: 파일, 따를 패턴, 완료 정의를 알고 있을 때.
• 빠르게 반복하며 여러 차례의 작은 편집을 예상할 때.
• 일상적인 유지보수를 수행할 때: 의존성 업그레이드, 이름 변경, 포매팅 중심 리팩터링.
• 비용이 빠르게 누적되는 독립적인 작은 작업을 다수 배치 처리할 때.

Claude 또는 GPT 계열 모델을 사용하세요:

• 문제가 모호하고 모델이 방대한 코드베이스에서 의도를 추론해야 할 때.
• 클라이언트, 서버, 스키마 계층에 걸친 프로토콜 변경처럼 많은 상호 의존 모듈에 걸쳐 지속적인 추론이 필요할 때.
• 잘못된 추측이 비용이 큰 미묘한 동시성, 메모리 또는 정확성 문제를 디버깅할 때.
• 첫 계획의 품질이 첫 응답의 속도보다 중요한 아키텍처 수준 설계를 할 때.

재시작 대신 작업 중간에 에스컬레이션하세요

Composer로 작업을 시작했는데 수렴하지 않고 맴도는 것을 발견하면, 새 채팅을 시작하는 대신 다음 턴에 모델을 전환하세요. 기존 컨텍스트, 열린 파일, 지금까지의 계획이 그대로 유지되고, 더 강력한 모델이 빠른 모델이 멈춘 곳에서 이어받을 수 있습니다.

작고 빠른 모델을 위한 프롬프트 팁

빠른 모델은 정밀함에 보답합니다. Composer는 프롬프트가 추측을 제거할 때 눈에 띄게 더 잘 반응합니다. 하지 않아도 되는 모든 추측이 지연 시간과 토큰을 절약하기 때문입니다.

다음 습관을 따르세요:

• 파일과 디렉터리를 미리 명시하세요. 빠른 모델은 덜 광범위하게 계획하므로, 즉시 올바른 범위를 가리키면 궤도에 머물게 됩니다.
• 완료 정의를 명시하세요. 어떤 테스트가 통과해야 하는지, 어떤 명령을 실행해야 하는지, 어떤 동작이 바뀌어야 하는지 말하세요.
• 프롬프트당 하나의 목표. 다중 목표 요청을 순차 프롬프트로 나누세요. 에이전트 루프는 하나의 광범위한 목표보다 작은 목표의 연쇄를 훨씬 잘 처리합니다.
• 기존 패턴에 고정하세요. 원하는 패턴을 이미 구현한 파일을 참조하고 모델에게 그것을 따르라고 요청하세요.
• 영향 범위를 제한하세요. 예를 들어 "UserService의 public API를 수정하지 마세요"처럼 건드리지 말아야 할 것을 명시적으로 말하세요.

Composer를 위한 잘 구성된 프롬프트는 다음과 같습니다:

In src/services/, add retry logic to the StripeClient class.
Follow the existing retry pattern in src/services/GithubClient.ts
(exponential backoff, max 3 attempts, logs via the shared logger).

Requirements:
- Only src/services/StripeClient.ts and its test file may change.
- Add unit tests mirroring GithubClient.test.ts.
- `npm test -- stripe` must pass when you are done.

Do not modify the public constructor signature.

"add retries to the Stripe client"와 같은 모호한 프롬프트와 비교해 보세요. 둘 다 결국 작동하지만, 첫 번째 버전은 보통 한 번에 성공하며, 그것이 바로 속도에 최적화된 모델의 용도입니다.

빠른 모델을 위한 프롬프트 최적화

위 습관은 기본을 다룹니다. 이 섹션은 빠른 모델의 작업을 형성하여 첫 시도에서 성공하도록 하는 방법을 더 깊이 다룹니다.

Do와 Do Not

Do	Do Not
정확한 파일과 디렉터리 명시	전체 저장소에서 "X가 어디 있는지 찾기"를 모델에 요청
완료 정의 명시	성공 기준을 암시적으로 남기기
프롬프트당 하나의 목표 제공	관련 없는 여러 목표를 하나의 프롬프트에 묶기
복사할 기존 패턴 지목	완전히 새로운 패턴을 산문으로만 설명
변경하면 안 되는 것 나열	모델이 영향 범위를 추론할 것이라 가정
검증 단계 요청	테스트를 건너뛰고 diff를 눈으로 신뢰

좋은 프롬프트 vs 나쁜 프롬프트

확산된 프롬프트는 확산된 편집을 만들어내는 경향이 있습니다:

Clean up the auth code and make it better.

범위가 정해진 프롬프트는 빠른 모델이 한 번에 성공하는 데 필요한 모든 것을 제공합니다:

In src/auth/session.ts, extract the token-refresh logic into a
private method refreshToken() and call it from getSession().

Constraints:
- Only src/auth/session.ts and src/auth/session.test.ts may change.
- Keep the public exports of the module identical.
- Mirror the structure of src/auth/oauth.ts, which already does this.
- `npm test -- auth` must pass.

Report the test output when done.

차이는 예의나 길이가 아니라 모델이 스스로 내려야 하는 결정의 수입니다. 결정이 적으면 잘못된 방향이 적고, 속도에 최적화된 모델에게는 낭비되는 초가 적습니다.

작업을 작은 단계로 범위 정하기

더 큰 목표를 짧은 순서로 나누고 에이전트 루프가 각 단계를 수행하게 하세요:

1. 계획: 서면 계획을 요청하고 편집 전에 확인합니다.
2. 구현: 프롬프트당 하나의 파일 또는 하나의 모듈.
3. 검증: 각 단계 후 관련 테스트나 명령을 실행합니다.
4. 계속: 이전 단계가 성공한 후에만 다음 단계로 이동합니다.

명시적인 파일 참조 제공하기

설명보다 경로와 심볼을 선호하세요. "src/billing/Invoice.ts를 업데이트하세요"가 "invoice 코드를 업데이트하세요"보다 낫습니다. 가능하면 따를 정확한 함수 이름이나 짧은 스니펫을 붙여넣으세요. 그러면 모델이 검색에 쓰는 시간을 줄이고 편집에 더 많은 시간을 씁니다.

검증 요청하기

빠른 모델은 검증을 명시적으로 만들 때 가장 큰 이득을 얻습니다. 프롬프트를 "npm test -- <scope>를 실행하고 출력을 붙여넣으세요" 또는 "실행한 정확한 명령을 보고하세요"와 같은 줄로 끝내세요. 이렇게 하면 에이전트의 속도가 검증되지 않은 움직임이 아니라 신뢰할 수 있는 진행으로 바뀝니다.

규칙에 팀 관례 인코딩하기

Composer는 속도를 위해 최적화되므로, 모든 것을 추론하는 느린 모델보다 가드레일에 더 의존합니다. 관례를 .cursor/rules에 두는 것은 빠른 모델에서 불균형적으로 이득이 됩니다. 간결한 규칙 파일:

---
description: Service layer conventions for fast model edits
globs:
  - "src/services/**/*.ts"
alwaysApply: false
---

- Follow the client class pattern in src/services/GithubClient.ts.
- All network calls use the shared http client; never import axios directly.
- Every public method needs a unit test in the matching .test.ts file.
- Prefer early returns; keep methods under 40 lines.
- After edits, run `npm test -- <affected-scope>` and report results.

이런 규칙이 있으면 Composer에 짧은 프롬프트를 던지고 반복적인 표준이 매번 다시 언급하지 않아도 강제된다고 신뢰할 수 있습니다.

백그라운드 에이전트에서 Composer 사용하기

백그라운드 에이전트는 다른 일을 하는 동안 저장소에 대해 Cursor의 에이전트를 원격으로 실행하고, diff나 풀 리퀘스트로 보고합니다. Composer는 두 가지 이유로 종종 최선의 기본값입니다:

1. 비용 효율성. 백그라운드 작업은 더 길고 탐색적인 경향이 있으며 토큰 비용이 세션 전체에 누적됩니다. 요청당 저렴한 모델은 백그라운드 에이전트 집합을 저렴하게 유지합니다.
2. 처리량. 여러 병렬 백그라운드 에이전트를 펼치면 각각이 몇 분 더 일찍 끝나는 것이 훨씬 더 민첩한 전체 워크플로로 복리 효과를 냅니다.

Composer에 좋은 백그라운드 작업으로는 모듈에 대한 누락된 테스트 작성, 패키지 전반에 기계적 리팩터링 적용, 문서 스텁 생성, 트래커에서 가져온 간단한 이슈 수정 등이 있습니다. 전체 시스템에 걸친 판단이 필요한 작업에는 대신 Claude 또는 GPT 계열 모델로 백그라운드 에이전트를 시작하거나, 포그라운드 편집기에서 계획 단계로 시작하여 Composer에 정확한 계획을 넘기세요.

백그라운드 프롬프트를 티켓처럼 작성하세요

백그라운드 에이전트는 대화형 세션처럼 실행 중간에 명확화 질문을 할 수 없습니다. 목표, 제약, 관련 파일, 성공 검증 방법을 제공하세요. 프롬프트를 작고 자체 포함된 티켓으로 취급하면 Composer가 자율성을 잘 활용할 것입니다.

백그라운드 에이전트에서의 Composer

백그라운드 에이전트는 각 단계를 앉아서 지켜보지 않으므로 Composer의 비용 및 속도 이점이 복리로 쌓이는 곳입니다. 잘 위임하려면 약간의 규율이 필요합니다.

장시간 실행 작업 위임하기

좋은 위임 프롬프트는 자체 포함적이고 티켓 형태입니다:

Goal: add unit tests for every public method in src/services/Billing.ts.

Context: follow the testing style in src/services/Billing.test.ts if it
exists; otherwise mirror src/services/GithubClient.test.ts.

Scope: only create or edit test files under src/services/. Do not change
production code. If a method looks untestable as written, note it in the
final summary instead of refactoring.

Verify: `npm test -- services/Billing` must pass. Report the output.

범위 선택하기

• 백그라운드 작업을 하나의 패키지, 하나의 모듈 또는 하나의 관심사로 유지하세요. 광범위한 작업은 표류합니다.
• 백그라운드 실행에는 기계적 변경을 선호하세요: 이름 변경, 테스트 커버리지, 문서 스텁, 마이그레이션 스크립트.
• 취향이나 아키텍처 판단에 달린 작업은 피하세요. 그런 것은 조종할 수 있는 포그라운드 세션에서 시작하세요.

diff 검토하기

백그라운드 에이전트는 diff나 풀 리퀘스트를 반환하므로 동료의 작업처럼 검토하세요:

1. 건드린 파일을 설정한 범위와 대조하세요. 범위 밖의 것은 더 자세히 볼 신호입니다.
2. 에이전트가 주장하는 작업 요약을 읽고 코드에서 최소한 하나의 주장을 검증하세요.
3. 병합 전에 테스트를 로컬에서 실행하거나 보고된 출력을 확인하세요.
4. diff가 대체로 맞지만 거친 부분이 몇 군데 있다면 전체 에이전트를 다시 실행하지 말고 편집기에서 수정하세요. 재실행이 관련 없는 줄을 바꿀 수 있습니다.

검토되지 않은 백그라운드 diff는 부채입니다

Composer는 빠르게 움직이므로 빠르게 큰 diff를 만들 수 있습니다. 생성 속도는 정확성의 속도가 아닙니다. 모든 백그라운드 결과를 테스트와 범위를 검증할 때까지 제안으로 취급하고, 실행 시간뿐 아니라 검토 시간을 계획하세요.

비용 및 사용 특성

Composer는 Cursor 플랜을 소비하는 가장 가격 효율적인 방법 중 하나입니다. 실질적 함의:

• 모든 것을 최전선 모델로 실행하는 것에 비해 플랜의 사용 허용량 안에 훨씬 더 많은 에이전트 요청이 들어갑니다.
• 많은 도구 호출을 연결하는 긴 에이전트 세션은 각 단계가 더 저렴하므로 저렴하게 유지됩니다.
• 빠른 응답은 세션당 소요 시간을 줄여, 대화형으로 반복할 때 간접적으로 비용을 절약합니다.

대시보드에서 사용량을 모니터링하면 Composer를 기본으로 한 일주일 후 차이가 분명히 보입니다: 동일한 양의 완료된 작업이 눈에 띄게 더 낮은 할당량 비중으로 들어옵니다. 일반적인 전략은 최전선 모델 할당량을 실제 추론 품질을 사는 곳에만 쓰고 일상적인 물량은 Composer가 흡수하게 하는 것입니다.

한도에 산정되는 것

Chat 및 Agent 요청, Cmd-K 편집, 백그라운드 에이전트 실행은 모두 플랜에 산정되며 요청당 과금됩니다. Tab 완성은 일반적으로 별도로 처리되고, 파일 읽기나 명령 실행은 그 자체로 청구되지 않습니다. 비용은 그것들을 호출하는 모델 턴에 의해 발생합니다.

상대적 비용, 속도 및 품질

아래 표는 선택을 돕기 위한 대략적이고 근사적인 비교이지 벤치마크가 아닙니다. 순위는 모델 버전 간에 그리고 작업 구성에 따라 달라질 수 있습니다.

모델	상대 속도 (대략)	상대 비용 (대략)	상대 추론 깊이 (대략)
Composer	가장 빠름	가장 낮음	좋음
Claude Sonnet	보통	더 높음	강함
Claude Opus	가장 느림	가장 높음	가장 강함
GPT 계열 모델	보통	높음~보통	강함
Gemini 모델	보통~빠름	보통	강함

표를 "Composer는 속도와 비용에서 이기고, 최전선 모델은 최고 추론에서 이긴다"로 읽으세요. 대부분의 팀은 그 반대가 아니라 Composer를 기본으로 하고 의도적으로 에스컬레이션하는 방식으로 정착합니다.

Composer를 다른 모델과 결합하기

가장 강력한 워크플로는 "하나의 모델을 영원히 선택"하는 것이 아니라 각 단계를 그것에 맞는 모델로 라우팅하는 것입니다.

1. 추론 모델로 계획하세요. Claude 또는 GPT 계열 모델로 시작해 계획만 요청하세요: 어떤 파일을 어떤 순서로 건드릴지, 어떻게 검증할지. 아직 편집하지 마세요.
2. Composer로 실행하세요. 계획이 작성되고 동의하면 실제 편집을 위해 모델을 Composer로 전환하세요. 명확한 계획을 가진 빠른 모델이 계획을 진행하면서 발견하는 빠른 모델보다 성능이 좋습니다.
3. 두 번째 모델로 검토하세요. 편집이 반영된 후 다른 모델로 전환하고 diff의 정확성, 엣지 케이스, 놓친 요구 사항을 검토하도록 요청하세요. 결과를 새로 읽는 모델은 실행 모델이 합리화해 넘긴 것들을 잡아냅니다.

Phase 1 (Claude/GPT, plan only):
"Read src/payments/ and propose a step-by-step plan to add idempotency
keys to the charge endpoint. List files, order, and verification. Do not edit."

Phase 2 (Composer, execute):
"Implement step 1 from the plan. Only src/payments/charge.ts may change.
Run `npm test -- payments` and report output."

Phase 3 (second model, review):
"Review this diff for correctness and edge cases. Flag anything that
breaks idempotency under retries."

이 계획-실행-검토 루프는 비싼 깊은 추론 호출을 작고 집중적으로 유지하면서 Composer가 실제 편집의 물량을 흡수하게 합니다.

같은 컨텍스트, 다른 모델

작업 중간에 모델을 전환하면 채팅, 열린 파일, 계획이 그대로 유지되므로 단계 간 핸드오프에 비용이 들지 않습니다. 작업을 다시 설명할 필요 없이 선택기만 바꾸고 계속하세요.

앞으로의 길: Composer 3

Composer 라인은 활발히 개발 중이며, 커뮤니티 로드맵에는 이미 흔히 Composer 3라고 불리는 다음 반복에 대한 요청이 가득합니다. 그 논의에서 반복되는 주제는 더 강력한 장기 지평 계획, 매우 큰 저장소에서의 더 나은 성능, 모호한 다단계 작업에서의 향상된 신뢰성이며, 시그니처인 낮은 지연 시간과 낮은 비용은 유지합니다.

그 중 무엇도 오늘 이득을 보기 위해 기다릴 필요는 없습니다. 현재 Composer 모델은 프로덕션 품질의 일상용 모델이며, 모델 선택이 약속이 아닌 드롭다운이므로 지금 채택하고 새 세대가 선택기에 나타나는 순간 전환할 수 있습니다.

일반적인 문제와 한계

Composer는 빠르고, 속도에는 초기에 인식해야 할 실패 유형이 있습니다.

크고 광범위한 편집 만들기

Composer는 저장소 전체 변경을 한 번에 시도하여 검토하기 어려운 방대한 diff를 남길 수 있습니다.

• 원인: "refactor the logging everywhere"와 같은 범위 없는 프롬프트.
• 해결: 변경을 하나의 패키지나 모듈로 제한하거나 작업을 범위가 정해진 짧은 프롬프트 순서로 나누세요. 변경이 정말로 광범위하다면 먼저 계획을 요청하세요.

긴 작업에서 지침 상실하기

긴 세션에서 컨텍스트가 커지면서 이전 제약이 희석될 수 있습니다.

• 원인: 단일 채팅에서 목표가 바뀌는 여러 턴.
• 해결: 방향을 바꿀 때 중요한 제약을 다시 진술하거나, 목표와 규칙의 간결한 요약으로 새 채팅을 시작하세요. .cursor/rules의 규칙 파일도 세션 전반에 관례를 고정하는 데 도움이 됩니다.

환각 API

빠른 모델은 때때로 존재하지 않는 메서드나 패키지를 참조합니다.

• 원인: 모델이 코드베이스가 아니라 학습에서 패턴 매칭합니다.
• 해결: 명시적인 파일 참조를 주고 실제 소스에 대해 검증하도록 요청하세요. API를 만들어낸다면 실제 것을 가리키고 저장소에 존재하는 심볼만 사용하여 편집을 다시 하도록 요청하세요.

전체 코드베이스 리팩터링이 필요한 경우

일부 리팩터링은 진정으로 전체 시스템에 걸쳐 있으며 빠른 모델이 한 번에 잘 처리하는 범위를 초과합니다.

• 원인: 변경에 교차 관심사 의존성과 모호한 경계가 있습니다.
• 해결: 먼저 추론 모델로 계획한 다음, 범위가 정해진 일련의 Composer 단계로 실행하고 각각 후 검증하세요. 하나의 거대한 실행보다 패키지당 하나의 백그라운드 에이전트를 고려하세요.

타임아웃 또는 멈춤

때때로 특히 매우 큰 작업에서 에이전트 실행이 멈추거나 타임아웃됩니다.

• 원인: 지나치게 광범위한 목표, 거대한 컨텍스트 또는 결코 해결되지 않는 단일 단계.
• 해결: 작업을 좁히고 재시도하세요. 반복되면 작업을 더 작은 단계로 나누고, 계속 멈추는 단계에는 최전선 모델을 고려하세요. 긴 백그라운드 실행의 범위를 정하여 멈춤이 1시간이 아니라 몇 분의 비용이 들게 하세요.

증상 → 원인 → 해결

증상	유력한 원인	해결
거대하고 검토 불가능한 diff	범위 없는 프롬프트	범위 제한, 계획 요청 및 단계로 분할
모델이 이전 제약 무시	긴 채팅에서 컨텍스트 희석	제약 재진술 또는 요약된 새 채팅 시작
모델이 존재하지 않는 메서드 호출	학습 기반 패턴 매칭	파일 참조 제공, 실제 심볼에 대해 검증 요청
전체 코드베이스 리팩터링이 불안하게 느껴짐	교차 관심사 변경	추론 모델로 계획한 다음 범위가 정해진 단계로 실행
실행이 멈추거나 타임아웃	지나치게 광범위한 작업 또는 과대한 컨텍스트	좁히고 재시도, 더 작은 단계로 분할

자주 묻는 질문

Composer는 2024년 Composer 기능과 같은 것인가요?

아니요. 2024년 "Composer"는 Cursor UI의 다중 파일 편집 워크플로였고 나중에 Agent 모드로 통합되었습니다. 이 가이드의 Composer는 Claude 및 GPT와 같은 선택기에서 선택하는 모델입니다.

Composer는 어떤 모델 위에서 실행되나요?

Composer는 Cursor 자체의 사내 모델 라인으로, 제3자로 라우팅되지 않고 Cursor 팀이 학습합니다. 속도와 비용 프로필은 범용 기반 모델이 아니라 그 집중에서 비롯됩니다.

Claude나 GPT 대신 Composer를 언제 선택해야 하나요?

명세가 잘 된 빠른 반복 작업에는 Composer를 기본으로 하세요. 작업이 모호하거나 많은 상호 의존 모듈에 걸치거나 깊은 아키텍처 수준 추론이 필요할 때 에스컬레이션하세요.

실제 프로덕션 작업에 충분히 좋은가요?

예, 대다수의 일상 작업에는 좋습니다: 명세된 컴포넌트 구현, 테스트 수정, 기계적 리팩터링, 일상 유지보수. 고위험 추론에는 계획-실행-검토 워크플로를 사용하여 최전선 모델과 짝지으세요.

추가 비용이 드나요?

플랜을 소비하는 가장 저렴한 방법 중 하나입니다. 플랜은 대부분 요청당 과금되므로 요청당 저렴한 모델은 허용량 안에 더 많은 작업이 들어가게 합니다.

작업 중간에 모델을 전환할 수 있나요?

예, 그리고 그래야 합니다. 채팅, 열린 파일, 계획이 유지되므로 추론 모델로 계획한 다음 컨텍스트를 잃지 않고 Composer로 전환해 실행할 수 있습니다.

편집이 멈추거나 제자리를 맴도는 이유는 무엇인가요?

보통 한 번의 실행에 작업이 너무 광범위했기 때문입니다. 범위를 좁히고, 명시적인 파일을 제공하고, 하나의 프롬프트가 모든 것을 하리라 기대하기보다 각 단계 후 검증하세요.

Composer 3가 나오나요?

커뮤니티 논의는 더 강력한 장기 지평 계획과 대형 저장소 성능을 갖춘 차세대를 가리킵니다. 기다릴 필요는 없습니다. 모델 선택이 드롭다운이므로 나타나는 날 바로 새 버전을 채택할 수 있습니다.

빠른 참조

질문	답변
Composer란 무엇인가요?	Cursor의 사내 속도 최적화 에이전트 코딩 모델
어디에서 선택하나요?	Chat 및 Agent 모드의 모델 선택기 또는 Settings > Models
언제 사용하지 말아야 하나요?	깊고 모호하며 아키텍처 중심 추론 작업
예전 Composer 기능인가요?	아니요, 2024년 다중 파일 도구는 Agent 모드로 통합되었습니다
백그라운드 에이전트에서 작동하나요?	예, 그리고 그곳에서 비용 효율적인 기본값입니다
다음은 무엇인가요?	Composer 3 세대에 대한 커뮤니티 논의

Composer는 단순한 워크플로에 보답합니다: 기본으로 하고, 정확한 프롬프트를 작성하고, 관례를 규칙에 인코딩하고, 작업이 진정으로 더 깊은 추론을 필요로 할 때만 최전선 모델로 에스컬레이션하세요. 그 습관이 중요한 곳에서 품질을 포기하지 않고 Cursor 자체 모델 라인의 속도와 비용 이점을 얻게 합니다.