HTTP 429 에러(Too Many Requests) 뜻과 해결 방법: 트위터·크롬·API

HTTP Error 429란 무엇인가?

HTTP 429 Too Many Requests는 서버가 요청 속도를 제한하고 있다는 뜻입니다. 사용자 본인이나 IP 주소, 또는 앱이 정해진 시간 안에 허용된 수보다 많은 요청을 보냈기 때문입니다. 이 상태는 일시적입니다. 서버는 정상적으로 작동하고 있으며, 지금은 응답하지 않기로 선택한 것뿐입니다.

이 코드는 바로 이런 경우를 위해 RFC 6585(2012년)에서 추가되었고, 응답에는 얼마나 기다려야 하는지 알려 주는 Retry-After 헤더가 들어 있을 수 있습니다. 사람이 몰리는 사이트를 둘러볼 때, API를 호출할 때, 파일을 대량으로 내려받을 때, 또는 많은 사람이 같은 IP 주소를 쓰는 VPN에서 자주 마주칩니다.

비슷한 오류와는 뜻이 다릅니다. 401은 로그인하지 않았다는 뜻이고, 403은 접근이 허용되지 않았다는 뜻이며, 429는 접근은 허용되지만 요청이 너무 빠르다는 뜻입니다.

429 오류는 어떻게 표시되나?

어떤 메시지가 보이는지는 누가 응답하느냐에 따라 다릅니다. 사람들이 많이 검색하는 메시지는 다음과 같습니다:

서버에서 무언가 고장 났다는 뜻인 500 오류와 달리, 429는 HTTP 분류상 클라이언트 오류입니다. 서버가 과도한 요청으로부터 자신을 보호하고 있는 것입니다.

레이트 리미팅의 작동 원리

레이트 리미팅(속도 제한)은 클라이언트가 일정 시간 안에 보낼 수 있는 요청 수를 서버가 제어하는 기술입니다. 한도를 넘으면 서버는 보통 429로 응답합니다(403이나 503으로 응답하는 서버도 있습니다).

일반적으로 사용되는 레이트 리미팅 알고리즘은 다음과 같습니다:

• 고정 윈도우(Fixed Window) — 서버가 시간 창당 N개의 요청을 허용합니다(예: 분당 100개 요청). 카운터는 고정된 간격으로 초기화됩니다.
• 슬라이딩 윈도우(Sliding Window) — 고정 윈도우와 유사하지만, 각 요청마다 시간 창이 이동합니다. 윈도우 경계에서 발생하는 갑작스러운 트래픽 폭주를 방지합니다.
• 토큰 버킷(Token Bucket) — 서버가 일정한 속도로 토큰을 보충합니다. 각 요청은 토큰 하나를 소비하며, 토큰이 모두 소진되면 요청이 거부됩니다.
• 리키 버킷(Leaky Bucket) — 폭주 규모에 관계없이 일정한 속도로 요청을 처리합니다. 초과 요청은 대기열에 쌓이거나 폐기됩니다.

많은 API가 응답 헤더로 한도를 알려 줍니다. 예를 들어 GitHub는 x-ratelimit-limit(시간당 허용 요청 수), x-ratelimit-remaining, x-ratelimit-used, x-ratelimit-reset(윈도우가 초기화되는 시각, Unix 초)을 보냅니다. 같은 용도의 표준 헤더로 RateLimit과 RateLimit-Policy를 제안하는 IETF 초안도 있습니다.

서비스가 어떤 알고리즘과 시간 윈도우를 쓰는지 알면 한도 안에서 동작하도록 클라이언트를 설계할 수 있습니다.

HTTP Error 429의 주요 원인

원인은 누가 이 오류를 보느냐에 따라 다릅니다:

방문자를 위한 429 오류 해결 방법

웹사이트를 탐색하다가 429 오류를 발견했다면, 아래 해결 방법을 순서대로 시도해보세요. 가장 간단한 방법부터 시작합니다.

