Rate Limiting 정리

핵심 요약

• Rate Limiting은 일정 시간 동안 허용할 요청 수를 제한하는 방식이다.
• 면접에서는 "왜 필요한가", "어떤 알고리즘이 있나", "분산 환경에서 어떻게 적용하나" 정도를 설명하면 좋다.
• 목적은 단순 트래픽 절감이 아니라, 과도한 호출로부터 시스템을 보호하고 공정한 사용량을 보장하는 데 있다.
• 정책만 세우고 사용자 경험을 고려하지 않으면 정상 사용자도 쉽게 막을 수 있어서 응답 방식과 예외 규칙까지 같이 설계해야 한다.

왜 Rate Limiting이 필요하냐

백엔드 서비스는 항상 악의적 공격만 막는 게 목적은 아니다.
정상 사용자라도 짧은 시간에 너무 많은 요청을 보내면 특정 API나 데이터베이스가 병목이 될 수 있다.

그래서 Rate Limiting은 보안과 안정성, 공정성 세 가지를 같이 본다.

• 봇이나 남용 요청 완화
• 특정 사용자의 과도한 사용으로 전체 서비스가 느려지는 상황 방지
• 유료 플랜, 파트너 API 같은 사용량 정책 반영

어디 기준으로 제한하냐

상황에 따라 기준이 달라진다.

• IP 기준
• 사용자 계정 기준
• API 키 기준
• 엔드포인트 기준
• 테넌트 기준

면접에서는 "무조건 IP 기준"처럼 말하기보다, 로그인 서비스면 사용자나 API 키 기준이 더 적절할 수 있다고 덧붙이면 좋다.

대표 알고리즘

1. Fixed Window Counter

1분에 100건처럼 고정된 시간 구간마다 카운트를 세는 방식이다.
구현은 쉽지만 경계 시점에 트래픽이 몰리면 실제로는 짧은 순간에 두 배 가까운 요청이 통과할 수 있다.

2. Sliding Window

고정 창의 경계 문제를 줄이기 위해 최근 N초 기준으로 더 부드럽게 계산하는 방식이다.
조금 더 정확하지만 구현과 저장 비용이 늘 수 있다.

3. Token Bucket

버킷에 토큰이 일정 속도로 채워지고, 요청이 들어올 때 토큰을 하나씩 소비한다고 보면 된다.
평균 요청률은 제한하면서도 짧은 순간의 버스트 트래픽은 일부 허용하기 좋아 실무에서 자주 언급된다.

4. Leaky Bucket

들어오는 요청을 일정 속도로 흘려보내는 개념이다.
출력 속도를 평탄하게 만들고 싶을 때 설명하기 좋다.

분산 환경에서는 뭐가 어려우냐

서버가 여러 대면 각 서버 메모리에 카운터를 두는 방식은 정확도가 떨어진다.
그래서 Redis 같은 외부 저장소를 써서 카운터를 공유하는 방식이 흔하다.

이때 중요한 포인트는 원자성이다.
동시에 여러 서버가 같은 키를 올릴 수 있으니 INCR, 만료 시간 설정, Lua 스크립트 같은 원자적 처리 전략이 같이 나온다.

제한에 걸리면 어떻게 응답하냐

보통 429 Too Many Requests를 사용한다.
가능하면 언제 다시 시도하면 되는지 알려 주는 정보도 함께 주는 편이 좋다.

예를 들어 Retry-After 헤더를 줄 수 있고, 클라이언트에게는 "잠시 후 다시 시도해 달라"는 의미가 된다.

너무 빡빡하게 걸면 생기는 문제

로그인, 검색, 자동 저장처럼 사용자 행동이 몰리는 API는 정상 사용도 쉽게 제한에 걸릴 수 있다.
그래서 엔드포인트 특성별로 정책을 다르게 두는 경우가 많다.

또 내부 관리자, 신뢰된 파트너, 헬스체크 트래픽처럼 예외 처리해야 하는 요청도 있다.

면접 답변 예시

Rate Limiting은 일정 시간 동안 허용할 요청 수를 제한해서 시스템을 보호하는 방식입니다. 목적은 단순히 트래픽을 줄이는 게 아니라 남용 방지, 공정한 자원 사용, 장애 전파 방지에 있습니다. 구현 방식으로는 Fixed Window, Sliding Window, Token Bucket 같은 알고리즘이 자주 나오고, 분산 환경에서는 Redis 같은 공용 저장소로 카운터를 관리해야 정확도를 높일 수 있습니다. 제한에 걸린 경우에는 보통 429 상태 코드와 재시도 정보를 함께 주는 식으로 설계합니다.

장점

• 과도한 요청으로부터 시스템을 보호할 수 있다.
• 사용자나 고객사별 사용량 정책을 반영하기 좋다.
• 장애가 전체로 번지는 것을 줄이는 안전장치가 된다.

단점

• 정책이 거칠면 정상 사용자 경험을 해칠 수 있다.
• 분산 환경에서는 구현 복잡도가 올라간다.
• 트래픽 패턴에 맞지 않는 알고리즘을 고르면 효과가 떨어진다.

주의사항 / 실무 팁

• 어떤 기준(IP, 사용자, API 키)으로 제한할지 먼저 정해야 정책이 덜 흔들린다.
• 429만 던지는 것보다 재시도 가능 시점이나 남은 quota 정보를 주면 클라이언트 구현이 쉬워진다.
• 로그인, 결제, 공개 API는 트래픽 성격이 달라서 같은 정책으로 묶지 않는 편이 안전하다.
• 면접에서는 알고리즘 이름만 나열하지 말고 "왜 Token Bucket을 쓰면 버스트 허용에 유리한가" 정도까지 말하면 좋다.