OpenAI API 요청 한도: GPT-6 Astra 티어와 429·503 대응

GPT-6 Astra를 API에 연결할 때 가장 먼저 알아야 할 숫자는 분당 요청 수(RPM), 분당 토큰 수(TPM), Batch queue입니다. 그러나 공개된 티어 표만 보고 운영 용량을 확정하면 안 됩니다. 표는 모델의 Astra Standard 기준이고, 지금 내 조직과 프로젝트에 적용되는 값은 OpenAI Platform의 Limits 페이지와 실제 응답의 x-ratelimit-* 헤더에서 확인해야 합니다.

모델이 보이지 않는 문제도 요청 한도 문제와 분리해야 합니다. Free에서는 GPT-6 Astra API가 지원되지 않으며, 유료 사용 등급이라도 단계적 출시 과정에서 아직 접근 권한이 열리지 않을 수 있습니다. 반대로 모델 호출은 되지만 429나 503이 발생한다면 HTTP 상태와 error.type, error.code, Retry-After를 기준으로 원인을 나눠야 합니다.

GPT-6 Astra Standard의 공개 요청 한도

OpenAI의 GPT-6 Astra 모델 페이지에 2026년 9월 4일 공개되어 있던 Standard 처리 기준은 다음과 같습니다.

세 열은 서로 다른 제약입니다.

• RPM은 1분 동안 보낼 수 있는 요청 수의 기준입니다.
• TPM은 1분 동안 처리할 수 있는 토큰 양의 기준입니다.
• Batch queue는 해당 모델에 제출되어 아직 끝나지 않은 Batch 작업의 입력 토큰 합계입니다. 작업 개수나 일일 토큰 한도가 아닙니다. 작업이 끝나면 그 입력 토큰은 대기열 한도를 더 이상 차지하지 않습니다. 자세한 계산 방식은 OpenAI의 요청 한도 가이드에 설명되어 있습니다.

표의 최댓값 하나만 보면 실제 병목을 놓치기 쉽습니다. 예를 들어 T2에서 요청당 토큰 예산이 평균 5,000이라면, 단순 계산으로는 1,000,000 TPM ÷ 5,000인 분당 약 200건에서 토큰 쪽이 먼저 좁아질 수 있습니다. 이 경우 RPM이 5,000이라고 해서 분당 5,000건을 처리할 수 있는 것은 아닙니다. 반대로 매우 짧은 요청을 한꺼번에 보내면 TPM에 여유가 있어도 RPM이나 트래픽 증가 속도에서 막힐 수 있습니다.

운영 계획에는 공개 최댓값을 그대로 넣기보다 다음처럼 계산한 뒤 여유를 남기는 편이 안전합니다.

text
요청 기준 처리량 ≈ RPM
토큰 기준 처리량 ≈ TPM ÷ 요청당 토큰 예산
실시간 경로의 계획 처리량 ≈ 둘 중 더 작은 값

실제 토큰 소비는 입력 길이, 출력 상한, 캐시 사용과 요청 형태에 따라 달라집니다. 평균만으로 결정하지 말고 상위 구간의 큰 요청도 따로 확인해야 합니다.

공개 표보다 현재 계정 값이 우선한다

OpenAI API의 한도는 사용자 개인 단위가 아니라 조직과 프로젝트 수준에서 적용되며, 모델마다 다를 수 있습니다. 일부 모델군은 한도를 공유할 수도 있습니다. 공개 Astra 표는 등급별 기준을 보여 주지만, 특정 API 키가 모델에 접근할 수 있는지, 해당 프로젝트에 정확히 같은 수치가 배정됐는지, 다른 모델과 한도를 공유하는지까지 보장하지 않습니다.

따라서 배포 전과 장애 발생 시에는 두 곳을 함께 확인해야 합니다.

1. OpenAI Platform의 Limits 페이지에서 현재 조직·프로젝트·모델에 표시된 값을 확인합니다.
2. 실제 API 응답에서 남은 요청 수와 토큰 수, 초기화 시점을 읽습니다.

응답 헤더 안내에 따라 우선 기록할 항목은 다음과 같습니다.

