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

Codex Goal 모드는 정해 둔 완료 조건을 충족할 때까지 목표를 유지하며 작업하는 기능이다. 무엇을 먼저 끝낼지와 완료를 어떻게 검증할지는 사용자가 정해야 한다. 이 조건이 빠지면 에이전트는 중요한 기능을 미완성으로 둔 채 눈앞의 보조 작업만 계속할 수 있다.

OpenAI의 장시간 작업 문서는 Goal을 시작할 때 결과·제약·완료 증거를 정하도록 안내한다. 이 글에서는 그 기준을 실제 장기 실행 후기에 대입해, 무엇을 계속하고 언제 방향을 바꿀지 살핀다. 명령과 시작·정지 방법은 Goal 공식 기능 가이드에서 이어 볼 수 있다.

개발자들의 실패 후기에는 희귀 테스트에 매달리거나, 코드는 쓰지 않은 채 계획을 늘리거나, 같은 가설에 수정을 계속 덧대는 모습이 나왔다. 성공 후기에서는 미리 정한 계획에 따라 한 단계씩 실행하고, 측정값이나 화면으로 결과를 확인한 방법을 살펴볼 수 있다.

작은 기능에 4시간 동안 테스트·감사를 반복했다

Reddit 작성자 SierraBravoLima는 간단한 기능을 추가하면서 Codex가 테스트·감사·드문 예외 조건을 반복해 약 4시간을 썼고, 도중에 크레딧을 두 차례 충전했다고 전했다. “5.5였다면 45분에 했을 것”이라는 말은 작성자의 예상이다. 이 장기 실행 후기에서 해당 작업의 /goal 사용 여부는 확인되지 않는다. 같은 토론의 다른 사용자는 세 시간 동안 구현 없이 명세와 계획만 만들었다고 적었다.

Goal 사용이 명시된 별도 토론에서는 SnooPeripherals5313가 범위나 완료 기준을 정하지 않은 채 기능 제작을 맡기면 결과가 좋지 않았다고 전했다. 댓글에서는 먼저 plan.md를 만들고, Goal이 직접 평가할 수 있는 지표를 주고, 같은 접근이 실패하면 다른 가설로 전환하라는 규칙을 넣으라고 권했다.

요구한 기능과 검사 결과가 나아지는지 본다

로그가 계속 생겨도 P0에 해당하는 화면·기능이 구현되지 않고 검사 결과도 개선되지 않는다면, 핵심 작업은 멈춘 채 같은 보조 작업만 반복하고 있을 수 있다.

우선순위·완료 증거·전환 조건이 없으면 Goal이 보조 작업에 매달릴 수 있다

실행 중 보이는 현상	Goal에 정하지 않은 작업 조건	추가할 지시
희귀 예외와 보조 테스트에 대부분의 시간을 씀	P0 작업 순서	“P0가 끝나기 전에는 P1·P2와 미관 개선을 하지 않는다.”
테스트 하나를 계속 고침	사용자 동작·빌드·핵심 테스트의 검증 방법	“요구한 사용자 동작을 실행하고 빌드와 핵심 테스트의 통과 결과를 남긴다.”
같은 접근을 조금씩 바꿔 반복	전환 조건	“같은 하위 문제에서 두 번 실패하면 원인 가설부터 다시 세운다.”
관련 코드 전체를 리팩터링	수정 가능·금지 범위	“src/auth만 수정하고 공개 API와 DB 스키마는 바꾸지 않는다.”
계획과 문서만 늘어남	완료 때 남길 결과물	“완료 시 동작 화면, 변경 파일, 통과한 명령을 남긴다.”
권한·데이터 부족을 우회하며 범위 확장	진행이 막혔을 때 멈출 조건	“필요한 입력과 확인한 증거를 적고 더 확장하지 말고 멈춘다.”

Goal에 “전체 품질을 높여라”처럼 넓은 목표만 주면 테스트 추가, 타입 정리, 문서 보완도 모두 다음 작업으로 선택할 수 있다. 먼저 끝낼 기능과 완료 증거, 같은 접근을 중단할 조건이 빠져 있으면 핵심 기능을 미완성으로 둔 채 보조 작업을 이어 갈 수 있다. 긴 실행에서 목표를 유지하는 기능만으로는 이 작업 순서를 정할 수 없다.

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

로봇 보정·DB 확장·게임 제작에서 실행 단위를 나누고 결과를 검증한 방법

로봇 서보 보정: 움직임을 측정해 다음 조정값을 정했다

로봇 서보를 보정한 사례에서는 값을 바꾸고, 실제 움직임을 관찰하고, 결과를 기록한 뒤 다음 값을 선택했다. 작은 신경망 학습 사례도 학습·평가·기록·다음 실험의 순서가 고정돼 있었다. 에이전트는 측정 결과로 목표에 가까워졌는지 판단하고 다음 조정을 정할 수 있었다.

벡터 데이터베이스 확장: Phase 5를 맡기고 실험을 기록하며 별도 리뷰를 받았다

벡터 데이터베이스 확장 기능을 만든 개발자는 먼저 대화를 통해 상세 명세, 작업 계획, 아키텍처 결정 기록(ADR)을 만들었다. 그다음 Goal에는 “Phase 5 완료”처럼 이미 정의된 한 단계만 맡겼다. 실행 중에는 실험 결과를 문서에 기록했고, 별도의 Claude 리뷰를 주기적으로 받았다. 23시간 넘는 실행에서 미리 정한 단계와 실험 기록이 작업 범위를 유지하고 다음 행동을 정하는 기준이 됐다.

10시간 실행 후기와 화면 검증 조언

