라우터 패턴은 저평가되어 있다: 지능형 에이전트 선택으로 토큰 비용을 60% 절감한 방법

저는 한 번에 $340가 소진되는 연구 파이프라인을 본 적이 있습니다. 실패해서가 아니라 성공했기 때문입니다. 스물세 단계의 모든 과정이 최첨단 모델(frontier model)로 라우팅되었고, 그중 19단계는 JSON 형식 지정, 날짜 추출, 지원 티켓 분류였습니다. 저는 자전거가 할 수 있는 일에 캐딜락 가격을 지불하고 있었습니다.

그것은 제가 모델을 탓하는 것을 멈추고 라우터(router)를 보기 시작한 날이었습니다.

모델이 생각하기 전에 청구서가 도착한다

에이전트 비용 폭발의 수학적 원리는 속임수처럼 간단합니다. Claude Opus 같은 최첨단 모델은 Claude Haiku 같은 소형 모델보다 토큰당 비용이 5배에서 25배까지 높습니다. 단 한 번의 호출에서는 사소한 오차일 수 있습니다. 하지만 다섯 개의 최첨단 호출이 연결되는 7단계 워크플로우에서는 동등한 소형 모델 파이프라인을 훨씬 초과하는 규모로 운영하게 됩니다.

연구는 이미 제 청구서가 알고 있던 것을 확인시켜 주었습니다. 프로덕션 환경의 다중 에이전트 실행에서, 수동으로 조정된(hand-tuned) 개별 에이전트 모델 바인딩 — 플래너(planner)는 소형 모델에, 리뷰어(reviewer)는 최첨단 모델에, 라이터(writer)는 소형 모델에 — 은 에이전트가 수행하는 모든 호출을 실제 호출의 난이도와 관계없이 동일한 모델로 보냅니다. 리뷰어가 태스크당 6번 호출하는 과정은 '모듈 요약'부터 '동시성 버그 찾기'까지 다양했지만, 에이전트가 최첨단 모델에 바인딩되어 있었기 때문에 모두 그곳으로 갔습니다.

핵심은 어떤 호출이 비용을 발생시키는지입니다. 호출별 라우팅(Per-call routing)은 16번의 호출 중 단 2번만 최첨단 모델로 보내는 데 성공했고, 리뷰어당 1,000건 검토에 $1.37가 들었습니다. 이는 모든 것을 최첨단 모델로 보낼 때 비용의 5분의 1이며, 개별 에이전트 설정보다도 절반 이하의 비용입니다. 또한, 이 방법은 6개의 시드 버그 중 4개를 찾아내어 모든 호출을 최첨단 모델로 보낸 경우와 일치했고, 3개를 찾은 개별 에이전트 바인딩보다 우수했습니다.

저는 잘못된 문제를 해결하고 있었습니다. 저는 애초에 그 작업으로 처리되어서는 안 되는 모델의 프롬프트를 계속 최적화하고 있었던 것입니다.

아키텍처를 바꾼 통찰력

동료 한 명이 제 추적 기록을 보고 모든 것을 재정립하는 질문을 했습니다.

답은 당황스러웠다. 나는 에이전트당 하나의 모델을 구성했었다. 기본 설정이었기 때문에 모든 단계에서 그것을 사용했다. 각 단계가 정말로 그것을 '필요'하는지 생각해 본 적이 없었다.

그때서야 모델 선택이 에이전트 단위 결정이 아니라 호출(call) 단위의 결정이라는 것을 깨달았다. 계획(planning) 단계는 진정으로 최첨단 수준의 추론 능력을 요구한다. 그 뒤를 잇는 포맷팅(formatting) 단계는 7B 모델만 필요할 뿐, 더 이상 아무것도 필요하지 않다. 이 둘을 동일하게 취급하는 것은 시니어 아키텍트를 고용해서 서류 작업을 처리하게 하는 것과 같은 구조적 오류에 해당한다.

vLLM 팀의 관점은 내가 모니터에 붙여두는 내용이다: 에이전트에 모델을 바인딩하는 것은 "아직 아무도 보지 못한 작업에 대한 예측"일 뿐이다. 이 작업은 호출 스트림(stream of calls)으로 도착하며, 에이전트당 바인딩은 그 모든 호출에 동일한 답변—어렵든 사소하든—을 부여한다.

역량 기반 라우팅: 에이전트가 아닌 호출과 일치시키기

이 문제를 해결한 패턴을 역량 기반 라우팅(capability-based routing) 또는 의미론적 라우팅(semantic routing)이라고 부르며, 그 원리는 놀라울 정도로 간단하다. 각 호출이 무엇을 필요로 하는지 분류하고, 가장 저렴하면서 충분한 모델로 라우팅하며, 게이트가 출력을 거부할 때만 에스컬레이션하는 것이다.

