Codex Day 11 상세 해설: Model at Capacity 오류 대폭 감소 및 자동 재개 기능 개선

OpenAI의 '28일간 업데이트'를 매일 추적하며 공식 정보에 기반하여 자세히 해설하고 있습니다. 새로운 기능과 리셋을 놓치고 싶지 않은 분들은 꼭 팔로우해 주세요.

2026년 10월 15일(미국 시간), OpenAI의 '28일간 Codex・ChatGPT Work 개선 또는 완전 초기화' 기획으로 Day 11이 발표되었습니다.

이번 업데이트는 Codex 및 Work에서 발생하던 모델 처리 용량 부족으로 인한 중단 현상을 줄이고, 오류 발생 후에도 작업이 자동으로 계속되도록 안정성을 개선한 것입니다.

대상되는 대표적인 오류는 다음과 같습니다.

Selected model is at capacity.
Please try a different model.

Day 10은 완전 초기화였지만, Day 11은 새로운 사용량 리셋이 아니라 서버의 처리 능력과 복구 동작을 개선한 날입니다.

OpenAI의 Tibo Sottiaux 씨는 추가적인 컴퓨팅 자원을 투입하고 여러 변경 사항을 통해 이 오류 발생률을 '매우 대폭' 줄였다고 설명했습니다. 오류가 남아 있는 경우에도 도중에 멈춰있지 않고, 최종적으로는 자동으로 처리를 계속할 수 있도록 했다고 발표했습니다.

다만, 오류 발생률의 구체적인 감소율, 최대 복구 시간, 모든 클라이언트에서의 완전한 복구 보장은 공표되지 않았습니다.

이 글에서는 Day 11 발표 내용을 분석하고, 과거 사용자 보고, 백엔드 용량 부족과 계정 사용 한도의 차이점, 재시도(retry) 및 대기열(queue)의 부작용에 대한 주의사항, 사용자가 할 수 있는 문제 해결 방법까지 정리합니다.

정보 확인일: 2026년 10월 16일(한국 시간). 발표된 사실과 일반적인 분산 시스템 설계로서의 해설을 구분합니다. 기술적인 구현 상세는 미공개입니다.

• Tibo Sottiaux 씨: Day 11 공식 발표 (X)
• OpenAI 공식: 28 days of Shipping at OpenAI
• Developer Community: Day 11 포함 추적 스레드

공식 X 게시물은 **2026년 10월 16일 00:11경(한국 시간)**에 발신되었습니다.

대규모 언어 모델은 요청을 받으면 GPU 등의 컴퓨팅 자원을 사용하여 추론 처리를 실행합니다.

사용자가 집중되어 특정 모델을 처리할 수 있는 용량이 부족해지면, 일시적으로 새로운 요청을 받을 수 없는 경우가 발생할 수 있습니다.

사용자 A ─┐
사용자 B ─┼─→ 모델 추론 기반
사용자 C ─┤ │
...

Day 11 발표는 추가적인 컴퓨팅(compute) 자원을 투입했음을 명시하고 있습니다.

다만, 투입된 GPU 대수, 지역, 데이터 센터, 모델별 배분, TPM 증가율 등은 공개되지 않았습니다.

따라서, 'GPU를 몇만 대 늘렸다', '속도가 몇 배가 되었다'와 같은 구체적인 수치를 보충할 수는 없습니다.

Tibo 씨는 '여러 변경 사항'을 통해 용량 부족 오류를 매우 대폭 줄였다고 설명했습니다.

추가 컴퓨팅 외의 변경 사항 구체적인 예시는 미공개입니다.

일반론적으로는 부하 분산(load balancing), 추론 요청의 큐잉(queuing), 용량 관리, 백프레셔 제어(backpressure control) 등이 관련 기술이지만, OpenAI가 Day 11에서 이를 채택했다는 증거는 아닙니다.

Day 11에서 특히 실용적인 것은 다음 내용입니다.

기존에는,

긴 코딩 작업을 실행
↓
모델 용량 부족
...

이런 경험을 한 사용자가 있었습니다.

Day 11에서는 공식 설명상,

긴 코딩 작업을 실행
↓
모델 용량 부족
...

