기본 패턴
text
/plan
목표:
- 인증 모듈 리팩터링
계획에 꼭 포함할 것:
- 단계별 파일 이동 범위
- 각 단계의 검증 방법
- 롤백 전략
- 사용자 영향이 없는지 확인하는 기준설명
- 큰 리팩터링, 마이그레이션, 아키텍처 변경은 바로 구현을 시키기보다 먼저 계획을 분리하는 것이 공식 가이드의 기본 권장 흐름입니다.
/plan을 쓰거나, 먼저 질문으로 요구사항을 인터뷰하게 만들면 불명확한 부분을 구현 전에 드러낼 수 있습니다.- 좋은 계획은 "무슨 파일을 어느 단계에서 바꾸는가", "각 단계가 끝났는지 무엇으로 판단하는가", "실패하면 어디까지 되돌릴 수 있는가"를 포함합니다.
- 마일스톤이 너무 크면 한 번의 diff가 읽기 어려워지고, 너무 작으면 흐름이 끊깁니다. 보통 검증 가능한 단위로 나누는 것이 좋습니다.
- Definition of Done은 마지막 한 줄 체크리스트가 아니라, 각 단계마다 통과 기준을 미리 적어 두는 방식이 더 안정적입니다.
짧은 예제
text
계획 요청 예시
- 먼저 3단계 계획만 제시해라.
- 각 단계마다 수정 파일과 검증 명령을 적어라.
- 공개 API를 건드리는 단계가 있으면 따로 표시해라.
- 마지막에 "이 단계가 실패하면 어디까지 되돌리면 되는가"를 적어라.빠른 정리
| 계획 요소 | 왜 필요한가 |
|---|---|
| 단계 구분 | 큰 작업을 검토 가능한 diff로 나눕니다. |
| 파일 범위 | 영향 면적을 미리 읽을 수 있습니다. |
| 검증 방법 | 각 단계 종료 판단이 쉬워집니다. |
| 롤백 전략 | 실패 비용을 낮춥니다. |
| Definition of Done | 중간 산출물을 최종 완료로 착각하지 않게 합니다. |
주의할 점
계획 없이 큰 작업을 한 번에 맡기면, Codex가 충분히 유능해도 검토 난이도가 급격히 올라갑니다. 구현 능력보다 검토 가능성을 먼저 설계하는 편이 실제 성공률이 높습니다.
참고 링크
3 sources