1. 잠시 기다린 후 다시 시도

가장 간단한 해결 방법은 기다리는 것입니다. 429는 일시적인 오류로, 서버가 사용자를 차단한 것이 아니라 속도를 줄여 달라고 요청하는 것입니다.

얼마나 기다려야 하는지는 사이트의 한도에 따라 다릅니다. 1분 안에 풀리는 곳도 있고, 시간 단위나 하루 단위로 한도를 두는 곳도 있습니다. 페이지나 API가 Retry-After 헤더를 보낸다면 그 값이 정확한 대기 시간입니다. 기다린 뒤에는 페이지를 한 번만 불러오세요.

새로고침을 반복하지 마세요. 새로고침할 때마다 새 요청이 생기고, 그 요청도 같은 한도에 포함됩니다.

2. 해당 사이트의 쿠키만 삭제

효과가 있는 경우는 드물지만, 세션 쿠키 단위로 요청 수를 세는 사이트도 있습니다. 다른 사이트에서까지 로그아웃되지 않도록, 문제가 생긴 사이트의 쿠키만 지워 새 세션을 시작하세요:

• Chrome / Edge: chrome://settings/content/all(Edge는 edge://settings/content/all)을 열고 사이트를 검색한 뒤 해당 사이트의 데이터를 삭제합니다
• Firefox: 주소 표시줄의 자물쇠 아이콘 클릭 → 쿠키 및 사이트 데이터 지우기…
• Safari: Safari → 설정 → 개인정보 보호 → 웹사이트 데이터 관리 → 해당 사이트 선택 → 제거

삭제한 뒤에는 브라우저를 닫았다가 다시 열고 사이트에 접속하세요.

3. VPN 또는 프록시 연결 해제

VPN이나 프록시를 사용 중이라면, 수백 명의 다른 사용자와 같은 IP 주소를 공유하고 있을 수 있습니다. 이들의 요청이 합산되어 서버의 한도를 초과하면, 해당 IP의 모든 사용자가 레이트 리미팅에 걸립니다.

VPN 연결을 해제하고 일반 인터넷 연결로 사이트에 접속해 보세요. 429 오류가 사라지면 VPN IP가 원인이었던 것입니다.

VPN을 꼭 써야 한다면 다른 서버 위치로 바꿔 보세요. 그 서버의 IP는 함께 쓰는 사람이 더 적을 수 있습니다.

4. 브라우저 확장 프로그램 비활성화

일부 확장 프로그램은 방문하는 사이트에 백그라운드로 요청을 보냅니다. 가격 추적기, SEO 도구, 자동 새로고침 확장 프로그램의 요청이 쌓이면 한도에 걸릴 수 있습니다. (광고 차단기는 보통 반대로 요청 수를 줄입니다.)

확인하려면 대부분의 확장 프로그램이 꺼지는 시크릿 창(Firefox는 사생활 보호 창)에서 사이트를 열어 보세요. 시크릿 창은 쿠키 없이 시작하므로, 여기서 429가 사라진다면 확장 프로그램이나 세션 단위의 한도가 관련된 것입니다.

확장 프로그램을 하나씩 비활성화하여 문제가 되는 것을 찾으세요. Chrome에서는 chrome://extensions/에서 개별적으로 끄고 켤 수 있습니다.

5. IP 주소를 다른 사람과 함께 쓰는지 확인

공인 IP 주소 하나를 여러 사람이 함께 쓰는 경우가 많습니다. 회사나 학교 네트워크, 통신사 모바일 네트워크(CGNAT), VPN 서버가 그렇습니다. 이 사람들의 요청도 내 요청과 같은 한도에 합산됩니다.

이런 네트워크를 쓰고 있다면 집 인터넷이나 모바일 데이터로 사이트를 열어 보면 공유 주소가 원인인지 알 수 있습니다. 한도가 내 주소에 걸린 것이라면 네트워크를 바꿔 피하려 하지 말고 한도가 풀릴 때까지 기다리세요. 현재 공인 IP는 내 아이피 주소 확인에서 볼 수 있습니다.

