Codex /goal 사용법: 긴 작업을 끝까지 이어 가는 기준 세우기 | DAKER 커뮤니티

마이그레이션이나 대형 리팩터링처럼 한 번의 답변으로 끝나지 않는 작업은, 중간에 방향이 흐려지기 쉽습니다. 테스트는 아직 실패하고 있는데 대화는 다음 아이디어로 넘어가고, 어디까지가 이번 작업의 범위였는지 다시 찾아야 하는 순간도 자주 생깁니다.

이럴 때 필요한 것은 더 긴 지시가 아니라, 끝났다고 말할 수 있는 기준입니다. Codex /goal은 목표와 검증 방식, 멈출 조건을 함께 묶어 여러 턴에 걸친 작업을 이어 가게 하는 명령입니다.

긴 작업이 끊기는 이유는 대개 더 많은 설명이 부족해서가 아니라, 완료 기준이 고정되지 않았기 때문입니다.

Codex /goal이란, 하나의 긴 작업 목표와 검증 가능한 종료 조건을 active chat에 붙여 Codex가 여러 턴 동안 계속 진행하게 하는 명령입니다.

왜 긴 작업은 중간에 흐려질까요?

마이그레이션 보드에는 할 일이 남아 있고, 테스트 로그에는 아직 실패가 남아 있습니다. 그런데 매번 새 요청으로 이어 가면 어디서 멈춰야 하는지, 무엇을 검증해야 하는지 대화 속에서 흐려집니다.

그래서 긴 작업일수록 목표를 한 줄로 잠가 두는 방식이 중요합니다. 작성 기준일 공식 문서는 /goal을 명확한 성공 조건과 validation loop가 있는 long-running work에 쓰고, 목표 조회·수정·일시정지·재개·clear 흐름을 설명합니다.

Codex /goal은 무엇을 붙잡아 두나요?

Codex /goal은 마이그레이션, 대형 리팩터링, 배포 재시도처럼 한 번의 답변으로 끝나지 않는 작업에 목표, 검증 명령, 중단 조건을 묶어 주는 장기 실행 루프입니다.

핵심은 계속 해 달라는 요청이 아니라 목표, 검증 방식, 멈출 조건을 하나의 계약으로 남기는 데 있습니다.

이렇게 해 두면 Codex가 다음 checkpoint로 넘어가도 작업의 경계와 성공 기준을 잃지 않습니다. 일반 요청은 한 턴이 끝날 때마다 다시 방향을 잡아야 하지만, /goal은 active chat 안에서 장기 objective를 유지한다는 점이 다릅니다.

/goal은 어떻게 시작하면 좋을까요?

긴 리팩터링, 마이그레이션, 반복 검증 작업을 맡기기 전에는 최소한의 기준을 먼저 정리해 두는 것이 좋습니다.

1. 먼저 하나의 objective를 쓰고, 끝났다고 말할 수 있는 stopping condition을 같은 문장에 붙입니다.
2. Codex가 먼저 읽어야 할 파일, 이슈, 로그, 계획 문서를 경로와 함께 지정합니다.
3. 진행을 증명할 테스트 명령, 빌드 명령, 스크린샷, 보고서 같은 검증 산출물을 정합니다.
4. 작업을 checkpoint로 나누고, 각 checkpoint 뒤에 짧은 progress log를 남기게 합니다.
5. 목표가 바뀌면 새 지시를 덧붙이기보다 /goal edit, pause, resume, clear 중 맞는 제어를 선택합니다.

좋은 goal 문장은 어떤 모양인가요?

예를 들어 결제 모듈 리팩터링을 맡긴다면 테스트가 모두 통과하고 기존 결제 플로가 유지될 때까지 진행하라처럼 목표와 종료 조건을 함께 씁니다. 그다음 먼저 읽을 파일, 돌릴 테스트, 건드리면 안 되는 공개 API를 붙이면 됩니다.

이렇게 쓰면 중간에 새 아이디어가 생겨도 현재 goal이 무엇을 끝내야 하는지 흔들리지 않습니다.

goal 작업은 어떤 순서로 이어지나요?

큰 리팩터링 계획서 옆에 아직 끝나지 않은 테스트 실패 목록이 놓여 있습니다. 다음 checkpoint로 넘어가기 전 실패 원인과 남은 범위가 보드에 갱신됩니다. 여기서 중요한 차이는 더 오래 일하게 만드는 것이 아니라, 끝났다고 말할 수 있는 증거를 남기는 데 있습니다.

1. 큰 리팩터링 계획서 옆에 아직 끝나지 않은 테스트 실패 목록이 놓여 있습니다.
2. /goal 카드에는 objective, stopping condition, 검증 명령이 굵게 고정됩니다.
3. Codex가 첫 checkpoint를 끝내고 테스트 로그와 변경 파일을 짧게 기록합니다.
4. 다음 checkpoint로 넘어가기 전 실패 원인과 남은 범위가 보드에 갱신됩니다.
5. 마지막에는 목표가 완료되거나 차단 조건에 걸려 멈추고, 사람이 다음 판단을 합니다.

어디서 가장 자주 막히나요?

goal은 길게 유지되기 때문에 작은 범위 혼동도 여러 checkpoint로 번지기 쉽습니다. 특히 완료 조건, 수정 금지 범위, 차단 조건은 처음에 구체적으로 적는 편이 좋습니다.

• 목표가 여러 작업의 느슨한 목록으로 퍼져 있지 않은지 봅니다.
• 완료 조건이 좋게 만들어 줘처럼 검증할 수 없는 말로 끝나지 않는지 확인합니다.
• 수정 금지 범위와 롤백 기준을 빼먹지 않는 것이 좋습니다.
• 중간 상태를 확인할 명령이나 파일을 지정해 두면 도움이 됩니다.
• 막혔을 때 계속 추측하지 말고 멈춰야 하는 조건을 적어 두는 편이 좋습니다.

좋은 /goal은 오래 일하게 만드는 장치가 아니라, 어디서 멈추고 무엇으로 완료를 증명할지 미리 정해 두는 장치입니다.

자주 묻는 질문

Codex /goal은 일반 프롬프트와 무엇이 다른가요?

일반 프롬프트는 한 번의 응답을 목표로 하지만, /goal은 active chat에 장기 objective를 붙여 여러 checkpoint 동안 유지하게 합니다.

/goal을 쓰면 언제 멈추나요?

목표가 검증 가능한 종료 조건에 도달했거나, 차단 조건이 반복되어 더 진행할 근거가 없을 때 멈춥니다.

좋은 /goal 문장에는 무엇이 들어가나요?

objective, stopping condition, 먼저 읽을 자료, 검증 명령, 수정 금지 범위가 들어가야 합니다.

/goal이 보이지 않으면 어떻게 하나요?

공식 문서 기준으로 goals 기능을 설정에서 켜거나 CLI 기능 활성화 명령을 사용할 수 있습니다. 팀 환경에서는 먼저 설정 권한을 확인하는 것이 좋습니다.

오늘 바로 적용할 최소 루틴은 무엇인가요?

작업 목표 한 문장, 완료 조건 한 문장, 검증 명령 한 줄, 멈춤 조건 한 줄을 쓰고 작은 리팩터링에 먼저 적용해 보면 됩니다.

참고 자료

• DAKER 코덱스 디렉터리
• Codex /status 사용법
• Codex exec 파이프 사용법
• Codex 도구 사용법 읽기 수정 검증 루프

다음 긴 작업을 맡길 때, 어떤 완료 조건을 먼저 적어 두면 가장 도움이 될지 궁금합니다.