API 속도 제한과 스로틀링이란?

속도 제한은 클라이언트가 윈도우당 보낼 수 있는 요청 수에 상한을 두는 제어 방식이며, 스로틀링은 초과 요청을 거부하지 않고 늦추는 방식입니다. 여기에 세 번째 형제인 할당량(quota), 즉 과금 주기 단위의 허용량을 더하면, 대부분의 설명이 한 단어로 뭉뚱그리는 어휘가 모두 갖춰집니다. 이 셋이 함께 API를 공정하고, 수지가 맞고, 중단 없이 유지합니다.

핵심 요약

429 응답과 속도 제한 헤더의 의미

HTTP/1.1 429 Too Many Requests        ← RFC 6585
Retry-After: 30                       ← 이만큼 대기(초 또는 날짜)
X-RateLimit-Limit: 1000               ← 이번 윈도우의 예산
X-RateLimit-Remaining: 0              ← 남은 양
X-RateLimit-Reset: 1767024000         ← 다시 채워지는 시점
RateLimit: "default";r=0;t=30         ← 새롭게 자리 잡는 IETF 표준 형식

계약의 클라이언트 쪽 절반, 즉 모든 SDK 사용자가 결국 필요로 하는 코드입니다:

// JavaScript / Node.js — Back4app JS SDK
// The client half of rate limiting: back off, with jitter, then retry
async function withBackoff(fn, attempt = 0) {
  try {
    return await fn();
  } catch (e) {
    if (e.code !== 155 || attempt >= 4) throw e;   // 155: request limit hit
    const wait = 2 ** attempt * 500 + Math.random() * 200;
    await new Promise((r) => setTimeout(r, wait)); // exponential + jitter
    return withBackoff(fn, attempt + 1);
  }
}
const results = await withBackoff(() => query.find());

// Flutter / Dart — Back4app Flutter SDK
// The client half of rate limiting: back off, with jitter, then retry
Future<ParseResponse> withBackoff(Future<ParseResponse> Function() fn,
    [int attempt = 0]) async {
  final response = await fn();
  if (response.success || attempt >= 4) return response;
  final wait = (1 << attempt) * 500 + Random().nextInt(200);
  await Future.delayed(Duration(milliseconds: wait)); // exponential + jitter
  return withBackoff(fn, attempt + 1);
}
final response = await withBackoff(() => query.query());

// iOS / Swift — Back4app Swift SDK
// The client half of rate limiting: back off, with jitter, then retry
func withBackoff<T>(_ attempt: Int = 0,
                    _ fn: @escaping () async throws -> T) async throws -> T {
  do { return try await fn() }
  catch {
    guard attempt < 4 else { throw error }
    let wait = pow(2.0, Double(attempt)) * 0.5 + .random(in: 0...0.2)
    try await Task.sleep(for: .seconds(wait))   // exponential + jitter
    return try await withBackoff(attempt + 1, fn)
  }
}
let results = try await withBackoff { try await query.find() }

// Android / Kotlin — Back4app Android SDK
// The client half of rate limiting: back off, with jitter, then retry
suspend fun <T> withBackoff(attempt: Int = 0, fn: suspend () -> T): T {
  return try {
    fn()
  } catch (e: ParseException) {
    if (attempt >= 4) throw e
    val wait = (1L shl attempt) * 500 + Random.nextLong(200)
    delay(wait)                                 // exponential + jitter
    withBackoff(attempt + 1, fn)
  }
}
val results = withBackoff { query.find() }

토큰 버킷 vs. 리키 버킷 vs. 고정 윈도우 vs. 슬라이딩 윈도우

다이어그램이 건너뛰는 분산 환경의 각주가 하나 있습니다. API 서버가 여러 대라면 버킷은 공유된 어딘가, 보통 원자적 증가 연산을 수행하는 인메모리 저장소에 있어야 하며, 엄격한 정확도(모든 검사가 저장소를 거침)와 속도(로컬 카운터, 느슨한 동기화) 중 하나를 선택해야 합니다. 대부분의 플랫폼은 지연 시간을 지키는 대가로 약간 느슨한 제한을 받아들이고, 계약상의 할당량에만 엄격한 처리를 적용합니다.

범위 지정: 정확히 누구를 제한할까?

