GitHub Copilot의 Auto 모드가 요청의 복잡성이나 모델의 가동 상황을 보고 GPT나 Claude 등으로부터 모델을 선택하고 있다는 사실은 알려져 있습니다.

하지만 실제로 무엇을 "복잡"하다고 판단하는 것일까요? 대화 도중에도 모델을 다시 선택할까요? 또한, 새로운 LLM이 추가될 때마다 라우터(Router)도 다시 학습해야 할까요?

Microsoft의 논문 「HyDRA: Hybrid Dynamic Routing Architecture for Heterogeneous LLM Pools」에서는 GitHub Copilot Auto에서 사용되는 라우팅(Routing) 방식이 설명되어 있습니다.

본 기사에서는 수식의 상세한 내용에는 들어가지 않고, 소프트웨어 엔지니어의 관점에서 구조를 정리합니다.

본 기사는 arXiv의 v2를 참조하고 있습니다. 논문 중의 본방 평가는 주로 VS Code Chat을 대상으로 하고 있습니다.

논문에서 비교 대상으로 삼고 있는 기존의 본방 라우터는 binary-v1과 기존의 휴리스틱(Heuristic)을 조합한 방식입니다.

binary-v1은 요청을 크게 다음의 두 가지로 분류합니다.

• 저렴한 모델로 처리할 수 있음
• 고성능 모델이 필요함

즉, 태스크를 "쉬운가 어려운가"라는 하나의 축으로 파악하는 방식입니다.

하지만 개발 태스크의 난이도는 하나의 축만으로는 표현하기 어렵습니다.

예를 들어, 복잡한 설계 판단이 필요하지만 코드를 거의 쓰지 않는 요청과, 추론은 단순하지만 대량의 코드 생성이나 도구 조작이 필요한 요청은 필요한 능력이 다릅니다.

또한, 특정 강점 모델과 약점 모델을 전제로 학습된 라우터는 새로운 중간 모델이 추가되어도 그 특징을 즉시 활용할 수 없습니다.

HyDRA는 이 두 가지 과제를 "필요 능력의 다차원화"와 "모델 카탈로그와의 분리"를 통해 해결하려고 합니다.

HyDRA는 요청을 직접 "GPT-5.4로 보낸다" 또는 "Claude Sonnet으로 보낸다"라고 분류하지 않습니다.

먼저, 요청을 처리하기 위해 다음 4가지 능력(Capability)이 어느 정도 필요한지를 각각 0에서 1 사이의 값으로 예측합니다.

• 추론 (Reasoning)
• 코드 생성 (Code Generation)
• 디버깅 (Debugging)
• 도구 이용 (Tool Use)

논문 중에서는 다음 요청이 예시로 사용되고 있습니다.

Fix the race condition in WebSocket reconnect.

이 요청에 대한 예측값은 다음과 같습니다.

경합 상태(Race condition)의 원인을 특정할 필요가 있기 때문에 추론과 디버깅의 요구값이 높게 나타나 있습니다. 반면, 대량의 신규 코드를 작성하는 요청은 아니기 때문에 코드 생성의 요구값은 비교적 낮습니다.

단순한 "난이도"가 아니라, 무엇이 어려운지를 나누어 예측하는 것이 HyDRA의 특징입니다.

4가지 요구값을 예측하는 것이 ModernBERT-base입니다.

ModernBERT는 GPT나 Claude처럼 문장이나 코드를 생성하는 모델이 아닙니다. 입력문을 읽고 분류 등에 이용할 수 있는 수치 표현으로 변환하는 인코더(Encoder) 계열의 모델입니다.

HyDRA에서는 현재의 사용자 메시지를 ModernBERT-base에 입력하여, 문장 전체를 나타내는 정보로부터 4가지 요구값을 출력합니다.

사용자의 요청
↓
ModernBERT-base
...

ModernBERT-base는 약 1억 4,900만 개의 파라미터(Parameter)를 가집니다. 현재의 대규모 생성 LLM과 비교하면 가볍고, 실제 환경에서는 CPU 상의 INT8 ONNX 모델로 동작합니다.

논문 본문의 측정에 따르면, 라우팅 처리의 레이턴시(Latency)는 P50 기준 55ms, P99 기준 120ms였습니다.

