속도 제한 (Rate limit)은 단순한 API 오류가 아닙니다.

그것은 종종 AI 제품이 어떤 사용자와 워크플로우를 가장 가치 있게 여기는지 드러내는 순간입니다.

이런 상황을 상상해 보세요:

백그라운드 작업이 수천 개의 문서를 요약하기 시작합니다.

동시에 고객이 지원 채팅(support chat)을 엽니다.

두 워크플로우 모두 동일한 모델 제공자 (model provider)를 사용합니다. 두 작업 모두 동일한 토큰 풀 (token pool)에 접근합니다. 배치 작업 (batch job)은 단순히 먼저 시작되었다는 이유만으로 승리합니다.

챗봇은 느려집니다. 재시도 (Retries)가 시작됩니다. 대기 시간 (Queue time)이 증가합니다. 필요한 JSON을 반환할 수 있는지 또는 동일한 도구 (tools)를 사용할 수 있는지 확인하지 않은 채 폴백 모델 (fallback model)이 선택됩니다.

기술적으로는 아무것도 다운되지 않았습니다.

하지만 제품 경험 (product experience)은 이미 망가졌습니다.

이것이 바로 속도 제한 (rate limits)이 제공자 (provider)의 문제일 뿐만 아니라 제품 (product)의 문제인 이유입니다.

재시도는 속도 제한 전략이 아니다

기본적인 구현 방식은 익숙합니다:

1. 요청을 보냅니다.
2. 429 오류를 받습니다.
3. 기다립니다.
4. 재시도합니다.

스크립트라면 괜찮습니다.

하지만 프로덕션 AI 애플리케이션 (production AI application)에서 맹목적인 재시도는 문제를 악화시킬 수 있습니다. 재시도는 과부하된 경로 (route)에 더 많은 트래픽을 추가하고, 압박의 실제 근원을 숨기며, 가장 중요한 요청을 지연시킵니다.

더 나은 질문은 이것입니다:

수요가 경로의 제한을 초과할 때, 어떤 워크플로우가 먼저 용량 (capacity)을 할당받아야 하는가?

그 답은 제품마다 다릅니다.

고객 대상 챗봇, RAG 답변, 에이전트 실행 (agent run), 그리고 야간 배치 작업 (nightly batch job)은 동등한 자격으로 경쟁해서는 안 됩니다.

각 워크플로우에 우선순위를 부여하라

멀티 모델 애플리케이션 (Multi-model applications)은 라우팅 정책 (routing policies) 외에도 트래픽 정책 (traffic policies)이 필요합니다.

예를 들어:

const workflowPolicies = {
  support_chat: {
    priority: "high",
...