ChatGPT Pro에서 계획하고 Codex에서 실행하기: 디자인 문서 핸드오프 플레이북

이번 달에 훔쳐 쓸 만한 워크플로는 모델이 아니라 역할 분담이다. 당신은 GPT-6 Pro에게 ChatGPT에서 저장소 URL을 건네고, 패치가 아니라 설계 문서를 요청한 다음, 그 문서를 Codex 또는 Claude Code에 넘겨 구현하게 한다. 기획자는 GPT-6 Astra 위에서 실행된다 — GPT-6 Pro는 ChatGPT의 사용량 한도가 그것을 부르는 이름이다 — 그리고 Astra는 2026-09-03 모델이므로, 여기서 말하는 어떤 것도 출시 보도나 릴리스 주장이 아니다. 지난 7일 사이에 달라진 것은 더 좁은 범위이며, 정확히 짚을 가치가 있다: 2026-09-17에 실무자들은 ChatGPT Work도 Codex도 아닌, 일반 ChatGPT Chat의 공식 GitHub 플러그인이 Codex/Work 허용량을 소모하지 않고 저장소 파일을 편집하고 커밋하며 풀 리퀘스트를 열 수 있다고 보고했다. 이는 커뮤니티 주장이지 벤더 문서가 아니다 — 공식 도움말 페이지는 여전히 GitHub 앱을 읽기 전용으로 설명하며 모든 쓰기 작업을 Codex로 라우팅한다 — 그리고 여기에 딸린 단서들은 그 주장만큼이나 중요하다. 아래의 모든 내용은 벤더 보고, 커뮤니티 보고, 또는 2026-09-19에 공식 페이지에서 직접 확인한 것으로 표시되어 있다.

워크플로우, 한 번에

실무자들은 같은 루프를 조금씩 변형해 설명한다. 되풀이되는 방식은 이것이다. GitHub 주소를 ChatGPT에 붙여 넣고, 코드를 읽고 설계 문서를 만들어 달라고 요청한 뒤, 그 문서를 내려받아 실행 에이전트에 넣는다. 일부는 풀 리퀘스트도 요청하고, 다른 이들은 문서에서 멈추고 실행자가 작성을 맡게 한다. 어느 쪽이든 형태는 동일하다 — 채팅 제품에서 계획하고 에이전트 제품에서 구축한다 — 그리고 이 방식을 따라 할 가치가 있는 이유는 두 부분이 별도로 과금되기 때문이다.

• 기획 산출물 — 설계 문서: 추가할 인터페이스, 경로로 명시된 수정 대상 파일, 마이그레이션 순서, 인수 테스트, 그리고 문제가 생겼을 때 해야 할 일.

• 실행 산출물 — 방금 작성한 테스트를 실행할 수 있는 에이전트가 생성한 브랜치와 풀 리퀘스트.

• 리뷰 산출물 — 리뷰어에게 도달해야 하는 유일한 것인 diff.

설계 문서는 핵심을 지탱하는 부분이며, 두 가지 이유로 제자리를 얻습니다. 첫째, 문서는 이식 가능합니다. 실행자가 Codex든 Claude Code든 직접 작성한 스크립트 에이전트든 동일한 텍스트가 작동하므로, 비용을 들인 계획이 특정 벤더의 도구에 묶이지 않습니다. 둘째, 그것은 검토 표면이며, 앞서 무엇이든 저장소에 작성되기 전에 존재합니다 — 이는 채팅 제품의 쓰기 경로가 전체 구조에서 가장 문서화가 덜 된 부분이라는 점을 고려하면 매우 중요합니다.

두 버킷 구조가 전부인 이유

ChatGPT는 이 워크플로를 하나의 재원에서 청구하지 않습니다. Chat, ChatGPT Work, Codex는 각각 별도의 할당량을 가지며, Work와 Codex는 둘 사이에서 하나의 풀을 공유합니다. OpenAI API 키는 다시 별도 청구입니다. 바로 그 구조가 핸드오프를 경제적으로 만듭니다. 사고는 Chat 버킷에서 일어나고, 실행은 에이전트 버킷에서 일어나며, 설계 문서에는 Chat 메시지 하나가 소요되는 반면 구현에는 에이전트 사용량이 소요됩니다.

