Agent-as-a-Router
2026-06 · arXiv:2606.22902 · NUS · DAMO · HKUST

코딩 작업을 위한
에이전트형 모델 라우팅

Agent-as-a-Router: Agentic Model Routing for Coding Tasks

현실의 사용자는 여러 제공자의 LLM에 접근할 수 있고, 각 모델은 서로 다른 영역에서 강하되 모든 영역을 지배하는 모델은 없다. 따라서 각 작업을 가장 적합한 모델로 보내는 라우팅이 성능과 비용 모두에서 중요해진다. 기존 라우터는 이를 정적 일회성 분류로 다루지만, 진짜 병목은 추론 능력이 아니라 정보 결핍이다.

+15.3% 차원별 성능 통계 부여 시 ~10K 작업 · 8개 모델 최저 누적 후회(regret)
C-A-F LOOP
C Context A Action F Feedback decide execute memorize
맥락 행동(모델 선택) 검증 피드백
§ 1 · INTRODUCTION

어떤 모델이 각 작업을 처리해야 하는가From provider-centric serving to user-centric routing

Claude Code, Codex 같은 현대 코딩 에이전트는 LLM을 코딩·디버깅·저장소 단위 프로그래밍의 상호작용 시스템으로 바꾸며 소프트웨어 개발에 큰 영향을 미쳤다. 그러나 대부분의 에이전트는 모든 작업을 동일한 단일 LLM으로 푼다.

이는 제공자 중심(provider-centric) 서빙 관점에서는 합리적이다. 제공자는 자사 모델과 예측 가능한 서빙 비용을 우선하기 때문이다. 그러나 작업 단위의 품질과 비용 효율이 우선인 사용자 중심(user-centric) 시나리오의 실제 요구는 간과한다. 8개 프런티어 모델을 여러 코딩 차원에서 실험하면 최적 모델은 작업마다 달라지며, 항상 전역 최강 모델을 고르는 전략조차 각 작업마다 최적 모델을 고르는 작업별 오라클(per-task oracle)에 뒤처진다. 작업마다 수동으로 최적 모델을 고르는 일은 대규모에서 불가능하므로, 자동 모델 라우팅이 핵심 기제로 떠오른다.

§ 3.1 · DIAGNOSIS

병목은 추론이 아니라 정보 결핍이다Information deficit, not reasoning failure

무엇이 라우터를 제약하는가. 추론 능력인가, 정보 접근인가. 이를 가리기 위해 LLM 라우터(Claude Sonnet 4.6)가 접근하는 정보만 바꾸는 절제 실험을 수행한다.

41.4%
Vanilla. 표준 제로샷 LLM 라우터. 작업 프롬프트만 보고 후보 풀에서 모델을 고른다.
47.7%
+Perf stats. 탐침(probing) 집합의 차원별 성능 통계를 추가하면 Vanilla 대비 상대 +15.3%.
47.5%
DimensionBest. 동일 통계를 인코딩한 최고 휴리스틱. +Perf stats가 이를 근소하게 능가한다.
절제(Ablation)해석AvgPerf%Perf/$
Oracle작업마다 최적 모델을 쓰는 이론적 상한57.008.20
DimensionBest사전지식으로 차원별 최적 모델 선택47.503.69
Vanilla표준 제로샷 LLM 라우터41.411.97
+Dimension+작업 차원 설명 추가41.181.81
+Perf stats+탐침 집합의 사전 성능 통계 추가47.741.71
표 1 · LLM-as-a-Router의 성능 병목 진단(Claude Sonnet 4.6, 2,919 작업). 사전 성능 통계 제공이 라우팅 성능을 크게 끌어올린다.

DimensionBest가 인코딩한 것과 동일한 통계를 받으면 LLM 라우터는 이를 넘어선다(47.74 대 47.50). 즉 라우터와 오라클 상한 사이 성능 격차의 큰 원천은 추론 능력 부족이 아니라 정보 결핍이다.

