API 레이트 리밋은 트래픽 제한이 아니라 남용 방어 장치다

핵심 요약

API 레이트 리밋은 서버 과부하만 막는 장치가 아니다. 로그인 추측, 계정 열거, 데이터 수집, 쿠폰·재고 선점, 결제·메시지 비용 유발처럼 정상 형식의 자동화 남용을 줄이는 정책이다. IP 하나가 아니라 계정·토큰·기기·테넌트·엔드포인트·대상 객체·비용을 조합하고, 초과 응답·재시도·예외·탐지 로그까지 제품 흐름으로 설계해야 한다.

API 요청이 문법적으로 정상이고 인증까지 통과했다고 해서 정당한 사용은 아니다. 공격자는 여러 IP와 계정을 나눠 쓰고, 정상 SDK의 헤더와 속도를 흉내 내며, 값비싼 검색·문자 발송·결제 확인 API를 조금씩 반복한다. 초당 요청 수 하나만 제한하면 정상 공유망 고객을 막거나 분산 남용을 놓치기 쉽다.

레이트 리밋의 목표는 “트래픽을 줄이는 것”이 아니라 보호할 자원과 업무 규칙에 맞춰 공격 비용을 높이고 피해가 누적되기 전에 추가 인증·지연·보류·차단으로 전환하는 것이다.

먼저 보호 단위를 정한다

보호 단위	남용 예시	적합한 제한 키
인증 계정	비밀번호 추측, 세션 재생	계정, 세션, 기기, 네트워크
익명 식별자	계정 존재 여부 확인	입력 식별자의 해시, IP 대역, 기기
API 소비자	키 유출, 과도한 호출	API 키, 클라이언트 ID, 테넌트
업무 객체	쿠폰·좌석·수취인 반복 시도	객체 ID, 계정, 대상 조합
비용 자원	SMS·이메일·LLM·검색 비용 유발	비용 단위, 고객 예산, 엔드포인트
데이터 범위	페이지 순회, 대량 수집	계정, 쿼리 패턴, 결과 건수
공급자 용량	하위 서비스 과부하	백엔드·지역·작업 큐별 한도

하나의 요청에는 여러 제한을 동시에 적용할 수 있다. 예를 들어 로그인은 IP 분당 한도, 계정별 실패 한도, 기기별 계정 전환 수, 전체 서비스의 비상 한도를 함께 본다. 하나를 초과했다고 무조건 영구 차단하기보다 위험도에 따라 지연, CAPTCHA, 추가 인증, 비밀번호 재설정 안내, 임시 잠금으로 나눈다.

알고리즘보다 정책이 먼저다

토큰 버킷, 누수 버킷, 고정·슬라이딩 윈도는 구현 방식이다. 선택 전에 다음 정책을 정한다.

지속 허용량: 정상 사용자가 장시간 사용할 수 있는 속도
순간 버스트: 페이지 로드·배치 작업처럼 짧게 허용할 양
누적 예산: 시간·일·월 단위 비용 또는 데이터 양
위험 가중치: 성공·실패, 읽기·쓰기, 저비용·고비용 요청의 서로 다른 비용
복구 속도: 제한 후 언제 얼마나 회복되는가
초과 행동: 429, 지연, 큐잉, 추가 인증, 비동기 전환, 차단
예외 범위: 내부 작업·파트너·고객 등 예외의 소유자와 만료

모든 요청을 1회로 계산하면 비용이 큰 작업을 놓친다. 검색 결과 1천 건, LLM 긴 문맥, SMS 100건, 대용량 내보내기는 서로 다른 가중치를 가져야 한다.

업무별 설계 예시

로그인과 계정 복구

계정 존재 여부가 외부 응답 시간·문구로 드러나지 않게 한다.
계정, IP, 기기, 입력 식별자 해시를 조합한다.
실패 횟수뿐 아니라 여러 계정을 순회하는 패턴을 본다.
정상 사용자의 공유망을 고려해 IP만으로 계정을 잠그지 않는다.
성공 직후에도 이전 실패, 새 기기, 비밀번호 변경을 위험 신호로 유지한다.
제한 상태와 추가 인증 결과를 감사 로그에 남긴다.

검색과 데이터 조회

요청 수 외에 결과 건수, 페이지 깊이, 고유 객체 수를 센다.
순차 ID, 유사 쿼리 반복, 낮은 클릭·활용률을 탐지한다.
테넌트별 계약 할당량과 전체 서비스 보호 한도를 분리한다.
대량 작업은 비동기 내보내기와 별도 승인 흐름으로 보낸다.

결제·쿠폰·재고

계정과 결제수단·수취인·쿠폰·상품 조합을 제한한다.
실패 후 금액·카드·쿠폰을 조금씩 바꾸는 패턴을 본다.
멱등성 키를 검증하고 같은 작업의 재시도가 중복 처리되지 않게 한다.
제한 때문에 결제 상태가 불명확해지지 않도록 조회·확정 API를 분리한다.
위험 거래 정책은 핀테크 거래 위험 모니터링과 연결한다.

429 응답과 재시도를 제품 계약으로 만든다

제한을 초과했을 때는 일반적으로 HTTP 429를 사용하고, 가능한 경우 안전한 재시도 시점을 전달한다. 다만 다음 원칙이 필요하다.

