HTTP 429 Too Many Requests — 요청 과다·속도 제한 원인·해결·예방

HTTP 429 Too Many Requests — 요청 과다·속도 제한 원인·해결·예방

API를 호출하거나 사이트를 빠르게 새로고침하다가 "429 Too Many Requests" 또는 "요청이 너무 많습니다"를 만나면, 서버가 "잠깐, 너무 빨리·너무 많이 보내고 있다"고 제동을 건 것이다. 자원이 없거나(404) 서버가 망가진 것(500)이 아니라, 정해진 속도 제한(rate limit)을 넘었다는 신호다.

 

429는 4xx 클라이언트 오류이지만 성격이 독특하다. 요청 하나하나는 멀쩡한데 "빈도"가 문제다. 보통 Retry-After 헤더로 "언제 다시 오라"를 알려준다. 이 글은 429의 의미, 자주 나오는 원인, 속도 제한·재시도 코드, 단계별 진단·해결, 그리고 503과의 차이까지 정리한다.

 

HTTP 429 Too Many Requests

이 글의 구성

 

🔎429 에러 메시지와 의미

🧩자주 나오는 발생 원인 5가지

💻재현 시나리오와 속도 제한·재시도 코드

🛠해결 방법과 단계별 진단

⚖️429 vs 503 vs 403 비교

💬자주 묻는 질문 5가지

---

🔎 429 에러 메시지와 의미

429는 HTTP 응답 상태 코드 가운데 4xx, 클라이언트 측 오류로 분류된다. 클라이언트가 주어진 시간 안에 너무 많은 요청을 보내 속도 제한(rate limiting)을 초과했을 때 반환한다. 요청의 내용이 아니라 빈도가 문제라는 점이 핵심이다.

항목	내용
상태 코드	429
영문 메시지	Too Many Requests
한글 의미	속도 제한 초과 — 너무 많은 요청
분류	4xx 클라이언트 오류
함께 보내는 헤더	Retry-After, X-RateLimit-* (한도·잔여·리셋)

429의 동반자가 Retry-After 헤더다. 서버는 "몇 초 뒤에 다시 오라"를 이 헤더로 알려줄 수 있다. 또한 X-RateLimit-Limit(한도)·X-RateLimit-Remaining(잔여)·X-RateLimit-Reset(리셋 시각) 같은 헤더로 현재 상태를 알려주는 API도 많다. 이 헤더들을 읽으면 언제·얼마나 보낼 수 있는지 알 수 있다.

핵심 관찰 — 내용이 아니라 속도가 문제

429는 "이 요청이 틀렸다"가 아니라 "너무 자주 보낸다"는 신호다. 그래서 해법은 요청을 고치는 게 아니라 보내는 속도를 늦추는 것이다. Retry-After를 무시하고 즉시 다시 쏘면 429만 더 심해진다.

---

🧩 자주 나오는 발생 원인 5가지

원인 1 — API 속도 제한 초과

가장 직접적이다. 대부분의 API는 분당·시간당 호출 한도를 둔다. 짧은 시간에 한도를 넘게 호출하면 429가 난다. 무료 플랜일수록 한도가 낮아 더 쉽게 부딪힌다.

원인 2 — 재시도 폭주·무한 루프

버그로 같은 요청을 반복하거나, 실패 시 쉬지 않고 즉시 재시도하는 코드가 429를 스스로 만든다. 특히 429를 받고도 곧바로 다시 쏘면 악순환에 빠진다. 백오프 없는 재시도 로직이 흔한 범인이다.

원인 3 — 봇·크롤러·스크래핑

자동화 도구가 짧은 시간에 대량 요청을 보내면 서버가 속도 제한으로 막는다. 정상 스크래핑이라도 간격 없이 빠르게 긁으면 429를 만난다. 봇 방어 목적의 의도된 차단이기도 하다.

원인 4 — 공유 IP·NAT 환경

회사·학교·공용 와이파이처럼 여러 사용자가 하나의 공인 IP로 묶이면, IP 기준 속도 제한을 함께 소진한다. 나는 조금만 썼는데 같은 IP의 다른 사용자 탓에 429를 만나는 경우다.

