글을 읽는 것보다 영상을 보는 것을 선호하신다면, 제 YouTube 채널의 이 영상을 확인해 보세요:

약 1년 전 저는 스케이트보드에 다시 재미를 붙였습니다. 아마 역사상 가장 안전하지 않은 중년의 위기일지도 모르겠지만, 집에서 체육관까지 이동할 수 있고, 킥턴(kickturn)을 할 수 있으며, 10번 중 1번 정도는 노즈 스톨(nose stall)도 해낼 수 있습니다. 예시로 이 영상을 봐주세요.

심지어 제 보드를 직접 만들기도 했습니다! 직접 그립 테이프(grip tape)를 붙이고, 트럭(trucks)을 볼트로 고정하고, 휠에 베어링(bearings)을 끼웠습니다. 이 과정을 통해 확실히 배운 점 하나는 스케이트보드 가격이 예전보다 훨씬 비싸졌다는 것입니다.

또 무엇이 비쌀까요? 바로 토큰(Tokens)입니다. 정액제 구독료 대신 토큰 기반 과금 방식이 도입되면서, 토큰맥싱(tokenmaxxing, 이 용어는 정말 싫습니다)의 시대는 진정으로 끝났습니다.

결국 AI 연구소들도 실제로 이익을 내려면 돈을 벌어야 한다는 사실이 드러난 것입니다

토큰 기반 과금으로의 전환이 드러낸 한 가지는, 사람들이 문서를 찾기 위해 웹을 검색하거나 심지어 간단한 git 명령어를 사용하는 것과 같은 단순한 작업을 수행할 때 얼마나 많은 토큰을 낭비하고 있었는지였습니다!

하지만 서로 다른 유형의 작업을 처리하는 멀티 에이전트 시스템(multi-agent system)을 운영한다면 어떨까요? 모든 상황을 커버하기 위해 단순히 Opus나 Fable 같은 고성능 모델을 사용해야 할까요? 아니면 그보다 더 똑똑하게 대처할 수 있을까요?

여기에서 모델 라우팅(Model Routing)이 등장합니다. 모델 라우팅은 각 사용자 요청을 해당 요청을 처리하기에 적합한 모델과 매칭해 주는 AI를 위한 교통 시스템입니다.

이 글에서는 Microsoft Foundry에서 모델 라우팅이 어떻게 작동하는지, 모델 라우팅을 어떻게 설정할 수 있는지, 그리고 에이전트가 부여된 작업에 가장 적합한 모델을 선택할 수 있도록 모델 라우터(model routers)를 사용하도록 어떻게 구성할 수 있는지 살펴보겠습니다.

모델 라우팅(Model Routing)이란 무엇인가?

Fable이나 Opus와 같은 강력한 추론 모델(reasoning models)은 더 나은 품질의 결과를 제공하는 경향이 있지만, 사용 시 요청/토큰 및 추론 토큰(reasoning tokens) 비용이 더 많이 들고 응답 속도도 느립니다. 그에 비해 작은 모델들은 더 빠르고 저렴하지만, 복잡한 추론 작업을 수행할 수는 없습니다.

단일 에이전트 (single-agent) 아키텍처에서는 토큰을 최대한 많이 사용하여 문제를 해결하려는 경향이 있어 강력한 모델을 선택하곤 합니다. 하지만 토큰은 비용이 많이 들기 때문에, 이러한 논리를 멀티 에이전트 (multi-agent) 아키텍처에 적용하면 순식간에 파산하게 될 것입니다. 또한 에이전트가 수행해야 하는 작업은 복잡도가 다양할 수 있는데, 단순한 작업을 수행하기 위해 강력한 모델을 사용하는 것은 비효율적입니다.

모델 라우팅 (Model routing)은 들어오는 작업을 분석하여 적절한 모델로 전달하는 자동화된 의사 결정 계층 역할을 합니다. 따라서 모든 요청을 Fable과 같은 비싸고 고성능인 모델을 사용하도록 하드코딩하는 대신, 모델 라우팅은 작업의 복잡도를 최적의 모델과 매칭합니다.