공격자가 내부 임계값을 정밀 추정할 정도로 과도한 정보를 주지 않는다.
클라이언트는 지수 백오프와 무작위 지연을 사용한다.
여러 인스턴스가 동시에 재시도하는 폭주를 막는다.
쓰기 요청은 멱등성을 보장하거나 상태 확인 방법을 제공한다.
제한 응답도 캐시·프록시에서 잘못 공유되지 않게 한다.
사용자 화면에는 원인과 다음 행동을 이해할 수 있게 안내한다.

SDK가 즉시 재시도를 무한 반복하면 레이트 리밋이 오히려 부하 증폭기가 된다. 공식 SDK와 문서에 기본 백오프를 넣고, 서버는 클라이언트가 지키지 않아도 보호되도록 해야 한다.

분산 남용을 찾는 보조 신호

하나의 계정에 여러 네트워크·기기가 짧은 시간에 연결
하나의 기기가 여러 계정·테넌트를 순회
여러 API 키가 같은 대상 객체·수취인·결제수단에 집중
성공률은 낮지만 전체 시도량이 여러 원본에 분산
User-Agent는 같지만 TLS·헤더 순서·행동 간격이 비정상적으로 동일
정상 사용 흐름 없이 특정 고비용 엔드포인트만 반복
제한 직후 키·계정·IP가 교체되며 동일 작업이 계속됨

이 신호는 단독 식별자로 확정하지 말고 위험 점수와 추가 검증에 사용한다. 공유 기기, NAT, 기업 프록시, 접근성 도구처럼 정상 원인을 고려해야 한다.

실패 모드와 탐지 신호

실패 모드	보이는 증상	확인할 항목
IP 단일 제한	기업·모바일망 정상 고객이 함께 차단	계정·기기·대상 단위 보완 키가 있는가
인스턴스별 카운터	수평 확장할수록 실제 한도가 커짐	일관된 공유 상태 또는 분할 전략이 있는가
실패 요청만 계산	공격자가 성공 요청으로 비용·데이터를 소진	업무 비용과 결과량을 계산하는가
예외 키 영구화	파트너 키에서 대량 호출·사고 집중	예외 소유자·범위·만료·경보가 있는가
429 무한 재시도	제한 중 요청량과 지연이 더 증가	SDK 백오프와 재시도 상한이 있는가
제한 서비스 장애 시 허용	카운터 저장소 장애와 함께 남용 급증	엔드포인트별 fail-open·fail-closed 기준이 있는가
전체 한도만 존재	한 고객이 용량을 독점	고객·엔드포인트·전체 한도를 계층화했는가

fail-open과 fail-closed를 미리 정한다

레이트 리밋 저장소나 정책 서비스가 장애를 일으킬 수 있다. 모든 API를 동일하게 처리하면 안 된다.

공개 콘텐츠 조회는 제한적으로 허용하되 전체 용량 보호 한도를 둔다.
로그인·OTP·결제·대량 내보내기 같은 고위험 작업은 보수적으로 제한하거나 안전한 대체 흐름으로 전환한다.
기존 세션의 저위험 읽기와 신규 자격 증명 발급을 구분한다.
장애 모드 전환과 복귀를 감사하고, 긴급 임계값 변경은 자동 만료한다.
카운터 손실 후 갑자기 모든 사용자가 새 버스트를 받지 않도록 복구 정책을 둔다.

도입과 튜닝 순서

보호할 엔드포인트와 업무 비용을 분류한다.
현재 트래픽을 계정·키·대상·결과별로 관찰한다.
정상 상위 백분위와 배치·피크 사용을 분리한다.
차단 없이 초과 예상 이벤트를 기록한다.
고객군·SDK 버전별 오탐을 검토한다.
저위험 경고·지연부터 단계적으로 적용한다.
고위험 작업에 추가 인증·보류·차단을 연결한다.
예외와 임계값을 정기적으로 만료·재검토한다.

경계 계층과 업무 계층의 책임을 나누는 방법은 WAF와 API 게이트웨이는 같은 방어선이 아니다에서 자세히 다룬다.

운영 대시보드

엔드포인트·고객·키·결과별 요청률과 상위 사용량
제한 초과율, 429 비율, 재시도 후 성공률
제한된 정상 고객의 문의·이탈·작업 실패율
대상 객체·결제수단·수취인별 분산 남용 신호
고비용 작업의 요청당 비용과 일별 예산 소진
예외 키 사용량, 마지막 사용, 만료 초과
정책 저장소 지연·오류, fail-open·fail-closed 전환
제한 정책 버전별 공격 손실과 정상 성공률

배포 전 체크리스트

제한 키가 프록시 헤더 조작에 영향을 받지 않는가.
수평 확장·리전 분산 환경에서 실제 한도가 유지되는가.
공식 SDK가 429와 재시도를 안전하게 처리하는가.
쓰기 요청의 멱등성과 상태 조회가 준비돼 있는가.
제한 저장소 장애 시 엔드포인트별 행동이 정의됐는가.
고객·파트너 예외에 범위·소유자·만료가 있는가.
관찰 모드 결과로 정상 피크와 자동화를 구분했는가.
정책 변경과 롤백을 즉시 감사할 수 있는가.

참고 기준

최종 판단

API 레이트 리밋은 숫자 하나를 게이트웨이에 넣는 작업이 아니다. 보호할 계정·객체·비용을 정의하고, 여러 식별자를 조합하며, 초과 후 사용자 경험과 재시도, 장애 모드, 탐지 로그까지 설계하는 남용 방어 체계다. 가장 먼저 할 일은 호출량이 많거나 비용·데이터 영향이 큰 API 세 개를 골라 요청 수가 아닌 실제 피해 단위를 적는 것이다.