원인 5 — 캐싱 부재로 중복 호출

잘 바뀌지 않는 데이터를 매 화면·매 요청마다 새로 호출하면 불필요하게 한도를 까먹는다. 캐싱이나 요청 합치기 없이 같은 응답을 반복해서 받아오면 429에 쉽게 도달한다.

---

💻 재현 시나리오와 속도 제한·재시도 코드

먼저 429 응답의 모습이다. Retry-After와 X-RateLimit 헤더로 상태를 알려준다.

# 응답
HTTP/1.1 429 Too Many Requests
Retry-After: 30
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0

서버 측에서는 Nginx로 요청 속도를 제한하고, 초과분에 429를 반환하도록 설정한다.

# Nginx 요청 속도 제한 + 초과 시 429 반환
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

location /api/ {
    limit_req zone=api burst=20 nodelay;
    limit_req_status 429;   # 기본 503 대신 429
}

클라이언트 측 핵심은 "즉시 재시도 금지, 지수 백오프"다. Retry-After를 존중하며 점점 간격을 늘려 재시도한다.

# ✗ 나쁜 예 — 429 받고 즉시 다시 쏨 (악순환)
while True:
    r = call_api()
    if r.status != 429: break

# ✓ 좋은 예 — Retry-After 존중 + 지수 백오프
delay = 1
for attempt in range(5):
    r = call_api()
    if r.status != 429: break
    wait = int(r.headers.get("Retry-After", delay))
    sleep(wait)
    delay = delay * 2   # 1 → 2 → 4 → 8 ... (jitter 추가 권장)

---

🛠 해결 방법과 단계별 진단

429는 "보내는 속도를 줄이는" 것이 정답이다. 사용자라면 잠시 대기를, 개발자라면 백오프·캐싱을 적용한다.

입장	해결 방법
방문자	Retry-After만큼 대기 후 재시도, 새로고침 연타 자제, 봇·확장프로그램 점검
재시도 로직	즉시 재시도 금지, Retry-After 존중 + 지수 백오프(+jitter)
요청량	캐싱·배치·요청 합치기로 호출 수 줄이기
한도 확인	X-RateLimit 헤더로 잔여·리셋 확인, 필요 시 플랜 상향
운영자	정당 트래픽이 막히면 limit_req 한도 조정, IP별 정책 점검

단계별 진단 절차

 

01응답의 Retry-After·X-RateLimit 헤더를 먼저 읽는다. 언제·얼마나 보낼 수 있는지 답이 거기 있다.

02내 코드가 짧은 시간에 얼마나 호출하는지 본다. 재시도·루프가 폭주하는지 확인한다.

03재시도에 Retry-After 존중 + 지수 백오프를 적용한다. 즉시 재시도는 절대 금지다.

04캐싱·배치로 불필요한 중복 호출을 줄인다. 안 바뀌는 데이터는 매번 부르지 않는다.

05그래도 부족하면 API 플랜을 올리거나, 운영자는 정당 트래픽 기준으로 한도를 조정한다.

---

⚖️ 429 vs 503 vs 403 비교

429는 비슷한 "거부" 코드들과 헷갈리기 쉽다. 누구 책임이고 무엇이 문제인지로 구분한다.

코드	의미	핵심 구분
429	요청 과다(속도 제한)	4xx — 클라이언트가 너무 많이 보냄
503	서비스 일시 불가	5xx — 서버가 지금 처리 못 함
403	접근 금지	권한 없음(속도와 무관)

특히 429와 503을 헷갈리기 쉽다. 둘 다 Retry-After를 동반할 수 있고 "잠시 후 다시 오라"는 점이 비슷하다. 차이는 책임이다. 429는 "당신(클라이언트)이 너무 많이 보냈다"는 4xx이고, 503은 "서버가 지금 감당이 안 된다"는 5xx다. 429는 내 요청 속도를 줄여 풀고, 503은 서버 쪽 복구를 기다려야 한다.

“

