원문 제목: A guide to /goal
원문 저자: @dkundel, OpenAI 개발자 관계 팀원
편집: Peggy

편집자 주: 이 글은 OpenAI 개발자 관계 팀원인 Dominik Kundel이 Codex의 'goal mode(/goal)' 기능 사용 경험을 정리한 내용입니다. 이는 단순한 프롬프트 기술이 아니라, AI 코딩 도구에서 일어나고 있는 역할 변화를 다룹니다. Codex는 더 이상 단일 명령에 응답하는 코드 어시스턴트가 아니라, 명확한 목표를 향해 지속적으로 작업을 수행하는 실행형 에이전트(Agent)로 진화하고 있습니다.

/goal 모드에서 진정으로 중요한 것은 요구사항을 길고 세밀하게 작성하는 것이 아니라, Codex를 위해 명확하고 검증 가능한 종료 기준을 설정하는 것입니다. 예를 들어 '배포 시간 30% 단축', '테스트 커버리지 100% 패리티 달성', 'LCP 2.5초 미만으로 낮추기'와 같은 지표가 필요합니다. 이러한 지표를 통해 Codex는 작업 완료 여부를 판단할 수 있으며, 모호한 목표 속에서 무한히 시행착오를 겪는 것을 방지합니다. 동시에 사용자는 Codex가 진행 상황을 측정하고 결과를 검증할 수 있도록 충분한 방향성, 도구 및 실제 환경을 제공해야 합니다. 단순히 로컬이나 가정된 조건에서 그럴듯한 솔루션을 완성하는 데 그치지 않도록 말이죠.

이 글은 특히 시각적 작업이 Codex를 세부 사항의 늪에 빠뜨리기 쉽다고 경고합니다. '100% 픽셀 단위 재현'을 요구하기보다는, 시각적 목표를 기능 목록, 디자인 시스템 규칙, 평가 가능한 지표로 분해하는 것이 좋습니다. 몇 시간에서 며칠에 걸친 장기 작업의 경우, commit, 초안 PR(draft PR), 진행 문서, Slack 업데이트 또는 사이드 채팅(side chat) 등을 통해 지속적으로 추적해야 하며, 최종적으로 추적 불가능한 변경 사항만 남는 상황을 피해야 합니다.

이 글의 정보적 가치는 /goal을 '장기 작업 관리 메커니즘'으로 재정의한 데 있습니다. AI가 수십 시간에서 수백 시간까지 연속적으로 실행할 수 있게 되면서, 개발자의 핵심 역량도 변화합니다. 단순히 AI가 코드를 생성하도록 하는 것이 아니라, 목표를 정의하고, 측정 체계를 구축하며, 실행 환경을 구성하고, 마지막으로 검토와 분석을 완료하는 것입니다. 즉, AI 코딩은 '프롬프트 작성'에서 '지속적으로 작업하는 엔지니어링 실행자를 관리하는 것'으로 나아가고 있습니다.

다음은 원문입니다:

우리는 목표 모드(goal mode, 또는 /goal)를 출시했습니다. 이는 Codex가 특정 결과를 향해 지속적으로 작업할 수 있도록 돕기 위한 것입니다. 목표를 설정하면 Codex는 목표가 달성될 때까지 작업을 계속합니다. 몇 시간이 걸리든 며칠이 걸리든 상관없습니다. 이미 어떤 사람들은 Codex가 동일한 목표를 위해 120시간 이상 연속 작업하도록 한 사례도 있습니다.

목표 모드는 매우 강력합니다. 그 효과를 최대한 활용하려면 /goal을 사용할 때 주의할 점 7가지가 있습니다.

명확하고 검증 가능한 기준 설정

목표 모드를 활성화할 때 입력하는 프롬프트는 초기 지시사항 역할을 할 뿐만 아니라, 더 중요하게는 해당 목표의 종료 기준이 됩니다. Codex는 각 작업 라운드가 끝난 후 이 목표가 완료되었는지 확인합니다.

