본문으로 건너뛰기

모델 라우팅 패턴: 캐스케이드, 분류기, 그리고 실제로 배포되는 것

중급

제품이 한 가지 이상의 일을 하기 시작하면, 하나의 모델로는 모든 요청에 대한 정답이 되지 못합니다. 티켓을 분류하고, 필드를 추출하고, 답변 초안을 작성하고, 이를 검토하는 것 — 이는 각기 다른 비용/지연시간/품질 예산을 가진 네 가지 작업입니다. 2026년에 전 분야가 수렴한 패턴은 각 요청을 그 작업에 맞는 모델로 라우팅하고, 저렴한 모델로 충분하지 않을 때 에스컬레이션하는 것입니다. 이 페이지는 이러한 패턴에 대한 편집 가이드입니다: 무엇인지, 각각이 언제 배포되는지, 작동하는 레시피, 그리고 피해야 할 실패 모드.

What you'll learn
  • 프로덕션에서 배포되는 6가지 라우팅 패턴과 각각을 언제 선택해야 하는지 이해하기
  • 라우팅(사전 결정 한 번)과 캐스케이딩(실패 시 에스컬레이션)의 차이 이해하기
  • 복사-붙여넣기 프롬프트와 일주일 롤아웃 계획으로 첫 분류기 라우터 구축하기
  • 비용 계산 읽기: 라우팅이 실제 돈을 절약할 때와 오버헤드가 절감분을 잠식할 때
  • 라우터를 언젠가 발생할 장애로 만드는 안티패턴 인식하기

2026년에 라우팅이 기본 패턴인 이유​

"모든 것에 하나의 큰 모델을 쓰는" 시대는 조용히 끝났습니다. 세 가지 힘이 이 전환을 이끌었습니다:

  • 넓고 잘 정돈된 가격 곡선. 이제 모든 주요 프로바이더가 패밀리를 제공합니다 — Anthropic (Haiku / Sonnet / Opus), OpenAI (small / mid / frontier), Google (Flash / Pro), 그리고 오픈 웨이트 티어까지. 저렴한 티어는 프론티어보다 10–100배 저렴하고, 좁은 작업에서는 미미하게 나쁠 뿐입니다. 저렴한 티어를 놀리는 것은 돈을 태우는 것입니다.
  • 실제 지연시간 예산. 지원 에이전트 앞의 분류 단계는 300ms 이내에 응답해야 합니다. 프론티어 모델은 비용 외의 이유로도 잘못된 도구인 경우가 많습니다 — 단순히 그 단계에 너무 느립니다.
  • 특화. 서로 다른 모델은 진정으로 서로 다른 작업에서 선두를 달립니다 — 하나는 구조화된 JSON에, 다른 하나는 긴 컨텍스트에, 다른 하나는 코드에, 또 다른 하나는 다국어에 더 뛰어납니다. 순위는 매달 뒤바뀌지만 (Choosing a Model 참고), 그 모양 — "서로 다른 작업에 서로 다른 도구" — 은 오래갑니다.

결과: 모델 앞에 라우터가 놓여 요청마다 어디로 작업을 보낼지 결정합니다. 이 페이지의 나머지는 그 라우터를 위한 설계 어휘입니다.

두 개의 큰 가족: 라우팅 vs 캐스케이딩​

아래의 거의 모든 패턴은 두 가지 아이디어의 변형입니다. 이 차이를 제대로 이해하면 나머지는 명명일 뿐입니다.

  • 라우팅은 어떤 모델이 실행되기 전에 사전 결정 한 번을 내립니다. 분류기(규칙, 소형 모델, 또는 더 큰 모델)가 요청을 읽고, 타겟을 선택하고, 넘깁니다. 빠르고, 정상 상태에서 저렴하지만, 분류기가 틀리면 잘못됩니다 — 그리고 나중에서야 알게 됩니다.
  • 캐스케이딩은 저렴한 모델을 먼저 실행하고 정의된 신호가 "이 답변은 충분히 좋지 않다"고 말할 때만 더 강한 모델로 에스컬레이션합니다. 신호가 실제 출력에 기반하므로 견고하지만, 모든 에스컬레이션은 두 모델 모두 비용을 지불합니다 — 따라서 승리는 저렴한 티어가 대부분의 트래픽을 자체적으로 처리할 때만 살아남습니다.

