LLM 라우터 도입 가이드: 모델 선택부터 비용·품질 검증까지

가장 강력한 모델은 그만한 성능이 필요한 일에 투입해야 합니다. 본인 인증을 마친 고객에게 주문 상태를 알려주는 답변과, 서로 모순되는 기록을 살펴야 하는 환불 분쟁을 처음부터 같은 경로로 처리할 이유는 없습니다. 어려운 부분은 저렴하게 만든 답변이 비싼 재작업으로 이어지기 전에 두 요청을 구별하는 일입니다.

아래에 설명한 제품 동작은 2026년 10월 21일에 실제 공개 문서와 대조해 확인했습니다. 고객 지원 업무와 계산은 설명을 위한 예시이며, 운영 환경에서 측정한 결과나 업체가 주장하는 비용 절감 수치가 아닙니다.

LLM 라우터는 어떤 일을 하나요?

모델 라우터는 요청마다 답변을 맡을 대규모 언어 모델, 즉 LLM을 선택하는 규칙 또는 학습된 분류기입니다. 분류기는 입력을 특정 범주에 배정합니다. 라우터는 애플리케이션의 작업 유형, 대화 내용, 필요한 툴, 입력 크기, 예상 난이도 등을 바탕으로 모델을 고를 수 있습니다.

고객 지원팀에서 업무를 배정하는 담당자를 떠올리면 이해하기 쉽습니다. 단순 조회는 효율적으로 처리할 수 있는 직원에게, 분쟁은 전문가에게 맡깁니다. 누구에게도 처리 권한이 없는 일이라면 어떤 절차로 넘길지 정해 둔 규칙도 필요합니다.

애플리케이션에서는 최적화에 앞서 사용 조건부터 확인해야 한다는 뜻입니다. 이 모델이 입력을 처리할 수 있는지, 필요한 툴을 호출할 수 있는지, 승인된 제공업체를 통해 실행할 수 있는지를 먼저 확인합니다. 이 조건을 통과한 후보끼리만 비용이나 기대 품질을 비교해야 합니다.

모델 라우팅, 제공업체 라우팅, 폴백은 각각 다른 문제를 해결합니다. 모델 라우팅은 답변할 모델을 고릅니다. 제공업체 라우팅은 선택한 모델을 어디에서 실행할지 결정합니다. 예를 들어 여러 호스팅 업체 중 하나를 고르는 일입니다. 폴백은 시도가 실패했을 때 다음으로 무엇을 시도할지 정합니다. 앱과 모델 API 사이의 접근 계층인 게이트웨이는 이 기능을 모두 구현할 수 있습니다. 하지만 게이트웨이를 추가했다고 해서 답변 품질을 고려하는 모델 선택기가 저절로 생기는 것은 아닙니다.

여기서 프런티어 모델은 검토 중인 범용 모델 가운데 가장 강력한 후보를 뜻합니다. 이 모델도 틀린 답변을 할 수 있습니다. 라우팅은 필요한 곳에 모델의 역량을 배분할 뿐, 답변이 사실임을 보장하지 않습니다.

LLM 라우팅을 구현하는 세 가지 방식

설명할 수 있는 규칙부터 시작합니다. 자동 선택은 규칙이 놓치는 다양한 요청을 처리하면서도 합격 기준을 충족할 때 가치가 있습니다. 다음 세 가지 구현 방식은 서로 겹칠 수 있습니다. 게이트웨이 안에서 학습된 라우터를 운영할 수도 있습니다.

직접 작성하는 규칙

애플리케이션이 이미 알고 있는 작업 유형과 제약 조건에 따라 모델을 배정합니다. 인증된 주문 데이터와 승인된 답변 템플릿을 갖춘 주문 상태 조회 엔드포인트의 요청은, 단지 메시지가 짧다는 이유로 쉽다고 분류한 요청보다 소형 모델에 맡기기 적합합니다.

