LLM Gateway 설계: 라우팅, Rate Limiting, Fallback 전략

LLM Gateway는 애플리케이션과 LLM 프로바이더 사이에 위치하는 프록시 계층입니다. API 키 관리, 멀티 프로바이더 라우팅, Rate Limiting, Fallback, 비용 추적, 로깅을 한 곳에서 처리하여 각 서비스가 이 로직을 중복 구현하지 않도록 합니다.

결론 아키텍처와 선택 이유

LLM Gateway를 도입하는 핵심 이유는 프로바이더 장애 시 자동 전환, 팀별 비용 통제, 통합 Observability 세 가지입니다.

설계 축	권장 접근	이유
라우팅 전략	비용 우선 → 지연 시간 우선 혼합	일반 요청은 저비용 모델로, 품질 민감 요청은 고성능 모델로 분리
Rate Limiting	TPM(토큰/분) + RPM(요청/분) 이중 제한	프로바이더 한도 초과 방지 + 내부 팀별 예산 통제
Fallback	Primary → Secondary → Degraded 3단계	단일 프로바이더 장애에도 서비스 연속성 유지
배포 형태	Kubernetes ClusterIP Service	내부 트래픽 전용, 외부 노출 불필요

---

1. 이 시스템이 실제 운영에서 필요한 상황

3개의 백엔드 서비스가 각각 OpenAI API를 직접 호출하는 환경을 가정합니다. 어느 날 OpenAI가 Rate Limit 429 응답을 반환하기 시작합니다.

서비스 A는 지수 백오프를 구현해 두었지만, 서비스 B는 단순 재시도만 있고, 서비스 C는 에러 핸들링 자체가 없습니다. 결과적으로 3개 서비스의 장애 대응 수준이 제각각이 되고, 장애 원인을 파악하려면 3개 서비스의 로그를 각각 확인해야 합니다.

이 상황에서 LLM Gateway가 해결하는 문제:

• 통일된 장애 대응: 모든 LLM 호출이 Gateway를 경유하므로 재시도, Fallback, Circuit Breaker 로직을 한 곳에서 관리
• API 키 중앙 관리: 각 서비스에 프로바이더 키를 배포하지 않음. Gateway만 실제 키를 보유하고, 서비스에는 가상 키(virtual key) 발급
• 비용 가시성: 팀별, 서비스별, 모델별 토큰 사용량과 비용을 단일 대시보드에서 확인
• 프로바이더 교체 용이성: 새 모델 추가나 프로바이더 변경 시 Gateway 설정만 수정하면 되고, 각 서비스 코드는 변경 불필요

---

2. LLM Gateway 기본 아키텍처

LLM Gateway 아키텍처

2.1 요청 처리 흐름

1. 인증(Auth): 가상 키 검증 → 팀/서비스 식별
2. 검증(Validate): 요청 형식 확인, 입력 토큰 수 사전 계산
3. Rate Limit 확인: TPM/RPM 한도 내인지 확인. 초과 시 429 반환 또는 큐잉
4. 라우팅(Route): 라우팅 전략에 따라 대상 프로바이더/모델 결정
5. Circuit Breaker 확인: 대상 프로바이더가 healthy 상태인지 확인
6. 요청 전송: 프로바이더 API 호출
7. Fallback: 실패 시 대체 프로바이더로 재시도
8. 응답 반환 + 로깅: 토큰 사용량, 지연 시간, 비용 기록

---

3. 라우팅 전략

3.1 라우팅 방식 비교

라우팅 전략	동작 방식	적합한 상황
Round Robin	등록된 프로바이더에 순차 분배	동일 모델의 여러 API 키 부하 분산
Least Latency	최근 응답 시간이 가장 짧은 프로바이더 선택	지연 시간 민감 서비스 (채팅, 실시간 응답)
Cost-based	토큰 단가가 낮은 프로바이더 우선	비용 최적화 우선, 품질 차이 허용 가능한 배치 작업
Content-based	요청 내용(모델명, 태그, 메타데이터)에 따라 분기	복잡도별 모델 분리 (단순 분류 → 소형 모델, 추론 → 대형 모델)
Weighted	가중치 비율로 분배 (예: OpenAI 70%, Anthropic 30%)	A/B 테스트, 점진적 마이그레이션

