Model Routing은 여러 LLM 중 어떤 모델에 요청을 보낼지 결정하는 계층이다. 겉으로는 “쉬운 요청은 싼 모델, 어려운 요청은 비싼 모델”처럼 보이지만, 실제 운영에서는 비용, 지연, 캐시, 규정, 장애, 워크로드 패턴을 함께 최적화해야 한다.
단순 분류가 아닌 시스템 최적화
IBM Research는 모델 라우팅의 어려움을 “모델 선택”보다 “시스템 운영점 찾기”로 설명한다. 모델 품질은 중요한 변수지만 유일한 변수가 아니다.
| 변수 | 라우팅에 미치는 영향 |
|---|---|
| 품질 | 작업별 정답률, 코딩 성공률, 평가 점수 |
| 비용 | 입력·출력 토큰 가격, 구독 한도, 무료 티어 |
| 지연 | 사용자 상호작용, batch 작업, 에이전트 루프 속도 |
| 캐시 | prompt cache 적중률, 같은 세션의 모델 고정 필요성 |
| 규정 | 데이터 위치, 민감 정보, 감사 요구사항 |
| 인프라 | provider 장애, rate limit, queue 상태 |
좋은 라우터는 매 요청마다 “최고 모델”을 찾는 것이 아니라, 현재 시스템 전체에서 가장 나은 trade-off를 고른다.
에이전트 워크로드에서 더 어렵다
에이전트는 한 번의 답변보다 수십~수백 번의 모델 호출로 작업을 완성한다. 초반 조사, 코드 작성, 테스트 실패 분석, 요약, 최종 보고는 서로 다른 모델이 적합할 수 있다. 그러나 모델을 너무 자주 바꾸면 컨텍스트 일관성, 캐시, 출력 형식, 도구 호출 안정성이 흔들린다.
따라서 에이전트용 라우팅은 다음 정책을 함께 다룬다.
- 작업 단계별 모델 후보군
- 실패 시 fallback 순서
- 같은 세션에서 모델을 유지할지 여부
- 민감 데이터가 포함된 요청의 허용 provider
- 비용 상한과 지연 시간 상한
- 평가 로그 기반 라우팅 정책 개선
구현 방식
라우팅은 애플리케이션 코드 안에 직접 넣을 수도 있지만, 규모가 커지면 agent-gateway나 omniroute 같은 게이트웨이 계층으로 분리하는 편이 운영하기 쉽다. 이 계층은 OpenAI 호환 API, Responses API, Claude/Gemini 변환, provider health check, rate limit, 비용 추적, 캐시, 로그를 한 곳에서 처리한다.
관련 문서
- agent-gateway — MCP·OpenAPI·GraphQL 도구를 하나의 에이전트 게이트웨이로 묶는 통합 레이어
- omniroute — 여러 AI provider와 코딩 에이전트를 하나의 엔드포인트로 연결하는 무료 AI 게이트웨이
- llm-orchestration-tips-framework-choice — LangChain·LlamaIndex·Raw API 선택 기준
- inference-caching — LLM 추론 비용과 지연 시간을 줄이는 캐시 전략
참고 자료
- Model Routing Is Simple. Until It Isn’t. — Hugging Face Blog / IBM Research (2026-07)