쿼리에서 모듈까지 — LLM 캐스케이드 라우팅 기술의 발전사
강한 모델은 품질이 좋은 대신 비싸고 약한 모델은 저렴한 대신 품질이 들쭉날쭉하다. 이 트레이드오프 자체는 새롭지 않지만 "어떤 요청에 어떤 모델을 쓸 것인가"라는 결정을 누가 언제 어떤 근거로 내리느냐는 계속 바뀌어 왔다. 캐스케이드 라우팅(cascade routing)은 이 결정을 자동화하는 기술 영역을 통칭하는 이름이다.
이 글은 이 영역의 대표 연구 세 편, 즉 쿼리 단위 라우팅의 출발점인 RouteLLM, 멀티턴 에이전틱 코딩 작업을 다루는 SWE-Router, 컴파운드 AI 시스템 관점에서 모듈 단위 모델 선택을 다루는 LLMSelector를 통해 이 문제가 풀려온 순서를 짚는다. 세 연구는 서로 경쟁 관계가 아니라 라우팅 판단이 이루어지는 지점을 각기 다른 층위로 넓혀 온 계보에 가깝다.
전제: 캐스케이드 라우팅이 푸는 문제
가장 단순한 형태의 캐스케이드는 저렴한 모델을 먼저 시도하고 결과가 미덥지 않을 때만 비싼 모델로 넘기는 구조다. 문제는 "미덥지 않다"를 무엇으로 판정하느냐다. 요청이 들어오기 전에 미리 정해둔 규칙으로 판단할 수도 있고 학습된 판별기를 둘 수도 있으며 작업이 진행되는 도중에 나오는 신호를 볼 수도 있다. 이 판단 지점을 어디에 두느냐가 곧 라우팅 기술의 설계 공간이고 세 연구는 이 공간의 서로 다른 좌표에 자리 잡고 있다.
쿼리 단위 라우팅의 출발점: RouteLLM
**RouteLLM(2024)**은 UC 버클리와 Anyscale이 함께 내놓은 연구로 캐스케이드 라우팅을 본격적인 학습 문제로 정식화한 초기 사례다. 문제의식은 명확하다. 강한 모델과 약한 모델 중 어느 쪽으로 보낼지를 사람이 규칙으로 정하는 대신 데이터로 학습시키자는 것이다.
방법론의 핵심은 인간 선호도 데이터의 활용이다. Chatbot Arena류의 선호도 데이터로 라우터를 학습시키되 이 데이터만으로는 성능이 무작위 수준에 그친다는 것을 확인하고 골든 라벨과 LLM 판정 라벨을 더하는 데이터 증강을 결합했다. 이렇게 만든 라우터는 유사도 기반 순위 모델, 행렬 분해 방식 판별기, BERT 분류기에 이르기까지 여러 아키텍처로 검증됐다.
결과는 구체적이다. MT-벤치에서는 전체 요청의 13.4%만 GPT-4로 보내고도 GPT-4 단독 성능의 95%를 유지하면서 비용을 3.66배 줄였다. MMLU에서는 GPT-4 성능의 92%를 유지하며 1.41배, GSM8K에서는 87%를 유지하며 1.49배의 비용 절감을 각각 보였다. 학습에 쓰지 않은 새로운 강한 모델과 약한 모델의 조합에도 재학습 없이 라우터가 어느 정도 전이된다는 점도 확인됐다.
다만 논문 스스로 인정하는 한계도 뚜렷하다. 첫째, 벤치마크의 쿼리 분포와 실제 서비스의 쿼리 분포가 다를 수 있어 도메인 특화 데이터 수집이 필요하다. 둘째, 지금의 설계는 강한 모델과 약한 모델 둘 사이의 이분법적 라우팅에 머물러 있고 셋 이상의 모델로 확장하는 것은 다음 과제로 남겨졌다. 셋째, 같은 데이터로 학습한 라우터끼리도 같은 벤치마크에서 성능 편차가 크게 나타나는데 그 원인이 아직 명확히 규명되지 않았다.
실행 궤적으로 라우팅을 확장하다: SWE-Router
RouteLLM류의 라우터는 공통적으로 요청이 실행되기 전에 프롬프트만 보고 딱 한 번 결정을 내린다. **SWE-Router(2026)**는 이 전제가 멀티턴 에이전틱 소프트웨어 엔지니어링 작업에서는 근본적으로 부족하다고 지적한다. 겉보기에 비슷한 이슈 설명이 오타 하나 고치는 일일 수도 있고 여러 모듈에 걸친 리팩터링일 수도 있는데 이 차이는 프롬프트 텍스트만으로는 원리적으로 구분되지 않는다. 논문은 이를 정보이론적 베이즈 오류 상한이라는 개념으로 표현한다. 프롬프트 전용 라우터가 아무리 정교해져도 넘을 수 없는 성능의 상한선이 존재한다는 뜻이다.
이 한계를 넘기 위한 SWE-Router의 방법론은 가치 기반의 시간적(temporal) 라우팅이다. 저렴한 약한 모델을 먼저 K턴 동안 실행시켜 테스트 실패 로그, 파일 내용, 스택 트레이스 같은 부분 궤적(partial trajectory)을 만들어 낸다. 그다음 Qwen2.5-Coder-7B를 LoRA로 미세조정한 가치 함수가 이 부분 궤적을 읽고 약한 모델이 결국 작업을 해결할지를 예측한다. 예측값이 비용 대비 임계값을 넘으면 약한 모델을 계속 쓰고 그렇지 않으면 강한 모델로 에스컬레이션한다. 논문은 부분 궤적을 조건으로 삼는 라우팅이 프롬프트 전용 라우팅보다 절대 나쁘지 않으며 궤적이 정보를 담고 있을 때는 엄격히 더 낫다는 것을 이론적으로도 증명해 낸다.
SWE-bench Verified 평가에서 deepseek-v3.2를 약한 모델로 두었을 때 비용 대비 해결율을 나타내는 Route-AUC 지표가 0.780을 기록했는데 이는 궤적을 보지 않는 기준선보다 15.3퍼센트포인트 높은 수치다. 흥미로운 점은 약한 모델과 강한 모델이 서로 다른 문제 부분집합을 풀어내면서 특정 비용 구간에서는 SWE-Router 조합이 강한 모델 단독 성능마저 넘어서는 시너지가 관측됐다는 것이다.
논문이 스스로 짚는 과제도 여럿이다. 에스컬레이션이 일어나면 강한 모델은 약한 모델의 탐색 결과를 넘겨받지 못하고 원래 프롬프트에서 처음부터 다시 시작한다. 약한 모델의 추론이 강한 모델의 판단을 오히려 편향시킬 수 있다는 이유로 의도한 설계지만, 그만큼 앞선 탐색이 버려지는 비효율이 남는다. 더 무거운 지적은 안전성이다. 부분 궤적을 판단 근거로 쓰는 구조 자체가 안전성 중심으로 설계된 프론티어 모델을 우회하는 경로로 악용될 수 있다고 논문은 명시한다. 그 밖에 평가에 쓰인 모델이 네 종류에 그쳐 일반화 여부가 불확실하다는 점과 K턴의 탐색 비용을 선불로 치러야 하므로 매우 약한 모델을 쓸 경우 오히려 이득이 줄어들 수 있다는 점도 남아 있다.
파이프라인 내부로: 모듈 단위 라우팅과 LLMSelector
세 번째 연구인 **LLMSelector(2025)**는 문제를 완전히 다른 각도에서 본다. 하나의 요청에 하나의 모델을 붙이는 것이 아니라 self-refine이나 multi-agent-debate처럼 생성기 비평가 개선기 같은 여러 모듈로 이루어진 컴파운드 AI 시스템에서 모듈마다 어떤 모델을 배정할지를 다룬다. 모듈 수와 후보 모델 수가 조금만 늘어도 전체 조합의 수는 지수적으로 폭발하기 때문에 모든 조합을 다 시도해 보는 방식은 애초에 성립하지 않는다.
LLMSelector는 두 가지 경험적 관찰에서 출발한다. 하나는 단조성이다. 나머지 모듈을 고정한 채 한 모듈의 성능만 놓고 보면 그 모듈의 성능이 좋아질수록 시스템 전체 성능도 대체로 함께 좋아지는 경향이 있다는 것이다. 다른 하나는 모델 스스로 자기 모듈 수준의 성능을 꽤 정확하게 추정해 낼 수 있다는 것이다. 이 두 관찰을 결합하면 모든 조합을 탐색하는 대신 한 번에 모듈 하나씩 골라 그 모듈에 가장 좋은 성능을 내는 모델을 배정하고 더 이상 개선이 없을 때까지 반복하는 탐욕적 최적화만으로도 충분히 좋은 배정에 도달할 수 있다.
Microsoft Research와 스탠퍼드, 프린스턴, UC 버클리 연구진이 함께 참여한 이 연구는 ICML 2025에서 발표됐다. LiveCodeBench, SimpleQA, FEVER를 포함한 여섯 개 벤치마크와 self-refine, multi-agent-debate, locate-solve 세 가지 컴파운드 시스템 구조에 걸쳐 GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 등을 후보 모델로 검증한 결과 모든 모듈에 같은 모델 하나만 쓰는 방식 대비 5%에서 최대 70%까지 정확도가 개선됐다.
이 접근의 취약점은 출발점이 된 가정 자체에 있다. 단조성은 실험적으로 관찰된 경향일 뿐 모든 시스템에서 성립을 보장하는 원리가 아니다. 모듈 사이에 복잡한 상호작용이나 피드백 구조가 있으면 한 모듈씩 순서대로 최적화하는 탐욕적 방식이 전역 최적에 못 미치는 배정에 머무를 가능성이 있다. 또한 모델이 자신의 모듈 수준 성능을 추정하는 능력에 크게 의존하는 구조이므로 검증 데이터가 부족한 새로운 도메인에서는 이 자기 진단 자체의 신뢰도가 흔들릴 수 있다.
세 연구를 관통하는 축: 무엇을 언제 어디서 라우팅할 것인가
세 연구를 나란히 놓고 보면 캐스케이드 라우팅이 확장되어 온 방향이 뚜렷하게 드러난다. RouteLLM은 하나의 독립된 쿼리를 판단 단위로 삼고 실행 전에 딱 한 번 결정을 내린다. SWE-Router는 판단 단위를 하나의 작업이 진행되는 시간의 흐름으로 넓혀 실행 도중에 나오는 신호로 결정을 갱신한다. LLMSelector는 판단 단위를 다시 시스템의 구조로 옮겨 하나의 요청 안에 있는 여러 모듈 각각에 서로 다른 모델을 배정한다. 즉 라우팅의 진화는 판단을 언제 내리는지(실행 전과 실행 중으로 나뉨)와 무엇을 단위로 내리는지(쿼리 단위, 궤적 단위, 모듈 단위로 비교)라는 두 축을 따라 정교해져 온 과정으로 읽을 수 있다.
아직 남은 과제
세 연구를 종합했을 때 공통적으로 드러나는 미해결 지점은 다음과 같다.
첫째, 이분법을 넘어서는 다자간 라우팅이다. RouteLLM은 강한 모델과 약한 모델 둘 사이의 라우팅에 머물러 있고 SWE-Router의 검증도 네 개 모델에 그쳤으며 LLMSelector조차 모듈 수와 후보 모델 수가 늘어나면 탐욕적 최적화의 품질이 담보되지 않는다. 후보 모델이 여러 개로 늘어난 현실적인 환경에서 조합 폭발을 피하면서도 품질을 담보하는 일반적인 방법은 아직 정립되지 않았다.
둘째, 분포 일반화다. 벤치마크로 학습하거나 검증한 라우터가 실제 서비스 트래픽의 분포에서도 같은 성능을 낼지는 별개의 질문으로 남는다. RouteLLM이 스스로 지적했듯 도메인이 바뀌면 재학습이나 재검증이 필요할 가능성이 크다.
셋째, 탐색 비용과 안전성의 충돌이다. SWE-Router처럼 실행 중 신호를 활용하려면 약한 모델을 먼저 돌려 보는 탐색 비용을 선불로 치러야 하고 이 탐색 자체가 안전성 중심으로 설계된 모델을 우회하는 경로로 악용될 위험까지 안고 있다. 비용 효율과 안전성이라는 두 요구가 같은 설계 지점에서 충돌한다.
넷째, 에스컬레이션 시점의 컨텍스트 손실이다. 판단이 바뀌어 더 강한 모델로 넘어갈 때 그 이전까지의 탐색과 진행 상황을 얼마나 넘겨줄지에 대한 표준적인 방식이 없다. SWE-Router는 편향을 피하려고 아예 처음부터 다시 시작하는 쪽을 택했지만 이는 곧 앞선 계산이 통째로 버려진다는 뜻이기도 하다.
정리 및 요약
캐스케이드 라우팅은 강한 모델과 약한 모델 사이에서 어느 쪽을 쓸지 정하는 단순한 이분법에서 출발했지만 그 판단이 이루어지는 지점은 계속 확장되어 왔다. RouteLLM은 이 문제를 실행 전에 내리는 학습된 결정으로 정식화했고 SWE-Router는 실행 중에 드러나는 궤적 신호까지 판단 근거로 끌어들였으며 LLMSelector는 판단의 단위 자체를 하나의 쿼리에서 시스템을 구성하는 여러 모듈로 옮겼다. 세 연구는 순서대로 라우팅이 언제 무엇을 근거로 어떤 단위에서 이루어질 수 있는지를 하나씩 넓혀 온 계보로 볼 수 있다.
동시에 셋 이상의 모델로 확장하는 문제, 벤치마크와 실제 트래픽 사이의 분포 차이, 탐색 비용과 안전성의 균형, 에스컬레이션 시 컨텍스트 이전 같은 과제는 세 연구 모두에서 형태를 조금씩 바꿔 가며 반복해서 나타난다. 결국 캐스케이드 라우팅을 실제 시스템에 들여오는 일은 논문에서 검증된 라우팅 알고리즘 하나를 가져다 붙이는 문제가 아니라 어떤 판단 단위와 시점이 자신의 시스템 구조에 맞는지를 스스로 가려내는 설계의 문제에 가깝다.