시스템의 안정성을 지키는 파수꾼: API Rate Limiting 마스터하기

안녕하세요, 10년 경력의 소프트웨어 엔지니어이자 기술 교육자로서 여러분과 함께 성장하고 있는 강엔지니어입니다. 오늘은 현대 웹 서비스와 분산 시스템에서 선택이 아닌 필수가 된 중요한 개념, 바로 API Rate Limiting에 대해 이야기해보려 합니다. 여러분이 만드는 서비스가 수많은 요청 속에서도 굳건히 버티고, 모든 사용자에게 공정한 기회를 제공하며, 나아가 악의적인 공격으로부터 스스로를 보호할 수 있도록 돕는 강력한 방패막이 될 것입니다.

Rate Limiting은 단순히 "너무 많이 요청하지 마!"라고 말하는 것을 넘어, 시스템의 안정성, 보안, 그리고 자원의 효율적인 관리를 위한 핵심 전략입니다. 초중급 개발자라면 이 개념을 정확히 이해하고 실무에 적용하는 것이 서비스의 품질을 한 단계 끌어올리는 중요한 발판이 될 것입니다.

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

정의

API Rate Limiting은 특정 기간 동안 클라이언트(사용자, 애플리케이션 등)가 서버에 보낼 수 있는 요청의 수를 제한하는 기술 또는 정책을 말합니다. 예를 들어, "이 사용자는 1분 동안 최대 100개의 요청만 보낼 수 있다"와 같은 규칙을 설정하고 이를 초과하는 요청은 거부하거나 지연시키는 방식입니다.

탄생 배경

Rate Limiting은 다음과 같은 문제들을 해결하기 위해 탄생했습니다.

1. 서비스 과부하 및 다운 방지: 단일 클라이언트나 소수의 클라이언트가 너무 많은 요청을 보내면 서버 자원(CPU, 메모리, 네트워크 대역폭, 데이터베이스 연결 등)이 고갈되어 서비스 전체가 느려지거나 다운될 수 있습니다. 특히 분산 서비스 거부(DDoS) 공격과 같은 악의적인 시도로부터 시스템을 보호하는 데 필수적입니다.
2. 자원 공정 분배: 모든 사용자 또는 클라이언트가 시스템 자원을 공정하게 사용할 수 있도록 보장합니다. 특정 사용자가 자원을 독점하는 것을 막아 다른 사용자들의 서비스 이용에 지장이 없도록 합니다.
3. 비용 관리: 클라우드 기반 서비스의 경우, API 요청 수에 따라 과금이 되는 경우가 많습니다. Rate Limiting을 통해 예상치 못한 과도한 요청으로 인한 비용 폭탄을 방지할 수 있습니다.
4. 보안 강화: 무차별 대입(Brute-force) 공격(예: 로그인 시도, 비밀번호 찾기)과 같이 특정 API를 반복적으로 호출하여 취약점을 찾으려는 시도를 방어합니다.

왜 중요한가?

2026년 현재, 대부분의 현대 웹 서비스는 마이크로서비스 아키텍처와 API 기반 통신을 활용합니다. 이는 서비스 간의 의존성과 복잡성을 증가시키며, 한 서비스의 장애가 다른 서비스로 전파될 위험을 높입니다. Rate Limiting은 이러한 복잡한 시스템에서 각 서비스의 독립성과 안정성을 보장하고, 전체 시스템의 탄력성을 높이는 데 핵심적인 역할을 합니다. 안정적인 서비스 운영은 사용자 신뢰와 직결되며, 이는 곧 비즈니스 성공으로 이어집니다.

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

Rate Limiting을 구현하는 데는 여러 가지 알고리즘이 사용됩니다. 각 알고리즘은 장단점이 있으며, 서비스의 특성에 맞춰 적절한 것을 선택해야 합니다.

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

