---
title: "LLM API Rate Limits Explained: How to Handle Them in Production"
description: "프로덕션 환경에서 LLM API rate limits를 이해하고 Python으로 처리하는 실전 가이드. 2026년 기준 전략과 구현 방법."
keywords: "llm api rate limits production handling python 2026"
date: 2025-01-15
---

LLM API Rate Limits: 프로덕션에서 제대로 처리하는 법 (2026)

결론부터: GPT-4o 기준 tier 1 계정의 기본 한도는 500 RPM(requests per minute), 30,000 TPM(tokens per minute)이며, Anthropic Claude는 tier 1에서 50 RPM, 40,000 TPM이다. 프로덕션에서 이 한도를 넘으면 429 Too Many Requests가 반환되고, 잘못된 retry 전략 하나가 비용을 3-5배 폭증시킬 수 있다.

이 글은 rate limit이 왜 발생하는지 원리부터, 어떻게 exponential backoff와 token-based throttling을 구현할지까지 다룬다.

---

Rate Limit이 왜 중요한가 — 숫자로 보는 맥락

2024년 기준 OpenAI, Anthropic, Google Gemini 등 주요 LLM 프로바이더의 API 트래픽은 전년 대비 약 400% 증가했다. 이 트래픽 폭증은 rate limit 설계를 더 엄격하게 만들었다.

문제는 rate limit 오류 자체가 아니라 그 처리 방식이다:

• 단순 time.sleep(1) retry → 동시 요청이 많을수록 thundering herd 문제 발생
• 재시도 횟수 무제한 설정 → tool-calling agent의 경우 무한 루프 진입 가능 (이를 “Infinite Loop Failure Mode”라 부른다)
• token count를 무시한 RPM만 체크 → TPM 초과로 여전히 429 반환

TrueFoundry의 AI Gateway 사례에 따르면, rate limit을 제대로 처리하지 않은 멀티테넌트 LLM 서비스에서 단일 heavy user가 전체 TPM의 60-80%를 소비하는 케이스가 빈번하다. 이는 나머지 사용자 전체에게 서비스 장애로 이어진다.

---

Rate Limit의 종류와 구조

LLM API rate limit은 단순히 “초당 몇 번”이 아니다. 4가지 차원이 동시에 적용된다.

제한 유형	설명	초과 시 응답	대응 전략
RPM (Requests Per Minute)	분당 API 호출 횟수	429	Request queuing, backoff
TPM (Tokens Per Minute)	분당 처리 토큰 수 (input+output)	429	Token budgeting, chunking
TPD (Tokens Per Day)	일일 토큰 총량	429	Daily quota monitoring
Concurrent Requests	동시 진행 중인 요청 수	429	Semaphore, connection pool

가장 자주 놓치는 것은 TPM이다. RPM을 철저히 지켜도 하나의 요청에 8,000 토큰짜리 prompt를 넣으면, 4개 요청만으로도 32,000 TPM 한도에 도달한다.

주요 프로바이더 Tier별 Rate Limit 비교 (2025년 기준)

프로바이더	모델	Tier	RPM	TPM	비고
OpenAI	gpt-4o	Tier 1	500	30,000	$5 spending 달성 후
OpenAI	gpt-4o	Tier 2	5,000	450,000	$50 spending 달성 후
OpenAI	gpt-4o-mini	Tier 1	500	200,000	mini는 TPM 여유 큼
Anthropic	claude-3-5-sonnet	Tier 1	50	40,000	기본 tier 낮음
Anthropic	claude-3-5-sonnet	Tier 4	4,000	400,000	$40 spending 달성 후
Google	gemini-1.5-pro	Free	2	32,000	Free tier 매우 제한적
Google	gemini-1.5-pro	Pay-as-you-go	1,000	4,000,000	유료 전환 시 급증

출처: 각 프로바이더 공식 문서, Portkey 비교 자료 참고

---

Rate Limit 처리 핵심 전략 4가지

1. Exponential Backoff with Jitter

가장 기본이지만 가장 많이 잘못 구현되는 전략이다. 단순한 고정 대기 시간은 multiple worker가 동시에 retry할 때 thundering herd를 만든다.

Jitter의 역할: 각 worker에 무작위 지연을 추가해 retry 폭탄이 동시에 서버에 도달하는 걸 막는다.

import asyncio
import random
import httpx
from typing import Any