3.2 Content-based 라우팅 실무 예시

복잡도에 따라 모델을 분리하는 패턴은 비용 절감 효과가 큽니다.

# LiteLLM proxy config 예시
model_list:
  - model_name: "fast"          # 단순 분류, 요약, 추출
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: "balanced"      # 일반 대화, 코드 생성
    litellm_params:
      model: anthropic/claude-sonnet-4
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: "powerful"      # 복잡한 추론, 분석
    litellm_params:
      model: anthropic/claude-opus-4
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  routing_strategy: "simple-shuffle"  # 같은 model_name 내 여러 deployment 간 분배
  num_retries: 2
  timeout: 120

애플리케이션 코드에서는 요청 복잡도에 따라 model 파라미터만 변경합니다:

import openai

client = openai.OpenAI(
    base_url="http://llm-gateway.internal:4000",  # Gateway 엔드포인트
    api_key="sk-virtual-team-a-key"                # 가상 키
)

# 단순 분류 작업 → 저비용 모델
response = client.chat.completions.create(
    model="fast",
    messages=[{"role": "user", "content": "이 문장의 감정을 분류해줘: ..."}]
)

# 복잡한 분석 → 고성능 모델
response = client.chat.completions.create(
    model="powerful",
    messages=[{"role": "user", "content": "이 코드의 보안 취약점을 분석하고..."}]
)

3.3 라우팅 전략 선택 기준

요청 지연 시간이 중요한가?
  ├── Yes → Least Latency
  └── No → 비용이 중요한가?
              ├── Yes → Cost-based 또는 Content-based
              └── No → 안정성이 중요한가?
                          ├── Yes → Weighted (멀티 프로바이더 분산)
                          └── No → Round Robin

---

4. Rate Limiting 설계

4.1 왜 Gateway 레벨 Rate Limiting이 필요한가

LLM 프로바이더는 계정 단위로 Rate Limit을 적용합니다. 예를 들어 OpenAI Tier 1 계정의 GPT-4o 한도는 500 RPM, 30,000 TPM입니다.

여러 서비스가 하나의 계정을 공유하면, 서비스 A의 버스트 트래픽이 서비스 B와 C의 가용 한도를 잠식합니다. Gateway에서 서비스별/팀별 한도를 사전에 분배하면 이 문제를 방지할 수 있습니다. 이 수치는 OpenAI 공식 Rate Limits 페이지 기준이며, Tier 업그레이드(사용 금액 누적)에 따라 한도가 증가합니다.

4.2 Rate Limiting 계층 구조

계층	적용 대상	측정 단위	목적
프로바이더 한도	계정 전체	RPM, TPM (프로바이더가 결정)	프로바이더 429 방지
팀 한도	팀/프로젝트	TPM, 월간 예산($)	비용 통제, 공정 분배
서비스 한도	개별 서비스	RPM, TPM	버스트 방지, 안정성
사용자 한도	최종 사용자	RPM	남용 방지

4.3 Token Bucket 기반 Rate Limiting 구현

LLM Rate Limiting은 일반 API와 다른 점이 있습니다. 요청 크기가 토큰 수에 따라 크게 다르므로, 단순 RPM만으로는 부족합니다.

# LiteLLM Rate Limiting 설정 예시
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

# 가상 키별 한도 설정 (API 또는 UI에서 관리)
# POST /key/generate
# {
#   "key_alias": "team-a-key",
#   "max_budget": 500,           # 월 $500 한도
#   "tpm_limit": 100000,         # 분당 100,000 토큰
#   "rpm_limit": 200,            # 분당 200 요청
#   "budget_duration": "1mo"     # 월간 리셋
# }

4.4 Rate Limiting 설정값 가이드

항목	기본값	권장값	조정 조건	잘못 설정 시 증상
팀 TPM	제한 없음	프로바이더 한도의 50~70%	팀이 1개뿐이면 80%까지 가능	여러 팀이 동시 사용 시 429 발생
서비스 RPM	제한 없음	60~120 RPM	실시간 채팅은 높게, 배치는 낮게	버스트 시 프로바이더 Rate Limit 도달
월간 예산	제한 없음	팀 AI 예산의 80% (버퍼 20%)	시즌별 사용량 패턴에 따라 조정	예산 초과 시 서비스 중단 또는 예상 외 청구
요청 타임아웃	600초 (LiteLLM 기본)	30~120초	Streaming은 120초, 단순 호출은 30초	너무 짧으면 긴 응답 생성 실패, 너무 길면 리소스 점유