숫자는 OpenAI가 Chat 쪽에 대해 공개한 그대로입니다 — 공급업체가 자체 요금제 문서에 보고한 수치이며, 측정값이 아닙니다:

• 월 $200의 ChatGPT Pro — 주당 200개의 GPT-6 Pro 메시지; GPT-5.6 Sol Pro는 추가로 하루 170개를 제공하며, 두 모델을 합치면 하루 200개로 제한됩니다.

• 월 $100의 ChatGPT Pro — 주당 50개의 GPT-6 Pro 메시지, GPT-5.6 Sol Pro와 공유되는 허용량에서 제공됩니다.

• Business Standard — 월 15개의 GPT-6 Pro 메시지, Sol Pro와 공유; Business Premium — 동일한 공유 기준으로 주당 50개.

• ChatGPT Plus — Chat에서는 GPT-6 Pro를 전혀 사용할 수 없습니다. Astra는 ChatGPT Work와 Codex를 통해서만 Plus에 도달하는데, 이는 바로 이 플레이북이 보호하려는 범주입니다.

Work/Codex 측에서 OpenAI는 한도가 아니라 추정치를 공개하며, 그렇게 밝힙니다. Plus에서는 5시간 구간당 대략 5~45개의 Astra 메시지, Pro 5x에서는 25~225개, Pro 20x에서는 100~900개이며, 같은 페이지에서는 실제 소비량이 작업 복잡도, 컨텍스트, 출력, 도구 사용에 따라 달라지고 주간 한도가 추가로 적용될 수 있다고 명시합니다. 이 범위는 동등한 Sol 수치의 대략 절반에 해당하는데, 이는 프런티어 모델을 에이전트로 실행하는 비용을 애초에 감당할 수 있게 하는 산술적 이유입니다.

실질적인 결과는 카드에 적어 둘 수 있는 예산 배분 규칙이다. Chat 메시지는 결정에, 에이전트 사용은 코드에 써라. 인터페이스에 대해 20분 동안 논쟁하는 계획 세션은 Chat 메시지 몇 개를 소모하고, 에이전트가 탐색적으로 편집하는 한 시간을 절약해 주는 문서를 만들어 낸다 — 이것이 바로 이 스레드의 실무자들이 실제로 감수하고 있는 트레이드오프다.

쓰기 경로: 커넥터가 실제로 하는 일과 사람들이 그것이 한다고 주장하는 일

여기서 자료들은 서로 엇갈리는데, 바로 그 엇갈림이 흥미로운 부분이다.

OpenAI 자체 도움말 문서는 명확합니다. ChatGPT의 GitHub 앱은 분석 및 검색을 위해 여러분의 저장소를 읽으며, 코드를 생성하고 편집하고 GitHub에 푸시하는 것은 Codex의 용도입니다. 그것이 읽기 전용 입장이며, 이를 팀 프로세스에 도입한다면 계획의 기준으로 삼아야 할 입장입니다. 왜냐하면 그것이 배후에 공급업체를 둔 입장이기 때문입니다.

2026-09-17자 커뮤니티 입장은, 웹 버전의 GitHub 플러그인이 Chat 모드에서 코드를 편집하고 커밋하며 풀 리퀘스트를 열 것이며, 서드파티 MCP 서버가 아닌 공식 플러그인이기 때문에 Codex나 Work 할당량을 소모하지 않는다는 것입니다. 같은 스레드는 범위에 대해 신중합니다: 작은 도구, 사소한 수정, 작은 버그 — 대규모 리팩터링과 어려운 디버깅은 여전히 Codex의 몫입니다. 해당 스레드의 댓글 작성자들은 반복할 가치가 있는 주의사항을 덧붙입니다. 왜냐하면 실제로 발목을 잡는 것은 바로 그것들이기 때문입니다:

• 일반 ChatGPT 요청 한도는 그대로 적용됩니다. "Codex 할당량이 아님"이 "무료"라는 뜻은 아닙니다.

• 여러 라운드를 거치면 예고 없이 품질이 저하될 수 있으며, 작업 도중 세션이 더 작은 모델로 전환될 수 있습니다.

• 이 스레드의 작성자들은 인터페이스가 Work로 전환할 것을 제안하더라도 전환하지 말라고 조언하며, 익명 채팅 페이지를 마구 두드리면 모든 사람의 웹 경험이 저하된다고 경고한다.