이 둘은 조합됩니다. 프로덕션 시스템은 대개 둘 다 수행합니다: 작업 유형에 따라 올바른 레인으로 라우팅한 다음, 레인 내부에서 저렴한 모델의 신뢰도에 따라 캐스케이드합니다. Anthropic의 분류법에서는 사전 결정을 "Routing"이라 부르고 동적 분해를 "Orchestrator-Workers"라 부릅니다. 캐스케이딩은 같은 아이디어의 "작은 것을 먼저 시도하고, 실패하면 에스컬레이션" 변형에 대한 업계 명칭입니다.

실제로 배포되는 6가지 패턴​

1. 규칙 기반 라우팅​

수작업 규칙(정규식, 키워드, 요청 필드, 메시지 길이)이 타겟을 결정합니다. 결정을 내리기 위해 어떤 모델도 실행되지 않습니다.

  • 언제 이깁니까. 신호가 명확하고 저렴할 때: "요청에 코드 펜스가 포함되어 있으면 코딩 모델로 보내라", "고객이 Enterprise 플랜이면 프론티어 티어로 보내라", "입력이 200k 토큰 이상이면 롱 컨텍스트 모델로 보내라".
  • 언제 깨집니까. 도메인이 이동함에 따라 규칙이 조용히 썩습니다 — 새로운 표현, 새로운 의도, 정규식이 예상하지 못한 엣지 케이스. 모든 "if X then Y"는 작은 기술 부채 조각입니다.
  • 언제 배포합니까. 하나 또는 두 개의 고가치 예외 처리(유료 티어, 코드 경로, 언어)가 있고 지연시간 오버헤드를 0으로 만들고 싶을 때.

2. 분류기 라우팅 (LLM-as-router)​

작고 빠른 모델이 요청을 읽고 레이블 — "billing" | "technical" | "sales" | "other" — 을 반환하고, 이것이 다운스트림 핸들러를 선택합니다. Anthropic이 정식 예시 중 하나로 제시합니다: 쉬운 질문은 Haiku에, 어려운 질문은 Sonnet에.

  • 언제 이깁니까. 작고 안정적인 카테고리 세트를 가지고 있고 각각이 고유한 프롬프트/도구 세트/모델을 받을 자격이 있을 때. 카테고리마다 특화된 단일 프롬프트가 하나의 거대한 만능 시스템 프롬프트를 이깁니다.
  • 언제 깨집니까. 카테고리가 겹칠 때(많은 실제 요청은 "billing 과 technical" 모두), 분류기가 조용히 잘못 라우팅할 때, 또는 레이블 세트가 ~10 카테고리를 넘어 폭발하여 선택이 노이즈가 될 때.
  • 언제 배포합니까. 상위 5–8개 요청 유형을 열거할 수 있고 각각이 다른 핸들러로부터 실질적으로 이득을 볼 때.

분류기-라우터 프롬프트 (Claude/GPT/Gemini에서 이식 가능)

You are a request classifier for a support product.

Read the CUSTOMER MESSAGE below and return a JSON object with:
- "category": one of ["billing", "technical", "account", "sales", "other"]
- "confidence": a number from 0.0 to 1.0
- "reason": one short sentence explaining the pick

If you are less than 0.7 confident, use "other" and say why.
Return ONLY the JSON, no prose, no code fence.

CUSTOMER MESSAGE:
"""
{{message}}
"""

3. 복잡도 기반 라우팅​

요청이 무엇에 관한 것인지 대신, 얼마나 어려운지를 추정합니다 — 길이, 엔티티 수, 숫자/코드를 참조하는지, 도구 사용이 예상되는지 — 그리고 그에 따라 티어를 선택합니다: 쉬운 것은 저렴하게, 중간은 미드, 어려운 것은 프론티어.

  • 언제 이깁니까. 작업 유형은 대략 동질적(예: "코딩 질문 답변")이지만 개별 요청의 난이도가 크게 다를 때. 두 줄짜리 문법 질문에 프론티어 가격을 지불하는 대신, 그런 것에는 Haiku 가격을 지불하고 프론티어는 여러 파일에 걸친 리팩터링에 예약합니다.
  • 언제 깨집니까. "난이도 점수"가 실제로는 "프롬프트 길이"이고, 긴 프롬프트가 항상 어려운 프롬프트는 아닙니다. 사용자가 거대한 스택 트레이스를 붙여넣고 그것에 대한 사소한 질문을 하면 — 라우터가 불필요하게 업그레이드합니다.
  • 언제 배포합니까. 작업 유형 내부에서 측정 가능한 난이도 편차가 있고 그것과 상관관계가 있는 명확한 신호(길이, 코드 존재, 하위 질문 수)가 있을 때.