4.5 프로바이더 한도 초과 시 처리 전략

프로바이더가 429를 반환했을 때 Gateway가 취할 수 있는 행동:

전략	설명	trade-off
지수 백오프 재시도	1초 → 2초 → 4초 간격으로 재시도	지연 증가. 사용자 체감 응답 시간 저하
Fallback 프로바이더 전환	다른 프로바이더의 동급 모델로 즉시 전환	응답 품질 차이 가능. 비용 증가 가능
요청 큐잉	Rate Limit 해제까지 큐에 대기	배치 작업에 적합. 실시간 요청에는 부적합
즉시 거부 (429 반환)	클라이언트에 바로 429 전달	가장 빠르지만 서비스 품질 저하

운영 환경에서는 요청 유형에 따라 조합합니다:

• 실시간 채팅 → Fallback 전환 (사용자 대기 불가)
• 배치 처리 → 큐잉 (시간 여유 있음, 비용 절약)
• 내부 분석 → 즉시 거부 + 재스케줄링 (우선순위 낮음)

---

5. Fallback 전략

5.1 Fallback Chain 설계

Fallback은 "Primary가 실패하면 Secondary로, Secondary도 실패하면 Degraded 모드로" 이어지는 체인입니다.

# LiteLLM Fallback 설정
model_list:
  - model_name: "default"
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  - model_name: "default"        # 같은 model_name에 여러 deployment
    litellm_params:
      model: anthropic/claude-sonnet-4
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: "fallback-cheap"
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

router_settings:
  routing_strategy: "latency-based-routing"
  num_retries: 2
  timeout: 60
  fallbacks:
    - {"default": ["fallback-cheap"]}    # default 그룹 실패 시 fallback-cheap으로
  allowed_fails: 3           # 3회 연속 실패 시 cooldown
  cooldown_time: 60          # 60초간 해당 deployment 제외

5.2 Circuit Breaker 패턴

Circuit Breaker는 프로바이더가 비정상 상태일 때 즉시 감지하고 트래픽을 차단하여, 불필요한 재시도로 지연이 누적되는 것을 방지합니다.

상태	조건	동작
Closed (정상)	에러율 < 임계값	정상 라우팅
Open (차단)	연속 N회 실패 또는 에러율 > 임계값	해당 프로바이더로 요청 차단, 즉시 Fallback
Half-Open (검증)	cooldown 시간 경과	소량 요청으로 복구 확인

[정상 상태]
     │
     │  연속 3회 실패 (allowed_fails: 3)
     ▼
[Open: 60초 cooldown]
     │
     │  60초 경과
     ▼
[Half-Open: 1개 요청 시도]
     │
     ├── 성공 → [Closed: 정상 복귀]
     └── 실패 → [Open: cooldown 재시작]

5.3 Fallback 설정값 가이드

항목	기본값 (LiteLLM)	권장값	조정 조건	잘못 설정 시 증상
num_retries	0	2	네트워크 불안정 환경이면 3. Streaming이면 1	0이면 일시적 에러에도 즉시 실패. 5 이상이면 지연 누적
timeout	600초	60초	긴 응답 생성 (코드 생성 등)은 120초	너무 짧으면 정상 응답도 타임아웃 처리
allowed_fails	0 (비활성)	3	프로바이더 불안정 빈도에 따라 조정	1이면 일시적 에러에도 즉시 cooldown → 가용 deployment 감소
cooldown_time	60초	60초	프로바이더 복구 시간에 따라. Rate Limit은 60초, 장애는 300초	너무 짧으면 복구 전에 재시도 → 연속 실패. 너무 길면 복구 후에도 미사용

5.4 Fallback 시 품질 관리

Fallback 모델이 Primary와 성능 차이가 크면 서비스 품질이 급격히 떨어질 수 있습니다.