• 원리: 시간을 일정한 간격(예: 1분)으로 나누고, 각 윈도우 내에서 발생한 요청 수를 카운트합니다. 윈도우가 시작될 때 카운터는 0으로 초기화됩니다.
• 비유: 놀이공원의 "1분 동안 100명 입장 가능" 규칙과 같습니다. 오전 9시 정각부터 9시 1분까지 100명이 들어오면 더 이상 입장이 안 되고, 9시 1분이 되는 순간 다시 100명이 들어올 수 있습니다.
• 장점: 구현이 간단하고 이해하기 쉽습니다.
• 단점: 윈도우 경계에서 문제가 발생할 수 있습니다. 예를 들어, 0분 59초에 99개 요청, 1분 01초에 99개 요청이 발생하면 실제로는 2초 동안 198개 요청이 발생했지만, 각 윈도우에서는 제한을 넘지 않아 통과될 수 있습니다. 이를 "윈도우 경계 문제(Edge Case Problem)"라고 합니다.

2. 슬라이딩 윈도우 로깅 (Sliding Window Logging)

• 원리: 각 요청이 발생한 정확한 타임스탬프를 기록하고, 새로운 요청이 들어올 때마다 현재 시간으로부터 이전 윈도우 크기(예: 1분) 안에 있는 모든 요청의 수를 세어 제한을 적용합니다.
• 비유: 놀이공원에서 "지금으로부터 과거 1분 안에 100명 이상 입장했으면 대기하세요"라고 말하는 것과 같습니다. 매번 입장 시마다 지난 1분간의 기록을 확인합니다.
• 장점: 고정 윈도우의 경계 문제를 해결하여 가장 정확한 제한을 제공합니다.
• 단점: 모든 요청의 타임스탬프를 저장해야 하므로 메모리 사용량이 많고, 요청 수를 계산하는 데 비용이 많이 듭니다.

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

• 원리: 고정 윈도우 카운터와 슬라이딩 윈도우 로깅의 장점을 결합한 방식입니다. 현재 윈도우의 카운터와 이전 윈도우의 카운터를 조합하여 사용합니다. 예를 들어, 현재 윈도우의 카운터와 이전 윈도우의 남은 비율에 해당하는 카운터를 합산하여 현재 요청 수를 추정합니다.
• 비유: "이번 1분 동안 쓴 카운터 + 지난 1분 동안 쓴 카운터 중 남은 시간만큼의 비율"을 합산하여 총량을 판단하는 방식입니다. 예를 들어, 1분당 100개 제한인데, 현재 윈도우가 30초 진행되었고 현재 윈도우에서 50개를 사용했다면, 이전 윈도우의 남은 30초 동안의 사용량(가정치)을 더해서 판단합니다.
• 장점: 고정 윈도우보다 정확하면서도 슬라이딩 윈도우 로깅보다 자원 효율적입니다. 실제 서비스에서 가장 널리 사용되는 방식 중 하나입니다.
• 단점: 완벽하게 정확하지는 않지만, 대부분의 경우 충분히 실용적입니다.

4. 토큰 버킷 (Token Bucket)

• 원리: 일정한 속도로 토큰이 채워지는 버킷이 있다고 가정합니다. 각 요청이 들어올 때마다 버킷에서 토큰 하나를 소모합니다. 버킷에 토큰이 없으면 요청은 거부됩니다. 버킷은 최대 토큰 수를 가질 수 있어, 순간적으로 많은 요청(버스트)을 처리할 수 있는 유연성을 제공합니다.
• 비유: 유료 고속도로의 "하이패스 차선"과 비슷합니다. 하이패스 잔액(토큰)이 충분하면 빠르게 통과하고, 잔액이 없으면 일반 차선으로 가거나 통과할 수 없습니다. 잔액은 시간이 지나면 자동으로 충전됩니다.
• 장점: 순간적인 트래픽 급증(버스트)에 유연하게 대처할 수 있습니다. 구현이 비교적 간단합니다.
• 단점: 버킷 크기와 토큰 생성 속도를 적절하게 조절하는 것이 중요합니다.