와 같은 개선이 이루어졌습니다. 다만 어떤 내부 상태로 대기할지, 몇 초 간격으로 재시도할지, 일정 시간 후 포기할지, 모든 클라이언트에 배포되었는지는 공표되지 않았습니다.

'반드시 무한히 재시도된다', '통신 단절이나 PC 재부팅까지 복구가 보장된다'는 의미가 아닙니다.

이 오류를 직역하면, '선택한 모델은 현재 처리 용량의 상한에 도달했습니다. 다른 모델을 시도해 주세요'입니다.

중요한 것은, 사용자 개인의 사용 한도와 서비스 측의 컴퓨팅 처리 용량은 별개라는 점입니다.

용량 부족 오류가 발생했다고 해서 즉시 'ChatGPT Pro의 주간 사용 한도가 소진되었다'는 의미는 아닙니다.

실제로 OpenAI의 Codex GitHub 리포지토리에는 플랜 사용량이 아직 남아있음에도 용량 부족 오류로 멈췄다는 보고가 있습니다.

참고로, 표시된 메시지만으로는 실제 근본 원인을 확정하기 어려울 때가 있습니다. 같은 종류의 오류처럼 보여도 백엔드 라우팅(routing), 클라이언트 연결 상태 등이 관련될 수 있습니다.

Day 11 개선 내용을 이해하려면 과거 사례를 보는 것이 쉽습니다.

2026년 7월 17일에 공개된 openai/codex Issue #33878에서는 macOS의 Codex Desktop에서 장시간 작업이 capacity 오류로 인해 종료되어 원래 작업을 계속할 수 없게 되었다고 보고되었습니다.

또한 같은 Issue에는 Windows에서 약 25분간 작업한 후 server_overloaded라는 내부 오류로 종료된 사례도 추가되었습니다.

개발자에게 문제가 되는 것은 단순히 몇 분 동안 기다려야 하는 것만이 아닙니다.

• 그동안의 조사 및 수정 맥락이 끊김
• 이어서 지시 사항을 직접 다시 작성해야 함
• 중간에 완료되지 않은 편집이 남았는지 확인이 필요함
• 자동화했던 긴 작업이 도중에 실패함

자신이 화면을 보고 있지 않으면 진행이 멈추기 때문에, 장시간 에이전트(agent) 사용에 큰 장애물이었습니다.

Issue #41790에서는 Pro 사용자로부터 약 15분 동안 동일한 작업에서 3번의 capacity 오류가 발생했다는 보고가 있습니다.

이 사례에서는 자동 재시도 및 대기(backoff) 자체는 이루어졌지만, 복구된 후 다시 오류가 발생했습니다.

즉, Day 11 이전에도 일부 환경에서는 재시도가 존재했습니다.

Day 11을 '최초로 자동 재시도 기능이 구현된 날'이라고 설명하는 것은 부정확합니다.

Issue #33853은 현재 작업이 capacity 오류가 되었을 때, 해당 작업이 완료되지 않은 채 다음 대기열 지시 사항(queued instruction)이 처리되는 것을 막아달라는 개선 요청입니다.

작업 A: 버그 수정
↓ 오류로 중단
작업 B: A의 수정 완료 후 병합(merge)
...

Day 11 발표는 '재개하기 쉽게 한다'는 개선을 보여주지만, 대기열 순서와 의존성 문제를 모두 해결했다는 명시적인 발표는 아닙니다.

이러한 Issue들은 Day 11의 배경을 이해하기 위한 사용자 보고/요구 사항일 뿐이며, OpenAI가 개별 결함 수정 완료를 인증한 자료가 아닙니다.

여기서는 Day 11의 구현 설명이 아니라, 일반적인 분산 시스템이나 AI 에이전트 설계 예시입니다.

일시적으로 실패한 처리를 다시 실행하는 것입니다.

실패 직후에 대량의 요청을 계속 보내는 것이 아니라, 다음 시도까지 대기 시간을 두는 것입니다.

예시:

1차 실패 → 잠시 기다림
2차 실패 → 더 오래 기다림
3차 실패 → 훨씬 더 오래 기다림
...

