Manifest의 라우터 폐기, 모델 선택 자동화의 역설
LLM 라우터는 단가를 낮추는 장치처럼 보이지만 실제 에이전트 운영에서는 캐시 손실, 행동 일관성, 평가 복잡도라는 보이지 않는 비용을 만든다. 자동 선택보다 의도별 고정 경로가 더 강한 기본값이 될 수 있다.
AI 뉴스를 놓치지 마세요
매주 핵심 AI 소식을 이메일로 받아보세요.
라우터 붐 속의 역주행
Manifest는 LLM 라우터를 폐기한다고 밝혔다. 회사는 2026년 3월 라우터를 출시했고 6월에 deprecate했으며 9월 1일 완전히 종료한다고 설명한다. 네 단계, 즉 simple, standard, complex, reasoning으로 요청을 분류해 더 싼 모델로 보내는 방식이었지만 7,000명 cloud 사용자 경험에서 기대만큼 명확한 효율을 만들지 못했다는 것이다.
이 결정은 시장 흐름과 반대다. Manifest의 LLM Gateway 자체도 여러 provider, BYOK, local model, 관측성을 제공한다. NVIDIA LLM Router는 더 넓은 NeMo Switchyard로 이어졌고, LiteLLM 라우터는 fallback과 load balancing을 주요 기능으로 내세운다. 그런데 Manifest는 비용 절감용 동적 라우팅만큼은 제거했다. Gemini Flash 세대교체, 에이전트 원가를 겨냥하다 이후 계속된 원가 경쟁 속에서 꽤 중요한 반례다.
프롬프트만 보고 난이도를 알 수 없다
Manifest의 첫 번째 주장은 프롬프트만으로 태스크 복잡도를 판단하기 어렵다는 것이다. 같은 테스트 개선 요청도 개인 HTML 사이트라면 단순하지만 Linux kernel이라면 완전히 다른 문제가 된다. 에이전트는 도구 호출, 저장소 탐색, 웹 검색, 로그 확인 뒤에야 실제 복잡도를 안다. 라우터가 첫 요청만 보고 모델을 고르면 너무 이른 판단이 된다.
두 번째 주장은 캐시다. Manifest는 cache read가 uncached input보다 75~90% 저렴하다고 적었다. 시스템 프롬프트와 대화 기록은 prompt 앞부분에 고정되므로 prefix cache가 잘 먹힌다. 그런데 동적 라우터가 provider나 모델을 자주 바꾸면 이 stickiness가 깨진다. 결국 cache-aware 라우터는 처음 고른 모델을 계속 쓰는 방향으로 움직이고, 그 순간 라우터는 라우팅하지 않는 방식으로 자기 역할을 수행한다.
| 선택 방식 | 장점 | 숨은 비용 | 실무 권장 |
|---|---|---|---|
| 매 요청 동적 라우팅 | 이론상 단가 절감 | 캐시 손실, 평가 복잡도 | 제한적 실험 |
| 의도별 고정 모델 | 행동 일관성 | 초기 설계 필요 | 기본값 |
| fallback 라우팅 | 장애 대응 | 응답 차이 관리 | 필수 운영 기능 |
| provider gateway | 관측성과 비용 집계 | 민감 데이터 로그 관리 | 팀 단위 도입 |
예측 불가능성도 비용이다
라우터는 단가표에 보이지 않는 비용을 만든다. 모델이 바뀌면 system prompt 튜닝, eval 기준, 금칙어 처리, JSON 복구, tool call 안정성이 모두 흔들린다. 특히 자율 에이전트는 한 번의 답변보다 여러 단계의 일관성이 중요하다. 중간에 모델이 바뀌면 추론 스타일과 실패 양상이 달라지고, 관측성 대시보드는 더 복잡해진다.
이는 LLM 코딩은 10배가 아니라 2배에 가깝다의 메시지와 맞닿아 있다. 생산성은 모델 하나의 지능보다 피드백 루프의 안정성에서 나온다. Jack Dorsey의 Buzz, 협업툴을 에이전트 OS로 바꾸다처럼 작업 공간 안에 에이전트를 넣을수록 모델 선택은 자동 추첨이 아니라 운영 계약이 된다.
한국 기업에 주는 신호
한국 SaaS와 SI 팀은 여러 API 키를 붙여 비용을 낮추려는 유혹이 크다. 하지만 내부 업무 자동화에서는 실패 한 번의 재작업 비용이 토큰 절감액보다 클 수 있다. 고객 응대, 법무 검토, 코드 리뷰, 데이터 추출처럼 재현성이 중요한 영역에서는 라우팅보다 경로 분리가 낫다. 예를 들어 요약은 빠른 모델, 코드 수정은 고정 reasoning 모델, 실패 fallback은 별도 경로로 두는 식이다.
관측성도 필수다. Datadog의 AI Engineering 보고서처럼 AI 운영은 지연, 오류, 비용, provider 장애를 함께 본다. 라우터를 쓰려면 요청별 모델, 캐시 hit, 실패 재시도, 출력 품질, 사람 수정률을 남겨야 한다. 그렇지 않으면 비용이 줄었는지 작업이 망가졌는지 알 수 없다.
자주 묻는 질문
Q1: LLM 라우터가 무조건 나쁜가요?
A: 아니다. 장애 fallback, quota 분산, tenant별 provider 선택에는 유용하다. Manifest가 비판한 것은 비용 절감 목적의 매 요청 난이도 분류 라우팅이다.
Q2: 캐시가 왜 라우터보다 중요한가요?
A: 긴 시스템 프롬프트와 대화 기록은 반복된다. 모델을 바꾸면 이 반복분을 다시 처리해야 해 절감 효과가 줄 수 있다.
Q3: 한국 스타트업은 어떻게 시작해야 하나요?
A: 기능별로 모델을 고정하고, fallback은 예외 경로로 둔 뒤, 캐시 hit와 수정률을 먼저 계측하는 편이 낫다.
Q4: 오픈소스 라우터는 계속 쓸 가치가 있나요?
A: 있다. 단, 자동 모델 선택보다 gateway, 로깅, rate limit, fallback, 키 관리 기능부터 쓰는 것이 현실적이다.
Q5: 에이전트에서는 무엇이 가장 위험한가요?
A: 단계마다 모델이 바뀌어 실패 양상이 달라지는 것이다. 장기 작업일수록 일관성이 단가보다 더 중요한 품질 요소가 된다.
관련 토픽 더 보기
📰 원본 출처
manifest.build이 기사는 AI 기술을 활용하여 작성되었으며, 원본 뉴스 소스를 기반으로 분석 및 해설을 추가한 콘텐츠입니다. 정확한 정보 전달을 위해 노력하고 있으나, 원본 기사를 함께 확인하시기를 권장합니다.