API 요청 제한, Rate Limiting 마스터하기: 안정적인 시스템 운영의 필수 전략

1. 개념 소개: 정의, 탄생 배경, 왜 중요한지

Rate Limiting이란?

Rate Limiting은 특정 기간 동안 클라이언트(사용자, IP 주소, API 키 등)가 API 또는 서비스에 보낼 수 있는 요청의 수를 제한하는 기술입니다. 예를 들어, "1분당 100개 요청"과 같이 제한을 두어 시스템에 가해지는 부하를 제어합니다.

탄생 배경

인터넷 서비스가 보편화되고 API 기반의 시스템이 확산되면서, 다음과 같은 문제들이 발생하기 시작했습니다.

• 서비스 거부 공격(DDoS): 악의적인 사용자가 대량의 요청을 보내 시스템을 마비시키려는 시도.
• 무차별 대입 공격(Brute Force Attack): 로그인 시도, 비밀번호 찾기 등 특정 API를 반복적으로 호출하여 보안 취약점을 노리는 공격.
• 자원 고갈: 특정 사용자가 과도하게 많은 요청을 보내 다른 사용자들의 서비스 이용에 지장을 주거나, 서버 자원을 불필요하게 소모시키는 경우.
• 비용 증가: 클라우드 환경에서는 요청 수에 따라 과금되는 경우가 많으므로, 불필요한 요청은 곧 비용 증가로 이어집니다.

이러한 문제들을 해결하고, 시스템의 안정성을 유지하며, 모든 사용자에게 공정한 서비스 경험을 제공하기 위해 Rate Limiting 기술이 필수적으로 등장했습니다.

왜 중요한가?

2026년 현재, 마이크로서비스 아키텍처와 클라우드 기반 시스템이 대세가 되면서 Rate Limiting의 중요성은 더욱 커졌습니다.

• 시스템 안정성: 과도한 요청으로부터 백엔드 서비스를 보호하여 장애를 예방합니다.
• 비용 효율성: 불필요한 API 호출을 줄여 클라우드 서비스 비용을 절감합니다.
• 공정성: 모든 사용자에게 균등한 서비스 접근 기회를 제공하고, 특정 사용자의 자원 독점을 방지합니다.
• 보안 강화: 무차별 대입 공격, 스팸 등 악의적인 행위를 차단하여 시스템 보안을 강화합니다.
• API 관리: API 사용량을 제어하고, 개발자나 파트너에게 명확한 사용 정책을 제공합니다.

Rate Limiting은 단순히 요청을 막는 것을 넘어, 시스템의 건강을 유지하고 지속 가능한 서비스를 제공하기 위한 핵심적인 방어 메커니즘이자 관리 도구입니다.

2. 핵심 원리 설명 (비유와 다이어그램 활용)

Rate Limiting에는 여러 알고리즘이 있으며, 각각 장단점이 있습니다. 초중급 개발자가 알아야 할 주요 알고리즘은 다음과 같습니다.

2.1. 고정 윈도우 카운터 (Fixed Window Counter)

가장 간단한 방법입니다. 정해진 시간 윈도우(예: 1분) 동안 들어온 요청 수를 세고, 이 수가 제한을 초과하면 요청을 거부합니다.

• 비유: 매 시간 정각에 초기화되는 '카운터'가 있는 문지기. 1분 동안 100명까지만 입장시키고, 1분이 지나면 카운터를 0으로 초기화합니다.
• 장점: 구현이 매우 간단합니다.
• 단점: 윈도우 경계(Edge Case)에서 문제가 발생할 수 있습니다. 예를 들어, 1분당 100개 제한일 때, 0분 59초에 90개 요청, 1분 01초에 90개 요청이 들어오면 실제로는 2초 사이에 180개 요청이 처리되어 시스템에 순간적인 부하가 집중될 수 있습니다.

graph TD
    A[요청 도착] --> B{현재 시간 윈도우};
    B -- 카운터 증가 --> C[카운터 < 제한?];
    C -- Yes --> D[요청 처리];
    C -- No --> E[429 Too Many Requests];
    B -- 윈도우 끝 --> F[카운터 0으로 초기화];

2.2. 토큰 버킷 (Token Bucket)

일정한 속도로 토큰을 생성하여 버킷에 채우고, 요청이 올 때마다 버킷에서 토큰을 하나씩 꺼내 사용합니다. 버킷에 토큰이 없으면 요청을 거부합니다. 버킷의 크기는 최대로 저장할 수 있는 토큰의 수를 결정하며, 이는 순간적으로 처리할 수 있는 요청의 최대치를 의미합니다 (버스트 허용).