Reddit 사용자 sjoti는 단일 Goal을 10시간 실행해 작업이 흐트러지지 않았다고 전했다. 같은 토론의 Sorry_Risk_5230은 새 컨텍스트와 잘 계획한 프롬프트를 권했고, noodlessentme는 PNG 스크린샷과 완료 전 기본 동작 점검(sanity check)을 요청한다고 적었다. 화면을 만드는 작업이라면 스크린샷과 동작 점검으로 작성한 코드가 실제 화면에서 요구대로 작동하는지 확인할 수 있다.

멀티플레이 게임: Goal 3~4번과 사람의 플레이 테스트가 필요했다

한 개발자는 Cloudflare Workers, WebSocket, Durable Objects를 사용한 실시간 멀티플레이 게임을 완성했다. 이 과정에서 Goal을 3~4번 나눠 실행했고 세 번 리셋했다. 사람이 직접 플레이하면서 화면 흔들림, 애니메이션, 타이머를 점검했다. 게임이 동작한 뒤에도 조작감과 화면 연출은 사람이 평가해야 했다.

실패한 장기 실행넓은 목표 → 눈앞의 오류 → 같은 수정 반복 → 시간 증가

성공한 장기 실행단계 고정 → 측정 → 기록 → 전환 또는 다음 단계

Plan에서 순서를 정하고 Goal에는 한 단계의 구현·검증을 맡긴다

Plan 단계에서는 요구사항을 쪼개고 의존성, 금지 범위, 완료 순서를 결정한다. Goal 단계에서는 그 계획에서 합의한 한 단계를 구현하고 검증한다. 복잡한 작업은 이 순서로 나누면 이번 실행에서 끝낼 범위가 분명해진다.

계획 문서를 먼저 만든다P0·P1을 나누고, 수정 경로와 공개 API·스키마 같은 금지 범위를 적는다.
Goal에는 한 단계만 넣는다“plan.md의 Phase 2를 완료하라”처럼 이번에 끝낼 범위를 지정한다.
세 가지 방법으로 완료를 검증한다사용자가 볼 결과를 보여 주고, 자동 검증 명령과 실행 결과를 남기고, 기존 동작이 깨지지 않았는지 검사한다.
반복 전환 규칙을 둔다동일 실패가 두 번 나오면 패치를 더 얹지 말고 원인 가설과 계획을 갱신한다.
시도마다 진행 상황을 기록한다각 시도의 가설·변경·결과·다음 행동을 plan.md에 적어 컨텍스트 압축 뒤에도 작업을 이어 갈 수 있게 한다.

결과물·작업 범위·전환·정지 조건을 적는 Goal 템플릿

나쁜 Goal

이 저장소의 인증 시스템을 완벽하게 개선하고 모든 문제를 해결해.

좋은 Goal

로그인 갱신 오류를 재현하고 수정한다. 성공 기준은 아래 명령과 사용자 동작으로 확인한다.

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

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

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

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

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

진행이 막혔을 때:
- 시도한 경로, 확인한 증거, 진행을 막는 원인,
  필요한 입력을 기록하고 정지한다.

P0가 멈춘 채 테스트·문서만 늘어나면 실행을 멈춘다

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

승인 대기 때문에 작업이 멈췄다면 마지막 도구 오류와 승인 요청에서 필요한 권한을 찾아야 한다. 2026년 5월 gerrry의 Goal 사용 후기에는 사소한 작업의 권한을 묻는 메시지가 밤새 반복됐다는 보고가 있다. 비슷한 이슈 #22833은 막혔을 때 종료할 수 있도록 수정됐다는 설명과 함께 5월 30일 닫혔다. 현재 실행에서 같은 메시지가 반복되면 CLI에서는 /goal pause로 멈춘 뒤 마지막 도구 오류나 승인 요청을 읽고, 필요한 권한을 제공할지 작업을 줄일지 정한다. 데스크톱 앱에서는 목표 진행 행의 일시정지 버튼을 쓴다. Goal은 기존 권한 범위 안에서 작업한다.

Goal 모드의 성패는 반복할 때마다 요구한 화면·기능이 구현되고, 검사 결과가 그 진전을 보여 주는지로 판단해야 한다. P0가 멈춘 채 보조 작업만 늘어나면 일단 실행을 멈추고, 다음 시도에서 끝낼 결과 하나와 접근을 바꿀 조건을 다시 적는 편이 낫다. 반복 절차를 매번 붙여 넣고 있다면 Skills 작성 가이드를 참고할 수 있다.

자주 묻는 질문

Codex Goal 모드는 어떤 작업에 가장 잘 맞는가?

완료 상태를 명확히 측정할 수 있고, 반복마다 결과를 확인할 수 있는 작업에 잘 맞는다. 대규모 기계적 리팩터링, 벤치마크 최적화, 테스트 가능한 단계별 구현이 대표적이다.

Goal 모드가 오래 돌면 제대로 일하고 있다는 뜻인가?

작업이 진전되는지는 우선 끝낼 필수 작업(P0)의 화면·기능이 구현되고 있는지와 검사 결과가 개선되는지로 판단한다. 같은 하위 문제에서 같은 접근을 반복하면 중단 조건이 필요하다.

Goal 전에 Plan 모드를 꼭 써야 하는가?

복잡한 작업이라면 먼저 계획 문서에 범위, 단계, 완료 조건과 금지 범위를 고정하는 편이 좋다. Goal에는 전체 제품이 아니라 그 계획의 한 단계를 맡기는 방식이 안정적이다.

Goal에 반드시 넣어야 할 항목은 무엇인가?

P0 결과물, 검증 명령과 기대 결과, 수정 가능 범위, 변경 금지 범위, 실패 뒤 전환 규칙, 막혔을 때 보고하고 멈추는 조건이 필요하다.