라우팅 — 프롬프트·모델·에이전트 라우터를 결정모델로

라우팅은 분류의 응용입니다

3장에서 문의·티켓·콘텐츠를 Choice·Score·Noul 스키마로 나누는 분류 설계를 봤습니다. 라우팅은 그 분류 결과에 '그래서 다음에 어디로 보낼지'를 한 겹 얹은 것입니다. 판정이 라벨에서 끝나지 않고, 그 라벨이 곧바로 코드의 경로를 고릅니다.

TypeSafe 공식 문서는 작업 유형을 나누면서 라우팅을 "카테고리가 다음 코드 경로를 선택하는 경우"로 정의합니다(docs.typesafe.ai). 분류와 라우팅의 차이는 목적입니다. 분류는 라벨 자체가 목표고, 라우팅은 그 라벨로 흐름을 가르는 게 목표입니다.

세 가지 라우팅 패턴

실무에서 마주치는 라우팅은 크게 세 갈래입니다. 이 장은 이 셋을 차례로 풉니다.

공통 골격은 '판정 → 임계값 → 분기'

세 패턴 모두 구조는 같습니다. 결정모델이 확률과 신뢰도를 돌려주면, 코드가 그 숫자를 임계값과 견줘 경로를 정합니다. 모델은 '의미적 판단'만 맡고, 실제 분기와 제어 흐름은 코드가 쥡니다. TypeSafe 문서의 표현을 빌리면 "코드가 제어 흐름을 소유하고, 모델은 의미적 결정을 처리"합니다(docs.typesafe.ai).

모델 라우팅 — 복잡도를 채점해 나눕니다

가장 이득이 큰 패턴부터 봅니다. 모델 라우팅은 들어온 요청이 얼마나 어려운지를 먼저 채점해서, 단순한 요청은 값싼 모델로, 어려운 요청만 비싼 모델로 넘기는 방식입니다. 라벨을 다는 판단 자체를 비싼 LLM에 시키면 배보다 배꼽이 커지므로, 이 앞단 판단을 Jev (TypeSafe AI) 같은 결정모델이 맡습니다.

저비용·고성능 사이를 고르는 논리

핵심은 "작업을 끝낼 수 있는 가장 저렴한 모델을 고르라"는 기준 하나입니다. 직접 조회, 값 추출, 국소적 수정 같은 요청은 빠른 모델로 충분하고, 아키텍처 설계나 되돌리기 어려운 판단은 고성능 모델로 보냅니다. LangChain 공식 블로그는 이 라우팅 판정에 Jev를 두는 ModelRouterMiddleware 패턴을 소개합니다(langchain.com).

LangChain ModelRouterMiddleware 예시

아래는 문서 형태를 참고한 개념 예시입니다(실제 모델 ID 문자열은 문서마다 표기가 달라 그대로 옮기지 않았습니다).

# illustrative — langchain.com 문서 형태 참고
router = ModelRouterMiddleware(
    choices={
        "fast":     ModelChoice(criteria="직접 조회·추출·국소 수정"),
        "powerful": ModelChoice(criteria="아키텍처·고위험 결정"),
    },
    instructions="작업을 끝낼 수 있는 가장 저렴한 모델을 고르라.",
)
agent = create_agent(middleware=[router])

여기서 결정모델은 요청을 읽고 fast/powerful 중 하나를 확률과 함께 돌려줄 뿐이고, 실제 LLM 호출은 뒤에서 일어납니다. 앞단 판정이 값싸고 빠르다는 점이 이 구조의 전부입니다.

Jev 응답 지연 70~500ms · 입력 100만 토큰당 $0.042(출력 무료) — 비교 LLM 입력 단가 $0.20~$10 (typesafe.ai)

라우팅으로 비용이 몇 배 줄었는지 같은 구체 수치는 LangChain이 공개하지 않아 단정하지 않겠습니다. 다만 앞단 판정 단가가 위 숫자라면, 라우팅 자체의 오버헤드는 사실상 무시할 만한 수준입니다.