대기 시간을 점진적으로 늘리는 것을 **Exponential Backoff (지수 백오프)**라고 부릅니다.

나아가, 동시에 많은 클라이언트가 재시도하는 것을 방지하기 위해 대기 시간에 무작위적인 변동(Jitter)을 추가하는 설계도 있습니다.

이러한 용어들을 이해하고 있으면, Codex가 일정 시간 기다린 후 다시 시작하는 동작을 해석하기 쉬워집니다.

다만, Day 11에서 지수 백오프나 Jitter가 새롭게 도입되었다고 공식적으로 발표된 것은 아닙니다.

도중에 실패했을 때, 사용자의 요청, 지금까지의 도구 결과, 파일 변경 상황 등을 유지하고 재개할 수 있도록 하는 설계입니다.

RUNNING
↓ 용량 부족
WAITING / RETRYING
...

이에 대해, 용량 부족으로 즉시 FAILED로 떨어지고 이전 상태를 복원할 수 없다면 사용자에게 더 많은 수고가 따릅니다.

이번 발표는 '궁극적으로 그대로 계속 진행될 수 있도록'이라는 방향성을 보여주고 있지만, 내부의 상태 전이가 이 다이어그램과 일치한다는 보장은 없습니다.

이 부분은 에이전트 자동화를 이용하는 개발자에게 특히 중요합니다.

예를 들어 Codex에 다음 작업을 요청했다고 가정해 봅시다.

1. 파일 편집
2. 테스트 실행
3. PR 생성
...

모델의 추론 리퀘스트 재시도와, GitHub에 쓰기 또는 외부 API에 게시하는 등의 재실행은 같지 않습니다.

일반적으로 한 번 성공한 외부 쓰기를 실패로 오인하여 다시 실행하면 중복된 PR, 댓글, 주문, 게시물 등이 발생할 가능성이 있습니다.

예를 들어,

PR 생성 API 전송
↓
GitHub 측에서는 PR 생성 성공
...

와 같은 패턴입니다.

Day 11의 공식 발표는 용량 부족 개선과 자동 지속에 관한 것이며, 모든 외부 API에 대해 Exactly Once(부작용이 반드시 한 번만) 실행을 보장한 것은 아닙니다.

• 작업 전후로 GitHub 등 현재 상태를 다시 읽어오기
• 기존 Issue나 PR을 검색한 후 새로 생성하기
• API가 지원한다면 Idempotency Key 사용하기
• 쓰기 결과가 불분명할 경우, 무조건 연속 재전송하지 않기
• CI나 배포는 실행 ID를 기록하기
• 중요한 병합(Merge)·삭제·운영 환경 쓰기는 권한이나 승인 설정을 명확히 하기

자동 재개가 개선되더라도, 중요한 부작용의 안전성은 앱 측/워크플로우 측에서 설계해야 합니다.

OpenAI의 Day 11 게시물은 오류가 아직 발생한다면 보고해 달라고 요청하고 있습니다.

오류가 발생하면, 먼저 클라이언트가 대기/재시도 중인지를 확인합시다.

자동으로 지속되는 도중에 새로운 작업을 추가하면 어디까지 실행했는지 파악하기 어려울 수 있습니다.

하지만, 기다린다고 반드시 복구된다는 보장은 없습니다.

Codex·Work의 사용 가능한 잔량은 데스크톱 앱 등에서 확인할 수 있습니다.

Settings
└─ Usage

Codex CLI로 이용 현황이 표시되는 환경이라면, 세션 내에서 다음 슬래시 커맨드를 확인합니다.

/status

Usage에 여유가 있는데 capacity 오류가 발생한다면, 적어도 단순히 플랜 상한에 도달했다는 설명만으로는 불충분합니다.

재시도 버튼을 여러 번 누르기 전에 소스 코드의 차이점, PR 유무, CI·배포 결과를 확인하세요.

손안의 Git 작업 디렉터리라면, 다음과 같은 읽기 전용 커맨드를 사용할 수 있습니다.

git status --short
git diff --stat

• git status --short:
  변경됨·미추적 파일의 개요를 표시 -
• git diff --stat:
  스테이징되지 않은 변경량을 파일별로 표시

