Cursor Composer와 Agent, 언제 바꾸나
Composer와 Agent는 UI에 나란히 보이지만 축이 다릅니다. Composer(현재 Composer 2.5 계열)는 Cursor 자체 agentic 모델이고, Agent는 코드베이스 검색·편집·터미널 등 도구를 쓰는 모드입니다. 가격·플랜·Cloud vs 로컬·타사 IDE 비교는 다루지 않습니다.
이 글은 Composer를 언제 고를지, Agent 모드를 언제 켤지, 같은 작업 안에서 전환 기준만 정리합니다. 근거는 Agent 개요, Agent 모드 도움말, Composer 모델 문서입니다.
Composer는 언제?
한 줄 답: Agent(또는 다른 모드) 위에서 실행·도구 루프를 돌릴 엔진으로 Composer를 고릅니다. “모드”가 아니라 모델 피커 축입니다.
공식 문서 기준 Composer 계열의 위치:
| 축 | 의미 |
|---|---|
| 정체 | Cursor 자체 agentic 모델(문서의 Composer 2.5) |
| 강점 | 긴 agentic 작업, 도구 선택·의도 파악, 파일 편집·터미널 루프 |
| 도구 | Cursor Agent 도구 전체에 접근(검색·편집·셸 등) |
| 고르는 곳 | 모델 피커(모드 드롭다운과 별개) |
실무에서 Composer를 고르는 신호:
- 구현·리팩터·버그픽스 루프가 이미 명확하고, 편집+명령 반복이 중심일 때.
- Plan/Ask로 범위·접근을 이미 고정한 뒤, 실행만 빠르게 닫고 싶을 때.
- 세션이 대화형으로 짧게 스티어링되며, Cursor에 맞춘 도구 호출이 중요할 때.
- 같은 Agent 세션에서 장시간 도구 연쇄가 예상될 때(문서는 long-horizon·tool use를 강점으로 둠).
Composer만 켠다고 파일이 바뀌지는 않습니다. **모드가 Agent(또는 Debug 등 편집 허용 모드)**여야 도구 편집·터미널이 열립니다. Composer는 “무엇을 생각·작성할지”의 엔진이고, Agent는 “무엇을 만질지”의 권한입니다.
Agent는 언제?
한 줄 답: 기능을 만들고, 리팩터하고, 버그를 고치며, 명령을 실행해야 할 때 Agent 모드를 씁니다. 공식 도움말도 대부분 작업의 기본값으로 Agent를 둡니다.
Agent 모드가 여는 축(Agent overview · help):
| 축 | Agent가 하는 일 |
|---|---|
| 구성 | 지시(규칙)·도구·선택한 모델 세 축 |
| 도구 | 검색·읽기·편집·셸·웹·브라우저 등(작업 중 도구 호출 횟수 제한 없음으로 안내) |
| 진입 | 사이드페인 Cmd/Ctrl+I 등 |
| 안전장치 | Checkpoints로 Agent 변경 롤백(Git과 별개) |
| 스티어링 | 큐·즉시 follow-up으로 진행 중 방향 조정 |
Agent를 고르는 신호:
- 멀티 파일 변경이 필요하고, 어떤 파일을 건드릴지 모델이 탐색해야 할 때.
- 테스트·빌드·스크립트를 돌리며 오류를 스스로 이어 고쳐야 할 때.
- “이 기능 추가해 줘”처럼 결과물=코드 변경이 목표일 때.
- Ask로 이해만 하거나 Plan으로 계획만 세운 뒤, 이제 적용 단계일 때.
반대로 읽기만이면 Ask, 접근을 먼저 리뷰하려면 Plan, 런타임 증거로 버그 추적이면 Debug입니다. 이 글의 축은 Composer(모델)↔Agent(모드)이므로 Ask/Plan/Debug는 전환 신호로만 언급합니다. Cloud vs 로컬 실행 장소 비교는 별도 글 영역입니다.
같은 작업에서 전환 기준은?
한 줄 답: 모드는 도구 권한·작업 단계로 바꾸고, Composer는 실행 엔진으로 유지하거나 막힐 때만 모델 축을 바꿉니다. 도움말은 모드 전환 시 컨텍스트가 새로 열린다고 안내하므로, 같은 작업이라도 인수인계를 짧게 적습니다.
전환 체크리스트
| 증상 | 먼저 바꿀 축 | 실무 동작 |
|---|---|---|
| 파일이 안 바뀌거나 설명만 나옴 | 모드 → Agent | Ask에 머문 채 “고쳐 줘”를 반복하지 않음 |
| 범위·설계가 흐림 | 모드 → Plan 후 승인 → Agent | 계획 MD를 고친 뒤 Build/실행 |
| 의도치 않은 대량 편집 | 모드 → Ask(또는 Stop) | 질문만 분리한 뒤 스코프를 다시 Agent에 넘김 |
| 구현 루프는 명확 | 모델 → Composer 유지 | Agent+Composer로 편집·터미널 반복 |
| Composer가 같은 실수 반복 | 모델 축만 조정 | 모드를 굳이 바꾸지 않음(도구 권한 문제는 모드) |
| 작업 주제가 완전히 바뀜 | 새 채팅 | 도움말: 작업 바뀔 때 새 채팅 권장 |
같은 작업 안에서의 권장 순서
- 스코프가 흐리면 Plan(또는 Ask)으로 범위·비목표를 고정합니다.
- 실행 단계에서 Agent로 전환하고, 실행 엔진으로 Composer를 둡니다.
- 진행 중 방향만 트면 큐/Steer로 이어 갑니다(모드를 매번 바꾸지 않음).
- 결과가 빗나가면 Checkpoint로 되돌린 뒤, 계획을 다듬고 다시 Agent로 실행합니다.
- 모드를 바꿀 때는(도움말: 모드마다 별도 컨텍스트) 목표·스코프·이미 한 일·재현 명령 네 줄을 첫 메시지에 붙입니다.
단축키 축(도움말): 모드 피커 또는 Shift+Tab으로 모드 순환. Composer 선택은 모델 피커입니다. 두 축을 한 토글로 묶지 않습니다.
이 글이 다루지 않는 것
- Cloud Agent vs 로컬 Agent — 실행 장소·PR/장시간 축(별도).
- Copilot Chat vs Cursor Agent — 제품 간 역할 분담(별도).
- 요금·요청 한도 숫자 — 선택 기준에서 제외합니다.
FAQ
Composer를 켜면 Agent가 자동인가요?
아닙니다. Composer는 모델입니다. 편집·터미널이 필요하면 Agent 모드를 선택한 뒤 모델로 Composer를 고릅니다.
Agent만 켜고 모델은 아무거나 써도 되나요?
가능합니다. Agent는 모델과 독립된 모드입니다. 문서상 Composer는 Agent 도구에 맞춰 튜닝된 Cursor 자체 모델이라, 일상 구현 루프에 자주 붙입니다.
모드를 바꾸면 이전 대화가 이어지나요?
도움말은 모드마다 자체 컨텍스트를 쓴다고 안내합니다. 같은 작업이라도 전환 시 짧은 인수인계를 붙이거나, 주제가 바뀌면 새 채팅을 권장합니다.