모델을 선택하기 위해 별도의 대규모 생성 LLM을 호출하는 대신, 경량 분류 모델을 전단에 배치하고 있습니다.

요청에 필요한 능력을 예측한 후, 그것을 각 LLM의 능력 프로필(Capability Profile)과 비교합니다.

각 모델에도 추론, 코드 생성, 디버깅, 도구 이용의 4개 축으로 능력값이 설정되어 있습니다.

여기서 계산하는 것이 다음의 부족분입니다.

요청이 요구하는 능력에 대해, 해당 모델에서 무엇이 얼마나 부족한가

예를 들어, 다음과 같은 관계가 있다고 가정합니다.

모델의 능력이 요구값을 상회하는 항목은 부족분이 0입니다.

중요한 점은 코드 생성 능력의 여유분이 디버깅 능력의 부족을 상쇄하지 않는다는 점입니다. 코드를 많이 생성할 수 있다고 해서 복잡한 결함을 올바르게 분석할 수 있다고 단정할 수는 없기 때문입니다.

각 능력에는 가중치도 설정되어 있으며, 논문의 분석에 따르면 디버깅(Debugging)과 도구 활용(Tool Use)의 부족이 추론(Reasoning)이나 일반적인 코드 생성(Code Generation)보다 더 무겁게 평가됩니다.

HyDRA는 단순히 부족함이 가장 적은 모델을 선택하는 것이 아닙니다.

부족량이 임계값 τ 미만인 모델을 후보로 삼고, 그중에서 가장 저렴한 모델을 선택합니다.

예를 들어, τ = 0.10인 경우는 다음과 같습니다.

부족함이 없는 고성능 모델이 아니라, 허용 범위 내에 들어온 저렴한 모델이 선택됩니다.

τ를 작게 설정하면 품질을 중시하게 되고, 크게 설정하면 비용을 중시하게 됩니다. 이 임계값은 운영 중에 변경할 수 있으며, 조정할 때마다 라우터(Router)를 재학습할 필요는 없습니다.

HyDRA가 학습을 통해 예측하는 것은 요청에 필요한 4가지 능력입니다.

반면, 각 LLM의 정보는 외부 설정으로서 관리됩니다.

• 4축 능력 프로필 (Capability Profile)
• 비용
• 대응 기능
• 이용 가능 여부

능력 프로필은 제품 소개의 스펙표가 아니라, 여러 벤치마크(Benchmark) 결과를 라우팅용 4축으로 변환한 것입니다.

새로운 모델이 추가된 경우에는 해당 능력 프로필과 비용을 YAML에 추가하기만 하면, 기존의 HyDRA가 선택 후보로 취급할 수 있습니다.

논문에서는 4개월 동안 6개의 모델을 추가하고 3개의 모델을 삭제했지만, 라우터의 재학습은 단 한 번도 필요하지 않았다고 밝혔습니다.

모델의 추가나 폐지가 빈번하게 발생하는 서비스에서는 이러한 분리가 큰 이점이 됩니다.

논문을 읽으며 특히 중요하다고 느낀 점은, Auto가 매 턴(Turn)마다 모델을 다시 선택하는 것이 아니라는 점입니다.

실제 운영 환경의 기본값은 대화 단위로 모델을 고정하는 per-session 방식입니다.

라우터가 호출되는 시점은 다음 세 가지 경우입니다.

• 새로운 대화의 첫 번째 턴
• 사용자가 명시적으로 컴팩션(Compaction)을 수행한 후
• 백그라운드 요약(Background Summarization) 후

그 외의 턴에서는 대화 ID(Conversation ID)에 연결된 동일한 모델을 계속 사용합니다.

이는 프롬프트 캐시(Prompt Cache)를 유지하기 위해서입니다. 대화 도중에 모델을 전환하면 그때까지 축적된 캐시를 이용할 수 없으며, 긴 컨텍스트(Context)를 다시 처리해야 합니다.

그 대신, 대화 도중에 작업의 난이도가 크게 변하더라도 컴팩션 전까지는 동일한 모델이 사용됩니다.

Auto는 '매 턴 최적의 모델을 고르는 메커니즘'이라기보다, 자연스러운 캐시 경계에서 모델을 선택하고 그 구간 동안은 고정하는 메커니즘이라고 이해하는 것이 실체에 더 가깝습니다.

