TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 31 READS

LLM 라우터를 접은 Manifest의 결정, 단일 모델이 답인 이유

LLM 라우터를 접은 Manifest의 결정, 단일 모델이 답인 이유
SOURCE IMAGE · HACKER NEWS

요청마다 가장 적합한 모델을 실시간으로 골라주는 'LLM 라우터'가 최근 몇 주 사이 잇따라 출시되며 화제를 모으고 있다. 공통된 약속은 하나다. 간단한 작업에 굳이 비싼 고성능 모델을 쓰지 말고, 요청의 난이도에 맞춰 저렴한 모델로 흘려보내 추론 비용을 줄이자는 것이다. 그런데 이 흐름에 정면으로 반대하는 사업자가 나왔다. LLM 게이트웨이를 운영하는 Manifest는 자사 라우터를 스스로 폐기하며, 대부분의 실무 상황에서는 검증된 단일 모델을 꾸준히 쓰는 편이 낫다고 결론지었다.

Manifest는 올해 3월 게이트웨이의 핵심 기능으로 LLM 라우터를 선보였다. 이 라우터는 들어오는 요청을 단순(simple), 표준(standard), 복잡(complex), 추론(reasoning)의 네 가지 복잡도 등급으로 분류해 그에 맞는 모델로 연결하는 방식이었다. 목적은 여느 라우터와 같은 비용 절감이었다. 그러나 7,000명의 클라우드 사용자를 대상으로 넉 달간 운영한 결과는 엇갈렸고, GitHub에는 관련 이슈와 논의가 쌓였다. 결국 회사는 6월에 이 기능을 지원 중단(deprecate)하기로 했고, 9월 1일자로 완전히 종료하기로 했다.

프롬프트만으로는 난이도를 알 수 없다

라우팅이 무너지는 첫 번째 지점은 분류의 전제 자체에 있다. 라우터는 들어온 프롬프트를 보고 난이도를 판정하지만, 프롬프트는 작업의 전부가 아니라 방아쇠에 불과하다. 실제 복잡도를 좌우하는 맥락은 이후 도구 호출이나 웹 검색을 거치며 뒤늦게 드러나는 경우가 많다. Manifest가 든 예시가 이를 잘 보여준다. "저장소 $GIT_REPO의 테스트를 평가하고 개선하라"는 동일한 지시라도, 대상이 순수 HTML5로 짜인 개인 홈페이지라면 지극히 단순한 작업이지만 리눅스 커널 저장소라면 극도로 복잡한 작업이 된다. 겉으로 드러난 문장이 같아도 실제 부하는 전혀 다른데, 라우터는 그 차이를 첫 프롬프트에서 알아낼 방법이 없다.

두 번째 문제는 비용 구조 자체가 라우팅을 배신한다는 점이다. 캐시된 입력은 캐시되지 않은 입력보다 75%에서 90%까지 저렴하다. 시스템 프롬프트와 대화 이력은 토큰 양이 상당한데, 이들은 프롬프트 앞부분에 고정적으로 자리 잡기 때문에 프리픽스 캐시가 매우 잘 작동한다. 문제는 캐시를 의식하는 라우터라면 처음 고른 모델에 '고착성(stickiness)'을 부여해 계속 같은 모델로 질의를 보내야 한다는 데 있다. 즉 캐시 이점을 살리려면 라우터는 라우팅을 하지 않아야 하는 역설에 빠진다. 요청마다 모델을 갈아타는 순간 캐시 할인이 날아가고, 절감하려던 비용이 오히려 다른 곳에서 새어 나온다.

엔지니어는 도구를 스스로 골라야 한다

Manifest의 반대는 비용 계산을 넘어 철학의 영역으로 이어진다. "엔지니어가 작업에 맞는 최적의 LLM을 고르는 일에 신경 쓸 필요가 없다"는 일각의 주장에 회사는 강하게 동의하지 않는다. 화가가 어떤 붓을 쓸지 정확히 알고 장인이 도구를 신중히 고르듯, 엔지니어도 모델마다의 트레이드오프와 미묘한 차이를 이해해야 한다는 것이다. Manifest에서는 실제로 모든 엔지니어가 자신의 의도에 맞춰 모델과 노력(effort) 파라미터를 직접 고른다. 작업 도중 이 모델 저 모델로 옮겨 다니면 전체 결과물의 품질이 떨어지고, 사람이 자기 도구를 숙달할 기회에서 멀어진다는 지적이다.

예측 가능성의 문제도 크다. 자동화된 에이전트 워크플로나 자율 에이전트에서는 라우터가 더하는 불확실성의 층을 관리하는 비용이 절감액을 넘어설 수 있다. 평가(eval), 시스템 프롬프트, 관측성(observability) 같은 요소가 모두 갑자기 유지하기 어려워지기 때문이다. 어떤 요청이 어떤 모델로 갈지 매번 달라지면 결과를 재현하고 문제를 추적하는 일 자체가 흔들린다. 그래서 각 요청을 분리해 적절한 모델과 파라미터, 프롬프트를 명시적으로 세팅하는 방식이 대부분의 경우 자연스럽게 우월하다는 것이 이들의 결론이다.

실무자가 새겨야 할 지점

Manifest도 라우팅이 유용한 사례가 분명히 존재하며, 라우터를 출시한 회사들에게도 나름의 합당한 이유가 있을 것이라고 인정한다. 다만 자신들이 관찰한 대부분의 사용 사례에서는 그만한 가치가 없었고, 절감한 비용은 결국 다른 곳에서 지불되는데 그 비용은 추정하기가 더 어렵다는 것이 핵심이다. 이 진단은 한 게이트웨이 사업자의 경험담이라는 점, 그리고 7,000명 규모의 특정 사용자군에서 나온 판단이라는 점을 감안해 읽어야 한다. 라우팅이 유효한 조건—예컨대 캐시 의존도가 낮고 요청 간 맥락이 단절된 대량 배치 작업—은 여전히 남아 있다. 그럼에도 이 사례가 던지는 실무적 메시지는 분명하다. 비용 절감을 자동화 계층에 위임하기 전에, 그 절감이 예측 가능성과 재현성, 캐시 효율이라는 눈에 덜 띄는 비용으로 되돌아오지 않는지 먼저 따져봐야 한다는 것이다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://manifest.build/blog/why-we-deprecated-our-llm-router...
SHARE
처리 중...