Codex의 Goals를 활용하는 법 — 개발자가 알아야 할 핵심 정리

Codex의 Goals를 활용하는 법 — 개발자가 알아야 할 핵심 정리

Codex가 사용자의 반복적 지시 없이도 스스로 목표를 향해 작업을 지속할 수 있다면 어떨까. 바로 이 문제를 해결하는 기능이 바로 Goals다. Codex 버전 0.128.0부터 사용할 수 있는 이 기능은 에이전트 코딩의 한계를 벗어난 작업 방식을 제안한다.

Goals란 무엇인가

Goals는 Codex 스레드에 영속적 목표를 부여하는 기능이다. 일반 프롬프트가 "이 작업을 해라"라고한다면, Goal은 "이 결과가 참이 될 때까지 계속 작업해라"라고ifference은 명확하다.

Codex는 이미 버그 수정, 테스트 추가, 같은 범위가능을 보이고 있다. 그러나 작업의 다음 단계가 Codex가 도중에 학습한 내용에 따라 달라지는 경우에는 일반 프롬프트만으로는하기 어렵다. 프로파일링, 패치, 벤치마킹, 플레이키 테스트 재현, 근거 기반 감사 같은 작업이 대표적인 예다.

이런 작업에는 더 큰 프롬프트를 만드는 것이 아니라 영속적 목표가 필요하다. Goal이 활성화되면 매 중간 결과마다 목표를 다시 진술하지 않아도 Codex가 목표를 유지하고, 완료 여부를 평가하며, 다음 행동을 선택한다.

Goals의 핵심 명령어

Goals는 네 가지 기본 명령으로 수명주기를 관리한다.

/goal <결과>           # 목표 설정/goal                 # 현재 Goal 확인/goal pause           # Goal 일시정지/goal resume          # 일시정지된 Goal 재개/goal clear           # 현재 Goal 제거

예를 들어 성능 최적화 작업이라면 다음과 같이 설정한다.

/goal Reduce p95 latency below 120 ms without regressing correctness tests

이렇게 설정하면 Codex는 벤치마크 실행부터 핫패스 검사, 표적 변경, 다시 벤치마크 실행, 정확성 스위트 실행까지 반복하며 결과가 목표에 도달할 때까지 작업한다.

일반 프롬프트와 Goal의 차이

일반 요청에서 Codex는 즉각적 지시를 수행한 후 결과를 보고하고 대기한다. 반면 Goal에서는 스레드에 지속적 목표가 부착되어, 턴 종료 후에도 현재 증거를 검사하고 목표 충족 여부를 판단한다. 충족되지 않고 Goal이 활성 상태이며 예산이 남아 있다면 최신 상태에서 작업 지속이 가능하다.

Goal 작성을 통해 이 차이를 명확히 할 수 있다.

약한 Goal 예시:

/goal Reduce p95 checkout latency below 120 ms without regressing correctness tests

강한 Goal 예시:

/goal Reduce p95 latency below 120 ms on the checkout benchmark while keepingthe correctness test suite green. Use the checkout service, benchmark fixtures,and related tests. Between iterations, record change logs, benchmark results,and next experiment. If blocked or no valid paths remain, report the blockerand required input for progress.

강한 버전은 결과를 포함한다. 검증 방법, 사용 범위, 반복 정책, 블로커 보고 조건까지 명시되어 있어야 한다.

Goal의 적정 범위 설정

Goal의 범위는 너무 좁거나 넓으면 안 된다. 감사 가능할 만큼 좁으면서도 다음 행동을 선택할 수 있을 만큼 넓어야 한다.

너무 좁은 예다. 하류 의존성이 진짜 문제인데 "Fix the failing checkout test"라고 설정하면 상류 원인을 놓칠 수 있다. 반대로 "Improve the whole system"이라고 설정하면 감사 표면이 없어 결과 판단이 불가능하다.

적절한 범위의 예다. 공개 API 동작을 변경하지 않으면서 현재 브랜치에서 체크아웃 테스트 스위트를 통과시키는 목표다. 검증 가능한 범위 안에 있으면서도 실제 개선 방향을 제시한다.

Goal 활성 시 어떻게 동작하는가

Goal이 활성화되면 여러 가지 변화가 일어난다. 목표가 계속 표시되므로 작업 방향을 놓치지 않는다. 테스트가 실패해도 스레드는 원래 목표를 유지한다. 벤치마크가 개선되었지만 임계값에 못 미치면 Codex가 계속 진행한다. 연구 경로가 데이터 부족에 부딪히면 증거 계획을 조정하면서도 연구 표준을 잃지 않는다.

완료는 증거 기반이어야 한다는 점이 중요하다. 모델이 "아마 끝났을 것"이라고 믿는 것으로는 완료 처리되지 않는다. 관련 파일, 테스트, 로그, 벤치마크 출력, 생성된 산출물, 기타 구체적 증거에 대해 목표를 검사한 후에만 완료로 처리된다.

Goals를 사용하지 않아야 하는 경우

모든 작업에 Goal이 적합한 것은 아니다. 한 줄 편집, 단순 설명, 짧은 코드 리뷰, 한 번의 답변 후 정지를 원하는 질문에는 일반 Codex 프롬프트가 적합하다.

결승선이 모호한 경우에도 Goal은 부적절하다. "Make this better"라고 설정하면 신뢰할 만한 완료 조건을 제공하지 못한다. "Refactor this code"도 예상 종료 상태, 테스트, 제약을 정의하지 않으면 약한 Goal이 된다.

불확실성을 숨기는 용도로 Goal을 사용하는 것도 금지다. 데이터가 사용 불가능할 수 있으면 Goal에 명시해야 한다. 벤치마크가 플레이키할 수 있다면 처리 방법도 함께 명시해야 한다.

실무 적용 사례

성능 최적화 상황에서 Goal의 힘을 확인할 수 있다. "Improve performance"라는 약한 목표보다 "p95 지연 시간을 120밀리초 미만으로 줄이되 정확성 테스트 스위트는 초록 상태를 유지하라"라는 구체적 목표가 훨씬 효과적이다.

이 경우 검증 수단으로 체크아웃 벤치마크를 지정하고, 제약으로 정확성 테스트 스위트 유지, 반복 정책으로 변경 내역과 벤치마크 결과 기록, 블로커 발생 시 보고 내용을 정의한다.

연구 작업에도 Goal을 활용할 수 있다. 논문 재현이 대표적인 예다. "논문을 재현하라"는 추상적 목표보다 "사용 가능한 자료로 이 논문의 가장 강력한 재현 결과를 만들어라. 가능한 부분은 검증하고, 재현 불가능한 부분은 블로커로 라벨링한 보고서를 작성하라"라는 목표가 훨씬 명확하다.

마무리

Goals는 Codex의 운영 모델을 근본적으로 바꾼다. 스레드를 고립된 프롬프트가 아닌 지속적 작업 단위로 변경한다. 목표는 계속 진행하되, 완료는 증거가 결정한다는 원칙이 핵심이다.

단순한 작업에는 일반 프롬프트를 사용하고, 복잡하고 지속적이며 증거 기반 결승선이 필요한 작업에 Goal을 활용하는 것이 가장 효과적인 전략이다.

---

📚 출처

• https://news.hada.io/topic?id=29639