HyDRA에 전달되는 입력은 현재의 사용자 메시지와 다음 7가지 종류의 플래그(Flag)입니다.

• 턴 수 구분
• 에러 유무
• 파일 참조 유무
• URL 유무
• 커맨드(Command) 유무
• 코드 유무
• 단문 여부

입력은 최대 512 토큰입니다.

반면, 라우터는 다음 정보를 직접 보지 않습니다.

• 과거의 어시스턴트(Assistant) 답변
• 도구 실행 결과
• 리포지토리(Repository)의 실제 코드나 상태

모델을 고르는 HyDRA와, 선택 후에 리포지토리를 읽고 작업을 수행하는 LLM은 별개입니다.

이 때문에 대상 코드를 보지 않으면 난이도를 알 수 없는 요청이나, "이것을 고쳐줘"와 같은 문맥 의존적(Context-dependent)인 요청의 경우 라우터가 이용할 수 있는 정보에 한계가 있습니다.

논문의 학습 데이터 생성 시, 리포지토리 상태를 재현할 수 없는 문맥 의존적 쿼리에 대해 보수적인 요구 레이블(Requirement Label)을 설정했습니다. 따라서 실제 운영 환경에서도 리포지토리 의존성이 강해 판단이 어려운 요청을 안전한 방향으로 처리하도록 학습했을 가능성이 있습니다.

이 부분은 논문에 명시된 운영 규칙이 아니라, 학습 방법으로부터 유추할 수 있는 경향성입니다. 운영 환경에서 모호한 요청에 대해 고정값을 설정하는 처리가 있다고 명시되어 있지는 않습니다.

SWE-bench Verified의 500건·5개 모델 풀(Pool) 평가에서는 대표적으로 다음과 같은 결과가 보고되었습니다.

비용 절감률은 평가 기준인 '전체 건을 Claude Sonnet 4.6으로 보낼 경우'를 기준으로 한 지표입니다.

보수적 설정의 HyDRA는 Sonnet 고정 방식과 비교했을 때 해결률 차이를 0.2포인트로 억제하면서, 평가상의 비용을 54.1% 절감했습니다.

또한, 약 100만 명씩을 대상으로 한 14일간의 A/B 테스트에서는 기존 라우터와 비교하여 완료 시간, 첫 번째 토큰까지의 시간(TTFT), 에러율이 개선되었으며, 측정 지표상으로는 이용자가 체감하는 품질의 통계적으로 유의미한 저하는 확인되지 않았습니다.

QR과 Oracle Routing에 대하여

논문에서의 QR(Quality Retention)은 일반적인 정답률이 아닙니다.

Oracle Routing은 모든 후보 모델의 결과를 사후에 확인하여, 문제를 해결할 수 있었던 모델들 중 가장 저렴한 모델을 선택한 것으로 간주하는 평가용 가상 라우터(Virtual Router)입니다.

QR은 이 Oracle Routing의 해결률에 대해, 대상 라우터가 어느 정도의 품질을 유지했는지를 나타냅니다.

HyDRA의 처리 과정을 간단히 정리하면 다음과 같습니다.

• 현재 메시지와 간이 플래그(Flag)를 ModernBERT-base에 입력한다
• 추론(Reasoning), 코드 생성(Code Generation), 디버깅(Debugging), 도구 사용(Tool Use)의 필요도를 예측한다
• 각 LLM의 능력 프로파일(Capability Profile)과의 부족분을 계산한다
• 부족분이 허용 범위 내에 있는 모델을 추출한다
• 그중에서 가장 저렴한 모델을 선택한다
• 원칙적으로 대화 중에는 동일한 모델을 계속 사용한다

특정 모델명이 아니라 태스크(Task)에 필요한 능력을 예측함으로써, 새로운 모델의 추가나 가격 변경에도 유연하게 대응할 수 있습니다.

한편, HyDRA 자체는 리포지토리(Repository)의 내용이나 과거의 응답을 직접 보지 않으며, 대화 도중의 난이도 변화에도 즉각적으로 추종하지는 않습니다.

품질, 비용, 가용성, 프롬프트 캐시(Prompt Cache), 빈번한 모델 교체 사이의 균형을 맞추기 위한 현실적인 프로덕션 라우터(Production Router)라고 이해하는 것이 가장 적절할 것입니다.