GPT API를 호출하는 함수를 배포했습니다. 스테이징 환경에서는 잘 작동합니다. 하지만 프로덕션 환경에서 첫 100명의 사용자가 접근하자, 로그에는 429 Too Many Requests 메시지가 가득 찹니다. 이제 추측해야 합니다. 분당 요청 수(RPM) 문제일까요, 분당 토큰 수(TPM) 문제일까요, 아니면 일일 한도(Daily Cap) 문제일까요? 아직 1단계(Tier 1)에 머물러 있나요? 지난주에 변경한 모델이 이전 모델보다 더 엄격한 제한을 가지고 있었나요?
OpenAI와 함께 작업해 본 경험이 있다면, 새로운 모델이 출시될 때마다 속도 제한 문제가 더 복잡해졌다는 것을 아실 겁니다. GPT-5.5는 GPT-4.1과 다른 제한을 가지며, 이미지 모델은 텍스트 모델과 다르게 계산되고, 지출이 증가함에 따라 사용량 티어는 조용히 변경됩니다. Apidog는 각 요청의 응답 헤더를 검사하고, 동시 트래픽을 시뮬레이션하며, 코드를 배포하기 전에 어떤 제한에 걸리는지 정확히 확인할 수 있는 단일 작업 공간을 제공합니다. 아직 Apidog가 없다면 다운로드하세요. 아래 워크플로우는 무료 플랜에서도 작동합니다.
실제로 중요한 네 가지 제한
OpenAI는 모든 GPT API 키에 여러 속도 제한을 적용합니다. 모든 프로덕션 애플리케이션에서 다음 네 가지 제한이 적용되는 것을 볼 수 있습니다.
- RPM (분당 요청 수): 분당 전송할 수 있는 API 호출 수. 대부분의 티어에서 가장 낮은 한도입니다.
- TPM (분당 토큰 수): 분당 처리할 수 있는 입력 및 출력 토큰의 총합. 대부분의 사람들이 잊어버리는 한도입니다.
- RPD (일일 요청 수): 무료 및 티어-1 키에 대한 일일 상한선. 대부분의 텍스트 모델에서는 더 높은 티어에서 사라집니다.
- IPM / TPD / 배치 큐 제한: 이미지 생성, 오디오, 임베딩 및 배치 엔드포인트에 대한 모델별 한도. 각 엔드포인트 제품군에는 자체 상한선이 있습니다.
요청이 거부되면 API는 HTTP 429와 다음과 같은 JSON 본문을 반환합니다.
{
"error": {
"message": "Rate limit reached for gpt-5.5 in organization org-abc on tokens per min (TPM): Limit 30000, Used 28432, Requested 3120.",
"type": "tokens",
"param": null,
"code": "rate_limit_exceeded"
}
}
본문에서 어떤 한도(예: tokens, requests 또는 때로는 tokens_usage_based)를 초과했는지 알려준다는 점에 주목하세요. 문제가 발생했을 때 가장 먼저 읽어야 할 부분입니다. TPM 한도 초과 오류는 RPM 한도 초과 오류와 다르게 보이며, 해결책도 다릅니다. 모든 429 오류가 같은 429 오류는 아닙니다.
HTTP 수준에서 429가 무엇을 의미하는지에 대한 전체적인 참조는 MDN 429 문서와 RFC 6585 사양을 참조하세요. 재시도 헤더 및 티어 이동과 관련된 OpenAI 특정 동작에 대해서는 OpenAI가 유지 관리하는 공식 속도 제한 페이지를 즐겨찾기에 추가해 두는 것이 좋습니다.
티어 작동 방식 및 승격(또는 정체)되는 이유
GPT API 키는 OpenAI 사용량 티어 안에 있습니다. 티어는 RPM 및 TPM 한도 뒤에 있는 실제 수치를 결정합니다. 계정의 총 지출과 첫 결제 시기에 따라 티어가 올라갑니다. 무료부터 티어 5까지 총 6개의 티어가 있으며, 텍스트 모델의 대략적인 형태는 다음과 같습니다.
| 티어 | 지출 조건 | 대기 조건 | 텍스트 RPM | 텍스트 TPM |
|---|---|---|---|---|
| 무료 | 없음 | 없음 | 3 | 40k |
| 1 | $5 지불 | 없음 | 500 | 모델별 30k–200k |
| 2 | $50 지불 | 7일 | 5,000 | 450k |
| 3 | $100 지불 | 7일 | 5,000 | 1M |
| 4 | $250 지불 | 14일 | 10,000 | 2M |
| 5 | $1,000 지불 | 30일 | 10,000 | 2M+ |
위 수치는 예시입니다. 정확한 한도는 시간이 지남에 따라 변동하며 모델마다 다릅니다. 워크로드를 측정하기 전에 대시보드 또는 (아래에서 다룰) 자체 API 응답 헤더에서 실시간 한도를 직접 확인하세요.
두 가지 실용적인 의미:
- 결제하면 자동으로 승격됩니다. 티어는 선택 사항이 아닙니다. 지출이 티어 조건을 넘고 대기 기간이 지나면, 다음에 이루어지는 요청은 새로운 한도를 적용받습니다. 알림도, 마이그레이션 단계도 없습니다.
- 강등될 수도 있습니다. 계정이 장기간 비활성화되거나 결제 수단이 실패하면 다시 내려갈 수 있습니다. 결제 변경 후에는 프로덕션 환경에서 테스트하십시오.
다른 모델 제공업체의 티어 시스템과 비교하려면 OpenAI API 사용자 속도 제한 설명, Claude API 속도 제한 가이드, 그리고 Grok-3 API 속도 제한 가이드를 참조하세요. 정신 모델은 제공업체마다 동일하지만, 구체적인 수치와 차원은 다릅니다.
응답 헤더에서 실시간 제한 확인하기
현재 제한을 찾기 위해 대시보드를 뒤질 필요가 없습니다. 모든 GPT API 응답은 헤더에 이러한 정보를 담고 있습니다. 다음 네 가지를 찾아보세요.
x-ratelimit-limit-requests: 이 엔드포인트의 RPM 한도.x-ratelimit-remaining-requests: 현재 분에 남은 요청 수.x-ratelimit-limit-tokens: TPM 한도.x-ratelimit-remaining-tokens: 현재 분에 남은 토큰 수.
일반적으로 x-ratelimit-reset-requests와 x-ratelimit-reset-tokens도 있으며, 둘 다 버킷이 다시 채워질 때까지 남은 시간을 사람이 읽을 수 있는 형식으로 제공합니다 (예: 6s, 1m30s).
이러한 정보를 확인하는 가장 깔끔한 방법은 단일 채팅 완성 요청을 보내고, 응답 헤더를 확인하여 자신이 생각하는 티어에 있는지 확인하는 것입니다. Apidog는 이를 한 번의 클릭으로 가능하게 합니다.
단계 1: Apidog에서 GPT 요청 구성하기
Apidog를 열고 새 프로젝트를 생성한 다음 그 안에 새 요청을 추가합니다.
메서드: POST URL: https://api.openai.com/v1/chat/completions
Headers 탭에서:
| 키 | 값 |
|---|---|
Authorization |
Bearer {{OPENAI_API_KEY}} |
Content-Type |
application/json |
이중 중괄호 구문은 Apidog 환경 변수에서 값을 가져오므로, API 키는 요청 자체 내에 저장되지 않습니다. 환경(Environments) 아래에서 변수를 한 번 설정하고, 환경을 전환하여 개인 키와 팀 키 사이를 오갈 수 있으며, 나머지 컬렉션은 자동으로 적용됩니다. OpenAI가 비용 할당을 위해 포함하도록 허용하는 조직 및 프로젝트 ID에도 동일한 트릭이 작동합니다.
Body 탭에서 JSON을 선택하고 다음을 붙여넣습니다.
{
"model": "gpt-5.5",
"messages": [
{"role": "user", "content": "ping"}
],
"max_tokens": 10
}
전송(Send)을 클릭합니다. 정상적인 완성 응답을 받아야 합니다. 이제 응답 패널에서 Headers 탭을 클릭하고 x-ratelimit-* 행으로 스크롤합니다. 이 네 가지 숫자가 현재의 실제 제한입니다. 이를 스크린샷으로 저장하세요. 이것이 테스트의 기준선이 될 것입니다.
채팅 완성 요청 설정에 대해 더 자세히 알아보고 싶다면, Apidog로 ChatGPT API를 테스트하는 방법 가이드에서 인증, 스트리밍, 도구 호출을 전체적으로 다룹니다.
단계 2: 의도적인 버스트로 제한 확인하기
헤더를 읽으면 한도를 알 수 있습니다. 단일 요청을 보내는 것만으로는 한도에서의 동작을 증명할 수 없습니다. 헤더에 명시된 지점에서 실제로 스로틀링이 발생하는지 확인하려면 작은 버스트 테스트를 수행해야 합니다.
Apidog는 동일한 요청을 N번 동시 실행할 수 있는 테스트 러너와 함께 제공됩니다. 저장된 요청을 열고, Send 옆의 드롭다운을 클릭한 다음, Run in Test Scenario를 선택하세요. 다음을 설정합니다.
- 반복 횟수: 50 (또는 명시된 RPM보다 충분히 높은 값)
- 동시성: 10
- 반복 간 지연: 0 ms
실행합니다. 다음 두 가지 결과가 유용합니다.
- 버스트가 끝나기 전에 일부 요청이 429를 반환합니다. 좋습니다. 이는 응답 헤더의 한도와 계정 상태가 일치함을 확인시켜 줍니다.
- 50개의 요청이 모두 성공하고 헤더에
remaining-requests가 예상대로 감소하는 것을 보여줍니다. RPM이 생각보다 높은 것입니다. 정확한 값은 응답 패널에서 확인하세요.
Apidog의 테스트 러너는 각 응답을 기록하므로, 상태 코드별로 정렬하여 모든 429를 한 화면에서 볼 수 있습니다. 429 행을 클릭하여 본문을 읽어보세요. message 필드는 RPM, TPM 또는 일일 한도를 초과했는지 알려줍니다. 이것이 프로덕션 코드에서 크기를 조정해야 하는 차원입니다.
한도에 도달했을 때 무엇을 해야 하는지에 대한 기본 정보는 속도 제한 초과 가이드에서 발생할 수 있는 모든 429 표면을 안내합니다.
단계 3: RPM 초과와 TPM 초과 구분하기
위의 첫 번째 버스트는 각 요청이 작기 때문에 RPM을 측정합니다. TPM을 조사하려면 더 적은 수의 요청을 보내되 각 요청의 크기를 더 크게 해야 합니다. messages가 훨씬 더 큰 페이로드를 전달하도록 요청 본문을 편집하세요.
{
"model": "gpt-5.5",
"messages": [
{"role": "system", "content": "<3,000 tokens of context here>"},
{"role": "user", "content": "Summarise the above in one sentence."}
],
"max_tokens": 200
}
이번에는 동시성 5로 20회 반복하는 또 다른 시나리오를 실행합니다. 30k TPM 한도를 가진 티어 1이라면, 요청 한도에 도달하기 훨씬 전에 토큰 한도에 도달할 것입니다.
이러한 구분은 해결책이 다르기 때문에 중요합니다. 실제 워크로드가 많은 작은 요청을 보낸다면 RPM을 수정해야 합니다: 큐에 넣거나, 배치 처리하거나, 간격을 두어 전송하세요. 더 적지만 큰 요청을 보낸다면 TPM을 수정해야 합니다: 시스템 프롬프트를 다듬거나, prompt_cache 메커니즘으로 컨텍스트를 캐싱하거나, 요청을 분할하세요.
단계 4: 동시 사용자 시뮬레이션
버스트 테스트는 자체 상한선을 측정합니다. 프로덕션 트래픽은 다르게 보입니다. 많은 사용자, 다양한 요청 크기, 안정적인 기준선 위에 발생하는 버스트.
Apidog에서 요청의 세 가지 또는 네 가지 변형(작은, 중간, 큰)을 반복하고 반복 사이에 무작위 대기 시간을 두는 테스트 시나리오를 생성하세요. 러너는 JavaScript 사전 및 사후 요청 스크립트를 지원하므로 다음을 수행할 수 있습니다.
- 반복마다 무작위 메시지 길이를 선택합니다.
- 각 응답 후에
x-ratelimit-remaining-tokens를 읽고, 임계값 아래로 떨어지면 시나리오를 중단합니다. - 200 상태 코드와 429 상태 코드에 대한 지연 시간을 별도로 기록하여 스로틀링이 p95에 어떤 영향을 미치는지 확인할 수 있습니다.
시나리오가 완료되면 보고서에서 상태 코드 히스토그램을 제공합니다. 이 히스토그램은 런북에 고정할 수 있는 가장 유용한 아티팩트입니다. 동료가 “속도 제한에 걸렸나요?”라고 묻는 순간, 다시 실행하여 비교할 수 있습니다.
스로틀링에 걸렸을 때 해야 할 일
벽이 어디에 있는지 측정한 후에는 세 가지 현실적인 선택지가 있습니다.
- 지연 재시도 (Back off). 모든 GPT 호출을 지수 백오프 재시도로 래핑합니다. 429 응답의
x-ratelimit-reset-tokens헤더를 읽고 이를 첫 번째 재시도 지연 시간으로 사용하세요. 이 헤더는 OpenAI가 “얼마나 기다려야 하는가”에 대한 문자 그대로의 답변입니다. 단순한time.sleep(2 ** attempt)도 작동하지만, 기다릴 필요가 없었던 시간을 낭비하게 됩니다. - 큐 (Queue). 트래픽이 버스트성이라면, 요청을 큐에 넣고 한도보다 약간 낮은 속도로 처리하세요. TPM보다 약간 낮은 토큰 버킷 제한기(token-bucket limiter)를 사용하는 것이 표준 패턴입니다. API 속도 제한을 구현하는 방법 및 API에서 속도 제한 구현하기에서 구현 트레이드오프에 대해 자세히 다룹니다.
- 배치 (Batch). OpenAI의 배치 API는 더 높은 한도로 실행되며 동기 호출 비용의 절반입니다. 워크로드가 24시간 처리 시간(야간 데이터 보강, 문서 분류, 임베딩 재구성)을 허용한다면, 이를 배치 API로 이동하여 사용자 대면 트래픽을 위한 동기 할당량을 확보하세요.
하나를 선택하기 전에 스로틀링과 속도 제한의 차이점에 대해 더 자세히 알아보고 싶다면, 스로틀 vs 속도 제한이 용어를 이해하는 가장 빠른 길입니다.
일반적인 GPT 429 오류 및 그 의미
세 가지 유형의 429 오류가 실제 사례의 약 90%를 차지합니다.
Rate limit reached … on requests per min (RPM)은 코드에서 크기에 관계없이 분당 너무 많은 호출을 발생시키고 있다는 의미입니다. 동시성 제어를 추가하세요. 병렬map에서 모든 레코드를 실행하지 말고, RPM을 안전 계수 2로 나눈 값으로 워커 풀을 제한하세요.Rate limit reached … on tokens per min (TPM)은 호출이 너무 크다는 의미입니다. 프롬프트를 감사하세요. 대부분의 TPM 초과는 시간이 지남에 따라 커진 시스템 프롬프트나 전체 문서를 컨텍스트에 채워 넣는 RAG 파이프라인에서 발생합니다. 다듬거나, 캐싱하거나, 분할하세요.You exceeded your current quota, please check your plan and billing details는 429처럼 보이지만 실제로는 속도 제한이 아니라 결제 한도입니다. 계정이 월별 지출 한도에 도달했거나, 등록된 카드 결제가 실패했거나, 선불 잔액이 소진된 경우입니다. 해결책은 코드에 있는 것이 아니라 결제 대시보드에 있습니다.
자주 묻는 질문
- GPT 속도 제한을 테스트하는 데 Apidog 비용이 드나요? 아니요. 무료 플랜은 단일 요청 테스트 및 소규모 동시 테스트 실행을 지원합니다. 더 큰 테스트 부하, 팀 작업 공간 또는 예약된 실행을 원할 경우에만 유료 플랜이 필요합니다. 자세한 내용은 Apidog 가격 책정을 참조하세요.
- 실제 토큰을 사용하지 않고 속도 제한을 테스트할 수 있나요? 부분적으로 가능합니다. 가장 저렴한 기준선 확인은
max_tokens: 1과 한 글자 메시지를 사용하는 단일 요청입니다. 비용은 1센트 미만이며 헤더는 완전히 반환됩니다. 버스트 테스트의 경우 실제 토큰을 소비하지만, 각 호출을 작게 유지할 수 있습니다. 완전히 오프라인으로 예행연습을 하고 싶다면, Apidog의 목 서버를 사용하여 429 응답 형태를 시뮬레이션하고 OpenAI를 전혀 호출하지 않고도 재시도 로직이 작동하는지 증명할 수 있습니다. - 내 티어 1 키가 동료의 티어 1 키보다 느리게 느껴지는 이유는 무엇인가요? 티어 한도는 키별이 아닌 조직별입니다. 귀하의 키가 다른 헤비 사용자와 공유되는 조직에 있다면, 그들의 트래픽과 경쟁하는 것입니다. Apidog는 이를 명확하게 보여줄 수 있습니다. 두 키로 동일한 요청을 나란히 실행하고
x-ratelimit-remaining-tokens감소를 비교해보세요. - 어떤 모델이 어떤 제한을 가지고 있는지 어떻게 알 수 있나요? 응답 헤더를 읽으세요. 블로그 게시물(이 게시물 포함)의 일반적인 표를 신뢰하지 마세요. Apidog에서 각 모델에 대해 저렴한 요청 하나를 보내고 헤더를 기록하세요. 이름은 같지만 스냅샷 버전이 다른 모델(예:
gpt-5.5vsgpt-5.5-0901)은 다른 한도를 가질 수 있습니다. - 스트리밍 요청은 다르게 계산되나요? TPM의 경우 그렇습니다. 스트리밍 요청은
max_tokens를 기반으로 토큰을 선점하므로, 실제 완성이 짧더라도 긴max_tokens값은 TPM 예산을 소모할 수 있습니다.max_tokens를 가장 현실적인 최저 상한선으로 낮추세요. Apidog로 ChatGPT API를 테스트하는 방법에서 스트리밍 동작을 다룹니다. - Apidog 속도 제한 테스트를 팀과 공유할 수 있나요? 예. 공유 프로젝트에 요청과 테스트 시나리오를 저장하세요. 작업 공간의 모든 사용자는 환경을 전환하여 자신의 키로 동일한 버스트를 실행할 수 있습니다. 이렇게 하면 "내 키가 스로틀링된 건가요 아니면 다른 팀원의 키가 스로틀링된 건가요?"라는 질문이 10초짜리 질문이 됩니다.