IP별 제한은 익명 트래픽 폭주와 DDoS 흡수 과정에서 새어 나오는 트래픽을 막지만, 사무실 NAT 뒤에서는 수백 명의 사용자가 주소 하나가 됩니다. 키별 제한은 제한을 애플리케이션과 요금제에 대응시키며, 가장 많이 쓰이는 범위입니다. 사용자별 제한은 계정 하나가 공유 앱의 키를 독점하지 못하게 합니다. 엔드포인트별 제한은 비싼 작업에 그 비용에 걸맞은 한도를 매깁니다. 검색과 내보내기 엔드포인트는 헬스 체크보다 빠듯한 예산을 받아야 합니다. 프로덕션 시스템은 이 범위들을 겹쳐 쓰며, 종합적인 질문은 언제나 “이 요청은 어느 예산을 소비했는가?”입니다.

일반적인 사용 사례

• 공개 API 보호 – 정석적인 사례입니다. 키별로 공정한 예산을 두고, 헤더로 공개하고, 엣지에서 강제합니다.
• 요금제 등급 강제 – 무료 요금제와 유료 요금제는 정확히 할당량과 버스트 허용량에서 차이가 납니다.
• 남용과 스크래핑 방어 – 익명 요청에는 빠듯한 제한을, 인증된 요청에는 넉넉한 제한을 둡니다.
• 비싼 경로의 비용 통제 – LLM 호출, 내보내기, 검색. 실제 비용을 반영한 엔드포인트별 예산입니다.
• 클라이언트 측 자기 방어 – 다른 서비스의 제한에 맞춘 백오프와 요청 병합입니다. 차단당하지 않으려면 연동 코드가 그 제한을 지켜야 합니다.

거부할까, 스로틀링할까? 결정 매트릭스

그리고 메타 규칙이 하나 있습니다. 무엇을 선택하든 공개해야 합니다. 문서와 헤더에 명시된 제한은 답답한 벽을, 클라이언트가 그에 맞춰 개발할 수 있는 엔지니어링 계약으로 바꿉니다.

한계와 트레이드오프

• 제한은 무딘 도구입니다. 요청 하나는 비용 단위가 아닙니다. 값싼 읽기 하나와 거대한 내보내기 하나가 똑같이 “1”을 소비합니다. 비용 인지형 제한(작업당 포인트)이 개선책이지만, 복잡성이라는 대가가 따릅니다.
• 분산 환경의 정확도는 지연 시간을 대가로 치릅니다. 엄격한 전역 카운터는 공유 저장소에서 직렬화되고, 느슨한 로컬 카운터는 경계에서 허용치보다 많이 받아들입니다. 유행이 아니라 필요한 보장 수준에 따라 선택해야 합니다.
• 429는 무고한 재시도 루프를 벌합니다. 지터가 없는 클라이언트는 서로 동기화되어 썬더링 허드가 됩니다. 제한기 설계는 최악의 클라이언트를 가정해야 합니다. 언젠가는 반드시 그런 클라이언트를 만나기 때문입니다.
• 스로틀링은 과부하를 숨깁니다. 큐에 들어간 요청은 그래프를 매끄럽게 만들면서 보이지 않는 백로그를 쌓습니다. 큐에는 상한과 부하 차단 정책이 필요하며, 그렇지 않으면 큐 자체가 장애 수준의 지연이 됩니다.
• 제한은 운영 설정처럼 보이지만 실은 제품 결정입니다. 예산, 요금제 등급, 버스트 허용량은 사용자 경험과 매출을 좌우합니다. 대시보드만 보지 말고 요금 페이지를 열어 둔 채 설정해야 합니다.

Back4app에서의 속도 제한

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 보호는 별도로 진행할 프로젝트가 아니라 플랫폼의 기본값입니다. 속도 제한은 엣지에서 앱과 요금제별로 적용되고, 비싼 작업은 자체 검사를 갖춘 Cloud Code 함수 뒤에 둘 수 있으며, 클라이언트는 의미가 명확한 429 응답을 받습니다. 위 코드 탭의 SDK 측 백오프 패턴은 이를 실패한 화면이 아니라 복원력 있는 동작으로 바꿉니다. 사용자는 정책을 조정할 뿐, 제한기를 직접 만들지 않습니다.