트위터(X)·디시·구글에서 429가 뜰 때

429는 어느 사이트에서 뜨든 뜻이 같습니다. '짧은 시간에 요청이 너무 많으니 잠시 기다리라'는 신호입니다. 다만 사이트마다 한도를 세는 방식과 풀리는 시간이 달라서, 한국에서 많이 검색되는 세 곳을 따로 정리했습니다.

트위터(X) 429 오류: 얼마나 기다려야 하나요?

트위터(X)에서 '429' 오류나 요청 한도를 넘었다는 메시지가 보이면, 짧은 시간에 타임라인 새로고침, 검색, 팔로우 같은 동작을 너무 많이 해서 X가 요청을 잠시 제한한 것입니다. X 고객센터의 X 이용 한도 안내에 따르면 한도에 걸리면 어떤 한도인지 오류 메시지로 알려 주고, 시간 기준 한도는 그 시간이 지나면 다시 이용할 수 있으며, 사이트 사용량이 많을 때는 한도가 일시적으로 낮아질 수 있습니다. X가 공개한 한도는 게시물 하루 2,400개(인증되지 않은 계정은 원글 50개·답글 200개, 다시 30분 단위로 나뉨), DM 하루 500개, 팔로우 하루 400개 등이며, 게시물 한도에 걸리면 한도 시간이 지난 뒤 몇 시간 후에 다시 시도하라고 안내합니다. 타임라인 열람 같은 읽기 한도는 숫자도, 풀리는 시간도 공개하지 않습니다.

X API를 쓰는 개발자라면 기준이 명확합니다. X 개발자 문서(영문)에 따르면 한도는 엔드포인트마다 다르고 보통 15분 또는 24시간 단위로 계산하며, 한도를 넘으면 429와 함께 오류 코드 88(Rate limit exceeded)을 돌려줍니다. 응답 헤더 x-rate-limit-reset에 한도가 풀리는 시각이 Unix 타임스탬프로 들어 있으므로, 그 시각까지 기다렸다가 다시 요청하세요.

• 새로고침 멈추기: 새로고침할 때마다 새 요청으로 계산됩니다. 앱과 브라우저를 닫고 시간을 두었다가 다시 여세요.
• 자동화와 연동 앱 줄이기: 자동 새로고침·자동 스크롤 확장 프로그램과 비공식 클라이언트를 끄세요. X 고객센터에 따르면 서드파티 앱의 API 요청도 시간당 한도에 합산되므로, 연동 앱을 여러 개 쓰면 한도에 더 빨리 걸립니다.
• 공유 IP라면: 회사·학교 Wi-Fi나 VPN에서만 429가 뜬다면 같은 IP를 쓰는 다른 사람의 요청 때문일 수 있습니다(위 5번 참고).
• 전체 장애 확인: 모든 사람이 같은 오류를 본다면 X 쪽 장애일 수 있습니다. 사이트 다운 확인으로 x.com이 응답하는지 확인하세요.

디시인사이드 등 커뮤니티에서 Too Many Requests가 뜰 때

디시인사이드 같은 커뮤니티 사이트에서도 짧은 시간에 새로고침, 글 목록 넘기기, 글쓰기·댓글을 반복하면 요청이 너무 많다고 판단되어 429 Too Many Requests 페이지가 뜰 수 있습니다. 차단은 보통 일시적이므로 새로고침을 멈추고 기다리는 것이 가장 빠른 해결책입니다. 기다리는 동안 계속 새로고침하면 그 요청도 한도에 계산되어 차단이 더 오래갑니다.

자동 새로고침 확장 프로그램이나 매크로를 쓰고 있다면 끄세요. 회사·학교 Wi-Fi나 VPN에서만 이 페이지가 뜬다면 같은 IP를 쓰는 다른 사람의 요청 때문일 수 있습니다(위 5번 참고).