4. 캐스케이드 (저렴한 것 먼저, 실패 시 에스컬레이션)​

저렴한 모델을 먼저 시도합니다. 실패 신호에 대해 답변을 확인합니다. 실패하면 더 강한 모델에서 재시도합니다. 이것은 업계가 다른 어떤 것보다 더 많이 배포하는 패턴입니다. "신호"가 모델이 실제로 말한 것에 기반하기 때문입니다 — 말할 것이라는 추측이 아니라.

  • 무엇이 신호로 간주됩니까? 저렴하고 신뢰할 수 있는 것 무엇이든: JSON 출력에 대한 스키마 검증, LLM 심판에 의한 "이것이 질문에 답합니까?" 확인, 모델이 확신이 없을 때 방출할 수 있는 명시적 "needs_help": true 필드, 코드를 실행하는 다운스트림 테스트, 프로바이더가 노출할 때 답변 토큰의 낮은 로그 확률.
  • 비용 계산. 절감은 저렴한 티어가 대부분의 트래픽을 처리할 때만 살아남습니다. 요청의 90%가 저렴한 모델에 의해 해결되고 10%가 에스컬레이션되면 0.9 × cheap + 0.1 × (cheap + strong) ≈ 대부분 저렴합니다. 절반이 에스컬레이션되면 강한 모델을 항상 사용하는 것보다 더 많이 지불하고 있습니다.
  • 언제 이깁니까. 명확한 "이것이 작동했나?" 신호가 있는 작업 — 실행되거나 실행되지 않는 코드, 검증되거나 검증되지 않는 JSON, 필드가 소스와 일치하거나 일치하지 않는 추출.
  • 언제 깨집니까. 저렴한 실패 신호가 없거나, 저렴한 모델이 성공하지 않았는데도 성공했다고 생각할 때 (조용한 실패 — 최악의 경우).
  • 언제 배포합니까. 실패 신호를 한 문장으로 이름 붙일 수 있고 강한 모델이 이를 확인할 필요가 없을 때.

5. 앙상블 / 검증 및 투표​

같은 요청을 N개의 모델에 대해 병렬로 실행하고 답변을 조정합니다 — 다수결 투표를 취하거나, 첫 번째로 스키마가 유효한 것을 취하거나, 모든 N개를 심판 모델에 보내 최고를 선택하게 합니다.

  • 언제 이깁니까. 품질이 비용이나 지연시간보다 중요할 때: 법률 조사, 의료 요약, 고위험 재무 추출, "이 계약서에서 위험 요소를 검토하라". 어려운 수학과 코드에도 유용하며, 서로 다른 모델이 서로 다른 실수를 하고 그 교집합이 어느 하나보다 더 신뢰할 수 있습니다.
  • 언제 깨집니까. N배 비용을 지불하고 모든 요청에 대해 가장 느린 모델의 지연시간을 상속합니다. 앙상블은 품질을 위해 감수하는 세금이지, 돈을 절약하는 방법이 아닙니다.
  • 언제 배포합니까. 답변을 잘못 얻는 비용이 N번의 모델 호출 비용보다 적어도 한 자릿수 이상 클 때 — 소비자 트래픽에서는 거의 참이 아니고 엔터프라이즈 워크플로우에서는 종종 참입니다.

6. 폴백 (비용이 아닌 가용성)​