5. 리키 버킷 (Leaky Bucket)

• 원리: 물이 일정한 속도로 새어 나가는 버킷이 있다고 가정합니다. 요청은 물방울처럼 버킷에 들어오고, 버킷이 가득 차면 더 이상 물을 받을 수 없습니다. 버킷에서 물이 새어 나가는 속도가 곧 요청 처리 속도가 됩니다.
• 비유: 고속도로의 "톨게이트"와 비슷합니다. 차들이 톨게이트로 들어오지만, 톨게이트는 일정한 속도로만 차들을 내보냅니다. 톨게이트 진입로가 가득 차면 더 이상 차가 들어올 수 없습니다.
• 장점: 요청 처리 속도를 매우 균일하게 유지하여 시스템 안정성을 높입니다.
• 단점: 순간적인 트래픽 급증(버스트)에 취약합니다. 요청이 지연될 수 있습니다.

3. 코드 예제 2개 (Python)

여기서는 이해를 돕기 위해 간단한 Rate Limiting 미들웨어 또는 데코레이터를 Python으로 구현해 보겠습니다. 실제 프로덕션 환경에서는 Redis와 같은 분산 캐시 시스템을 사용하여 카운터를 관리해야 합니다.

예제 1: 고정 윈도우 카운터 (Fixed Window Counter)

import time
from collections import defaultdict

# 사용자별 요청 기록을 저장할 딕셔너리 (실제로는 Redis 같은 곳에 저장)
# { 'user_id': { 'window_start_time': count } }
request_counts = defaultdict(lambda: defaultdict(int))

# Rate Limiting 설정
RATE_LIMIT_WINDOW_SECONDS = 60  # 1분
RATE_LIMIT_MAX_REQUESTS = 5     # 1분당 최대 5개 요청

def fixed_window_rate_limiter(user_id):
    """
    고정 윈도우 카운터 알고리즘을 사용하여 요청을 제한합니다.
    :param user_id: 요청을 보내는 사용자 ID
    :return: 요청 허용 여부 (True/False)
    """
    current_time = time.time()
    # 현재 윈도우의 시작 시간을 계산 (예: 1분 윈도우면 0, 60, 120...)
    window_start = int(current_time / RATE_LIMIT_WINDOW_SECONDS) * RATE_LIMIT_WINDOW_SECONDS

    # 현재 윈도우의 요청 카운트를 가져옴
    current_window_requests = request_counts[user_id][window_start]

    if current_window_requests < RATE_LIMIT_MAX_REQUESTS:
        # 제한 내이면 요청 허용 및 카운트 증가
        request_counts[user_id][window_start] += 1
        print(f"[{user_id}] 요청 허용. 현재 윈도우 ({window_start}s) 요청 수: {request_counts[user_id][window_start]}")
        return True
    else:
        # 제한 초과 시 요청 거부
        print(f"[{user_id}] 요청 거부. 제한 초과 ({RATE_LIMIT_MAX_REQUESTS}개/분). 현재 윈도우 ({window_start}s) 요청 수: {current_window_requests}")
        return False

# 테스트
print("--- 고정 윈도우 카운터 테스트 ---")
user1 = "user_alpha"

# 첫 번째 윈도우 (5개 요청 허용)
for i in range(7):
    fixed_window_rate_limiter(user1)
    time.sleep(0.1) # 짧은 지연

print("\n--- 윈도우 경계 넘어서 테스트 (새로운 윈도우) ---")
time.sleep(RATE_LIMIT_WINDOW_SECONDS + 1) # 다음 윈도우로 이동
for i in range(3):
    fixed_window_rate_limiter(user1)
    time.sleep(0.1)