Federation of Agents 논문은 이 메커니즘을 공식화했다: **버전별 역량 벡터(Versioned Capability Vectors, VCVs)**는 기계가 읽을 수 있는 프로필로, 의미론적 임베딩(semantic embeddings)을 통해 에이전트의 역량을 검색 가능하게 만들어준다. 이를 통해 에이전트는 자신의 역량, 비용, 그리고 한계를 광고할 수 있다. 라우팅 계층은 샤딩된 HNSW 인덱스(sharded HNSW indices)를 통해 작업과 에이전트를 매칭하는 동시에, 비용 편향 최적화(cost-biased optimization)를 통해 운영 제약 조건을 강제한다.

Equinix의 LatentGate 논문은 이를 엔터프라이즈 관점에서 설명합니다. 100개의 전문 에이전트가 있는 환경에서, 라우터는 자연어 입력을 올바른 에이전트에 매핑해야 하며 동시에 세 가지 제약 조건을 만족시켜야 합니다: 100ms 미만의 지연 시간(latency), 높은 정밀도(라우팅 오류는 잘못된 API 호출을 유발함), 그리고 새로운 에이전트에 대한 낮은 비용의 온보딩입니다. 프롬프트 기반 LLM 라우팅은 강력한 의미론적 추론을 제공하지만, 엄청난 지연 시간을 초래합니다 — 대략 15002000ms — 그리고 100개 에이전트에서는 정확도가 7077%로 떨어집니다. 해결책은 더 큰 라우터가 아닙니다. 의미론적으로 유사하지만 기능적으로는 구별되는 에이전트를 같은 임베딩 콘(embedding cone)으로 붕괴시키지 않는 표현 방식입니다.

순진한 캐스케이드(cascade)에는 함정이 있습니다. 추격할지 여부를 결정하는 게이트가 바로 핵심 부품입니다. 출력 형태만 검사하는 게이트는 잘못된 답변을 그대로 통과시킬 수 있습니다. 왜냐하면 형식이 맞지 않은 JSON은 잡기 쉽지만, 자신감 있게 틀린 추출 결과물은 정확한 것과 똑같이 보이기 때문입니다.

연구가 실제로 정량화하는 내용

2026년의 문헌들은 이론을 넘어섰습니다. 수치들이 구체적입니다.

MTRouter는 상호작용 이력(interaction history)과 후보 모델들을 결합된 히스토리-모델 임베딩으로 인코딩하고, 기록된 궤적(logged trajectories)으로부터 결과 추정기(outcome estimator)를 학습하여 턴 레벨(turn-level) 모델 유틸리티를 예측합니다. ScienceWorld에서는 GPT-5를 능가하는 성능을 보이면서도 총 비용을 58.7% 절감했습니다. Humanity's Last Exam에서는 GPT-5 대비 총 비용을 43.4% 절감하면서 경쟁력 있는 정확도를 달성했습니다. 이는 이전의 멀티턴 라우터보다 모델 전환 횟수가 적고 일시적인 오류에 더 관대합니다.

Planner-as-Router는 모델 계층(model-tier) 선택을 계획 자체에 통합합니다. 플래너가 질의를 하위 작업(subtasks)으로 분해함에 따라, 각 작업에 작은(small), 중간(mid), 또는 최첨단(frontier)과 같은 모델 크기 계층을 할당하여 어떤 전문 에이전트가 실행되기 전에 의존성을 가시화합니다. 54개의 엔터프라이즈 에이전틱 태스크를 아우르는 1,157개 평가에서, 이는 모든 최첨단 라우팅 대비 비용을 44% 절감하면서도 정확도를 단 2.9 포인트만 포기했습니다.

RouterHGC는 사용자 질의, 협업 모드, 에이전트 역할, LLM을 포함하는 이종 그래프(heterogeneous graph) 상에서의 노드 선택으로 라우팅을 공식화합니다. 이는 MATH와 HotpotQA에서 0.80%~6.17%의 정확도 향상을 달성하는 동시에 추론 비용을 27.40% 절감합니다.

L7은 모델별 Beta 분포에 대한 Thompson Sampling을 사용하는 베이즈 라우팅 프레임워크로, 10,000개의 이종 벤치마크 작업 전반에 걸쳐 정적 라운드 로빈(static round-robin) 기준 대비 총 추론 비용 68.5% 감소를 입증했습니다. 이는 학습 데이터가 필요 없으며, 균일 사전 분포(uniform prior)에서 온라인 업데이트로 작동합니다.

이 모든 사례에서 일관되게 발견되는 점은 다음과 같습니다: 호출 복잡도(call complexity)가 단일 에이전트의 작업 부하 내에서도 광범위하게 변하기 때문에 단계별 라우팅(step-level routing)이 에이전트 수준 라우팅(agent-level routing)보다 우수합니다.

