21장. Plan First — 바로 구현시키지 않는다
Task가 준비됐다.
이제 바로 구현시키고 싶어진다.
Agent는 몇 분이면 코드를 내놓는다.
그런데 그 몇 분이 가장 비싼 몇 분이 될 수 있다.
실패 비용은 뒤로 갈수록 커진다
방향이 틀렸을 때 되돌리는 비용이다.
flowchart LR
A[계획 단계<br/>1분] --> B[구현 직후<br/>20분]
B --> C[리뷰 단계<br/>1시간]
C --> D[배포 후<br/>???]
Agent가 생기면서 이 곡선이 더 가팔라졌다.
사람은 방향이 이상하면 중간에 멈춘다.
Agent는 멈추지 않는다.
⚠️ 틀린 방향으로 300줄을 완주한다.
그리고 그 300줄은 그럴듯하다.
테스트도 통과한다. 틀린 것을 정확히 구현했기 때문이다.
계획 단계의 1분이
뒤의 한 시간을 산다.
계획 모드를 쓴다
7장에서 본 그 모드다.
Shift+Tab 으로 들어가면 읽기만 한다.
@tasks/PAY-2841.md 의 작업을 하려고 해.
먼저 현재 코드가 어떻게 되어 있는지 확인하고
수정 계획을 세워줘. 코드는 수정하지 마.
계획 모드는 “수정하지 마” 를 잊어버릴 수 없게 만든다.
문장이 아니라 조건이다.
4장에서 본 차이가 여기서 실용적으로 쓰인다.
좋은 계획의 다섯 요소
## 1. 현재 구조
PaymentService.pay()
→ PgClient.request() (RestTemplate, 타임아웃 3초)
→ 실패 시 PaymentFailedException 던짐
→ PaymentController에서 500 응답
## 2. 근거
- PgClient.kt:44 에서 예외를 그대로 전파
- 재시도 로직 없음 (grep "Retry" 결과 0건)
- 멱등키는 이미 있음 (PaymentRequest.idempotencyKey)
## 3. 변경 계획
- PgClient.request() 에 @Retryable 적용 (3회, 지수 백오프)
- 재시도 대상 예외를 PgTimeoutException, PgServerException 으로 한정
- PaymentEntity 에 retryCount 컬럼 추가 (마이그레이션 V32)
## 4. 영향 범위
- 결제 요청 경로 전체
- 결제 취소는 별도 클라이언트라 영향 없음
- 배치 정산은 PgClient를 공유함 ← 확인 필요
## 5. 검증 방법
- PG 타임아웃 mock 테스트 3건
- 멱등성 테스트 1건
- 기존 결제 테스트 24건 회귀
이 다섯 개가 다 있어야 검토가 가능하다.
특히 2번과 4번이 없는 계획은 검토할 수 없다.
근거 없이 “이렇게 하겠습니다” 만 있는 셈이다.
승인 전에 물어볼 세 가지
계획을 그냥 승인하면 Plan First의 절반만 쓰는 것이다.
1️⃣ 근거를 요구한다
"재시도 로직이 없다" 는 어떻게 확인했어?
검색한 명령과 결과를 보여줘.
Agent가 코드를 확인하고 말한 것인지,
일반적인 지식으로 말한 것인지 여기서 갈린다.
2️⃣ 영향 범위를 도전한다
PgClient를 쓰는 곳을 전부 찾아줘.
배치 정산 말고 다른 호출자는 없어?
계획서의 “확인 필요” 는 대개 진짜 확인이 필요하다.
3️⃣ 대안을 물어본다
@Retryable 말고 다른 방법도 있어?
각각의 단점은?
대안을 물으면 두 가지를 얻는다.
- Agent가 첫 번째 아이디어에 고착됐는지 알 수 있다
- 우리가 몰랐던 선택지를 본다
그럴듯한데 틀린 계획
가장 위험한 유형이다.
세 가지 냄새로 구별할 수 있다.
| 냄새 | 무슨 뜻인가 |
|---|---|
| 파일명과 줄 번호가 없다 | 코드를 확인하지 않았다 |
| 일반론이 섞여 있다 | “일반적으로 이런 경우에는…” |
| 우리 코드에 없는 클래스가 등장한다 | 관행에서 유추했다 |
# ❌ 확인 안 한 계획
PaymentRetryConfig 에 재시도 정책을 정의하고
RetryTemplate 을 주입받아 처리합니다
# ✅ 확인한 계획
PgClient.kt:44 의 request() 에 @Retryable 을 붙입니다
(RetryConfig 는 없어서 새로 만들어야 합니다)
🔥 계획서에서 파일 경로와 줄 번호를 요구하는 습관 하나가
이 문제의 대부분을 걸러낸다.
언제 생략해도 되는가
모든 작업에 계획이 필요한 것은 아니다.
| 생략 가능 | 계획 필수 |
|---|---|
| 오타·문구 수정 | 여러 파일이 바뀌는 작업 |
| 테스트 하나 추가 | 데이터 변경·마이그레이션 |
| 로그 한 줄 추가 | 외부 시스템 연동 |
| 이미 계획한 작업의 다음 단계 | 원인이 불명확한 버그 |
기준은 되돌리기 비용이다.
git checkout 한 번으로 끝나면 생략해도 된다.
마이그레이션이 끼면 예외 없이 계획한다.
계획은 문서로 남긴다
승인한 계획은 대화 안에만 두지 않는다.
19장의 원칙 그대로다.
이 계획을 tasks/PAY-2841.md 의 "결정된 사항" 에 추가해줘.
그 다음 계획 모드를 벗어나서 구현을 시작하자.
이렇게 하면 세 가지가 가능해진다.
- 세션이 끊겨도 계획이 살아남는다
- 구현 중에 계획과 어긋나면 대조할 수 있다
- Review 세션에서 “계획대로 됐는지” 를 볼 수 있다
세 번째가 특히 강력하다.
Review의 기준이 “잘 짰는가” 가 아니라
“합의한 대로 됐는가” 가 된다.
이 장의 핵심
- 방향이 틀렸을 때의 비용은 뒤로 갈수록 가파르게 커진다
- 사람은 이상하면 멈추지만 Agent는 틀린 방향으로 완주한다
- 틀린 것을 정확히 구현한 코드는 테스트도 통과한다
- 계획 모드는 “수정하지 마” 를 문장이 아니라 조건으로 만든다
- 좋은 계획에는 현재 구조 · 근거 · 변경 계획 · 영향 범위 · 검증 방법이 있다
- 승인 전에 근거를 요구하고, 영향 범위를 도전하고, 대안을 묻는다
- 파일 경로와 줄 번호가 없는 계획은 코드를 확인하지 않은 계획이다
- 되돌리기 비용이 크면 계획하고,
git checkout으로 끝나면 생략해도 된다 - 승인한 계획을 문서로 남기면 Review 기준이 “합의한 대로 됐는가” 가 된다