print("\n--- 윈도우 경계 문제 시뮬레이션 ---")
# 윈도우 끝에 몰아서 요청
user2 = "user_beta"
RATE_LIMIT_WINDOW_SECONDS_SIM = 10 # 10초 윈도우
RATE_LIMIT_MAX_REQUESTS_SIM = 3    # 10초당 3개 요청
request_counts_sim = defaultdict(lambda: defaultdict(int)) # 시뮬레이션용 별도 카운터

def fixed_window_rate_limiter_sim(user_id):
    current_time = time.time()
    window_start = int(current_time / RATE_LIMIT_WINDOW_SECONDS_SIM) * RATE_LIMIT_WINDOW_SECONDS_SIM
    current_window_requests = request_counts_sim[user_id][window_start]

    if current_window_requests < RATE_LIMIT_MAX_REQUESTS_SIM:
        request_counts_sim[user_id][window_start] += 1
        print(f"[{user_id}] 요청 허용. 현재 윈도우 ({window_start}s) 요청 수: {request_counts_sim[user_id][window_start]}")
        return True
    else:
        print(f"[{user_id}] 요청 거부. 제한 초과 ({RATE_LIMIT_MAX_REQUESTS_SIM}개/{RATE_LIMIT_WINDOW_SECONDS_SIM}초). 현재 윈도우 ({window_start}s) 요청 수: {current_window_requests}")
        return False

# 윈도우 끝에 요청 몰아넣기
for i in range(RATE_LIMIT_MAX_REQUESTS_SIM):
    fixed_window_rate_limiter_sim(user2)
    time.sleep(0.1) # 윈도우 끝에 몰아서 보냄
time.sleep(RATE_LIMIT_WINDOW_SECONDS_SIM - 0.5) # 윈도우 끝나기 직전까지 대기
print(f"\n--- 윈도우 경계 직전: {time.time()} ---")
for i in range(RATE_LIMIT_MAX_REQUESTS_SIM):
    fixed_window_rate_limiter_sim(user2)
    time.sleep(0.1)
print(f"-> 2*{RATE_LIMIT_MAX_REQUESTS_SIM} = {2*RATE_LIMIT_MAX_REQUESTS_SIM}개의 요청이 짧은 시간 안에 허용될 수 있습니다.")

예제 2: 토큰 버킷 (Token Bucket)

import time

class TokenBucketRateLimiter:
    def __init__(self, capacity, fill_rate_per_second):
        """
        토큰 버킷 Rate Limiter를 초기화합니다.
        :param capacity: 버킷의 최대 토큰 수 (버스트 허용량)
        :param fill_rate_per_second: 초당 토큰 생성 속도
        """
        self.capacity = capacity
        self.fill_rate_per_second = fill_rate_per_second
        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_per_second
        self.tokens = min(self.capacity, self.tokens + tokens_to_add)
        self.last_refill_time = now

    def allow_request(self, num_tokens=1):
        """
        요청에 필요한 토큰을 버킷에서 소모합니다.
        :param num_tokens: 요청에 필요한 토큰 수 (기본값 1)
        :return: 요청 허용 여부 (True/False)
        """
        self._refill_tokens() # 먼저 토큰을 보충

        if self.tokens >= num_tokens:
            self.tokens -= num_tokens
            # print(f"요청 허용. 남은 토큰: {self.tokens:.2f}")
            return True
        else:
            # print(f"요청 거부. 남은 토큰 부족: {self.tokens:.2f}")
            return False

# 테스트
print("\n--- 토큰 버킷 Rate Limiter 테스트 ---")
# 10개의 토큰 용량, 초당 2개의 토큰 생성 (1분당 120개)
limiter = TokenBucketRateLimiter(capacity=10, fill_rate_per_second=2)

print("초기 상태 (버킷 가득 참):")
for i in range(12): # 버킷 용량보다 많이 요청
    if limiter.allow_request():
        print(f"요청 {i+1} 허용. 남은 토큰: {limiter.tokens:.2f}")
    else:
        print(f"요청 {i+1} 거부. 남은 토큰: {limiter.tokens:.2f}")
    time.sleep(0.1) # 짧은 지연

