업데이트 — 2026년 여름: 제 환경에서는 더 이상 통하지 않았다
2026년 여름이 되자 이 workflow는 제 환경에서 더 이상 안정적으로 작동하지 않았다. 계정에서 5시간 사용량 창의 표시가 사라지고 주간 한도만 보였다. 결과적으로 예전에 이 방법의 기준으로 삼았던 짧은 리셋 주기를 더 이상 전제로 할 수 없었다.
더 중요한 변화는 장시간 작업의 동작이었다. 큰 Codex 작업이 제 주간 한도의 끝에 도달했을 때, 예전처럼 완료까지 계속 진행되는 대신 작업이 멈추는 경우를 봤다. 그래서 “마지막 3–5%에서 가장 무거운 작업을 시작한다”는 예전 규칙은 제게 거의 의미가 없어졌다. 이미 시작한 작업이 주간 한도 종료를 넘어 계속될 것이라고 기대할 수 없었기 때문이다.
다만 제가 관찰한 현상과 공식 제품 규칙은 분리해서 써야 한다. 제가 확인할 수 있는 것은 제 계정과 workflow에서 실제로 일어난 일뿐이며, OpenAI가 모든 사용자에게서 5시간 창을 영구적으로 없앴다고 증명할 수는 없다. 실제로 OpenAI의 현재 Codex 문서는 5시간 창과 주간 창을 모두 언급하고 있으며, 한도에 도달한 뒤에도 fair-use 제한 내에서 진행 중인 turn이 계속될 수 있다고 설명한다. 따라서 2026년 여름의 변화는 제가 실제로 경험한 동작으로 기록하되 모든 계정에 적용되는 보편적 규칙으로는 다루지 않는다.
아래 본문은 이 변화 이전에 제 환경에서 실제로 작동했던 workflow의 기록으로 남겨 둔다. 현재 상황은 기존 본문의 현재형 권장보다 이 업데이트를 우선해서 봐야 한다.
ChatGPT Plus에서 쓰는 Codex의 사용량 표시가 약 3–5% 남으면 저는 그 잔여분을 작은 프롬프트에 쓰지 않습니다. 반대로, 이미 준비해 둔 가장 큰 개발 작업을 시작합니다.
제 경우에는 전체 TypeScript 마이그레이션, 저장소 전반의 ESLint 정리, 대규모 codebase의 심층 버그 리뷰, 큰 구조적 리팩터링 같은 작업입니다. 여러 프로젝트를 미리 준비해 두고, 마지막 사용량을 실제로 실행 가능한 가장 무거운 작업에 투입하는 경우가 많습니다.
이 방식으로 바뀐 이유는 반복해서 본 현상 때문입니다. 눈에 보이는 한도가 거의 끝났을 때 큰 작업을 시작한 뒤, 한도가 소진된 것처럼 보여도 Codex가 계속 작업하는 모습을 여러 번 봤습니다. 어떤 경우에는 그대로 작업이 끝나기도 했습니다. 제 스케줄링을 바꾸기에는 충분히 반복됐지만, 이를 제품이 보장하는 규칙이라고 말할 수는 없습니다.
제 workflow를 바꾼 관찰
사용 한도에 가까워지면 보통 보수적으로 행동하게 됩니다. 큰 task는 중간에 끊길 수 있으니 남은 양을 작은 요청에 쓰고 싶어집니다. 저는 이제 마지막 3–5%를 반대로, 새로운 작업을 시작하는 launch window로 봅니다.
질문은 더 이상 “작은 프롬프트를 몇 개 더 보낼 수 있을까?”가 아닙니다. “포함된 사용량이 남아 있을 때, 준비된 작업 중 어떤 것을 시작하는 게 가장 가치 있을까?”입니다.
이 방식이 가능한 이유는 프로젝트가 이미 준비되어 있고 task 범위가 명확하기 때문입니다. 마지막 몇 퍼센트를 무엇을 할지 탐색하는 데 쓰지 않습니다. 실행을 시작하는 데 씁니다.
이름과 한도에 대한 중요한 정정
처음에는 이를 “Codex Plus”라고 불렀지만, 이는 편의상 쓰는 표현이지 공식 제품명이 아닙니다. OpenAI는 Codex가 ChatGPT Plus에 포함된다고 설명합니다. 이 부분을 바로잡아야 Codex Plus가 별도의 요금제나 제품처럼 보이지 않습니다.
OpenAI의 현재 Codex 사용 문서는 사용량이 작업의 크기와 복잡도, 모델, task가 실행되는 위치에 따라 달라진다고 설명합니다. 또한 5시간 window와 주간 window를 포함한 사용 구간을 문서화하고 있습니다. 따라서 여기서 “3–5%”는 usage UI에 표시되는 남은 비율을 뜻하며, 실제 시간이나 token의 3–5%, 혹은 보장된 개발 작업량을 뜻하지 않습니다.
조건을 충족하는 Plus 사용자는 포함된 한도에 도달한 뒤 credits로 Codex 사용을 연장할 수도 있습니다. 그렇다고 이 workflow가 무의미해지는 것은 아닙니다. 제가 설명하는 것은 포함된 사용량을 어떻게 배분하느냐이지, quota를 우회하는 방법이 아닙니다.
마지막 3–5%에 시작하는 작업
이 시점에 주로 시작하는 것은 범위가 넓은 개발 작업입니다.
- 전체 TypeScript 마이그레이션
- 저장소 전반의 ESLint 정리
- 대규모 codebase의 심층 버그 리뷰
- 큰 구조적 리팩터링
남은 사용량을 가치가 낮은 작은 요청 여러 개로 나누기보다, 이런 작업 중 하나를 하나의 실질적인 작업 단위로 시작하는 편을 선호합니다. 이런 종류의 task에서는 영리한 프롬프트 문구보다 준비된 repository와 명확한 목표가 더 중요합니다.
여러 프로젝트를 미리 준비하는 것도 같은 이유입니다. 어떤 repository에 아직 결정이나 setup이 필요하다면 마지막 window를 준비 작업에 쓰지 않고, 이미 준비된 다른 프로젝트를 시작할 수 있습니다.
실제 제약은 preparation이다
핵심은 “3%까지 기다렸다가 거대한 프롬프트를 붙여 넣는 것”이 아닙니다. Task가 모호하면 제한된 budget이 탐색, 추가 질문, 잘못된 방향의 작업에 쉽게 소모됩니다. 이 패턴은 프로젝트가 실행 가능한 상태이고 task가 충분히 명확할 때만 유용합니다.
비슷한 workflow를 시도한다면 시작 전에 scope를 명시하는 것이 좋습니다. 무엇을 바꿀지, 무엇은 바꾸지 않을지, 어떤 constraint가 있는지, 결과를 어떻게 검증할지, agent에게 어떤 output을 기대하는지 정리합니다. 이는 일반적인 engineering safeguard이지, 특정 prompt 형식이 더 많은 usage를 해제한다는 증거가 아닙니다.
이렇게 준비하면 실제로 한도에서 task가 끊겨도 재개하기 쉬워집니다. Scope와 validation 기준이 처음부터 명확하면 중간까지 진행된 migration이나 review를 이어가기 훨씬 쉽습니다.
확인할 수 있는 것과 확인할 수 없는 것
제 사용 경험에서 확인할 수 있는 것은 제한적입니다. 이미 시작한 task가 눈에 보이는 사용 한도가 소진된 것처럼 보인 뒤에도 여러 번 계속 진행됐고, 일부는 완료됐습니다.
하지만 그 mechanism은 확인할 수 없습니다. OpenAI가 모든 실행 중 task에 숨겨진 grace period를 제공한다거나, 마지막 3–5%만 있으면 어떤 대규모 작업도 끝낼 수 있다거나, 이 behavior가 항상 유지된다거나, 한도를 우회하는 방법이라는 주장은 할 수 없습니다. OpenAI 문서도 이런 내용을 보장하지 않습니다.
이 구분이 중요합니다. 저는 반복해서 관찰한 behavior를 고려해 계획하지만, 보장이라고 가정하지 않습니다. 한도에서 task가 멈춰도 이상한 일이 아닙니다. 남은 포함 사용량을 작은 프롬프트 몇 개보다 더 중요한 작업에 썼다면 전략의 목적은 이미 달성된 것입니다.
작업 완료와 검증 완료는 다르다
Task가 커질수록 또 하나의 구분이 중요해집니다. 완료는 correctness의 증명이 아닙니다. TypeScript migration이 build된다고 runtime behavior가 맞다는 뜻은 아닙니다. ESLint가 깨끗하다고 business logic이 올바르다는 뜻도 아닙니다. Bug review가 의심스러운 pattern을 표시했다고 실제 bug가 확인된 것도 아닙니다. 테스트가 통과한 refactor 역시 그 신뢰도는 test와 check의 coverage에 달려 있습니다.
이 workflow가 바꾸는 것은 작업을 언제 시작하느냐입니다. Validation 기준을 낮추지는 않습니다. 큰 agentic change에는 risk에 맞는 diff review, typecheck, tests, build, runtime checks 또는 프로젝트별 검증이 여전히 필요합니다.
이 패턴이 맞지 않는 경우
모든 큰 task가 end-of-limit task에 적합한 것은 아닙니다. 작업이 아직 모호하거나, 자주 product decision이 필요하거나, destructive 또는 production-sensitive operation을 포함하거나, 중간에 끊겼을 때 repository가 위험한 상태가 된다면 이 접근은 좋지 않습니다.
그런 경우에는 더 작고 명확하게 제한된 task나 새로운 usage window가 더 좋은 engineering 선택입니다. 목표는 마지막 prompt를 극적으로 만드는 것이 아니라, 제한된 포함 사용량을 안전하게 유용한 progress를 만들 수 있는 작업에 쓰는 것입니다.
지금의 제 규칙
ChatGPT Plus에 포함된 Codex 사용량이 약 3–5% 남으면 저는 남은 prompt 개수를 최적화하려 하지 않습니다. 미리 준비한 프로젝트를 보고, scope가 명확하고 할 가치가 있는 가장 무거운 engineering task를 시작합니다.
보이는 counter가 0이 된 뒤에도 Codex가 계속 일하면, 저는 그것을 반복해서 관찰한 유용한 behavior로 받아들일 뿐 보장된 권리로 생각하지 않습니다. 멈춰도 놀라지 않습니다. 저는 limit을 우회하는 방법을 찾은 것이 아닙니다. Limit에 도달하기 전에 무엇을 시작할지 더 잘 결정하는 방법을 찾았습니다.