• 비유: 수도꼭지에서 일정한 속도로 물방울(토큰)이 떨어져서 통(버킷)에 모입니다. 사람이 물(요청)을 마실 때마다 통에서 물방울 하나를 꺼냅니다. 통이 비어있으면 물을 마실 수 없습니다. 통의 크기가 크면 한 번에 많은 물을 마실 수 있습니다.
• 장점: 버스트 트래픽(순간적인 요청 증가)을 유연하게 처리할 수 있습니다. 토큰 생성 속도를 통해 평균 처리율을 제어하고, 버킷 크기를 통해 최대 버스트 크기를 제어합니다.
• 단점: 고정 윈도우 방식보다는 구현이 복잡합니다.

graph TD
    A[토큰 생성기] -- 일정한 속도 --> B[토큰 버킷 (최대 용량)];
    C[요청 도착] --> D{버킷에 토큰이 있는가?};
    D -- Yes --> E[토큰 사용 & 요청 처리];
    D -- No --> F[429 Too Many Requests];

2.3. 슬라이딩 윈도우 카운터 (Sliding Window Counter)

고정 윈도우 카운터의 경계 문제와 슬라이딩 윈도우 로그 방식의 높은 메모리 사용량 단점을 보완한 하이브리드 방식입니다. 현재 윈도우의 카운터와 이전 윈도우의 카운터를 조합하여 요청 수를 추정합니다.

• 비유: 1분당 100개 제한이라고 가정해봅시다. 현재 시간이 1분 30초라면, 현재 1분 윈도우(1분 0초 ~ 1분 59초)의 요청 수와 이전 1분 윈도우(0분 0초 ~ 0분 59초)의 요청 수를 모두 사용합니다. 이전 윈도우의 카운터는 현재 윈도우와 겹치는 비율만큼만 가중치를 부여하여 계산합니다. 예를 들어, 1분 30초 시점에서는 이전 윈도우의 절반만 현재 윈도우에 영향을 미치므로, 현재 윈도우 카운터 + (이전 윈도우 카운터 * 0.5)로 총 요청 수를 추정합니다.
• 장점: 고정 윈도우 방식보다 경계 문제를 훨씬 완화하면서도, 슬라이딩 윈도우 로그 방식보다 메모리 효율적입니다.
• 단점: 정확도가 완벽하지는 않지만, 실용적인 수준에서 좋은 절충안입니다.

graph TD
    A[요청 도착] --> B{현재 시간};
    B --> C[현재 윈도우 카운터 증가];
    C --> D{이전 윈도우 카운터와 가중치 계산};
    D -- 합산 요청 수 --> E{합산 요청 수 < 제한?};
    E -- Yes --> F[요청 처리];
    E -- No --> G[429 Too Many Requests];

3. 코드 예제 2개 (Python)

예제 1: 간단한 인메모리 토큰 버킷 (Token Bucket) 구현

이 예제는 단일 프로세스 내에서 작동하는 간단한 토큰 버킷입니다. 실제 분산 환경에서는 Redis 같은 외부 저장소를 사용해야 합니다.

import time

class TokenBucketRateLimiter:
    def __init__(self, capacity: int, fill_rate: int):
        """
        토큰 버킷 레이트 리미터를 초기화합니다.
        :param capacity: 버킷의 최대 토큰 용량 (최대 버스트 요청 수)
        :param fill_rate: 초당 토큰 생성 속도 (평균 처리율)
        """
        self.capacity = capacity
        self.fill_rate = fill_rate
        self.tokens = capacity # 초기에는 버킷을 가득 채웁니다.
        self.last_refill_time = time.time() # 마지막 토큰 충전 시간

    def _refill_tokens(self):
        """
        시간이 지남에 따라 토큰을 충전합니다.
        """
        now = time.time()
        time_elapsed = now - self.last_refill_time
        
        # 경과 시간 동안 생성되어야 할 토큰 수
        tokens_to_add = time_elapsed * self.fill_rate
        
        # 현재 토큰 수에 추가하고, 버킷 용량을 초과하지 않도록 합니다.
        self.tokens = min(self.capacity, self.tokens + tokens_to_add)
        self.last_refill_time = now

    def allow_request(self, cost: int = 1) -> bool:
        """
        요청을 허용할지 여부를 반환합니다.
        :param cost: 요청이 소비할 토큰 수 (기본 1)
        :return: 요청 허용 여부
        """
        self._refill_tokens() # 토큰을 먼저 충전합니다.

        if self.tokens >= cost:
            self.tokens -= cost
            return True
        return False

