Codex Goals, 코딩 에이전트의 새 완료 계약
OpenAI Codex Goals는 장시간 코딩 작업을 목표, 검증 표면, 제약, 예산이 붙은 증거 기반 루프로 바꿉니다.
- 무슨 일: OpenAI가 Codex
/goal을 목표, 검증, 제약이 붙은 지속형 작업 루프로 설명했습니다.- Codex 0.128.0 릴리스에는 persisted
/goalworkflows, runtime continuation, TUI controls가 포함됐습니다.
- Codex 0.128.0 릴리스에는 persisted
- 핵심 변화: 코딩 에이전트의 경쟁축이 "얼마나 오래 도나"에서 "무엇을 완료로 인정하나"로 이동합니다.
- 실무 영향: 좋은 Goal은 결과물보다 먼저 테스트, 로그, 벤치마크, 산출물 같은 증거 표면을 정의해야 합니다.
- 주의점: Goals는 무제한 자율성이 아니라 스레드 범위, 예산, 중단 조건이 있는 완료 계약입니다.
OpenAI Codex에 들어간 Goals는 겉으로 보면 작은 slash command처럼 보입니다. 사용자는 /goal 뒤에 목표를 적고, Codex는 그 목표를 향해 여러 턴 동안 작업합니다. 하지만 OpenAI가 5월 9일 공개한 Cookbook 문서와 4월 30일 openai/codex 0.128.0 릴리스 노트를 같이 읽으면, 이 기능의 핵심은 "계속 실행"이 아니라 "완료 조건을 제품 표면으로 끌어올린 것"에 가깝습니다.
이 차이는 중요합니다. 지금까지 코딩 에이전트를 쓰는 개발자는 자주 같은 말을 반복했습니다. 계속 진행해 주세요. 다음 가능성이 높은 수정을 시도해 주세요. 테스트를 다시 돌려 주세요. 실패하면 다른 접근을 찾아 주세요. 이런 문장은 사실 하나의 작업 계약입니다. 다만 그 계약이 프롬프트 사이에 흩어져 있었을 뿐입니다. Codex Goals는 이 계약을 스레드의 지속 상태로 붙입니다. 목표, 검증 방법, 제약, 경계, 반복 정책, 막혔을 때의 중단 조건을 한곳에 묶는 방식입니다.
OpenAI 문서는 Goals를 "persistent objectives"라고 설명합니다. 더 구체적으로는 Codex가 어떤 결과를 향해 일해야 하는지, 성공을 어떻게 확인해야 하는지, 어떤 제약을 깨면 안 되는지를 담는 완료 조건입니다. GitHub의 openai/codex 0.128.0 릴리스 노트도 새 기능 첫 항목으로 persisted /goal workflows를 적고, app-server APIs, model tools, runtime continuation, create/pause/resume/clear용 TUI controls를 함께 언급합니다. 단순한 문서 팁이 아니라 Codex 런타임과 UI에 들어간 작업 모델 변화입니다.
프롬프트 다음의 작업 단위
일반 프롬프트는 "다음 일을 해 달라"는 요청입니다. Codex가 코드를 읽고, 수정하고, 테스트하고, 결과를 보고한 뒤 기다립니다. 반면 Goal은 "이 결과가 참이 될 때까지 일하라"는 요청입니다. 이때 핵심은 기다리지 않는 것이 아니라, 기다릴지 계속할지를 판단하는 기준이 스레드에 남는다는 점입니다.
OpenAI Cookbook은 이 차이를 ask -> work -> result -> wait와 work -> check -> continue or complete의 차이로 설명합니다. 한 번의 요청에서는 결과를 내고 멈추지만, Goal이 활성화된 스레드는 작업 뒤에 현재 증거를 확인합니다. 목표가 아직 충족되지 않았고 예산과 상태가 허용하면 다음 유용한 행동을 선택할 수 있습니다.
이 이미지는 Goals가 스레드에 붙이는 네 가지 요소를 잘 보여줍니다. durable state, evidence check, lifecycle controls, continuation입니다. 여기서 눈여겨볼 부분은 "스레드 범위"입니다. OpenAI 문서는 Goals가 global memory도 아니고 project-level instruction도 아니라고 선을 긋습니다. Goal은 현재 스레드에 묶입니다. 그 스레드 안에는 Codex가 읽은 파일, 실행한 명령, 본 로그, 만든 diff, 생성한 산출물, 축적한 추론 경로가 있습니다.
이 설계는 코딩 에이전트의 신뢰 문제와 직접 연결됩니다. 목표가 전역 메모리로 흘러가면 의도치 않은 작업에 영향을 줄 수 있습니다. 반대로 매 턴 프롬프트로만 남으면 장시간 작업에서 목표가 흐려집니다. 스레드 단위 상태는 두 극단 사이의 타협입니다. 충분히 오래 남아 작업을 이어갈 수 있지만, 해당 작업의 증거 맥락 밖으로 번지지 않습니다.
좋은 Goal은 긴 프롬프트가 아닙니다
OpenAI 문서가 가장 강하게 강조하는 대목은 "좋은 Goal은 더 큰 프롬프트가 아니다"라는 점입니다. 좋은 Goal은 작은 계약에 가깝습니다. 결과가 무엇인지, 그 결과를 무엇으로 검증할지, 어떤 제약을 보존해야 하는지, 어디까지 건드릴 수 있는지, 반복 사이에 무엇을 기록해야 하는지, 더 이상 방어 가능한 경로가 없을 때 무엇을 보고해야 하는지를 담아야 합니다.
예를 들어 "성능을 개선해"는 Goal로 약합니다. 이 문장에는 완료 조건이 없습니다. 반면 "checkout benchmark에서 p95 latency를 120ms 아래로 낮추고 correctness suite는 green으로 유지하라"는 Goal은 훨씬 강합니다. 목표 숫자가 있고, 검증 표면이 있고, 깨면 안 되는 제약이 있습니다. Codex가 벤치마크를 실행하고, 핫패스를 조사하고, 수정을 만들고, 다시 벤치마크를 돌린 뒤, correctness suite를 확인할 수 있습니다.
이 구조는 일반적인 개발 자동화에도 그대로 적용됩니다. 마이그레이션이라면 새 경로가 contract test를 통과하고 기존 경로에는 rollback이 남아 있어야 합니다. flaky test 조사라면 재현 로그, 실패 빈도, 수정 후 반복 실행 결과가 있어야 합니다. 연구 재현이라면 어떤 주장은 정확히 재현됐고, 어떤 주장은 근사 재구성에 그쳤고, 어떤 주장은 원자료 부족으로 막혔는지 나누어야 합니다.
여기서 코딩 에이전트의 숙제가 드러납니다. "완료"는 모델이 자신 있게 말한다고 생기지 않습니다. 완료는 증거로 만들어집니다. 테스트 결과, 벤치마크 출력, 로그, diff, 생성 파일, 배포 상태, 재현 보고서가 있어야 합니다. Goals는 이 증거 표면을 작업 시작 전에 묻게 만듭니다.
| 구분 | 약한 지시 | 강한 Goal |
|---|---|---|
| 성능 | 성능을 개선합니다. | p95 latency를 특정 기준 아래로 낮추고 correctness suite를 유지합니다. |
| 마이그레이션 | 새 스택으로 옮깁니다. | 화면 동등성, 테스트, rollback 경계를 함께 검증합니다. |
| 연구 | 논문을 재현합니다. | 확인, 근사, 차단, 불확실성을 분리한 증거 보고서를 만듭니다. |
자동 루프가 아니라 보수적인 continuation
Goals를 "무한 루프 코딩 에이전트"로 읽으면 핵심을 놓치기 쉽습니다. OpenAI 문서는 continuation이 단순 반복문이 아니라 event-driven이라고 설명합니다. Codex는 아무 때나 다음 턴을 시작하지 않습니다. 현재 턴이 끝났고, 다른 작업이 대기 중이지 않고, 사용자 입력이 queued 상태가 아니며, 스레드가 idle이고, Goal이 active이고, 예산 안에 있을 때만 continuation을 검토합니다.
또 하나의 안전장치도 흥미롭습니다. continuation turn이 tool call을 만들지 않으면 다음 자동 continuation은 억제됩니다. 모델이 말만 반복하며 헛도는 상황을 줄이려는 장치입니다. 사용자가 interrupt하면 목표는 멈출 수 있고, pause, resume, clear 같은 생명주기 제어는 명령 표면에 남습니다. 예산에 도달하면 substantive work를 멈추고 진행 상황과 blocker, 다음 유용한 단계를 요약해야 합니다. 예산 제한은 완료가 아닙니다.
이런 조건들은 코딩 에이전트 시장에서 중요한 신호입니다. 작년과 올해의 경쟁은 "에이전트가 터미널과 브라우저를 쓸 수 있는가", "원격에서 PR을 만들 수 있는가", "IDE 밖에서도 계속 일할 수 있는가"에 집중됐습니다. 이제 다음 질문은 "그 에이전트가 멈춰야 할 때를 어떻게 아는가"입니다. Goals는 이 질문에 대한 OpenAI식 답입니다. 오래 도는 것만으로는 충분하지 않고, 완료를 선언할 권한은 증거와 사용자 계약에 묶여야 한다는 답입니다.
왜 지금 이 기능이 중요한가
Codex Goals는 아주 작은 기능처럼 보여도, 시장 맥락에서는 꽤 큰 방향 전환입니다. GitHub Copilot은 cloud agent와 Agents tab, 데스크톱 앱, 원격 세션 제어를 빠르게 확장하고 있습니다. Anthropic은 Claude Code와 기업용 Claude 배포를 통해 개발자와 지식노동자의 실제 도구 표면으로 들어가고 있습니다. Cursor는 Composer 2.5에서 긴 작업과 RL feedback을 강조합니다. 모두 "에이전트가 더 많은 일을 맡는다"는 같은 방향을 가리킵니다.
그런데 에이전트가 맡는 일이 길어질수록 실패의 성격도 달라집니다. 한 번의 코드 생성 실패는 리뷰에서 잡을 수 있습니다. 하지만 다섯 시간짜리 자동 마이그레이션이 잘못된 완료 기준으로 달리면 비용이 커집니다. 테스트는 통과했지만 제품 요구사항을 놓쳤을 수 있고, 벤치마크는 좋아졌지만 회귀가 생겼을 수 있으며, 연구 보고서는 그럴듯하지만 원자료가 없는 추정을 사실처럼 썼을 수 있습니다.
Goals는 이런 실패를 완전히 없애지는 못합니다. 대신 실패를 다룰 언어를 줍니다. "목표가 부정확했다", "검증 표면이 약했다", "제약이 빠졌다", "blocked stop condition이 없었다", "예산 제한을 완료로 오해했다"처럼 문제를 분해할 수 있게 합니다. 코딩 에이전트 운영에서 이 언어는 중요합니다. 팀이 에이전트 실패를 모델 탓으로만 돌리지 않고, 작업 계약의 품질을 개선할 수 있기 때문입니다.
OpenAI가 5월 8일 공개한 "Running Codex safely at OpenAI"도 같은 방향을 보입니다. 그 글은 Codex를 실제 워크플로에 배포할 때 접근 경계, 승인 조건, telemetry, audit이 필요하다고 설명합니다. Goals는 이 안전 논리의 작업 단위 버전으로 볼 수 있습니다. 에이전트가 어떤 시스템에 접근할 수 있는지뿐 아니라, 어떤 증거를 보고 완료라고 말할 수 있는지도 운영 표면이 됩니다.
개발팀은 무엇을 바꿔야 하나
개발자가 Goals에서 바로 얻을 수 있는 실무 교훈은 단순합니다. 에이전트에게 긴 일을 맡기기 전에 "done"을 먼저 써야 합니다. 하지만 여기서 done은 체크박스 제목이 아닙니다. 검증 가능한 상태여야 합니다. 다음 네 가지 질문이 최소 기준입니다.
첫째, 결과가 무엇입니까. "리팩터링"이 아니라 "공개 API 동작을 유지한 채 checkout test suite가 통과한다"처럼 관찰 가능한 결과여야 합니다. 둘째, 무엇으로 검증합니까. 테스트 명령, 벤치마크, Playwright 스크린샷, 로그 쿼리, 생성 문서, 배포 URL처럼 확인할 수 있는 표면이 필요합니다. 셋째, 무엇을 건드리면 안 됩니까. 공개 API, 데이터 마이그레이션 경로, 보안 정책, 스타일 시스템, 기존 사용자 변경사항 같은 제약이 명확해야 합니다. 넷째, 막히면 무엇을 보고해야 합니까. 실패 로그, 시도한 경로, 남은 가설, 사람이 줘야 할 입력을 분리해야 합니다.
이 질문은 Codex만의 문제가 아닙니다. Claude Code, Copilot agent, Cursor Composer, 사내 에이전트 런타임에도 그대로 적용됩니다. 에이전트가 강해질수록 프롬프트 작성법보다 작업 명세 작성법이 중요해집니다. 특히 장시간 작업에서는 "좋은 목표"가 곧 안전장치입니다.
커뮤니티 반응이 말하는 것
GeekNews는 5월 20일 기준 "Codex의 Goals를 활용하는 법"을 소개하면서 Goals를 여러 턴에 걸쳐 정의된 결과를 향해 지속되는 기능으로 요약했습니다. Hacker News 첫 화면에는 Cursor Composer 2.5와 Anthropic의 Stainless 인수가 함께 올라와 있었습니다. 둘 다 같은 흐름을 보여줍니다. 개발자 커뮤니티의 관심은 점점 "어떤 모델이 더 똑똑한가"에서 "에이전트가 실제 개발 워크플로에 어떻게 붙는가"로 이동하고 있습니다.
Reddit 반응은 더 현실적입니다. 어떤 사용자는 /goal을 오랫동안 실행했다는 경험을 공유했고, 다른 사용자는 많은 체크리스트가 남은 상태에서 Codex가 멈췄다고 질문했습니다. 이 상반된 반응은 Goals의 본질을 잘 보여줍니다. Goals는 마법의 자동 완성 버튼이 아닙니다. 목표가 모호하거나, 검증 표면이 약하거나, 예산과 중단 조건이 작업 크기와 맞지 않으면 사용자는 여전히 실망합니다. 반대로 목표가 잘 정의되면 Codex가 다음 행동을 선택할 여지가 생깁니다.
따라서 이 기능의 성공 여부는 OpenAI의 구현만으로 결정되지 않습니다. 사용자가 일을 어떻게 쪼개고, 팀이 어떤 테스트와 로그를 제공하고, 제품이 예산과 상태를 얼마나 명확하게 보여주느냐가 함께 작동해야 합니다. 코딩 에이전트는 혼자 똑똑해지는 것이 아니라, 주변의 검증 인프라와 결합할 때 실무 도구가 됩니다.
완료 조건이 제품이 되는 시대
Codex Goals의 가장 흥미로운 점은 "목표"가 프롬프트 내용에서 제품 상태로 올라왔다는 점입니다. 목표는 이제 잠깐 적고 사라지는 문장이 아니라, active, paused, complete, budget-limited 같은 상태를 갖는 객체입니다. 이 객체는 continuation을 허용하거나 막고, 예산에 도달하면 요약을 요구하며, 완료 선언을 증거에 묶습니다.
이 변화는 앞으로 코딩 에이전트 UI가 어디로 갈지 힌트를 줍니다. 에이전트 제품에는 채팅창만으로 부족합니다. 목표 목록, 검증 표면, 현재 증거, 남은 blocker, 예산 사용량, 사람이 승인해야 할 위험 작업, 완료 판정의 근거가 보여야 합니다. GitHub의 Agents tab, Cursor의 session UI, Claude Code의 permission flow, Codex의 Goals는 서로 다른 형태로 같은 운영 계층을 만들고 있습니다.
개발팀 입장에서는 이 흐름을 낙관과 회의 사이에서 봐야 합니다. 낙관할 이유는 분명합니다. 잘 정의된 Goal은 개발자가 반복적으로 "계속해"라고 말하던 시간을 줄이고, 성능 튜닝이나 flaky test 조사처럼 길고 지루한 작업을 더 안정적으로 맡길 수 있게 합니다. 회의해야 할 이유도 분명합니다. 완료 조건을 잘못 정의하면 에이전트는 잘못된 목표를 성실하게 달성할 수 있습니다. 증거 표면이 부실하면 그럴듯한 보고서가 완성으로 포장될 수 있습니다.
결국 Codex Goals가 던지는 질문은 제품 기능 하나보다 큽니다. AI 코딩 에이전트에게 일을 맡긴다는 것은 무엇을 의미합니까. 이제 답은 "프롬프트를 잘 쓰는 것"에서 조금씩 멀어지고 있습니다. 더 정확한 답은 "완료를 증명할 수 있는 작업 계약을 쓰는 것"입니다. OpenAI가 Codex에 붙인 /goal은 그 계약을 명령어와 스레드 상태로 만든 첫 번째 명확한 사례 중 하나입니다.
이제 코딩 에이전트 경쟁에서 중요한 문장은 "이 모델이 코드를 얼마나 잘 쓰는가"만이 아닙니다. "이 에이전트는 무엇을 보고 끝났다고 말하는가"입니다. Codex Goals는 그 질문을 개발자 앞에 직접 꺼내 놓았습니다.