LiteLLM 핵심 경로만 2,900줄로 추린 'litelm' 공개

litelm은 LiteLLM의 핵심 호출 경로만 뽑아낸 경량 라이브러리다. 여러 LLM 제공자 사이에서 요청을 라우팅하고 메시지 포맷을 변환하는 기능을 약 2,900줄, 의존성 2개(openai, httpx)로 구현했다. 프록시 서버나 캐싱, 비용 추적 같은 부가 기능은 덜어냈다.

LiteLLM은 원래 제공자별 API 차이를 감추고 하나의 인터페이스로 호출하게 해주는 도구다. 문제는 그 핵심이 10만 줄이 넘는 코드에 묻혀 있다는 점이다. 프록시 서버, 캐싱 레이어, 비용 추적, 그리고 대부분의 사용자가 건드리지 않는 수십 가지 기능이 함께 들어가 있다. litelm은 여기서 모델 라우팅, 메시지 변환, 스트리밍, 도구 호출, 임베딩만 남긴다. Router 클래스도, 프록시도, 캐싱도 없다.

설치는 필요한 만큼만 고르면 된다. 기본 설치에는 openai와 httpx만 딸려오고, Anthropic이나 Bedrock을 쓰려면 각각의 extra를 붙인다. 전체를 한 번에 받는 옵션도 있다.

사용법은 LiteLLM과 사실상 같다. "provider/model-name" 형식의 문자열로 모델을 지정하고 completion이나 embedding을 호출한다. 스트리밍은 stream=True로 켜고 청크를 순회하면 된다. 모든 함수에 async 짝이 있어서 acompletion, aembedding, aresponses, atext_completion을 쓸 수 있다. 함수 이름과 인자, 응답 타입이 LiteLLM과 같아서 기존 코드의 import만 바꾸면 된다는 것이 프로젝트의 설명이다.

라우팅 대상은 19개 제공자다. OpenAI 호환 엔드포인트라면 api_base만 지정해서 붙일 수 있어서, 로컬에서 돌리는 Ollama나 LM Studio 같은 서버도 같은 방식으로 호출한다. API 키는 제공자별 환경변수로 두거나 호출 시 인자로 넘긴다.

에러 처리도 정리돼 있다. 제공자마다 제각각인 오류를 litelm 자체 예외 계층으로 매핑한다. ContextWindowExceededError, RateLimitError, AuthenticationError 같은 이름으로 잡아서 처리할 수 있다. 함수 호출(tool use)도 지원하며, tools와 tool_choice를 넘기고 응답의 tool_calls에서 이름과 인자를 꺼내는 흐름이다.

배경을 보면, LLM 애플리케이션이 여러 제공자를 섞어 쓰는 게 일반화되면서 추상화 레이어의 무게가 부담이 되는 경우가 늘었다. 간단한 챗봇이나 사내 도구 하나 만드는 데 프록시와 대시보드까지 딸려오는 패키지는 과하다. litelm은 그런 상황에서 호출 경로만 필요로 하는 사용자를 겨냥한다.

개발자 입장에서 눈여겨볼 지점은 마이그레이션 비용이 낮다는 것이다. LiteLLM을 쓰던 코드라면 import 경로만 바꾸는 수준으로 전환을 시도해볼 수 있다. 다만 LiteLLM의 부가 기능에 의존하고 있다면 캐싱, 예산 관리, 비용 추적, 이미지 생성, 오디오, OCR, 파인튜닝 같은 항목이 litelm에는 없다는 걸 먼저 확인해야 한다. DSPy와의 드롭인 호환도 검증됐다고 밝히고 있다.

프로젝트는 스스로를 알파 단계라고 명시한다. 자체 테스트 262개가 통과했고, LiteLLM 9a715df2 기준으로 포팅한 테스트 75개가 통과하며 남은 조치 가능한 실패는 없다고 한다. 유지보수자는 649eb2d부터 9a715df2까지의 LiteLLM 라우팅·포맷팅 변경을 검토하면서 핵심 경로 커밋 360개를 분류하고, 업스트림 테스트를 확인해 호환성 격차를 테스트 우선 방식으로 메웠다고 밝혔다. 이 감사는 litelm이 선언한 라우팅·포맷팅·DSPy 표면에 한정된 것이지 LiteLLM 전체 호환성을 보증하는 것은 아니다.

또 하나 특이한 점은 개발 방식이다. 이 프로젝트는 사람이 방향을 잡고 AI가 코드 작성을 도운 소프트웨어라고 스스로 밝힌다. 상당 부분이 Claude Code와 Claude Opus 4.6/4.7로 작성됐고, 2026년 5월 14일 이후 코드는 Pi를 통해 GPT-5.5로 작성됐다는 설명이다. 호환성 주장은 AI 작성 여부가 아니라 테스트와 유지보수자 검토에 근거한다고 못 박는다.

라이브 테스트는 .env.test에 API 키를 넣어야 돌아가고 기본적으로는 건너뛴다. 실제 제공자 45개 테스트와 DSPy 스모크 테스트 10개가 통과했다는 기록이 있지만, 이는 특정 시점의 의존성 잠금 상태에서 나온 결과라는 점을 감안해야 한다.