기본을 시도하고, 429/5xx/타임아웃 발생 시 다른 프로바이더의 보조로 투명하게 재시도합니다. 이것은 다른 어떤 것도 사용하지 않더라도 진지한 멀티모델 앱이라면 모두 필요한 패턴입니다.

  • 언제 이깁니까. 기본 프로바이더가 정확히 잘못된 순간에 장애를 겪거나 스로틀될 때마다. 폴백은 신뢰성 패턴이지 비용 최적화 패턴이 아닙니다 — 보조는 대개 더 저렴한 모델이 아닌 다른 프로바이더의 동등한 티어입니다.
  • 무엇을 주의해야 합니까. 폴백 경로는 대부분의 시간 테스트되지 않은 코드입니다; 회귀됩니다. 라이브 트래픽의 최소 일부를 보조를 통해 지속적으로 실행하여 장애 상황에서 의존하기 전에 응답 형태가 이동했다는 것을 알아내세요.
  • 언제 배포합니까. 업타임 SLO가 어느 단일 프로바이더보다 높거나, 단일 프로바이더 의존이 비즈니스 리스크(계약, 지역 가용성, 지정학)일 때.

한눈에 보는 비교​

패턴결정 시점지연시간 추가?비용 추가?주요 리스크
규칙 기반모델 실행 전없음없음입력이 이동함에 따라 규칙이 조용히 썩음
분류기소형 모델에 의해 사전에+ 빠른 호출 1회+ 저렴한 호출 1회카테고리가 겹칠 때 잘못 라우팅
복잡도 기반휴리스틱에 의해 사전에미미함미미함"난이도"는 종종 "길이"를 의미
캐스케이드저렴한 모델이 시도한 후+ 에스컬레이션 시 재시도정상 상태에서 대부분 저렴잘못된 답변에 대한 조용한 성공
앙상블병렬로 N개 실행, 조정N개 중 가장 느림N×품질을 사는 것이지 돈을 절약하는 것이 아님
폴백기본 실패 시에만정상 경로에서 0정상 경로에서 0중요할 때까지 테스트되지 않음

실제 배포 레시피​

위의 패턴은 레고입니다. 프로덕션에서는 조합됩니다. 반복적으로 보이는 세 가지 레시피:

  • 고객 지원 에이전트. 분류기 라우터가 레인(billing / technical / account / sales)을 선택하고, 각 레인은 고유한 시스템 프롬프트와 도구 세트를 가지며, technical 레인 내부에서는 캐스케이드가 저렴한 모델을 먼저 시도하고 "에스컬레이션 필요" 도구 호출이 발생하면 프론티어로 에스컬레이션합니다. 프로바이더 간 폴백이 모든 것을 감쌉니다. 결과: 트래픽의 70–90%는 프론티어 모델을 만나지 않습니다.
  • 코딩 어시스턴트. 파일 유형과 diff 크기에 대한 규칙 기반 라우팅이 작은 편집은 저렴한 티어로, 여러 파일 리팩터링은 코딩 전문가로 보냅니다. 출력에 대한 캐스케이드 — "패치가 깨끗하게 적용되고 스모크 테스트를 통과합니까?" — 가 실패를 더 강한 모델로 에스컬레이션합니다. Claude vs GPT vs Gemini for coding의 필드 가이드와 비교하세요.
  • 문서 코퍼스에 대한 RAG QA. 분류기가 "컨텍스트에서 답변"(저렴)과 "문서 간 추론 필요"(미드) 사이에서 선택합니다. 두 모델의 앙상블이 고위험 문서(계약서, 신고서)에 대한 답변을 교차 검증합니다. Retrieval-Augmented Generation과 비교하세요.

일주일 안에 첫 라우터를 구축하는 방법​

Guided walkthrough1 of 7
  1. 제품이 이미 보내고 있는 *실제* 프롬프트를 계측하세요. 최소 수백 개, 이상적으로는 결과(해결됨 / 에스컬레이션됨 / 잘못됨)로 분류된 것이 필요합니다. 실제 트래픽 없이는 라우터가 어디로 보내야 할지 추측하는 것입니다.

