AI API 요청이 갑자기 거절될 때, rate limit과 재시도 확인법

AI를 활용하여 생성한 이미지입니다.

AI API에서 429가 나왔다고 무조건 기다렸다가 반복 요청하면 안 됩니다. 짧은 시간의 요청 수·토큰 한도를 넘은 경우도 있지만, 크레딧 소진이나 조직·프로젝트 지출 한도에 도달한 경우도 있습니다.[1][2] 먼저 오류 세부 코드와 헤더를 확인해 일시적인 속도 제한인지, 설정·결제 문제인지 구분하세요.

429의 원인을 먼저 나누기

OpenAI는 RPM(분당 요청)과 TPM(분당 토큰)처럼 여러 기준을 적용하며, 먼저 도달한 한도가 요청을 막을 수 있다고 설명합니다. 한도는 조직·프로젝트·모델에 따라 다를 수 있고 일부 모델군이 공유 한도를 사용할 수도 있습니다.[1]

오류가 나왔을 때 기록할 항목

1. HTTP 상태 코드와 오류 객체의 error.code, error.type을 저장합니다.
2. Retry-After 응답 헤더가 있는지 확인합니다.
3. 사용한 모델, 입력·출력 토큰, 최근 요청 수와 동시 실행 수를 기록합니다.
4. 크레딧·조직 지출·프로젝트 지출·사용량 한도를 확인합니다.
5. 재시도 횟수와 전체 경과 시간도 별도 카운터로 남깁니다.

로그에는 API 키, 전체 프롬프트, 개인정보를 그대로 남기지 마세요. 운영에 필요한 요청 ID와 마스킹한 오류 정보는 남기되, 사용자가 보는 화면에는 내부 키·조직 ID·전체 스택을 노출하지 않는 것이 좋습니다.

Retry-After를 우선하는 재시도

OpenAI의 rate limit 안내에서는 Retry-After가 일시적인 제한 뒤 다시 요청하기 전 기다릴 시간을 나타낼 수 있다고 설명합니다.[1] 값이 있으면 임의로 정한 짧은 시간보다 우선하세요. 초 단위 숫자로 해석되지 않는 형식이라면 HTTP 라이브러리의 해석 방법을 확인하고, 안전한 대기값과 오류 기록을 준비해야 합니다.

429인가?
아니오 → 일반 오류 처리
예 → 세부 코드 확인
속도 제한 → Retry-After 우선
          없으면 지수 백오프 + 무작위 지연
          재시도 상한 안에서만 실행
한도·크레딧 오류 → 관리자·결제·사용량 확인
                    자동 재시도하지 않음

지수 백오프와 재시도 상한

여러 클라이언트가 429 뒤에 정확히 같은 1초를 기다리면 다시 동시에 몰릴 수 있습니다. 지수 백오프는 간격을 늘리고, 작은 무작위 지연은 재요청 시점을 분산합니다. 예를 들어 기본 대기 시간에 재시도 횟수에 따른 배수를 적용하되 최대 대기 시간을 둡니다. Retry-After와 계산한 값이 다르면 더 긴 대기를 선택하세요.

• 재시도 횟수와 전체 요청 시간에 상한을 둡니다.
• 동시에 실행할 작업 수를 세마포어·워커 수로 제한합니다.
• 실패한 작업은 대기열에 남기고 무한 루프에 넣지 않습니다.
• 재시도도 새 요청으로 한도에 영향을 줄 수 있어 별도로 집계합니다.

파일 생성·결제·메시지 발송처럼 결과가 중복되면 곤란한 작업은 재시도 전에 중복 실행을 막는 식별자와 완료 상태를 설계하세요. API가 같은 요청을 안전하게 반복할 수 있는지 확인하지 않았다면, 자동 재시도 대신 대기열에 보류하고 사람이 상태를 확인하게 하는 편이 낫습니다.

정확한 대기 숫자는 서비스의 응답과 애플리케이션 요구 사항에 따라 달라집니다. 이 글의 흐름을 SDK에 그대로 복사하기보다 사용하는 언어의 예외 클래스, 헤더, 타임아웃 처리 방식에 맞춰 구현하세요.

재시도하면 안 되는 경우

크레딧 소진, 조직·프로젝트 지출 한도, 승인된 사용량 한도라면 잠시 기다리는 것만으로 회복되지 않을 수 있습니다. OpenAI 오류 안내도 결제·지출·쿼터 문제는 관련 설정을 먼저 수정해야 하며 반복 재시도가 해결책이 아니라고 구분합니다.[2] 이때 API 키를 새로 만드는 것도 조직 한도나 결제 문제를 초기화하지 않습니다.