Fallback 단계	모델 예시	품질 영향	대응
Primary	Claude Opus 4 / GPT-4o	기준 품질	-
Secondary (동급)	GPT-4o → Claude Sonnet 4	미미한 차이	별도 대응 불필요
Degraded (저급)	→ GPT-4o-mini	복잡한 추론 품질 저하	응답에 "품질 제한 모드" 메타데이터 첨부
Emergency (캐시)	Semantic Cache 반환	유사 질문의 과거 응답	새로운 질문에는 부적합

Degraded 모드 진입 시 애플리케이션이 인지할 수 있도록 응답 헤더에 메타데이터를 추가하는 것을 권장합니다:

{
  "x-llm-gateway-model": "gpt-4o-mini",
  "x-llm-gateway-fallback": true,
  "x-llm-gateway-fallback-reason": "primary_rate_limited"
}

---

6. 규모별로 달라지는 설계

규모	기준	설계	추가 필요 도구/프로세스
소규모	서비스 1~3개, 요청 < 100 RPM, 팀 1~5명	단일 Gateway 인스턴스, 1개 프로바이더 + 1개 Fallback, 설정 파일 기반 관리	LiteLLM 단일 인스턴스, SQLite 또는 파일 기반 사용량 추적
중규모	서비스 5~20개, 요청 100~1,000 RPM, 팀 5~20명	Gateway HA 구성 (2~3 replicas), Redis 기반 Rate Limiting, 팀별 가상 키 분리, DB 기반 사용량 추적	LiteLLM + PostgreSQL + Redis, Grafana 대시보드, PagerDuty 알림
대규모	서비스 30개+, 요청 1,000+ RPM, 팀 20명+	Gateway 클러스터 (HPA 기반 오토스케일링), 리전별 배포, 중앙 정책 관리 + 로컬 캐시, 전용 Observability 파이프라인	Kubernetes HPA, Redis Cluster, 전용 비용 거버넌스 도구, 승인 기반 예산 변경 프로세스

소규모에서 시작할 때

# 최소 구성: LiteLLM + 1 Primary + 1 Fallback
model_list:
  - model_name: "default"
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY

  - model_name: "fallback"
    litellm_params:
      model: anthropic/claude-haiku-4
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  num_retries: 2
  timeout: 60
  fallbacks:
    - {"default": ["fallback"]}

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

소규모에서는 이 설정만으로 충분합니다. Redis 없이 in-memory Rate Limiting을 사용하고, 사용량은 SQLite에 기록합니다.

중규모로 전환 시 추가되는 것

• Redis 추가: Rate Limiting 카운터를 여러 Gateway 인스턴스가 공유
• PostgreSQL 추가: 사용량, 가상 키, 팀 정보를 영속적으로 관리
• Gateway 복제: 단일 장애점 제거 (최소 2 replica)
• 팀별 가상 키: 팀 A는 월 $500, 팀 B는 월 $1,000처럼 예산 분리

대규모에서 추가로 고려하는 것

• HPA 기반 스케일링: Gateway Pod의 CPU 또는 요청 큐 길이 기준으로 수평 확장
• 리전별 배포: 지연 시간 최소화. 각 리전의 Gateway가 가장 가까운 프로바이더 엔드포인트를 사용
• 정책 중앙 관리: 설정 변경이 Git PR → Review → 자동 배포 파이프라인을 통해 이루어짐
• 비용 거버넌스 연동: 팀별 예산 초과 시 자동 알림 + 승인 없이는 한도 증가 불가

---

7. 장애 모드(Failure Modes)

7.1 LLM Gateway에서 발생하는 주요 장애

장애 모드	증상	원인	탐지 방법
프로바이더 Rate Limit 도달	429 에러 급증, 응답 지연 증가	트래픽 급증 또는 한도 미설정	llm_gateway_provider_429_total 메트릭
프로바이더 장애	5xx 에러, 타임아웃	프로바이더 인프라 문제	llm_gateway_provider_error_rate > 50%
Gateway 자체 과부하	모든 요청 지연, 큐 적체	Gateway Pod CPU/메모리 부족	Pod CPU > 80%, 요청 큐 길이 증가
Rate Limiter 장애 (Redis 다운)	Rate Limiting 미적용 또는 모든 요청 거부	Redis 연결 실패	Redis health check 실패
Fallback 연쇄 실패	모든 프로바이더 응답 불가	복수 프로바이더 동시 장애	모든 Circuit Breaker Open 상태
비용 폭주	일간/월간 예산 급속 소진	Prompt Injection으로 대량 토큰 생성, 무한 루프	시간당 비용 증가율 임계값 초과