# 사용 예제
if __name__ == "__main__":
    # 버킷 용량 10개, 초당 2개 토큰 생성 (즉, 5초 동안 최대 10개 버스트, 평균 초당 2개 처리)
    limiter = TokenBucketRateLimiter(capacity=10, fill_rate=2) 
    
    print("--- 1초에 3개씩 요청 시도 ---")
    for i in range(1, 10):
        if limiter.allow_request():
            print(f"[{time.time():.2f}] Request {i}: Allowed")
        else:
            print(f"[{time.time():.2f}] Request {i}: DENIED (Too Many Requests)")
        time.sleep(0.3) # 0.3초마다 요청 시도

    print("\n--- 잠시 대기 후 다시 시도 ---")
    time.sleep(3) # 3초 대기 (토큰 6개 충전 예상)

    for i in range(10, 15):
        if limiter.allow_request():
            print(f"[{time.time():.2f}] Request {i}: Allowed")
        else:
            print(f"[{time.time():.2f}] Request {i}: DENIED (Too Many Requests)")
        time.sleep(0.3)

실행 결과 예시:

--- 1초에 3개씩 요청 시도 ---
[1701234567.89] Request 1: Allowed
[1701234568.19] Request 2: Allowed
[1701234568.49] Request 3: Allowed
[1701234568.79] Request 4: Allowed
[1701234569.09] Request 5: Allowed
[1701234569.39] Request 6: Allowed
[1701234569.69] Request 7: Allowed
[1701234569.99] Request 8: Allowed
[1701234570.29] Request 9: Allowed

--- 잠시 대기 후 다시 시도 ---
[1701234573.59] Request 10: Allowed
[1701234573.89] Request 11: Allowed
[1701234574.19] Request 12: Allowed
[1701234574.49] Request 13: Allowed
[1701234574.79] Request 14: DENIED (Too Many Requests) # 토큰이 부족해 거부될 수 있음

(실행 시간과 토큰 충전 로직에 따라 정확한 출력은 달라질 수 있습니다.)

예제 2: 인메모리 슬라이딩 윈도우 카운터 (Sliding Window Counter) 개념 구현

이 역시 단일 프로세스용이며, 분산 환경에서는 Redis Sorted Set 등을 활용해야 합니다.

import time
from collections import deque

class SlidingWindowCounterRateLimiter:
    def __init__(self, window_size_seconds: int, limit: int):
        """
        슬라이딩 윈도우 카운터 레이트 리미터를 초기화합니다.
        :param window_size_seconds: 윈도우 크기 (초 단위)
        :param limit: 윈도우 내 최대 허용 요청 수
        """
        self.window_size = window_size_seconds
        self.limit = limit
        # 각 요청의 타임스탬프를 저장하는 덱 (가장 오래된 요청부터 제거)
        self.requests = deque() 

    def allow_request(self) -> bool:
        """
        요청을 허용할지 여부를 반환합니다.
        :return: 요청 허용 여부
        """
        now = time.time()
        
        # 윈도우 밖의 오래된 요청들을 제거합니다.
        while self.requests and self.requests[0] <= now - self.window_size:
            self.requests.popleft()
            
        # 현재 윈도우 내의 요청 수가 제한을 초과하는지 확인합니다.
        if len(self.requests) < self.limit:
            self.requests.append(now) # 요청 허용 시 현재 타임스탬프를 추가
            return True
        else:
            return False

# 사용 예제
if __name__ == "__main__":
    # 10초 동안 최대 5개 요청 허용
    limiter = SlidingWindowCounterRateLimiter(window_size_seconds=10, limit=5)

    print("--- 10초 동안 5개 초과 요청 시도 ---")
    for i in range(1, 10):
        if limiter.allow_request():
            print(f"[{time.time():.2f}] Request {i}: Allowed")
        else:
            print(f"[{time.time():.2f}] Request {i}: DENIED (Too Many Requests)")
        time.sleep(1) # 1초마다 요청 시도

    print("\n--- 10초 대기 후 다시 시도 ---")
    time.sleep(10) # 10초 대기 (모든 이전 요청들이 윈도우 밖으로 나감)

    for i in range(10, 15):
        if limiter.allow_request():
            print(f"[{time.time():.2f}] Request {i}: Allowed")
        else:
            print(f"[{time.time():.2f}] Request {i}: DENIED (Too Many Requests)")
        time.sleep(1)