구글 검색에서 429(비정상적인 트래픽)가 뜰 때

구글 검색 중 'Google의 시스템이 컴퓨터 네트워크에서 비정상적인 트래픽을 감지했습니다'라는 화면이 나오면, 구글이 검색 요청을 429로 막고 reCAPTCHA를 보여 준 것입니다. 구글 검색 고객센터에 따르면 로봇, 프로그램, 검색 스크래퍼처럼 자동화된 검색이 내 네트워크에서 감지될 때 나타나며, reCAPTCHA를 풀면 다시 검색할 수 있습니다.

메시지가 계속 나온다면 구글이 안내하는 원인을 하나씩 확인하세요.

• 악성 소프트웨어: 내 PC나 같은 네트워크의 다른 기기에 설치된 악성 프로그램이 몰래 검색을 보낼 수 있습니다. 백신으로 검사하세요.
• 공유 네트워크: 학교·회사처럼 같은 네트워크를 쓰는 다른 사람이 자동 검색을 보내면 모두가 함께 막힙니다.
• VPN·IPv6 터널: 같은 VPN이나 IPv6 터널 서비스를 쓰는 다른 사용자 때문일 수 있습니다. VPN을 끄고 확인하세요.
• 순위 확인 프로그램: 검색 순위를 자동으로 조회하는 프로그램도 자동화된 트래픽으로 간주됩니다.

팁: 내 아이피 주소 확인으로 지금 쓰는 공인 IP를 확인하세요. 학교·회사 네트워크나 VPN처럼 여러 사람이 쓰는 주소라면, 구글 안내대로 네트워크 관리자나 VPN 업체, 인터넷 제공업체에 문의하는 것이 근본적인 해결책입니다.

개발자를 위한 429 오류 해결 방법

코드에서 429를 받는다면 API가 허용하는 것보다 빠르게 요청을 보내고 있다는 뜻입니다. Retry-After를 먼저 읽고, 지터를 더한 백오프로 기다린 다음, 보내는 요청 수 자체를 줄이는 순서로 처리하세요.

1. 지수 백오프 구현

지수 백오프(Exponential Backoff)는 표준 재시도 전략입니다. 429를 받은 즉시 재시도하지 말고 대기 시간을 매번 두 배로 늘리세요(1초, 2초, 4초, 8초…). 여기에 무작위 추가 지연인 지터(jitter)를 더하면 여러 클라이언트가 같은 순간에 한꺼번에 재시도하는 것을 막을 수 있습니다.

아래 코드는 서버가 유효한 Retry-After를 보내면 두 가지 형식 중 어느 쪽이든 해석해 그 값을 따르고, 그렇지 않으면 지터를 더한 백오프로 기다리며, 몇 번 시도한 뒤에는 포기합니다. (브라우저에서 다른 사이트의 API를 호출할 때는 그 API가 Access-Control-Expose-Headers로 Retry-After를 노출해야만 읽을 수 있습니다.)

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Retry-After 헤더 준수

서버가 429와 함께 Retry-After를 보내면 얼마나 기다려야 하는지 정확히 알려 주는 것입니다. RFC 9110은 초 단위 숫자와 HTTP 날짜, 두 가지 형식을 허용합니다.

Retry-After: 60은 60초 동안 기다리라는 뜻입니다. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT는 그 시각까지 기다리라는 뜻입니다. 자체 백오프 로직보다 이 헤더를 먼저 확인하세요. 대기 시간은 코드보다 서버가 더 잘 압니다.

Python에서는 두 형식을 모두 처리하고, 끝없이 재귀 호출하지 말고 몇 번 시도한 뒤 멈추세요:

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

3. API 응답 캐싱

애플리케이션이 동일한 API 호출을 여러 번 수행한다면, 매번 API를 호출하는 대신 응답을 캐싱하세요. 요청 수를 획기적으로 줄일 수 있습니다.