remaining-requests가 먼저 바닥난다면 호출 빈도와 동시 요청을 줄이고 순간적으로 몰리는 트래픽을 평탄화해야 합니다. remaining-tokens가 먼저 줄어든다면 대화 기록, 시스템 지시문, 입력 문서, 최대 출력 토큰을 점검합니다. 두 값이 충분해 보이는데 실패한다면 사용 등급만 탓하지 말고 프로젝트·조직·모델 접근 권한, 결제 상태, 엔드포인트를 확인해야 합니다.

운영 로그에는 HTTP 상태, error.type, error.code, 모델 ID, 프로젝트, 위 여섯 헤더와 Retry-After를 한 요청 단위로 남겨 두는 것이 좋습니다. API 게이트웨이나 SDK가 헤더를 숨기고 있다면 애플리케이션까지 전달하도록 설정해야 실제 병목을 추적할 수 있습니다.

모델 접근과 단계적 출시를 먼저 분리한다

OpenAI API 변경 기록은 GPT-6 Astra의 API 출시일을 2026년 9월 3일로 기록했습니다. 같은 시점의 공식 안내는 API와 Plus, Pro, Business, Enterprise 제공이 며칠에 걸쳐 순차적으로 열린다고 설명했습니다. 문서에 모델이 올라왔다는 사실과 모든 계정에서 즉시 사용할 수 있다는 뜻은 같지 않습니다.

호출 전에 다음 세 가지를 구분하세요.

• Free라서 Astra API가 지원되지 않는가
• 유료 등급이지만 현재 조직이나 프로젝트에 모델 접근 권한이 아직 없는가
• 모델 접근은 되지만 RPM, TPM 또는 트래픽 증가 속도에 걸렸는가

첫째와 둘째는 재시도 횟수를 늘려도 해결되지 않습니다. 계정의 Limits, 모델 사용 가능 상태, 요청에 연결된 프로젝트와 조직을 먼저 확인해야 합니다. 프로젝트 범위를 다시 점검해야 한다면 OpenAI API Key와 Organization ID 설정을 참고할 수 있습니다.

초기 Enterprise 제공은 Daybreak access 대상에 한정되며, 출시 후 첫 2주 동안 Astra가 기본으로 꺼져 있을 수 있습니다. 관리자가 대상 워크스페이스의 사용자나 그룹에 Astra를 켜더라도 워크스페이스 모델 제공 안내에 따르면 API 키의 접근 권한까지 생기지는 않습니다. Chat, Work, Codex의 모델 선택 화면과 API 조직·프로젝트의 권한은 별도로 확인해야 합니다.

429 slow_down과 503 server_is_overloaded

둘 다 잠시 기다린 뒤 재시도할 수 있지만, 같은 장애는 아닙니다. OpenAI의 빠른 트래픽 증가 및 모델 과부하 안내는 다음과 같이 구분합니다.

slow_down은 RPM이나 TPM 잔량이 0이 아니어도 발생할 수 있습니다. 1분 총량뿐 아니라 트래픽이 얼마나 급격히 늘었는지도 제어되기 때문입니다. 새 배포에서 병렬 작업 수를 한 번에 크게 올리지 말고, 낮은 수준에서 시작해 단계적으로 증가시키세요.

server_is_overloaded는 계정 한도를 다 썼다는 뜻이 아닙니다. 크레딧 충전이나 API 키 교체를 먼저 하지 말고, Retry-After를 따른 뒤 재시도 간격을 늘립니다. 여러 지역이나 독립된 요청 경로에서도 지속된다면 OpenAI 상태 페이지를 확인하고, 사전에 검증한 대체 모델 정책이 있을 때만 폴백합니다.

429라는 상태만 보고 모두 slow_down으로 처리해서도 안 됩니다. OpenAI API 오류 코드 문서에 따라 응답 본문의 error.type과 error.code를 함께 기록하세요. 사용 가능한 크레딧이나 지출 한도가 원인이라면 백오프는 근본 해결책이 아니며, 호출 빈도가 원인이라면 크레딧을 추가해도 RPM과 TPM이 자동으로 늘어나지 않습니다.

