Codex 사용량 제한과 잦은 리셋, 개발자가 할 수 있는 대비

Codex 사용량이 예전보다 빨리 닳는다는 제보가 2026년 7월 내내 이어졌습니다. OpenAI 는 7월 29일 유료 사용자 전체의 사용량 한도를 리셋하고 GPT-5.6 Sol 의 효율 수정을 함께 배포했습니다. 리셋 공지가 반복되자 그것만 추적하는 커뮤니티 사이트까지 생겼습니다. 이 글은 실제로 무슨 일이 있었는지, 제한이 어떤 구조로 겹쳐 걸리는지, 그리고 개발자가 미리 해 둘 수 있는 대비를 정리합니다.
2026년 7월 29일 리셋과 그 앞뒤 사정
7월 12일 OpenAI 는 Plus, Business, Pro 플랜에 걸려 있던 5시간 사용량 제한을 일시적으로 걷어냈습니다. Codex 와 ChatGPT 를 맡고 있는 Thibault Sottiaux 가 X 계정으로 공지한 내용입니다. 비슷한 시기 OpenAI 개발자 포럼의 토큰 소모 스레드에는 1분에서 2분이면 끝나는 작업이 5시간 할당량의 11% 를 먹었다거나, 40줄짜리 수정에 15% 가 나갔다는 보고가 쌓였습니다. 느낌이 아니라 퍼센트로 올라온 제보였습니다.
7월 29일에는 유료 사용자 전체 리셋이 다시 시행됐습니다. OpenAI 는 같이 배포된 효율 수정으로 일반적인 Sol 사용이 약 18% 더 오래 간다고 밝혔습니다. 조사 기간 동안 멈춰 두었던 5시간 제한은 그다음 날 복구됐습니다. 이때 OpenAI 가 분명히 한 것은 구독 플랜의 사용량을 줄인 적이 없다는 점입니다. 조용한 성능 하향이 아니라 모델이 일하는 방식이 달라진 결과라는 설명입니다.
리셋이 모두에게 똑같이 적용되지도 않았습니다. openai/codex 저장소에는 7월 29일 리셋을 받지 못했다는 Plus 계정 리포트가 이튿날 올라왔고 지금도 열려 있는 상태입니다. 공지 문구는 전체를 가리키는데 계정에 실제로 반영됐는지는 사용자가 확인할 방법이 마땅치 않습니다.
5시간 창과 주간 상한이 겹쳐 걸린다
Codex 문서는 로컬 메시지와 클라우드 채팅이 하나의 5시간 창을 공유하고, 여기에 주간 한도가 추가로 적용될 수 있다고 적고 있습니다. 두 창이 겹치기 때문에 5시간 창에 여유가 남아 있어도 주간 상한에 닿으면 작업이 멈춥니다. 반대 상황도 마찬가지입니다. 주간 여유가 남아 있어도 5시간 창을 다 쓰면 기다려야 합니다.
한도는 고정된 메시지 개수가 아니라 구간으로 공지됩니다. Codex 요금 문서 기준으로 Plus 의 5시간 창은 GPT-5.6 Sol 이 10에서 100 메시지, Terra 가 25에서 200, Luna 가 250에서 2,000 입니다. 폭이 이렇게 넓은 이유는 2026년 4월 2일부터 메시지당 과금이 아니라 API 토큰 사용량에 맞춘 크레딧 방식으로 바뀌었기 때문입니다. Sol 은 입력 100만 토큰당 125 크레딧, 캐시된 입력 12.5, 출력 750 크레딧이고 작업 하나가 대략 5에서 40 크레딧을 씁니다. 같은 메시지 한 개라도 컨텍스트 크기와 추론량에 따라 소모량이 몇 배씩 차이 납니다.
게다가 ChatGPT Work 와 Codex 는 사용량 풀을 공유합니다. 에디터에서 쓴 양과 웹에서 쓴 양이 같은 곳에서 함께 빠져나갑니다.
Codex 요금표모델별 크레딧 단가와 한도 구조를 1차로 확인할 수 있는 도움말
모델이 좋아질수록 할당량 계산은 나빠진다
OpenAI 가 내놓은 원인 설명이 이 문제의 핵심입니다. Sol 은 같은 요청을 받아도 더 오래 일합니다. 도구 호출이 늘고 서브에이전트 조율이 붙습니다. 높은 추론 설정에서는 이전 세대보다 토큰을 더 쓸 수 있고, 병렬 실행과 코드 모드는 한 턴당 캐시된 입력과 응답 수를 함께 늘립니다. 어려운 문제를 푸는 데는 유리하지만, 그만큼 할당량이 빨리 줄어듭니다.
중앙값만 보면 멀쩡해 보였다는 점도 짚을 만합니다. 몇 시간짜리 리팩터링을 돌리던 사용자가 먼저 벽에 부딪혔고 평균적인 사용자는 아무 변화도 느끼지 못했습니다. 그래서 문제를 늦게 알아차리고, 알아차린 뒤에도 재현이 어렵습니다. 포럼에 올라온 제보가 대부분 퍼센트 이야기인 것도 그래서입니다.
이건 한 회사의 실수라기보다 에이전트형 도구가 공통으로 안고 있는 문제입니다. 성능을 올리는 방향과 비용을 예측 가능하게 만드는 방향이 서로 반대로 당깁니다. 모델이 알아서 더 찾아보고 더 검증할수록 결과는 좋아지지만, 같은 구독료로 살 수 있는 작업 수는 줄어듭니다. 예전에 EKS 에서 Vault Raft 클러스터를 복구했던 작업처럼 로그와 매니페스트를 오래 뒤져야 하는 일이 특히 그렇습니다. 사람이 봐도 탐색이 긴 문제는 에이전트에게도 깁니다. 잘 푸는 대가로 할당량을 더 쓰는 셈입니다.
적립 리셋, 크레딧, 그리고 읽히지 않는 제한
적립 리셋은 자동으로 돌아오는 타이머를 기다리는 대신 필요한 순간에 직접 쓰는 방식입니다. 도움말에 따르면 적립 리셋 하나를 쓰면 5시간 창과 주간 창이 함께 리셋되고, 주간 리셋일이 사용 시점 기준 약 7일 뒤로 옮겨집니다. 유효 기간은 지급일로부터 30일이라 아껴 두다가 그냥 날릴 수도 있습니다. 대상 사용자에게 무료 리셋 하나가 주어졌고, Plus 와 Pro 는 2주 동안 진행된 추천 파일럿에서 최대 3명을 초대해 추가로 받을 수 있었습니다. 초대받은 사람이 첫 메시지를 보내면 양쪽 모두 리셋 하나를 얻는 구조였습니다.
한도에 걸렸을 때 남는 선택은 기다리거나, 크레딧을 추가하거나, 가벼운 모델로 내려가는 것입니다. 도움말은 일부 Plus 와 Pro 사용자가 크레딧을 더해 계속 쓸 수 있고 나머지는 플랜을 올리거나 리셋을 기다려야 한다고 적고 있습니다. 크레딧 구매가 모두에게 열려 있는 선택지는 아니라는 뜻입니다.
정작 불편한 건 제한이 제품 안에서 보이지 않는다는 것입니다. openai/codex 저장소의 이슈 20395 는 공지된 리셋이 어떤 창에 적용됐는지, 주간 한도가 포함됐는지를 사용량 화면에서 보여 달라는 요구입니다. 이슈 24080 은 더 구체적입니다. CLI 상태줄은 five-hour-limit 과 weekly-limit 을 퍼센트로만 노출하는데, 내부 API 는 리셋 시각과 창 길이, 크레딧 잔액 같은 값을 이미 돌려주고 있다는 지적입니다. 5시간 80% 라는 숫자만으로는 지금 큰 작업을 시작해도 되는지 판단할 수 없습니다.
리셋 공지를 모아 보여주는 트래커가 생긴 것도 같은 맥락입니다. codex-reset.com 은 OpenAI 와 무관한 커뮤니티 사이트이고 스스로를 공개 데이터 추적기라고 밝히고 있습니다. 조롱할 일은 아닙니다. 제한 체계가 제품 안에서 읽히지 않으면 사람들은 그것을 밖에서 읽으려 하고, 결국 공지를 기다리는 데 시간을 씁니다.
openai/codex 이슈 20395리셋 범위를 사용량 UI 에 보여 달라는 요구가 공식 채널에 남은 기록
개발자가 지금 할 수 있는 대비
대부분은 도구를 바꾸는 문제가 아니라 습관을 바꾸는 문제입니다. 큰 작업을 시작하기 전에 잔량을 먼저 보고, 작업의 무게에 따라 모델을 나눠 쓰고, 기한이 걸린 일은 한 도구에 몰지 않는 정도로 상당 부분이 해결됩니다.
- 작업 시작 전
/status와/usage로 잔량 확인 - 상태줄에 five-hour-limit 과 weekly-limit 항목 켜 두기
- 무거운 탐색과 단순 조회의 모델 분리
- 적립 리셋은 마감 직전용으로 보관, 다만 30일 만료 주의
- 기한 있는 작업은 도구 하나에 의존하지 않기
모델을 나눠 쓰는 기준은 생각보다 단순합니다. 여러 파일을 오가며 원인을 좁혀야 하는 일은 상위 모델에 맡기고, 리눅스 명령어 사용법을 확인하는 정도의 단답형 질문은 가벼운 모델로 충분합니다. 가벼운 모델은 같은 작업에 크레딧을 훨씬 적게 쓰기 때문에, Luna 계열의 5시간 구간이 Sol 보다 훨씬 넓게 잡혀 있습니다. 습관적으로 최상위 모델을 켜 두면 정작 필요한 순간에 창이 바닥나 있습니다.
기한이 있는 작업일수록 이중화가 필요합니다. 쿠버네티스 인증서 만료를 확인하고 kubeadm certs renew 로 갱신하는 일처럼 날짜가 정해진 작업은 사용량 한도에 걸렸다고 미룰 수가 없습니다. 이런 작업은 절차를 문서로 남겨 두고 손으로도 진행할 수 있게 해 두는 편이 낫습니다. 에이전트가 못 도와주는 시간대가 생긴다는 전제로 일정을 잡는 것이 현실적입니다.
정리
- 7월 12일 5시간 제한 일시 중단, 7월 29일 전체 리셋과 Sol 효율 수정, 7월 30일 5시간 제한 복구
- 원인은 플랜 하향이 아니라 Sol 이 도구 호출과 서브에이전트 조율로 더 오래 일하는 구조
- 5시간 창과 주간 상한이 겹쳐 걸리고, 한도는 고정 개수가 아니라 토큰 기반 크레딧으로 계산됨
- 적립 리셋은 5시간과 주간 창을 함께 되돌리지만 지급일로부터 30일 뒤 소멸
- 잔량 확인 습관과 모델 분리, 기한 작업의 이중화가 지금 가능한 대비
출처: Codex 요금 문서, Codex 요금표 도움말, Codex 추천 프로모션 도움말, openai/codex 이슈 20395, openai/codex 이슈 24080, openai/codex 이슈 36170, OpenAI 개발자 포럼 토큰 소모 스레드