이 진단에서 두 가지 설계 통찰이 따라온다. 첫째, 라우터는 매 결정마다 새로운 실행 기반(execution-grounded) 정보를 획득해야 한다. 정적 사전지식이나 모델의 자기평가가 아니라, 선택한 모델의 출력을 실제로 샌드박스에서 실행해 얻은 성능 신호다(검증). 둘째, 라우터는 그 정보를 작업 스트림 전반에 축적해야 미래 결정이 과거 결과에 조건화될 수 있다(기억).

§ 3.2 · THE C-A-F LOOP

라우팅을 순환 루프로 형식화하다Context → Action → Feedback → Context

Agent-as-a-Router는 작업 스트림 위에서 동작하며 매 루프의 검증된 결과로 내부 상태를 갱신한다. 라우터는 인덱싱된 모델 풀 M에 접근하고, N개 작업 스트림을 하나씩 처리한다. 각 라우팅 결정 뒤 검증된 결과가 다음 결정의 맥락으로 되먹임된다.

ci  —decide→  ai  —execute→  fi  —memorize→  ci+1(1)

완료된 각 루프가 다음 루프를 더 정보에 밝게 만든다. C→A→F→C 순환은 작업 스트림이 진행됨에 따라 반복된다.

CONTEXT

맥락 ci

(p_i, d_i, H<i)

입력 프롬프트 p_i, 선택적 메타데이터 d_i(설명·난이도·언어), 그리고 이전 모든 루프에서 축적된 메모리 상태 H<i로 구성된다.

ACTION

행동 ai

a_i ∈ [M]

모델 풀 M에서 선택된 모델 m_{a_i}의 인덱스. 이번 작업에 어떤 모델을 호출할지를 결정한다.

FEEDBACK

피드백 fi

(ŝ_i, κ̂_i)

검증기가 관측한 성능 점수 ŝ_i ∈ [0,1]과, 토큰 소비·공식 단가로 계산한 금전 비용 κ̂_i. 메모리가 축적하는 실행 기반 피드백이다.

동치맥락적 멀티암드 밴딧

C-A-F 형식화는 c_i를 부가 정보, a_i를 암(arm) 당김, f_i를 피드백으로 보는 맥락적 멀티암드 밴딧 문제와 연결된다. 라우팅 정책은 모델 풀 위의 다항 분포 π(·|h_i)를 유도한다. 작업별 보상은 사용자가 정한 가중치 ε₁>0(성능 보상), ε₂<0(비용 벌점)로 결합된다.

ri(ai) = ε₁·si(ai) + ε₂·κi(ai)(2)

작업별 오라클은 보상 행렬 R을 완전히 안다는 가정 하에 각 작업에서 보상을 최대화하는 모델을 독립적으로 고른다. 이 작업별 오라클은 단일 전역 최적 모델에 전념하는 정책과는 일반적으로 같지 않다. 정책 π에 대해 누적 후회(cumulative regret)를 보고한다.

CumRegN(π) = Σi=1N δi = N·(V* − V(π))(7)

여기서 δ_i = r*_i − r_i(a_i) ≥ 0은 단일 작업 후회다. 누적 후회는 작업 스트림 전반의 누적 보상 격차를 측정하며, 낮을수록 최적에 가까운 라우팅이다.

대비세 가지 라우팅 전략

① STATIC MAPPING

휴리스틱 라우터

사전 설정 키워드와 엄격 매칭으로 룩업 테이블을 통해 직접 디스패치한다(예: DimensionBest). 정적 규칙이며 메모리·피드백이 없다.

② STATIC POLICY

학습 정책 라우터

학습된 정책 모델이 작업 특징을 모델 선택으로 사상한다. 의미 추론·분류는 하나 메모리가 없어 스트림 동안 적응하지 못한다.

③ AGENT-AS-A-ROUTER

자기진화 라우터

루프·메모리·도구·피드백을 모두 갖춘 반복 자기진화 라우터. 작업 스트림 안에서 검증 경험을 축적하며 진화한다.

§ 3.3 · ACROUTER

ACRouter: C-A-F의 구체화Orchestrator · Verifier · Memory