프롬프트·의도 라우팅 — Choice로 핸들러를 고릅니다

두 번째 패턴은 사용자 의도를 먼저 분류해서, 그 의도에 맞는 프롬프트나 핸들러로 넘기는 것입니다. 챗봇이 "결제 문의"인지 "환불 요청"인지 "일반 문의"인지에 따라 서로 다른 프롬프트와 도구를 붙여야 할 때 쓰입니다.

의도를 Choice로 분류해 분기

의도 라우팅의 뼈대는 Choice 하나입니다. 후보 의도를 옵션으로 넣으면(옵션은 최대 255개까지 가능) 각 옵션의 확률 분포와 신뢰도가 돌아오고, 코드는 가장 확률 높은 의도에 해당하는 핸들러를 실행합니다. 3장에서 다룬 '전체 카테고리를 빠짐없이 나열하고, 다 못 담으면 other를 추가하라'는 스키마 규칙이 그대로 적용됩니다.

확률·신뢰도 임계값으로 자동과 폴백을 가름

의도가 분명하면 자동 처리하고, 애매하면 사람이나 더 무거운 처리로 넘기는 게 실전 설계입니다. 신뢰 문서에서 찾은 가장 구체적인 임계값 코드는 환불 판정 예시입니다.

# illustrative — docs.typesafe.ai 환불 예시 참고
if refund.noul > 0.7:
    route_to_billing_with_flag(ticket_id, refund_likely=True)
else:
    route_to_billing(ticket_id)

숫자 하나(0.7)가 자동 처리와 플래그 부착을 가릅니다. 의도 라우팅도 같은 골격입니다. 최고 확률이 임계값을 넘으면 그 핸들러로 직행하고, 넘지 못하면 확인 단계나 기본 핸들러로 폴백합니다.

에이전트·툴 라우팅과 게이팅

세 번째는 방향이 조금 다릅니다. 앞의 둘이 '어디로 보낼지'를 골랐다면, 게이팅은 '실행해도 되는지'를 먼저 묻습니다. 에이전트가 도구를 호출하기 직전에 위험 여부를 판정해, 위험하면 실행 자체를 막는 패턴입니다.

도구 실행 전에 위험을 판정하는 AutoModeMiddleware

LangChain의 AutoModeMiddleware는 "위험한 결정을 내릴 수 있는 도구 호출을 Jev로 평가해 실행 전에 차단"합니다(langchain.com). 위험으로 판정되면 도구를 돌리는 대신 에러 ToolMessage를 돌려줍니다.

# illustrative — docs.langchain.com 문서 형태 참고
agent = create_agent(
    tools=[delete_all_backups],
    middleware=[AutoModeMiddleware(tools=[delete_all_backups])],
)

백업 전체 삭제처럼 되돌릴 수 없는 도구일수록 이 앞단 게이트가 값을 합니다. 전통적으로는 풀 LLM에 맡기던 안전 판단을 Choice·Noul만으로 처리하는, 결정모델의 대표적인 경계 사례입니다.

가드레일 Noul 배터리와 정책 임계값

게이팅을 좀 더 촘촘하게 짜면 여러 Noul을 한 번에 묻는 '배터리' 형태가 됩니다. TypeSafe 가드레일 쿡북은 jailbreak(탈옥)·harmful_request·medical_advice·self_harm을 각각 Noul로 정의하고, 위해도는 0~3 단계 Score로 함께 채점합니다(docs.typesafe.ai). 그리고 임계값 정책으로 결과를 네 갈래로 가릅니다.

같은 질문 배터리를 사용자 입력에도, LLM 응답에도 걸 수 있습니다. 도구 호출 앞의 게이트와 응답 반환 앞의 재검증을 하나의 스키마로 돌리는 셈입니다.

임계값 설계와 자동화 연결