규칙은 애플리케이션이 업무 흐름을 이미 알고 있을 때 유용합니다. 다만 모호한 요청에서는 한계가 드러납니다. 같은 엔드포인트로 단순 조회가 들어올 수도 있고, 상충하는 기록이 얽힌 불만이 들어올 수도 있습니다. 작은 변화에도 쉽게 빗나가는 키워드 규칙을 계속 늘리기보다, 판단이 불확실한 요청을 보낼 경로를 명시적으로 남겨 두어야 합니다.

게이트웨이의 자동 라우팅

라우팅용 별칭으로 요청을 보내면 게이트웨이가 모델을 선택합니다. 제품에 따라 분류기, 미리 구성한 등급, 그 밖의 신호를 활용할 수 있습니다. 동작을 한곳에서 관리할 수 있는 대신, 무엇이 적합한 모델인지에 대한 해당 라우터의 기준을 따르게 됩니다.

들어오는 작업의 종류가 다양하고 자체 선택기를 운영하는 부담이 지나치게 클 때 고려할 만합니다. 승인된 후보 집합을 유지하고 실제로 답변한 모델을 기록해야 합니다. 별칭만으로는 계속 같은 모델을 가리킨다고 볼 수 없습니다.

학습형 LLM 라우터는 어떻게 개선되나요?

학습형 라우터는 예시와 결과 레이블을 통해 어떤 후보가 더 나은 성능을 낼지 학습합니다. 학습에서 물어야 할 핵심은 문장이 복잡해 보이는지가 아니라, 이 요청에서 더 강력한 모델을 쓰면 실질적인 이점이 있는지입니다.

라우터를 서빙하고 평가하는 오픈 소스 프레임워크 **RouteLLM**은 선호도 데이터로 학습해 강력한 모델과 약한 모델 중 하나를 선택하는 방식과 임계값 보정 방법을 문서화하고 있습니다. 임계값은 강력한 모델을 얼마나 자주 선택할지 조절합니다. 공개된 결과만으로 자사의 고객 지원 티켓에서도 같은 성능이 나온다고 판단할 수는 없습니다. RouteLLM 문서.

유지보수에서 문제가 되는 것은 데이터 분포의 변화입니다. 새로운 작업 유형이 등장하거나 모델이 교체되면 이전에 유효했던 임계값이 더 이상 맞지 않을 수 있습니다. 개발용 예시로 학습하거나 보정한 뒤, 라우터를 조정하는 데 한 번도 쓰지 않은 별도의 사례로 평가해야 합니다.

고객 지원 앱의 라우팅 정책을 설계해 봅니다

근거가 확보되고 범위가 명확한 답변은 소형 모델에, 아직 해결되지 않은 추론은 프런티어 모델에 맡깁니다. 권한 판단은 애플리케이션 정책으로 관리해야 합니다. 환불 절차를 설명할 수 있다는 이유만으로 어느 모델에도 환불 실행 권한이 생기지는 않습니다.

정기 구독 상품을 판매하는 업체를 가정해 보겠습니다. 앱은 답변 초안을 작성하기 전에 고객의 주문, 관련 정책, 대화 기록을 가져옵니다. 다음은 정책 제안이며, 특정 소형 모델이 이미 이 기준을 통과한다는 주장이 아닙니다.

소형 모델 경로에서는 필요한 근거가 없으면 답변을 보류해야 합니다. 앱은 누락된 주문 필드, 잘못된 출력 구조, 허용된 워크플로를 벗어나는 작업 요청을 검사할 수 있습니다. 사실관계의 모순은 별도의 검증기나 사람의 검토가 필요할 수 있습니다. 형식이 올바른 답변도 내용은 틀릴 수 있습니다.

프런티어 모델은 어려운 요청에 사용하고, 소형 모델의 시도가 실패했다면 그 실패를 감지할 수 있을 때만 프런티어 모델로 넘깁니다. 기록이 빠져 있다면 추가 검색이나 확인이 필요합니다. 똑같이 불완전한 근거를 더 큰 모델에 보낸다고 누락이 해결되지는 않습니다.

상위 모델로 넘긴 호출까지 비용에 포함합니다

설명을 위해 1,000건의 요청이 있는 배치를 가정하겠습니다. 정책에 따라 700건은 소형 모델로, 300건은 곧바로 프런티어 모델로 보냅니다. 처음 소형 모델에 보낸 호출 가운데 70건이 검사를 통과하지 못해 프런티어 모델에서 다시 실행됩니다.

이때 지불하는 비용은 소형 모델 호출 700회와 프런티어 모델 호출 370회, 그리고 라우팅과 검증 비용입니다. 답변 모델의 호출 횟수는 1,000회가 아니라 1,070회입니다. 사용자에게 최종 답변만 보이더라도 재시도는 추가 작업입니다.

원래 요청 하나당 평균 라우팅 비용을 r, 소형 모델의 평균 호출 비용을 s, 프런티어 모델의 평균 호출 비용을 f, 배치 단위로 추가되는 게이트웨이 또는 검증 요금을 g라고 하겠습니다. 이 단순화한 예시에서는 기준 시스템, 직접 호출, 상위 모델로 넘긴 호출의 프런티어 모델 평균 비용이 모두 같다고 가정합니다.

라우팅 적용 비용 = 1,000r + 700s + 370f + g

모든 요청에 프런티어 모델을 쓰는 기준 비용 = 1,000f

라우팅이 더 저렴하려면 700(f − s) > 70f + 1,000r + g를 만족해야 합니다. 왼쪽은 최초 답변을 소형 모델에 맡겨 아낀 비용이고, 오른쪽은 추가 프런티어 모델 재시도와 부대 비용입니다.

선택한 모델과 요금으로 호출 비용을 계산합니다. 요금이 100만 토큰당 금액으로 표시된다면 호출 비용 = (캐시되지 않은 입력 토큰 × 입력 단가 + 캐시된 입력 토큰 × 캐시 단가 + 과금되는 출력 토큰 × 출력 단가) / 1,000,000입니다. 별도로 청구되는 툴 사용료와 요청 요금도 더해야 합니다.

운영 환경에서는 단순화한 평균값 대신 작업 유형과 경로별 실제 사용량을 적용해야 합니다. 어려운 티켓에서는 답변이 더 길어질 수 있고, 재실행에는 더 많은 컨텍스트가 포함될 수 있으며, 모델을 바꾸면 캐시 재사용률이 달라질 수 있습니다. 해당되는 경우 라우터 분류기의 토큰과 과금되는 추론 토큰을 포함하되, 같은 요금을 두 번 더하지 않도록 합니다. 두 시스템은 동일한 재시도 정책으로 비교해야 합니다.

목표는 품질 하한선을 지키면서 합격 기준을 충족한 해결 건당 비용을 낮추는 것입니다. 청구액은 줄었지만 근거 없는 환불 약속이 늘었다면 이 기준을 충족한 것이 아닙니다.

주요 라우팅 제품은 실제로 무엇을 선택하나요?

라우팅 엔드포인트를 도입하기 전에 선택 방식부터 확인해야 합니다. 제품마다 결정하는 대상이 다릅니다. 이름에 모두 ‘라우터’가 들어간다고 기본 동작까지 같지는 않습니다.

OpenRouter: 작업 유형을 고려하는 Auto Router

여러 모델 제공업체에 접근할 수 있는 관리형 게이트웨이 **OpenRouter**는 openrouter/auto를 통해 Auto Router를 제공합니다. 현재 문서에 따르면 먼저 작업을 분류한 뒤, 최근 7일 동안 해당 작업 유형에서 발생한 커뮤니티 지출액으로 모델의 순위를 정하고 비용 구간과 사용 조건에 따라 후보를 필터링합니다. 이는 전체 사용자의 이용 행태를 집계한 신호이지, 자사의 고객 지원 품질 기준이 아닙니다. Auto Router 문서.