재시도는 더 조용해지도록 설계한다

재시도 가능한 응답에서는 서버가 보낸 Retry-After를 우선합니다. 값이 없을 때는 지터를 포함한 지수 백오프를 사용하고, 전체 시도 횟수와 최대 대기 시간을 제한합니다. SDK, 게이트웨이, 애플리케이션이 각각 재시도하면 한 번의 실패가 여러 호출로 증폭될 수 있으므로 하나의 재시도 예산으로 합쳐야 합니다.

ts
function backoffMs(attempt: number, retryAfter: string | null) {
  const seconds = retryAfter ? Number(retryAfter) : Number.NaN;
  if (Number.isFinite(seconds)) return Math.max(0, seconds * 1000);

  const retryAt = retryAfter ? Date.parse(retryAfter) : Number.NaN;
  if (Number.isFinite(retryAt)) return Math.max(0, retryAt - Date.now());

  const base = Math.min(15_000, 500 * 2 ** attempt);
  return base + Math.random() * base * 0.25;
}

// HTTP 상태와 error.code를 확인한 뒤, 재시도 가능한 경우에만 사용한다.

안전한 조정 순서는 다음과 같습니다.

1. Retry-After 또는 초기화 헤더가 가리키는 시점까지 기다립니다.
2. 요청 수가 병목이면 동시 요청 수를 줄이고 큐로 순간 부하를 흡수합니다.
3. 토큰이 병목이면 불필요한 입력을 제거하고 현실적인 최대 출력값을 사용합니다.
4. 실시간 응답이 필요 없는 작업은 Batch API로 옮깁니다.
5. 최적화 뒤에도 지속적으로 용량이 부족할 때만 한도 증액을 검토합니다.

재시도할 때마다 같은 큰 요청을 그대로 다시 보내면 TPM 압력이 커집니다. 실패 횟수가 늘어날수록 대기 시간이 길어져야 하며, 최대 시도에 도달하면 작업을 보류하거나 명시적으로 실패시켜야 합니다. 같은 오류를 숨긴 채 무한 반복하는 것은 복구가 아닙니다.

Batch queue는 실시간 TPM의 대체 숫자가 아니다

대규모 비동기 작업에서는 Batch API가 실시간 경로의 순간 부하를 줄이는 데 도움이 됩니다. 하지만 표의 Batch queue가 RPM이나 TPM에 더해진 범용 토큰 잔액은 아닙니다. 해당 모델의 아직 완료되지 않은 Batch 작업에 들어 있는 입력 토큰 총량을 제한하는 별도 기준입니다.

예를 들어 T2의 공개 Batch queue는 3,000,000 tokens입니다. 각 작업의 입력이 50,000 tokens라면 단순 계산으로 동시에 대기시킬 수 있는 규모는 약 60개입니다. 실제로는 작업별 입력 크기가 다르므로 제출 전에 현재 대기 중인 입력 토큰 합계를 계산하고 여유를 둬야 합니다. 완료된 작업의 입력 토큰은 대기열 점유에서 빠집니다.

즉시 응답이 필요한 요청을 무조건 Batch로 보내거나, Batch 한도를 일일 사용량으로 해석하면 안 됩니다. 실시간성과 완료 시점 요구를 먼저 나눈 뒤 경로를 선택하세요.

공개되지 않은 숫자는 추정하지 않는다

2026년 9월 4일 확인한 Astra 모델 페이지에는 RPM, TPM, Batch queue가 공개되어 있지만 Astra 전용 RPD, TPD, 동시 요청 수와 별도의 장문 컨텍스트 RPM·TPM 수치는 제시되어 있지 않습니다. 빈칸을 0, 무제한, 다른 모델과 동일한 값으로 해석해서는 안 됩니다.

GPT-6 Astra의 컨텍스트 창 1,050,000 tokens, 최대 입력 922,000 tokens, 최대 출력 128,000 tokens는 한 요청의 크기와 관련된 모델 사양입니다. 이것을 TPM이나 동시 요청 한도로 바꿔 읽을 수 없습니다. 272K를 넘는 입력에 적용되는 별도 가격 규칙도 장문 컨텍스트 한도 숫자가 아닙니다. 장문 요청을 운영한다면 개발자 콘솔에 표시되는 현재 한도를 직접 확인해야 합니다.

