AI 자동화가 잘 돌아가다가 429 오류와 함께 멈출 수 있습니다. 이때 같은 요청을 빠르게 반복하면 해결될 것 같지만, 오히려 요청이 더 몰릴 수 있습니다. 먼저 일시적인 처리 한도인지, 사용량이나 결제 상태를 확인해야 하는 문제인지 구분해야 합니다. 이 글은 OpenAI API의 공식 안내를 바탕으로 재시도 흐름을 정리합니다.
오류 번호 다음에 메시지를 읽기
호출 횟수와 토큰 사용량에는 각각 한도가 적용될 수 있습니다. 요청 개수가 적어도 한 번에 보내는 자료가 크면 다른 한도에 먼저 닿을 수 있습니다. 따라서 “오늘 몇 번 쓰지 않았다”는 기억만으로 원인을 판단하기 어렵습니다. 오류 본문의 종류와 설명, 사용 중인 프로젝트와 모델, 관련 응답 헤더를 같이 확인하세요.
공식 문서는 일시적인 rate limit에 대해 대기 후 재시도를 안내합니다. 유효한 Retry-After 값이 있으면 최소 그만큼 기다리고, 없거나 유효하지 않으면 대기 간격을 늘리며 작은 무작위 지연을 더하는 방식이 제시됩니다. 반면 할당량·결제처럼 조치가 필요한 오류는 계속 재시도하지 않도록 구분합니다. OpenAI 한도와 재시도 안내
재시도는 기다림과 끝나는 조건이 한 쌍입니다
예를 들어 사내 공지 초안 30건을 한꺼번에 요청하는 가상의 작업을 생각해 보겠습니다. 모두 동시에 재시도하면 잠깐 뒤에도 같은 지점에 요청이 몰릴 수 있습니다. 작업을 대기열에 두고 일부씩 처리하면서, 일시적인 오류만 다음 시도로 넘기는 흐름을 설계할 수 있습니다. 숫자 30은 설명용 예시이며 권장 처리량이 아닙니다.
- 어떤 오류를 다시 시도할지 정합니다.
- 서버가 안내한 대기 시간을 우선 확인합니다.
- 최대 시도 횟수와 전체 작업의 종료 시간을 함께 정합니다.
- 사용자가 취소하면 대기 중인 재시도도 끝냅니다.
- 한도를 넘긴 작업은 실패 이유와 함께 보류 목록에 남깁니다.
서버가 요구한 대기 시간이 작업 마감보다 길다면 더 짧게 기다려 억지로 호출하기보다 보류를 알리는 편이 맞습니다. 한 번의 요청에 설정한 타임아웃과 여러 번 재시도하는 전체 시간도 구별하세요. 각각은 짧아 보여도 재시도가 겹치면 사용자가 기다리는 시간이 길어집니다.
중복 재시도와 중복 실행을 따로 막기
사용하는 SDK가 이미 자동으로 재시도하는데 바깥 코드에서도 같은 오류를 반복 처리하면 예상보다 많은 호출이 발생할 수 있습니다. 재시도를 누가 담당하는지 한곳에서 확인해야 합니다. 공식 문서 역시 중첩된 재시도 횟수를 고려하고 실패 요청도 분당 한도에 포함될 수 있음을 설명합니다.
또 하나의 문제는 결과를 받은 뒤 이어지는 동작입니다. 초안을 생성하는 단계와 이메일을 발송하는 단계를 하나의 재시도 묶음으로 만들면, 어디까지 성공했는지 모호할 때 같은 메일이 다시 나갈 위험이 있습니다. 생성 결과와 후속 실행의 상태를 나누어 기록하고, 완료된 동작은 확인 없이 반복하지 않도록 설계하세요. 이는 API 오류 처리에서 파생되는 운영상의 점검 제안입니다.
문제 해결에 필요한 최소 기록
오류를 조사하려면 발생 시각, 모델명, 오류 종류, 시도 횟수, 대기 시간, 작업 상태를 남기는 것이 좋습니다. 비밀 키나 원문 전체를 그대로 로그에 넣지는 마세요. 사용자에게는 “진행 중”만 계속 보여 주기보다 대기·보류·실패를 구분해 알리면 다시 눌러야 하는지 판단하기 쉽습니다.
429 대응의 목표는 최대한 많이 다시 부르는 것이 아닙니다. 원인을 나누고 기다릴 수 있는 범위를 정해, 완료 여부를 확실히 남기는 것입니다. 같은 오류가 반복될 때는 호출 속도와 입력 크기, 계정의 한도 상태를 함께 확인하세요.
자료 확인: 2026년 10월 12일. 기능과 제공 조건은 변경될 수 있습니다.