Codex 팁 – /goal 명령을 작업 계약으로 쓰는 방법

codex의 /goal은 긴 코딩 작업을 “한 번 답하고 끝나는 프롬프트”가 아니라 계속 추적되는 목표로 만드는 명령이다. 좋은 /goal은 할 일 설명보다 완료 조건(done state) 과 검증 방법을 명확히 적은 작업 계약에 가깝다.

좋은 /goal의 형태

단순히 /goal 이 앱 만들어줘라고 쓰면 여전히 모호하다. 에이전트가 언제 멈춰야 하는지, 어떤 변경이 허용되는지, 성공 여부를 무엇으로 확인할지 알 수 없다.

더 나은 형태는 다음과 같다.

/goal Build the app described in SPEC.md.
Done means tests pass, build passes, README is accurate,
and git status only shows relevant project files.

핵심은 “무엇을 만들라”보다 “완료란 무엇인가”를 적는 것이다.

요소	설명
스펙 파일	요구사항, 범위, 금지 사항을 `SPEC.md`에 고정한다
완료 조건	테스트, 빌드, 문서, git 상태처럼 관찰 가능한 조건을 쓴다
검증 명령	`npm test`, `npm run build`, `pytest` 등 실제 실행할 명령을 명시한다
변경 범위	어떤 파일·디렉터리를 수정할 수 있는지 제한한다
중단 조건	외부 API 키, 권한, 모호한 제품 판단 등 사람이 필요한 지점을 정한다

이 다섯 가지가 있으면 /goal은 긴 자율 실행 세션에서도 방향을 잃을 가능성이 줄어든다.

한 에이전트가 만든 결과를 같은 에이전트가 최종 판정하게 하면 자기 보고에 기대게 된다. 더 강한 패턴은 역할 분리다.

Codex를 구현 담당으로, Claude Code를 리뷰 담당으로, 별도 스크립트나 오케스트레이터를 검증 담당으로 두면 /goal은 단순 장시간 프롬프트보다 훨씬 신뢰할 수 있다.

여러 /goal을 동시에 돌릴 수는 있지만, 같은 파일을 여러 worker가 동시에 쓰게 하면 충돌과 부분 덮어쓰기가 쉽게 난다. 병렬화가 필요하면 파일 소유권을 나누거나, 각 접근을 별도 git worktree에서 실행한 뒤 비교하는 편이 낫다.

실무 기준은 간단하다.