코덱스 Goal 모드 주의사항: 오래 돌려도 핵심을 놓치는 이유

Codex Goal 모드는 에이전트를 오래 일하게 만드는 버튼이 아닙니다. 검증 가능한 종료 상태를 붙들게 하는 장치입니다. 문제는 에이전트가 “가장 중요한 다음 일”과 “지금 눈앞에서 계속 고칠 수 있는 일”을 자동으로 구분해 주지는 않는다는 데 있습니다.

실제 개발자들의 실행 기록을 보면 실패 패턴은 비슷했습니다. 원래 기능보다 희귀 테스트에 매달리고, 코드는 쓰지 않은 채 계획을 늘리고, 같은 가설에 수정을 계속 덧댔습니다. 반대로 결과가 좋았던 작업은 시작 전에 계획을 고정하고, 한 단계만 맡기고, 매 반복에서 측정값이나 화면 같은 증거를 남겼습니다.

4시간 실행이 4시간 진전은 아니었다

한 개발자는 45분 정도로 예상한 기능을 Goal에 맡겼다가 4시간 동안 실행했습니다. 에이전트는 기능을 끝내는 대신 테스트, 감사, 드문 예외 조건을 계속 파고들었습니다. 추가 사용량까지 소진했지만 핵심 산출물은 실행 시간만큼 전진하지 않았습니다. 같은 토론에는 세 시간 동안 구현 없이 명세와 계획만 만든 사례도 나왔습니다.

또 다른 개발자는 열린 형태의 기능 제작을 Goal에 맡겼다가 평범한 결과를 얻었습니다. 댓글에서 반복된 해결책은 더 오래 기다리는 것이 아니었습니다. 먼저 plan.md를 만들고, Goal이 직접 평가할 수 있는 지표를 주고, 같은 접근이 실패하면 다른 가설로 전환하라는 규칙을 넣는 것이었습니다.

Goal이 지엽적인 문제에 갇히는 이유

Goal은 긴 실행 동안 목표를 유지하지만, 처음부터 없던 우선순위까지 만들어 주지는 않습니다. “전체 품질을 높여라”처럼 넓은 목표를 주면 테스트 추가, 타입 정리, 문서 보완도 모두 정당한 다음 행동이 됩니다. 핵심 기능이 남아 있어도 에이전트 입장에서는 목표를 수행하고 있는 셈입니다.

검증 기준을 하나만 주는 것도 위험합니다. 테스트 한 개가 유일한 종료 조건이면 실제 사용자 동작보다 그 테스트를 통과시키는 데 최적화할 수 있습니다. 화면이 필요한 작업은 스크린샷과 브라우저 동작, 백엔드는 API 응답과 핵심 테스트, 성능 작업은 전후 벤치마크를 함께 묶어야 합니다.

오래 돌려도 결과가 나온 사례에는 무엇이 있었나

로봇 서보 보정: 측정 루프가 목표와 정확히 일치했다

로봇 서보를 보정한 사례에서는 값을 바꾸고, 실제 움직임을 관찰하고, 결과를 기록한 뒤 다음 값을 선택하는 루프가 분명했습니다. 작은 신경망 학습 사례도 학습·평가·기록·다음 실험의 순서가 고정돼 있었습니다. 에이전트가 스스로 “좋아졌는지” 확인할 수 있었기 때문에 반복이 곧 진전이 됐습니다.

벡터 데이터베이스: 제품 전체가 아니라 Phase 5만 맡겼다

벡터 데이터베이스 확장 기능을 만든 개발자는 먼저 대화형으로 상세 명세, 작업 계획, ADR을 만들었습니다. 그 다음 Goal에는 “Phase 5 완료”처럼 이미 정의된 한 단계만 맡겼습니다. 실행 중에는 실험 결과를 문서에 기록했고, 별도의 Claude 리뷰를 주기적으로 붙였습니다. 23시간 넘게 실행됐지만 긴 시간이 성과를 만든 것이 아니라 미리 정한 단계와 실험 원장이 긴 실행을 통제했습니다.

10시간 리라이트: 화면 증거와 sanity check가 있었다