아무도 경고해주지 않는 비용 역설 (The Cost Paradox Nobody Warns You About)

이것은 제가 이해하는 데 3주, 수정하는 데 2개월이 걸린 부분입니다.

멀티턴(multi-turn) 에이전트에서 라우팅을 잘못 구현하면 아예 라우팅을 하지 않았을 때보다 더 많은 비용을 지불할 수 있습니다.

그 이유는 프롬프트 캐싱(prompt caching) 때문입니다. 에이전트 세션의 3번째 턴(Turn 3)에 이르러, 캐시된 토큰이 전체 토큰 페이로드의 대부분을 차지합니다. 이것이 바로 보호하고 있는 효율성입니다.

세션 중간에 모델을 전환하는 것은 그 보호막을 완전히 파괴합니다. 모든 제공업체의 캐시는 모델별로 특화되어 있습니다. 새로운 모델은 이전 모델이 저장한 기록에 접근할 수 없으며, 전체 대화를 처음부터 다시 읽어야 하므로 최대 입력 토큰 비용(full input token cost)이 발생합니다.

이것이 바로 vLLM Semantic Router 팀이 **세션 인식 에이전트 라우팅(Session-Aware Agentic Routing, SAAR)**을 구축한 이유입니다. 핵심 통찰은 라우터가 현재 요청에 어떤 모델이 가장 적합한지만 아는 것이 아니라, 모델 전환 시 세션이 깨지는지 여부를 알아야 한다는 것입니다. SAAR은 라우터 소유의 세션 메모리, 도구 루프와 비포터블(non-portable) 제공업체 상태 주변의 하드 잠금 장치(hard locks), 안전한 리셋 경계(safe reset boundaries), 그리고 프리픽스 캐시 인식 스위치 가격 책정 기능을 추가합니다. 21,600회의 결정론적 턴(deterministic turns)에 걸쳐 SAAR은 모델 전환을 79.29% 줄이고, 3,836개의 안전하지 않은 전환을 제거하며, 추정 물리-모델 비용을 78.71% 절감합니다.

제가 저지른 실수는 세션 전반에 걸쳐(across) 라우팅하는 것이었습니다. 해결책은 단계 내에서(within) 라우팅하는 것입니다. 즉, 각 생성마다 모델을 선택하고, 그것을 완료한 다음, 원래의 세션 모델로 돌아오는 방식입니다. 또는 더 나아가: 전환하기 전에 컨텍스트를 요약하여, 새 모델이 콜드 캐시(cold cache) 대신 압축된 히스토리로 시작하게 하는 것입니다.