ACRouter(Agentic Coding Router)는 진단의 세 요구—결정 시점의 정보 통합, 매 루프의 새 실행 기반 정보 생산, 루프 간 축적—를 각각 오케스트레이터·검증기·메모리로 실현하고, 세 모듈이 모두 활성인 채 작업 스트림 위에서 진화한다.

오케스트레이터 — 정보 통합

동적 맥락에 기반해 라우팅 결정을 내린다. DimensionBest 사전지식, 메모리에서 kNN으로 검색한 상위 10개 과거 이웃, 작업 메타데이터를 종합한다. 핵심 정책은 CodeRouterBench 탐침 집합으로 미세조정한 비용 효율적 Qwen3.5-0.8B 모델이며, 가중 투표(weighted voting)로 휴리스틱 규칙과 결합한다.

검증기 — 정보 생산

모델 출력을 샌드박스에서 평가하고 여러 신호를 단일 성능 점수 u_i ∈ [0,1]로 집계한다.

ui = Σk∈K_d(t_i) wd(t_i),k · ŝk(ai, ti)(8)

d(t_i)는 작업 유형(실행 가능 여부 결정), K_d는 검증 도구 집합(AST 파싱, 샌드박스 실행 등), w는 유형별 가중치로 합이 1이다.

메모리 — 정보 축적

작업 임베딩(voyage-code-3 / BGE-large)으로 키를 잡는 온라인 벡터 저장소다. 값에는 선택 모델·성능·비용·검증 추적이 기록된다. 검색은 코사인 kNN으로 상위 10개 이웃을 가져와 오케스트레이터에 전달한다. 저장소는 2만 항목으로 FIFO 제한되고 매 시도 후 제자리에서 커밋된다. 정적 차원 해시 라우팅과 달리, 임베딩 기반 저장소는 세밀하고 맥락 인지적인 의사결정을 가능케 하며, 유사 작업에서 후보의 과거 성공과 최근 실패를 모두 오케스트레이터에 노출한다.

▷ 예시 작업 — 런타임 오류 수정
"제공된 클래스가 오류 메시지를 보인다… AttributeError: 'User' object has no attribute '_name'. 고쳐라."
api_llm (Qwen3.5-0.8B)→ MiniMax
logreg→ GLM-5
memory_KNN→ Kimi-K2.5
dim_best→ Kimi-K2.5
─ 가중 투표 점수: Kimi-K2.5 = 1.47 · MiniMax = 0.64 · GLM-5 = 0.43 ─
Argmax → Kimi-K2.5  → 버그 수정 · 코드 재실행 · 성공 반환

3.4C-A-F 구성으로 분해한 라우팅 정책

C-A-F 루프는 기존 전략을 점검하는 통합 관점을 제공한다. 구성요소(오케스트레이터·검증기·메모리)를 각각 제한하거나 제거해 베이스라인을 정리하면 자연스럽게 절제 연구가 설계된다.

방법 계열오케스트레이터검증기메모리
Single-Model (Always-m)직접 디스패치
Static: 휴리스틱 (DimensionBest, kNN)정적 룩업동결된 탐침 사전지식
Static: 학습 정책 (LogReg, RouteLLM, Qwen3.5-FT)학습 모델
Dynamic: 온라인 밴딧 (LinUCB, LinTS)argmax 규칙보상만암별 모수 사후분포
ACRouter (루프 완성)LLM 정책 + 도구샌드박스 네이티브온라인 작업 임베딩 kNN
표 4 · C-A-F 구성으로 정리한 라우팅 방법. 루프가 끊긴 방법은 메모리를 비우거나 동결하며, 루프가 완성된 ACRouter는 세 핵심 모듈을 모두 활성화한다.
§ 4 · CODEROUTERBENCH

스트리밍 라우팅을 위한 평가 환경~10K tasks · 10 dimensions · 8 frontier LLMs

스트리밍 라우팅에서 누적 후회를 평가하려면 작업별·모델별 결과가 미리 수집된 통제 환경이 필요하다. 기존 라우팅 벤치마크는 일회성 정확도만 측정해 이를 지원하지 못한다. 이에 10개 차원에 걸친 약 1만 코딩 작업으로 구성된 통합 테스트베드 CodeRouterBench를 도입한다.