실행 결과 예시:

--- 10초 동안 5개 초과 요청 시도 ---
[1701234575.00] Request 1: Allowed
[1701234576.00] Request 2: Allowed
[1701234577.00] Request 3: Allowed
[1701234578.00] Request 4: Allowed
[1701234579.00] Request 5: Allowed
[1701234580.00] Request 6: DENIED (Too Many Requests)
[1701234581.00] Request 7: DENIED (Too Many Requests)
[1701234582.00] Request 8: DENIED (Too Many Requests)
[1701234583.00] Request 9: DENIED (Too Many Requests)

--- 10초 대기 후 다시 시도 ---
[1701234593.00] Request 10: Allowed
[1701234594.00] Request 11: Allowed
[1701234595.00] Request 12: Allowed
[1701234596.00] Request 13: Allowed
[1701234597.00] Request 14: Allowed

4. 실무 적용 사례

Rate Limiting은 다양한 시스템 계층에서 활용됩니다.

• API Gateway 또는 Reverse Proxy: Nginx, Apache, AWS API Gateway, Azure API Management, Google Cloud Apigee 등에서 클라이언트로부터 들어오는 모든 요청에 대해 일괄적으로 Rate Limiting을 적용합니다. 이는 백엔드 서비스에 도달하기 전에 미리 트래픽을 제어하는 가장 효과적인 방법입니다.
• 로드 밸런서 (Load Balancer): 특정 IP 주소나 사용자로부터의 과도한 트래픽을 감지하여 해당 트래픽을 제한하거나 차단할 수 있습니다.
• 마이크로서비스 내부: 각 마이크로서비스가 자체적인 Rate Limiting 로직을 가질 수 있습니다. 예를 들어, 사용자 프로필 서비스는 "분당 100회 조회"로 제한하고, 결제 서비스는 "분당 10회 결제 시도"로 제한하는 식입니다. 이는 서비스 간의 의존성을 줄이고 각 서비스의 독립적인 안정성을 보장합니다.
• 로그인/회원가입 시스템: 특정 IP 주소 또는 사용자 ID가 짧은 시간 내에 너무 많은 로그인 시도를 할 경우, 무차별 대입 공격으로 간주하고 해당 계정의 잠금 또는 IP 차단을 적용합니다.
• 서드파티 API 연동: 외부 API를 사용할 때, 해당 API 제공자가 정해놓은 Rate Limiting 정책을 준수해야 합니다. 이를 위해 클라이언트 측에서도 요청 전 Rate Limiter를 구현하여 불필요한 에러 발생을 막습니다.
• 검색 엔진 크롤링: 웹사이트는 검색 봇이 너무 자주 페이지를 요청하여 서버에 부하를 주는 것을 막기 위해 Rate Limiting을 적용할 수 있습니다.

5. 자주 하는 실수와 해결법

5.1. 너무 엄격하거나 너무 느슨한 제한

• 문제: 제한이 너무 엄격하면 정당한 사용자의 서비스 이용이 방해받고, 너무 느슨하면 시스템이 공격에 취약해지거나 과부하에 노출됩니다.
• 해결법:
  • 사용량 분석: 실제 사용자들의 트래픽 패턴, 피크 시간대, 평균 요청 수 등을 모니터링하여 합리적인 기준을 설정합니다.
  • 단계별 적용: 처음에는 약간 느슨하게 시작하여 점진적으로 조정하거나, 사용자 등급별(무료/유료, 일반/프리미엄)로 다른 정책을 적용합니다.
  • A/B 테스트: 다양한 제한 정책을 소수의 사용자 그룹에 적용하여 효과를 검증합니다.

5.2. 분산 환경 고려 부족 (인메모리 Rate Limiter 사용)

• 문제: 애플리케이션 서버가 여러 대일 때, 각 서버가 독립적으로 Rate Limiting을 수행하면 총 요청 수가 실제 제한보다 훨씬 많아질 수 있습니다. 예를 들어, 1분당 100개 제한인데 서버가 5대라면, 각 서버가 100개씩 허용하여 총 500개가 허용될 수 있습니다.
• 해결법:
  • 중앙 집중식 저장소 활용: Redis와 같은 분산 캐시 시스템을 활용하여 모든 서버가 공유하는 Rate Limiting 카운터를 관리합니다. Redis의 INCR, EXPIRE, ZADD, ZCOUNT, ZREMRANGEBYSCORE 등의 명령어를 조합하여 고정 윈도우, 슬라이딩 윈도우, 토큰 버킷 등을 구현할 수 있습니다.
  • API Gateway 활용: API Gateway 수준에서 Rate Limiting을 적용하여 백엔드 서비스에 도달하기 전에 요청을 제어합니다.

