litelm, LLM 라우팅의 작은 코어를 꺼내다

2900줄짜리 라우팅 코어

litelm GitHub 저장소는 자신을 LiteLLM의 라우팅과 포맷 변환을 약 2900줄, 기본 의존성 openai와 httpx 두 개로 추린 프로젝트라고 소개한다. 대상은 모델 라우팅, 메시지 변환, 스트리밍, 도구 호출, 임베딩, Responses API 같은 호출 경로다. 반대로 프록시 서버, 캐싱, 예산 관리, 토큰 카운팅, 에이전트, 스케줄러는 제외한다.

이 메시지는 분명하다. LLM 앱을 만드는 팀 모두가 거대한 게이트웨이를 원하는 것은 아니다. 어떤 팀은 OpenAI 호환 엔드포인트와 Anthropic, Mistral, Bedrock 등의 포맷 차이를 흡수하되, 실행 경로는 직접 이해하고 싶어 한다.

LiteLLM 생태계의 반작용

LiteLLM은 여러 모델 제공자를 하나의 API로 묶는 대표 프로젝트다. 프록시, 라우터, 비용 추적, 캐시, 운영 기능까지 커지면서 기업 도입에는 강해졌지만 작은 라이브러리로 쓰기에는 부담이 커졌다. litelm은 그 반대편 선택지다.

OpenRouter의 Astra 가격표, 에이전트 비용의 현실처럼 모델 비용과 라우팅은 에이전트 제품의 핵심이 됐다. 그러나 비용 관리 도구가 호출 경로 전체를 가리면 장애 분석은 어려워진다. vLLM의 AMD speculative decoding, 추론비 경쟁의 다음 축은 추론비 최적화가 점점 낮은 계층으로 내려간다고 봤다.

호환성 주장의 새로운 기준

litelm README는 19개 제공자 라우팅, DSPy 드롭인 검증, 자체 테스트 262개 통과, 일부 라이브 테스트와 업스트림 계약 테스트를 언급한다. 또 2026년 9월 11일 기준 LiteLLM의 routing/formatting 변경 360개 core-path commit을 검토했다고 적었다. 이런 attestation은 작은 프로젝트가 신뢰를 얻는 방식이다.

오픈소스 AI 인프라에서는 별 수가 없다. 모델 제공자 API는 계속 바뀌고, 같은 OpenAI 호환이라는 말도 세부 필드에서는 흔들린다. 트러스팅 트러스트, 컴파일러 밖으로 번졌다가 말한 공급망 신뢰 문제는 LLM 클라이언트에도 적용된다.

한국 팀이 볼 지점

한국 스타트업은 보통 처음에는 하나의 모델 API로 시작한다. 그러나 고객사가 늘면 Azure, OpenRouter, 로컬 vLLM, 국내 클라우드 GPU가 섞인다. 이때 모델 라우팅 계층을 너무 무겁게 잡으면 제품보다 인프라 운영이 커지고, 너무 가볍게 잡으면 장애와 비용 추적이 새기 시작한다.

litelm의 가치는 당장 표준이 되는 데 있지 않다. 작은 호출 경로를 읽을 수 있게 만들었다는 점이다. 코딩 에이전트가 고르는 도구가 시장을 정한다처럼 에이전트가 기본으로 쓰는 라우팅 라이브러리가 시장 분배를 바꿀 수도 있다.

자주 묻는 질문

Q1: litelm은 LiteLLM을 대체하나요?

A: 목적이 다릅니다. LiteLLM은 운영 기능이 풍부한 게이트웨이에 가깝고, litelm은 호출 경로 중심의 경량 라이브러리입니다.

Q2: 운영 환경에 바로 써도 되나요?

A: README상 alpha 상태입니다. 작은 내부 도구나 실험에는 매력적이지만, 기업 운영에는 자체 검증이 필요합니다.

Q3: 왜 의존성 수가 중요한가요?

A: 보안 감사, 배포 크기, 장애 원인 분석, 공급망 리스크가 줄어들 수 있기 때문입니다.

Q4: 한국 기업에는 어떤 의미인가요?

A: 모델 제공자 다중화를 하되, 라우팅 계층의 복잡도를 팀 규모에 맞게 선택해야 한다는 신호입니다.

Q5: 가장 큰 리스크는 무엇인가요?

A: 제공자 API 변화에 뒤처지는 것입니다. 경량 프로젝트일수록 호환성 테스트와 유지보수 지속성이 중요합니다.