10
코딩 차원 (9개 단일턴 ID + 1개 에이전트형 OOD)
7,080
탐침(probing) 집합 작업 — 라우터 개발용
2,919
분포 내(ID) 테스트 작업 · OOD 테스트 176

전체 작업은 널리 쓰이는 고품질 벤치마크 15종 이상에서 용도 변경했다. 7개 차원은 샌드박스 실행 기반 채점(pass@1)을, 3개 차원은 프록시 지표를 LLM-as-Judge로 보완해 쓴다. 3단계 파이프라인은 데이터 수집(15개 출처 → 약 1만 작업) → 모델 평가(8개 LLM의 관측 행렬 생성, 샌드박스·심사 채점) → 라우팅 평가(여러 라우팅 방법을 성능·비용 지표와 파레토 분석으로 비교)로 진행된다.

실세계 테스트 — 에이전트형 프로그래밍. 에이전트형 프로그래밍 차원은 C-A-F 형식화의 첫 OOD 검증으로 설정된다. 다단계 계획·파일 탐색·반복 디버깅이 필요해 9개 단일턴 차원과 질적으로 다르며, SWE-bench Verified·LongCLI-Bench·FeatureBench·SWE-CI에서 176개 작업을 추출하고 Docker 기반 샌드박스(mini-swe-agent + SWE-Bench harness, 40 step 제한)로 평가한다.

4.2모델 풀: 모든 차원을 지배하는 단일 모델은 없다

8개 프런티어 LLM(Claude Opus 4.6, Sonnet 4.6, GPT-5.4, Qwen3-Max, Qwen3.5-Plus, GLM-5, Kimi-K2.5, MiniMax-M2.7)을 평가한다. Claude Opus 4.6이 평균 최고(42.9%)지만, 알고리즘 설계는 GLM-5에(47.2 대 25.4, 상대 +86%), 테스트 생성은 Qwen3-Max에(82.7 대 39.2, 상대 +111%), 데이터 과학은 Kimi-K2.5에(18.4 대 14.2, +30%) 뒤진다. 9개 차원에서 5개의 서로 다른 모델이 차원별 최강으로 등장하며, 강한 모델일수록 비용이 높은 경향이 있어 라우팅의 가치를 성능·비용 양면에서 확인한다.

모델 / 차원생성알고버그완성리팩DS다언어이해테스트AVG
그림 4(a) · 탐침 집합에서 8개 모델 × 9개 차원 성능 히트맵(0–1 정규화). 금색 테두리는 차원별 최강. 최적 모델이 작업 영역마다 크게 달라진다.

비용도 극적으로 다르다. 풀에서 가장 비싼 모델(Claude Opus 4.6 출력 $25/M)은 가장 싼 모델(MiniMax-M2.7 출력 $1.20/M)의 20배가 넘는다. Claude Opus 4.6의 총비용은 Kimi-K2.5의 약 12배다.

§ 5 · EMPIRICAL VALIDATION

실험 결과ACRouter attains the lowest cumulative regret

ACRouter는 맥락을 동적으로 축적해 ID·OOD 양쪽에서 라우터 중 최고 AvgPerf를 달성하며, 최강 단일 모델 Opus-4.6을 항상 고르는 것보다 비용이 낮다.

지표 — AvgPerf: 전 작업 평균 성능. CumReg: 식 (7)의 종단 누적 후회(ε₁,ε₂ = 1, −0.1). Perf/$: AvgPerf%/비용. 값↑은 클수록, ↓은 작을수록 좋음.

