원문: Smart Routing in Unity AI Gateway: Match frontier quality with 30%+ lower cost per task 저자: Ankit Mathur, Ivan Zhou, Bryan Qiu, Rohit Agrawal, Elise Gonzales, Kelly Albano 게시일: 2026년 8월 13일
요약
- Smart Routing 은 코딩 작업을 복잡도에 따라 적절한 모델로 자동 라우팅해, 개발자 생산성을 해치지 않으면서 비용을 줄이는 Unity AI Gateway 의 새 기능입니다(현재 Beta).
- 작업 인식(task-aware) 라우팅 방식을 채택해, 세션 시작 시 작업 복잡도를 판단하고 모델·하니스를 선택한 뒤 세션 내내 유지합니다. 이렇게 하면 캐시 적중률(cache hit rate) 을 보존해 대규모에서의 비용을 낮춥니다.
- 내부 벤치마크에서 35% 비용 절감, 공개 벤치마크에서 56% 비용 절감을 달성했으며, Opus 5 같은 선도 모델 대비 작업당 65% 비용으로 그 성능을 뛰어넘거나 절반 이하 비용으로 성능을 맞췄습니다.
코딩 작업의 가격·성능 프런티어에는 엄청나게 다양한 모델과 하니스(harness)가 존재합니다. 2026년 한 해에만 33개의 새 모델이 출시되는 것을 봤습니다. Databricks 코드베이스를 대상으로 한 벤치마킹에 관한 이전 글에서, 우리는 모델들이 역량 계층(capability tier)으로 군집을 이루며 일상적인 작업의 상당수(예: 플래그 하나 뒤집기, 단일 파일 편집, 범위가 잘 잡힌 버그 수정)는 가장 비싼 모델을 필요로 하지 않는다는 것을 발견했습니다. 그렇다면 개발자 생산성을 희생하지 않으면서 AI 코딩 비용을 줄이려면 어떻게 해야 할까요? 가장 큰 기회 중 하나는 모든 작업을 가장 유능한(그리고 가장 비싼) 옵션으로 기본 처리하는 대신, 각 작업을 적절한 모델에 매칭하는 것입니다. 저비용 모델을 활용하기만 해도 50% 이상 절감할 수 있지만, 사용자에게는 이것이 몹시 부담스러운 일입니다. 훌륭한 모델과 유능한 하니스가 넘쳐 나면서, 코딩 에이전트 사용자는 끊임없이 선택 과부하(choice overload)에 시달립니다. 매 작업마다 최적의 모델을 고르느라 시간을 낭비하는 대신, 많은 이들이 가장 유능한 모델을 최고 노력(highest effort)으로 설정해 두고 넘어가 버립니다. 우리는 사용자에게 선택을 강요하거나 하드 캡(hard cap)으로 생산성을 억누르는 대신, 혁신이 필요하다고 판단했습니다.
그래서 우리는 Unity AI Gateway 의 다음 주요 비용 통제 기능인 Smart Routing 을 출시합니다(현재 Beta). Unity AI Gateway 는 전사에 걸쳐 AI 에 대한 접근을 제공하고, 지출을 관리하며, 통제를 강제하는 중앙 지점입니다. 여기에 Smart Routing 이 작업을 복잡도에 따라 적절한 모델에 자동으로 매칭하는 지능형 최적화를 더합니다. Smart Routing 은 Claude Code 와 Codex 에서 곧바로 동작하므로, 개발자가 이미 쓰고 있는 도구를 그대로 최적화할 수 있습니다.
그리고 우리는 모델 라우팅을 넘어섭니다. 코딩 에이전트를 위한 메타 하니스(meta-harness)인 Omnigent 를 활용하면, 팀은 모델과 코딩 하니스 양쪽에 걸쳐 최적화하는 Smart Routing 의 온전한 힘을 누릴 수 있습니다. 개발자가 직접 고를 필요 없이, 작업에 맞는 조합을 제공하는 것입니다.
결과가 모든 것을 말해 줍니다. 내부 코딩 워크로드에서 Smart Routing 은 Opus 5 같은 선도 모델의 작업당 비용의 단 65% 로, 그 어떤 단일 모델보다도 뛰어난 성과를 냈습니다. 공개 벤치마크에서는 절반 이하의 비용으로 Opus 5 의 성능을 맞췄습니다.
우리가 배운 것은 다음과 같습니다.
- 승리의 대부분은 더 단순한 작업에 더 저렴한 모델을 쓰는 데서 나옵니다. 내부적으로 우리는 매우 다양한 작업을 마주하며, 그 대부분은 프리미엄 모델이 필요 없습니다. 우리는 라우터가 단순한 작업에는 더 저렴한 모델을 고르되, 프런티어 모델의 성능이 필요한 복잡한 작업은 “에스컬레이트(escalate)” 하도록 구성했습니다.
- 작업 시작 시점에 확보 가능한 정보(설명과 메타데이터)만으로도 좋은 결과를 얻었습니다. 우리는 정답, 테스트, 리포지토리에 관한 어떤 정보도 제공하지 않았지만, Smart Routing 은 여전히 효과적으로 선택할 수 있었습니다.
- 작업 복잡도를 효과적으로 가늠하고 필요할 때 에스컬레이트하는 데는 아직 개선의 여지가 큽니다. 완벽한 예지력을 가진 라우터라면 우리 라우터가 쓰는 비용의 극히 일부로 모든 단일 모델을 이길 것이며, 실제 세션에서는 작업이 진행 중에 더 복잡해졌는지를 중간에 재평가하는 것도 도움이 될 수 있습니다. 이 격차를 좁히는 것은 연구 문제이자 하니스 설계 문제입니다. 우리는 이를 개선하기 위해 실제 사용자 피드백에서 배워야 합니다.
지능형 모델 라우팅은 어떻게 작동하는가?
지능형 모델 라우팅은 복잡도, 역량, 비용 같은 요소를 바탕으로 작업에 가장 적합한 모델을 선택합니다. 코딩 에이전트에서 중요한 결정 하나는, 그 라우팅이 언제 일어나야 하는가입니다. 라우팅에는 일반적으로 두 가지 접근법이 있습니다.- 요청별 라우팅(Per-request routing). 주어진 세션 안에서, 일부 팀은 해당 메시지의 프롬프트 복잡도만으로 각 요청을 라우팅하는 방식을 탐구해 왔습니다. 문제는, 대규모에서는 비용이 캐시 적중률(cache hit rate) 에 좌우된다는 점입니다. 높은 캐시 적중률을 유지하려면 연속된 턴(turn)을 같은 모델로(그리고 현재 인기 모델의 경우 같은 노력 수준으로) 라우팅해야 합니다.
- 작업 인식 라우팅(Task-aware routing). 세션 시작 시 작업의 복잡도를 평가한 뒤, 그 세션 내내 유지할 모델과 하니스를 제안합니다. 이 방식은 캐시 적중률을 보존하며, 캐시가 오래되었을 때(예: 컴팩션 이벤트가 발생할 때) 필요에 따라 업그레이드하거나 다운그레이드하는 등 향후 최적화의 기회를 제공합니다.
우리의 Smart Router 가 작동하는 방식
우리는 캐시 효율을 보존하면서 각 코딩 작업을 적절한 모델과 하니스에 매칭하기 위해 작업 인식 라우팅을 택했습니다. 가장 흥미로운 문제는, 작업을 시작하기도 전에 그것이 얼마나 어려운지를 판단하는 일입니다. 우리는 단순하게 시작하고 싶었기에, 현재 라우터는 하나의 정책(single policy)을 모든 작업에 동일하게 적용합니다. 먼저, 작업을 분류합니다. 이를 위해 저렴하고 지연이 낮은 모델을 사용해 작업 설명을 읽고 몇 가지 시맨틱 필드로 라벨링합니다. 시스템의 어느 부분이 바뀌는지, 프롬프트가 어떤 코드 증거(코드 스니펫, 트레이스백, 혹은 명시적인 것 없음)를 담고 있는지, 어떻게 실패하는 것으로 보이는지, 수정 범위가 얼마나 국소적인지, 어떤 종류의 프로젝트에 속하는지 등입니다. 이로부터 라우터는 작업 유형 계열(task-type family)과 언어 계열(language family)을 도출합니다. 프런티어 모델을 쓰면 (우리가 아끼고 싶은 단순한 작업까지 포함해) 모든 요청에 세금이 붙으므로, 이 추출기(extractor)는 의도적으로 작고 빠르게 만들었습니다. 그다음, 어떤 모델 클래스가 최적인지를 삼각 측량(triangulate)합니다. 라우터는 중간 크기 모델을 기본으로 두고, 라벨을 사용해 어느 쪽으로든 움직입니다. 작업이 프런티어 수준의 역량과 지식을 요구할 때는 더 비싼 모델로 에스컬레이트하고, 그렇지 않을 때는 더 저렴한 모델로 위임(delegate down)합니다. 즉 하나의 정책으로 모델 전체 스위트를 활용할 수 있습니다. 초기 결과는 유망합니다. 어떤 연구소도 접근한 적 없는 우리 자체 내부 벤치마크에서 35% 절감을 봤습니다. 결과가 일반화됨을 보여 주는 공개 코딩 벤치마크에서는 56% 비용 절감을 달성했습니다. 우리 자체 사용 사례에 대해 더 배우고 설계 파트너들과 함께하면서 이 수치가 더 커질 것으로 기대합니다.모델과 하니스에 걸쳐 코딩 작업을 어떻게 라우팅하는가?
Smart Routing 은 라우팅 결정을 처리하지만, 그다음에는 그 결정에 따라 실제로 행동할 수 있어야 합니다. Smart Routing 은 Claude Code 와 Codex 안에서 네이티브로 동작하지만, 코딩 에이전트의 경우 올바른 모델뿐 아니라 올바른 코딩 하니스까지 고를 때 더 나은 성능을 보입니다. 선택된 모델과 하니스를 엔지니어가 활용하도록 돕기 위해서는, 개별 코딩 세션 위에 앉아 세션 전반을 오케스트레이션하는 계층이 필요합니다. 우리가 Omnigent 를 만든 이유입니다.
Smart Routing 은 Omnigent 안에서 두 개의 층위로 구현됩니다.
첫째, Omnigent 를 쓰는 개발자는 특정 코딩 하니스를 수동으로 고르는 대신 Smart Routing 을 선택할 수 있습니다. 그러면 Omnigent 가 각 작업에 대해 하니스와 모델을 모두 자동으로 선택하며, 모델 라우팅은 Unity AI Gateway 의 Smart Routing 으로 구동됩니다. 이 설계는 개발자와 관리자에게 조직 수준의 가이드나 이전 대화 이력 사용 여부 같은 커스터마이징을 제공할 자유를 주며, 그때마다 클라이언트를 바꿀 필요가 없습니다.
이는 또한 모든 서브에이전트 실행이 Smart Routing API 를 거친다는 뜻이며, 덕분에 서브에이전트가 서로 다른 하니스와 모델을 활용할 수 있습니다. 사용자의 최초 프롬프트는 종종 불충분하게 명세되어 복잡도를 판단하기 어렵습니다. 서브에이전트는 새로운 정보를 바탕으로, 신선한 캐시와 명확한 지시로 새 작업을 조정할 수 있게 해 줍니다. 하나의 작업이 계획 수립과 병렬 서브에이전트 작업 전반에 걸쳐 섬세한 라우팅 결정을 겪을 수 있습니다(예: 대규모 코드베이스 요약 작업은 더 저렴한 모델로 라우팅하면서 아키텍처 설계는 더 비싼 모델로 처리). 이는 훨씬 더 큰 절감으로 이어집니다.
모델 라우팅이 작동하는지 어떻게 평가하는가?
효과적인 모델 라우팅은 비용만이 아니라 비용과 개발자 생산성을 동시에 최적화해야 합니다. 라우터는 아직 초기 기술이라 상당한 반복 개선이 필요하므로, 피드백 신호를 갖추는 것이 결정적입니다. 우리의 첫 단계는 이후 평가를 위해 모든 코딩 세션 트레이스(trace)를 로깅하는 것이었습니다. 우리는 비용과 개발자 경험을 모두 고려하고자 합니다 — 생산성을 희생해 비용을 최적화하고 싶지는 않습니다. Unity AI Gateway 를 사용하면 코딩 에이전트의 트레이스를 Unity Catalog 에 기록할 수 있습니다. 이는 매우 민감한 데이터이며, 성숙한 대부분의 기업에서는 정교한 태깅과 접근 정책으로 거버넌스된 상태를 유지해야 합니다. 우리는 AI 모델과 사람의 검토를 모두 사용해 트레이스를 분석하고 라우터 변경을 평가했습니다. 라우팅 이전의 우리 자체 세션에 이 분석을 돌려 보니, 상당수 세션이 필요하지도 않은 작업에 프런티어 모델 비용을 쓰고 있었습니다. 단지 기본 모델이 가장 비싼 모델이었기 때문입니다. 실무적으로 라우터가 유용한지 검증하는 방법은, 다음 지표들을 지속적으로 모니터링하는 것입니다.- 모델별 세션 분포(breakdown)
- 라우팅된 모델이 엔드투엔드로 완료한 세션 수
- 라우팅으로 인한 절감액(달러)
지능형 모델 라우팅을 다음으로 어디까지 끌고 갈 것인가
우리는 이것이 상당한 기회가 있는 영역이라고 믿으며, 여기서 실질적인 연구를 계속할 계획입니다. 아직 초기 단계라 배울 것이 많습니다. 우리의 첫 번째 과제는, 실제 사용자 행동과 맞지 않는 신뢰할 수 없는 벤치마크 데이터였습니다. 벤치마크 작업은 유난히 얌전해서, 저마다 자기 완결적인 작업 명세로 도착합니다. 라우터가 그런 작업에서는 잘 동작하지만, 실제 세션은 전혀 그렇지 않은 경우가 많습니다.- 여는 프롬프트(opening prompt)는 좀처럼 정밀하지 않습니다. 개발자가 처음 입력하는 것은 명세가 아니라 증상이나 대략적인 의도이기 때문입니다. 그런데 우리 라우터는 그 첫 메시지를 읽고 결정을 확정해 버립니다.
- 세션은 재사용됩니다. 그래서 첫 요청에는 맞았던 결정이 네 번째 요청에는 틀릴 수 있는데, 아무것도 라우터에게 다시 묻지 않습니다.
- 작업 범위 설정이 공짜인 곳에서 시작하기. PR 리뷰, 서브에이전트 실행, 배치 마이그레이션, 스케줄된 잡은 기계가 작업 명세를 작성했기 때문에 처음부터 완전히 명세되어 있습니다. 라우팅은 오늘날 누구의 습관도 바꾸지 않고 이 부류에서 잘 작동하며, 그래서 우리는 여기에 먼저 배포하고 있습니다.
- 첫 턴이 아니라 몇 턴 후에 라우팅하기. 대화형 작업에서 여는 프롬프트는 결정을 내리기에 가장 나쁜 순간이며, 그 순간에 결정하도록 강제하는 것은 아무것도 없습니다. 대신, 저렴한 모델이 초기 교환과 명확화 질문을 처리하게 한 뒤, 작업의 형태가 잡히면 그때 라우팅하는 것이 유용할 수 있습니다. 빠르고 작은 모델로 탐색하는 편이 낫기 때문에, 이렇게 하면 비용과 경험이 함께 개선됩니다.
- 세션을 더 작게 만들기. 하나의 작업에 머무는 세션이 더 잘 라우팅되고 비용도 덜 듭니다. 도구는 주제가 바뀔 때 새 세션을 여는 것이 자연스러운 선택이 되도록 유도할 수 있습니다.
- 전환을 저렴하게 만들기. 위의 모든 것은 세션 중간의 모델 변경이 감당할 만해야 성립합니다. 비용이 캐시 적중률에 좌우되는 오늘날의 세계에서, 세션 중간에 전환하는 것은 대규모에서는 감당하기 어렵습니다. 컨텍스트 컴팩션(context compaction)은 자연스러운 이음새(seam)입니다. 이미 캐시 미스가 그 지점에서 발생하고 있기 때문입니다(Cognition 의 Devin Fusion 이 하는 방식이 그렇습니다). 시간이 지나면 우리는 라우팅 계층이 캐시 미스를 라우터 사용 방식에 은근히 녹여 넣는 대신 명시적으로 가격 매기도록 만들고 싶습니다.
오늘 Smart Routing 을 사용해 보세요
Smart Routing 은 이제 Unity AI Gateway 를 통해 Beta 로 제공됩니다. 코딩 작업을 복잡도에 따라 적절한 모델로 자동 라우팅하여, 모든 작업에 최적의 모델을 선택함으로써 팀이 프런티어 수준의 성능을 30% 이상 절감된 비용으로 달성하도록 돕습니다. 개발자의 선택권이나 생산성을 제한하지 않으면서 AI 코딩 비용을 줄이려는 팀에게, Smart Routing 은 모델을 수동으로 고르거나 무딘 지출 상한에 의존하는 방식의 대안을 제공합니다. 그리고 Omnigent 를 사용하면 지능형 라우팅을 모델과 코딩 하니스 전반으로 확장할 수 있습니다. 시작하려면 문서 페이지를 방문하세요.- 모델 라우팅: Unity AI Gateway 를 통해 Smart Routing 활성화하기
- 모델 + 하니스 라우팅: Omnigent(v0.9.0+)와 함께 Smart Routing 사용하기