5.3. 버스트 트래픽 처리 미흡 (고정 윈도우 방식만 고집)

• 문제: 고정 윈도우 방식은 윈도우 경계에서 순간적인 대량 요청(버스트)을 효과적으로 막지 못할 수 있습니다.
• 해결법:
  • 토큰 버킷 또는 슬라이딩 윈도우 카운터 사용: 버스트 트래픽에 더 강한 토큰 버킷이나 슬라이딩 윈도우 카운터 알고리즘을 적용합니다. 특히 토큰 버킷은 버킷 용량을 통해 버스트 허용량을 명확히 제어할 수 있습니다.

5.4. 사용자에게 불친절한 응답

• 문제: Rate Limiting에 걸렸을 때, 사용자에게 명확한 피드백을 주지 않으면 혼란을 야기하고 불만을 초래할 수 있습니다.
• 해결법:
  • HTTP 429 Too Many Requests 응답: 표준 HTTP 상태 코드인 429를 반환하여 클라이언트에게 요청이 제한되었음을 알립니다.
  • Retry-After 헤더 제공: HTTP 응답 헤더에 Retry-After 필드를 포함하여 클라이언트가 몇 초 후에 다시 시도해야 하는지 알려줍니다. 이는 클라이언트가 불필요한 재시도를 줄이고, 개발자가 재시도 로직을 구현하는 데 도움을 줍니다.

5.5. 잘못된 식별자 사용

• 문제: Rate Limiting의 기준(Key)을 잘못 설정하면, 의도치 않게 다른 사용자에게 영향을 주거나 공격에 취약해질 수 있습니다. 예를 들어, 모든 요청에 대해 단일 IP 주소로만 제한하면 NAT 환경의 여러 사용자가 한 명의 공격자 때문에 피해를 볼 수 있습니다.
• 해결법:
  • 다양한 기준 조합: IP 주소, 사용자 ID, API 키, 세션 ID 등 여러 식별자를 조합하여 사용합니다.
  • 계층적 Rate Limiting: 예를 들어, IP당 분당 100개, 사용자 ID당 분당 50개와 같이 여러 계층의 제한을 동시에 적용하여 더 정교하게 제어합니다.

6. 더 공부할 리소스 추천

• Redis 공식 문서: Redis를 활용한 Rate Limiting 구현 방법에 대한 좋은 예제와 설명이 많습니다. 특히 INCR, EXPIRE, ZADD, ZCOUNT 등의 명령어를 중심으로 살펴보세요.
  • Redis Rate Limiting with Lua scripts (Lua 스크립트를 사용한 고급 기법)
• System Design Interview Resources: Rate Limiting은 시스템 디자인 면접에서 단골 주제입니다.
  • Grokking the System Design Interview (유료 강의지만, 핵심 개념을 잘 다룹니다.)
  • "Designing a Rate Limiter" 관련 블로그 글이나 유튜브 강의를 검색하여 다양한 구현 방식과 트레이드오프를 비교해보세요.
• Nginx, AWS API Gateway 문서: 실제 상용 서비스에서 Rate Limiting을 어떻게 설정하고 활용하는지 살펴보면 실무 감각을 익히는 데 도움이 됩니다.
  • Nginx Rate Limiting
  • AWS API Gateway Usage Plans and Throttling
• 관련 라이브러리/프레임워크: 사용하고 있는 언어나 프레임워크에 Rate Limiting을 쉽게 적용할 수 있는 라이브러리들이 있습니다.
  • Python: flask-limiter, ratelimit
  • Node.js: express-rate-limit, rate-limiter-flexible
  • Java: resilience4j (circuit breaker와 함께 사용 가능)

Rate Limiting은 복잡한 분산 시스템을 안정적으로 운영하기 위한 필수적인 기술입니다. 단순히 요청을 막는 것을 넘어, 시스템의 자원을 효율적으로 사용하고, 사용자 경험을 개선하며, 잠재적인 보안 위협으로부터 서비스를 보호하는 다면적인 역할을 수행합니다. 이 글이 여러분의 시스템을 더욱 견고하게 만드는 데 도움이 되기를 바랍니다!