레이트 리미팅(Rate Limiting)

레이트 리미팅(rate limiting)은 클라이언트가 API를 호출할 수 있는 빈도를 제한하는 것입니다. 예를 들어 API 키당 분당 100건처럼 제한을 두며, 한도를 넘은 요청은 시간 창(window)이 초기화될 때까지 거부됩니다. 서비스를 과부하와 남용으로부터 보호하고, 요청이 많은 한 클라이언트가 다른 클라이언트의 자원을 고갈시키지 못하게 하며, 비밀번호 대입 같은 공격의 속도를 늦춥니다. 한도는 보통 API 키, 사용자, 토큰 또는 IP 주소 단위로 집계합니다.

예시

HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30

{"error": "rate_limited", "message": "Try again in 30 seconds"}

429 Too Many Requests와 Retry-After는 HTTP 표준입니다. 남은 할당량을 알려 주는 X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset 같은 헤더는 널리 쓰이는 관례일 뿐 단일 표준이 아니므로, 테스트 대상 API의 문서에서 무엇을 쓰는지 확인해야 합니다.

대표적인 알고리즘

• 고정 윈도(Fixed window): 달력 기준 1분 단위로 요청 수를 셉니다. 단순하지만 윈도 경계를 사이에 두고 클라이언트가 두 배의 요청을 한꺼번에 보낼 수 있습니다.
• 슬라이딩 윈도(Sliding window): 최근 N초 동안의 요청 수를 세므로 경계 효과가 완화됩니다.
• 토큰 버킷(Token bucket): 토큰이 일정한 속도로 채워지고 요청마다 토큰을 하나씩 소비합니다. 평균 속도는 지키면서 버킷 크기만큼의 짧은 폭주(burst)는 허용합니다.

무엇을 테스트해야 하는가

• 한도 자체: 한도 + 1건의 요청을 보내 정확히 초과된 한 건만 429를 받는지 확인합니다.
• 복구: Retry-After 시간이나 초기화 시각이 지나면 요청이 다시 성공하는지 확인합니다.
• 적용 범위: 한 사용자나 키의 트래픽이 다른 사용자의 할당량을 소진해서는 안 됩니다. 한도가 키, 사용자, IP 중 어느 단위로 적용되는지, 그리고 값싼 무언가를 바꿔 가며 한도를 우회할 수 있는지 확인합니다.
• 민감한 엔드포인트: 로그인, 비밀번호 재설정, OTP 인증은 일반 조회보다 더 엄격한 한도를 가져야 합니다.
• 응답 형식: 거부된 요청은 500이나 멈춘 연결이 아니라, 이해하기 쉬운 본문과 함께 429를 반환해야 합니다.
• 클라이언트 동작: 자사 클라이언트가 짧은 루프로 재시도하지 않고 백오프(back off)하며 Retry-After를 존중하는지 확인합니다.

레이트 리미팅과 테스트 스위트

병렬로 실행되는 API 테스트와 부하 테스트는 운영 환경과 비슷한 한도에 걸려, 테스트 대상 변경과 무관한 이유로 실패할 수 있습니다. 테스트 환경에서는 전용 키를 쓰거나 한도를 높여 두고, 용량을 측정하려는 부하 테스트라면 레이트 리미터가 아니라 서비스 자체를 측정하고 있는지 확인해야 합니다.