Codex 프롬프트 작성법: 목표·맥락·경계·완료 기준으로 작업 품질 높이기 | DAKER 커뮤니티
Codex 프롬프트 구조의 핵심은 목표, 맥락, 경계, 완료 기준을 한 요청에 담아 작업 범위를 선명하게 만드는 것입니다. Codex 프롬프트 구조란, 코덱스가 무엇을 바꾸고 무엇을 유지하며 언제 끝낼지 판단하도록 주는 요청 설계입니다. 오늘 복잡한 작업을 맡긴다면 이 네 칸을 먼저 채워야 수정 결과를 더 빨리 검토할 수 있습니다.
한 줄 요약: 좋은 Codex 요청은 긴 명령문이 아니라 리뷰 가능한 작업 계약입니다.
문제 상황: 왜 Codex 요청은 짧을수록 흔들릴까요?
“이 코드 좀 개선해줘”라는 요청은 빠르게 시작할 수 있지만, 코덱스가 어떤 동작을 보존해야 하는지 알기 어렵습니다. 큰 저장소에서는 파일 구조, 테스트 명령, 금지할 변경, 완료 기준이 빠지면 결과가 맞아도 리뷰 비용이 커집니다. 이 글은 2026-07-18 KST 기준 OpenAI Codex 공식 매뉴얼의 Best practices와 Prompting 내용을 확인하고, DAKER 코덱스 최근 게시물과 겹치지 않도록 작성했습니다.
특히 팀 작업에서는 “잘 고쳐줘”보다 “어떤 증거가 나오면 끝인지”가 더 중요합니다. 완료 기준을 먼저 적으면 코덱스가 탐색, 수정, 테스트, 보고를 같은 방향으로 묶을 수 있습니다.
핵심 개념: Codex 프롬프트에는 무엇을 넣어야 할까요?
Codex 프롬프트 구조는 목표, 맥락, 경계, 완료 기준 네 요소로 나누면 가장 실용적입니다. 목표는 바뀌어야 할 결과이고, 맥락은 봐야 할 파일과 증거이며, 경계는 건드리면 안 되는 조건입니다. 완료 기준은 테스트 통과, 화면 확인, 재현 종료처럼 작업을 닫는 증거입니다.
| 요소 | 넣을 내용 | 좋은 예시 |
|---|---|---|
| 목표 | 바꾸거나 만들 결과를 한 문장으로 씁니다. | 결제 설정 저장 실패 원인을 찾고 저장 성공까지 고칩니다. |
| 맥락 | 파일, 화면, 로그, 최근 결정처럼 결과를 바꿀 정보를 줍니다. | 설정 화면과 저장 API, 실패 로그를 먼저 확인합니다. |
| 경계 | 유지할 동작, 권한, 문구, 데이터 형식을 명시합니다. | 응답 형식과 화면 문구는 바꾸지 않습니다. |
| 완료 기준 | 끝났다고 말할 수 있는 검증 증거를 적습니다. | 관련 테스트를 실행하고 실패 재현이 사라졌음을 보고합니다. |
단계별 사용법: 오늘 바로 어떻게 써볼까요?
- 첫 문장은 원하는 결과로 시작합니다. 구현 방법보다 바뀌어야 할 상태를 먼저 씁니다.
- 관련 파일, 화면, 오류 메시지, 이전 결정처럼 코덱스가 확인해야 할 맥락을 붙입니다.
- 바꾸면 안 되는 API 응답, 디자인, 권한, 데이터 마이그레이션 범위를 경계로 적습니다.
- 테스트, 타입 검사, 화면 확인, 재현 종료처럼 완료 기준을 명시합니다.
- 복잡한 작업이면 구현 전에 계획과 위험한 가정을 먼저 내라고 요청합니다.
- 수정 후에는 변경 파일, 실행한 검증, 남은 위험을 짧게 보고하게 합니다.
짧은 예시: 나쁜 요청과 좋은 요청은 어떻게 다를까요?
나쁜 요청은 “대시보드 느린 것 좀 고쳐줘”입니다. 느린 구간, 보존할 기능, 측정 기준이 없어서 조사와 수정 범위가 함께 흔들립니다.
좋은 요청은 “관리자 대시보드 첫 로딩이 느린 원인을 찾아 주세요. 차트 쿼리와 필터 컴포넌트를 먼저 확인하고, API 응답 형식과 화면 문구는 유지해 주세요. 구현 전 변경 계획과 위험한 가정을 정리한 뒤, 수정 후 관련 테스트와 로딩 확인 결과를 보고해 주세요”입니다.
이 예시는 코덱스에게 자유를 없애는 문장이 아닙니다. 오히려 어디서 판단해도 되는지와 어디서는 멈춰야 하는지를 알려 줍니다.
실수 방지 체크리스트: 요청 전에 무엇을 확인할까요?
- 목표가 기능 이름이 아니라 결과 상태로 쓰였는지 확인합니다.
- 코덱스가 봐야 할 파일이나 화면을 최소 1개 이상 제공했는지 확인합니다.
- 유지해야 할 계약을 경계로 적었는지 확인합니다.
- 테스트나 재현 종료처럼 완료 증거가 있는지 확인합니다.
- 외부 배포, 삭제, 권한 변경처럼 위험한 행동은 승인 단계로 분리했는지 확인합니다.
- 큰 작업은 바로 구현하지 말고 계획을 먼저 받도록 요청했는지 확인합니다.
공식 출처와 함께 볼 DAKER 글은 무엇인가요?
공식 확인은 OpenAI Codex 공식 매뉴얼의 Best practices와 Prompting 안내를 기준으로 했습니다. 공개 본문에는 DAKER 정책에 맞춰 DAKER와 DACON 도메인만 링크로 남깁니다.
FAQ: 자주 묻는 질문
Codex 프롬프트는 항상 길게 써야 하나요?
아닙니다. 작은 작업은 짧아도 됩니다. 다만 결과가 중요하거나 저장소가 크다면 목표, 맥락, 경계, 완료 기준 네 가지를 넣는 편이 안전합니다.
파일명을 모르면 어떻게 요청해야 하나요?
코덱스에게 먼저 관련 파일과 호출 흐름을 찾고 근거를 제시하라고 요청하면 됩니다. 파일을 모른다는 사실도 중요한 맥락입니다.
완료 기준은 테스트만 의미하나요?
테스트가 가장 좋은 증거인 경우가 많지만 전부는 아닙니다. 화면 렌더링, 로그 확인, 재현 종료, 문서 갱신도 작업에 맞는 완료 기준이 될 수 있습니다.
좋은 프롬프트와 AGENTS 파일은 어떻게 나눠야 하나요?
이번 한 번만 필요한 조건은 프롬프트에 두고, 매번 반복되는 팀 규칙은 AGENTS 파일 같은 저장소 지침으로 옮기면 좋습니다.
오늘 코덱스에게 맡길 작업이 있다면 첫 요청을 보내기 전에 목표, 맥락, 경계, 완료 기준 네 줄만 먼저 채워 보세요.