동일한 패턴에 대한 독립적인 일본어 기사는 할당량 주장 없이도 호환되는 결론에 도달한다: GitHub 통합이 쓰기 작업을 지원한다면, 일반 채팅은 저장소를 읽고, 파일을 수정하고, 브랜치를 만들고, 풀 리퀘스트를 열 수 있다; 일반 채팅 속도 제한이 적용된다; 그리고 Codex와 Work는 공유 에이전트 풀을 사용하므로, 일반 채팅은 몇 개 파일 편집용이고 Codex는 긴 소프트웨어 작업용이다. 두 설명이 일치하는 부분에서, 그 일치가 활용 가능한 부분이다: 채팅은 작은 변경 채널이고, Codex는 긴 세션 채널이며, 풀은 분리되어 있다.

실제 git 워크플로—브랜치, diff, 커밋, 푸시, 풀 리퀘스트 열기—를 노출하는 서드파티 MCP 서버가 있으며, 권한은 읽기 전용부터 푸시까지 등급을 매길 수 있습니다. 쓰기 경로가 기대하는 동작이 아니라 결정적이고 감사 가능하기를 원한다면, 그것이 그 경로입니다; OpenAI가 문서화한 범위 안에 머물고 싶다면 Chat에서 계획하고 Codex에서 작성하세요.

어느 쪽이든, 설계 문서 핸드오프가 채팅 쓰기 경로를 정당화할 수 있게 만드는 요소입니다. 리포지토리에 대한 쓰기 범위를 가진 채팅 세션은 읽기 범위를 가진 채팅 세션보다 더 큰 권한 부여이며, 그 문서는 해당 권한 부여가 행사되기 전에 검토하는 산출물입니다.

핸드오프, 단계별로

• 플래너가 저장소를 가리키게 하세요 — 프롬프트에 붙여넣은 공개 URL, 또는 권한을 부여했다면 GitHub 커넥터를 — 그리고 무엇이든 제안하기 전에 코드를 읽어 달라고 요청하세요.

• 패치가 아니라 설계 문서를 요구하세요. 파일 경로, 추가되거나 변경되는 인터페이스, 변경 사항이 반영되어야 하는 순서, 그리고 각 단계를 입증하는 테스트를 명시하도록 하세요.

• 실제로 읽은 파일을 인용해 달라고 요청하세요. 저장소에 존재하지 않는 인터페이스를 설명하는 설계 문서는 이 워크플로가 실패하는 가장 흔한 방식이며, 인용문은 스프린트가 아니라 1분 만에 그것을 잡아내는 방법입니다.

• 문서를 다음 도구에 붙여 넣지 말고 저장소에 저장하세요. 파일을 읽는 실행자는 파일을 다시 읽을 수 있지만, 붙여 넣기를 받은 실행자는 단 한 번의 기회만 가집니다.

• 문서를 지시문 삼아 실행기를 시작하고, 풀 리퀘스트 하나의 범위를 문서의 한 섹션으로 한정하세요. 긴 세션이야말로 에이전트 품질이 조용히 저하되는 곳입니다.

• 이후에는 플래너를 검토 전용 역할로 유지하세요. 문서가 잘못되었으면 다시 계획을 세우고 문서를 갱신하세요 — 실행자가 문서를 벗어나 즉흥적으로 처리하도록 내버려 두지 마세요. 즉흥적인 작업이야말로 문서가 존재하는 이유였던 것을 막기 위한 것이기 때문입니다.

어디서 부러지는가

• 저장소 상태가 오래됨 — 기능 브랜치에서 작업 중인데 플래너가 기본 브랜치를 읽었으므로 문서의 파일 경로가 한 버전 뒤처져 있습니다. 어느 브랜치를 읽어야 하는지 알려주거나 브랜치 트리를 붙여넣으세요.

• 설계 문서 드리프트 — 문서와 코드가 서로 어긋나는데, 실행자는 문서를 따릅니다. 위의 파일 인용 단계가 저렴한 보험입니다.

• 잘못된 방향으로 튀는 할당량 — 20분짜리 계획 대화는 Chat 메시지 측면에서는 저렴하고 주의력 측면에서는 비싸며, 긴 에이전트 실행은 그 반대다. 실제로 소비하는 버킷에 예산을 배정하세요.