이들은 변경 사항을 확인하는 커맨드이며, 파일을 수정하거나 삭제하지 않습니다.

계속 발생한다면, 다음 정보를 정리하면 조사하기 쉽습니다.

Day 11은 안정성 개선이므로, 다른 대책과 혼동하지 않도록 합시다.

둘은 '사용할 수 있게 된다'는 점에서는 비슷해도, 근본적으로 다른 문제에 대한 대책입니다.

⚠️ [IMG:N] 형식 토큰은 이미지 placeholder 입니다. 번역하지 말고 원래 위치에 그대로 유지하세요.

Day 10이 이용 가능량 회복에 관한 것이라면, Day 11은 장시간 작업이 도중에 중단될 가능성 자체를 줄이는 개선입니다.

확인한 공식 트래커에는 Day 11의 추가 리셋은 게재되어 있지 않습니다. Day 11은 처리 용량과 안정성의 개선입니다.

'0(제로)'이 된다고 발표된 것은 아닙니다. 발생률을 대폭 줄이고, 발생하더라도 최종적으로는 자동 지속할 수 있도록 했다는 설명입니다.

Day 11의 공식 공지에는 대상 플랜별 실측값이나 제공 버전의 완전한 표가 없습니다. Codex / Work 전체에 관련된 시책이지만, 각 계정에서의 효과를 일률적으로 보장하는 정보는 아닙니다.

그러한 발표는 아닙니다. 과거에도 일부 클라이언트에서 자동 재시도는 이루어졌습니다. 이번 변경으로 무엇을 대체하고 무엇을 유지했는지는 미공개입니다.

CLI를 포함한 모든 클라이언트에 동일한 복구 보장은 공개되지 않았습니다. 아직 발생하는 경우, 사용 앱/버전/로그를 첨부하여 공식에 보고합시다.

보장되지 않습니다. 파일 변경, PR 생성, 배포 등은 실제 외부 상태를 확인할 수 있도록 설계해야 합니다.

Day 11은 눈에 띄는 신기능보다는 장시간 작업의 실용성에 직결되는 안정성 개선이었습니다.

주목할 점은 다음과 같습니다.

2026년 10월 15일 (미국 시간)의 Day 11은 capacity 오류 대책-
추가 계산 자원 + 여러 시스템 개선을 실시하여 'Selected model is at capacity' 오류를 대폭 감소-
오류가 남아도
최종적으로 자동 지속하기 쉽게 하는 개선이며, 발생률/대기 시간/모델별 실측값은 미공표모든 실패/외부 조작/큐 동작을 보장하는 것은 아님Day 11의 추가 풀 리셋은 공식 발표에서 확인되지 않음-
아직 발생하는 경우,
앱, 모델, 시각, 재시도 결과를 첨부하여 보고해야 합니다.

Codex를 몇 분, 몇 시간이나 걸리는 레포지토리 조사, 테스트, 리뷰, PR 생성에 사용하는 사람일수록, 도중에 멈추기 어려워지는 이점을 기대할 수 있습니다.

단순히 추론이 빠르다는 것 이상으로, 도중에 사람이 오류 대응으로 돌아가지 않아도 되는 것은 AI 에이전트에 의한 지속적인 개발의 중요한 품질 지표입니다.

• OpenAI 공식: 28 days of Shipping at OpenAI (Day 11)
• Tibo Sottiaux 씨: Day 11 처리 용량/자동 지속 개선 발표
• OpenAI Developer Community: Day 11 보고 게재
• openai/codex Issue #33878: 장시간 작업의 capacity 중단 (사용자 보고)
• openai/codex Issue #41790: 재시도해도 반복 발생 (사용자 보고)
• openai/codex Issue #33853: 중단 후 큐 실행 주의 (사용자 요청)
• openai/codex Issue #50238: 용량 부족 시 복구 동작에 관한 설계 제안 (사용자 게시물)
• OpenAI Status

앞으로도 OpenAI・Codex의 28일간 업데이트를 매일 추적하여, 공식 발표와 미확인 사항을 구분하여 자세히 전달하겠습니다. Day 12 이후의 개선/리셋도 놓치고 싶지 않은 분들은 꼭 팔로우해 주세요.