라우터 분포 내 (n=2,919) OOD 테스트 (n=176)
AvgPerf↑CumReg↓Perf/$↑AvgPerf↑CumReg↓Perf/$↑
Oracle57.0008.2075.8902.32
ACRouter (ours)49.98205.53.7962.5017.01.18
LinTS46.48307.44.4946.4335.90.75
LinUCB46.84296.94.3849.8231.10.96
DimensionBest47.50277.43.69
kNN Retrieval47.18286.76.0714.2966.71.45
LogReg47.26284.46.2719.6461.81.17
RouteLLM-BERT47.22285.56.2221.4359.41.30
TF-IDF+MLP46.97292.86.1113.3967.91.17
Qwen3.5-0.8B-FT46.41309.16.8255.3627.20.74
RouteLLM-MF46.16316.56.198.9372.70.94
Always-Opus 4.643.83387.11.2957.1426.70.64
Always-Kimi-K2.536.66593.312.6218.7562.31.22
Random38.75533.62.4831.2550.40.85
표 3 · 구성 분류별 라우팅 결과. 왼쪽: 9개 단일턴 차원의 분포 내 테스트. 오른쪽: 에이전트형 프로그래밍 실세계 OOD 테스트. DimensionBest는 사전 정의된 차원→모델 매핑이 필요해 OOD에 적용 불가.

5.2주요 관찰

ID

ACRouter가 분포 내에서 최고

AvgPerf 49.98%, 누적 후회 205.5로 전 계열을 압도한다. 완전한 차원별 사전지식을 가진 DimensionBest를 AvgPerf 2.48점 앞선다.

OOD

분포 이동에도 일반화

OOD에서 62.50% AvgPerf로 최강 단일 모델 Always-Opus(57.14%)와 미세조정 Qwen3.5-0.8B(55.36%)를 모두 앞선다.

FRAGILE

정적 학습기는 OOD에서 붕괴

경량 분류기(LogReg, TF-IDF+MLP, RouteLLM-MF/BERT)는 ID에서 DimensionBest와 1.3% 이내지만, OOD AvgPerf는 8.93~21.43%로 급락해 Random(31.25%)보다도 낮다.

$$$

비용 효율도 우위

ACRouter의 Perf/$는 ID 3.79, OOD 1.18로 Always-Opus(1.29 / 0.64)를 모두 능가한다. Opus는 ID에서 $34.02를 쓰고도 ACRouter($13.21)에 6.15점 뒤진다.

맥락적 밴딧(LinUCB, LinTS)은 온라인 갱신을 계속해 OOD에서 49.82 / 46.43%로 더 잘 버티지만, 암별 선형 모델이 오케스트레이터·메모리가 주는 맥락 인지 추론을 결여해 AvgPerf와 CumReg 모두에서 ACRouter에 뒤진다. 정적 방법은 후회를 더 빨리 누적(경량 분류기 284–317)하고 밴딧이 약간 뒤따르며(297–307), 배포 중 메모리가 정보 격차를 메우는 ACRouter(205.5)만이 낮은 후회를 보인다.

왜 정적 베이스라인은 OOD에서 붕괴하는가. 9개 단일턴 탐침 차원은 짧은 단일 파일 작업이 지배하지만, OOD 집합은 다단계 계획·파일 탐색·반복 디버깅을 요구한다. 학습된 분류기는 OOD 분포에서 더는 같은 신호를 담지 않는 프롬프트 특징에 조건화되고, 평가 중 새 피드백을 획득할 수 없다. 반면 ACRouter와 온라인 밴딧은 OOD 스트림 동안 메모리나 암별 사후분포를 축적해 더 많은 신호를 회복한다.

D.3차원이 설명하는 신호는 27%뿐

작업별 오라클 결정이 값싼 구조 신호에서 얼마나 회복되는지 정량화하기 위해, 오라클이 할당한 모델 y_t와 작업 차원 d(t) 사이 상호정보 I(y_t; d(t))를 계산한다. 차원 정체성은 y_t 엔트로피의 약 27%만 포착한다. 이는 DimensionBest가 약 0.475 AvgPerf에 도달하는 이유를 설명하지만 0.570 작업별 오라클에는 한참 못 미친다. 나머지 라우팅 신호는 작업별 내용(알고리즘 선택, API 패턴, 경계 사례 처리)에 있으며, 이것이 바로 ACRouter의 작업 임베딩 메모리가 키로 잡는 대상이다. DimensionBest의 낮은 해상도 차원 해시가 아니다.

§ E.2 · PRACTITIONER'S GUIDE

직접 에이전트 라우터를 만드는 법This work's core output is a construction kit, not a leaderboard