429를 받고 곧바로 다시 쏘는 것은 닫힌 문을 더 세게 두드리는 것과 같다. 기다림(백오프)이 가장 빠른 해결이다.

 

— 429는 속도, 503은 서버, 403은 권한

---

💬 자주 묻는 질문 5가지

Q1429가 떴는데 어떻게 해야 하나요?

먼저 응답의 Retry-After 헤더를 확인하고 그 시간만큼 기다렸다가 다시 시도하세요. 헤더가 없으면 잠시(수십 초) 쉬었다가 재시도합니다. 새로고침을 연타하면 오히려 차단 시간이 길어질 수 있습니다.

Q2나는 별로 안 썼는데 429가 떠요.

공유 IP 환경(회사·공용 와이파이)이라면 같은 IP의 다른 사용자와 한도를 함께 쓰기 때문일 수 있습니다. 또는 백그라운드 앱·확장프로그램이 자동으로 요청을 보내고 있을 수도 있습니다. 네트워크를 바꿔 보면 원인이 좁혀집니다.

Q3API 연동에서 자꾸 429가 나요.

재시도 로직에 지수 백오프를 적용하고 Retry-After를 존중하세요. 그리고 캐싱·배치로 호출 수 자체를 줄이는 것이 근본 대책입니다. X-RateLimit 헤더로 남은 한도를 확인하며 호출 속도를 조절하면 429를 미리 피할 수 있습니다.

Q4429와 503은 뭐가 다른가요?

429는 "클라이언트가 너무 많이 보냈다"는 4xx(내 책임), 503은 "서버가 지금 처리 못 한다"는 5xx(서버 책임)입니다. 둘 다 Retry-After를 줄 수 있지만, 429는 내 요청 속도를 줄여 풀고 503은 서버 복구를 기다립니다.

Q5지수 백오프가 정확히 뭔가요?

재시도 간격을 1초, 2초, 4초, 8초처럼 점점 두 배로 늘리는 방식입니다. 실패가 이어질수록 더 오래 기다려 서버 부담을 줄입니다. 여기에 약간의 무작위 지연(jitter)을 더하면 여러 클라이언트가 동시에 재시도하는 쏠림을 막을 수 있습니다.

---

📌 결론

429 Too Many Requests는 "요청 자체가 아니라 보내는 속도가 문제"라는 신호다. 404가 경로, 401이 인증의 문제였다면, 429는 빈도의 문제다. 그래서 해법은 요청을 고치는 게 아니라 속도를 늦추는 것이다.

실무 원칙은 다음과 같다.

 

⏳ Retry-After를 존중하고 지수 백오프로 재시도한다. 즉시 재시도는 429를 키울 뿐이다.

📦 캐싱·배치로 호출 수 자체를 줄인다. 안 바뀌는 데이터를 매번 부르지 않는다.

📊 X-RateLimit 헤더로 잔여 한도를 모니터링하며 속도를 조절한다.

429 트러블슈팅 체크리스트

01응답 Retry-After·X-RateLimit 헤더 확인 후 그만큼 대기.

02재시도·루프가 폭주하는지 내 호출 빈도 점검.

03즉시 재시도 금지 — Retry-After 존중 + 지수 백오프(+jitter) 적용.

04캐싱·배치·요청 합치기로 불필요한 중복 호출 제거.

05공유 IP·봇·확장프로그램 등 외부 요청 요인 점검.

06부족하면 API 플랜 상향, 운영자는 limit_req 한도 재조정.

07429와 503 구분 — 속도(내 책임) vs 서버 과부하(서버 책임).

---

본 글은 HTTP 429 Too Many Requests 에러의 일반적 원인과 해결 방법을 정리한 자료다. 서버·클라이언트 설정 변경은 운영 환경에 적용하기 전 테스트 환경에서 충분히 검증한다.

 

#429에러 #TooManyRequests #HTTP429 #HTTP에러 #HTTP상태코드 #요청과다 #레이트리밋 #RateLimit #RetryAfter #지수백오프 #API에러 #429와503차이 #Nginx #웹개발 #트러블슈팅