async def call_llm_with_backoff(
    client: httpx.AsyncClient,
    payload: dict,
    max_retries: int = 5,
    base_delay: float = 1.0,
    max_delay: float = 60.0,
) -> Any:
    """
    Full jitter exponential backoff for LLM API calls.
    max_retries=5로 무한 루프 방지 (tool-calling agent에서 필수)
    """
    for attempt in range(max_retries):
        try:
            response = await client.post("/v1/chat/completions", json=payload)
            
            if response.status_code == 429:
                # Retry-After 헤더가 있으면 그 값을 우선 사용
                retry_after = response.headers.get("retry-after")
                if retry_after:
                    wait_time = float(retry_after)
                else:
                    # Full jitter: [0, min(cap, base * 2^attempt)]
                    cap = min(max_delay, base_delay * (2 ** attempt))
                    wait_time = random.uniform(0, cap)
                
                if attempt == max_retries - 1:
                    raise Exception(f"Rate limit exceeded after {max_retries} retries")
                
                await asyncio.sleep(wait_time)
                continue
                
            response.raise_for_status()
            return response.json()
            
        except httpx.HTTPStatusError as e:
            if e.response.status_code not in (429, 500, 502, 503):
                raise  # 재시도 불가 오류는 즉시 raise
            if attempt == max_retries - 1:
                raise
    
    raise Exception("Unexpected retry loop exit")

핵심 포인트:

• max_retries=5 고정 → tool-calling agent의 무한 루프 방지
• Retry-After 헤더 우선 확인 → 프로바이더가 지정한 대기 시간 준수
• 재시도 불가 오류(4xx except 429)는 즉시 raise → 불필요한 retry 비용 방지

2. Token Budget 관리

RPM만 체크하고 TPM을 무시하면 여전히 429가 발생한다. 요청을 보내기 전에 예상 토큰 수를 계산해야 한다.

실용적 접근:

• tiktoken (OpenAI) 또는 anthropic SDK의 count_tokens()로 request 전 토큰 수 측정
• 분당 사용한 토큰을 sliding window로 추적
• TPM 한도의 80% 초과 시 새 요청 지연

typedef.ai의 프로덕션 데이터에 따르면, token budget을 적용한 파이프라인은 적용 전 대비 429 오류를 평균 73% 감소시켰다.

3. Request Queue + Semaphore

동시 요청 수를 제어하는 것은 RPM/TPM 제어와 별개로 필요하다. Python asyncio의 Semaphore로 concurrent requests를 제한한다.

# 예시 패턴 (동시 요청 10개 제한)
semaphore = asyncio.Semaphore(10)

async with semaphore:
    result = await call_llm_with_backoff(client, payload)

4. 응답 캐싱

동일하거나 유사한 prompt가 반복되는 경우, 캐싱은 rate limit 압박을 가장 효과적으로 줄이는 방법이다.

• Exact match cache: Redis에 hash(prompt + model + params) → response 저장
• Semantic cache: 벡터 유사도 기반 캐싱 (Portkey, GPTCache 등 지원)
• TTL 설정 필수 — RAG 기반 앱에서 stale response를 캐싱하면 hallucination보다 심각한 문제가 생긴다

Portkey의 production 분석에 따르면, 일반적인 LLM 앱에서 동일/유사 prompt의 비율은 약 25-40%이며, 캐싱 적용 시 실효 API 비용을 20-35% 절감할 수 있다.

---

멀티테넌트 환경: 사용자별 Tiered Rate Limiting

자체 서비스에서 여러 사용자에게 LLM 기능을 제공한다면, 사용자별 rate limit 계층화가 필수다.

TrueFoundry가 AI Gateway에서 기본 제공하는 전략을 일반화하면 다음과 같다:

사용자 등급	RPM 할당	TPM 할당	우선순위	초과 시 처리
Free tier	10	5,000	낮음	즉시 429 반환
Pro tier	100	50,000	중간	큐 대기 후 처리
Enterprise	1,000	500,000	높음	별도 API key 사용
Internal	Unlimited	Unlimited	최고	Rate limit 미적용

구현 시 고려사항:

• Free tier 사용자는 즉시 거절(fail-fast)이 UX상 더 낫다 — 큐 대기 후 처리하면 타임아웃이 길어짐
• Enterprise 사용자는 가능하면 별도의 API key를 발급해 rate limit pool을 분리
• Redis를 이용한 sliding window counter로 사용자별 실시간 사용량 추적

---

비용/성능 트레이드오프 분석

Rate limit 처리 전략을 선택할 때 비용과 복잡도를 함께 고려해야 한다.