7.2 장애 시나리오별 확인 절차

시나리오: 프로바이더 Rate Limit 도달

# LiteLLM 로그에서 429 확인
$ kubectl logs -l app=litellm-proxy --tail=100 | grep "429"
[2026-06-11 14:23:01] ERROR - openai.RateLimitError: Error code: 429 - Rate limit reached for gpt-4o
  model_group=default, deployment=openai/gpt-4o
  Fallback triggered: routing to anthropic/claude-sonnet-4

판독: Fallback triggered가 보이면 자동 전환이 정상 동작 중입니다. 반복적으로 나타나면 해당 프로바이더의 RPM/TPM 한도를 확인하고, Gateway 측 Rate Limiting을 프로바이더 한도 이하로 조정해야 합니다.

시나리오: Redis 다운으로 Rate Limiter 장애

$ kubectl logs -l app=litellm-proxy --tail=50 | grep -i "redis"
[2026-06-11 14:25:00] WARNING - Redis connection failed. Falling back to in-memory rate limiting.
[2026-06-11 14:25:01] WARNING - In-memory rate limits are per-pod only. 
  Cluster-wide limits not enforced.

판독: Redis 장애 시 LiteLLM은 in-memory 모드로 전환됩니다. 이 상태에서는 Pod별로 독립적으로 Rate Limiting이 적용되므로, 전체 클러스터 합산 한도가 초과될 수 있습니다. Redis 복구가 우선입니다.

---

8. Observability

8.1 모니터링해야 할 핵심 메트릭

메트릭	정상 범위	경고 임계값	위험 임계값	의미
llm_request_duration_seconds (p50)	1~5초	> 10초	> 30초	사용자 체감 응답 시간
llm_request_duration_seconds (p99)	5~15초	> 30초	> 60초	최악 경우 지연
llm_provider_error_rate	< 1%	> 5%	> 20%	프로바이더 건강 상태
llm_fallback_triggered_total (rate/5m)	0~2회	> 10회/5분	> 50회/5분	Fallback 빈도 — 높으면 Primary 불안정
llm_tokens_used_total (팀별, 시간별)	예산 내	일간 예산 70% 도달	일간 예산 90% 도달	비용 소진 속도
llm_circuit_breaker_open	0	1 (단일 프로바이더)	2+ (복수 프로바이더)	사용 가능한 프로바이더 감소
llm_rate_limit_rejected_total	0	> 10회/분	> 100회/분	내부 Rate Limit으로 거부된 요청

8.2 알림 설정 예시

# Prometheus alerting rules
groups:
  - name: llm-gateway
    rules:
      - alert: LLMGatewayHighErrorRate
        expr: |
          sum(rate(llm_provider_errors_total[5m])) 
          / sum(rate(llm_requests_total[5m])) > 0.05
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "LLM Gateway 에러율 5% 초과"
          description: "최근 5분간 프로바이더 에러율이 {{ $value | humanizePercentage }}입니다."

      - alert: LLMGatewayAllCircuitBreakersOpen
        expr: sum(llm_circuit_breaker_open) == count(llm_circuit_breaker_open)
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "모든 LLM 프로바이더 Circuit Breaker Open"
          description: "모든 프로바이더가 비정상 상태입니다. Fallback 불가."

      - alert: LLMGatewayBudgetNearLimit
        expr: |
          llm_team_spend_current / llm_team_budget_limit > 0.9
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "팀 {{ $labels.team }} AI 예산 90% 소진"

for: 3m 근거: LLM 프로바이더의 일시적 에러(네트워크 지터, 순간 Rate Limit)는 1~2분 내에 자연 복구되는 경우가 많습니다. 3분 지속이면 일시적 현상이 아닌 실제 문제로 판단합니다.

8.3 대시보드에서 확인할 패턴

패턴	시각적 특징	의미	조치
지연 시간 계단식 증가	평탄 → 급상승 → 유지	프로바이더 처리량 포화	Fallback 확인, 트래픽 분산
Fallback 스파이크	fallback_triggered 급증	Primary 불안정	Primary 프로바이더 상태 페이지 확인
비용 직선 상승	일간 비용 그래프가 급경사	비정상 사용 (루프, Prompt Injection)	해당 가상 키 일시 차단, 로그 확인
429 주기적 발생	매 정시에 429 스파이크	Cron 배치와 실시간 트래픽 충돌	배치 전용 한도 분리 또는 시간대 조정

---

9. 운영 절차

9.1 즉시 대응 (Mitigation)

상황	즉시 조치	명령어/절차
특정 프로바이더 장애	해당 프로바이더 수동 cooldown	LiteLLM Admin UI에서 deployment 비활성화 또는 cooldown_time 증가
비용 폭주	해당 팀 가상 키 일시 차단	POST /key/block {"key": "sk-team-x-key"}
Gateway 과부하	Pod 수동 스케일업	kubectl scale deployment litellm-proxy --replicas=5
Redis 다운	Redis 복구 우선. 임시로 in-memory 모드 허용	Redis Pod 재시작 또는 Failover 확인

9.2 근본 수정 (Root Fix)

상황	근본 수정
Rate Limit 도달 반복	프로바이더 Tier 업그레이드 요청, 또는 프로바이더 추가 (부하 분산)
특정 팀 과다 사용	팀과 협의하여 예산/한도 조정. 불필요 호출 패턴 확인
Gateway 과부하 반복	HPA 설정 검토. CPU 임계값 또는 요청 큐 기준 스케일링 조건 추가
Fallback 품질 불만	Fallback 모델을 더 높은 성능 모델로 교체, 또는 Primary 프로바이더 추가

9.3 롤백 방법

Gateway 설정 변경 후 문제가 생겼을 때:

# 설정 파일이 Git 관리 되는 경우
git revert HEAD
kubectl rollout restart deployment litellm-proxy

# ConfigMap 기반 배포인 경우
kubectl rollout undo deployment litellm-proxy

# 특정 리비전으로 복구
kubectl rollout history deployment litellm-proxy
kubectl rollout undo deployment litellm-proxy --to-revision=3

9.4 변경 관리

변경 유형	승인 필요	영향 범위
새 모델/프로바이더 추가	팀 리드	해당 모델 사용 서비스
Rate Limit 한도 변경	플랫폼 팀	해당 팀의 모든 서비스
Fallback 체인 변경	플랫폼 팀 + 서비스 팀	장애 시 전체 서비스
Gateway 스케일링 정책 변경	인프라 팀	전체 LLM 트래픽
월간 예산 증액	매니저 + 재무	비용

9.5 소유권

구성 요소	소유 팀	책임
Gateway 인프라 (Pod, Redis, DB)	플랫폼/인프라 팀	가용성, 스케일링, 모니터링
라우팅 정책, Fallback 설정	플랫폼 팀 + AI/ML 팀	최적 모델 배치, 품질 기준
팀별 예산/한도	각 서비스 팀 (요청) + 플랫폼 팀 (승인)	비용 통제
프로바이더 API 키 관리	보안 팀 + 플랫폼 팀	키 로테이션, 접근 제한
비용 거버넌스 정책	매니저 + 재무	전체 AI 예산 배분

---

10. 재발 방지

10.1 자동화 검증 항목

검증 항목	자동화 방법	실행 시점
설정 YAML 문법 검증	CI 파이프라인에 litellm --config config.yaml --test	PR 머지 전
Fallback 동작 검증	Integration test: Primary 차단 후 Fallback 응답 확인	배포 후 Smoke test
Rate Limit 동작 검증	부하 테스트에서 한도 초과 시 429 반환 확인	주간 부하 테스트
예산 알림 동작 검증	테스트 팀에 $1 예산 설정 후 초과 알림 확인	월간 점검
프로바이더 Health Check	Synthetic request (간단한 completion) 주기적 전송	매 30초

10.2 포스트모템 작성 포인트

LLM Gateway 장애 발생 시 포스트모템에 포함할 항목:

• 타임라인: 장애 시작 → 감지 → Fallback 동작 → 수동 개입 → 복구까지 각 시점
• 영향 범위: 영향받은 서비스 수, 실패한 요청 수, 사용자 영향
• 감지 지연 원인: 알림이 없었는지, 있었는데 놓쳤는지, 임계값이 부적절했는지
• Fallback 효과: Fallback이 정상 동작했는가? 사용자가 품질 차이를 인지했는가?
• 비용 영향: Fallback 프로바이더 사용으로 인한 추가 비용