cost_tier에는 low, medium, high, xhigh, max가 있으며, 기본 동작은 대체로 low에 가깝습니다. 등급은 비용 구간이지 엄격한 지출 상한선이 아닙니다. allowed_models와 excluded_models로 후보를 제한하고 응답의 model 필드를 기록해야 합니다. 대화 중 선택한 모델을 유지하는 기능이 있더라도, 그 선택이 끝까지 고정된다고 보장되지는 않습니다.

환경 변수에 API 키를 설정한 상태에서 다음 명령으로 최소한의 라우팅 요청을 보낼 수 있습니다.

curl --fail-with-body https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto",
    "messages": [{"role": "user", "content": "Rewrite this status politely: Your parcel is in transit."}],
    "plugins": [{"id": "auto-router", "cost_tier": "low"}]
  }'

평가할 때는 후보 집합을 제한해야 합니다. 그렇지 않으면 모델 풀이 바뀔 때마다 이전에 얻은 품질 결과를 해석하기 어려워집니다.

LiteLLM: 배포 대상 라우팅과 Auto Router를 구분해야 합니다

설정 가능한 LLM 게이트웨이 **LiteLLM**은 가중치 기반 선택, 최소 부하, 지연 시간 기반, 비용 기반 등 여러 배포 대상 라우팅 전략을 문서화하고 있습니다. 기본 전략인 simple-shuffle은 고객 지원 티켓의 난이도를 분류하는 기능이 아닙니다. 라우터 문서.

별도로 제공되는 Auto Router 문서에는 휴리스틱, LLM, 키워드 규칙, 사용자 정의 플러그인 분류기가 나옵니다. SIMPLE, MEDIUM, COMPLEX, REASONING 등급은 설정된 모델이나 모델 풀에 매핑됩니다. 문서에 안내된 대시보드 설정 경로는 Models + Endpoints → Add Model → Auto Router이며, 구성을 마친 뒤 Test Routing을 실행합니다. Auto Router 문서.

후보 모델과 분류 동작을 직접 제어해야 하는 개발팀에 적합합니다. 다만 운영 책임은 직접 져야 합니다. 등급별 모델을 지정했다고 해서 자사의 합격 기준에 맞는지 검증된 것은 아닙니다. 인프라 선택에 관한 자세한 내용은 LiteLLM과 OpenRouter 비교에서 다룹니다.

Vercel AI Gateway: 제공업체 선택과 명시적인 라우팅 제어

모델 API를 위한 관리형 접근 계층 **Vercel AI Gateway**는 최근 가동률과 지연 시간을 기준으로 기본 제공업체를 선택합니다. 제공업체 옵션으로 우선순위와 필터링을 제어할 수 있으며, 문자열로 지정한 모델 폴백은 기본 모델이 실패하거나 사용할 수 없을 때 예비 모델을 시도합니다. 서비스 안정성에 유용한 기능이지만, 이 기능만으로 고객 지원 티켓에 프런티어 모델이 필요한지 판단하지는 않습니다. 제공업체 라우팅과 폴백 문서.

게이트웨이의 라우팅 규칙은 요청된 모델을 다른 모델로 바꾸거나 요청을 거부하는 기능도 지원합니다. 모델을 바꾸는 규칙으로 트래픽을 한곳에서 이전할 수 있지만, 특정 모델로 향하는 모든 요청을 바꾸는 것은 요청별 난이도를 분류하는 일과 다릅니다. 라우팅 규칙 문서.

동작을 명시적으로 제어해야 한다면 애플리케이션 수준의 선택 정책 아래에서 이 기능을 활용합니다. 제공업체 자동 선택에 작업 품질을 고려한 자동 선택까지 포함되어 있다고 생각하면 한계에 부딪힙니다. 접근 계층의 전반적인 선택 기준은 멀티 모델 앱을 위한 AI 게이트웨이를 참고할 수 있습니다.

Microsoft Foundry: 제공업체가 관리하는 학습형 라우터