전략	구현 복잡도	지연 시간 영향	비용 절감 효과	적합한 케이스
Simple retry (fixed sleep)	낮음	높음 (예측 불가)	없음	개발/테스트 환경
Exponential backoff + jitter	낮음	중간	낮음	대부분의 케이스
Token budget + queue	중간	낮음	중간 (10-20%)	배치 처리 파이프라인
Response caching (exact)	중간	매우 낮음	높음 (20-35%)	FAQ봇, 반복 쿼리 앱
Semantic caching	높음	낮음	높음 (25-40%)	대규모 RAG 앱
Multi-provider fallback	높음	낮음	중간	고가용성 필수 서비스
AI Gateway (Portkey 등)	낮음 (관리형)	낮음	높음	빠른 프로덕션 적용

Multi-provider fallback 주의사항: OpenAI가 429를 반환할 때 자동으로 Anthropic으로 전환하는 패턴은 매력적이지만, 두 모델의 output 형식과 품질이 다르기 때문에 응답 검증 레이어 없이 사용하면 예상치 못한 버그가 발생한다.

---

흔한 실수와 오해

실수 1: RPM만 체크하고 TPM 무시

가장 흔한 실수다. 특히 long-context 모델(128K context window)을 사용할 때, 단 2-3개의 요청만으로 TPM 한도를 초과할 수 있다. 요청 전 토큰 계산을 항상 수행하라.

실수 2: 무제한 retry

tool-calling agent에서 특히 위험하다. LLM이 tool을 호출하고, tool이 실패하고, LLM이 다시 tool을 호출하는 루프에서 rate limit 오류가 각 단계를 재시도 트리거로 만들면 하나의 사용자 요청이 수백 번의 API 호출을 생성할 수 있다. 항상 max_retries를 명시적으로 설정하고, agent loop에는 별도의 max_iterations 카운터를 추가하라.

실수 3: 429를 모두 rate limit으로 가정

일부 프로바이더는 content policy 위반, 잘못된 parameter 등에도 429를 반환한다. 응답 body의 error.code 또는 error.type을 파싱해 실제 rate limit 오류인지 확인하고, 그렇지 않은 경우 retry하지 마라.

실수 4: Tier upgrade를 rate limit 해결책으로 기대

tier upgrade는 즉각적이지 않다. OpenAI의 경우 spending 기준이 누적되어야 자동 승급되며, 승급 직후에도 새 limit이 적용되기까지 수 시간이 걸릴 수 있다. 현재 tier의 한도 내에서 동작하도록 코드를 작성하는 것이 우선이다.

실수 5: 개발 환경에서 rate limit 테스트 안 함

프로덕션에서 처음 rate limit을 만나면 이미 늦다. 개발 환경에서 의도적으로 rate limit을 시뮬레이션(예: mock server에서 N번째 요청부터 429 반환)해 retry 로직을 검증하라.

---

모니터링: 무엇을 추적해야 하나

rate limit 처리가 실제로 작동하는지 확인하려면 다음 메트릭을 추적해야 한다:

메트릭	설명	알람 임계값
rate_limit_errors_per_min	분당 429 오류 수	> 5
retry_rate	전체 요청 중 retry된 비율	> 10%
avg_retry_count	성공한 요청의 평균 retry 횟수	> 1.5
token_utilization_pct	TPM 한도 대비 실제 사용률	> 85%
p99_latency_ms	99th percentile 응답 시간	서비스별 SLA
cache_hit_rate	캐싱 적용 시 hit 비율	< 15% (캐싱 전략 재검토)

retry_rate > 10%는 단순히 rate limit 처리 문제가 아니라 아키텍처 레벨의 문제 신호다. 이 수치가 지속된다면 tier upgrade, 프로바이더 다변화, 또는 요청 패턴 자체를 재설계해야 한다.

---

결론

LLM API rate limit은 피할 수 없지만 대부분의 경우 예측 가능하고 처리 가능하다. RPM과 TPM을 동시에 추적하고, jitter가 포함된 exponential backoff와 명시적인 max_retries를 기본값으로 설정하고, 반복 쿼리가 많은 서비스라면 exact match cache부터 적용하라. tool-calling agent를 빌드한다면 무한 루프 방지를 위한 max_iterations 가드는 선택이 아닌 필수다.

참고: 여러 AI 모델을 하나의 파이프라인에서 사용한다면, AtlasCloud는 Kling, Flux, Seedance, Claude, GPT 등 300개 이상의 모델에 단일 API로 접근할 수 있습니다. API 키 하나로 모든 모델 사용 가능. 신규 사용자는 첫 충전 시 25% 보너스(최대 $100).