자주 접근하는 데이터에는 인메모리 캐시(Redis 또는 간단한 Map 등)를 사용하세요. 데이터의 변경 빈도에 따라 적절한 TTL(유효 기간)을 설정합니다.

예를 들어, 도메인의 DNS 조회를 조회하는 경우 5분 이내에 결과가 변경될 가능성은 거의 없으므로, 캐싱하는 것이 효율적입니다.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) return cached.data;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. 폴링 대신 웹훅 사용

변경 사항을 확인하기 위해 API를 반복적으로 호출하고 있다면(예: 10초마다 주문 상태 확인), 서비스가 지원하는 경우 웹훅으로 전환하세요.

웹훅을 사용하면 변경이 발생했을 때 서버가 애플리케이션에 업데이트를 직접 보내주므로, 지속적인 폴링이 필요 없습니다. 시간당 수천 건의 API 호출을 단 몇 건으로 줄일 수 있습니다.

대부분의 최신 API(Stripe, GitHub, Twilio, Shopify 등)가 웹훅을 지원합니다. API 문서에서 웹훅 설정 방법을 확인하세요.

5. 더 높은 레이트 리미트 요청

정당하게 더 많은 API 호출이 필요하다면, 서비스 제공업체에 문의하세요. 많은 API가 유료 플랜이나 인증된 애플리케이션에 대해 더 높은 레이트 리미트를 제공합니다.

더 높은 한도를 요청할 때는 사용 사례를 설명하고 예상 요청량을 제시하세요. Google을 비롯한 많은 API가 한도 상향 신청 양식이나 유료 등급을 제공합니다.

일부 API는 단일 요청으로 여러 리소스를 가져올 수 있는 벌크 엔드포인트를 제공하여 전체 호출 수를 줄일 수 있게 해줍니다.

웹사이트 관리자를 위한 429 오류 해결 방법

방문자나 API 사용자가 429 오류를 겪고 있다면, 서버 설정에 문제가 있는 것입니다. 진단 및 해결 방법을 알아보겠습니다.

1. 레이트 리미팅 규칙 조정

실제 사용자가 429를 겪고 있다면 어느 계층이 먼저 응답하는지 찾으세요. CDN이나 WAF, 웹 서버, 애플리케이션 중 하나입니다. 그런 다음 그 계층의 한도를 조정하세요.

nginx에서는 limit_req가 이 일을 합니다. 기본적으로 503으로 응답한다는 점에 주의하세요. limit_req_status 429;를 추가해야 클라이언트가 서버 다운으로 오해하지 않고 속도를 줄여야 한다는 것을 알 수 있습니다:

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

burst 매개변수는 짧은 급증을 429 없이 통과시킵니다. 이 설정이 없으면 요청이 많은 평범한 페이지 로드 한 번으로도 한도에 걸릴 수 있습니다.

Apache에는 요청 속도를 제한하는 기본 기능이 없습니다. mod_ratelimit은 요청 수가 아니라 대역폭을 제한하고, 서드파티 모듈인 mod_evasive는 403으로 응답합니다. 429를 보내려면 리버스 프록시, WAF 또는 애플리케이션에서 제한하세요. Node.js의 express-rate-limit은 기본적으로 429로 응답합니다.

2. 신뢰할 수 있는 IP 화이트리스트 등록

특정 클라이언트(모니터링 서비스, 결제 처리 업체, 자체 마이크로서비스)가 레이트 리미팅에 걸린다면, 해당 IP 주소를 화이트리스트에 추가하세요.

nginx에서는 geo와 map으로 신뢰할 수 있는 주소에 빈 키를 부여하는데, nginx는 키가 비어 있는 요청을 세지 않습니다. 아래 설정은 앞 예시의 limit_req_zone 줄을 대체합니다:

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

