HTTP 429 상태 코드 기준

HTTP 429 Too Many Requests는 클라이언트가 일정 시간 안에 너무 많은 요청을 보냈을 때 서버가 속도를 줄이라고 알리는 상태 코드입니다. 크롤러나 API 클라이언트 입장에서는 실패로만 기록하고 즉시 재시도할 문제가 아니라, 요청 속도와 재시도 시점을 다시 계산해야 하는 신호입니다.

결론부터 말하면 429를 받았을 때의 기준은 세 가지입니다. 첫째, 응답에 Retry-After가 있으면 그 값을 우선합니다. 둘째, 없으면 같은 속도로 반복하지 말고 지수 백오프와 요청 큐 조정을 적용합니다. 셋째, 검색 크롤러를 제어하려는 사이트 운영자는 403이나 404 대신 과부하 상황에서 429 또는 503을 임시로 써야 합니다.

429는 어떤 상황의 코드인가

RFC 6585는 429를 사용자가 주어진 시간 동안 너무 많은 요청을 보냈음을 나타내는 코드로 정의합니다. 이 문서는 서버가 요청을 어떤 단위로 세는지, 사용자를 어떻게 식별하는지는 정의하지 않습니다. 서버마다 전체 서버 기준, 특정 리소스 기준, 인증 사용자 기준, 쿠키 기준, 여러 서버 묶음 기준으로 제한할 수 있습니다.

따라서 429는 단순히 "URL이 없다"거나 "권한이 없다"는 뜻이 아닙니다. 같은 URL이라도 잠시 후에는 허용될 수 있고, 같은 서버라도 다른 사용자나 다른 토큰에는 제한이 다르게 적용될 수 있습니다.

Retry-After가 있으면 어떻게 처리할까

429 응답에는 Retry-After 헤더가 포함될 수 있습니다. RFC 9110 기준으로 Retry-After는 다음 요청을 보내기 전에 기다려야 하는 시간을 나타내며, 값은 HTTP 날짜 또는 초 단위 지연 시간으로 표현됩니다.

HTTP/1.1 429 Too Many Requests
Retry-After: 120
Content-Type: text/plain

위 응답을 받은 클라이언트는 같은 대상에 대한 재요청을 최소 120초 뒤로 미뤄야 합니다. 값이 날짜 형식이면 해당 시각 이후로 재시도합니다. 크롤러에서는 이 값을 단일 요청에만 적용할지, 같은 호스트나 같은 API 그룹 전체에 적용할지 정책을 정해야 합니다. 보통 같은 제한 버킷에 묶인 요청은 함께 늦추는 편이 안전합니다.

Retry-After가 없으면 바로 재시도해도 될까

바로 재시도하는 것은 피해야 합니다. 429는 서버가 현재 요청 속도를 받아들이기 어렵다는 신호이므로, 같은 속도로 반복하면 제한 시간이 길어지거나 차단 정책에 걸릴 수 있습니다. 헤더가 없을 때는 클라이언트 쪽 기본 대기 시간을 두고, 실패가 반복될수록 간격을 늘리는 방식이 무난합니다.

중요한 것은 재시도 횟수보다 재시도 분산입니다. 여러 워커가 동시에 같은 호스트에 다시 붙으면 대기한 뒤에도 트래픽이 한 번에 몰릴 수 있습니다. 그래서 지수 백오프에 무작위 지터를 더하고, 호스트 단위 동시성 제한을 함께 낮추는 편이 좋습니다.

상황	권장 처리	피해야 할 처리
Retry-After 있음	지정된 시간까지 같은 제한 그룹 요청을 보류	헤더를 무시하고 즉시 재시도
Retry-After 없음	기본 대기 시간, 지수 백오프, 지터 적용	고정 간격으로 빠르게 반복
429가 계속 반복됨	호스트 동시성, 초당 요청 수, 우선순위 재조정	워커 수를 늘려 처리량을 보전하려 함

429와 503은 어떻게 구분할까

429는 요청 주체가 너무 많이 요청했다는 의미에 가깝고, 503 Service Unavailable은 서버가 일시적으로 요청을 처리할 수 없다는 의미에 가깝습니다. 둘 다 Retry-After와 함께 쓰일 수 있지만, 클라이언트가 해석하는 기준은 다릅니다.

API의 사용자별 할당량, IP별 제한, 로그인 계정별 제한처럼 요청 주체의 속도를 줄이고 싶다면 429가 더 직접적입니다. 배포, 점검, 전체 서버 과부하처럼 서비스 자체가 일시적으로 처리할 수 없는 상태라면 503이 더 자연스럽습니다.

