429 vs 503 차이: 요청 한도인가요, 서버 과부하인가요?

429 Too Many Requests는 클라이언트인 여러분이 주어진 시간 동안 요청을 너무 많이 보냈다는 뜻이므로, 속도를 늦춰야 합니다. 503 Service Unavailable은 서버 쪽의 과부하나 점검 때문에 서버가 일시적으로 요청을 처리할 수 없다는 뜻입니다. 둘 다 다시 시도하기 전에 얼마나 기다릴지 알려 주는 Retry-After 헤더를 담을 수 있습니다.

정의는 RFC 6585와 RFC 9110에서 인용했고, 2026-09-28에 확인했습니다. Sume 예시는 오류와 요청 한도 (영문)와 Generation admission 문서, 그리고 따로 표시한 곳은 현재 API 코드에서 가져왔습니다.

429와 503의 차이는 무엇인가요?

누가 제한을 받느냐입니다. RFC 6585는 429를 사용자가 주어진 시간 동안 요청을 너무 많이 보낸 상태, 즉 요청 한도(rate limiting)로 정의하며, 사용자를 어떻게 식별하고 요청을 어떻게 셀지는 서버에 맡깁니다. RFC 9110은 503을 일시적인 과부하나 예정된 점검 때문에 서버가 요청을 처리할 수 없는 상태로 정의하며, 이 상태는 얼마간 지나면 해소될 가능성이 높습니다.

즉 429는 여러분이 통제할 수 있는 요청 속도의 문제이고, 503은 여러분이 통제할 수 없는 서버 상태의 문제입니다. RFC 9110은 서버가 과부하 상태라고 해서 반드시 503을 보내야 하는 것은 아니라고도 적고 있습니다. 그냥 연결을 거부하는 서버도 있습니다.

Sume API에서 429와 503은 무슨 뜻인가요?

상태마다 코드가 여러 개 있으며, 모두 같은 방식으로 풀리지는 않습니다.

503은 얼마나 지속되나요?

서버에 필요한 만큼입니다. RFC 9110은 이 상태가 얼마간 지나면 해소될 가능성이 높다는 것, 그리고 서버가 Retry-After를 보내 기다릴 시간을 제안할 수 있다는 것만 말합니다. Sume에서는 표에서 보듯, 현재 코드에서 retry-after를 담는 503 두 가지가 분이 아니라 초 단위의 대기를 요청합니다.

429나 503은 재시도해야 하나요?

반복해도 안전한 요청이라면 대개 기다린 뒤 재시도하면 됩니다. 그러니 생성 요청은 Idempotency-Key와 함께 보내세요. 예외는 오류 본문에 retryable: false가 있을 때입니다. 현재 코드는 503 provider_not_configured를 그렇게 표시하며, 문서는 이 오류를 공격적으로 재시도하지 말라고 합니다. Sume에서는 읽기와 쓰기의 예산이 분리되어 있으므로, 상태를 빠르게 폴링해도 내 생성 요청이 429를 받지는 않습니다. 또 폴링 루프 안에서 받은 429나 503은 일시적인 것이며, 실행은 계속됩니다. 요금제별 예산은 Sume API 오류와 요청 한도에 나와 있습니다.

용량 오류에서는 멱등성 키에 주의하세요. 현재 코드에서 queue_full이나 provider_capacity_exceeded로 거절된 생성 요청은 실패한 Job으로 저장되고, 같은 Idempotency-Key로 다시 보내면 그 오류가 다시 돌아옵니다. 그러니 용량이 풀린 뒤 같은 키로 재시도하면 성공하리라고 기대하지 마세요. 더 이상 필요 없는 큐의 Job을 취소하면 용량이 더 일찍 풀립니다. 호출 방법은 Job을 취소하는 방법에서 보여 줍니다.

내 API는 429와 503 중 무엇을 반환해야 하나요?

클라이언트 하나가 주어진 시간 동안 요청을 너무 많이 보내면 429를, 서버 자체가 지금 요청을 처리할 수 없으면 503을 반환하세요. 대기 시간을 알면 어느 쪽이든 Retry-After를 함께 보내고, RFC 6585에 따라 429에는 상황을 설명하는 세부 정보를 넣으세요.

엔드포인트가 Sume의 Run 웹훅을 받는다면, 두 코드 모두 백프레셔로 쓸 수 있습니다. 전달에 429나 503과 Retry-After로 응답하면, Sume는 자체 백오프와 여러분이 보낸 값 중 더 긴 쪽만큼, 최대 한 시간까지 기다립니다. 이 헤더의 두 가지 형식과 읽는 법은 Retry-After 헤더에서 다룹니다.