여러 LLM 공급자를 하나의 인터페이스로 묶어 호출하려는 개발자에게 litellm은 사실상의 표준 라이브러리로 자리 잡았다. 그러나 그 편의성 뒤에는 무게가 있다. litellm의 진짜 핵심 기능인 공급자 라우팅과 메시지 포맷 변환은, 프록시 서버·캐싱 계층·비용 추적을 비롯해 대부분의 사용자가 손대지 않는 수십 가지 기능으로 이루어진 10만 줄 이상의 코드 아래 묻혀 있다. litelm은 바로 이 지점에 대한 반작용으로 등장한 프로젝트다. 이름 한 글자를 뺀 데서 짐작되듯, litellm에서 호출 경로만 도려내 약 2,900줄과 두 개의 의존성(openai, httpx)으로 다시 구현한 경량 대안을 표방한다.
무엇을 덜어냈나
litelm이 남긴 것은 명확하다. 모델 라우팅, 메시지 변환, 스트리밍, 툴 사용(tool use), 임베딩까지 실제 LLM 호출이 지나가는 경로가 전부다. 반대로 Router 클래스도, 프록시 서버도, 캐싱 계층도 들어 있지 않다. 이는 단순히 코드가 가볍다는 이야기를 넘어, 라이브러리가 책임지는 범위를 호출 변환으로 좁혔다는 설계 선언에 가깝다. 부가 기능이 필요 없는 팀에게는 의존성 트리가 얕아지고 동작을 추적하기 쉬워진다는 실질적 이점이 있지만, 반대로 게이트웨이 수준의 라우팅 정책이나 비용 관리를 라이브러리에 기대던 사용자라면 그 부분을 스스로 마련해야 한다는 뜻이기도 하다.
호출 방식은 litellm의 관례를 그대로 따른다. 공급자는 "provider/model-name" 형식으로 지정하며 총 19개 공급자를 지원하고, OpenAI 호환 엔드포인트라면 api_base 인자만으로 연결된다. 공급자별 인증은 환경 변수로 처리하고, 각 공급자가 던지는 오류는 litelm 자체의 예외 계층으로 매핑된다. 동기 함수마다 async 변형(acompletion, aembedding, aresponses, atext_completion)이 짝으로 제공되어 비동기 코드베이스에도 그대로 얹을 수 있다.
이관 비용이 거의 없다는 설계
litelm의 가장 눈에 띄는 결정은 API를 litellm과 동일하게 맞춰 둔 점이다. 함수 이름, 인자, 응답 타입이 같기 때문에 이미 litellm을 쓰고 있다면 임포트 구문에서 litellm을 litelm으로 바꾸는 것만으로 교체가 끝난다고 프로젝트는 설명한다. 이 드롭인 전략은 채택 장벽을 크게 낮추는 동시에, 검증 방식도 규정한다. 즉 litelm은 독자적인 API를 새로 설계하기보다 litellm의 특정 동작을 얼마나 충실히 재현하느냐로 스스로를 증명해야 하는 위치에 선다.
실제로 유지보수자는 이 호환성을 별도의 감사 기록으로 뒷받침한다. 2026년 9월 11일자 검증에 따르면 litellm의 라우팅·포매팅 변경 사항을 커밋 649eb2d부터 9a715df2까지 검토했고, 핵심 경로에 해당하는 360개 커밋을 분류한 뒤 관련될 수 있는 상류(upstream) 테스트를 살펴보고 드러난 호환성 간극을 테스트 우선 방식으로 메웠다고 한다. 현재 의존성 잠금 상태에서 로컬 스코프 테스트는 262개 통과·55개 건너뜀을 기록했고, 사용 가능한 공급자 대상 라이브 테스트 45개와 DSPy 스모크 테스트 10개도 모두 통과했다.
DSPy 연동과 남은 한계
프레임워크 연동 측면에서는 DSPy 드롭인이 검증됐다는 점이 강조된다. Predict, Chain-of-Thought, 타입 시그니처, 스트리밍, 임베딩, 툴 사용, 다중 출력까지 7개 실행 경로가 모두 실제 호출로 확인됐다. DSPy 파이프라인의 백엔드로 litellm을 쓰던 팀이라면 이 부분이 교체 여부를 가르는 실질적 기준이 될 수 있다. 다만 라이브 테스트는 API 키를 .env.test에 두어야 하고 기본적으로 건너뛰도록 되어 있어, -m live로 명시해야 실행된다.
한계도 분명히 선을 그어 둔다. 유지보수자는 이번 검증이 litelm이 선언한 라우팅·포매팅·DSPy 표면에 한정된 것이며 litellm 전체와의 완전한 호환을 보증하지 않는다고 못 박는다. 프로젝트 성숙도 역시 알파 단계로, 자체 테스트 262개가 통과하고 스코프를 좁힌 LiteLLM 9a715df2 기준선에서 이식된 테스트 75개가 통과하며 현재 조치가 필요한 단정·런타임 실패는 남아 있지 않은 상태다. 코드 상당 부분이 AI 보조로 작성됐다는 점도 공개돼 있는데, 초기에는 Claude Code와 Claude Opus 4.6/4.7이, 2026년 5월 14일 이후 코드는 Pi를 통한 GPT-5.5가 관여했다. 다만 호환성 주장은 AI가 썼다는 사실이 아니라 테스트와 유지보수자 검토에 근거한다고 밝힌다.
종합하면 litelm은 모두를 위한 litellm 대체가 아니라, 라우팅과 변환이라는 핵심만 있으면 충분하고 프록시·캐싱 같은 무거운 레이어를 스스로 걷어내고 싶은 팀을 겨냥한 선택지다. 얇은 의존성과 손쉬운 교체라는 장점이 분명한 만큼, 알파 단계라는 성숙도와 명시적으로 한정된 호환 범위를 함께 저울에 올려 판단할 필요가 있다.