AI 코딩 도구를 조금이라도 써보셨다면 다음 상황들이 낯익으실 겁니다.
- 에이전트(Agent) 모드에 “이 기능 추가해 줘”라고 던졌더니, 정작 내가 의도한 것과는 전혀 다른 결과물이 나왔을 때
- 피드백을 주면 줄수록 늪에 빠져서, 차라리 처음부터 다시 시작하는 게 빠를 뻔했다고 느꼈을 때
- 생성된 코드는 잘 작동하지만, 나중에 걷잡을 수 없이 엉망이 된 내부 설계 때문에 고생했을 때
이 세 가지 문제의 근본적인 원인은 모두 같습니다. 바로 설계가 제대로 끝나기도 전에 구현부터 시작했기 때문입니다. Cursor의 **플랜 모드(Plan Mode)**는 바로 이 문제를 근본적으로 해결하기 위해 만들어졌습니다.
플랜 모드란 무엇인가요? AI가 코드를 쓰기 전에 활용하는 방법
플랜 모드는 Cursor가 2025년 10월에 도입한 전용 구현 계획 수립 모드입니다. 한마디로 코드가 작성되기 전에 AI와 함께 설계를 확실하게 고정하는 메커니즘입니다.
일반적인 에이전트 모드가 곧바로 파일을 수정하는 작업에 뛰어드는 것과 달리, 플랜 모드는 먼저 다음과 같은 과정을 거칩니다.
- 명확화 질문(Clarifying questions) — 요구사항 중 모호한 부분이 있다면 에이전트가 직접 질문을 던집니다.
- 코드베이스 조사(Codebase research) — 관련 파일과 기존 구현 내용을 자동으로 탐색합니다.
- 계획 생성(Plan generation) — 파일 경로와 코드 참조가 포함된 상세한 계획을 마크다운(Markdown)으로 작성합니다.
- 검토 및 수정(Review and edit) — 사람이 실행을 승인하기 전에 계획을 검토하고 조정합니다.
- 빌드(실행) — 승인이 완료되면 “빌드”를 눌러 실제 구현 단계로 넘어갑니다.
여기서 핵심은 4단계인 ‘검토’입니다. AI가 일방적으로 무언가를 구현하는 대신, 사람이 직접 계획을 확인하고 수정한 뒤에야 진행 허가를 내릴 수 있습니다. 이 단 한 번의 추가 과정 덕분에 결과물의 코드 품질이 대폭 향상됩니다.
플랜 모드를 켜는 방법
채팅 입력창에서 단순히 **Shift + Tab**을 누르기만 하면 됩니다. 또는 모드 드롭다운 메뉴에서 “Plan”을 선택할 수도 있습니다.
복잡한 작업임을 암시하는 키워드가 감지되면, Cursor가 알아서 플랜 모드로 전환을 제안하기도 합니다.
플랜 모드가 진가를 발휘하는 순간
공식 문서에 따르면 다음과 같은 상황에서 특히 효과적입니다.
실행 가능한 대안이 여러 개인 복잡한 기능: 예를 들어 인증 기능을 추가할 때 JWT, 세션, OAuth 등 여러 경로를 선택할 수 있습니다. 플랜 모드에서 접근 방식을 미리 확실히 정해두면 중간에 구현 방향이 흔들리는 것을 막을 수 있습니다.
여러 파일이나 시스템에 걸쳐 있는 작업: 대규모 리팩토링이나 여러 모듈에 걸치는 기능 개발 등입니다. 작업 범위(Blast radius)를 미리 시각화해 두면 누락과 재작업을 줄일 수 있습니다.
요구사항이 모호하고 먼저 범위를 확정하고 싶을 때: “이런 느낌의 무언가를 만들고 싶어”라는 막연한 지시 사항도 AI가 던지는 명확화 질문을 통해 구체적인 요구사항으로 다듬어집니다.
코드를 작성하기 전에 아키텍처 결정을 검토하고 싶을 때: “이 로직은 어느 레이어에 있어야 할까?”, “어떤 라이브러리를 써야 할까?” 같은 결정을 코드가 존재하기도 전에 미리 승인받을 수 있습니다.
반면 자주 하는 사소한 변경이나 루틴 작업의 경우에는 곧바로 에이전트 모드로 직행해도 아무 문제가 없습니다. 플랜 모드는 모든 상황을 위한 게 아닙니다. 복잡성이나 모호함이 감돌기 시작할 때 골라 쓰는 것이 요령입니다.
계획 저장 및 재사용하기
기본적으로 플랜 모드가 생성한 계획은 홈 디렉토리에 임시 파일로 만들어집니다. “Save to workspace”를 클릭하면 대신 .cursor/plans/ 폴더에 저장됩니다.
이를 통해 얻을 수 있는 장점들은 다음과 같습니다.
- 팀 공유 — 팀원들이 작업 이면에 있는 설계 의도를 파악할 수 있습니다.
- 문서화 — 특정 구현 방식을 선택한 이유에 대한 기록이 남습니다.
- 작업 재개 — 작업이 중간에 중단되더라도 계획을 토대로 쉽게 다시 이어갈 수 있습니다.
- 향후 에이전트를 위한 컨텍스트 — 같은 기능을 이어받아 작업할 다음 에이전트에게 인수인계 자료가 됩니다.
계획은 단순한 마크다운 파일이므로 직접 편집하기도 쉽습니다. 필요 없는 단계를 지우거나 AI가 놓친 컨텍스트를 추가할 수 있습니다.
플랜 → 에이전트: 확실하게 통하는 작업 패턴 예시
❌ 사람들이 흔히 빠지는 실패 패턴
[In Agent mode]
"Add user authentication"→ 인증 로직, 세션 처리, 에러 핸들링이 뒤엉킨 코드가 반환됩니다. 나중에 이를 다시 분리하는 데 엄청난 시간이 걸립니다.
✅ 대신 플랜 모드 사용하기
1단계: 플랜 모드에서 요구사항 확정하기
[Switch to Plan Mode with Shift+Tab]
"I want to add user authentication.
Requirements: email + password login, session management,
error handling, test coverage"AI가 명확화 질문을 던지며 돌아옵니다(예: “기존 인증 기반이 있나요?”, “세션은 어디에 저장해야 하나요?”). 이에 답변하면 다음과 같은 계획이 만들어집니다.
## Implementation Plan: User Authentication
### Step 1: Build the auth controller
- POST /login endpoint
- POST /logout endpoint
### Step 2: Build the auth service
- Password hash verification logic (kept separate from the controller)
### Step 3: Implement session-management middleware
- Session creation, validation, and teardown
### Step 4: Error handling
- Exception handling for failed auth and expired sessions
### Step 5: Write test coverage
- Unit tests for each endpoint2단계: 계획 검토 및 조정
내 관점에서 계획을 편집합니다. 예를 들어 “4단계 전에 입력값 검증 단계를 추가해 줘”라고 수정할 수 있습니다.
3단계: 빌드를 눌러 구현하기(에이전트 모드)
계획이 마음에 든다면 “Build”를 클릭하세요. 명확한 청사진이 손에 있으므로 에이전트가 엉뚱한 길로 새지 않고 구현을 마칩니다.
실용적인 팁을 하나 더 드리자면, 모든 단계를 한 번에 실행하기보다는 한두 단계씩 실행하며 그때그때 정상 작동하는지 확인하는 것이 좋습니다. 문제를 더 일찍 발견할 수 있고, 코드를 이해하는 깊이도 훨씬 깊어집니다.
계획이 틀어졌을 때: 다시 플랜 모드로 돌아가기
에이전트가 의도와 다른 방향으로 구현을 시작했다면, 추가 프롬프트를 입력해 궤도를 수정하려고 애쓰는 것은 대개 잘못된 접근입니다.
올바른 대처법은 다음과 같습니다.
- Stop을 눌러 작업 중단하기
- 변경사항 되돌리기(Undo)
- 플랜 모드로 돌아가 더 구체적인 조건 추가하기
- 빌드 다시 실행하기
먼 길을 돌아가는 것처럼 느껴지지만, “실행 중인 에이전트를 후속 지시로 고치는 것”보다 훨씬 빠르고 깔끔한 결과로 이어집니다.
변경 규모가 클수록 정확하고 범위가 명확한 계획을 세우는 데 시간을 투자하는 것이 보람을 가져다줍니다. 어려운 부분은 무엇을 만들 것인지 정하는 것입니다. 지시사항이 올바르게 내려졌다면, 어떻게 만들지는 에이전트에게 믿고 맡겨도 됩니다.
Cursor의 4가지 모드와 각각의 활용 시점
플랜 모드를 더 잘 활용하려면 4가지 모드의 특성을 머릿속에 명확히 정리해 두는 것이 좋습니다.
| 모드 | 용도 | 활용 시점 |
|---|---|---|
| Ask | 질문, 조사, 코드 이해 | “이 코드는 무슨 일을 하나요?”, “이 에러의 원인이 뭔가요?” |
| Plan | 설계를 말로 풀어내기, 구현 전 계획 수립 | 여러 파일에 걸친 작업, 혹은 요구사항이 모호할 때 |
| Agent | 코드 생성, 편집, 리팩토링 | 설계가 확정된 상태에서의 구현, 단일 기능 추가 |
| Debug | 버그 재현, 원인 파악 | 재현하기 어려운 버그, 런타임 에러 조사 |
스마트하게 자문해 보세요. “이 작업이 하나의 파일에 들어가나요? 설계가 이미 명확한가요?” 둘 중 하나라도 아니오라면, 플랜 모드로 시작하는 것이 훨씬 안전합니다.
저는 이제 에이전트 모드에 곧바로 수정을 지시하는 일이 드뭅니다. 기본적으로 플랜 모드를 거치도록 강제하면 작업에 대한 생각을 스스로 정리하게 되기 때문에, 본격적으로 넘어가기 전에 플랜 모드로 큰 그림을 먼저 잡는 편이 나중에 코드를 다시 뜯어고치는 일을 엄청나게 줄여줍니다.
흔히 저지르는 실수와 피하는 법
계획을 너무 맹신하기
계획은 어디까지나 가설일 뿐입니다. 구현 중에 “사실 5단계를 3단계보다 먼저 해야 한다”는 사실을 깨달았다면, 계속 진행하기 전에 계획을 수정하세요. 비효율적인 구현임을 알면서도 계획에 맹목적으로 집착하는 것은 본말이 전도된 것입니다.
계획을 지나치게 세세하게 짜기
“이 파일의 X번째 줄에 이걸 넣어라” 수준까지 계획을 적어버리면 구현의 유연성을 전부 잃어버리게 됩니다. 알맞은 상세 수준은 대략 “컴포넌트 또는 기능” 단위이며, 세부적인 구현 방법은 에이전트에게 맡겨야 합니다.
너무 단순한 작업에도 플랜 모드 쓰기
단순한 변수명 변경이나 한 줄짜리 수정에 플랜 모드를 사용하는 것은 오히려 비효율적입니다. 작업이 에이전트 모드에 바로 보내도 될 만큼 단순한지 판단하는 안목도 중요합니다.
Ask 모드를 건너뛰고 곧바로 Plan으로 넘어가기
이상적으로는 Ask 모드를 통해 기존 코드베이스를 먼저 파악한 뒤, 플랜 모드에서 설계해야 합니다. 이미 있는 코드가 무엇인지 파악하지도 않고 계획을 세우면 중복 구현이나 일관성 없는 코드가 나오기 십상입니다.
최신 동향: 2026년의 플랜 모드와 모델 선택
2026년 2월 기준으로, 플랜 모드에서 어떤 모델을 사용하느냐 자체가 중요한 의사결정 요소가 되었습니다.
- 일상적인 플랜 작성: Composer 1.5 / Auto (빠르고 비용 효율적이며 Cursor에 최적화됨)
- 복잡한 아키텍처 설계: Claude Opus 4.6 (SWE-rebench 1위, 1M 토큰 컨텍스트 윈도우 지원)
Cursor 자체의 Composer 1.5는 파일 편집기, 터미널, 검색 등 Cursor 내부 툴 안에서 직접 학습되어 일상적인 계획 및 구현 작업에 특히 뛰어난 적합성을 보여줍니다.
핵심 요약: “설계 먼저, 작성은 그다음”
플랜 모드 이면에 있는 핵심 아이디어는 단순합니다. AI가 그 자리에서 “무작정 코드를 쓰게” 만들지 않는 것입니다.
- 요구사항이 여전히 모호한 상태에서 구현을 지시하지 마세요.
- AI의 판단을 맹신하지 말고 검토 단계를 마련하세요.
- 무언가 잘못되었을 때 구현을 억지로 쫓아가지 말고 계획으로 돌아가세요.
단지 이 마인드셋을 유지하는 것만으로도 AI 보조 코딩의 품질과 효율성이 크게 달라집니다. “에이전트가 엉뚱한 길로 샌다”거나 “자꾸 코드를 다시 짜고 있다”고 느껴지셨다면, 지금 바로 플랜 모드를 시도해 보세요.
플랜 모드를 켜는 방법: 채팅 입력창에서 Shift + Tab
