Codex /goal 사용법: 긴 작업을 멈추지 않게 맡기는 법 | DAKER 커뮤니티
Codex /goal은 마이그레이션, 대형 리팩터링, 배포 재시도처럼 한 번의 답변으로 끝나지 않는 작업에 목표, 검증 명령, 중단 조건을 묶어 주는 장기 실행 루프입니다. 작성 기준일 공식 문서는 /goal을 명확한 성공 조건과 validation loop가 있는 long-running work에 쓰고, 목표 조회·수정·일시정지·재개·clear 흐름을 설명합니다. 지금 큰 작업이 중간 보고에서 자꾸 끊긴다면, 먼저 끝낼 조건을 한 줄로 잠가야 합니다.
Codex /goal이란, 하나의 긴 작업 목표와 검증 가능한 종료 조건을 active chat에 붙여 Codex가 여러 턴 동안 계속 진행하게 하는 명령입니다.
문제 상황: 왜 긴 작업은 중간에 흐려질까요?
마이그레이션 보드에는 할 일이 남아 있고, 테스트 로그에는 아직 실패가 남아 있습니다. 그런데 매번 새 요청으로 이어 가면 어디서 멈춰야 하는지, 무엇을 검증해야 하는지 대화 속에서 흐려집니다. 작성 기준일 현재 OpenAI 공식 공개 문서 3개와 DAKER 코덱스 디렉터리 최신 목록을 비공개로 확인했습니다. 공개 본문에는 DAKER 정책에 맞춰 내부 링크만 남깁니다.
핵심 개념: Codex /goal은 무엇을 붙잡아 두나요?
Codex /goal은 마이그레이션, 대형 리팩터링, 배포 재시도처럼 한 번의 답변으로 끝나지 않는 작업에 목표, 검증 명령, 중단 조건을 묶어 주는 장기 실행 루프입니다. 핵심은 “계속 해 줘”가 아니라 목표, 검증 방식, 멈출 조건을 하나의 계약으로 남기는 것입니다. 그래야 Codex가 다음 checkpoint로 넘어가도 작업의 경계와 성공 기준을 잃지 않습니다.
단계별 사용법: /goal은 어떻게 시작하면 좋을까요?
아래 순서는 긴 리팩터링, 마이그레이션, 반복 검증 작업을 맡기기 전의 최소 점검입니다.
- 먼저 하나의 objective를 쓰고, “끝났다”고 말할 수 있는 stopping condition을 같은 문장에 붙입니다.
- Codex가 먼저 읽어야 할 파일, 이슈, 로그, 계획 문서를 경로와 함께 지정합니다.
- 진행을 증명할 테스트 명령, 빌드 명령, 스크린샷, 보고서 같은 검증 산출물을 정합니다.
- 작업을 checkpoint로 나누고, 각 checkpoint 뒤에 짧은 progress log를 남기게 합니다.
- 목표가 바뀌면 새 지시를 덧붙이기보다 /goal edit, pause, resume, clear 중 맞는 제어를 선택합니다.
짧은 예시: 좋은 goal 문장은 어떤 모양인가요?
예를 들어 결제 모듈 리팩터링을 맡긴다면 “테스트가 모두 통과하고 기존 결제 플로가 유지될 때까지 진행하라”처럼 목표와 종료 조건을 함께 씁니다. 그다음 먼저 읽을 파일, 돌릴 테스트, 건드리면 안 되는 공개 API를 붙입니다. 이렇게 쓰면 중간에 새 아이디어가 생겨도 현재 goal이 무엇을 끝내야 하는지 흔들리지 않습니다.
| 구분 | 일반 요청으로 맡길 때 | /goal로 맡길 때 |
|---|---|---|
| 시간 | 한 턴이 끝나면 다시 방향을 줘야 합니다 | 목표가 유지되어 다음 checkpoint로 이어집니다 |
| 검증 | 테스트를 돌릴지 매번 흔들릴 수 있습니다 | 성공 조건과 검증 명령을 목표에 묶습니다 |
| 범위 | 중간 요구가 늘어나며 작업이 퍼질 수 있습니다 | objective와 stopping condition으로 범위를 좁힙니다 |
| 상태 | 현재 어디까지 왔는지 대화 속에서 찾아야 합니다 | /goal 조회와 progress log로 상태를 확인합니다 |
워크플로 이미지: goal 작업은 어떤 순서로 이어지나요?
큰 리팩터링 계획서 옆에 아직 끝나지 않은 테스트 실패 목록이 놓여 있습니다. 다음 checkpoint로 넘어가기 전 실패 원인과 남은 범위가 보드에 갱신됩니다. 이 장면의 차이는 더 오래 일하게 만드는 것보다, 끝났다고 말할 수 있는 증거를 남기는 데 있습니다.
- 큰 리팩터링 계획서 옆에 아직 끝나지 않은 테스트 실패 목록이 놓여 있습니다.
- /goal 카드에는 objective, stopping condition, 검증 명령이 굵게 고정됩니다.
- Codex가 첫 checkpoint를 끝내고 테스트 로그와 변경 파일을 짧게 기록합니다.
- 다음 checkpoint로 넘어가기 전 실패 원인과 남은 범위가 보드에 갱신됩니다.
- 마지막 컷에서 목표가 완료되거나 차단 조건에 걸려 멈추고, 사람이 다음 판단을 합니다.
실수 방지 체크리스트: 어디서 가장 자주 막히나요?
goal은 길게 유지되기 때문에 작은 범위 혼동이 여러 checkpoint로 번집니다. 특히 완료 조건, 수정 금지 범위, 차단 조건은 처음에 구체적으로 적는 편이 좋습니다.
- 목표가 여러 작업의 느슨한 목록으로 퍼져 있지 않나요?
- 완료 조건이 “좋게 만들어 줘”처럼 검증할 수 없는 말로 끝나지 않나요?
- 수정 금지 범위와 롤백 기준을 빼먹지 않았나요?
- 중간 상태를 확인할 명령이나 파일을 지정했나요?
- 막혔을 때 계속 추측하지 말고 멈춰야 하는 조건을 적었나요?
공식 출처와 내부 링크: 어디서 더 확인하면 좋을까요?
기능 사실은 작성 기준일에 OpenAI 공식 공개 문서로 비공개 검증했습니다. 공개 본문에는 DAKER 정책에 맞춰 DAKER 내부 링크만 남깁니다.
FAQ: Codex /goal을 쓸 때 자주 묻는 질문은 무엇인가요?
Codex /goal은 일반 프롬프트와 무엇이 다른가요?
일반 프롬프트는 한 번의 응답을 목표로 하지만, /goal은 active chat에 장기 objective를 붙여 여러 checkpoint 동안 유지하게 합니다.
/goal을 쓰면 언제 멈추나요?
목표가 검증 가능한 종료 조건에 도달했거나, 차단 조건이 반복되어 더 진행할 근거가 없을 때 멈춰야 합니다.
좋은 /goal 문장에는 무엇이 들어가나요?
objective, stopping condition, 먼저 읽을 자료, 검증 명령, 수정 금지 범위가 들어가야 합니다.
/goal이 보이지 않으면 어떻게 하나요?
공식 문서 기준으로 goals 기능을 설정에서 켜거나 CLI 기능 활성화 명령을 사용할 수 있습니다. 팀 환경에서는 먼저 설정 권한을 확인하세요.
오늘 바로 적용할 최소 루틴은 무엇인가요?
작업 목표 한 문장, 완료 조건 한 문장, 검증 명령 한 줄, 멈춤 조건 한 줄을 쓰고 작은 리팩터링에 먼저 적용해 보세요.
다음 긴 작업을 맡길 때는 objective, stopping condition, 검증 명령, 멈춤 조건을 먼저 적고 Codex /goal이 어디까지 이어 가야 하는지 분명히 남겨 보세요.