RAG에 사용할 LLM 라우터 개발하기

RAG에 LLM 라우터를 붙인다는 말은 단순히 여러 모델 이름 중 하나를 고르는 기능을 만든다는 뜻이 아닙니다. 사용자의 질문, 검색된 문서의 신뢰도, 컨텍스트 길이, 답변에 필요한 추론 난이도, 비용과 지연 시간, 개인정보 민감도를 함께 보고 어떤 모델로 보낼지 결정하는 제어 계층을 만든다는 뜻에 가깝습니다.

RAG는 검색 결과가 매 요청마다 달라집니다. 같은 질문이라도 검색 문서가 충분할 때와 부족할 때, 최신 문서가 있을 때와 오래된 문서만 있을 때, 단순 요약이면 되는 경우와 여러 문서를 비교해야 하는 경우가 다릅니다. 모든 요청을 가장 비싼 모델로 보내면 비용이 커지고, 모든 요청을 가벼운 모델로 보내면 근거가 약한 답변이나 누락이 늘어납니다. LLM 라우터는 이 균형을 운영 규칙으로 다루기 위한 장치입니다.

LLM 라우터의 역할

LLM 라우터는 사용자 요청과 RAG 컨텍스트를 받은 뒤 적절한 실행 경로를 선택합니다. 여기서 실행 경로는 모델 선택만 의미하지 않습니다. 컨텍스트를 더 검색할지, 답변을 보류할지, 사람 검토로 넘길지, 저비용 모델로 요약만 할지, 고성능 모델로 비교 판단을 시킬지까지 포함합니다.

기본 역할은 네 가지로 나눌 수 있습니다.

첫째, 질문의 의도를 분류합니다. 단순 정보 조회, 문서 요약, 여러 문서 비교, 정책 판단, 코드 생성, 장애 원인 분석은 필요한 모델 특성이 다릅니다.

둘째, 검색 컨텍스트를 평가합니다. 문서 출처가 믿을 만한지, 서로 모순되는 문서가 있는지, 답변에 필요한 근거가 충분한지, 토큰 길이가 과도한지 확인합니다.

셋째, 운영 정책을 적용합니다. 개인정보나 보안 정보가 포함된 요청은 외부 모델로 보내지 않거나 마스킹을 먼저 수행해야 합니다. 응답 시간이 중요한 화면에서는 고성능 모델보다 빠른 모델이 더 적절할 수도 있습니다.

넷째, 라우팅 결과를 기록합니다. 어떤 모델을 왜 선택했는지 남기지 않으면 나중에 품질 문제, 비용 증가, 장애 원인을 추적하기 어렵습니다.

RAG에서 라우터가 필요한 이유

일반 챗봇의 모델 라우팅은 질문만 보고 결정하는 경우가 많습니다. RAG에서는 질문만으로 충분하지 않습니다. 검색된 문서가 답변 품질을 크게 바꾸기 때문입니다. RAGRouter 논문도 RAG 환경에서는 외부 문서가 모델의 응답 품질에 동적으로 영향을 주기 때문에, 검색 문서를 라우팅 판단에 포함해야 한다고 설명합니다.

예를 들어 “이 정책을 요약해줘”라는 질문은 겉보기에는 단순합니다. 하지만 검색된 문서가 2쪽짜리 공지인지, 80쪽짜리 보안 정책인지, 서로 다른 버전의 문서가 섞여 있는지에 따라 필요한 모델이 달라집니다. 짧고 명확한 문서라면 빠른 모델로 충분할 수 있습니다. 서로 다른 문서의 충돌을 설명해야 한다면 추론력이 좋은 모델이 필요합니다. 개인정보가 들어 있으면 모델 선택 전에 마스킹이나 차단이 먼저입니다.

따라서 RAG 라우터는 “질문 분류기”가 아니라 “질문과 검색 결과를 함께 보는 운영 판단기”로 설계해야 합니다.