Microsoft Foundry의 model router는 배포 리소스 형태로 제공되는 학습형 모델 선택기입니다. Microsoft는 복잡성, 추론, 작업 유형 등의 속성을 활용해 모델을 선택한다고 설명합니다. Balanced, Quality, Cost 모드와 함께 후보 모델의 부분 집합을 지정하는 기능을 제공합니다. Model router 개념 문서.

이미 Foundry를 쓰는 앱에서 사용 조건을 충족하는 모델 사이의 선택을 관리형 서비스에 맡기고 싶을 때 적합합니다. 핵심 제약은 후보 집합입니다. 리전과 접근 권한에 따라 사용 가능한 모델이 달라지며, Microsoft 문서는 구성 모델 중 가장 작은 컨텍스트 윈도우가 라우터가 안정적으로 받을 수 있는 입력의 한계를 정한다고 경고합니다. 입력 요건을 충족하는 모델만 후보에 남겨야 합니다.

모드 이름이 Quality라고 해서 작업 평가를 대신할 수는 없습니다. 실제 대화 길이, 툴, 합격 기준으로 선택한 후보 집합을 테스트해야 합니다.

어떤 AI 라우터를 선택해야 하나요?

쉬운 작업을 안정적으로 가려낼 수 있다면 애플리케이션 규칙을 유지합니다. 작업의 다양성 때문에 규칙이 자주 빗나간다면 관리형 자동 라우팅을 고려합니다. 대표성 있는 결과 데이터에 레이블을 충분히 확보했고 유지보수할 가치가 있다면 선택기를 학습하는 방식을 검토합니다.

이런 선택 방식 외에 인프라 대안을 비교하려면 OpenRouter 대안 가이드를 이어서 읽을 수 있습니다. 그래도 가장 먼저 결정할 것은 더 긴 제공업체 목록이 아니라 라우팅 정책과 그 근거입니다.

평가 세트로 라우터의 성능을 어떻게 검증하나요?

‘쉬움’과 ‘어려움’ 같은 레이블에 얼마나 잘 맞추는지가 아니라, 라우팅을 거쳐 나온 답변을 평가해야 합니다. 선택기가 작업 유형을 정확히 분류하더라도 소형 모델이 처리하면 안 되는 요청을 소형 모델에 보낼 수 있습니다.

평가 세트는 반복해서 사용할 수 있도록 요청, 컨텍스트, 합격 기준을 모은 것입니다. 고객 지원 앱이라면 각 사례에 대화, 주문 데이터 스냅샷, 적용 정책, 답변에 담겨야 할 사실, 금지된 주장이나 조치, 상위 검토로 넘겨야 하는 조건과 방식을 포함해야 합니다.

평가표는 비용이 큰 실수를 드러낼 수 있어야 합니다.

어떤 지표의 분모에 해당하는 사례가 없다면 0이 아니라 정의할 수 없다고 보고해야 합니다. 두 모델의 출력을 각각 독립적으로 평가한 결과를 바탕으로 유해한 소형 모델 배정률을 추정하고, 상위 모델로 넘긴 뒤에도 남은 최종 오류를 함께 보고합니다. 두 모델이 모두 실패한 사례는 별도로 표시해야 합니다. 선택기가 그 후보들만으로 합격하는 답변을 만들어낼 수는 없습니다.

치명적이지 않은 품질 차이를 어느 정도까지 허용할지 테스트 전에 정하고, 새로 발생한 치명적인 품질 저하는 모두 조사합니다. 짝지어진 표본에 적합한 신뢰구간을 사용합니다. 불확실성의 범위에 여전히 허용할 수 없는 품질 손실이 포함된다면, 동등한 성능이라고 결론 내리지 말고 근거를 더 모아야 합니다.

마지막으로 기존 모델이 고객에게 계속 답변하는 동안 실제 트래픽의 제한된 표본으로 라우터를 섀도 모드에서 실행합니다. 섀도 호출에는 추가 비용이 듭니다. 결과를 검토한 뒤 제한적으로 배포하고, 기존 모델 정책으로 즉시 되돌릴 수 있는 경로를 마련합니다. 요청 유형별 모니터링을 이어 가고 프롬프트, 툴, 모델, 라우팅 동작이 바뀌면 평가를 다시 실행합니다.

