# 처리량 제한 (Rate Limit)

RTZR STT OpenAPI는 일반적인 시간 기반의 Rate Limit(예: 초당 요청 수) 대신, 동시 처리량을 기준으로 서비스 사용을 제어합니다. 이는 음성인식 서비스의 특성을 고려한 것으로, [파일 방식](/docs/stt-file.md)과 [스트리밍 방식](/docs/stt-streaming.md)에 따라 각기 다른 제한 정책이 적용됩니다. 모든 제한은 계정(organization) 단위로 적용됩니다.

## [파일 방식 STT](/docs/stt-file.md): 동시처리제한[​](#file-stt-concurrency-limit "file-stt-concurrency-limit에 대한 직접 링크")

파일 방식 STT는 \*\*동시처리제한 (max concurrency limit)\*\*의 영향을 받습니다. 동시처리제한은 **동시에 음성인식을 처리할 수 있는 파일의 최대 개수**를 의미합니다.

예를 들어, 동시처리제한이 10으로 설정된 경우, 최대 10개의 파일을 동시에 처리할 수 있습니다. 11번째 파일을 요청하면, 현재 처리 중인 10개의 파일 중 하나가 완료될 때까지 해당 요청은 대기 상태가 되거나, 시스템 정책에 따라 에러가 반환될 수 있습니다.

### 제한 초과 시 응답[​](#response-when-exceeding-the-limit "제한 초과 시 응답에 대한 직접 링크")

동시처리제한을 초과하여 요청하면 API는 HTTP `429 Too Many Requests` 상태 코드와 함께 다음과 같은 에러 메시지를 반환합니다.

```json
{
  "code": "A0002",
  "msg": "Too many concurrent requests"
}

```

## [스트리밍 방식 STT](/docs/stt-streaming.md): 동시채널제한[​](#streaming-stt-concurrent-channel-limit "streaming-stt-concurrent-channel-limit에 대한 직접 링크")

스트리밍 방식 STT는 \*\*동시채널제한 (max channel limit)\*\*의 영향을 받습니다. 동시채널제한은 **동시에 연결할 수 있는 스트리밍 채널(세션)의 최대 개수**를 의미합니다.

예를 들어, 동시채널제한이 5로 설정된 경우, 최대 5개의 스트리밍 연결을 동시에 유지할 수 있습니다. 6번째 연결을 시도하면, 연결이 거부되거나 에러가 발생합니다.

## 등급별 처리량 제한[​](#limits-by-plan "등급별 처리량 제한에 대한 직접 링크")

### 일반 STT (파일 방식)[​](#batch-stt-file-mode "일반 STT (파일 방식)에 대한 직접 링크")

일반 STT의 동시처리제한은 모델별로 차등 적용됩니다.

| 사용자 등급             | [`sommers` 모델](/docs/stt-file/model.md) | [`whisper` 모델](/docs/stt-file/model.md) |
| ----------------------- | ----------------------------------------- | ----------------------------------------- |
| **가입 후 무료 사용자** | 10                                        | 2                                         |
| **유료 사용자 (Basic)** | 20                                        | 5                                         |
| **Enterprise**          | 별도 협의                                 | 별도 협의                                 |

### 스트리밍 STT[​](#streaming-stt "스트리밍 STT에 대한 직접 링크")

스트리밍 STT의 동시채널제한은 다음과 같습니다.

| 사용자 등급             | 동시채널제한 |
| ----------------------- | ------------ |
| **가입 후 무료 사용자** | 5            |
| **유료 사용자 (Basic)** | 20           |
| **Enterprise**          | 별도 협의    |

팁

Enterprise 등급의 경우, [요금제 페이지](/docs/pricing.md#plans)를 참고하시거나 별도 문의를 통해 최적의 처리량 제한을 협의하여 제공합니다.

## 처리량 제한 관리 및 모범 사례[​](#managing-limits-and-best-practices "처리량 제한 관리 및 모범 사례에 대한 직접 링크")

안정적인 서비스 운영을 위해 다음과 같은 방법을 고려해 보세요.

### 지수 백오프 (Exponential Backoff)[​](#exponential-backoff "지수 백오프 (Exponential Backoff)에 대한 직접 링크")

제한 초과(`429` 오류) 또는 일시적인 네트워크 문제로 요청이 실패했을 때, 즉시 재시도하면 실패가 반복될 수 있습니다. **지수 백오프**는 재시도 간격을 점차 늘려가며 API에 가해지는 부하를 줄이는 효과적인 전략입니다.

**기본 로직:**

1. 요청이 실패하면, 짧은 시간(예: 1초)을 기다린 후 재시도합니다.
2. 또다시 실패하면, 대기 시간을 2배(예: 2초, 4초, 8초...)로 늘려가며 재시도합니다.
3. 최대 재시도 횟수나 최대 대기 시간에 도달하면 요청을 최종 실패로 처리합니다.

### 클라이언트 측 큐 (Client-Side Queue)[​](#client-side-queue "클라이언트 측 큐 (Client-Side Queue)에 대한 직접 링크")

한 번에 많은 파일을 처리해야 하는 경우, 모든 파일을 동시에 요청하면 동시처리제한에 쉽게 도달할 수 있습니다. 애플리케이션에서 자체적으로 **요청 큐**를 구현하여, 한 번에 동시처리제한 만큼의 파일만 요청하고 이전 요청이 완료될 때마다 큐에서 다음 파일을 가져와 처리하는 방식으로 안정성을 높일 수 있습니다.