Codex Goal mode로 긴 작업의 완료 기준을 분명하게 잡는 법 | DAKER 커뮤니티
긴 개발 작업을 Codex에 맡길 때 가장 자주 흐려지는 것은 무엇을 바꿀지가 아니라 어디까지 끝나야 완료인지입니다. 요청은 분명히 했다고 생각해도, 막상 작업이 길어지면 범위와 검증 기준이 흔들리기 쉽습니다.
Codex Goal mode는 이런 지점을 정리하는 데 도움이 됩니다. 핵심은 결과, 제약, 검증 기준을 하나의 목표에 묶어 두고, Codex가 그 기준으로 진행 상황과 완료 여부를 추적하게 만드는 데 있습니다.
긴 작업을 맡길수록 무엇을 해달라는 요청보다 어떤 상태가 되면 끝인지 먼저 써야 합니다.
Codex Goal mode는 언제 유용할까요?
Codex Goal mode는 여러 단계의 파일 탐색, 수정, 테스트, 보고가 함께 필요한 작업에서 특히 유용합니다. 작업 목표가 길어질수록 완료 기준이 흐려지기 쉬우므로, 처음부터 결과와 제약과 검증을 한 문장에 묶어 두는 것이 좋습니다.
짧은 질문이나 단일 파일 수정은 일반 작업으로도 충분합니다. 반대로 여러 날 이어질 수 있거나, 중간에 상태 확인이 자주 필요한 작업은 Goal mode로 시작하면 진행 상황과 완료 판단을 같은 기준으로 유지하기 쉽습니다.
이 글은 2026년 7월 16일 KST에 OpenAI Codex manual과 DAKER 코덱스 최근 게시물을 확인한 기준으로 작성했습니다.
긴 Codex 작업은 왜 중간에 흐려질까요?
예를 들어 대시보드 느린 것 좀 고쳐줘 같은 요청은 얼핏 간단해 보여도 실제로는 범위가 넓습니다. 성능 문제를 쿼리에서 봐야 하는지, UI에서 봐야 하는지, 캐시까지 손대야 하는지 기준이 없습니다.
이런 상태에서는 Codex가 많은 변경을 해도 사용자가 다시 결과를 판단해야 합니다. 검증 기준이 없으면 변경만 쌓이고, 무엇이 충분한 수정인지도 모호해집니다.
그래서 긴 작업에서는 목표를 활동이 아니라 완료 상태로 써야 합니다. 첫 로딩을 2초 안으로 줄이고, 기존 필터 동작을 유지하며, 빌드와 관련 테스트 결과를 보고한다처럼 끝 상태를 정해 두면 Codex가 다음 행동을 고르는 기준이 생깁니다.
긴 작업에서는 무엇을 할지가 아니라 어떤 상태가 되면 끝인지가 목표가 되어야 합니다.
좋은 Goal 문장은 무엇을 포함할까요?
| 요소 | 넣을 내용 | 실무 예시 |
|---|---|---|
| 결과 | 완료 후 달라져야 할 상태 | 로그인 실패 원인을 수정하고 성공 흐름은 유지합니다. |
| 제약 | 바꾸면 안 되는 계약과 경계 | 인증 API 형식과 기존 UI 문구는 바꾸지 않습니다. |
| 검증 | 완료를 증명할 테스트와 확인법 | 성공과 실패 테스트를 실행하고 결과를 보고합니다. |
이 세 가지가 함께 들어가면 Goal 문장은 장기 작업의 기준점이 됩니다. 배경 설명이 길지 않아도, 결과와 제약과 검증이 분명하면 Codex가 작업 방향을 유지하기 쉬워집니다.
Goal은 어떻게 시작하면 좋을까요?
먼저 결과를 수행할 일이 아니라 완료된 상태로 적는 것이 좋습니다. 그다음 보존해야 할 API, 데이터, UI, 권한 경계를 함께 적고, 마지막으로 테스트나 빌드, 타입체크, 화면 확인, API 응답처럼 완료를 증명할 수 있는 기준을 붙이면 됩니다.
관련 작업은 같은 task에서 이어가고, 독립적인 작업은 별도 task로 나누는 편이 좋습니다. 같은 파일을 동시에 바꿀 가능성이 있는 병렬 작업은 worktree나 별도 작업 공간으로 분리하면 충돌을 줄이기 쉽습니다.
나쁜 요청과 좋은 Goal은 어떻게 다를까요?
리팩터링해줘 같은 요청은 범위가 넓고 기준이 없습니다. 무엇을 얼마나 바꿔야 하는지, 어떤 동작은 유지해야 하는지, 완료를 어떻게 확인할지 빠져 있기 때문에 Codex가 어디까지 손대도 되는지 판단하기 어렵습니다.
반대로 결제 설정 화면의 중복 상태 관리를 줄여 주세요. 기존 저장 API와 화면 문구는 유지하고, 관련 단위 테스트와 타입체크를 실행해 결과를 보고해 주세요 같은 요청은 다릅니다. 결과, 제약, 검증이 한 문장 안에 함께 들어 있어 장기 작업의 기준으로 쓰기 좋습니다.
좋은 Goal은 결과와 제약과 검증이 한 번에 보이는 문장입니다.
시작 전에 확인할 점
- 목표가 무엇을 할지보다 어떤 상태가 되어야 하는지로 쓰였는지 봅니다.
- 보존해야 할 API, 데이터, UI, 권한 경계를 적어 둡니다.
- 테스트가 없다면 빌드, 타입체크, 화면 확인처럼 가능한 검증 기준을 넣으면 됩니다.
- 중간 조건이 바뀌면 새 목표를 덧붙이기보다 현재 목표의 제약을 분명하게 갱신하는 편이 좋습니다.
- 완료 보고에는 변경 파일, 실행한 검증, 남은 위험을 함께 남기게 하면 됩니다.
함께 볼 자료
공식 확인은 OpenAI Codex manual의 Long-running work, Goal mode, prompting, worktrees 안내를 기준으로 했습니다.
관련해서 DAKER 글도 함께 보면 흐름을 잡는 데 도움이 됩니다.
자주 묻는 질문
Goal mode는 Scheduled Tasks와 같은 기능인가요?
아닙니다. Scheduled Tasks는 정해진 시간에 반복 실행하는 방식이고, Goal mode는 현재 작업을 하나의 장기 목표로 추적하는 방식입니다.
Goal 문장에는 얼마나 자세히 써야 하나요?
결과, 제약, 검증 세 가지가 들어가면 충분합니다. 긴 배경 설명보다 완료 기준이 더 중요합니다.
작업 중에 조건이 바뀌면 새로 시작해야 하나요?
같은 맥락을 유지해야 한다면 같은 task에서 조건을 갱신하는 편이 좋습니다. 독립 실험이나 충돌 위험이 있는 변경은 별도 task나 worktree로 나누는 것이 좋습니다.
테스트가 없는 저장소에서도 Goal mode가 유용한가요?
유용합니다. 테스트가 없다면 빌드, 타입체크, 화면 확인, API 응답 확인처럼 지금 가능한 검증 기준을 Goal에 넣으면 됩니다.
오늘 긴 Codex 작업을 맡기기 전에 결과, 제약, 검증을 한 문장으로 묶는다면 어떤 표현이 가장 먼저 떠오르시나요?