# 플랜 우선 워크플로 (/ko/docs/verdent-for-vscode/configuration/plan-workflows)
> 복잡한 작업에 AI 지원 플래닝 사용하기
플랜 우선 워크플로는 읽기 전용 실행 모드인 **Plan Mode**를 활용합니다. 이 모드에서 Verdent는 변경을 실행하기 전에 코드를 분석하고, 리서치를 수행하며, 상세한 플랜을 만듭니다. 이 워크플로는 전략적 플래닝과 구현을 분리하여, 코드 수정을 확정하기 전에 검토하고 다듬을 수 있게 합니다.
### Plan Mode를 사용해야 할 때 [#plan-mode를-사용해야-할-때]
* 조율이 필요한 복잡한 다중 파일 변경
* 최선의 구현 방식이 불확실할 때
* 프로덕션 핵심 코드에 대한 중요한 변경
* 탐색이 필요한 낯선 코드베이스의 작업
* 실행 전에 승인이 필요한 전략적 플래닝
***
## AI 지원 작업 분해 [#ai-지원-작업-분해]
Verdent는 AI 지원 작업 분해를 통해 복잡한 요청을 관리 가능한 순차 단계로 자동 분해합니다.
### 분해 프로세스 [#분해-프로세스]
Verdent는 자연어 요청을 분석하여 다음을 파악합니다.
* 주요 목표와 원하는 결과
* 영향을 받는 파일, 컴포넌트 또는 시스템
* 필요한 기술 작업과 의존성
* 잠재적인 복잡도 요인
Verdent는 프로젝트 구조를 살펴 다음을 이해합니다.
* 기존 아키텍처와 확립된 패턴
* 파일 구성과 기술 스택
* 수정이 필요한 현재 구현
Verdent는 요청을 논리적인 하위 작업으로 나눕니다.
* 자연스러운 중단 지점과 구현 단계를 식별합니다
* 의존성 순서대로 작업을 정렬합니다(선행 작업 먼저)
* 관련 작업을 함께 묶습니다
* 각 하위 작업의 범위와 복잡도를 추정합니다
Verdent는 분해를 다듬기 위해 질문할 수 있습니다.
* "기존 검증 로직을 수정할까요, 아니면 새 validator를 만들까요?"
* "영향을 받는 모든 컴포넌트의 테스트를 업데이트할까요?"
* "이 변경을 웹과 모바일 컴포넌트 모두에 적용할까요?"
### 분해 특성 [#분해-특성]
* 집중 작업 15\~45분에 맞춘 작업 크기
* 테스트와 검증을 위한 자연스러운 중단 지점
* 의미 있을 만큼은 복잡하지만 실행하기에는 충분히 단순함
* 의존성을 준수합니다(구현 전에 설정)
* 논리적인 진행 흐름을 따릅니다(데이터 계층 → 비즈니스 로직 → UI)
* 주요 단계 뒤에 검증 단계를 둡니다
플랜 분해 형식은 `plan_rules.md`를 통해 다음을 제어하도록 사용자 지정할 수 있습니다.
* 세부 수준(상위 수준 vs 세분화)
* 플랜 구조와 섹션
* 포함할 정보(예상 시간, 위험, 의존성)
***
## 플랜 검토 및 승인 [#플랜-검토-및-승인]
Plan Mode에서 요청을 제출하면, Verdent가 검토할 수 있도록 Chat View에 구조화된 플랜을 생성해 표시합니다.
### 검토 프로세스 [#검토-프로세스]
Verdent는 명확한 섹션, 번호가 매겨진 단계, 영향을 받는 파일, 식별된 의존성을 포함한 플랜을 생성합니다
다음을 검토합니다.
* **정확성:** 이 접근 방식이 문제를 해결하나요?
* **완전성:** 필요한 모든 단계가 포함되어 있나요?
* **효율성:** 이것이 최선의 접근 방식인가요?
* **위험:** 무엇이 잘못될 수 있나요? 엣지 케이스나 보안 우려는 없나요?
불명확한 부분이 있으면 추가 정보를 요청합니다.
```
Can you explain step 3 in more detail?
Why are we modifying both the service and controller?
What happens if the API call fails in step 5?
```
플랜을 수정하도록 피드백을 제공합니다.
```
Let's use JWT tokens instead of OAuth2
Can we break step 4 into smaller substeps?
Add error handling considerations to the plan
```
Verdent가 플랜을 생성한 뒤에는 두 가지 옵션이 제공됩니다.
* **Edit**: 수정 요청, 명확화 질문 또는 플랜 추가 다듬기
* **Start Building**: Agent Mode로 전환하고 승인한 플랜 실행 시작
### 플랜 상호작용 옵션 [#플랜-상호작용-옵션]
생성된 플랜을 검토한 뒤, Verdent는 두 가지 옵션을 제공합니다.
**Edit:**
이 옵션을 선택해 다음을 수행합니다.
* 플랜 접근 방식에 대한 구체적인 변경 요청
* 구현 세부 사항에 대한 명확화 질문
* 누락된 요소나 고려 사항 추가
* 특정 단계 단순화 또는 확장
* 대안 접근 방식 탐색
이 옵션을 사용하면 변경을 실행하지 않고, 반복적으로 다듬기 위해 Plan Mode에 머무릅니다.
**Start Building:**
이 옵션을 선택해 다음을 수행합니다.
* Agent Mode로 전환하고 실행 시작
* 승인한 플랜을 완전한 자율성으로 구현
* 계획대로 파일 수정 및 명령 실행
다음 방식도 선택할 수 있습니다.
* **수동 구현**: 플랜을 검토하고 직접 변경 사항 구현
* **점진적 실행**: Verdent에게 특정 단계를 구현하도록 요청하고 단계 사이에 검토 체크포인트 설정
필요한 만큼 **Edit**를 사용해 플랜을 반복적으로 다듬으세요. 접근 방식이 정확하고 완전하다고 확신할 때만 **Start Building**을 선택합니다.
***
## 반복적 플래닝 [#반복적-플래닝]
사용자는 **Edit**를 선택하고 대화형 피드백을 제공하여 플랜을 자유롭게 수정하고 반복할 수 있습니다. Verdent는 플랜 생성을 대화형 반복 프로세스로 다룹니다.
### 수정 방법 [#수정-방법]
**구체적인 변경 요청:**
```
Change step 3 to use Redux instead of Context API
Add input validation before the database insert
Swap the order of steps 4 and 5
```
**누락된 요소 추가:**
```
Add error handling for network failures
Include rollback procedures
Add performance optimization considerations
```
**단순화 또는 확장:**
```
This is too complex - can we simplify the approach?
Break down step 5 into more detailed substeps
Give me more detail on the database schema changes
```
**대안 탐색:**
```
What if we used webhooks instead?
Show me an alternative plan using microservices architecture
Can we accomplish this without changing the database schema?
```
### 반복 흐름 예시 [#반복-흐름-예시]
```
User: "Add user authentication to the API"
[Verdent generates initial plan with JWT tokens]
User: "Actually, let's use OAuth2 instead of JWT"
[Verdent revises plan to use OAuth2]
User: "Add step for migrating existing users"
[Verdent adds migration step to plan]
User: "Can you break down the migration step more?"
[Verdent expands migration with detailed substeps]
User: Chooses **Start Building**
[Verdent switches to Agent Mode and begins execution]
```
**무제한 반복:**
* 수정 횟수 제한 없음
* 각 반복은 대화 컨텍스트를 유지함
* 이전 버전은 채팅 기록에 보존됨
* 이전 플랜 버전을 참조할 수 있음: "첫 번째 접근 방식으로 돌아가줘"
플랜 거부는 반복적 플래닝 프로세스의 자연스러운 일부입니다. 승인되고 충분히 이해된 전략만 실행하도록 보장하여, 잘못된 구현에 낭비되는 노력을 줄입니다.
***
## FAQ(자주 묻는 질문) [#faq자주-묻는-질문]
**아니요.** Plan Mode는 엄격히 읽기 전용입니다.
* Verdent는 파일을 읽고, 코드를 검색하고, 코드베이스를 분석할 수 있습니다
* Plan Mode 중에는 **파일 쓰기, 편집 또는 삭제가 발생하지 않습니다**
* 플랜은 Chat View에만 표시됩니다
* 사용자가 명시적으로 승인하고 Agent Mode로 전환한 뒤에만 코드 실행이 시작됩니다
**안전 보장:** Plan Mode는 실수로 코드를 수정할 수 없습니다. 안전한 탐색과 전략 수립을 위해 설계되었습니다.
**네.** 점진적 실행을 완전히 지원합니다.
**점진적 승인 패턴:**
```
Let's start with Phase 1 first, then we'll review before continuing
Implement steps 1-3, then stop for review
Do the database migration first, I'll review before the API changes
```
**작동 방식:**
1. Verdent가 지정된 단계를 실행합니다
2. 검토 체크포인트에서 멈춥니다
3. 사용자가 결과를 검토하고 피드백을 제공합니다
4. 다음 단계로 계속 진행하거나 접근 방식을 조정합니다
5. 완료될 때까지 반복합니다
**적합한 경우:** 위험이 큰 변경, 익숙하지 않은 패턴, 단계적 롤아웃으로 위험을 줄여야 하는 프로덕션 핵심 코드.
점진적 실행을 사용하면 우선순위가 작업 중간에 바뀔 때 유용하게, 플랜의 일부는 승인하고 나머지는 나중으로 미룰 수 있습니다.
**플랜 거부는 완전히 정상이며 예상되는 과정입니다.**
* Verdent는 피드백을 바탕으로 새 플랜을 생성합니다
* 이전 플랜 버전은 참조할 수 있도록 채팅 기록에 남습니다
* 코드 변경은 발생하지 않습니다(Plan Mode는 읽기 전용입니다)
* 만족할 때까지 무제한으로 반복할 수 있습니다
**일반적인 거부 이유:**
* 접근 방식이 너무 복잡하거나 너무 단순함
* 엣지 케이스 또는 오류 처리가 빠짐
* 더 나은 대안 아키텍처가 있음
* 요구 사항을 잘못 이해함
**프로 팁:** 거부는 프로세스의 일부입니다. 잘못된 전략을 실행하느라 노력을 낭비하는 것보다 플랜을 반복적으로 다듬는 편이 낫습니다.
**Input Box에서 즉시 전환할 수 있습니다.**
**Plan Mode로 들어가기:**
* Input Box의 **Switch Mode** 버튼을 선택합니다
* 드롭다운에서 **Plan Mode**를 선택합니다
* 또는 "Switch to Plan Mode"라고 말합니다
**Plan Mode에서 나가기:**
* Input Box의 **Switch Mode** 버튼을 선택합니다
* 드롭다운에서 **Agent Mode**를 선택합니다
* 또는 플랜을 검토한 뒤 **Start Building**을 선택합니다
**모드 유지:**
* 모드 선택은 현재 세션 안에서 유지됩니다
* 새 세션은 기본 Agent Mode에서 시작합니다
* 언제든지 자유롭게 모드를 전환할 수 있습니다
**일반적인 워크플로:** Plan Mode → 검토 → Agent Mode → 실행 → 다음 복잡한 기능을 위해 다시 Plan Mode로 돌아가기.
**네, `plan_rules.md`를 사용하면 됩니다.**
**위치:** `~/.verdent/plan_rules.md` (전역 구성 디렉터리)
**사용자 지정할 수 있는 항목:**
* **세부 수준:** 상위 수준 개요 vs. 세분화된 단계별 설명
* **플랜 구조:** 포함할 섹션(요약, 위험, 의존성, 테스트)
* **포함할 정보:** 예상 시간, 파일 경로, 검증 단계
* **형식 선호:** 번호 목록, 단계, 분류
**plan\_rules.md 예시:**
```markdown
# Plan Rules
## Plan Structure
- Start with a brief summary (2-3 sentences)
- Include estimated time for each major step
- List prerequisites before implementation steps
- Identify potential risks and mitigation strategies
## Level of Detail
- Break tasks into subtasks of 15-30 minutes
- Include specific file paths for modifications
- List functions or components to create/modify
- Provide verification steps for each phase
```
**변경 사항은 새 Plan Mode 세션에 즉시 적용됩니다.**
**아니요, Plan Mode에는 별도의 컨텍스트 관리가 있습니다.**
* **Plan Mode 컨텍스트:** 분석과 전략적 사고에 최적화
* **Agent Mode 컨텍스트:** 실행과 구현에 최적화
* **장점:** 플랜이 탐색 리서치로 실행 컨텍스트를 어지럽히지 않습니다
**분리가 중요한 이유:**
* Plan Mode는 Agent Mode를 복잡하게 만들지 않고 여러 접근 방식을 탐색할 수 있습니다
* 거부된 플랜 시도는 Agent Mode 컨텍스트를 소비하지 않습니다
* 실행으로 전환할 때 깨끗한 상태에서 시작합니다
**컨텍스트 재설정:** 모드를 전환하면 새 작업 유형에 맞는 새로운 컨텍스트가 제공됩니다.
**명확화 질문은 분해 프로세스의 일부입니다.**
**질문하는 이유:**
* 모호한 요구 사항에 명확화가 필요함
* 여러 유효한 접근 방식이 있음(하나 선택)
* 엣지 케이스나 제약 조건이 아직 지정되지 않음
* 초기 요청만으로 선호를 알기 어려움
**응답 방법:**
* 대화형 언어로 직접 답합니다
* 도움이 된다면 예시를 제공합니다
* Verdent의 판단을 신뢰한다면 "네가 선택해"라고 말합니다
* 확신이 없으면 되묻습니다
**예시 대화:**
```
Verdent: "Should I modify the existing validation or create a new validator?"
You: "Create a new validator - we'll deprecate the old one later"
Verdent: [Updates plan with new validator approach]
```
**프로 팁:** 질문은 Verdent가 사용자의 구체적인 요구에 맞춘 정확하고 관련성 높은 플랜을 생성하는 데 도움이 됩니다.
***
## 함께 보기 [#함께-보기]
Plan Mode와 다른 실행 모드에 대해 자세히 알아보기
Plan Mode를 위한 효과적인 프롬프트 작성하기