모델 라우팅에서 과장되는 부분은 무엇인가요?

‘같은 품질을 더 낮은 비용으로’라는 말은 특정 워크로드에서 검증해야 할 결과이지, 라우터 자체의 속성이 아닙니다. 어떤 요청이 들어오는지, 어떤 후보를 사용할 수 있는지, 무엇을 합격으로 보는지에 따라 달라집니다. 다른 워크로드에서 얻은 절감률로 이 측정을 대신할 수는 없습니다.

API가 성공 응답을 반환했다는 사실만으로는 답변 품질을 거의 알 수 없습니다. 오류 폴백은 사용할 수 없는 엔드포인트를 우회할 수 있지만, 매끄러운 답변 속에 지어낸 정책이 들어 있는지는 감지하지 못합니다. 품질 문제로 상위 모델에 넘기려면 별도의 검사가 필요하고, 그 검사에도 고유한 오류율과 비용이 있습니다.

난이도 점수도 똑같이 검증해야 합니다. 분류기의 신뢰도가 곧 선택된 모델이 정답을 낼 확률은 아닙니다. 모든 임계값은 실제로 관찰한 작업 결과에 맞춰 보정해야 합니다. 사용자가 입력한 “이건 쉬운 일이에요” 같은 문구로 애플리케이션의 권한이나 후보 제한을 우회하게 해서는 안 됩니다.

마지막으로 앱 코드가 그대로여도 자동 선택은 달라질 수 있습니다. OpenRouter의 지출 기반 후보는 계속 바뀌며, Microsoft의 현재 model-router 버전에는 구성 모델이 추가될 수 있습니다. 문서에 명시된 이런 동작을 고려하면 후보 모델 기록과 평가 갱신은 선택적인 정리 작업이 아니라 라우터 운영의 일부입니다.

누가 도입해야 하고, 누가 기다려야 하나요?

개발팀은 합격 조건이 분명한 반복 작업을 따로 가려낼 수 있을 때 시작해야 합니다. 근거가 확보된 상태 안내 답변에 소형 모델 경로를 추가하고, 불확실한 요청은 보수적으로 처리할 경로를 유지하며, 실패를 재현할 수 있도록 정책의 버전을 관리합니다.

운영팀은 워크플로 전체의 근거를 요구해야 합니다. 티켓 재접수, 사람의 검토, 해결 시간이 늘어난다면 추론 비용이 줄었다는 사실만으로는 충분하지 않습니다. 오프라인 평가와 함께 이런 결과도 추적해야 합니다.

구매 담당자는 자사의 사례를 재실행해 달라고 요청해야 합니다. 선택된 모델과 폴백 동작을 확인할 수 있어야 합니다. 일반적인 벤치마크로는 라우터가 자사의 환불 정책을 이해하는지 판단할 수 없습니다.

올바른 결과를 정의할 수 없거나, 후보 풀을 제한할 수 없거나, 운영에 들이는 노력을 회수할 만큼 트래픽이 충분하지 않다면 도입을 미루는 편이 낫습니다. 고정된 좁은 작업에 이미 검증된 소형 모델을 쓰는 앱은 선택기를 추가해도 얻는 이점이 작을 수 있습니다.

다음 업무일에 바로 시작할 일은 이렇습니다. 대표적인 고객 지원 사례를 내보내고 근거 자료를 고정한 다음, 현재 모델과 더 작은 후보 하나를 나란히 평가합니다. 작은 후보가 통과한 요청 유형에 한정해 라우팅 규칙을 작성합니다. 자동 라우터에는 동일한 품질 요건을 충족하면서 그 규칙보다 비용을 낮춘다는 점을 확인한 뒤에만 트래픽을 맡깁니다.

모델 라우팅에 관한 자주 묻는 질문

AI 애플리케이션 구축과 평가에 관한 실용적인 가이드를 받아보려면 뉴스레터를 구독하세요.