2,900줄로 줄인 LiteLLM, 따져야 할 건 줄 수가 아니다
19개 제공자 지원 중 검증은 7개. 얇은 재구현의 진짜 비용은 의존성 개수가 아니라 유지보수 주체 수다. 채택 기준은 '내가 포크해서 유지할 수 있는 크기인가'.
LiteLLM의 핵심만 남겨 2,900줄로 줄인 Litelm이 나왔다. 여기서 볼 숫자는 2,900이 아니다. 지원 제공자 19개 중 검증된 건 7개라는 쪽이다.
저장소 README가 만든 이유를 직접 적어놨다.
"litellm routes LLM calls across providers and translates between message formats. That core is buried under 100k+ LOC of proxy servers, caching layers, cost tracking, and dozens of features most users never touch."
확인된 것
- 약 2,900줄, 핵심 의존성 2개(
openai,httpx). - 제외한 것을 표로 명시했다: Router, Proxy server, Caching/budgeting/cost tracking, Token counting, Image gen/audio/OCR/fine-tuning, Agents/guardrails/scheduler.
- 제공자 19개 지원, 검증 표시(Yes)는 7개 — OpenAI, Anthropic, Groq, Mistral, xAI, OpenRouter, Azure. 나머지는 "No".
- 안정성 표기는 한 줄이다. "Alpha. 262 own tests passing." (비라이브 테스트 기준 262 passed, 55 skipped)
- 라이선스 MIT.
- 저자가 개발 방식을 먼저 밝혔다. "litelm is human-directed, AI-assisted software. Much of the code was written with Claude Code using Claude Opus 4.6/4.7."
내 판단
1. 기능 비교표가 아니라 내가 실제로 import하는 것을 세야 한다.
LiteLLM에서 프록시나 캐싱이나 비용 추적을 쓰고 있다면 Litelm은 대안이 아니다. 애초에 그걸 뺀 물건이다.
그런데 대부분은 그렇지 않다. 라우팅과 메시지 포맷 변환만 쓰면서 나머지를 딸려온 채로 두고 있다. 확인은 1분이면 된다 — 저장소에서 litellm을 grep해서 실제로 부르는 심볼을 세본다. 한 줌이면 무거운 쪽을 계속 쓸 이유가 사라진다.
덧붙이면, 그 한 줌이 정말 작을 때는 선택지가 Litelm 하나가 아니다. 직접 짜는 것도 후보다. 제공자 두세 개에 대한 포맷 변환은 생각보다 짧고, 그 코드는 내 것이다.
2. 19 대 7이 이 프로젝트에서 가장 중요한 숫자다.
"19개 제공자 지원"은 코드 경로가 있다는 뜻이고, "검증 7개"는 누군가 돌려봤다는 뜻이다. 둘은 다르다. 내가 쓰는 제공자가 뒤쪽 12개에 있으면, 나는 지원받는 사용자가 아니라 첫 번째 테스터다.
이건 이 프로젝트를 깎는 말이 아니다. 저장소가 그 구분을 표에 그대로 드러냈다는 게 오히려 신뢰할 근거다. 숨기지 않은 미검증은 정보고, 숨긴 미검증이 사고를 낸다.
3. 얇은 재구현의 진짜 비용은 줄 수가 아니라 유지보수 주체 수다.
10만 줄짜리 라이브러리의 핵심 3%를 개인이 다시 짜는 일이 실제로 가능해졌다. 저자가 AI 보조로 만들었다고 밝힌 것도 그 신호다.
따져야 할 건 그다음이다. 제공자들이 API 포맷을 바꾸면 원본 LiteLLM은 여러 사람이 따라가지만, 이 2,900줄은 한 명이 따라가야 한다. Alpha이고 전체 호환성을 보장하지 않는다는 문장도 같은 자리에서 나온다.
그래서 이런 걸 채택할 때 내가 쓰는 기준은 이것이다. "내가 포크해서 유지할 수 있는 크기인가." 2,900줄은 읽을 수 있는 크기다. 저자가 손을 떼도 내가 이어받을 수 있다면 의존해도 되고, 아니면 의존성 2개짜리라도 위험은 똑같다. 의존성 개수보다 이쪽이 먼저다.
어제 쓴 WebKit 모듈 로더 글과 겹쳐 보면 대비가 선명하다. 거기서는 기존 구현을 보지 않고 명세에서 다시 만들었기 때문에 기존 버그를 물려받지 않았다. 여기서는 기존 구현의 동작을 좁게 따라갔기 때문에 "전체 호환은 보장하지 않는다"가 남는다. 재작성에는 두 가지 길이 있고, 각각 무엇을 포기하는지가 다르다.
모르는 것
- 직접 써보지 않았다. 위 내용은 저장소 문서 기준이다.
- 설치 크기나 임포트 시간 수치는 저장소에 없다. 가벼움의 실제 체감치를 확인하지 못했다.
- 건너뛴 테스트 55개가 무엇인지, 미검증 제공자 12개가 어느 단계인지 모른다.
- 한국어로 도는 요약 중에 라이선스가 명시되지 않았다는 서술이 있었는데, 저장소에는 MIT로 표기돼 있다. 위 내용은 저장소 기준으로 썼다.
댓글
불러오는 중...