검색 엔진 크롤러를 실수로 제한하지 마세요. Google은 429를 서버 오류로 취급하고 크롤링 속도를 늦춥니다(Google 검색 센터). 진짜 Googlebot과 Bingbot의 요청인지는 PTR 레코드 조회 조회로 얻은 이름을 다시 정방향 조회해 확인하거나, 크롤러가 공개한 IP 대역을 예외로 두세요.

3. WAF 및 CDN 설정 확인

Cloudflare, AWS WAF, Sucuri 같은 보안 서비스를 쓴다면 요청이 서버에 닿기도 전에 그 서비스의 속도 제한 규칙이 응답할 수 있습니다.

Cloudflare는 속도 제한 규칙이 작동하면 방문자에게 "Error 1015: You are being rate limited"를 보여 줍니다. 대시보드의 보안 규칙에서 해당 규칙을 찾아 이벤트를 확인한 뒤, 임계값을 높이거나 적용 범위를 좁히세요.

AWS WAF의 속도 기반 규칙(rate-based rule)은 IP(또는 다른 키)별 요청 수를 1분, 2분, 5분, 10분 중 하나의 윈도우로 세며, 한도는 최소 10입니다. 차단된 요청은 기본적으로 403을 받으므로, 클라이언트가 속도를 줄일 수 있도록 사용자 지정 응답을 429로 설정하세요.

무엇이든 바꾸기 전에 CDN 분석 데이터로 실제 방문자와 봇을 구분하세요.

4. 서버 성능 최적화

일부 서비스는 부하가 걸리면 안전장치로 속도 제한을 더 엄격하게 적용합니다. 서버 성능을 개선하면 한도를 안전하게 높일 수 있습니다.

주요 최적화 방법으로는 응답 캐싱을 활성화하여 백엔드 부하를 줄이고, 정적 자산에 CDN을 사용하고, Redis나 Memcached로 데이터베이스 쿼리 캐싱을 추가하고, 데이터베이스 연결에 커넥션 풀링을 구현하며, 트래픽이 충분한 경우 로드 밸런싱으로 수평 확장하는 것이 있습니다.

HTTP 헤더 검사를 사용하면 캐싱 헤더가 올바르게 설정되어 있는지 확인할 수 있습니다.

429 오류와 다른 HTTP 오류 비교

429 오류는 다른 HTTP 상태 코드와 혼동하기 쉽습니다. 각각의 차이점을 정리하면 다음과 같습니다:

핵심 차이는 429가 의도적이고 일시적이라는 점입니다. 서버가 지금은 요청을 받지 않기로 선택한 것입니다. 대부분의 5xx 코드는 서버에서 무언가 실패했다는 뜻이지만, 503은 계획된 점검일 수도 있고 nginx에서는 속도 제한일 수도 있습니다.

429 오류를 예방하는 방법

예방이 치료보다 낫습니다. 429 오류를 사전에 방지하기 위한 모범 사례를 소개합니다:

• API 문서 숙지 — 코드를 작성하기 전에 레이트 리미팅 한도를 확인하세요. 대부분의 서비스가 한도를 명확하게 공개합니다.
• 사용량 모니터링 — X-RateLimit-Remaining 헤더를 추적하여 한도에 얼마나 가까운지 파악하세요.
• 요청 일괄 처리 — 개별 호출 대신 벌크 엔드포인트를 사용하세요.
• 요청 분산 — 한꺼번에 보내지 말고 API 호출을 시간에 걸쳐 균등하게 분배하세요.
• API 키 사용 — 인증된 요청은 보통 익명 요청보다 더 높은 레이트 리미트를 받습니다.
• 서킷 브레이커 구현 — 반복적으로 429를 받으면, 냉각 기간 동안 요청 전송을 완전히 중단하세요.
• 레이트 리미트 시뮬레이터로 테스트 — 개발 환경에서 429 응답을 시뮬레이션하여 오류 처리가 제대로 작동하는지 확인하세요.
• 429 응답 로깅 — 레이트 리미팅이 언제, 어디서 발생하는지 기록하여 요청 패턴을 최적화하세요.