
모두가 LLM 라우터를 만들고 있지만, 우리는 우리 것을 폐기했습니다
요약
비용 절감을 위해 도입했던 LLM 라우터 기능을 폐기한 이유를 분석합니다. 프롬프트만으로는 작업의 실제 복잡도를 판단하기 어렵고, 라우팅보다 캐싱을 활용하는 것이 비용 효율성 측면에서 훨씬 유리하다는 결론을 제시합니다.
핵심 포인트
- 프롬프트만으로는 도구 호출이나 컨텍스트를 포함한 실제 작업 복잡도를 예측할 수 없음
- 비용 절감에는 모델 라우팅보다 접두사 캐시(Prefix Cache) 활용이 훨씬 효과적임
- 라우팅은 모델 간 동작 일관성을 해칠 수 있으며 엔지니어의 직접적인 모델 선택이 중요함

우리는 더 이상 모델 라우팅 (model routing)을 신뢰하지 않습니다. 대부분의 사용 사례에서는 검증된 단일 모델을 고수하는 것이 당신이 할 수 있는 최선의 선택입니다.
최근, 요청에 따라 즉석에서 응답할 모델을 선택하는 AI 모델 라우터 (AI model routers)에 대한 엄청난 열풍이 불고 있습니다. 최근 몇 주 동안 추론 비용 (inference costs)을 절감하겠다는 유사한 약속을 내걸며 많은 출시가 있었습니다. 우리에게도 LLM 라우터가 있었지만, 이를 제거하기로 결정했습니다.
먼저 배경을 설명하자면: 우리는 지난 3월 Manifest LLM 게이트웨이 (LLM gateway)의 핵심 기능으로 Manifest LLM 라우터를 출시했고, 6월에 이를 폐기(deprecated)했으며, 9월 1일에 완전히 종료했습니다. 우리의 라우터는 각 요청을 단순(simple), 표준(standard), 복잡(complex), 추론(reasoning)의 네 가지 복잡도 계층 중 하나로 분류했습니다.

대부분의 LLM 라우터와 마찬가지로, 우리의 라우터도 비용 절감을 위해 만들어졌습니다. 단순한 작업을 위해 강력하고 따라서 비싼 모델을 호출할 필요가 있을까요? 가장 비용 효율적인 모델로 라우팅하는 것이 자연스러운 해결책처럼 보이지 않나요? 하지만 그렇게 간단하지 않습니다. 7,000명의 클라우드 사용자들을 대상으로 4개월간 사용해 본 결과, 엇갈린 결과와 함께 GitHub 이슈 및 관련 논의가 많이 발생했습니다. 주요 문제점들을 살펴보겠습니다.
복잡도는 프롬프트(prompt)만으로는 추론할 수 없습니다
프롬프트 자체에는 전체 작업이 포함되어 있지 않습니다. 그것은 단지 트리거 (trigger)일 뿐입니다. 복잡도를 결정하는 많은 컨텍스트 (context)는 도구 호출 (tool calls), 웹 검색 (web searches) 등을 통해 나중에야 발견됩니다.
예를 들어 보겠습니다: *“$GIT_REPO 리포지토리의 테스트를 평가하고 개선하라”*라는 문구는 단순한 HTML5로 작성된 개인 웹사이트를 언급한다면 매우 간단한 작업일 수 있지만, 리눅스 커널 (Linux kernel) 리포지토리를 대상으로 한다면 믿기지 않을 정도로 복잡한 작업이 될 수 있습니다.
비용 절감에는 라우팅보다 캐시(Cache)가 더 효과적입니다
캐시 읽기 (Cache reads)는 캐시되지 않은 입력 (uncached inputs)보다 75%에서 90% 사이로 더 저렴합니다. 시스템 프롬프트 (System prompts)와 대화 기록 (conversation history)은 종종 많은 토큰 (tokens)을 차지합니다. 접두사 캐시 (Prefix cache)는 이들이 프롬프트의 시작 부분에 위치하기 때문에 매우 효과적으로 작동합니다.
캐시를 인식하는 모델 라우터 (cache-aware model router)는 처음에 선택된 모델에 고착성 (stickiness)을 부여하여 해당 모델에 계속 쿼리를 보냄으로써 이를 고려할 것입니다. 즉, 라우터는 역설적이게도, 자신의 일을 하지 않음으로써 자신의 역할을 수행하게 됩니다.
LLM 라우터는 동작 일관성을 깨뜨립니다
어떤 이들은 "엔지니어가 자신의 작업에 가장 적합한 LLM을 선택하는 것에 대해 고민할 필요가 없다"라고 말합니다. 하지만 저희는 이에 강력히 반대합니다.
화가가 어떤 붓을 사용해야 할지 정확히 알고, 장인이 도구를 신중하게 선택하는 것과 마찬가지로, 엔지니어 또한 서로 다른 모델들의 트레이드오프 (trade-offs)와 미묘한 차이점을 이해해야 합니다. Manifest의 모든 엔지니어는 자신의 의도에 따라 모델과 노력 매개변수 (effort parameters)를 선택합니다.
작업 세션 중에 모델을 이리저리 옮겨 다니는 것은 전체 작업의 품질을 저하시키며, 사람들이 자신의 도구를 숙달하는 것을 방해합니다.
예측 불가능성에는 비용이 따릅니다
그 누구도 예측 불가능한 상황을 좋아하지 않으며, 특히 소프트웨어 엔지니어는 더욱 그렇습니다.
자동화된 에이전트 워크플로 (agentic workflows)나 자율 에이전트 (autonomous agents) 환경에서, 이 추가적인 불확실성 계층을 관리하는 비용은 절감되는 비용보다 더 클 수 있습니다. 평가 (evals), 시스템 프롬프트 (system prompts), 관측 가능성 (observability) 등을 생각해 보십시오. 모든 것이 갑자기 유지보수하기 어려워집니다.
각기 다른 요청을 격리하고 그에 맞는 적절한 모델, 매개변수 (params), 프롬프트를 설정하는 것이 대부분의 경우 자연스럽게 더 우월해 보입니다.
결론
LLM 라우팅이 유용할 수 있는 사례는 아마도 많을 것이며, 이를 출시한 기업들도 아마 타당한 이유가 있을 것입니다.
하지만 저희의 경험에 비추어 볼 때, 저희가 목격한 대부분의 사례에서는 그럴만한 가치가 없다는 결론을 내렸습니다. 절감된 금액은 다른 어딘가에서 지불되며, 그 비용은 추산하기가 더 어렵습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 HN AI Posts의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기