모델 라우팅은 멀티 에이전트 (multi-agent) 아키텍처에서 이상적입니다. 서로 다른 작업들이 각기 다른 복잡도 범주에 속하기 때문에, 단순한 작업을 위해 강력한 모델을 사용하여 토큰을 낭비하기보다는 주어진 작업에 적합한 모델이 처리하도록 하는 것이 더 낫기 때문입니다. 각 요청의 복잡도는 모델이 호출되기 전에 모델 라우터 (model router)에 의해 평가되며, 그 후에 모델 라우터는 요청의 요구 사항에 어떤 모델이 일치하는지 결정합니다.

제 친구 중 한 명이 git 명령어를 찾아보는 데 Opus 4.8을 사용했다고 말하더군요. 그를 비난하고 싶지는 않지만, 그건 단순한 웹 검색일 뿐인데 말이죠....

Microsoft Foundry는 내장된 모델 라우터 (built-in Model router)를 갖추고 있습니다. 이는 실시간으로 각 프롬프트 (prompt)를 분석하여 작업에 가장 적합한 LLM (Large Language Model)으로 라우팅 (routing)하는 학습된 ML (Machine Learning) 모델로, 비용, 응답 품질 및 지연 시간 (latency)을 최적화합니다. 모델 라우터 (Model Router)는 단일 프롬프트부터 복잡한 에이전트 워크플로 (agentic workflows)에 이르기까지 수많은 시나리오를 바탕으로 학습된 ML 모델입니다. Microsoft는 새로운 모델과 라우팅 개선 사항을 통해 활성 라우터 버전을 업데이트하므로, 사용자가 직접 관리할 필요가 없습니다.

이 블로그 포스트의 나머지 부분에서 모델 라우터 (Model Router)라고 말할 때는 Microsoft Foundry의 모델 라우터 (Model Router) 기능을 의미합니다. 모델 라우팅 (model routing)이라고 말할 때는 그 개념을 적용합니다. 궁금한 점이 있다면 댓글로 질문해 주세요.

어떻게 작동하나요?

모델 라우터 (Model Router)는 복잡성, 추론 (reasoning), 작업 유형 및 기타 속성을 기반으로 프롬프트 (prompts)를 분석합니다. 모델 라우터 (Model Router)가 에이전트 (agents)와 함께 사용될 때는 전체 요청 컨텍스트 (request context)를 분석합니다. 여기에는 시스템 메시지 (system message), 사용자 메시지 (user message), 도구 정의 (tool definitions), 대화 기록 (conversation history) 등이 포함됩니다.

모델 라우터 (Model Router)에는 선택할 수 있는 세 가지 라우팅 모드 (routing modes)가 있습니다:

1. Balanced (균형): 좁은 품질 범위 내의 모델들을 고려한 후, 가장 비용 효율적인 모델을 선택합니다.
2. Cost (비용): 더 넓은 품질 범위를 사용한 후, 가장 비용 효율적인 모델을 선택합니다.
3. Quality (품질) 모드: 비용은 무시하고 프롬프트 (prompt)에 대해 가장 높은 등급을 받은 모델을 선택합니다.

모델 라우터 (Model Router)는 세션 단위가 아닌 요청 단위 (per-request, not per-session)로 작동하기 때문에 대화의 각 턴 (turn)이 라우팅됩니다. 대화 중에 요청에 따라 서로 다른 모델을 사용하는 여러 에이전트 (agents)가 있을 수 있습니다. 라우터는 다음을 기반으로 요청의 복잡성을 결정합니다:

• 사실적 회상 (factual recalls), 간단한 인사, 또는 기본적인 후속 질문의 경우, 이러한 요청은 낮은 복잡도 (low complexity) 작업으로 간주되어 더 저렴한 모델을 사용합니다.
• 도구 오케스트레이션 (Tool orchestration)은 더 낮은 비용으로 구조화된 도구 호출 (tool calls)을 안정적으로 생성할 수 있도록 중간 단계 (mid-tier) 모델로 라우팅됩니다.
• 연구, 다단계 추론 (multi-step reasoning), 그리고 복잡한 코드 생성 경로는 높은 복잡도 (highly complex) 작업이며, 따라서 일반적으로 성능이 더 높고 비용이 더 높은 모델로 라우팅됩니다.

