요즘 팀에서는 Token 비용에 대한 관심이 많다. '토큰 이코노미'에 대해서 대부분 비슷할꺼라 생각된다.
단일 모델(예산 범위내에서 가장 좋은 모델)로 제품을 만들고, 다른 사용 사례에도 확장하는 형태로 대부분 사용한다. 이유는 간단하다. 일관된 품질을 유지하고 예측 가능한 동작을 보장한다는 것이다.
이러다 비용은 급격히 증가하게 된다. 슈퍼 컴퓨터 가격을 지불하면서 계산기로 해결할 수 있는 문제를 해결하게 되고, 결국 경제성이 떨어지게 된다.
이것이 본 글에서 언급하고자 하는 '라우팅 문제'이다.
라우팅이란 무엇인가?
라우팅은 들어오는 요청의 특성에 따라 적절한 모델로 전달하는 의사 결정 로직이다. 매커니즘 자체가 복잡하지는 않지만, 작업을 충분히 이해하여 의미 있게 분류하는 데에 핵심이 있다.
병원 응급실에 들어가면 누군가가 환자를 분류한다. 발목이 삐었다면 정형외과, 서류 관련 문의는 행정 직원이 처리, 즉 환자에게 가장 적합한 수준의 치료를 안내한다.
LLM 라우팅은 요청에 대해서 동일한 방식으로 작동한다. 간단한 질문은 빠르고 저렴한 모델로 전달되고, 복잡한 창작 작업은 강력하고 비싼 모델로 전달된다. 그 외의 요청은 지연 시간 요건이나, 비용 제약, 규정 준수, 기타 요소를 기준으로 라우팅된다.
문제는 이것을 복잡하게 생각하기 때문에 발생한다. 일반적으로 '라우팅'이라고 하면 실시간으로 요청을 분석하고 강화 학습을 사용하여 최적의 결정을 내리는 '어마 무시 한' 정교한 AI를 떠올린다. 물론 매우 중요한 곳에서는 이런 시스템을 사용할 수 도 있지만, 대부분 라우팅은 조건 논리에 기반한다. 즉, '이러면 저렇게 한다.' 식이다. 핵심은 적절한 조건 선택에 있다.
라우팅이 필요한 경우
모든 상황에 라우팅이 필요한 것은 아니다.하루에 1,500건을 처리하고 LLM 비용이 월 300달러라면 라우팅은 시간 낭비일 수 있다. 이럴 땐 좋은 모델을 쓰면 된다.
반대로 아래의 문제가 하나 이상 있으면 라우팅을 고려해야 한다.
- 비용이 수익보다 증가할 경우: 기본적인 신호이다. 내부에서 사용하는 것 외에 고객에게 제공해주는 상황이라면 문제는 더 심각하다. 사용자당 LLM 비용이 줄지 않아 마진이 감소하기 때문이다. 신규 고객을 확보할 때마다 수익성 악화가 되는 악순환에 빠진 것이다.
- 사용 사례는 다양하지만, 모델은 하나일 경우: 여러 용도로 사용하고 있지만, 동일한 모델을 사용하는 케이스이다. 사용 사례별로 요구 사항이 다르지만, 모두 동일하게 처리하고 있는 경우다.
- LLM 비용으로 인한 새로운 기능 도입 배제: 가치를 제공할 수 있는 아이디어가 있지만, 현재 모델로는 경제성이 맞지 않아 도입하지 못하는 경우다. 이 경우 사용자 문제에 집중하기 보다는 기존 상황에 맞춘 경우다.
- 장애로 전체 제품이 동작하지 않는 사태: LLM 계층에 이중화 시스템을 만들지 않는다면, API 오류 하나만으로 장애가 발생할 가능성이 높다.
위와 같은 문제가 없다면 라우팅은 필요없다.
LLM 라우팅 결정을 좌우하는 요소
기준이 필요하다. 무엇을 최적화해야 하는지 모르면 설정을 할 수 없다. 대부분의 경우 아래의 요소 조합으로 라우팅을 한다.
1. 비용 및 물량
요건들은 가치도 다르고 비용도 다르다. 경제적 원리를 적용해 라우팅을 통해 이런 요청을 적절하게 매칭해야 한다.
고객을 위한 챗봇을 제공한다고 했을 때 "제가 주문한 내역을 알고 싶어요." 라는 질문을 처리하는 챗봇은 질문당 최소한의 비즈니스 가치만 창출할 가능성이 높다.
사용자는 불안해서 질문하는 것이고, 빠르게 답변을 하지 않으면 상담원 연결로 이어지기에 이 부분을 방지해야 한다. 진정한 가치는 여기서 사용되는 비용이 아니라 불필요한 문의를 줄이는 것에 있다.
AI가 답변하는 질문 하나당 어느정도의 고객 티겟 비용이 절약될 것이라 생각해야 한다. 그래서 산출해야 한다. 요청당 비용이 0.02 달러일지, 0.001 달러일지 정하면 ROI는 엄청나게 증가하게 된다.
위에서 예시를 든 경제 원리를 이해하면 라우팅 로직은 이미 만들어진 것이다. 대량의 저가치 요청은 저렴한 모델로, 소량의 고가치 요청은 비싼 모델로 배정해야 한다. 이것이 상황에 맞는 라우팅 최적화이다.
2. 지연 시간 및 사용자 경험
어떤 요청은 사용자가 기다리는 동안에 처리해야 하고, 어떤 요청은 백그라운드에서 처리된다. 이런 차이가 라우팅 전략을 결정하는데 매우 중요한 요소이다.
대부분의 사용자는 '기다림의 여유'가 없다. 그래서 1초 이상이 걸리면 무언가 고장났다고 생각할 가능성이 높다. 그래서 사용자가 기다리는 요청은 속도 최적화에 많은 노력을 기울여야 한다. 비용이 더 들거나 품질이 살짝 떨어지더라도 빠르게 응답하는 모델을 선택해야 한다. 아주 좋지는 않지만 '충분히 좋고, 빠른' 모델을 사용하는 것을 고려해야 한다.
반대로 백그라운드에서 처리되는 문서 처리, 보고서 등의 작업은 느려도 된다. 사용자가 작업을 요청하고 다른 업무를 볼 것이고, 이 요청에 대한 답변이 오래 걸릴 것이라고 사용자는 인지하고 있기 때문이다. 이런 경우에는 속도보다는 품질과 비용을 최적화해야한다.
3. 작업 복잡도
강력한 모델이 필요한 작업도 있지만, 그렇지 않은 작업도 존재한다. 그러나 이 기준을 세우는 것은 생각보다 어렵다.
요즘 Goose를 사용중인데, Default Model을 Openrouter에서 제공하는 gpt-oss-120b:free 를 사용중이다.
예를 들어 창의력이 발휘되어야 하는 작업을 하려면 이해력이 뛰어난 모델이 필요하다. 반대로 텍스트에서 이메일 주소를 추출하는 작업에는 높은 지능이 필요 없다.
중요한 것은 '완벽 주의'를 피해야 한다. 모든 요청의 복잡성을 정확하게 알 수는 없다. 라우팅을 통해 절감되는 비용이 ROI가 나올 정도의 예측이면 된다. 예를 들어 라우팅의 정확도가 80%이고 많은 요청을 처리한다고 하면, 라우팅된 80%에서 비용이 절감되는 것이다.
4. 개인 정보 보호, 규정 준수
앞에서 언급한 비용보다 우선시되는 법적 또는 규정 제약 조건이 있다. 의료, 금융 등은 데이터 센터의 위치도 중요하고, LLM이 어디에서 Serving이 되는지도 중요하다.
이런 제약 조건으로 인해 라우팅이 필요하다. 민감한 데이터는 제공자가 제한되고, 환경도 제한된다. 데이터를 보호하기 위해서는 On-premise 환경이 필요할 수 있다.
그래서 이 기준으로 라우팅 규칙을 적용해야 한다.
라우팅 로직이 위치해야 할 곳
클라이언트쪽에 위치하게 하면 end-point를 직접 선택할 수 있기에, 지연 시간을 최소화할 수 있다.
하지만, 클라이언트는 신뢰할 수 없다. 거기에 규정 준수 규칙, 가격 등급, 예산 등의 코드를 넣을 수는 없다. 그래서 모든 라우팅 결정은 개인적으로 사용하는 용도가 아닌 이상, 서버 측에서 이루어져야 한다.
물론 단점은 지연이다. 모든 요청이 서버측을 거치게 되기에 지연 시간이 추가될 수 있다. 그래도 최적화를 한다면 이는 허용할 수 있는 밀리초 단위일 것이다.
어떤 툴을 사용해야 할까?
상황에 따라 다르겠지만, LLM 라우팅이 발전함에 따라 많은 도구들이 존재하고 몇 가지만 언급해본다.
OpenRouter는 수십 개의 라우터 제공업체를 하나의 API로 통합한다. 한 번의 연동으로 다양한 라우터에 접근 할 수 있다.물론 수수료를 받는다. 단점은 자체 라우팅 로직을 구현하지 못하며 대신 OpenRouter의 로직을 신뢰해야 하기에 제어력이 떨어진다. 개인적으로 사용할 때는 추천한다. (매우 편하다.)
LiteLLM Proxy는 오픈 소스 기반의 Self-Hosting 옵션이다. YAML 형식으로 라우팅 규칙을 구성하고 자체 인프라에서 프록시를 실행할 수 있다. 수수료도 없고, 라우팅 규칙도 제어할 수 있다. 다만, 운영 부담이 크다는 단점이 있다. 배포, 모니터링, 확장 및 디버깅을 직접 수행해야 한다.
맺음말
물론 라우팅이 만능 해결책은 아니다. 실제적인 제약 조건을 해결 할 수 있을때만 도입해야 한다. 라우팅을 도입할 상황이 아니라면 하나의 훌륭한 모델만 사용해도 충분하기 때문이다.
Sources:
0 Comments:
댓글 쓰기