실제로 배포되는 것 (2026 필드 노트)​

  • 캐스케이드가 학습된 라우터보다 훨씬 많이 배포됩니다. RouteLLM 같은 연구 시스템은 선호도 데이터로 라우터를 훈련하고 표준 벤치마크에서 비용을 2배 이상 절감할 수 있습니다 (RouteLLM 논문 참고) — 그러나 학습된 라우터를 훈련하고 유지하는 것은 실제 엔지니어링입니다. 대부분의 팀은 저렴-우선 + 명시적 에스컬레이션에서 대부분의 승리를 얻습니다.
  • 분류기는 거의 항상 파인튜닝이 아닌 저렴한 채팅 모델입니다. 좋은 프롬프트를 가진 Haiku급 또는 Flash급 모델은 5–8 카테고리에 대해 정확도 기준을 충족합니다. 규모에 있고 저렴한 분류기가 병목일 때만 파인튜닝하세요.
  • 평가자가 라우터보다 더 중요합니다. 메트릭 루프가 없는 라우터는 추측입니다. 모든 라우팅 결정을 요청 → 선택된 모델 → 결과로 계측하고, 주간으로 검토하세요. 측정하지 않는 것은 튜닝할 수 없습니다.
  • 인프라와 설계는 분리 가능합니다. 위의 패턴은 언어 및 프로바이더 중립적입니다. 배관 — 프로바이더당 하나의 엔드포인트, 가상 키, 팀당 지출 상한선, 프롬프트 캐싱 — 은 AI 게이트웨이가 제공하는 것입니다. 원하는 패턴을 알게 되면, 구체적인 선택은 AI gateways: LiteLLM, OpenRouter, Portkey, Vercel를 참고하세요.

피해야 할 안티패턴​

  • 프론티어 모델을 호출하는 분류기. 레인을 선택하는 것이 강한 모델을 실행하는 것만큼 비용이 든다면, 아무것도 절약하지 못하고 지연시간을 추가했습니다. 분류기는 저렴해야 합니다.
  • 실패 신호가 없는 캐스케이드. "저렴한 모델이 뭔가를 반환했으니 끝났다"는 신호가 아닙니다 — 도박입니다. 모든 캐스케이드는 저렴한 모델이 실패할 수 있는 정의된 확인이 필요합니다.
  • 규칙 증식. 10개의 규칙은 관리 가능합니다. 100개는 테스트 없이 손으로 코딩한 분류기입니다. 규칙 세트가 ~15개 분기를 넘어 이동하면 뜯어내고 소형 모델을 사용하세요.
  • 비용 전략으로서의 앙상블. 돈을 절약하기 위해 세 모델을 병렬로 실행하는 것은 범주 오류입니다 — 앙상블은 품질을 사기 위해 N× 비용이 들지, 비용을 절약하기 위한 것이 아닙니다. 나쁜 기본 모델을 만회하기 위해 앙상블을 사용한다면, 대신 기본을 고치세요.
  • 폴백 경로 없음. 모든 모델 프로바이더는 결국 다운됩니다. 단일 프로바이더 제품은 그 장애를 상속합니다. 배관은 AI gateways를 참고하세요.
  • 관측 가능성 없는 라우팅. 모든 것을 조용히 잘못된 레인으로 보내는 라우터는 2주 후 품질이 곤두박질칠 때까지 괜찮아 보입니다. 입력 해시, 선택된 모델, 결과, 비용으로 모든 결정을 로깅하고 — 주간으로 검토하세요.

이해도 확인​

Check yourself

0/3
  1. 당신은 요청의 90%가 저렴한 모델에 의해 올바르게 답변되지만 나머지 10%는 프론티어가 필요한 지원 제품을 가지고 있습니다. 어떤 패턴이 가장 큰 비용 승리를 가져다줍니까?
  2. Anthropic의 'Building Effective Agents' 가이드는 Routing을 다음과 같이 정의합니다:
  3. 당신은 분류기 라우터를 구축하고 있습니다. '정확도가 중요하다'는 이유로 분류기 프롬프트가 프론티어 모델에서 실행됩니다. 무엇이 문제입니까?

다음​

출처​

  • Anthropic — Building Effective Agents — Routing 및 Orchestrator-Workers 워크플로우의 정식 정의.
  • RouteLLM paper (arXiv 2406.18665) — 선호도 데이터로 훈련된 학습 라우터; 패턴의 여지를 보여주지만, 대부분의 프로덕션 팀은 여전히 학습된 라우팅보다는 규칙 + 분류기 + 캐스케이드를 배포합니다.