API 속도 제한

속도 제한은 여러 알고리즘을 통해 구현되며, 각 알고리즘은 서로 다른 장단점을 가집니다. Fixed Window (고정 창): 정의된 시간 창(예: 시간당 1,000개 요청)당 요청 수를 계산합니다. 간단하지만 창 경계에서 트래픽이 폭증할 경우 취약합니다. Sliding Window (슬라이딩 창): 롤링 시간 창(예: 60분 동안 1,000개 요청)을 사용하여 경계 폭증을 제거합니다. Token Bucket (토큰 버킷): 고객은 최대치까지 꾸준한 속도로 '토큰'을 축적하며, 각 요청은 하나의 토큰을 소모합니다. 버킷 크기까지의 버스트 트래픽을 허용하면서 지속적인 평균 제한을 적용합니다. 이는 실제 사용 패턴과 가장 유사합니다. Leaky Bucket (리키 버킷): 고정된 속도로 요청을 처리하고 초과 요청을 대기열에 넣습니다. 트래픽을 완전히 평활화하지만 버스트 시 지연 시간을 유발합니다. 대부분의 SaaS 플랫폼은 Token Bucket 또는 Sliding Window를 사용하는데, 이는 합법적인 버스트 사용 패턴에 대한 유연성과 지속적인 남용 또는 폭주하는 코드로부터의 보호 사이의 균형을 맞추기 때문입니다.

속도 제한 오류(HTTP 429 "Too Many Requests")는 예상된 API 동작이 아닌 버그로 잘못 진단되는 경우가 많습니다. 지원팀은 다음을 수행해야 합니다. 첫째, 고객이 실제로 요금제 속도 제한을 초과하고 있는지 확인합니다(관리 대시보드에서 API 사용량 데이터 확인). 둘째, 429 응답 및 'retry-after' 헤더에 대해 교육합니다(API 응답에는 다음 요청이 허용될 때까지의 시간이 포함됩니다. 올바른 클라이언트는 429를 수신할 때 즉시 재시도하는 대신 exponential backoff를 구현해야 합니다). 셋째, 고객의 구현이 속도 제한을 올바르게 처리하고 있는지 조사합니다(많은 통합 버그는 속도 제한 문제를 악화시키는 무한 재시도 루프에서 발생합니다). 넷째, 고객이 더 높은 속도 제한에 대한 합법적인 필요가 있는지 판단합니다(더 높은 처리량을 요구하는 엔터프라이즈 고객은 맞춤형 제한 또는 요금제 업그레이드를 정당화할 수 있습니다). 마지막으로, 요금제 수준의 제한이 적절한지 또는 조정이 필요한지 판단하기 위해 속도 제한 관련 질문을 체계적으로 문서화해야 합니다.

속도 제한은 단순한 기술적 제약이 아니라 제품 설계 및 상업적 결정입니다. Product Ops는 속도 제한이 다음을 보장해야 합니다. 첫째, 공개 API 참조에 명시적으로 문서화되어야 합니다(전역 제한뿐만 아니라 엔드포인트별 제한 포함). 둘째, 가격 책정 계층별로 차등화되어야 합니다(더 높은 요금제 고객은 더 높은 제한을 받습니다. 이는 업그레이드에 대한 구체적이고 실질적인 이점을 창출합니다). 셋째, 제품 내 사용량 대시보드를 통해 실시간으로 표시되어야 합니다(고객은 한도에 도달하기 전에 경고와 함께 현재 사용량을 확인할 수 있어야 합니다). 넷째, 명확한 업그레이드 경로가 동반되어야 합니다(고객이 속도 제한의 80%에 도달했을 때 트리거되는 배너 또는 이메일은 단순히 429 오류로 실패하는 대신 업그레이드를 안내합니다). 속도 제한 기반 업그레이드는 Product Ops가 다른 확장 트리거와 함께 추적하는 측정 가능한 확장 수익 동인입니다.