AI 운영 경제학 (2/4) — 모델 라우팅 전략: 비용·품질·지연 3축 의사결정
"가장 비싼 모델"이 답이 아닌 이유는 단순하다 — 같은 결과를 1/10 비용으로 얻을 수 있는 작업이 80% 이상이기 때문이다.
핵심 요약
- 라우팅은 작업과 모델을 매칭하는 룰 시스템. 즉흥 선택이 아니다
- 3축: 비용 / 품질 / 지연 — 모든 라우팅 결정은 이 셋의 trade-off
- 1차 자료: Anthropic·OpenAI 가격 페이지, 사용자 자체 라우팅 시스템 운영 데이터
- 출발점: "이 작업이 실패해도 다시 하면 되는가?" — 그렇다면 작은 모델로 시작
- 자동화는 classifier가 작업을 분류하면 라우터가 모델을 정함. 사람의 즉흥 결정은 라우팅이 아님
1. 왜 라우팅인가
LLM 모델은 같은 프로바이더 안에서도 단가 차이가 크다.
| 모델 | 입력 단가 (1M 토큰) | 출력 단가 |
|---|---|---|
| Claude Opus 4.7 | $15 | $75 |
| Claude Sonnet 4.6 | $3 | $15 |
| Claude Haiku 4.5 | $0.80 | $4 |
1M 토큰 입력 기준 Opus는 Haiku의 ~19배. 같은 분류 작업을 Opus로 돌리는 것은 19배의 청구서를 받는다는 뜻이다.
질문은 "Haiku가 충분한가"이지 "Opus가 더 좋은가"가 아니다. 충분히 좋은 가장 싼 모델을 고르는 것이 라우팅의 핵심.
2. 3축 — 비용·품질·지연
라우팅 결정은 항상 세 축의 trade-off다.
2.1 비용
- 단가 + 토큰 사용량의 곱.
- 캐싱·라우팅·짧은 출력으로 최대 ~95% 절감 가능 (편 1/4 + 5/A 참고).
2.2 품질
- 재시도 빈도로 측정한다. 작은 모델이 같은 작업을 3번 만에 통과하면 실효 비용은 3배.
- 품질은 정확도 임계가 아니라 재시도 함수로 본다.
2.3 지연
- 작은 모델이 빠르다. 사용자가 5초 안에 답을 받아야 하는 인터랙션이면 큰 모델은 후보에서 빠진다.
- 백그라운드 작업은 지연 가중치 0이다.
3축 통합 공식 (개념):
실효 비용 = (단가 × 토큰) × (1 + 재시도율) + (지연 × 사용자 인내 페널티)
복잡해 보이지만 실제로는 룰 테이블로 환원된다.
3. 작업 × 모델 매핑 룰
다음은 일반적인 출발점이다. 자체 측정으로 조정한다.
| 작업 | 추천 모델 | 이유 |
|---|---|---|
| 분류 / 라벨링 / 의도 추출 | Haiku 또는 oMLX 로컬 | 단순, 재시도 비용 낮음 |
| 요약 (≤5K 입력) | Haiku 또는 Sonnet | Haiku로 시작, 품질 부족 시 Sonnet |
| 일반 코드 변경 / PR 작성 | Sonnet | 품질·비용 균형점 |
| 복잡한 디버깅 / 설계 / 멀티 단계 추론 | Opus | 재시도 줄이는 편이 더 싸다 |
| 백그라운드 모니터링 / 폴링 | Haiku 또는 로컬 | 빈도 높고 지연 무관 |
| 사용자 대화형 챗 | Sonnet (스트리밍) | 지연 ≤2초 필요 |
핵심 룰: 작은 모델로 시작 → 측정 → 필요할 때만 큰 모델로 승격. 반대 방향(큰 모델로 시작)은 거의 항상 과지출이다.
4. 멀티 프로바이더 라우팅
Anthropic 단일 생태계가 아니라 OpenAI·Anthropic·로컬을 섞는다면 프로바이더 간 라우팅이 추가 레버다.
프로바이더 선택 축: - 데이터 위치: 코드·문서가 외부 API로 나가도 되는가? 안 된다면 로컬. - 모델 강점: 코드 = Anthropic 강한 편, 일부 reasoning = OpenAI o-시리즈 강한 편 (벤치마크와 자체 측정으로 결정). - 가용성: 한 프로바이더가 5xx를 내면 자동으로 다른 쪽으로 fallback.
fallback 전략: - 1차: 가장 비용 효율적인 프로바이더. - 2차: 1차 실패 시 다른 프로바이더의 동급 모델. - 3차: 둘 다 실패하면 상위 모델로 escalate (재시도가 더 비싸도 작업 자체는 통과해야 함).
측정: provider × model × success_rate를 일별로 본다. fallback이 자주 발동되는 작업은 1차 선택을 재검토.
5. Classifier 기반 자동 라우팅
사람이 매 작업마다 모델을 고르는 것은 라우팅이 아니라 즉흥 선택이다. 진짜 라우팅은 classifier로 자동화된다.
최소 classifier:
- 입력: 사용자 요청 텍스트 + 메타데이터 (작업 길이, 도구 카탈로그 등).
- 출력: {model: "haiku-4.5", reason: "classification task"}.
- 구현: 룰 기반(키워드)으로 시작 → 측정 후 작은 LLM(Haiku)으로 업그레이드.
라우터 구조:
[사용자 요청] → [Classifier] → [모델 선택] → [LLM 호출] → [결과]
│ │
└─[로깅: task_type, model, cost, latency]
자체 라우터 운영 시 classifier 자체의 비용도 토큰을 소모하므로, classifier에는 가장 작은 모델 또는 룰 기반을 쓴다. classifier가 호출 비용의 10% 이상이면 룰로 간소화 검토.
6. 실측 — 무엇을 보는가
라우팅 효과는 다음 지표로 측정한다:
- 모델별 호출 분포: 작업 종류별로 어느 모델이 어느 비율로 호출됐나.
- 재시도율: 모델별 재시도 빈도. 작은 모델이 30% 이상 재시도면 모델이 너무 작다.
- fallback 발동율: 너무 자주면 1차 모델 신뢰도 낮음.
- 평균 비용 / 작업: classifier 도입 전후 비교.
경험적 룰: classifier 도입 후 평균 비용이 50% 이상 감소하는 게 일반적이다. 그렇지 않으면 classifier 룰이 너무 conservative (작은 모델로 못 보내고 있음).
7. 함정 — 라우팅이 망가지는 4가지 패턴
7.1 작은 모델 영구 회귀
- "Haiku가 빠르고 싸다"라고 모든 작업을 Haiku로 보냄.
- 결과: 재시도 폭증 → 비용은 같거나 더 든다.
7.2 큰 모델 default
- "Opus가 안전하다"라고 default 선택.
- 결과: 80% 작업이 과지출.
7.3 측정 없는 라우팅
- 일단 도입했지만 효과를 측정 안 함.
- 결과: 6개월 후 라우터의 룰이 현실과 어긋나도 모름.
7.4 너무 많은 모델
- 5개 프로바이더 × 3개 모델 = 15개 옵션.
- 결과: classifier가 어디로 보낼지 예측 불가, fallback 체인이 복잡해 디버깅 곤란.
8. 한눈에 정리
| 단계 | 핵심 | 측정 신호 |
|---|---|---|
| 1. 작업 분류 | 룰 기반 또는 classifier | task_type 분포 |
| 2. 모델 매핑 | 작은 모델부터 시작 | 재시도율 |
| 3. 멀티 프로바이더 | 데이터·강점·가용성 | fallback 발동율 |
| 4. 자동화 | Classifier + 라우터 | 평균 비용/작업 추이 |
| 5. 모니터링 | provider × model × 일별 | success_rate, latency |
라우팅은 한 번 짜고 끝이 아니다. 모델 라인업·가격·내부 작업 분포가 바뀌므로 매 분기 재검토가 적절하다.
다음 편
다음 편(3/4)은 컨텍스트 캐싱 가이드 — 1시간 vs 5분이다. 라우팅이 모델을 결정한다면 캐싱은 입력 토큰을 결정한다. 두 레버가 함께 가야 비용 절감이 완성된다.
참고 자료
- Anthropic, Pricing — claude.com/pricing (2026-05-05 확인).
- OpenAI, Pricing — platform.openai.com/pricing (2026-05-05 확인).
- AI Coding Agents in Practice (5/5) — 비용 관리 4가지 레버 (시리즈 A 마지막 편).
- 시리즈 1편 — 토큰 비용 구조와 실측 함정.
이 글은 AI 운영 경제학 시리즈의 2/4 편입니다.
댓글
댓글 쓰기