10시간 동안 단일 Goal을 성공적으로 돌렸다는 개발자는 새 컨텍스트에서 잘 계획한 프롬프트로 시작했습니다. 댓글에서는 결과를 PNG 스크린샷으로 증명하고, 완료 전에 sanity check를 수행하도록 명시하는 방식이 공유됐습니다. “엉망으로 만들지 말라”는 추상적 주문만으로 성공한 것이 아니라 결과를 확인할 장치가 함께 있었습니다.

멀티플레이 게임: 한 번의 Goal이 아니라 네 번의 Goal과 사람의 플레이 테스트

Cloudflare Workers, WebSocket, Durable Objects를 사용한 실시간 게임도 end-to-end로 완성됐습니다. 다만 작성자는 Goal을 3~4번 나눠 실행했고 세 번 리셋했습니다. 사람이 직접 플레이하면서 화면 흔들림, 애니메이션, 타이머를 다시 판단했습니다. 아키텍처가 완성됐다는 것과 제품 경험이 완성됐다는 것은 다른 문제였습니다.

Plan은 길을 정하고, Goal은 증거가 생길 때까지 실행한다

복잡한 작업에서 Plan과 Goal을 같은 것으로 쓰면 안 됩니다. Plan 단계에서는 요구사항을 쪼개고 의존성, 금지 범위, 완료 순서를 결정합니다. Goal 단계에서는 이미 합의된 한 단계를 구현하고 검증합니다.

1. 계획 문서를 먼저 만든다P0·P1을 나누고, 수정 경로와 공개 API·스키마 같은 금지 범위를 적습니다.
2. Goal에는 한 단계만 넣는다“서비스를 완성하라”가 아니라 “plan.md의 Phase 2를 완료하라”로 범위를 닫습니다.
3. 증거를 세 종류로 만든다사용자가 보는 결과, 자동 검증 명령, 회귀하면 안 되는 기존 동작을 함께 둡니다.
4. 반복 전환 규칙을 둔다동일 실패가 두 번 나오면 패치를 더 얹지 말고 원인 가설과 계획을 갱신합니다.
5. 진행 원장을 남긴다매 반복의 가설·변경·결과·다음 행동을 plan.md에 기록해 컨텍스트 압축 뒤에도 경로를 보존합니다.

복사해서 쓰는 Goal 템플릿

/goal [P0 결과물]을 완료한다.

완료 조건:
1. [사용자가 확인할 산출물]
2. [테스트·빌드·벤치마크 명령과 기대 결과]
3. [회귀하면 안 되는 기존 동작]

작업 순서:
1. P0 항목을 적힌 순서대로 끝낸다.
2. P0가 끝나기 전에는 미관 개선, 일반화, 희귀 예외,
   관련 없는 리팩터링을 하지 않는다.

반복 규칙:
- 매 시도 뒤 plan.md에 가설·변경·결과·다음 행동을 기록한다.
- 같은 하위 문제에서 두 번 실패하거나 검증 수치가 두 번 연속
  좋아지지 않으면 같은 접근을 중단하고 원인 가설을 다시 세운다.
- 하위 문제가 P0를 막지 않으면 blocked 목록으로 옮기고 다음 P0로 간다.

범위:
- 수정 가능: [경로]
- 변경 금지: [공개 API·스키마·서비스]

차단 시:
- 시도한 경로, 확인한 증거, 정확한 blocker,
  필요한 입력을 기록하고 정지한다.

이 신호가 보이면 직접 멈춰야 한다

• P0 체크박스는 그대로인데 테스트 파일과 문서만 계속 늘어납니다.
• 같은 오류에 세 번째 패치를 얹고 있지만 원인 가설은 바뀌지 않았습니다.
• diff는 커지는데 사용자가 확인할 화면·API·성능 수치는 달라지지 않습니다.
• 작업 범위 밖의 테스트와 리팩터링이 원래 기능보다 커졌습니다.
• 권한이나 외부 데이터가 없는데 보고하고 멈추지 않고 우회 구현을 시작합니다.

Goal 모드의 성패는 몇 시간을 돌았는지가 아니라 핵심 산출물과 검증 증거가 반복마다 늘었는지로 판단해야 합니다. 오래 실행할수록 Goal 문장은 더 구체적이어야 합니다. 결과, 순서, 범위, 전환, 정지 조건이 빠지면 지속성은 생산성이 아니라 고집이 됩니다.

자주 묻는 질문