• 조용한 다운그레이드 — 여러 차례 대화를 주고받은 뒤 더 작은 모델로 성능이 저하된 채팅 세션이라도 여전히 자신감 넘치는 설계 문서를 만들어냅니다. 문서를 검토할 때는 플래그십 모델이 작성했다는 가정에 기대지 말고, 문서 자체의 가치를 기준으로 판단하세요.

• 권한 확대 — 플러그인이든 MCP 서버든, 쓰기 경로는 채팅 세션에 코드를 변경할 수 있는 능력을 부여합니다. 권한을 등급화하고, 변경이 반영되면 권한을 회수하세요.

executor 절반을 하나의 엔드포인트를 통해 실행

이 워크플로의 계획 절반은 구독 제품 안에 존재하며, 그 부분은 어쩔 수 없는 그대로입니다. 실행 절반은 API 호출이고, 바로 그 절반이 소유할 가치가 있는 부분입니다. 실행기를 스크립트로 만든다면 — 승인된 설계 문서를 브랜치로 바꾸는 작은 에이전트 루프, CI 작업 — 모델 호출만이 교체 가능해야 하는 유일한 조각입니다. 왜냐하면 다음 분기에 원하게 될 모델은 오늘을 기준으로 계획하고 있는 모델이 아니기 때문입니다.

그것이 바로 라우팅 레이어의 존재 이유입니다. openai/gpt-6-astra과 동일한 OpenAI 호환 엔드포인트 뒤에 위치하며, 200개 이상의 다른 모델공급자 정가가 0% 마진으로 그대로 전달됩니다 — 따라서 공급업체가 가격을 변경하면 우리 쪽 가격도 다음 계약 갱신 때가 아니라 같은 날에 변경됩니다. 자동 장애 조치를 사용하면 검증되지 않은 모델을 트래픽의 일부에 배치하고 그 아래에 검증된 모델을 둘 수 있는데, 이는 저렴한 실행기가 테스트에 충분히 적합한지 알아내는 정직한 방법입니다. 그리고 라우팅 DSL은 여러 모델을 하나의 호출로 구성하므로, 검토자 모델이 동일한 키에서, 동일한 요청 경로 내에서 실행기의 diff를 확인할 수 있고 별도의 통합이 필요 없습니다.

그중 어느 것도 핸드오프의 구조를 바꾸지 않습니다. 그것은 당신이 통제하는 절반을 실험하는 데 드는 비용을 바꿉니다: 키 하나, 엔드포인트 하나, 그리고 파이프라인을 건드리지 않고 바꿀 수 있는 모델 문자열.

지금 누가 이것을 실행해야 하고, 누가 기다려야 합니까?

이미 Pro 등급으로 ChatGPT 플랜을 결제하고 있고 이미 Codex나 Claude Code를 실행하고 있다면, 이번 주에 이 핸드오프를 도입할 가치가 있습니다. 청구서에서 두 항목이 이미 별도로 분리되어 있고, 설계 문서는 루프에서 가장 저렴한 요소이기 때문입니다. 잘못된 계획을 알아차릴 만큼 충분히 이해하는 변경부터 시작하세요: 문서를 요청하고, 인용된 파일을 읽은 다음, 넘겨주세요.

Plus를 사용 중이라면 기대를 낮추세요. Astra는 Work와 Codex를 통해서는 접근할 수 있지만 Chat을 통해서는 안 되므로, 이 플레이북의 기획 절반은 설명된 형태로는 사용할 수 없습니다 — 같은 풀에서 기획하고 실행하게 되어 경제적 논거가 사라지고, 문서를 먼저 작성하는 규율만 남습니다. 그 규율은 여전히 지닐 가치가 있습니다. 할인은 그렇지 않습니다.

그리고 이것을 원하는 이유가 핸드오프가 아니라 Chat의 쓰기 경로 때문이라면, OpenAI의 문서가 포럼 스레드를 따라잡을 때까지 기다리세요. 공급업체 자체의 도움말 페이지가 모순되는 기능은 페이지가 바뀔 때까지 스크래치 저장소에 두어야 할 기능입니다.

동일한 키로 카탈로그의 나머지 부분에도 접근할 수 있으며, 전체 모델 카탈로그를 둘러보면 하나의 OpenAI 호환 엔드포인트 뒤에 무엇이 더 있는지 확인할 수 있습니다.