API Rate Limit 대응 패턴: 429를 장애로 키우지 않는 백엔드 설계법
💡 Key Takeaways
- 429 대응은 재시도 코드 한 줄이 아니라 트래픽 예산을 제어하는 아키텍처 문제입니다.
- 동기 재시도만으로는 장애를 증폭할 수 있으므로 큐 기반 완충 계층이 필요합니다.
- 사용자 등급별 토큰 버킷 정책을 분리하면 핵심 트래픽을 보호할 수 있습니다.
- 백오프 실패율, 대기열 지연, 드롭률을 함께 추적해야 실제 안정성이 보입니다.
API Rate Limit 대응 패턴
외부 API 의존도가 높은 서비스에서 가장 흔한 장애 신호는 타임아웃이 아니라 429 Too Many Requests입니다. 문제는 429가 발생했을 때 대부분의 시스템이 과도한 재시도로 반응한다는 점입니다. 결과적으로 API 공급자 쪽 한도는 더 빨리 소진되고, 우리 시스템은 스레드와 커넥션을 소비하면서 연쇄 지연을 일으킵니다. 즉, 429는 단일 에러가 아니라 장애 전파의 시작점이 될 수 있습니다.
처음부터 완벽한 고가용성 구조를 만들 필요는 없습니다. 다만 "요청이 몰렸을 때 무엇을 우선 보호할지"에 대한 원칙은 반드시 있어야 합니다. 예를 들어 결제 검증, 로그인, 핵심 조회 같은 경로는 지켜야 하고, 비핵심 분석 호출은 지연되거나 생략될 수 있어야 합니다. 이 우선순위가 코드와 인프라에 반영되지 않으면, 트래픽 급증 시 가장 중요한 기능부터 같이 무너집니다.
1. 동기 재시도에만 의존하지 않기
대부분의 SDK가 자동 재시도를 제공하지만, 운영에서 이것만 믿으면 위험합니다. 동기 요청 경로에서 3회 재시도를 기본으로 두면, 원래 1회 요청이 최대 4회로 늘어나고 피크 구간에서는 부하를 급격히 증폭시킵니다. 특히 사용자 요청 스레드 안에서 재시도하면 응답 지연이 누적되어 타임아웃 비율도 함께 올라갑니다.
실무에서는 "즉시 응답이 필요한 경로"와 "지연 허용 경로"를 분리해야 합니다. 즉시 경로는 재시도 횟수를 최소화하고, 지연 허용 경로는 큐로 넘겨 백그라운드 작업으로 처리하는 편이 안전합니다. 이 한 단계 분리만 적용해도 피크 구간의 응답 안정성이 크게 개선됩니다.
2. 토큰 버킷으로 트래픽 예산 통제하기
Rate limit 대응의 핵심은 에러 처리보다 사전 제어입니다. 토큰 버킷이나 리키 버킷을 사용해 초당 허용량을 강제하면, 외부 API 한도를 넘기기 전에 내부에서 자연스럽게 완충할 수 있습니다. 여기서 중요한 포인트는 전체 글로벌 제한 하나만 두지 말고, 사용자 등급·기능 타입·엔드포인트별로 버킷을 나누는 것입니다.
예를 들어 무료 사용자는 보수적으로 제한하고, 유료 사용자는 우선순위 버킷을 제공할 수 있습니다. 또 대시보드 통계 조회와 주문 처리 API를 같은 버킷에 넣으면 안 됩니다. 핵심 기능이 비핵심 트래픽에 밀리지 않도록 예산을 분리해야 실제 서비스 품질을 지킬 수 있습니다.
3. 큐 기반 완충 계층으로 피크 흡수
순간 트래픽이 몰리는 이벤트(오픈, 마감, 프로모션)가 있는 서비스라면 큐 기반 완충이 거의 필수입니다. 요청을 직접 외부 API로 보내지 않고 내부 큐에 넣으면, 소비자 워커가 제한된 동시성으로 안정적으로 처리할 수 있습니다. 이 구조는 외부 API 불안정 구간에서 시스템 전체가 흔들리는 것을 막아줍니다.
다만 큐를 넣었다고 끝은 아닙니다. 대기열 길이가 임계치를 넘는 순간 어떤 작업을 지연할지, 어떤 작업은 드롭할지 정책이 있어야 합니다. 드롭 정책 없이 무한 적재하면 결국 지연이 사용자 불만으로 돌아옵니다. 실무에서는 중요도 낮은 작업부터 명시적으로 포기하는 전략이 오히려 시스템을 건강하게 만듭니다.
4. 백오프 정책은 수치로 관리하기
"지수 백오프를 쓰자"는 말은 흔하지만, 실제로는 수치가 중요합니다. 시작 지연, 최대 지연, 지터(jitter) 비율을 정하지 않으면 팀마다 다르게 구현되어 예측이 어려워집니다. 또한 백오프의 목표는 성공률 100%가 아니라, 공급자 한도를 존중하면서 서비스 품질을 유지하는 것입니다.
추천하는 운영 방식은 간단합니다. 백오프 성공률, 재시도 평균 횟수, 최종 실패율을 대시보드에 붙이고, 릴리스마다 추세를 비교합니다. 특히 재시도 성공률은 높은데 지연 시간이 급증한다면, 사용자 체감은 이미 나빠졌다는 의미입니다. 단순 성공 여부만 보는 모니터링은 운영 현실을 놓치기 쉽습니다.
5. 장애 대응 플랜을 문서화하기
Rate limit 이슈는 주로 야간 또는 이벤트 피크에 발생합니다. 이때 "누가 어떤 스위치를 내릴지"가 정해져 있지 않으면 대응 시간이 길어집니다. 저는 운영 문서에 최소 세 가지를 고정합니다. 비핵심 호출 비활성화 방법, 버킷 한도 임시 조정 절차, 공급자 상태 페이지 확인 루틴입니다.
마지막으로, 429는 공급자가 잘못해서 생기는 문제가 아니라 우리가 예상해야 하는 정상 상황이라는 인식이 필요합니다. 이 관점으로 시스템을 설계하면 429는 재앙이 아니라 제어 가능한 이벤트가 됩니다.