요청을 덜 몰리게 하는 설계

• 사용자 요청을 바로 모두 전송하지 말고 짧은 대기열을 둡니다.
• 동시 실행 수를 제한하고 버스트를 속도 조절합니다.
• 긴 대화와 중복 문서를 줄여 입력 토큰을 관리합니다.
• 필요한 답변 길이에 맞게 출력 상한을 설정합니다.
• 같은 결과를 반복하지 않도록 캐시를 검토합니다.
• 대량 작업은 제공되는 처리 방식과 한도를 확인해 분산합니다.

입력을 줄일 때는 무작정 내용을 잘라 품질을 낮추기보다 오래된 대화, 중복 문서, 불필요한 출력 형식을 먼저 정리하세요. 요청 수가 적어도 입력이 길면 TPM 한도에 닿을 수 있고, 평균 사용량이 낮아도 특정 순간의 버스트가 429를 만들 수 있습니다.

상태 코드별로 나누는 간단한 흐름

성공 → 결과 반환
429 → 세부 코드 확인
      속도 제한이면 제한적 재시도
      크레딧·지출·사용량이면 관리자 확인
401·403 → 인증·권한·지역·모델 접근 확인, 자동 재시도 안 함
500·503 → 짧은 대기 후 제한적 재시도, 계속되면 상태 확인

서버 오류와 rate limit은 원인이 다릅니다. OpenAI 오류 문서는 500·503을 제한적으로 재시도할 수 있는 오류로 안내하지만, 429의 결제·크레딧·지출 문제와 같은 방식으로 처리하지 않습니다.[2]

사용자 안내와 모니터링

일시 제한에는 “요청이 잠시 많아 처리 중입니다. 잠시 후 다시 시도해 주세요”처럼 안내하고, 크레딧·지출 한도에는 “서비스 사용 한도에 도달해 관리자 확인이 필요합니다”라고 구분하세요. API 키와 내부 오류 상세는 운영자 로그에서만 확인합니다.

자주 묻는 질문

429가 나오면 몇 초 뒤에 보내나요?

고정된 값은 없습니다. Retry-After가 있으면 따르고, 없으면 지수 백오프와 무작위 지연을 사용합니다. 크레딧·지출·사용량 한도라면 기다림만으로 해결되지 않습니다.[1][2]

API 키를 새로 만들면 풀리나요?

대개 그렇지 않습니다. 제한과 지출은 조직·프로젝트·모델에 연결될 수 있으므로 키 교체가 한도를 초기화하지 않습니다.[1][2] 키 노출이나 인증 오류일 때만 교체를 검토하세요.

모델을 바꾸면 피할 수 있나요?

모델별 한도가 다를 수 있지만 공유 한도도 있습니다.[1] 비용·품질·기능을 확인하고 단순 우회로 무작정 바꾸지 마세요.

무한 재시도하면 언젠가 성공하나요?

아닙니다. 일시 제한에도 재시도 상한과 전체 타임아웃을 두고, 계속 실패하면 대기열이나 사용자 재요청으로 넘기세요.

정리 체크리스트

• 429의 code·type·Retry-After를 기록합니다.
• RPM·TPM·동시성·버스트를 함께 봅니다.
• 속도 제한에만 백오프와 제한적 재시도를 적용합니다.
• 크레딧·지출·사용량 문제는 자동 재시도하지 않습니다.
• 키와 개인정보를 로그에서 마스킹합니다.
• 사용자에게 원인에 맞는 메시지를 보여 줍니다.

429 대응의 핵심은 “기다리기”가 아니라 원인을 분류하는 것입니다. 속도 제한이면 Retry-After와 백오프, 입력·동시성·대기열 조정을 사용하고, 결제나 사용량 한도면 관리 화면과 권한을 확인해야 합니다.[1][2]

관련 글

• AI 답변이 중간에 잘릴 때, 출력 길이와 토큰을 확인하는 법
• AI API 키를 안전하게 보관하고 노출 시 대응하는 법
• AI JSON 응답 형식이 흔들릴 때 구조화된 출력 확인법

Sources

1. [1] OpenAI API, Rate limits — RPM·TPM, 조직·프로젝트·모델별 한도와 응답 헤더.
2. [2] OpenAI API, Error codes — 429 속도·크레딧·지출·사용량 오류와 500·503 대응.