---

11. 도구 비교: 직접 구축 vs 오픈소스 vs 매니지드

기준	직접 구축 (Nginx + 코드)	LiteLLM (오픈소스)	Portkey (매니지드)	Cloudflare AI Gateway
초기 구축 비용	높음 (2~4주)	낮음 (1~2일)	가장 낮음 (수 시간)	낮음 (Cloudflare 사용 시)
운영 복잡도	높음	중간	낮음	낮음
커스터마이징	완전 자유	높음 (오픈소스)	제한적	제한적
멀티 프로바이더 지원	직접 구현	100+ 프로바이더	200+ 프로바이더	주요 프로바이더
Rate Limiting	직접 구현	내장 (Redis 기반)	내장	내장
비용 추적	직접 구현	내장	내장 + 대시보드	내장
데이터 위치	완전 통제	자체 인프라	Portkey 클라우드	Cloudflare 인프라
가격	인프라 비용만	무료 (셀프 호스팅)	무료 Dev 플랜 (10K req/월) + Pro $49/월	무료 (일정 사용량까지)

선택 기준

• 데이터 민감도 높음 + 커스텀 로직 필요: LiteLLM 셀프 호스팅
• 빠른 도입 + 운영 부담 최소화: Portkey 또는 Cloudflare AI Gateway
• 기존 Cloudflare 인프라 사용 중: Cloudflare AI Gateway
• 완전한 제어 + 특수 라우팅 로직: 직접 구축

---

12. 자주 하는 실수

실수	결과	올바른 접근
Fallback 없이 단일 프로바이더만 설정	프로바이더 장애 = 서비스 장애	최소 1개 Fallback 프로바이더 설정
Gateway Rate Limit을 프로바이더 한도와 동일하게 설정	버스트 시 프로바이더 429 도달	프로바이더 한도의 70~80%로 설정하여 버퍼 확보
모든 요청에 최고 성능 모델 사용	비용 폭증, Rate Limit 빨리 도달	요청 복잡도별 모델 분리 (Content-based 라우팅)
타임아웃을 너무 길게 설정 (600초)	장애 시 연결 점유, 리소스 고갈	용도별 타임아웃 분리 (30~120초)
Rate Limiter 저장소(Redis) 장애 시 전체 거부	Gateway가 사용 불가	Fail-open 전략: Redis 다운 시 in-memory로 전환
가상 키 없이 팀 구분 없이 운영	비용 귀속 불가, 한도 분배 불가	팀/서비스별 가상 키 발급 필수
Fallback 모델을 테스트하지 않음	실제 장애 시 Fallback 모델 응답 품질이 사용 불가 수준	정기적으로 Fallback 모델에 동일 프롬프트로 품질 확인
Circuit Breaker cooldown을 너무 짧게 설정	복구 전에 재시도 → 연속 실패 루프	프로바이더별 복구 시간 데이터 기반으로 cooldown 결정

---

13. 정리

LLM Gateway는 단일 프로바이더 직접 호출에서 시작해도, 서비스가 2개 이상으로 늘어나는 시점에서 도입을 검토할 가치가 있습니다.

핵심 설계 원칙:

• 라우팅: 단순 Round Robin보다 Content-based 라우팅으로 비용과 품질을 동시에 최적화
• Rate Limiting: TPM + RPM 이중 제한으로 프로바이더 한도 초과를 사전에 방지하고, 팀별 예산을 분리
• Fallback: Primary → Secondary(동급) → Degraded(저급) 3단계 체인으로 서비스 연속성 확보
• Observability: 에러율, Fallback 빈도, 비용 소진 속도를 실시간 모니터링하여 장애를 조기 감지

규모가 작을 때는 LiteLLM 단일 인스턴스 + 1개 Fallback으로 시작하고, 서비스와 팀이 늘어나면 Redis, PostgreSQL, HPA를 순차적으로 추가하는 접근이 실용적입니다.

---

관련 글

• AI 서비스 비용 최적화 전략
• AI 서비스 비용 거버넌스
• AI Agent 아키텍처: Tool Use, Planning, Memory 설계 패턴
• AI 애플리케이션 보안 리스크: Prompt Injection과 데이터 유출