따라서 목표 프롬프트는 너무 길게 작성하기보다는 명확한 기준에 초점을 맞춰야 합니다. 즉, 어떤 상황에서 목표가 달성되었다고 볼 수 있는지 정의하는 것이 중요합니다.

대부분의 경우 좋은 목표에는 모델이 완료 여부를 판단할 수 있는 명확한 숫자 지표를 포함하는 것이 좋습니다. 예를 들어:

「빌드 및 배포 시간을 30% 단축합니다.」

「이 기능을 TypeScript에서 Rust로 마이그레이션하고 100% 테스트 일관성을 달성합니다.」

「애플리케이션 스캐폴딩을 최적화하여 프로덕션 환경에서 Largest Contentful Paint(페이지 주요 콘텐츠 로딩 속도를 측정하는 지표)를 2.5초 미만으로 유지합니다.」

이 프롬프트에 항상 숫자가 포함되어야 하는 것은 아니지만, 일반적으로 숫자가 있으면 이후 단계를 더 쉽게 진행할 수 있습니다.

목표를 어떻게 정의해야 할지 확실하지 않거나, 먼저 Codex와 함께 프로젝트에 대해 브레인스토밍하고 싶다면 처음부터 목표 모드로 대화를 시작할 필요는 없습니다.

Codex는 스스로 목표를 설정할 수 있습니다. 일반 대화를 먼저 시작한 후, Codex가 실행을 시작할 준비가 되면 이전 논의 내용을 바탕으로 Codex가 목표를 설정하도록 할 수 있습니다.

또한 언제든지 목표를 편집할 수 있습니다. Codex 애플리케이션에서 편집 버튼을 클릭하거나 CLI에서 /goal을 다시 사용하면 됩니다.

가능한 한 지침 제공

「빌드 및 배포 시간을 30% 단축합니다」와 같은 프롬프트는 멋져 보이고 Codex가 창의적인 해결책을 찾도록 할 수도 있습니다. 하지만 문제가 어디에 있을지 대략적으로 알고 있다면, 이러한 프롬프트는 Codex가 잘못된 방향으로 갈 수도 있습니다.

따라서 가능한 경우 Codex에 문제 해결을 시작해야 할 위치, 목표를 달성하는 데 사용할 수 있는 도구, 또는 잘못된 방향으로 빠지지 않도록 하는 기타 힌트를 제공하는 것이 좋습니다.

예를 들어, 제 동료 @reach_vb는 한 실험에서 이렇게 했습니다: Codex에게 Chrome 브라우저를 사용해 Google Colab에 접속할 수 있다고 알려주고, Codex가 모델을 학습시킬 때 스스로 데이터셋을 생성하도록 하는 등 몇 가지 허용 가능한 제한 조건을 설명했습니다.

마찬가지로, 빌드 시간을 단축하고 싶고 대부분의 시간이 어느 단계에서 소모되는지 이미 알고 있다면, 프롬프트에서 먼저 Codex를 해당 영역으로 안내하는 것이 좋습니다.

또 다른 방법으로는, 먼저 Codex가 계획 모드(plan mode)에서 예비 조사를 수행하게 하고, 잠재적 솔루션을 기록하는 계획 파일을 만들도록 한 후, 이후 목표가 이 계획을 참조하도록 하는 것입니다.

진행 상황을 측정 가능하게 만들기

목표가 야심 차거나 Codex가 점진적으로 목표에 접근할 수 있는 다양한 방법이 있다면, Codex에 진행 상황을 측정할 도구를 제공하는 것이 매우 중요합니다.

일부 작업의 경우 이는 자연스럽게 성립할 수 있습니다. 예를 들어 빌드 시간 최적화나 테스트 커버리지 향상 같은 경우, Codex가 이미 관련 도구를 사용할 수 있거나 자연스럽게 이러한 도구를 생성하기 때문입니다.

하지만 다른 목표의 경우, Codex와 함께 어떤 도구가 진행 상황을 판단하는 데 도움이 될지 브레인스토밍하거나, 자신이 목표에 가까워지고 있는지 확인하는 방법에 대한 힌트를 제공하는 것이 좋습니다. 예를 들어, 두 개의 스크린샷을 비교하는 시각적 차이 분석 도구를 만들거나, 디버깅 중인 에이전트를 위한 평가 세트를 만드는 것입니다.

저는 Codex가 비디오를 기반으로 일부 컴포넌트를 재현하도록 한 적이 있는데, 그때 Codex는 스크린샷을 비교하고 차이점을 확인하는 도구를 스스로 만들었습니다. 이후에는 다양한 차이 비교 모드를 추가하며 이 도구를 지속적으로 개선했습니다.

이미지: Codex가 생성한 스크린샷으로, 두 화면 프레임을 시각적으로 비교하기 위한 것입니다.

작업에 따라 측정하거나 확인해야 할 추가 기준이 있는지 고려해야 합니다. 그렇지 않으면 Codex가 작업이 완료되었다고 생각할 수 있지만, 사용자 입장에서는 아직 완전하지 않을 수 있습니다.

예를 들어, Codex가 UI를 '픽셀 단위로 재현'하기 위해 디자인 참조 이미지를 직접 잘라 페이지에 삽입하거나, 테스트 통과율을 100%로 만들기 위해 오히려 테스트 범위를 축소할 수도 있습니다. 이는 실제로 원하는 완료 방식이 아닙니다.

현실적인 환경 조성

Codex가 목표를 향해 실질적인 진전을 이루길 원한다면, 충분히 현실적인 환경에서 작동해야 합니다.

실제로 이는 다음과 같은 의미입니다: 배포 시간이나 지연 문제를 최적화하려면 Codex가 배포 및 테스트 환경에 접근할 수 있어야 하며, 이러한 환경은 최대한 프로덕션 환경을 모방해야 합니다. 즉, 동일한 기술 스택, 동일한 구성 스위치, 유사한 데이터베이스를 사용하는 것입니다.

예를 들어, 우리는 developers.openai.com의 빌드 및 배포 시간 최적화를 디버깅한 적이 있습니다. 당시 이미 배포 프리뷰를 사용하고 있었기 때문에 Codex가 이러한 프리뷰 환경을 활용해 배포하고 관련 로그를 확인할 수 있었습니다. 하지만 문제는 프리뷰 배포가 전체 프로덕션 환경에 비해 일부 빌드 경로가 비활성화되어 있었다는 점입니다.

결국 Codex는 수동 배포를 통해 코드를 프로덕션 구성에 더 가까운 환경에 배포한 후에야 문제를 실제로 확인할 수 있었습니다.

마찬가지로, Codex가 computer use(모델이 실제 애플리케이션 인터페이스를 조작하는 능력)를 사용해 실제 앱을 테스트하도록 할 수도 있습니다. iOS의 일부 성능 문제를 최적화하기 위해 @dimillian은 가장 정확한 테스트 환경을 위해 실제 디바이스까지 사용했습니다.

시각적 목표 설정 시 주의

Codex에 "이 이미지를 기준으로 100% 픽셀 단위로 UI를 재현하라"와 같은 시각적 목표를 주는 것은 매우 유혹적입니다. 하지만 설정에 따라 문제를 일으킬 수도 있습니다.

적절한 지침과 제약 조건을 제공하지 않으면, Codex가 특정 세부 사항에 지나치게 집중해 전체 목표를 놓칠 수 있습니다. 예를 들어, 참조 이미지에 그래픽 요소가 포함되어 있고 Codex가 이를 생성하길 기대한다면—SVG 아이콘이든 이미지든—문제를 올바르게 분해하는 대신 "이러한 요소를 정확히 복제하는 방법"에 많은 에너지를 쏟을 수 있습니다.

또한, Codex가 시각적 비교를 제대로 수행하려면 도구가 필요합니다. 이는 더 많은 이미지 입력과 전체적인 토큰 소모 증가를 의미하지만, Codex가 실제로 가치 있는 개선 기회를 식별할 수 있는 간단한 방법을 제공하지는 않습니다.

따라서 이미지는 일반적으로 목표 컨텍스트로 사용하는 것이 더 적합하며, 유일한 완료 기준으로 삼아서는 안 됩니다. 기능 목록, 구현 사양, 디자인 시스템 준수 여부 등 Codex가 목표 달성을 판단할 수 있는 다른 방법을 찾아야 합니다.

진행 상황 추적

Codex가 백그라운드에서 몇 시간 또는 며칠 동안 작업하거나, 심지어 다른 머신에서 실행되는 경우, 어디까지 진행되었고 어떤 작업이 완료되었는지 쉽게 잊어버릴 수 있습니다.

목표에 따라 다음과 같은 방법이 유용하다는 것을 알게 되었습니다:

· Codex가 주요 지점에서 코드를 커밋하고 초안 PR로 푸시하도록 설정합니다. 특히 웹사이트를 작업 중이고 미리보기 배포가 있는 경우 매우 유용합니다.

· Codex가 경영진 대상의 산출물을 업데이트하도록 합니다. 이는 앱 내 브라우저에서 계속 열어둘 수 있는 HTML 파일이거나, Sites를 통해 팀이 볼 수 있도록 배포된 페이지, 렌더링된 진행 상황 차트, 또는 일반 Markdown 파일일 수 있습니다.

Codex에게 진행 업데이트를 능동적으로 게시하도록 지시합니다. 목표에 이를 포함시킬 수도 있습니다: Codex가 중요한 진전이 있을 때 Slack 채널이나 진행 상황을 기록하려는 다른 곳에 업데이트를 보내도록 합니다.

다른 채팅 창을 사용해 상태를 확인합니다. 현재 상태를 빠르게 확인하려면 /side를 실행해 새로운 사이드 채팅을 시작하고 질문합니다. 이 채팅은 현재 스레드에서 분기되므로 지금까지의 전체 컨텍스트를 가지지만 수명이 짧습니다.

Codex 앱에서 다른 대안은 일반 새 채팅을 열고 Codex가 다른 목표 스레드를 읽고 질문에 답하도록 하는 것입니다. Codex가 진행 상황을 정기적으로 확인하는 자동화 작업을 설정하도록 하면 특히 강력합니다.

정리 및 최종 결과 확인

좋습니다, 목표가 드디어 완료되었습니다! 이제 결과물을 팀에 던져주고 끝내면 될까요?

일반적으로, 특히 최적화 관련 작업에서는 Codex가 자신이 완료한 작업을 되돌아보고 검토하도록 하는 것이 유용합니다. 먼저 /review로 로컬 코드 리뷰를 실행할 수 있지만, Codex가 더 깊이 반성하도록 하는 것도 가치가 있습니다: 목표를 달성하기 위해 어떤 경로를 시도했는지? 어떤 시도가 효과적이었고 어떤 시도가 효과가 없었는지? 그런 다음 이를 바탕으로 코드를 정리합니다.

Codex는 목표에 도달할 때까지 계속 작업하므로, 효과가 충분하지 않거나 전혀 효과가 없는 방법을 시도했을 수 있으며, 이러한 잔여 변경 사항이 최종 코드에 남아 있을 수 있습니다.

다음 작업에도 목표를 설정하세요

Codex의 목표 기능은 가장 의미 있는 엔지니어링 과제를 해결하는 데 도움을 줄 수 있는 매우 강력한 도구입니다. 하지만 올바른 환경과 지침을 제공해야만 더 효율적으로 목표에 도달할 수 있습니다.

/goal을 사용해 어떤 작업을 해보셨나요?

[원문 링크]

BlockBeats 공식 커뮤니티에 참여하세요:

Telegram 구독 그룹：https://t.me/theblockbeats

Telegram 토론 그룹：https://t.me/BlockBeats_App

Twitter 공식 계정：https://twitter.com/BlockBeatsAsia