저희는 Codex 가 구체적인 결과를 향해 나아갈 수 있도록 돕는 방법으로 목표 모드(또는 /goal)를 출시했습니다. 목표를 설정하면 Codex 는 목표가 달성될 때까지 계속 작업하며, 몇 시간이 걸리든 며칠이 걸리든 상관없이 작업을 지속합니다. 어떤 사람들은 Codex 를 사용하여 120시간 이상 단일 목표를 위해 작업하기도 했습니다.
목표 모드는 매우 강력하며, 이를 최대한 활용하기 위해 할 수 있는 몇 가지 방법이 있습니다. /goal 을 사용할 때 염두에 두어야 할 7가지 사항은 다음과 같습니다.
1. 명확하고 *검증 가능한* 기준
목표 모드를 활성화할 때 정의하는 프롬프트는 초기 프롬프트 역할을 할 수 있지만, 더 중요한 것은 목표의 종료 기준 역할을 한다는 것입니다. Codex 는 각 턴이 끝난 후 목표가 달성되었는지 여부를 확인합니다. 따라서 목표 프롬프트는 지나치게 길지 않아야 하며, 목표가 달성되었을 때의 명확한 기준에 초점을 맞춰야 합니다.
대부분의 경우 좋은 목표에는 모델이 목표 완료로 간주하기 전에 도달해야 하는 명확한 숫자\* 가 포함됩니다. 좋은 예시:
- "빌드 및 배포 시간을 30% 단축합니다."
- "이 기능을 TypeScript 에서 Rust 로 마이그레이션하고 100% 테스트 패리티를 달성합니다."
- "프로덕션 환경에서 최대 콘텐츠풀 페인트(LCP)를 2.5초 미만으로 낮추도록 애플리케이션 스캐폴딩을 개선합니다."
\프롬프트가 항상 숫자일 필요는 없지만 일반적으로 다음 팁에 도움이 됩니다.*
목표를 가장 잘 정의하는 방법을 잘 모르거나 Codex 와 먼저 프로젝트에 대해 브레인스토밍하고 싶다면 목표 모드로 스레드를 시작할 필요가 없습니다.
Codex 는 스스로 목표를 설정할 수 있으므로 대화를 시작하고 Codex 가 작업을 시작할 준비가 되면 Codex 에게 대화 내용을 바탕으로 목표를 설정하도록 요청할 수 있습니다.
또한 Codex 앱에서 편집 버튼을 누르거나 CLI 에서 /goal 을 다시 사용하여 언제든지 목표를 편집할 수 있습니다.
2. 가능하면 지침 제공하기
"빌드 및 배포 시간을 30% 단축" 과 같은 프롬프트를 보내는 것은 멋질 수 있고 창의적인 해결책을 찾을 수도 있습니다. 하지만 문제가 있을 수 있는 위치에 대한 아이디어가 있다면 Codex 가 엉뚱한 방향으로 갈 수도 있습니다.
가능하면 Codex 에게 작업을 시작할 출발점, 목표를 달성하는 데 사용할 수 있는 도구, 또는 Codex 가 잘못된 경로로 갈 수 있는 다른 지침을 제공하세요.
예를 들어, 제 동료 @reach_vb 는 실험 중 하나에서 Codex 에게 Chrome 브라우저를 사용하여 Google Colab 에 접속할 수 있다고 알리고, Codex 가 모델을 훈련시킬 때 자체 데이터 세트를 생성하는 것과 같은 허용 가능한 제한 사항을 알려주었습니다.
마찬가지로 빌드 시간을 줄이려고 하고 대부분의 시간이 어디에 소비되는지 알고 있다면 프롬프트의 일부로 Codex 를 해당 영역으로 먼저 안내해 보세요.
또는 Codex 가 계획 모드에서 초기 조사를 수행하고 잠재적인 옵션을 문서화하는 데 사용할 수 있는 파일로 계획을 작성하도록 할 수도 있습니다. 그런 다음 목표가 해당 계획을 참조하도록 하세요.
3. 진행 상황을 측정 가능하게 만들기
목표가 야심차거나 Codex 가 목표에 더 가까이 갈 수 있는 다양한 방법이 있는 경우 Codex 에게 진행 상황을 측정할 도구를 제공하는 것이 중요합니다.
일부 작업의 경우 빌드 시간 개선이나 테스트 적용 범위 증가와 같이 Codex 가 이미 도구를 가지고 있거나 자연스럽게 생성하는 경우가 많기 때문에 이는 당연한 일일 수 있습니다.
다른 목표의 경우 어떤 도구가 유용할지 Codex 와 브레인스토밍하거나 진행 상황을 확인할 수 있는 방법을 암시하는 것이 좋습니다. 예를 들어, 두 스크린샷 간의 시각적 차이를 계산하는 도구를 만들거나 조정하려는 에이전트를 위한 평가 스위트를 만드는 것 등이 있습니다.
제가 Codex 가 비디오의 일부 구성 요소를 재현하도록 했을 때, Codex 가 스크린샷을 비교하고 차이점을 검사할 수 있는 도구를 스스로 만들도록 했습니다. Codex 는 시간이 지남에 따라 다양한 차이 모드를 갖도록 도구를 발전시키기로 선택했습니다.
Codex 가 두 프레임을 시각적으로 비교하기 위해 생성한 스크린샷
작업에 따라 Codex 가 작업이 완료되었다고 생각할 수 있지만 사용자가 불완전하다고 생각할 수 있는 추가 기준을 측정/확인해야 하는지 고려해야 합니다. 예를 들어, 디자인 영감을 잘라내어 인라인으로 삽입하여 "픽셀 완벽"하게 UI를 구현하거나 테스트 적용 범위를 줄여 100% 통과 가능한 테스트 비율을 달성하는 것 등이 있습니다.
4. 현실적인 환경 만들기
Codex 가 목표를 향해 진정으로 진전하려면 현실적인 환경에서 작동해야 합니다. 실제로 이는 배포 시간이나 지연 시간 문제를 개선하려는 경우 프로덕션 환경을 모방한 배포 및 테스트 환경에 액세스할 수 있어야 함을 의미합니다. 즉, 동일한 스택, 동일한 플래그, 유사한 데이터베이스를 사용해야 합니다.
예를 들어, 저희는 developers.openai.com 의 빌드 및 배포 시간 개선을 디버깅하고 있었습니다. 저희는 이미 배포 프리뷰를 사용하고 있었기 때문에 Codex 는 이를 사용하여 배포하고 관련 로그를 검토할 수 있었지만, 프리뷰 배포에는 전체 프로덕션 실행에 비해 일부 빌드 경로가 비활성화되어 있었습니다. 따라서 Codex 는 대신 유사한 프로덕션 구성을 가진 동일한 환경에 수동으로 배포하여 환경을 검사해야 했습니다.
마찬가지로 Codex 가 컴퓨터 사용을 통해 실제 애플리케이션을 테스트하도록 할 수 있습니다. iOS 의 성능 개선 작업을 위해 @dimillian 은 가장 정확한 환경을 위해 실제 물리적 장치를 사용하기도 했습니다.
5. 시각적 목표에 주의하기
Codex 에게 "이 이미지를 기반으로 이 UI를 100% 픽셀 완벽하게 구현" 과 같은 시각적 목표를 제공하는 것은 유혹적일 수 있지만 설정에 따라 문제를 일으킬 수도 있습니다.
올바른 지침과 제약 조건을 제공하지 않으면 전반적인 목표를 무시하고 일부 문제에 빠져들 수 있습니다. 예를 들어, 참조에 Codex 가 생성해야 하는 SVG 아이콘이나 이미지와 같은 그래픽이 포함된 경우 문제를 적절히 분석하지 않고 정확성을 얻는 데 집중할 수 있습니다.
또한 Codex 는 시각적 비교를 올바르게 수행할 도구가 필요하므로 더 많은 이미지 입력과 전반적인 토큰 사용량 증가로 이어질 수 있으며, Codex 가 기회를 식별할 쉬운 방법을 제공하지 못할 수 있습니다.
대신 이미지는 종종 목표를 향해 나아가는 데 도움이 되는 유용한 컨텍스트를 제공할 수 있지만, Codex 가 목표에 도달했음을 식별할 수 있는 다른 방법(예: 기능 체크리스트, 구현할 사양, 디자인 시스템 준수 등)을 찾아야 합니다.
6. 진행 상황 추적하기
Codex 가 백그라운드에서(또는 다른 머신에서) 몇 시간 또는 며칠 동안 작업하게 되면 Codex 가 얼마나 진행되었는지 또는 어떤 작업이 수행되었는지 추적하기 어려울 수 있습니다. 목표에 따라 진행 상황을 따라잡는 데 도움이 되는 몇 가지 방법이 있습니다.
- 의미 있는 단계에서 Codex 에게 커밋하고 초안 PR로 푸시하도록 요청하세요. 특히 프리뷰 배포가 있는 웹사이트에서 작업하는 경우 유용합니다.
- Codex 가 임원진을 위한 아티팩트를 업데이트하도록 하세요. 인앱 브라우저에서 열어두거나 Sites를 사용하여 팀에 배포할 수 있는 HTML 파일, 진행 상황을 추적하는 렌더링된 그래프 이미지 또는 일반 마크다운 파일이 될 수 있습니다.
- Codex 에게 업데이트를 게시하도록 지시하세요. 목표의 일부로 Codex 에게 주요 진행 상황을 Slack 채널이나 진행 상황을 문서화하려는 다른 곳에 다시 전달하도록 요청할 수도 있습니다.
- 다른 채팅을 사용하여 상태 업데이트를 요청하세요. 현재 상태를 빠르게 확인하고 싶다면 /side 를 실행하여 새로운 사이드 채팅을 열고 거기서 질문할 수 있습니다. 현재 스레드를 포크하기 때문에 이 시점까지의 모든 컨텍스트를 가지고 있지만 수명이 짧습니다. Codex 앱의 대안은 일반 새 채팅에서 Codex 에게 다른 목표 스레드를 읽고 질문에 답변하도록 요청하는 것입니다. Codex 에게 정기적으로 확인하는 자동화를 예약하도록 요청하면 특히 강력할 수 있습니다.
7. 정리 및 최종 결과 확정하기
좋습니다, 드디어 목표를 달성했습니다! 이제 팀에 $yeet 하고 끝낼 시간인가요?
일반적으로 특히 최적화 작업의 경우 Codex 가 수행된 작업을 되돌아보고 검토하도록 하는 것이 도움이 된다는 것을 알게 되었습니다. /review 로 시작하여 로컬 코드 리뷰를 실행할 수 있지만, Codex 가 목표를 해결하기 위해 시도한 다양한 접근 방식을 더 깊이 되돌아보고 그에 따라 정리하도록 하는 것도 가치가 있습니다.
Codex 는 목표에 도달할 때까지 계속 진행되므로 변경 사항에 남아 있을 수 있는 충분히 효과적이지 않거나 전혀 효과가 없는 여러 가지를 시도했을 수 있습니다.
다음 작업을 목표로 삼을 시간입니다
Codex 의 목표 기능은 직면하는 가장 의미 있는 문제를 해결하기 위한 매우 강력한 도구이지만, 올바른 환경과 지침을 제공하면 목표에 더 효율적으로 도달할 수 있습니다.
/goal 을 어떤 용도로 사용하셨나요?
https://x.com/OpenAIDevs/status/2057530209470210453