실제 적용 사례 (Who's Actually Shipping This)

Barclays는 네 개의 에이전트로 구성된 풀-리퀘스트 검토 크루에 대한 통제 실험을 수행했습니다. 모든 프론티어(frontier) 모델은 1,000개 리뷰당 약 $7의 비용이 들었습니다. 에이전트당 바인딩 비용은 약 $3이었습니다. vLLM Semantic Router를 사용한 호출별 라우팅 비용은 $1.37로, 모든 프론티어 모델을 사용하는 방식보다 5분의 1 수준이며, 에이전트당 방식의 절반에도 미치지 못하면서도 프론티어 기준선과 동일한 버그 감지율을 보였습니다. 이 라우터는 p50에서 각 결정에 1.86ms를 추가했습니다.

Equinix는 LatentGate를 5개의 SLM 백본(backbones) 및 100개의 엔터프라이즈 에이전트에 걸쳐 배포했으며, 자연어 질의에 대해 **도메인 내 정확도 98.8%와 도메인 외 정확도 80.0%**를 달성했습니다. 이는 임베딩 기준선보다 13점에서 22점 높은 수치이며, T4 GPU에서 약 28ms의 속도를 보였고, SLM 포워드 패스는 에이전트 개수와 무관하게 작동했습니다.

Microsoft Foundry는 에이전트가 요청할 때 최적의 LLM을 선택하는 모델 라우터(Model Router)를 드롭인 배포 형태로 제공합니다. 간단한 인사말은 빠르고 저렴한 모델로 연결됩니다. 복잡한 도구 호출 체인은 최첨단 모델(frontier model)로 연결됩니다. 서로 다른 에이전트마다 다른 라우터를 할당할 수 있으며, 각 라우터는 자체적인 라우팅 모드와 모델 서브셋을 가지므로 배포를 각 에이전트의 비용 프로파일에 맞출 수 있습니다.

Red Hat의 vLLM Semantic Router 벤치마크 결과는 가장 구체적입니다: 자동 추론 모드 조정(auto reasoning mode adjustment)을 통해 +10.2% 정확도, -47.1% 지연 시간(latency), 그리고 -48.5% 토큰 사용량을 달성했습니다. 비즈니스 및 경제 도메인에서는 정확도 향상이 20%를 초과합니다.

아키텍처에 적용하는 방법 (Where This Fits in Your Architecture)

계층적 라우팅(Tiered routing)은 기본 기능이 아닙니다. 특정 문제에 대한 대응책입니다.

에이전트 워크로드가 호출 수준에서 복잡도 편차를 가질 때 사용하세요. 계획 및 합성 호출(Planning and synthesis calls)에는 최첨단 추론(frontier reasoning)이 필요합니다. 추출, 형식 지정, 분류 호출에는 그렇지 않습니다. 모든 호출이 진정으로 최첨단 기능을 요구한다면, 라우팅은 도움이 되지 않을 것입니다.

토큰 볼륨이 충분히 높아 절감액이 인프라 비용을 정당화할 때 사용하세요. 월 $50 청구서에서 40%를 절약해 주는 라우터는 구축할 가치가 없습니다. 하지만 월 $50,000 청구서에서 40%를 절약해 주는 라우터는 가치가 있습니다.

쿼리 수준 기능이 아닌 단계(step) 수준 기능을 사용하세요. 연구에 따르면 단일 턴 라우터(single-turn routers)는 궤적 컨텍스트(trajectory context)를 놓치기 때문에 에이전트 단계를 잘못 라우팅합니다. TwinRouterBench가 존재하는 이유도 바로 이것입니다. 기존 벤치마크들은 라우터를 오직 원샷 프롬프트(one-shot prompts)로만 평가하고, 중간 에이전트 단계에서 라우터가 볼 수 있는 접두사(prefix)를 결코 노출하지 않기 때문입니다. 중요한 기능은 단계에서 사용 가능한 것들입니다: 지침(instruction), 누적 컨텍스트 길이(accumulated context length), 이전 단계의 계층(prior step's tier), 그리고 의존성 구조(dependency structure)입니다.

요약 없이 세션 간 라우팅을 하지 마세요. 캐시 페널티가 절감액을 모두 먹어치울 것입니다. 단일 단계 내에서 라우팅하거나, 전환하기 전에 요약하세요. SAAR의 세션 잠금(session locks)은 이 원칙의 프로덕션 구현 사례입니다.

포기해야 하는 트레이드오프

Capability 기반 라우팅은 비용 절감과 종종 낮은 지연 시간을 제공합니다. 하지만 결정론(determinism)을 포기하고 스택에 분류기(classifier)를 추가하는 대가를 치러야 합니다.

라우팅 결정이 이루어질 때마다 잘못된 경로로 전송될 위험이 있습니다. 저렴한 모델로 보낸 복잡한 호출이 실패하면, 그 저가 시도 비용과 에스컬레이션 비용, 그리고 둘의 지연 시간을 모두 지불해야 합니다. 게이트웨이(gate)의 오탐지율 — 사다리가 아니라 — 이 연쇄 과정이 수익성이 있는지 결정합니다. 만약 여러분의 게이트가 잘못된 답변을 수락한다면, 할인 가격으로 그 답변들을 배포하게 되고, 절감액은 거짓말이 됩니다.

게다가 더 많은 움직이는 부품들(moving parts)을 받아들이는 것입니다. 라우터, 게이트, 티어 구성, 티어별 비용 추적. 이 모든 것이 독립적으로 실패할 수 있는 요소입니다. vLLM Semantic Router의 실패 모드들은 교훈적입니다: 신뢰도가 낮은 답변은 자동으로 에스컬레이션되고, 제공업체(provider) 장애는 회로 차단기(circuit breakers)를 작동시키며, 예산 소진은 에스컬레이션을 멈추고 사용 가능한 최상의 응답을 반환합니다. 이 중 어느 것도 공짜가 아닙니다.

하지만 측정 가능한 품질 저하 없이 청구서가 68%나 줄어드는 것을 지켜보면서 제가 배운 것은 이것입니다: 에이전트(agent)로 성공하고 있는 팀들은 모든 것에 최고의 모델을 사용하지 않는다는 것입니다. 그들은 각 호출에 맞는 올바른 모델을 사용합니다 — 그리고 '올바르다'는 것이 명시적으로 결정할 가치가 있다는 것을 받아들였습니다.

그래서 제 질문은 이렇습니다: 만약 여러분의 에이전트 비용 내역을 호출별로 분석한다면, 의도적으로 모델을 선택했을 때 그중 몇 개의 호출에 대해 최고 수준(frontier) 가격을 지불했겠습니까?

어떤 결과에 도달했는지 듣고 싶습니다. 크루(crew) 앞에 배치된 시맨틱 라우터, 방어해 온 에이전트별 바인딩, 온라인으로 학습하는 베이지안 정책(Bayesian policy), 아니면 마침내 여러분의 눈길을 끈 청구서 — 그리고 무엇이 변화를 가져왔는지요?