AI API로부터 받는 429 응답은 분당 요청 수 초과, 분당 토큰 수 초과, 동시 연결 수 초과, 계정 잔액 부족이라는 네 가지 다른 의미를 가질 수 있습니다. 네 가지 경우 모두 동일한 상태 코드를 반환하므로, 해결책은 단순히 재시도를 반복하는 것이 아니라 실제로 어떤 제한에 걸렸는지 진단하는 데 달려 있습니다. 이 가이드에서는 실패 유형을 분석하고, 현재 제한에 대해 어떤 증거를 사용할 수 있는지(또는 없는지) 설명하며, 프로덕션 환경에서 견고하게 작동하는 재시도 및 폴백(fallback) 패턴을 제시합니다.
핵심 요약
429오류는 요청 한도, 토큰 예산, 동시성 제한, 계정 잔액 부족 중 하나를 의미할 수 있습니다. 각각 다른 해결책이 필요하며, 무차별적인 재시도는 이 중 하나만 해결할 뿐입니다.- 성공적인 응답 시에도 속도 제한 헤더를 읽고, 한계치에 도달하기 전에 속도를 조절하십시오.
- 클라이언트 측 토큰 계산은 보장이 아닌 추정치입니다. 사용하는 라이브러리와 제공업체의 실제 계산 방식 간의 토크나이저 불일치로 인해 생각보다 안전 마진이 좁을 수 있습니다.
- 모델 및 티어별 정확한 RPM/TPM 한도는 이 문서의 증거 자료에서 공개되지 않았습니다. 다른 곳에서 본 수치는 고정된 상수가 아니라 자신의 계정 대시보드에서 확인해야 할 대상으로 간주하십시오.
- 탄력적인 재시도를 위해서는 지수 백오프(exponential backoff), 지터(jitter), 최대 재시도 횟수 설정, 그리고
retry-after헤더 준수가 필요합니다. 멱등성이 보장되지 않는 작업은 절대 무작위로 재시도하지 마십시오.
AI API 속도 제한 이해: 4가지 실패 유형
요청 제한(Request limits)
대부분의 제공업체는 분당 요청 수(RPM)를 계산합니다. 이를 초과하면 즉시 429 오류가 발생하며, 종종 빈 본문이 반환됩니다. 사용자가 결과를 빠르게 넘겨보거나, 속도 제한 없이 실행되는 크론 작업이 일반적인 트리거입니다.
토큰 제한(Token limits)
팀들이 가장 과소평가하는 함정입니다. 제공업체는 종종 RPM과 별도로 분당 토큰 수(TPM)를 제한하므로, 요청 한도보다 훨씬 여유로운 상태에서도 429 오류를 겪을 수 있습니다. 대규모 컨텍스트 모델은 이 문제를 악화시킵니다. TokenLab의 실시간 가격 증거(2026-07-07 관찰)에 따르면, Claude Opus 4.8과 GPT-5.5는 모두 1,000,000개 이상의 토큰 컨텍스트를 지원합니다. 대용량 문서, 전체 코드베이스 또는 긴 대화 기록을 해당 윈도우에 로드하는 호출은 단 한 번의 요청이라도 분당 토큰 예산의 상당 부분을 소비할 수 있습니다. 이는 호출당 토큰 수가 아닌 컨텍스트 윈도우 크기에 기반한 용량 계획 위험이므로, 고정된 수치를 가정하기보다 실제 로그를 통해 사용량을 검증하십시오.
동시성 제한(Concurrency limits)
제공업체는 분당 평균 볼륨은 허용하다가도, 한 번에 50개의 스트림을 여는 순간 제한을 걸 수 있습니다. 동시성 제한은 진행 중인 요청이나 연결을 제한합니다. 스트리밍 응답은 연결을 더 오래 유지하므로 짧은 단일 호출보다 동시성 슬롯을 더 빨리 소모합니다. Claude Sonnet 5나 Kimi K2.7 Code 기반의 코딩 에이전트, Gemini 3.5 Flash를 사용하는 음성 인터페이스는 한 번에 많은 장기 연결을 유지하기 때문에 흔한 트리거가 됩니다.
할당량 또는 잔액 소진(Quota or balance exhaustion)
이는 대시보드에서 속도 제한과 동일하게 보입니다. 호출이 작동을 멈추지만 해결책은 다릅니다. 선불 크레딧이 소진되거나 일일 지출 한도에 도달하면 API는 속도 제한과 유사한 오류를 반환합니다. 이 경우 백오프는 아무런 도움이 되지 않습니다. 잔액을 충전하거나 지출 한도를 높여야 합니다.
소스 스냅샷
| 데이터 포인트 | 출처 | 관찰 일자 |
|---|---|---|
| 모델 컨텍스트 윈도우 및 토큰당 가격 | TokenLab 실시간 모델/가격 증거 | 2026-07-07 |
| 모델 SSOT 명명 (Claude Sonnet 5, GPT-5.5, Gemini 3.5 Flash 등) | TokenLab 모델 SSOT | 2026-07-07, 2026-07-14 만료 |
| 공식 제공업체 RPM/TPM 티어 제한 | 이 증거 세트에서는 이용 불가 | 확인되지 않음, 제공업체 계정 대시보드 확인 |
| TokenLab 게이트웨이 헤더 정규화 동작 | 이 증거 세트에서는 이용 불가 | 단일 헤더 스키마에 의존하기 전 TokenLab API 문서 확인 |
현재 모델 컨텍스트 윈도우 및 가격 (TokenLab 실시간 증거)
이 수치들은 TokenLab 실시간 가격 스냅샷에서 직접 가져온 것입니다. 이는 RPM이나 TPM 제한이 아니며, 대규모 컨텍스트 모델에서의 단일 호출이 왜 토큰 예산을 불균형하게 소모하는지 보여줍니다.
| 모델 | 제공업체 | 컨텍스트 윈도우 | 입력 $/MTok | 출력 $/MTok | 출처 | 관찰 |
|---|---|---|---|---|---|---|
| Claude Sonnet 5 | Anthropic | 1,000,000 | $2.00 | $10.00 | TokenLab 실시간 가격 증거 | 2026-07-07 |
| Claude Opus 4.8 | Anthropic | 1,000,000 | $5.00 | $25.00 | TokenLab 실시간 가격 증거 | 2026-07-07 |
| Claude Fable 5 | Anthropic | 1,000,000 | $10.00 | $50.00 | TokenLab 실시간 가격 증거 | 2026-07-07 |
| GPT-5.5 | OpenAI | 1,050,000 | $5.00 | $30.00 | TokenLab 실시간 가격 증거 | 2026-07-07 |
| GPT-5.5 Batch/Flex | OpenAI | 1,050,000 | $2.50 | $15.00 | TokenLab 실시간 가격 증거 | 2026-07-07 |
| Gemini 3.5 Flash | 1,048,576 | $1.50 | $9.00 | TokenLab 실시간 가격 증거 | 2026-07-07 | |
| GLM-5.2 | Z.ai | 1,048,576 | $0.93 | $3.00 | TokenLab 실시간 가격 증거 | 2026-07-07 |
| Kimi K2.7 Code | Moonshot AI | 262,144 | $0.74 | $3.50 | TokenLab 실시간 가격 증거 | 2026-07-07 |
| DeepSeek V4 Pro | DeepSeek | 1,048,576 | $0.44 | $0.87 | TokenLab 실시간 가격 증거 | 2026-07-07 |
| DeepSeek V4 Flash | DeepSeek | 1,048,576 | $0.09 | $0.18 | TokenLab 실시간 가격 증거 | 2026-07-07 |
| Qwen3.7 Plus | Alibaba | 1,000,000 | $0.32 | $1.28 | TokenLab 실시간 가격 증거 | 2026-07-07 |
| MiniMax M3 | MiniMax | 1,048,576 | $0.30 | $1.20 | TokenLab 실시간 가격 증거 | 2026-07-07 |
모델 SSOT 참고: 이 이름들은 2026-07-07에 관찰되어 2026-07-14에 만료되는 TokenLab 모델 SSOT를 반영합니다. 명명 및 가용성은 자주 변경됩니다. 프로덕션 코드에 모델 문자열을 하드코딩하기 전에 TokenLab 모델 디렉토리 또는 모델 리더보드에서 여전히 유효한지 확인하십시오.
재시도 로직을 처음부터 만들지 않고 속도 제한 실패 해결하기
위의 모든 내용은 진단에 관한 것입니다. 어떤 모델로 폴백할지 결정하고, 사용자별 동시성을 추적하며, 어떤 모델 제품군이 정상인지 실시간으로 파악하는 작업은 정확히 TokenLab의 라우팅 계층이 흡수하도록 설계된 부분입니다. 5개 제공업체에 걸쳐 폴백 매트릭스를 직접 만드는 대신, 요청을 TokenLab으로 보내고 게이트웨이가 가용성과 폴백 규칙에 따라 현재 모델 카탈로그 중에서 선택하도록 하십시오.
한 가지 솔직한 주의사항: TokenLab은 여러 업스트림 제공업체 앞에 위치하며, 각 업스트림은 고유한 헤더 세트, 오류 형식 및 재시도 의미론을 반환합니다. 게이트웨이가 모든 속도 제한 헤더를 하나의 일관된 스키마로 완전히 정규화하는지, 아니면 일부 업스트림 헤더를 변경 없이 통과시키는지 여부는 이 문서의 증거에서 확인되지 않았습니다. 모든 모델에 걸쳐 단일 통합 스키마를 가정하는 파싱 로직을 작성하기 전에 TokenLab API 문서에서 현재 헤더 동작을 확인하십시오. 헤더 파서를 방어적으로 구축하여 필드가 존재한다고 가정하기보다 각 필드의 존재 여부를 확인하십시오.
속도 제한 헤더 읽기
제공업체는 응답 헤더에 속도 제한 정보를 반환하지만, 정확한 이름은 제공업체마다 다릅니다. 일반적인 패턴은 다음과 같습니다:
x-ratelimit-limit-requests: 500
x-ratelimit-remaining-requests: 499
x-ratelimit-reset-requests: 12s
retry-after: 0
이 헤더들을 429 오류 발생 후뿐만 아니라 성공적인 응답 시에도 읽으십시오. 남은 예산의 누적 카운트를 유지하고, 일반적으로 10-20%의 안전 여유 공간 아래로 떨어지면 속도를 늦추십시오. 적절한 수치는 트래픽의 버스트 특성에 따라 다르며, 이 증거 세트에서 지정할 수 없습니다.
명시적 오류 처리를 포함한 재시도 로직
재시도 도우미는 429 사례 이상을 처리해야 합니다. 일시적인 오류(429, 503, 타임아웃)와 재시도해도 성공하지 못할 클라이언트 오류(429를 제외한 4xx)를 구분해야 하며, 존재할 경우 retry-after를 준수해야 합니다.
async function callWithRetry(fn, maxRetries = 4) {
for (let attempt = 0; attempt <= maxRetries; attempt++) {
try {
return await fn();
} catch (err) {
const status = err.status;
// 429를 제외한 클라이언트 오류는 재시도해도 성공하지 않음
if (status && status >= 400 && status < 500 && status !== 429) {
throw err;
}
// 오류 유형과 관계없이 최대 재시도 횟수 도달 시 포기
if (attempt === maxRetries) throw err;
// 429: retry-after가 있으면 준수하고, 없으면 지터와 함께 백오프
if (status === 429) {
const retryAfter = parseRetryAfterHeader(err);
const delay = retryAfter
? retryAfter * 1000
: Math.pow(2, attempt) * 1000 + Math.random() * 1000;
await sleep(delay);
continue;
}
// 503 또는 네트워크 타임아웃: 백오프 및 재시도, 관측 가능성을 위해 로그 기록
if (status === 503 || err.code === 'ETIMEDOUT' || err.code === 'ECONNRESET') {
await sleep(Math.pow(2, attempt) * 1000 + Math.random() * 1000);
continue;
}
// 알 수 없는 5xx: 백오프와 함께 재시도, 시도 횟수 엄격히 제한
if (status && status >= 500) {
await sleep(Math.pow(2, attempt) * 1000 + Math.random() * 1000);
continue;
}
throw err;
}
}
}
결제 청구나 부작용이 있는 쓰기 작업과 같이 멱등성이 없는 작업은 절대 단순한 재시도 루프에 넣지 마십시오. 해당 호출을 재시도하기 전에 멱등성을 확인하거나 멱등성 키를 사용하십시오.
토큰 추정 정확도: 로컬 카운트가 제공업체 카운트와 차이가 나는 이유
클라이언트 측 토큰 계산 라이브러리는 특정 모델이 실제로 사용하는 토크나이저를 근사치로 계산합니다. tiktoken은 OpenAI 제품군과 밀접하게 일치하지만 Anthropic, Google 또는 오픈 웨이트 토크나이저와 정확히 일치한다고 보장할 수는 없습니다. 특수 토큰, 멀티바이트 문자, 시스템 프롬프트 형식 주변에서 차이가 발생하며, 긴 대화에서는 이러한 차이가 누적됩니다.
차이를 줄이기 위한 실질적인 단계:
- 응답 본문에 반환되는 실제 토큰 사용량을 읽고(대부분의 제공업체는 프롬프트 및 완료 토큰 수를 포함함) 이를 사용하여 시간이 지남에 따라 로컬 추정기를 보정하십시오.
- 엄격한 경계가 아닌 안전 마진을 유지하십시오. 제공업체의 TPM 한도가 추정 사용량과 가깝다면, 한계치에서 바로 보내기보다 요청을 지연하거나 분할하십시오.
- 프롬프트가 크거나 호출 간 반복되는 경우, TokenLab의 토큰화 동작 및 프롬프트 분할 전략을 참조하여 한계에 도달하기 전에 요청당 토큰을 줄이는 구체적인 방법을 확인하십시오. 호출당 토큰을 줄이는 것이 더 높은 티어를 협상하는 것보다 종종 더 저렴한 해결책입니다.
트래픽 셰이핑 및 모델 폴백
지터가 포함된 지수 백오프를 사용하십시오. 재시도할 때마다 대기 시간을 두 배로 늘리고 무작위 지터를 추가하여 동시 클라이언트들이 동시에 재시도하지 않도록 하십시오.
사용자 또는 작업별 트래픽 셰이핑을 적용하십시오. 사용자당 동시 호출을 제한(예: 동시 3개, 초당 5개 요청 버스트)하여 한 명의 헤비 유저가 계정 전체 한도를 소진하여 다른 사용자들의 성능을 저하시키지 않도록 하십시오.
전송 전 토큰 예산 추정을 수행하십시오. 클라이언트 측에서 토큰을 계산하고, 요청이 추적 중인 TPM 예산을 초과할 경우 전송 후 기대하기보다 지연하거나 분할하십시오.
안전망으로서의 모델 폴백을 사용하십시오. 기본 모델이 429를 반환하면 별도의 제한과 유사한 기능을 가진 대체 모델로 라우팅하십시오. 코딩 작업은 Claude Sonnet 5에서 DeepSeek V4 Pro 또는 Kimi K2.7 Code로 장애 조치할 수 있습니다. 대용량 저비용 워크로드는 현재 모델 카탈로그의 저비용 라우팅 티어에 속하는 DeepSeek V4 Flash, Gemini 3.5 Flash, Qwen3.7 Plus 간에 장애 조치할 수 있습니다.
속도 제한 처리 체크리스트
| 범주 | 확인 사항 | 즉각적인 조치 | 장기적인 해결책 |
|---|---|---|---|
| 요청 제한 | RPM 헤더 값, 버스트 빈도 | 클라이언트 요청 스로틀링, 로컬 속도 제한기 추가 | 사용자별 티어, 서버 측 큐잉 |
| 토큰 제한 | 모델별 TPM 예산, 호출당 평균 토큰, 응답 보고 사용량 | 토큰 사전 계산, 대용량 프롬프트 분할, 한계치 근접 시 호출 지연 | 토큰 예산 기반 배치 처리, 대용량 작업을 저비용 모델로 라우팅 |
| 동시성 제한 | 최대 동시 스트림 또는 연결 | 클라이언트당 동시 요청 제한, 유휴 스트림 종료 | 연결 풀링, 단계적 스트림 시작 |
| 할당량 / 잔액 | 계정 잔액, 일일 지출 한도 | 크레딧 충전, 지출 한도 조정 | 잔액 부족 알림, 선불 자동 충전 |
일반적인 제한 범위: 확인 가능한 것과 없는 것
이 주제에 대한 2차 검색은 종종 "일반적인" RPM/TPM 수치 표를 원합니다. 우리는 이를 임의로 만들지 않을 것입니다. 게시된 티어별 제한은 자주 변경되며, 계정 기록 및 사용 티어에 따라 다르고, 이 문서에서 사용할 수 있는 증거의 일부가 아닙니다.
| 질문 | 상태 | 검증 단계 |
|---|---|---|
| 프론티어 모델의 "일반적인" RPM 제한은 무엇인가요? | 이 증거 세트에서 확인되지 않음 | 제공업체 계정 대시보드 또는 속도 제한 응답 헤더 직접 확인 |
| 1M 컨텍스트 모델의 "일반적인" TPM 제한은 무엇인가요? | 이 증거 세트에서 확인되지 않음 | 일주일간의 트래픽 응답 헤더에서 실제 사용량을 기록하여 자체 기준선 구축 |
| 사용 티어가 이 수치를 변경하나요? | 일반적인 제공업체 동작에 기반하여 그럴듯함, 여기서는 벤치마킹되지 않음 | 제공업체 콘솔에서 현재 티어 제한 확인 |
| TokenLab의 집계 제한이 업스트림 제공업체 제한과 정확히 일치하나요? | 이 증거 세트에서 확인되지 않음 | 용량 계획 전 TokenLab API 문서에서 확인 |
제한 사항
- GPT-5.5, Claude Opus 4.8, Gemini 3.5 Flash 또는 여기에 언급된 다른 모델에 대한 공식 RPM/TPM 수치는 제공되지 않았습니다. 위 가격 표의 모든 수치는 컨텍스트 윈도우 크기와 토큰당 비용이며, 속도 제한이 아닙니다.
- TokenLab의 게이트웨이가 모든 업스트림 제공업체에 걸쳐 속도 제한 헤더를 완전히 통합하는지, 아니면 일부를 변경 없이 통과시키는지 여부는 이 증거 세트에서 확인되지 않았습니다. 문서에서 현재 게이트웨이 동작을 확인할 때까지 헤더 파싱을 제공업체별로 처리하십시오.
- 이 문서의 모델 이름은 2026-07-07에 관찰되어 2026-07-14에 만료되는 TokenLab 모델 SSOT를 반영합니다. 모델 문자열을 하드코딩한 코드를 배포하기 전에 모델 디렉토리에서 현재 가용성을 확인하십시오.
- 제공업체 측 계산 대비 토큰 추정 정확도는 이 증거 세트에서 벤치마킹되지 않았습니다. 고정된 오프셋을 신뢰하기보다 응답 보고 사용량에 대해 자체 추정기를 보정하십시오.
FAQ
요청 수가 제한 미만인데도 앱에서 429 오류가 발생하는 이유는 무엇인가요? 먼저 분당 토큰(TPM) 예산을 확인하십시오. 단일 대용량 프롬프트가 요청 수는 낮게 유지되더라도 토큰 허용량을 소진할 수 있습니다. 동시성도 확인하십시오. 열려 있는 스트리밍 연결은 RPM과 TPM이 모두 정상으로 보여도 새 요청을 차단할 수 있습니다.
429 오류를 받으면 즉시 재시도해야 하나요?
아니요. retry-after에 지정된 기간을 기다리거나, 해당 헤더가 없는 경우 지터를 포함한 지수 백오프를 사용하십시오. 즉시 재시도하면 썬더링 허드(thundering-herd) 효과의 위험이 있으며 잠금 기간이 연장될 수 있습니다.
로컬 토큰 카운트가 제공업체가 실제로 청구하는 것과 일치하는지 어떻게 알 수 있나요? 정확히 알 수는 없습니다. 클라이언트 측 토크나이저는 근사치입니다. 각 응답 본문에 반환된 토큰 사용량을 읽고 이를 사용하여 시간이 지남에 따라 추정기를 보정하며, 추정된 한계치에서 바로 요청을 보내기보다 안전 마진을 유지하십시오.
TokenLab은 모든 모델에 걸쳐 하나의 통합된 속도 제한 헤더 세트를 노출하나요? 여기서 이용 가능한 증거로는 확인되지 않았습니다. 서로 다른 업스트림 제공업체는 서로 다른 헤더 형식을 반환하며, TokenLab이 어느 정도의 정규화를 적용하는지는 가정하기보다 현재 API 문서에서 확인해야 할 사항입니다.
플랜을 업그레이드하지 않고 속도 제한을 피하려면 어떻게 해야 하나요? 토큰 예산 책정, 로컬 동시성 제한, 모델 폴백을 결합하십시오. 전송 전 토큰을 추정하고, 긴 프롬프트를 분할하며, 기본 한도에 도달했을 때 Claude Sonnet 5에서 DeepSeek V4 Pro로 라우팅하는 것과 같이 대체 모델로 라우팅하십시오.
시작하기
속도 제한은 AI API를 구축할 때 발생하는 사실이지만, 서비스 중단을 일으킬 필요는 없습니다. TokenLab의 게이트웨이는 현재 모델 카탈로그와 실시간 가격 및 처리량 데이터에 대한 액세스를 제공하므로 제한을 추측하는 대신 우회하여 라우팅할 수 있습니다. 애그리게이터 트레이드오프를 평가 중이라면 OpenRouter 비교에서 폴백 동작 및 운영 오버헤드를 더 자세히 다룹니다. tokenlab.sh에서 API 키를 받고, 제공업체별로 만들지 말고 재시도 및 폴백 로직을 한 번만 구축하십시오.
출처
2026-07-07 기준 가격
- TokenLab model directory2026-07-07 기준 확인
