캐럿 라우터, 왜 LiteLLM에서 any-llm으로 옮겼나

캐럿 라우터

캐럿(Caret)에서 LLM 라우터를 설계하면서 가장 중요하게 봤던 건 **“우리가 통제할 수 있는 단순함”**이었다. 모델은 계속 늘어나고, 벤더는 바뀌고, 요구사항은 커지는데 라우터까지 무거워지면 결국 운영 복잡도가 제품 속도를 잡아먹는다는 걸 이미 여러 번 경험했기 때문이다.

우리는 한동안 LiteLLM을 사용했다. 기능적으로는 매우 훌륭했고, 잘 만들어진 프로젝트다. 하지만 캐럿이 지향하는 방향과 실제 운영 환경에서는 점점 맞지 않는 부분이 분명해졌다. 그래서 라우터를 LiteLLM → any-llm으로 전환했다.

이 글은 “비교 리뷰”가 아니라, 우리가 왜 바꿨고, 바꾼 뒤 무엇이 가능해졌는지에 대한 기록이다.

1. LiteLLM은 너무 복잡했고, 캐럿에는 필요 없는 기능이 많았다

캐럿 라우터, LiteLLM vs any-llm

LiteLLM은 단순한 SDK라기보다는 AI Gateway / Proxy Server에 가깝다. 멀티테넌시, 가상 키, 조직 관리, 예산 제어, 로깅, 알림, 데이터베이스 연동까지… “엔터프라이즈 환경”에서는 분명 강력한 장점이 된다.

문제는 캐럿의 라우터에는 그 정도의 기능 세트가 필요하지 않았다는 점이다.

라우터 하나 바꾸는데 DB, 워커 설정, 운영 파라미터가 따라온다
우리가 쓰지 않는 기능까지 포함된 구조를 유지해야 한다
결국 “LLM 라우팅”보다 “라우터 운영”이 더 중요한 일이 된다

결과적으로 LiteLLM은 기능이 부족해서가 아니라, 너무 많은 기능 때문에 캐럿에는 무거운 선택이 됐다.

2. any-llm은 간결했고, 확장하기 쉬웠다

캐럿 라우터, any-llm

any-llm을 선택한 가장 큰 이유는 명확하다.

“라우터는 얇아야 한다.”

any-llm은 기본적으로 API 인터페이스에 집중한 라이브러리다.

프록시 서버를 강제하지 않는다
모델 호출 추상화에만 집중한다
구조가 단순해서 코드 레벨에서 이해하기 쉽다

이건 단순히 “가볍다”는 차원이 아니라, 우리 서비스 구조 안으로 자연스럽게 녹여 넣을 수 있다는 의미였다.

라우터를 하나의 독립 서비스가 아니라, 캐럿 플랫폼의 내부 컴포넌트로 다루고 싶었던 우리에게는 이 점이 결정적이었다.

3. any-llm에는 없는 기능을, 캐럿에 맞게 직접 확장할 수 있었다

캐럿 라우터, 확장

LiteLLM을 쓰면서 가장 어려웠던 부분 중 하나는 “이미 정해진 구조 안에서 캐럿에 맞추는 것”이었다.

any-llm으로 옮긴 뒤에는 접근 방식이 완전히 바뀌었다.

라우터는 라우팅만 하고, 나머지는 우리가 만든다.

캐럿 라우터, 시퀀스

그 결과, any-llm에는 없지만 캐럿에는 꼭 필요한 기능들을 우리 방식으로 직접 붙일 수 있었다.

프로필 관리
청구 / 결제 관리
API Key 관리
크레딧 관리
소셜 로그인 및 인증

이 기능들은 라우터 레벨에서 강제되는 것이 아니라, 캐럿의 비즈니스 로직과 자연스럽게 결합되어야 했다.

any-llm의 단순한 API 구조 덕분에, 이런 확장이 훨씬 수월해졌다.

4. any-llm은 API만 제공하기 때문에, UI를 완전히 자유롭게 만들 수 있었다

캐럿 라우터, UI

LiteLLM은 기본적으로 “관리 UI를 포함한 플랫폼”에 가깝다. 하지만 캐럿은 이미 자체적인 사용자 경험과 디자인 철학이 있다.

any-llm은 UI를 전혀 강요하지 않는다.

API만 제공
UI/UX는 전적으로 서비스가 결정

덕분에 우리는:

캐럿 사용자 흐름에 맞는 UI
크레딧·결제·키 관리가 자연스럽게 연결된 화면
LLM 기능이 “도구”처럼 느껴지는 경험

을 제약 없이 설계할 수 있었다.

라우터가 UX를 규정하는 게 아니라, 제품이 라우터를 감싸는 구조가 된 셈이다.

5. 추후 Golang 기반으로 성능을 개선하는 데도 any-llm이 유리하다

캐럿 라우터, 성능

캐럿은 장기적으로 성능과 비용 효율을 중요하게 본다. 특히 라우터 레이어는 트래픽이 몰리기 쉬운 영역이다.

any-llm은 구조가 단순하기 때문에:

특정 언어/런타임에 종속되지 않고
추후 Golang 기반으로 재구성하거나 일부 컴포넌트를 대체하는 것도 현실적인 선택지다

이미 무거운 프록시 서버를 전제로 한 구조였다면 쉽지 않았을 결정이다. 하지만 any-llm 기반 구조에서는 성능 개선 전략을 유연하게 가져갈 수 있다.

6. 곧 정리되는 대로, 오픈소스로 공개할 예정이다

캐럿 라우터, 오픈소스

LiteLLM에서 any-llm으로 전환하면서, 그리고 캐럿에 맞는 기능들을 직접 붙이면서 느낀 점이 하나 있다.

이 구조는 우리만 쓰기엔 아깝다.

그래서 현재 코드를 정리 중이고, 정리되는 대로 오픈소스로 공개할 예정이다.

any-llm 기반 라우팅 구조
캐럿에서 실제로 쓰는 확장 패턴
운영하면서 얻은 경험들

같이 고민하고, 같이 만들고 싶은 개발자들의 참여를 기다리고 있다. “완성된 프레임워크”보다는, 함께 키워가는 기반이 되길 바란다.

마무리하며

이번 전환은 “LiteLLM이 나쁘다”는 이야기가 아니다. LiteLLM은 여전히 훌륭한 도구이고, 많은 팀에게 잘 맞는 선택이다.

다만 캐럿에게는:

더 얇은 라우터
더 자유로운 확장
더 명확한 책임 분리

가 필요했고, 그 선택지가 any-llm이었다.

이 선택이 어떤 결과를 만들어낼지는, 앞으로의 운영과 오픈소스 과정에서 더 분명해질 것이다.

곧 코드로 이야기하겠다.