Codex Goal 기능: 장기 작업을 끝까지 이어가는 방법

Codex Goal의 개념부터 /goal 사용법, 좋은 완료 조건 작성법, 실행 중 조정과 병렬 작업 주의점까지 정리합니다.

Codex Goal 기능: 장기 작업을 끝까지 이어가는 방법

개발 업무는 한 번의 답변으로 끝나지 않는 경우가 많습니다. 코드를 읽고, 계획을 세우고, 수정하고, 테스트 실패를 고친 뒤 다시 검증해야 하죠. Codex의 Goal 기능은 이런 장기 작업에서 목표와 완료 조건을 대화에 지속적으로 붙여 두고, 다음 단계를 자동으로 이어가도록 설계된 기능입니다.

Goal은 무엇이 다른가

일반 프롬프트는 현재 요청에 답하는 데 초점이 있습니다. 반면 Goal은 달성해야 할 결과를 활성 대화에 유지합니다. Codex는 그 목표를 첫 요청이자 완료 판단 기준으로 사용하고, 여러 단계가 필요한 작업을 진행하면서 상태를 추적합니다.

핵심은 “이 작업을 해줘”보다 “어떤 상태가 되면 끝난 것인지”를 명확히 정의하는 것입니다.

공식 문서 기준으로 Goal은 지속 목표와 자동 연속 실행을 제공하는 안정(Stable) 기능입니다. ChatGPT 데스크톱 앱, 대화형 Codex CLI, IDE 확장 채팅에서 /goal로 시작할 수 있습니다.

시작하는 방법

  1. ChatGPT 데스크톱 앱, Codex CLI 또는 IDE 확장의 대화창에서 /goal을 입력합니다.
  2. 원하는 결과와 제약, 검증 기준을 목표로 작성합니다.
  3. 실행 중에는 같은 대화에서 맥락을 추가하거나 조건을 조정하고, 상태 요약을 요청할 수 있습니다.

CLI에서는 /goal로 현재 목표를 확인하고, /goal edit, /goal pause, /goal resume, /goal clear로 목표를 관리할 수 있습니다. 목표 문장은 4,000자 이하여야 하므로, 긴 요구사항은 문서 파일에 적고 Goal에서 그 파일을 참조하는 편이 좋습니다.

좋은 Goal을 만드는 세 가지 요소

1. Outcome — 활동이 아니라 결과

“TypeScript로 바꿔줘”보다 “기존 동작을 보존하면서 TypeScript strict 모드로 마이그레이션해줘”가 좋습니다. Codex가 도달해야 할 상태가 분명해지기 때문입니다.

2. Constraints — 지켜야 할 경계

사용해야 하는 도구, 호환 버전, 수정하면 안 되는 영역, 피해야 할 접근을 명시합니다. 예를 들어 “공개 API는 변경하지 말 것”, “새 런타임 의존성은 추가하지 말 것”처럼 작성할 수 있습니다.

3. Verification — 완료를 증명하는 방법

테스트, 빌드, 린트, 성능 수치나 리뷰 기준을 넣습니다. Goal이 강력해지는 지점은 Codex가 작업 여부뿐 아니라 완료 여부를 스스로 확인할 수 있게 하는 것입니다.

실전 예시

/goal 이 코드베이스를 JavaScript에서 TypeScript로 마이그레이션한다.
기존 동작과 공개 API를 유지하고, strict 모드에서 명시적 any 없이 컴파일되게 한다.
전체 테스트와 린트가 통과하면 완료로 판단한다.

결과가 아직 모호하다면 먼저 /plan으로 요구사항과 제약을 정리한 뒤, 측정 가능한 완료 조건을 가진 Goal로 전환하는 흐름이 유용합니다.

실행 중에도 방향을 바꿀 수 있다

Goal은 한 번 정하면 손댈 수 없는 작업 큐가 아닙니다. 진행 중 후속 메시지로 새로운 맥락을 추가하거나 제약을 조정할 수 있습니다. 데스크톱 앱에서는 진행 표시줄에서 일시정지, 재개, 편집, 해제가 가능하며, 연결이 끊길 예정이라면 미리 일시정지한 뒤 나중에 재개할 수 있습니다.

상태 설명만 듣고 싶을 때는 별도 사이드 채팅을 이용하면 주 작업 흐름을 끊지 않고 진행 상황을 확인할 수 있습니다.

보안과 권한은 그대로다

Goal을 시작한다고 Codex의 권한이 넓어지지는 않습니다. 기존 샌드박스와 승인 정책이 그대로 적용되며, 사용자 결정이 필요한 지점에서는 멈춥니다. 장시간 실행과 무제한 권한은 전혀 다른 개념입니다.

병렬 Goal을 사용할 때의 원칙

각 채팅은 독립적인 대화 맥락과 Goal을 갖기 때문에 여러 작업을 동시에 실행할 수 있습니다. 다만 두 작업이 같은 파일을 동시에 수정하면 충돌할 수 있습니다. 독립 작업은 별도 채팅으로 분리하고, 동일 저장소를 병렬로 다룬다면 Git worktree처럼 서로 다른 체크아웃을 사용하는 편이 안전합니다.

언제 Goal을 쓰면 좋은가

  • 대규모 리팩터링이나 프레임워크 마이그레이션
  • 여러 테스트 실패를 순차적으로 진단하고 수정하는 작업
  • 기능 구현부터 문서와 검증까지 한 흐름으로 끝내야 하는 작업
  • 중간 상태를 확인하면서도 장시간 같은 완료 기준을 유지해야 하는 작업

반대로 짧은 질문, 단일 파일의 작은 수정, 즉시 답할 수 있는 조회에는 일반 프롬프트가 더 간결합니다.

마무리

Codex Goal의 가치는 오래 실행되는 데만 있지 않습니다. 결과·제약·검증을 하나의 지속적인 완료 기준으로 묶는다는 데 있습니다. 잘 작성한 Goal은 장기 작업에서 맥락 손실을 줄이고, 사용자는 중간에 방향을 조정하면서도 최종 품질 기준을 놓치지 않게 해줍니다.


참고: OpenAI — Long-running work, OpenAI — Goal mode and prompting. 기능과 제공 화면은 제품 업데이트에 따라 달라질 수 있습니다.