이 연구의 핵심 산출물은 리더보드가 아니라 조립 키트다. 다음 순서로 자신의 라우터를 구축한다.

  1. 도구 계층 설정후보 모델을 연결하고 실행 샌드박스를 구성한다.
  2. 탐침 집합으로 프로파일링CodeRouterBench(또는 C-A-F로 자체 작업)로 차원×모델 성능 행렬을 구축한다.
  3. DimensionBest로 시작정적 메모리 + 룩업만으로 오라클 AvgPerf의 약 83%를 거의 무비용으로 달성한다. 이것이 베이스라인이다.
  4. 분류기 추가라우팅 도구를 학습 분류기(LogReg, RouteLLM)로 바꿔 더 싼 배포로 DimensionBest 수준 AvgPerf를 낸다(Perf/$ 6.11–6.82).
  5. C-A-F 루프 완성 (ACRouter)새 분포에 배포할 때 세 모듈을 모두 활성화해 피드백 루프를 닫는다. 가진 사전지식으로 메모리를 초기화하면 루프가 수렴을 보장한다.
  6. 도구 맞춤화검증기의 평가 도구를 교체(예: 도메인 특화 테스트)하고, 맞춤 라우팅 도구를 추가한다.
  7. 벤치마크 확장C-A-F로 작업을 추가한다. 새 모델은 응답+채점이, 새 차원은 작업 집합+채점 함수가 필요하다.

모델 라우팅을 넘어서. C-A-F 루프(맥락 관찰 → 행동 → 피드백 수신 → 맥락 갱신)는 모델 라우팅에 국한되지 않는다. 도구 선택, API 엔드포인트 선택, 프롬프트 전략 선택, 사고 노력 배분에도 동일한 패러다임이 적용된다. 코딩 라우팅은 더 넓은 에이전트 의사결정 패러다임의 구체적 첫 사례다.

§ 5.3 · 6 · TAKEAWAYS & CONCLUSION

핵심 요약과 결론Actively closing the information gap as a general principle

  1. LLM 라우터의 주된 성능 병목은 추론 실패가 아니라 정보 결핍이다.
  2. 모든 코딩 차원을 지배하는 단일 모델은 없다.
  3. 완전한 Agent-as-a-Router는 ID·OOD 양쪽에서 최고 성능을 내며, Opus-4.6 고정 선택보다 비용이 낮다.
  4. 정적 학습기는 ID에서 준수하나 OOD에서 크게 실패한다. 예컨대 RouteLLM-BERT는 ID Perf/$는 준수하지만 OOD를 거의 처리하지 못한다.

Agent-as-a-Router는 Context-Action-Feedback 루프로 실행 기반 정보를 획득하는 라우팅 프레임워크이며, 누적 후회를 스트리밍 지표로 하는 맥락적 밴딧으로 자연스럽게 형식화된다. 이를 오케스트레이터·검증기·메모리로 구성된 ACRouter로 구체화하고, 후회 기반 비교를 위해 설계된 CodeRouterBench에서 평가한다. ACRouter는 분포 내 스트림에서 최저 누적 후회를 달성하고, OOD 에이전트형 프로그래밍에서 강한 성능을 유지하는 유일한 라우터다. 더 넓게 보면, 실행 기반 피드백으로 정보 격차를 능동적으로 메우는 것이 이종 도구·모델을 라우팅해야 하는 에이전트 시스템 구축의 일반 원리로 떠오른다.

한계
  • 제공자 측 캐시 적중률은 관측 불가하므로 금전 비용 추정은 공개 토큰 단가와 측정 토큰 사용량에 기반한다. 따라서 금전 비용은 상대 비교용 보조 지표일 뿐 1차 지표가 아니다.
  • 에이전트형 프로그래밍 평가는 예산 통제를 위해 표준 250 step 대신 40 step 제한을 쓴다(상대 비교는 영향받지 않음).
  • 본 C-A-F 구체화는 LLM 정책 + 메모리-kNN 앙상블을 쓴다. 고급 모수 수준 메모리 기법 같은 대안 구체화는 향후 과제로 남는다.