세 패턴을 관통하는 건 결국 임계값 설계입니다. 결정모델은 확률과 신뢰도를 주지만, 그 숫자를 어디서 자르느냐는 온전히 코드의 몫입니다. 그리고 그 코드는 대개 홀로 돌지 않고 기존 게이트웨이·자동화 흐름 안의 분기점에 얹힙니다.

응답 필드를 읽어 분기 조건을 짭니다

스키마마다 읽는 필드가 다릅니다. 분기 조건을 짤 때 헷갈리기 쉬운 지점입니다.

• Choice choice(선택)와 probabilities(합 1.0), confidence(0~1)를 봅니다. 보통 최고 확률과 신뢰도를 함께 임계값에 겁니다.
• Score score(레벨의 확률가중평균)와 legend, confidence를 봅니다. 복잡도 채점 라우팅에 쓰입니다.
• Noul 별도 신뢰도 필드 없이 noul 확률 하나가 곧 답입니다. 게이팅 판정에 그대로 씁니다.

액션별로 임계값을 달리 둡니다

임계값을 하나의 숫자로 고정하면 안 됩니다. TypeSafe 신뢰도 문서는 "같은 시스템 안에서도 결과의 중대성에 따라 액션별로 다른 임계값을 적용하라"고 안내합니다(docs.typesafe.ai). 흔한 패턴은 기본 0.5 바닥값을 두되, 파괴적이거나 되돌릴 수 없는 작업은 0.9 이상으로 더 높이는 것입니다.

신뢰도 3단계 운영: 높음 → 자동 실행 / 중간 → 확인·검토 플래그 / 낮음 → 사람에게 라우팅하거나 다른 시스템으로 폴백 (docs.typesafe.ai)

보편적으로 통하는 임계값은 없습니다. 문서 스스로 "보수적으로 시작해 도메인과 모델 성능에 맞춰 조정하라"고 못 박습니다. 처음에는 높게 걸어 대부분을 사람에게 보내고, 데이터가 쌓이면 자동 처리 구간을 넓히는 순서가 안전합니다.

모델 게이트웨이의 '어디로 보낼지'를 맡습니다

OpenRouter처럼 여러 LLM을 한 엔드포인트로 묶어 주는 게이트웨이를 쓸 때, '이 요청을 어느 모델로 보낼지'라는 판단을 결정모델이 앞단에서 내립니다. 게이트웨이는 호출을 대신 라우팅해 주지만 '무엇이 저렴하고 충분한가'라는 의미적 판단까지 대신 해 주지는 않습니다. 그 빈자리가 결정모델의 자리입니다.

워크플로 자동화의 분기 노드로

n8n·Make·Zapier 같은 워크플로 자동화 도구는 노드를 이어 붙여 흐름을 만듭니다. 결정모델을 HTTP 노드로 호출해 Choice·Noul 결과를 받고, 그 값으로 다음 분기(승인/보류, A경로/B경로)를 정하면 됩니다. 라우팅 로직을 코드로 직접 짜지 않고도 결정모델의 판정을 흐름 한가운데에 꽂는 방법입니다.

정리

라우팅은 분류에 '다음 경로'를 얹은 응용이고, 모델 라우팅(Score)·의도 라우팅(Choice)·툴 게이팅(Noul)이라는 세 패턴 모두 '판정 → 임계값 → 분기'라는 같은 골격을 씁니다. 확률과 신뢰도를 읽어 임계값을 액션별로 다르게 거는 설계가 실전 품질을 가릅니다.

다음 장에서는 '스코어링·추출·안전 점검 — 구조화 출력이 필요한 작업들'을 다룹니다. 환불정책 적용·계정 리스크 평가 같은 스코어링, 정해진 필드로 값을 판정하는 추출·트리아지, 그리고 LLM 생성물 앞뒤에 결정모델을 두는 안전 패턴을 실전 예시로 살펴보겠습니다.