모두가 LLM 라우터를 만들고 있지만, 우리는 폐기했다

우리는 더 이상 모델 라우팅이 필요하다고 생각하지 않는다. 대부분의 사용 사례에서는 충분히 검증된 모델 하나를 계속 사용하는 것이 최선이다.

최근 요청에 응답할 모델을 실시간으로 선택하는 AI 모델 라우터가 큰 관심을 받고 있다. 지난 몇 주 동안 추론 비용을 줄여 준다는 비슷한 약속을 내건 제품이 여럿 출시됐다. 우리에게도 LLM 라우터가 있었지만, 이를 제거하기로 했다.

먼저 배경부터 설명하겠다. 우리는 지난 3월 LLM 게이트웨이의 핵심 기능으로 Manifest LLM 라우터를 출시했고, 6월에 지원 중단을 발표한 뒤 9월 1일 완전히 종료했다. 이 라우터는 각 요청의 복잡도를 단순, 표준, 복잡, 추론이라는 네 단계 중 하나로 분류했다.

대부분의 LLM 라우터와 마찬가지로 우리 라우터도 비용을 줄이기 위해 만들었다. 간단한 작업에 강력하고 그만큼 비싼 모델을 호출할 이유가 있을까? 비용 효율이 가장 좋은 모델로 요청을 보내면 자연스럽게 해결될 것 같지 않은가? 하지만 그렇게 간단하지 않았다. 7000명의 클라우드 사용자가 4개월 동안 사용한 결과는 엇갈렸고, GitHub에도 관련 이슈와 논의가 많이 올라왔다. 이제 주요 문제를 하나씩 살펴보자.

프롬프트만으로는 복잡도를 판단할 수 없다

프롬프트에는 작업 전체가 담겨 있지 않다. 프롬프트는 작업을 시작하는 계기일 뿐이다. 복잡도를 결정하는 맥락의 상당 부분은 이후 도구 호출이나 웹 검색 등을 거치면서 비로소 드러난다.

예를 들어 *"$GIT_REPO 저장소의 테스트를 평가하고 개선하라"*라는 요청을 생각해 보자. 순수 HTML5로 만든 개인 웹사이트를 가리킨다면 아주 간단한 작업일 수 있지만, Linux 커널 저장소를 대상으로 한다면 엄청나게 복잡한 작업이 될 수 있다.

비용 절감에는 라우팅보다 캐시가 더 효과적이다

캐시에서 읽는 비용은 캐시되지 않은 입력보다 75%에서 90% 저렴하다. 시스템 프롬프트와 대화 기록은 토큰에서 큰 비중을 차지할 때가 많다. 이 내용은 프롬프트 앞부분에 있으므로 프리픽스 캐시가 매우 효과적으로 작동한다.

캐시를 고려하는 모델 라우터라면 처음 선택한 모델을 계속 사용하도록 고정성을 부여하고, 이후 요청도 같은 모델에 보내야 한다. 아이러니하게도 라우터는 라우팅하지 않음으로써 제 역할을 하게 되는 셈이다.

LLM 라우터는 동작의 일관성을 깨뜨린다

일각에서는 "엔지니어가 작업에 가장 적합한 LLM을 고르는 데 신경 쓸 필요가 없다"고 말한다. 하지만 우리는 전혀 동의하지 않는다.

화가가 어떤 붓을 써야 하는지 정확히 알고 장인이 도구를 신중하게 고르듯, 엔지니어도 모델마다 어떤 장단점과 미묘한 차이가 있는지 이해해야 한다. Manifest에서는 모든 엔지니어가 의도에 맞춰 모델과 추론 강도 매개변수를 직접 선택한다.

작업 도중 모델을 계속 바꾸면 전체 결과물의 품질이 낮아지고, 사용자가 자신의 도구를 능숙하게 다루기도 어려워진다.

예측 불가능성에도 비용이 따른다

예측할 수 없는 것을 좋아하는 사람은 없다. 소프트웨어 엔지니어라면 특히 그렇다.

자동화된 에이전트 워크플로나 자율 에이전트에서는 추가된 불확실성을 관리하는 비용이 절감액보다 커질 수 있다. 평가, 시스템 프롬프트, 관측 가능성 등을 생각해 보라. 갑자기 모든 요소를 유지보수하기가 더 어려워진다.

대부분의 경우에는 요청을 서로 분리하고 각각에 적합한 모델, 매개변수, 프롬프트를 설정하는 편이 더 낫다.

결론

LLM 라우팅이 유용한 사용 사례도 분명 많을 것이며, 관련 제품을 출시한 회사들에도 타당한 이유가 있을 것이다.

하지만 우리가 경험한 사용 사례 대부분에서는 그럴 만한 가치가 없다는 결론을 내렸다. 한곳에서 아낀 비용은 결국 다른 곳에서 치르게 되며, 그 비용은 추산하기도 더 어렵다.

^{source https://manifest.build/blog/why-we-deprecated-our-llm-router/}

HN에서는 프롬프트만 보고 난이도를 정하는 범용 라우터에 회의적인 반응이 두드러졌다. 작업의 복잡도는 저장소를 살피거나 도구를 호출한 뒤에야 드러나는 경우가 많다. 짧은 요청에 숨은 맥락까지 판별하려면 라우터가 문제를 상당 부분 먼저 풀어야 한다. 모델이 바뀔 때마다 답변 방식과 코드 작성 성향이 달라져 결과의 일관성이 흔들린다는 점도 부담이다.

다만 모델을 나눠 쓰는 방식 자체가 무의미하다는 뜻은 아니다. 탐색·설계·구현처럼 역할을 세분화하고, 실제 평가를 거쳐 각 단계에 맞는 모델을 고정하면 비용과 품질을 함께 관리할 수 있다는 경험이 나왔다. 법률·의료·코드처럼 입력 범주가 분명한 반복 업무도 분류하기 쉽다. 막연한 난이도 예측보다 업무 유형과 실행 단계를 구체적으로 정의하는 편이 낫다는 주장이다.

비용만 따져도 계산은 단순하지 않다. 캐시 효율을 유지하려면 같은 모델을 계속 쓰는 편이 유리해 잦은 전환의 이점이 줄어든다. 장애 대응이나 규제 준수는 라우터의 별도 가치가 될 수 있지만, 공급자마다 지원하는 도구가 달라 다른 모델이나 서비스로 곧바로 넘기기 어렵다. 반면 처리량이 크고 반복 작업이 많다면 초기 구축 비용보다 누적 절감 효과가 커질 수 있다.

결국 도입 전에 실제 업무를 분류하고 모델별 성능을 반복해서 검증할 수 있는지부터 확인해야 한다. 후보 모델은 적고 차이가 뚜렷해야 하며, 품질과 비용뿐 아니라 캐시 손실과 동작 일관성도 함께 측정해야 한다. 이런 근거가 없다면 검증된 단일 모델을 유지하는 편이 안정적이다. 역할별 성능 차이를 충분한 실행 기록으로 입증할 수 있을 때만 업무 맞춤형 오케스트레이션을 고려할 만하다.