코드	의미	대표 상황
429	요청자가 허용 속도를 넘김	API rate limit, 크롤러 요청 과다
503	서비스가 일시적으로 처리 불가	점검, 배포, 전체 서버 과부하
403	권한 없음 또는 접근 금지	인증·인가 정책 위반
404	리소스 없음	삭제되었거나 존재하지 않는 URL

검색 크롤러에는 어떤 기준이 필요할까

Google Search Central 문서는 Googlebot 요청이 서버를 압도하는 긴급 상황에서 일시적으로 503 또는 429를 반환해 크롤링 속도를 늦출 수 있다고 설명합니다. 다만 며칠 이상 계속 반환하면 Google이 해당 URL을 색인에서 제외하거나 크롤링을 크게 줄일 수 있으므로 임시 조치로 다뤄야 합니다.

또한 Google의 robots.txt 문서 기준으로 robots.txt 요청에서 4xx 대부분은 유효한 robots.txt가 없는 것처럼 처리되지만, 429는 예외로 다뤄집니다. 그래서 크롤링 속도 제한을 의도하면서 401, 403, 404를 쓰는 것은 적절하지 않습니다.

크롤러 구현에서는 어디에 상태를 저장할까

429 처리는 요청 하나의 예외 처리로 끝나지 않습니다. 같은 호스트, 같은 API 키, 같은 로그인 계정, 같은 경로 그룹처럼 서버가 제한할 가능성이 있는 단위별로 상태를 저장해야 합니다. 그래야 한 URL에서 429가 났을 때 같은 제한 버킷의 다른 요청도 함께 늦출 수 있습니다.

큐 기반 크롤러라면 URL별 재시도 시간만 두는 것보다 호스트 단위의 다음 허용 시각, 현재 동시성, 최근 429 비율을 함께 관리하는 편이 안정적입니다. API 클라이언트라면 서비스 문서가 제공하는 quota 단위와 reset 기준을 우선합니다.

서버가 429를 보낼 때 주의할 점

서버 입장에서는 429 응답 본문에 제한 조건을 설명할 수 있습니다. RFC 6585는 응답 표현에 조건 설명을 포함하는 것이 좋다고 설명합니다. 사용자나 개발자가 원인을 이해할 수 있도록 "분당 요청 수 초과", "계정별 할당량 초과"처럼 공개해도 되는 수준의 정보를 제공하는 것이 좋습니다.

다만 제한 기준을 너무 자세히 공개하면 우회 시도에 도움이 될 수 있습니다. 공개 문서에는 클라이언트가 지켜야 할 속도, 재시도 기준, 문의 경로를 적고, 내부 점수나 탐지 규칙은 노출하지 않는 편이 안전합니다.

자주 묻는 질문

429는 항상 클라이언트 버그인가

항상 그렇지는 않습니다. 클라이언트가 과도하게 요청한 경우가 많지만, 서버의 제한 정책이 너무 낮거나 트래픽이 갑자기 몰린 상황일 수도 있습니다. 클라이언트는 속도를 줄이고, 서버 운영자는 제한 정책과 정상 사용 패턴을 함께 확인해야 합니다.

429를 캐시해도 될까

RFC 6585는 429 응답을 캐시에 저장하면 안 된다고 명시합니다. 일시적인 제한 상태를 캐시하면 제한이 끝난 뒤에도 잘못된 오류가 계속 보일 수 있습니다.

robots.txt로 크롤링 속도를 조절할 수 있을까

robots.txt는 주로 어떤 URL을 크롤링하지 말아야 하는지 알려주는 파일입니다. Google 문서 기준으로 401이나 403 같은 4xx를 속도 제한 목적으로 쓰는 것은 적절하지 않고, 과부하 긴급 상황에서는 429 또는 503을 임시로 사용해야 합니다.

정리

HTTP 429는 요청 속도를 줄이라는 명확한 신호입니다. Retry-After가 있으면 그 값을 우선하고, 없으면 클라이언트가 자체 백오프와 동시성 제한을 적용해야 합니다. 같은 속도로 즉시 반복하는 재시도는 429를 해결하기보다 악화시킬 가능성이 큽니다.

검색 크롤러와 사이트 운영에서는 429를 임시 과부하 대응 수단으로 다뤄야 합니다. 없는 페이지는 404, 권한 문제는 403, 전체 서비스 일시 중단은 503, 요청자가 너무 빠른 상황은 429로 구분하는 것이 기본 기준입니다. 이 글은 2026년 8월 15일 기준 RFC 6585, RFC 9110, MDN HTTP 문서, Google Search Central 문서를 바탕으로 정리했습니다.