여러 LLM 제공사를 하나의 인터페이스로 호출하게 해주는 LiteLLM, 파이썬으로 AI 서비스 만드는 분들은 한 번쯤 써보셨을 거예요. 그런데 이 라이브러리가 너무 커졌다는 불만이 꽤 오래전부터 있었거든요. 그 불만에 답하듯 「Litelm: 군살 없는 LiteLLM」이라는 프로젝트가 등장했어요. 이름부터 LiteLLM에서 L을 하나 뺀 거예요. 라이브러리 이름에서 글자를 빼서 「더 가볍다」는 걸 표현한 셈이죠.
LiteLLM이 뭐냐면
먼저 LiteLLM부터 설명할게요. OpenAI, Anthropic, 구글, AWS Bedrock, Azure, 그리고 오픈소스 모델 서빙 도구까지 LLM 제공사는 수십 곳인데, 각각 API 형식이 조금씩 달라요. 요청 본문 구조도 다르고, 스트리밍 방식도 다르고, 함수 호출(tool calling) 포맷도 달라요. LiteLLM은 이 차이를 가려주는 어댑터 계층이에요. 이게 뭐냐면, 여러분이 OpenAI 방식으로 코드를 한 번 짜두면 모델 이름만 바꿔서 Claude든 Gemini든 똑같이 호출할 수 있게 해주는 번역기 같은 거예요. 파이썬 라이브러리로도 쓸 수 있고, 별도 프록시 서버로 띄워서 팀 전체가 하나의 엔드포인트를 공유하게 할 수도 있어요.
그런데 뭐가 문제였나
LiteLLM은 성공했고, 성공한 만큼 커졌어요. 100개가 넘는 제공사를 지원하다 보니 코드베이스가 거대해졌고, 의존성도 함께 불어났어요. 사용자들 사이에서 나온 불만을 모아보면 이런 것들이에요. import litellm 한 줄이 몇 초씩 걸린다, 설치하면 딸려오는 패키지가 너무 많다, 프록시 서버에는 비용 추적, 라우팅, 캐싱, 관리자 UI, 데이터베이스 연동까지 다 들어 있어서 「그냥 API 호출만 통일하고 싶은」 사람에겐 과하다, 릴리스가 워낙 잦아서 버전을 올릴 때마다 뭔가 깨진다. 특히 서버리스 환경이나 컨테이너 이미지 크기에 민감한 팀에게 무거운 의존성은 실제 비용이에요. 콜드 스타트가 길어지고 빌드 시간이 늘어나거든요.
Litelm의 접근
Litelm은 여기서 「정말 필요한 건 뭔가」를 다시 묻는 프로젝트예요. 핵심은 통합 호출 인터페이스 하나예요. 주요 제공사에 대해 요청과 응답 형식을 맞춰주는 얇은 어댑터, 스트리밍 처리, 그 정도로 범위를 좁혔어요. 의존성은 HTTP 클라이언트 수준으로 최소화하고, 프록시 서버나 대시보드 같은 건 넣지 않는 방향이에요. 코드가 작으니까 읽어서 이해할 수 있고, 뭔가 안 맞으면 직접 고칠 수 있다는 것도 장점이죠. 「라이브러리가 하는 일을 내가 다 파악할 수 있다」는 건 운영 관점에서 생각보다 큰 안심이에요.
물론 트레이드오프가 있어요. 100개 제공사를 지원하지는 않고, LiteLLM 프록시의 팀 단위 키 관리나 예산 제한 같은 기능도 없어요. 그런 기능이 필요하면 LiteLLM이 맞아요. Litelm은 「제공사 서너 곳을 코드에서 바꿔가며 쓰고 싶은데 라이브러리 하나가 앱 전체보다 무거운 게 싫은」 사람을 위한 거예요.
업계 맥락: OpenAI 호환이 표준이 된 세계
이 논의의 배경에는 흥미로운 변화가 있어요. OpenAI의 채팅 API 형식이 사실상 업계 표준이 됐다는 거예요. 요즘은 대부분의 제공사가 OpenAI 호환 엔드포인트를 직접 제공해요. vLLM이나 Ollama 같은 로컬 서빙 도구도 그렇고, 구글 Gemini도 OpenAI 호환 모드가 있죠. 그러니까 「어댑터 계층」이 해야 할 일 자체가 예전보다 줄어든 거예요. 이런 환경에서는 얇은 라이브러리가 오히려 합리적이에요.
비슷한 문제의식을 가진 프로젝트도 여럿이에요. 앤드류 응이 참여한 aisuite, 모질라의 any-llm은 모두 「최소한의 통합 인터페이스」를 표방해요. 자바스크립트 쪽에서는 Vercel AI SDK가 비슷한 역할을 하는데 이쪽은 오히려 기능이 풍부한 편이고요. OpenRouter 같은 서비스는 아예 라이브러리 대신 「호스팅된 프록시」로 같은 문제를 풀어요. 결국 선택지는 「기능 많은 무거운 라이브러리, 얇은 라이브러리, 외부 프록시 서비스, 직접 구현」 네 갈래로 정리돼요.
한국 개발자에게 주는 시사점
한국 개발자에게 이 흐름이 특히 의미 있는 이유가 있어요. 네이버 HyperCLOVA X, 업스테이지 Solar 같은 국내 LLM들도 OpenAI 호환 엔드포인트를 제공하는 추세거든요. 해외 대형 라이브러리는 이런 국내 모델을 공식 지원하지 않는 경우가 많은데, 얇은 어댑터 방식이면 base URL과 모델 이름만 바꿔서 붙일 수 있어요. 오히려 거대한 라이브러리보다 작은 라이브러리가 국내 환경에 더 잘 맞을 수 있다는 거죠.
그리고 한 가지 더. 「의존성 다이어트」는 AI 라이브러리에만 해당하는 얘기가 아니에요. 편하다고 큰 라이브러리를 계속 끌어오다 보면 어느 순간 빌드는 느려지고 보안 경고는 쌓이고 업그레이드는 무서워져요. 내 프로젝트의 requirements를 한번 훑어보면서 「이 중에 실제로 쓰는 기능이 몇 퍼센트지?」를 물어보는 것만으로도 얻는 게 있을 거예요.
마무리
한 줄 정리하면, LLM 호출 통합 라이브러리도 이제 「다 되는 것」보다 「필요한 것만 되는 것」이 선택지로 자리 잡았어요. 여러분 팀은 LLM 제공사 전환을 어떻게 처리하고 계세요? 큰 라이브러리 하나, 얇은 라이브러리, 아니면 직접 httpx로 호출하시나요?
🔗 출처: Hacker News