Fast 처리도 요청 가능량을 늘리는 우회 수단이 아닙니다. OpenAI의 Fast mode 안내에 따르면 같은 모델의 Standard와 Fast는 요청 한도를 공유하며, Fast 트래픽에도 증가 속도 제약이 적용됩니다. 지연 시간 옵션과 호출 처리량을 서로 다른 결정으로 다루세요.

API와 Work·Codex 한도는 서로 다른 계약이다

OpenAI API에서는 API 키가 속한 조직과 프로젝트의 RPM, TPM, Batch 대기열 및 사용량을 봅니다. ChatGPT 계정으로 사용하는 Work와 Codex에는 플랜별 사용 창과 공유 사용량 정책이 적용됩니다. Work나 Codex에서 Astra를 선택할 수 있다는 사실은 API 키 권한을 증명하지 않으며, ChatGPT 플랜을 올린다고 API 프로젝트의 RPM이나 TPM이 자동으로 증가하지도 않습니다.

같은 Codex라도 로그인 방식에 따라 확인할 곳이 달라집니다.

• ChatGPT 계정으로 사용하는 Codex의 제한은 OpenAI Codex 사용 한도에서 확인합니다.
• API 키로 호출하는 경로는 해당 API 조직·프로젝트의 Limits와 응답 헤더를 확인합니다.
• 구독과 API 결제를 혼동했다면 Codex 구독과 API 키의 차이를 먼저 정리합니다.

제품 경계를 나누면 “Codex 사용 창이 남았는데 API가 429다” 또는 “ChatGPT에서 Astra가 보이는데 API 호출은 안 된다” 같은 상황을 모순으로 오해하지 않게 됩니다.

증액을 요청하기 전에 남길 기록

한도 증액은 코드와 트래픽을 정리한 뒤에도 지속 용량이 부족할 때 의미가 있습니다. 요청 전에는 적어도 다음 정보를 확보하세요.

• 실제로 호출한 모델 ID와 엔드포인트
• 조직과 프로젝트, 현재 사용 등급
• Limits에 표시된 현재 값
• 시간대별 RPM·TPM과 요청당 토큰 분포
• 동시 요청 수와 급격한 증가 구간
• HTTP 상태, error.type, error.code, Retry-After, 초기화 헤더
• 적용한 큐, 백오프, 입력 축소와 Batch 전환 결과

이 기록이 있으면 증액이 필요한 지속 수요인지, 순간 부하인지, 토큰이 큰 일부 요청인지 판단할 수 있습니다. 실시간 처리와 Batch 처리의 필요 용량도 따로 제시할 수 있습니다.

실무 판단 순서

GPT-6 Astra의 공개 T1~T5 표는 용량 계획의 첫 기준으로 유용하지만 최종 답은 아닙니다. 먼저 모델 접근 여부와 단계적 출시 상태를 확인하고, 현재 프로젝트의 Limits와 응답 헤더를 기준으로 RPM·TPM 병목을 찾으세요. Batch 작업은 대기 중인 입력 토큰 합계로 별도 계산해야 합니다.

오류가 발생하면 상태 코드만 보지 말고 error.type과 error.code까지 분류합니다. 429 slow_down이면 증가 속도를 낮추고, 503 server_is_overloaded이면 서버가 제시한 시간 뒤 간격을 늘려 재시도합니다. 결제·프로젝트·모델 접근 문제에는 재시도를 적용하지 않습니다.

원인을 확인한 뒤에는 가장 작은 수정부터 시작하세요. 요청 병렬도를 낮추고, 토큰 예산을 줄이고, 비실시간 작업을 Batch로 옮긴 다음에도 지속 처리량이 부족할 때 증액을 검토하면 됩니다. 재시도와 폴백의 종료 조건을 정해야 한다면 LLM API 재시도와 폴백을 결정하는 기준을 이어서 확인하세요.