라우터가 봐야 할 입력 신호

처음부터 복잡한 머신러닝 라우터를 만들 필요는 없습니다. 운영에 필요한 신호를 명확히 정하고, 규칙 기반으로 시작하는 편이 관리하기 쉽습니다.

이 표가 라우터 정책의 출발점입니다. 중요한 점은 “좋은 모델 하나”를 찾는 것이 아니라, 요청 상태에 따라 선택 기준을 다르게 적용하는 것입니다.

권장 아키텍처

실제 구현에서는 라우터를 하나의 거대한 함수로 만들기보다 책임을 나누는 편이 좋습니다.

`Query Analyzer`는 질문의 목적과 위험도를 분류합니다. 예를 들어 단순 조회인지, 비교 판단인지, 코드 실행을 요구하는지, 개인정보가 포함되어 있는지 판단합니다.

`Context Evaluator`는 검색 결과를 봅니다. 문서 수, 출처, 최신성, 토큰 수, 중복, 근거 문장 존재 여부를 계산합니다. RAG에서는 이 단계가 특히 중요합니다. 검색 결과가 나쁘면 모델을 바꿔도 답변 품질이 크게 좋아지지 않습니다.

`Policy Engine`은 운영 규칙을 적용합니다. 비용 상한, 모델별 허용 작업, 보안 정책, 사용자 권한, 응답 시간 기준을 한곳에서 관리합니다.

`Model Gateway`는 실제 모델 호출을 담당합니다. 라우터가 직접 여러 SDK 호출 코드를 흩뿌리면 장애 대응이 어려워집니다. 게이트웨이에서 타임아웃, 재시도, 폴백, 토큰 제한을 통일하는 편이 안전합니다.

`Evaluation Logger`는 라우팅 이유와 결과를 남깁니다. 요청 원문 전체를 무조건 저장하기보다 라우팅에 필요한 요약 신호, 선택된 모델, 정책 버전, 비용, 지연 시간, 오류 상태를 남깁니다.

규칙 기반으로 시작하는 라우팅 정책

처음부터 학습 기반 라우터를 만들면 설명 가능성과 장애 대응이 어려워질 수 있습니다. 운영 초기에는 결정 규칙을 명시적으로 두고, 로그가 쌓인 뒤 점수 기반이나 학습 기반 라우터로 확장하는 편이 현실적입니다.

예시는 다음처럼 단순하게 시작할 수 있습니다.

routes:
  - name: sensitive-request
    when:
      pii_detected: true
    action:
      type: block_or_mask
      next: internal_model

  - name: weak-context
    when:
      evidence_score_below: 0.45
    action:
      type: retrieve_again
      max_retry: 1

  - name: complex-comparison
    when:
      intent: compare
      context_documents_over: 3
    action:
      type: model
      model_class: reasoning

  - name: simple-summary
    when:
      intent: summarize
      context_tokens_below: 4000
      evidence_score_over: 0.70
    action:
      type: model
      model_class: fast

이 정책에서 중요한 부분은 모델 이름을 직접 박아 넣지 않는 것입니다. `fast`, `reasoning`, `internal_model`처럼 모델 등급을 먼저 정하고, 실제 모델명은 별도 설정에서 관리하면 교체가 쉽습니다.

구현 예시

아래 코드는 실제 서비스 코드의 축약 예시입니다. 핵심은 질문과 컨텍스트를 따로 평가한 뒤, 정책 결정 결과를 남기는 구조입니다.

from dataclasses import dataclass


@dataclass
class RouteDecision:
    action: str
    model_class: str | None
    reason: str


