모델 라우팅은 단순한 모델 선택이 아니다: IBM Research가 본 엔터프라이즈 Agent의 현실

도입

모델 라우팅은 기업 AI에서 손쉬운 비용 절감 방법처럼 보인다. 간단한 요청은 저렴한 모델에 보내고, 어려운 작업은 고성능 모델에 맡기며, 코드나 멀티모달처럼 특화된 영역은 해당 모델에 배정하면 된다는 식이다. 하지만 IBM Research는 Hugging Face Blog 글에서, Agent 시스템에 라우터를 넣는 순간 문제는 곧 “어떤 모델을 고를 것인가”가 아니라 “전체 시스템을 어떻게 최적화할 것인가”로 바뀐다고 설명한다.

핵심 요점

1. 비용은 가격표만으로 결정되지 않는다
   글은 동일한 CodeAct Agent로 AppWorld Test Challenge의 417개 작업을 수행한 결과를 소개한다. Claude Sonnet 4.6은 총 79달러, 작업당 약 0.19달러였고, GPT-4.1은 총 155달러, 작업당 약 0.37달러였다. 표면적으로는 GPT-4.1의 토큰 가격이 더 낮고, Sonnet은 더 많은 추론 단계를 거쳤기 때문에 반대 결과가 예상된다. 차이를 만든 변수는 캐시였다. Agent 작업은 여러 단계에서 큰 컨텍스트를 반복적으로 재사용하므로, 캐시 읽기 가격과 캐시 적중률이 실질 비용을 크게 바꾼다.

2. 복잡도는 사전에 보이는 난이도와 다르다
   난이도 기반 라우팅은 직관적이지만, 실행 전에 실제 난이도를 알기 어렵다. “이 계약서를 요약해 달라”는 단순한 요청도 검색, 컴플라이언스 확인, 도구 사용, 여러 차례의 수정 과정을 유발할 수 있다. 반대로 기술적으로 보이는 프롬프트가 작은 전문 모델로 효율적으로 처리될 수도 있다. 기업 환경에서는 데이터 소재지, 개인정보 보호, 승인된 모델 목록 같은 제약도 라우팅 결정에 영향을 준다.

3. 지연시간은 모델 속도만의 문제가 아니다
   사용자가 체감하는 응답 시간은 모델 크기만으로 설명되지 않는다. 라우팅 자체의 오버헤드, 어떤 하드웨어에서 실행되는지, 엔드포인트 부하, 캐시가 준비되어 있는지 등이 전체 지연시간을 좌우할 수 있다. 작업당 한 번만 라우팅하면 부담은 작지만, Agent의 매 단계에서 라우팅하면 적응력은 높아지는 대신 지연시간과 운영 복잡성이 늘어난다.

4. 라우팅은 다목적 최적화에 가깝다
   IBM Research는 “이 작업에 가장 좋은 모델은 무엇인가”라는 질문에서 벗어나 비용, 품질, 지연시간을 동시에 최적화하는 방식으로 접근했다고 설명한다. AppWorld 실험에서는 여러 라우터 설정이 비용과 정확도의 프런티어를 만들었다. 지연시간을 최적화한 한 설정은 정확도 84%, 비용 93달러, 지연시간 83초를 기록했으며, Opus만 사용하는 경우와 비교해 비용을 21%, 지연시간을 9% 줄였고 정확도 하락은 4%였다.

의미와 영향

이 글의 핵심 메시지는 모델 라우팅이 단순한 모델 선택 문제가 아니라는 점이다. 모델은 캐시 동작, 인프라 상태, 워크로드 패턴, 신뢰성, 컴플라이언스와 함께 고려해야 하는 여러 변수 중 하나다. 기업용 Agent에서 좋은 라우터는 항상 가장 강력한 모델을 고르는 장치가 아니라, 품질과 비용, 지연시간, 거버넌스 사이에서 시스템 전체에 가장 적합한 운영 지점을 찾는 장치다.

출처: Hugging Face Blog