Foundry 내에서 각각 고유한 라우팅 모드와 모델 서브셋 (subset)을 가진 여러 모델 라우터 배포 (model router deployments)를 생성할 수 있습니다. 예를 들어, cost 라우팅 모드를 사용하는 router-efficient라는 배포를 생성할 수 있으며, 이 경우 모델 라우터는 프롬프트를 gpt-5-nano와 같은 더 저렴한 모델로 라우팅합니다.

Microsoft Foundry에서 모델 라우터 배포하기

Microsoft Foundry에서 모델 라우터 설정하기는 일반적인 배포를 생성하는 것과 유사합니다. Foundry 모델 카탈로그 (model catalog)에서 model-router를 입력하기만 하면 찾을 수 있습니다:

기본 설정은 지원되는 전체 모델 세트에 대해 균형 (Balanced) 모드를 제공합니다. 다른 라우팅 모드가 필요하거나 라우팅할 모델 서브셋을 제한하고 싶은 경우 사용자 정의할 수도 있습니다.

이 글을 작성하는 시점에 모델 라우터는 5개 지역으로 제한되어 있으며 (Australia East가 그중 하나입니다), 사용하려는 Claude 모델을 제외하고는 기반 모델을 먼저 배포할 필요가 없습니다.

Bicep에서는 다음과 같이 모델 라우터를 생성할 수 있습니다:

resource efficientRouter 'Microsoft.CognitiveServices/accounts/deployments@2025-10-01-preview' = {
  parent: account
  name: 'router-efficient'
...

다시 한번 말씀드리지만, 모델 라우터 (model router) 모델은 Microsoft Foundry 계정 아래의 또 다른 배포 (deployment)일 뿐입니다. Foundry Project가 에이전트 (agents)를 호스팅하며, dependsOn: [project] 라인이 계정에 대한 동시 쓰기 (concurrent writes)를 방지합니다.

우리의 샘플에서는 작업에 따라 서로 다른 에이전트로 라우팅하는 분류 (triage) 에이전트를 사용할 것입니다. 그러면 각 전문 에이전트 (specialist agent)를 위한 모델 라우터 (Model router)가 기반이 되는 모델을 선택합니다. 위의 Bicep 블록에서 우리는 비용 (Cost) 모드를 구현하여, 간단한 작업은 gpt-5.4-nano 또는 gpt-5-nano 모델을 사용하는 에이전트로 라우팅되도록 했습니다. 이는 어떤 모델이 작업을 처리할지 더욱 세밀하게 조정하고 싶을 때 유용합니다.

여기서 단점은 특정 모델이 지원 종료 (deprecated)되는 시점을 계속 주시해야 한다는 점입니다.

샘플 구축하기

스케이트보드 이야기로 돌아가서, 스케이터들이 괜찮은 장비를 갖추기 위해 수백 달러를 들일 필요 없이 다른 사람으로부터 중고 장비를 살 수 있는 중고 스케이트보드 장비 마켓플레이스를 위한 멀티 에이전트 시스템 (multi-agentic system)을 잠시 상상해 보세요.

코드를 따라 해보고 싶다면, 제 GitHub에서 확인하세요!

마켓플레이스의 매물 (Listings)은 다음과 같을 수 있으며, 여기에는 제품 정보, 장비의 상태, 사진, 그리고 판매자에 대한 정보가 포함됩니다:

{
"L01": {
    "brand": "Powell Peralta",
...

마켓플레이스 내에는 판매자들이 있습니다. 판매자에 대해 우리가 가질 수 있는 정보에는 계정 생성 기간, 완료된 판매 횟수, 현재 진행 중인 분쟁 (disputes) 횟수, 만족도 등급, 그리고 인증된 결제 수단 보유 여부 등이 포함될 수 있습니다:

{
"S01": {
    "account_age_days": 1240,
...

모델 라우팅 (model routing)을 시연하기 위해, 다음과 같은 에이전트들을 구현할 수 있습니다:

단순한 질의(queries)나 분류(triaging) 질문의 경우, 이러한 간단한 작업에는 비용이 낮은 모델을 사용합니다. 분석 또는 연구 유형의 작업(예: 리스팅이 사기인지 여부 판단)의 경우, 프론티어 모델 (frontier model)로 라우팅합니다.

에이전트 설정하기 (Configuring our agents)

모델 라우터 (model routers)를 매핑하기 위해, 각 전문가 역할(specialist role)을 라우터 배포(router deployment)에 매핑하는 config.py 파일을 작성했습니다:

def deployment_for(self, role: Role) -> str:
        return {
            Role.SPEC: self.router_efficient,
...

그 후, 다음과 같이 라우터 배포 이름을 사용하여 에이전트를 생성합니다:

def ensure_agents(project: AIProjectClient, settings: Settings) -> dict[Role, str]:
    """작업당 하나의 에이전트를 생성하며, 각 에이전트는 그에 적합한 라우터 배포에서 실행됩니다."""
    created: dict[Role, str] = {}
...

이를 통해 다음과 같은 에이전트와 할당이 생성됩니다:

deck-check-spec  -> router-efficient -> 비용 (Cost) 모드
deck-check-price -> router-balanced  -> 균형 (Balanced) 모드
deck-check-scam  -> router-frontier  -> 품질 (Quality) 모드

분류 (triage) 에이전트 또한 효율적인 라우터 (efficient router)를 사용하므로, 다음과 같이 설정할 수 있습니다:

triage_agent = ensure_triage(
    project,
    settings.router_efficient,
...

Foundry에서 모델 라우터 (Model Router)를 단순히 또 다른 배포 (deployment)로 취급하는 것이 여기서 유용한 이유는, 애플리케이션 코드 내에서 이것이 단지 모델 파라미터 (model parameter)에 불과하기 때문입니다.

만약 이것이 없었다면, 서로 다른 모델로 라우팅을 수행하기 위해 자체적인 분류기 (classifier)를 구현해야 했을 것이며, 이는 더 많은 코드를 필요로 했을 것입니다.

라우팅 결정 사항을 관찰하려면, 각 응답에는 라우터에 의해 어떤 모델이 선택되었는지 보여주는 model 필드가 포함됩니다. 이 필드를 사용하여 에이전트의 상호작용 전반에 걸친 라우팅 분포 (routing distribution)를 추적할 수 있습니다:

def _record(response: Any, elapsed_ms: float) -> RequestRecord:
    usage = getattr(response, "usage", None)
    details = getattr(usage, "input_tokens_details", None)
...

샘플 실행하기 (Running our sample)

중고 보드를 하나 사봅시다! 다음 리스팅을 살펴보세요:

{
"L04": {
    "brand": "Santa Cruz",
...

Santa Cruz Screaming Hand 디자인은 꽤 멋져 보이고, 가격이 단돈 40달러라면 아주 좋은 거래입니다!

하지만 너무 조건이 좋지 않나요? 게다가 설명이 약간 수상해 보입니다 (항상 당신에게 긴박감을 심어주려는 판매자를 주의하세요. 사기일 수 있습니다). 우리 에이전트들에게 확인을 요청해 봅시다.

먼저 데크(deck)에 대한 기본적인 사실들을 알아봅시다:

L04  Santa Cruz Screaming Hand, 상태 좋음, 40 AUD

사용자> 이 데크의 너비는 얼마인가요?
...

이것은 데크에 관한 사실을 묻는 간단한 질문입니다. 따라서 우리가 볼 수 있듯이, 트리아지 에이전트(triage agent)는 gpt-5-nano를 사용하여 우리의 질문을 스펙 에이전트(spec agent)로 라우팅(routing)하며, 스펙 에이전트는 더 저렴한 모델을 사용하여 우리를 대신해 간단한 사실 확인(fact check)을 수행할 수 있습니다.

이제 40달러라는 가격이 이 보드에 적절한 가격인지 확인해 봅시다: