모델 라우팅 시스템은 도대체 무엇을 라우팅하는가
모델 라우팅의 본질은 「요청 의도」와 「능력 공급」의 매칭이다. 랜덤/라운드로빈/로드밸런싱 같은 전통적 분배 메커니즘이 아니라, 먼저 요청이 무엇을 원하는지 이해하고 나서 어떤 모델, 어떤 도구체인, 어떤 실행 플로우를 쓸지 결정하는 것이다. 라우팅의 대상은 단일 모델이 아니라 실행 방안 한 세트다.
의도 분류
- 개방형 QA
- 코드 생성
- 카피 다듬기
- 정보 추출
- 구조화 작성
- 고위험 의사결정 지원
요구 차원
- 모델 능력
- 컨텍스트 길이
- 응답 지연
- 출력 포맷
의도 판단이 틀리면 뒤에 아무리 강한 모델을 써도 잘못된 길로 갈 수 있다.
능력 매칭
- 일반 QA — 경량 모델
- 복잡 추론 — 대형 모델
- 구조화 추출 — 제약이 더 강한 모델
- 시효성 문제 — 검색 증강 모델 + 도구체인
결론: 라우팅은 모델 이름만 고르는 것이 아니라 처리 방안 한 세트를 고르는 것이다.
흔한 5가지 라우팅 차원
- 작업 유형
- 복잡도
- 지연 요구
- 비용 예산
- 리스크 등급
| 상황 | 요청 | 라우팅 결과 |
|---|
| 상황 1 | 저위험 잡담 | 저렴한 모델 |
| 상황 2 | 고위험 재무·세무 QA | 더 강한 모델 + 검색 검증 |
반례: 단일 차원의 위험
비용만 기준으로 라우팅 → 원래 강한 모델을 써야 할 복잡 추론 작업이 잘못 배정된다.
기업의 다중 모델 생태계
- 로컬 소형 모델
- 클라우드 대형 모델
- Embedding(벡터화) 모델
- 리랭크 모델
- 도구 호출
- 플로우 규칙 엔진
라우팅 시스템의 3가지 전형적 오류
- 모든 복잡한 문제를 최대 모델로 보냄 — 비용 폭발
- 구조화 추출까지 개방형 생성 모델에 맡김 — 포맷 불안정
- 시효성을 전혀 보지 않고 뉴스류 질문을 파라미터 모델로 응답 — 답이 낡음
라우팅은 지속적으로 반복되는 의사결정 시스템
- 성숙한 라우팅 시스템은 피드백 루프를 갖춰야 한다. 라우팅 후 핵심 지표를 기록하고
- 다시 그것으로 라우팅 전략을 최적화한다. 이유: 오늘 잘 나눴다고 해서 내일 데이터 분포가 바뀐 뒤에도 맞다는 보장은 없다.
정리
- 성질 규정: 모델 라우팅 시스템의 본질은 요청 의도와 능력 공급의 매칭이다.
- 식별 계층: 먼저 작업 유형, 복잡도, 지연 요구, 리스크 등급을 식별한다.
- 결정 계층: 그다음 어떤 모델을 쓸지, 검색·리랭크·도구 호출이 필요한지 결정한다.
- 대상: 라우팅의 대상은 단일 모델이 아니라 실행 방안 한 세트다.
- 폐루프: 여기에 품질, 비용, 실패율을 결합해 피드백 최적화를 한다. 로드밸런싱 사고로만 문제를 보는 것을 피할 것.
핵심 통찰
- 「라우팅」이라는 단어 자체가 함정이다 — 네트워크 공학의 이름을 빌려왔지만 네트워크 공학의 의미가 아니다. 네트워크 라우팅의 목표는 부하 분산(무상태, 동질 백엔드)이고, 모델 라우팅의 목표는 능력 적합(유상태, 이질 백엔드)이다. 이 차이를 먼저 짚으면 즉시 층위가 달라진다.
- 라우팅의 대상은 「실행 방안」이지 「모델」이 아니다 — 한 번의 라우팅이 결정하는 것은 「모델 + 검색 여부 + 리랭크 여부 + 도구 호출 여부 + 어떤 플로우」의 조합이다. 라우팅을 「모델 이름 고르기」로 이해하는 것은 조합 최적화 문제를 단일 선택 문제로 차원 축소하는 것이다.
- 의도 분류는 전체 링크의 단일 장애점이다 — 링크의 맨 앞에 있어서 한 번 잘못 분류되면 뒤에서 아무리 강한 모델을 써도 「잘못된 길」이다. 그래서 의도 분류에 대한 투자 대비 수익이 보통 백엔드 모델을 키우는 것보다 훨씬 높다.
- 단일 차원 라우팅은 반드시 불균형해지고, 불균형 방향도 예측 가능하다 — 비용만 보면 복잡 작업이 강등되고(품질 붕괴), 품질만 보면 전부 최대 모델로 가고(비용 폭발), 지연만 보면 검색류 요청이 우회된다(시효성 붕괴). 어떤 단일 차원 목표든 나머지 네 차원을 희생시키므로, 5차원(작업 유형/복잡도/지연/비용/리스크)을 반드시 함께 결정해야 한다.
- 리스크 등급이 엔지니어가 가장 잘 빠뜨리는 차원이다 — 저위험 잡담과 고위험 재무·세무 QA는 토큰 수도 복잡도도 같을 수 있지만 감당 가능한 오류 대가는 몇 자릿수 차이다. 「잡담 vs 재무·세무 QA」라는 대조는 비용 차원과 리스크 차원이 정반대의 라우팅 결론을 준다는 것을 정확히 보여준다.
- 능력 풀의 이질성이야말로 라우팅 문제의 원인이다 — 기업에 모델이 하나뿐이면 라우팅은 필요 없다. 로컬 소형 모델, 클라우드 대형 모델, Embedding, 리랭크, 도구, 규칙 엔진 여섯 종류가 동시에 존재할 때 문제는 「있느냐 없느냐」에서 「어떻게 조합해야 가장 이득인가」로 바뀐다. 라우팅의 가치는 능력 풀의 이질성에 따라 커진다.
- 피드백 루프가 없는 라우팅 규칙은 반드시 만료된다 — 라우팅 전략은 현재 데이터 분포에 적합화된 산물이며, 분포가 드리프트하면 규칙은 무효가 된다. 따라서 품질/소요/비용/실패율을 수집해 전략에 되먹여, 라우팅을 「일회성 규칙」에서 「지속적으로 반복되는 의사결정 시스템」으로 만들어야 한다.
- 「파라미터 모델로 억지 응답」은 시효성 문제의 표준 안티패턴이다 — 뉴스류, 시세류, 정책류 요청은 반드시 검색 경로를 타야 한다. 파라미터화된 지식으로 억지로 답하는 것은 모델 능력이 틀린 게 아니라 라우팅 결정이 틀린 것이다.
엔지니어링 실전 Tips
- 비용 최적화는 「강등」이지 「절단」이 아니다: 일반 QA를 경량 모델로 내리는 건 절약이지만, 복잡 추론을 경량 모델로 내리는 건 절약 실패다. 강등은 반드시 복잡도 차원을 먼저 봐야 한다.
- 구조화 추출에 개방형 생성 모델을 쓰지 말 것: 포맷 불안정으로 인한 재작업 비용(재시도 + 파싱 실패 + 사람 폴백)이 보통 제약이 강한 모델로 바꾸는 차액보다 훨씬 크다.
- 의도 분류기 자체의 비용도 통제할 것: 모든 요청의 맨 앞에 있으므로, 대형 모델로 분류하면 라우팅으로 절약한 돈을 분류기가 먹어버린다.
- 실패율은 반드시 별도 집계할 것: 「결과 품질」과는 다른 것이다. 타임아웃, 포맷 파싱 실패, 도구 호출 실패는 실패율에 속하고, 잘 못 답한 것은 품질에 속한다. 둘에 대응하는 최적화 동작이 완전히 다르다.
- 라우팅 결정을 로그에 남길 것: 「왜 이 경로를 골랐는가」(어떤 의도에 명중했는지, 각 차원의 점수)를 기록해야 폐루프 최적화 시 귀인할 수 있다.
- 답변 순서 제안: 먼저 교정(로드밸런싱이 아니다) → 성질 규정(의도 × 능력 공급) → 두 단계 설명(의도 분류, 능력 매칭) → 5차원 → 반례(비용만 기준) → 폐루프. 이 순서대로 말하면 그것이 곧 완전한 「플랫폼 관점」이다.