def route_request(query_features, context_features, runtime_state) -> RouteDecision:
    if query_features.pii_detected:
        return RouteDecision(
            action="mask_then_model",
            model_class="internal",
            reason="pii_detected",
        )

    if context_features.evidence_score < 0.45:
        return RouteDecision(
            action="retrieve_again",
            model_class=None,
            reason="weak_context",
        )

    if runtime_state.reasoning_model_unavailable:
        return RouteDecision(
            action="model",
            model_class="fallback",
            reason="reasoning_model_unavailable",
        )

    if query_features.intent in {"compare", "policy_judgement", "root_cause"}:
        return RouteDecision(
            action="model",
            model_class="reasoning",
            reason="complex_reasoning_required",
        )

    return RouteDecision(
        action="model",
        model_class="fast",
        reason="simple_grounded_answer",
    )

이 정도 구조만 있어도 “왜 이 모델을 썼는지”를 설명할 수 있습니다. 라우터의 첫 번째 목표는 똑똑한 자동화가 아니라 운영자가 납득할 수 있는 선택 기준을 만드는 것입니다.

폴백과 장애 대응

LLM 라우터에서 폴백은 단순히 실패하면 다른 모델로 보내는 기능이 아닙니다. 어떤 실패를 허용하고, 어떤 실패는 멈춰야 하는지 구분해야 합니다.

타임아웃이나 일시적인 사용량 제한은 폴백 모델을 호출할 수 있습니다. 하지만 개인정보 마스킹 실패, 근거 부족, 고위험 정책 판단은 모델만 바꿔서 해결하면 안 됩니다. 이 경우에는 답변을 보류하거나 사람 검토로 넘기는 편이 안전합니다.

운영 정책에는 최소한 다음 기준이 있어야 합니다.

• 모델 호출 실패 시 재시도 횟수
• 폴백 모델로 보낼 수 있는 요청 유형
• 폴백 금지 요청 유형
• 근거 부족 시 재검색 기준
• 사람 검토로 넘기는 조건
• 사용자에게 보여줄 오류 메시지

장애 대응 기준이 없으면 라우터는 품질을 높이는 장치가 아니라 조용히 문제를 숨기는 장치가 될 수 있습니다.

평가 지표

LLM 라우터는 모델 선택 정확도만 보면 부족합니다. RAG 서비스에서는 답변이 근거와 맞는지, 비용이 줄었는지, 지연 시간이 관리되는지, 위험 요청이 제대로 걸러졌는지를 함께 봐야 합니다.

이 지표는 모델 성능 평가이면서 동시에 검색 품질 평가입니다. 라우터가 자주 고성능 모델을 선택한다면 모델 문제가 아니라 검색 컨텍스트가 부실한 것일 수도 있습니다.

로그와 보안

라우터 로그에는 모든 프롬프트와 문서를 그대로 남기지 않는 편이 좋습니다. 특히 사내 문서, 고객 정보, 보안 설정이 들어간 RAG에서는 로그가 또 다른 위험이 될 수 있습니다.

권장 로그 항목은 다음과 같습니다.

• 요청 ID
• 질문 의도 분류 결과
• 컨텍스트 문서 수와 토큰 수
• 출처 유형과 신뢰도 점수
• 개인정보 감지 여부
• 선택된 모델 등급
• 라우팅 이유
• 정책 버전
• 응답 시간과 비용
• 오류와 폴백 여부

원문 저장이 필요하다면 접근 권한, 보관 기간, 마스킹 기준을 별도로 둬야 합니다. 라우터를 만들 때 로그 설계를 뒤로 미루면 운영 중 문제가 생겼을 때 원인을 찾기도 어렵고, 개인정보 관리도 어려워집니다.

배포 순서

처음부터 모든 트래픽을 라우터에 맡기지 말고 단계적으로 적용하는 것이 좋습니다.

1. 기존 단일 모델 흐름을 유지한 채 라우터가 어떤 결정을 내렸을지만 기록합니다.

2. 로그를 보고 규칙이 너무 공격적인지, 너무 보수적인지 조정합니다.

3. 단순 요약이나 조회처럼 위험이 낮은 요청부터 실제 라우팅을 적용합니다.

4. 비교 판단, 정책 판단, 보안 관련 요청은 별도 검증 후 적용합니다.

5. 비용, 지연 시간, 답변 품질, 폴백 비율을 주기적으로 봅니다.

6. 문제가 생기면 즉시 단일 모델 경로로 되돌릴 수 있는 스위치를 둡니다.

이 순서를 지키면 라우터 도입이 모델 교체 실험으로 끝나지 않고, RAG 운영 품질을 관리하는 체계로 자리 잡을 수 있습니다.

자주 생기는 실수

가장 흔한 실수는 질문만 보고 라우팅하는 것입니다. RAG에서는 검색 컨텍스트가 답변 품질을 좌우하므로 문서 상태를 반드시 함께 봐야 합니다.

두 번째 실수는 비싼 모델을 정답처럼 다루는 것입니다. 근거가 부족하면 고성능 모델도 그럴듯한 답을 만들 뿐입니다. 이 경우에는 모델 변경보다 재검색, 컨텍스트 정리, 답변 보류가 먼저입니다.

세 번째 실수는 폴백을 무조건 허용하는 것입니다. 보안이나 개인정보 요청에서 폴백이 잘못 작동하면 원래 차단해야 할 요청이 다른 모델로 흘러갈 수 있습니다.

네 번째 실수는 로그를 남기지 않는 것입니다. 라우터는 운영 중 계속 바뀌는 정책입니다. 선택 이유와 결과가 없으면 개선할 근거가 없습니다.

결론

RAG에 사용할 LLM 라우터는 비용 절감 도구이면서 동시에 품질 관리 도구입니다. 좋은 라우터는 가장 강한 모델을 항상 고르는 시스템이 아니라, 질문과 검색 컨텍스트를 보고 지금 필요한 처리 방식을 설명 가능하게 선택하는 시스템입니다.

초기에는 명시적 규칙으로 시작하는 편이 좋습니다. 질문 의도, 컨텍스트 품질, 문서 신뢰도, 민감도, 비용과 지연 시간 기준을 분리해서 기록하고, 운영 로그를 보면서 정책을 조정해야 합니다. 충분한 데이터가 쌓이면 점수 기반 또는 학습 기반 라우팅으로 확장할 수 있습니다.

핵심은 라우터를 모델 호출 앞의 작은 분기문으로 보지 않는 것입니다. RAG 서비스에서 라우터는 검색, 모델, 보안, 비용, 평가를 연결하는 운영 제어 계층입니다.

FAQ

처음부터 학습 기반 라우터를 만들어야 하나요?

대부분은 아닙니다. 서비스 초기에는 규칙 기반 라우터가 더 설명하기 쉽고 운영자가 수정하기도 쉽습니다. 학습 기반 라우터는 충분한 품질 평가 데이터와 실패 사례가 쌓인 뒤 검토하는 편이 좋습니다.

검색 결과가 나쁠 때 더 좋은 모델을 쓰면 해결되나요?

항상 그렇지는 않습니다. 근거가 부족한 상태에서 좋은 모델을 쓰면 그럴듯한 추측이 늘어날 수 있습니다. 이 경우에는 재검색, 문서 필터링, 답변 보류가 먼저입니다.

모델 라우터와 프롬프트 라우터는 같은 개념인가요?

겹치는 부분은 있지만 같지는 않습니다. 프롬프트 라우터는 어떤 프롬프트 템플릿을 쓸지 고르는 데 집중합니다. LLM 라우터는 모델, 재검색, 폴백, 사람 검토, 보안 처리까지 포함하는 더 넓은 운영 판단을 다룹니다.

더 확인할 자료

아래 자료는 RAG, 모델 선택, 라우팅 구조를 검토할 때 함께 확인할 만한 공식 문서와 연구 자료입니다.

• OpenAI Retrieval 문서
• OpenAI Models 문서
• LangChain 개요 문서
• RAGRouter: Efficient Retrieval-Augmented Generation via Routing