print("\n잠시 대기 후 (토큰 보충 확인):")
time.sleep(2) # 2초 대기 -> 4개의 토큰이 보충됨
print(f"2초 후 남은 토큰: {limiter.tokens:.2f}")
if limiter.allow_request():
    print(f"추가 요청 허용. 남은 토큰: {limiter.tokens:.2f}")
else:
    print(f"추가 요청 거부. 남은 토큰: {limiter.tokens:.2f}")

print("\n버스트 요청 테스트:")
burst_limiter = TokenBucketRateLimiter(capacity=5, fill_rate_per_second=1)
print(f"버킷 용량: {burst_limiter.capacity}, 초당 생성: {burst_limiter.fill_rate_per_second}")
for i in range(7): # 순간적으로 7개 요청
    if burst_limiter.allow_request():
        print(f"버스트 요청 {i+1} 허용. 남은 토큰: {burst_limiter.tokens:.2f}")
    else:
        print(f"버스트 요청 {i+1} 거부. 남은 토큰: {burst_limiter.tokens:.2f}")
    # time.sleep(0.01) # 거의 동시에 요청

4. 실무 적용 사례

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

1. API 게이트웨이 (API Gateway): 마이크로서비스 아키텍처에서 모든 요청이 통과하는 API 게이트웨이(예: Nginx, Kong, AWS API Gateway, Azure API Management)에서 중앙 집중식으로 Rate Limiting을 적용하는 것이 일반적입니다. 이를 통해 백엔드 서비스는 Rate Limiting 로직을 직접 구현할 필요 없이 비즈니스 로직에 집중할 수 있습니다.
2. 웹 애플리케이션 백엔드: 특정 엔드포인트(예: 로그인, 회원가입, 비밀번호 찾기, 댓글 작성)에 직접 Rate Limiting을 적용하여 오용을 방지합니다. 예를 들어, 로그인 실패 횟수 제한을 통해 무차별 대입 공격을 막을 수 있습니다.
3. 클라우드 서비스: AWS, GCP, Azure와 같은 클라우드 서비스는 자체적으로 다양한 서비스(Lambda, EC2, S3 등)에 대한 Rate Limiting을 적용하여 서비스 안정성을 유지하고 과도한 리소스 사용을 방지합니다.
4. 마이크로서비스 간 통신: 서비스 간의 과도한 호출로 인해 특정 서비스가 병목 현상을 일으키는 것을 방지하기 위해, 서비스 A가 서비스 B를 호출할 때 Rate Limiting을 적용할 수 있습니다. 이는 서킷 브레이커 패턴과 함께 사용되어 시스템의 탄력성을 더욱 높입니다.
5. 서드파티 API 연동: 외부 API를 사용할 때, 해당 API 제공업체가 정한 Rate Limit을 초과하지 않도록 클라이언트 측에서도 Rate Limiting을 구현해야 합니다. 이는 우리의 애플리케이션이 외부 서비스로부터 차단되는 것을 방지합니다.

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

1. 과도한 제한 또는 너무 느슨한 제한

• 문제: 너무 엄격한 제한은 정당한 사용자 요청까지 거부하여 사용자 경험을 저해하고, 너무 느슨한 제한은 Rate Limiting의 목적을 달성하지 못하게 합니다.
• 해결법: 서비스의 특성, 예상 트래픽, 사용자 행동 패턴을 면밀히 분석하여 적절한 제한 값을 설정해야 합니다. 개발 초기에는 여유롭게 시작하여 점진적으로 조정하고, 중요한 API는 더 엄격하게, 덜 중요한 API는 더 유연하게 설정하는 등 다층적인 정책을 고려할 수 있습니다.

2. 분산 환경에서의 Rate Limiting 문제

