레이트 리미팅 · 요청 제한
Rate Limiting
레이트 리미팅이란?
- 시간당 요청 횟수 제한
- 과부하·남용·비용폭증 방지
- 429 오류로 차단
레이트 리미팅을 켜는 순간 서비스 운영의 전제가 바뀝니다. 그전까지는 들어온 요청을 일단 다 받아놓고 버티다가 서버가 쓰러지면 증설하거나 재기동했다면, 이제는 정해진 선을 넘은 요청을 의도적으로 거절하는 것이 정상 동작이 됩니다. 거절은 장애가 아니라 설계입니다. 트래픽이 몰려도 서버는 감당 가능한 만큼만 처리하고 나머지는 잠시 밀릴 뿐, 서비스 자체는 살아 있습니다. 소수의 폭주가 다수의 정상 사용자를 함께 끌고 내려가는 구조를 끊는 것이 핵심입니다.
방식은 크게 네 가지로 갈립니다. 고정 윈도우는 '매분 0초에 카운터 초기화'라 만들기 쉽지만 경계 구간에 두 배가 몰립니다. 슬라이딩 윈도우는 그 경계 문제를 없애고, 토큰 버킷은 평소 아낀 여유분으로 순간 폭주를 허용하며, 리키 버킷은 처리 속도를 일정하게 고릅니다. 무엇을 기준으로 셀지도 그만큼 중요합니다. IP, API 키, 사용자 ID, 조직 단위 중 어디에 거느냐에 따라 결과가 완전히 달라집니다. 분당 호출 수 제한과 월 쿼터, 동시 실행 수 제한은 서로 다른 장치입니다. 월 100만 건 쿼터가 80만 건 남아 있어도 초당 한도에 걸리면 429는 그대로 떨어집니다.
현장에서 가장 흔한 사고는 IP 기준으로 걸어둔 경우입니다. 고객사 임직원 200명이 사내 NAT를 거쳐 하나의 공인 IP로 나오면, 한도에 걸리는 순간 200명이 동시에 막힙니다. 두 번째는 재시도입니다. 429를 받자마자 0.1초 뒤 다시 호출하는 코드는 제한을 푸는 게 아니라 스스로 공격을 만듭니다. 지수 백오프에 무작위 지연을 섞고 Retry-After 헤더를 읽어야 합니다. 세 번째는 내부 배치입니다. 새벽 정산 잡이 한도를 다 써버리면 아침 고객 요청이 막히므로, 내부 트래픽은 별도 키로 떼어 한도를 따로 잡아야 합니다.
네트워크·API 트래픽 관리 기법으로, 웹 서비스와 오픈 API의 확산과 함께 표준 방어 수단이 됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 140명 규모의 B2B 온라인 교육 플랫폼 A사 이야기입니다. 강의 요약·퀴즈 생성 기능에 외부 LLM API를 붙인 지 5주 만에 월 API 청구서가 210만 원에서 1,680만 원으로 뛰었고, 수강신청이 열리는 매달 첫 주 월요일마다 서버가 20분씩 멈췄습니다. CTO가 '요금제를 올릴 게 아니라 문을 좁혀야 한다'며 대응에 들어갔습니다.
- 백엔드 김 팀장이 2주치 호출 로그를 뜯어보니 전체 호출의 61%가 상위 3개 계정에서 나왔고, 그중 한 곳은 자동화 스크립트로 초당 40회씩 두 시간을 때리고 있었습니다.
- CTO와 김 팀장은 토큰 버킷 방식을 골라 API 키 단위로 분당 60회, 순간 버스트 20회까지 허용하도록 게이트웨이 설정을 바꿨고, 초과분은 429로 돌려보내기로 했습니다.
- 프론트 담당 박 선임이 429 응답에 Retry-After를 30초로 실어 내려주고, 클라이언트에는 2초·4초·8초 지수 백오프와 무작위 지연을 붙여 재시도가 다시 폭주로 번지지 않게 막았습니다.
- 적용 이틀째, 본사 직원 90명이 한꺼번에 막히는 사고가 났습니다. 사내 NAT 탓에 전원이 같은 IP로 나온 탓이라 김 팀장이 '기준을 IP가 아니라 사용자 ID로 바꿉니다'라고 정리했고, 새벽 정산 배치는 별도 키로 분리했습니다.
- 적용 6주 뒤 월 API 비용은 1,680만 원에서 290만 원으로 내려갔고, 수강신청일 장애는 20분에서 0분, 평균 응답 시간은 3.4초에서 1.1초로 줄었습니다.