Codex Plan mode 사용법: 모호한 작업을 구현 전 계획으로 바꾸는 법 | DAKER 커뮤니티
Codex Plan mode 사용법의 핵심은 구현 전에 목표, 맥락, 제약, 완료 기준을 검증 가능한 계획으로 바꾸는 것입니다. Plan mode란, Codex가 코드를 바로 고치기 전에 저장소 맥락을 읽고 질문과 실행 순서를 먼저 정리하는 작업 방식입니다. 지금 요구사항이 애매하다면 코드를 바로 고치기보다 계획부터 확인해야 나중에 되돌릴 일이 줄어듭니다.
Codex Plan mode는 언제 쓰면 좋을까요?
Codex Plan mode는 작업 범위가 넓거나, 어떤 파일을 건드려야 할지 아직 확실하지 않거나, 구현 전에 위험을 먼저 보고 싶을 때 유용합니다. 이 글은 2026년 7월 17일 KST에 OpenAI Codex 공식 매뉴얼과 DAKER 코덱스 최근 게시물을 확인한 기준으로 작성했습니다. 확인한 공식 내용은 공개 본문에 외부 링크로 노출하지 않고, 실무자가 바로 쓸 수 있는 요청 구조로 정리했습니다.
반대로 오타 수정, 단일 테스트 실패 수정, 이미 원인이 분명한 작은 변경은 바로 실행해도 충분합니다. Plan mode는 작업 속도를 늦추는 버튼이 아니라, 모호함이 큰 작업에서 구현 전 합의 비용을 줄이는 안전장치에 가깝습니다.
문제 상황: 왜 애매한 Codex 작업은 구현 전에 흔들릴까요?
“대시보드 느린 것 좀 고쳐줘”처럼 넓은 요청은 성능, 쿼리, UI, 캐시 중 어디까지 손댈지 모호합니다. Codex가 저장소를 잘 읽어도 사용자가 기대한 범위와 실제 변경 범위가 달라질 수 있고, 검증 기준 없이 변경만 쌓이면 리뷰가 어려워집니다.
Plan mode에서는 먼저 관련 파일과 현재 동작을 확인하고, 열린 질문과 실행 순서를 분리합니다. “첫 로딩 병목을 찾되, 기존 필터 UI와 API 응답 형식은 유지하고, 측정 방법을 계획에 포함한다”처럼 말하면 구현 전에 기준점이 생깁니다.
핵심 개념: 좋은 Plan mode 요청은 무엇을 포함하나요?
| 요소 | 넣을 내용 | 실무 예시 |
|---|---|---|
| 목표 | 해결하려는 문제와 기대 결과 | 관리자 대시보드 첫 로딩 병목을 줄입니다. |
| 맥락 | 관련 파일, 에러, 화면, 기존 결정 | 최근 변경된 차트 쿼리와 필터 컴포넌트를 봅니다. |
| 제약 | 바꾸면 안 되는 계약과 경계 | API 응답 형식과 화면 문구는 유지합니다. |
| 완료 기준 | 구현 전 확인할 계획과 구현 후 검증 | 실행 순서, 위험, 테스트 기준을 먼저 제시합니다. |
단계별 사용법: Plan mode를 어떻게 시작하면 좋을까요?
- 처음 한 문장에 목표를 씁니다. “무엇을 만들지”보다 “무엇이 좋아져야 하는지”를 먼저 둡니다.
- 관련 파일, 화면, 에러 로그, 기존 DAKER 글처럼 Codex가 봐야 할 맥락을 지정합니다.
- 바꾸면 안 되는 API, 데이터, 문구, 권한 경계를 제약으로 적습니다.
- Codex에게 구현 전에 계획, 열린 질문, 위험한 가정, 검증 방법을 먼저 내라고 요청합니다.
- 계획을 보고 범위가 맞으면 구현을 이어가고, 맞지 않으면 같은 작업에서 계획만 수정합니다.
짧은 예시: 나쁜 요청과 좋은 Plan mode 요청은 어떻게 다를까요?
나쁜 요청은 “리팩터링해줘”입니다. 범위, 보존할 동작, 검증 기준이 없어서 Codex가 어디까지 조사하고 어디부터 구현해야 하는지 판단하기 어렵습니다.
좋은 요청은 “결제 설정 화면의 중복 상태 관리를 줄이는 계획을 먼저 세워 주세요. 기존 저장 API와 화면 문구는 유지하고, 관련 파일, 위험한 가정, 테스트 기준을 계획에 포함해 주세요”입니다. 이 문장은 구현 전 검토에 필요한 목표, 맥락, 제약, 완료 기준을 한 번에 줍니다.
실수 방지 체크리스트: 시작 전에 무엇을 확인할까요?
- 계획만 필요한 단계인지, 바로 구현까지 이어갈 단계인지 먼저 구분합니다.
- 관련 파일이나 화면을 지정하지 못했다면 Codex가 먼저 찾고 근거를 제시하게 합니다.
- 팀이 보존해야 할 API, 데이터, UI, 권한 경계를 제약으로 적습니다.
- 질문이 남아 있는데도 구현으로 넘어가면 안 되는 지점을 정합니다.
- 계획의 마지막에는 실행 순서, 검증 방법, 남은 위험이 함께 있어야 합니다.
공식 출처와 함께 볼 DAKER 글은 무엇인가요?
공식 확인은 OpenAI Codex 공식 매뉴얼의 Best practices와 Prompting 안내를 기준으로 했습니다. 공개 링크는 DAKER 정책에 맞춰 DAKER와 DACON 도메인만 남깁니다.
자주 묻는 질문
Plan mode는 구현을 막는 기능인가요?
아닙니다. 구현 전에 범위와 순서를 확인하는 단계입니다. 계획이 맞으면 같은 작업에서 바로 구현으로 이어갈 수 있습니다.
Plan mode 요청은 얼마나 길어야 하나요?
목표, 맥락, 제약, 완료 기준 네 가지가 들어가면 충분합니다. 긴 배경보다 바꾸면 안 되는 조건과 확인 방법이 더 중요합니다.
모호한 요구사항은 Codex에게 질문부터 시켜도 되나요?
좋습니다. 공식 권장 흐름에서도 애매한 아이디어는 Codex가 질문을 통해 더 구체적인 작업으로 바꾸는 방식이 유용합니다.
계획을 받은 뒤 바로 구현해도 되나요?
계획의 범위, 위험, 검증 기준이 맞다면 바로 이어가도 됩니다. 계획이 넓거나 위험하면 범위를 줄인 뒤 구현하는 편이 안전합니다.
오늘 애매한 Codex 작업을 시작한다면 첫 요청에 목표, 맥락, 제약, 완료 기준을 넣고 구현 전 계획부터 받아 보세요.