• 문제: 여러 서버 인스턴스에서 애플리케이션이 실행되는 분산 환경에서는 각 서버가 독립적으로 카운터를 관리하면 실제 요청 수보다 더 많은 요청이 허용될 수 있습니다. (예: 1분 100개 제한인데 서버 2대면 총 200개 허용)
• 해결법: Rate Limiting 정보를 중앙 집중식으로 관리해야 합니다. Redis와 같은 인메모리 데이터 저장소를 사용하여 요청 카운터나 토큰 정보를 공유하고, 분산 락(Distributed Lock)을 활용하여 동시성 문제를 해결하는 것이 일반적입니다.

3. Rate Limiting 초과 시 부적절한 에러 처리

• 문제: 제한을 초과한 요청에 대해 단순히 서버 에러(500)를 반환하거나 불친절한 메시지를 제공하면 클라이언트가 상황을 이해하고 적절히 대응하기 어렵습니다.
• 해결법: HTTP 표준에 따라 HTTP 429 Too Many Requests 상태 코드를 반환해야 합니다. 또한, Retry-After 헤더를 포함하여 클라이언트에게 언제 다시 요청을 시도할 수 있는지 알려주는 것이 좋습니다. 이는 클라이언트가 불필요한 재시도를 줄이고 서버 부하를 줄이는 데 도움이 됩니다.

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

{
  "error": "Too Many Requests",
  "message": "You have exceeded your API rate limit. Please try again after 60 seconds."
}

4. Rate Limiting 정책의 가시성 부족

• 문제: 클라이언트 개발자가 API의 Rate Limiting 정책을 알기 어렵다면, 불필요한 시행착오를 겪거나 의도치 않게 제한을 위반할 수 있습니다.
• 해결법: API 문서에 Rate Limiting 정책을 명확하게 명시해야 합니다. 또한, 응답 헤더에 현재 남은 요청 수, 제한 값, 재설정 시간 등을 포함하여 클라이언트가 자신의 요청 상태를 실시간으로 모니터링할 수 있도록 돕는 것이 좋습니다 (예: X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset).

6. 더 공부할 리소스 추천

Rate Limiting은 서비스의 안정성과 확장성을 위한 필수적인 기술입니다. 아래 리소스들을 통해 더욱 깊이 있는 이해와 실전 경험을 쌓아보세요.

1. Redis 공식 문서: Redis를 활용한 Rate Limiting 구현은 분산 환경에서 가장 보편적인 방법 중 하나입니다. Redis의 INCR, EXPIRE 명령어와 Lua 스크립트를 이용한 구현 방법을 살펴보세요.
   • Redis for Rate Limiting
2. Nginx Rate Limiting: Nginx는 limit_req_zone 및 limit_req 지시어를 통해 강력한 Rate Limiting 기능을 제공합니다. 실제 프로덕션 환경에서 가장 많이 사용되는 방법 중 하나입니다.
   • Nginx Rate Limiting
3. AWS API Gateway Rate Limiting: 클라우드 환경에서 API Gateway를 사용한다면, 해당 서비스에서 제공하는 Rate Limiting 기능을 활용하는 방법을 익히는 것이 중요합니다.
   • AWS API Gateway Throttling and Quotas
4. 관련 오픈소스 라이브러리:
   • Python: ratelimit (데코레이터 기반), limits (Redis 지원)
   • Node.js: express-rate-limit (Express.js 미들웨어)
   • 이러한 라이브러리들의 코드를 분석하며 실제 구현 방식을 이해하는 것도 좋은 학습 방법입니다.
5. 기술 블로그 및 아티클: "Rate Limiting Algorithms Explained", "How to Implement Rate Limiting in Microservices" 등의 키워드로 검색하여 다양한 구현 사례와 알고리즘 비교 글을 읽어보세요.

Rate Limiting은 단순히 요청을 막는 것을 넘어, 시스템의 건강과 사용자 경험을 동시에 책임지는 중요한 설계 요소입니다. 이 글이 여러분의 서비스가 더욱 견고하고 안정적으로 성장하는 데 도움이 되기를 바랍니다.