LiteLLM의 역사: Python SDK에서 AI Gateway까지
LiteLLM을 단순한 멀티 모델 호출 라이브러리로만 이해하면 현재 모습의 절반만 보게 됩니다. 출발점은 Python 애플리케이션 안에서 여러 AI 모델 제공자를 같은 방식으로 호출하는 일이었지만, 지금은 조직의 모델 접근을 한곳에서 통제하는 AI Gateway까지 범위가 넓어졌습니다. 이 변화는 이름만 커진 것이 아니라, LLM 추상화를 어디에 둘 것인가에 대한 답이 달라진 과정입니다.
2023년 7월, 작은 Python 패키지로 시작
LiteLLM의 GitHub 저장소와 PyPI 0.1.0은 모두 2023년 7월 27일에 공개됐습니다. 최초 저장소에는 README와 라이선스만 있었고, 첫 PyPI 패키지도 별도 설명이 없을 정도로 작았습니다.
하지만 같은 해 8월의 README에는 방향이 이미 선명했습니다. OpenAI, Azure, Cohere, Anthropic, Hugging Face의 API 호출을 단순화하고 다음 세 가지를 공통 처리하는 패키지로 소개됐습니다.
- 공급자별 completion 및 embedding 요청으로 입력을 변환합니다.
- 응답을 일관된 구조로 돌려줍니다.
- 공급자별 오류를 공통 예외 형식으로 매핑합니다.
스트리밍도 초기부터 중요한 기능이었습니다. 애플리케이션은 공급자마다 다른 스트림 조각을 직접 해석하지 않고, 같은 반복문으로 응답을 소비할 수 있었습니다. LiteLLM의 첫 번째 가치는 모델의 지능을 추상화한 것이 아니라 API의 차이를 흡수한 데 있었습니다.
OpenAI 형식을 공통 계약으로 선택한 이유
멀티 모델 계층에는 자체 형식을 새로 만들 수도 있고, 특정 공급자의 형식을 기준으로 삼을 수도 있습니다. LiteLLM은 OpenAI 입력과 출력 형식을 공통 계약으로 선택했습니다. 애플리케이션은 익숙한 messages, model, stream 같은 필드를 사용하고, LiteLLM이 이를 각 공급자의 요청으로 바꿉니다. 응답과 예외도 다시 공통 형식으로 정규화합니다.
이 선택은 새 공급자를 추가할 때 애플리케이션 전체를 수정하지 않아도 된다는 장점이 있습니다. 반면 모든 모델의 의미가 완전히 같아지는 것은 아닙니다. 도구 호출, 추론 옵션, 안전 정책, 토큰 집계 방식처럼 공급자마다 다른 기능은 공통 필드만으로 표현하기 어렵습니다. 따라서 LiteLLM의 호환성은 차이를 없애는 마법이라기보다, 공통 영역을 넓히고 나머지 차이를 어댑터 안으로 모으는 설계에 가깝습니다.
2023년 하반기, 호출 래퍼에서 운영 계층으로
공개 저장소 이력을 보면 현재 proxy_server.py 경로는 2023년 9월부터 확인되며, 여러 배포 대상으로 요청을 분산하는 Router는 10월 18일에 추가됐습니다. 불과 몇 달 만에 문제의 범위가 한 번의 API 호출에서 서비스 운영으로 확장된 셈입니다.
2023년 12월의 README에는 이 변화가 더 분명하게 나타납니다. 당시 문서는 다음 기능을 한 화면에서 소개했습니다.
- 여러 배포 대상 사이의 부하 분산
- OpenAI 클라이언트가 접속할 수 있는 Proxy Server
- 비동기 호출과 스트리밍
- 관측 도구로 데이터를 보내는 콜백
- 프로젝트와 사용자별 사용 금액 추적
- 모델 접근 범위와 만료 시간을 가진 가상 키
- 키별 예산 설정
이 시점부터 LiteLLM은 두 가지 배치 방식을 갖게 됐습니다. Python SDK는 각 애플리케이션 프로세스 안에서 호출을 통일했고, Proxy Server는 여러 애플리케이션 앞에 놓이는 중앙 서비스가 됐습니다.
왜 SDK만으로는 충분하지 않았을까
SDK는 개발자의 코드 중복을 줄이는 데 효과적입니다. 그러나 팀과 서비스가 늘어나면 애플리케이션마다 동일한 운영 문제가 반복됩니다.
- 공급자 API 키를 어느 서비스에 배포할지 결정해야 합니다.
- 어떤 팀이 어떤 모델을 사용할 수 있는지 통제해야 합니다.
- 요청 수와 토큰 수, 비용을 공통 기준으로 집계해야 합니다.
- 장애가 난 배포 대상을 제외하고 대체 모델로 전환해야 합니다.
- 프롬프트 로깅, 개인정보 제거, 가드레일 정책을 일관되게 적용해야 합니다.
이 책임을 각 애플리케이션의 SDK 설정에 남겨 두면 정책이 서비스 수만큼 복제됩니다. 중앙 Proxy를 두면 애플리케이션은 하나의 내부 API만 호출하고, 인증과 라우팅, 예산, 관측 정책은 게이트웨이에서 집행할 수 있습니다. LiteLLM이 AI Gateway로 확장된 이유는 지원 모델 수가 늘어서만이 아니라, 추상화의 사용자가 개인 개발자에서 플랫폼 팀으로 바뀌었기 때문입니다.
현재의 두 실행 방식
현재 공식 문서는 LiteLLM을 Python SDK와 AI Gateway 두 방식으로 구분합니다.
| 구분 | Python SDK | AI Gateway 또는 Proxy Server |
|---|---|---|
| 실행 위치 | 애플리케이션 프로세스 내부 | 애플리케이션과 모델 제공자 사이의 독립 서비스 |
| 주 사용자 | 한 제품을 개발하는 애플리케이션 개발자 | 여러 제품을 지원하는 플랫폼 및 인프라 팀 |
| 인증 정보 | 애플리케이션이 공급자 자격 증명을 보유 | 게이트웨이가 공급자 자격 증명을 보유 |
| 정책 범위 | 해당 애플리케이션 | 키, 사용자, 팀, 프로젝트 단위 |
| 주요 기능 | 공통 호출, 예외 매핑, Router, 콜백 | 인증, 가상 키, 예산, 속도 제한, 라우팅, 가드레일, 관리 UI |
두 방식은 경쟁 관계가 아닙니다. 한 서비스에서 모델 두세 개를 빠르게 비교하려면 SDK가 가볍습니다. 여러 서비스가 같은 모델 정책을 공유해야 한다면 Gateway가 자연스럽습니다. 조직에 따라 SDK로 시작한 뒤 호출량과 정책 요구가 커질 때 중앙 Gateway로 옮길 수도 있습니다.
Proxy가 AI Gateway가 되는 경계
단순 Proxy는 요청을 받아 다른 서버로 전달합니다. AI Gateway는 그 전후의 의사결정까지 맡습니다. LiteLLM의 Router는 여러 배포 대상의 부하 분산과 재시도, 대체 경로, 타임아웃, 냉각 상태를 관리합니다. Proxy의 가상 키는 모델 접근 범위를 제한하고 키, 사용자, 팀 단위의 사용 금액을 추적합니다. 예산과 TPM, RPM 제한도 같은 정책 경계에서 적용할 수 있습니다.
이 구조에서는 모델 이름도 물리적 배포 이름이 아니라 논리적 별칭이 됩니다. 예를 들어 애플리케이션이 support-fast를 요청하면 Gateway가 현재 건강 상태와 정책에 따라 실제 공급자와 리전을 선택할 수 있습니다. 공급자를 교체해도 애플리케이션 계약을 유지할 수 있다는 점이 중앙화의 핵심입니다.
다만 자동 대체가 항상 안전한 것은 아닙니다. 일부 응답을 이미 사용자에게 스트리밍한 뒤 다른 모델로 전환하면 서로 다른 답변이 한 응답에 섞일 수 있습니다. 모델마다 안전 정책과 도구 호출 의미도 다를 수 있습니다. Gateway가 제공하는 기능과 별개로, 어느 오류에서 재시도하고 어느 모델끼리 대체할지는 서비스가 명시적으로 설계해야 합니다.
채팅을 넘어선 확장
초기 LiteLLM은 completion과 embedding 호출의 차이를 줄이는 데 집중했습니다. 현재 공식 문서는 chat completions뿐 아니라 responses, embeddings, images, audio, batches 등 여러 엔드포인트 변환을 안내합니다. Gateway 문서에는 인증, 캐시, 가드레일, 비밀 관리, 비용 최적화, 감사 로그, Agent와 MCP 접근까지 별도의 운영 영역으로 정리돼 있습니다.
지원 범위가 넓어질수록 공통 인터페이스의 역할도 달라집니다. 처음에는 함수 하나의 입력과 출력을 맞췄다면, 이후에는 조직 전체의 AI 트래픽에 공통 제어면을 제공하게 됩니다. LiteLLM의 역사는 멀티 모델 SDK가 LLMOps 인프라로 확장되는 전형적인 경로를 보여줍니다.
2026년의 Rust 코어 도입
2026년 6월 23일에는 Mistral OCR 브리지를 시작점으로 Rust 워크스페이스가 저장소에 추가됐습니다. 이후 현재 저장소 소개는 Rust 코어와 Python SDK의 조합을 전면에 내세우고 있습니다. Python 사용 계약을 유지하면서 성능과 동시성에 민감한 실행 경로를 별도 코어로 확장하려는 변화로 읽을 수 있습니다.
이 변화도 앞선 역사와 같은 방향을 가리킵니다. 사용자에게는 안정된 공통 인터페이스를 제공하고, 내부에서는 공급자와 프로토콜, 실행 환경의 변화를 흡수합니다. 추상화의 외부 계약과 내부 구현을 분리하는 것이 LiteLLM이 처음부터 반복해 온 설계입니다.
도입 전에 구분할 질문
LiteLLM을 검토할 때는 지원 모델 개수보다 책임의 위치를 먼저 정하는 편이 좋습니다.
Python SDK가 잘 맞는 경우는 다음과 같습니다.
- 호출 주체가 한두 개 애플리케이션으로 제한됩니다.
- 공급자 자격 증명과 비용 책임을 애플리케이션이 가져도 됩니다.
- 별도 Gateway를 운영하는 부담을 피하고 싶습니다.
AI Gateway가 잘 맞는 경우는 다음과 같습니다.
- 여러 서비스가 같은 모델 별칭과 정책을 공유합니다.
- 공급자 키를 중앙에서 격리해야 합니다.
- 팀별 접근 제어, 예산, 속도 제한, 감사 기록이 필요합니다.
- 장애 대응과 모델 교체를 애플리케이션 배포와 분리해야 합니다.
직접 구현이 더 적합한 경우도 있습니다. 공급자가 소수이고 조직 고유의 인증, 정산, 데이터 보존 정책이 핵심이라면 작은 내부 Gateway가 더 단순할 수 있습니다. 반대로 다양한 공급자와 엔드포인트를 빠르게 지원해야 한다면 LiteLLM이 이미 해결한 변환과 운영 기능을 다시 만드는 비용이 큽니다.
마무리
LiteLLM은 2023년 여러 LLM API를 같은 Python 함수로 호출하려는 작은 추상화에서 시작했습니다. 스트리밍과 Router가 추가되고, Proxy가 가상 키와 예산, 사용량, 가드레일을 맡으면서 조직의 AI Gateway로 확장됐습니다. 핵심은 모델을 하나처럼 보이게 만드는 데 있지 않습니다. 계속 달라지는 모델 제공자와 애플리케이션 사이에 안정된 계약을 두고, 변화와 정책을 한 경계에서 관리하는 데 있습니다.
참고 자료
함께 읽기
- LLM 게이트웨이 직접 구현: 스트리밍부터 사용량 기록까지이 글에서 직접 구현할 LLM 서버는 모델 가중치를 GPU에 올리는 추론 서버가 아닙니다. 여러 외부 또는 내부 모델 엔드포인트 앞에서 인증, 모델 선택, 스트리밍, 장애 처리, 사용량 기록을 담당하는 애플리케이션 계층의 LLM Gateway입니다. 모델 추론 자체는 vLLM 같은 별도 엔진이나 상용 API가 담당한다고…
- RAG 대표 기술 한눈에 보기: 검색부터 GraphRAG까지RAG(Retrieval-Augmented Generation)는 사용자의 질문과 관련된 외부 지식을 먼저 찾고, 그 근거를 언어 모델에 전달해 답변을 생성하는 방식입니다. 모델이 학습 과정에서 기억한 정보에만 의존하지 않으므로 조직의 최신 문서나 전문 자료를 답변에 반영하고 출처를 제시하기 좋습니다.
- 사내 지식을 답변으로 바꾸는 RAG 시스템 구축기문서는 많지만 필요한 순간에 찾기 어렵고, 검색 결과를 열어 일일이 내용을 비교해야 한다면 지식은 충분히 활용되지 못합니다. 이번 글에서는 문서와 업무 데이터를 자연어로 검색하고, 근거와 함께 답을 생성하는 RAG 시스템을 작은 범위에서 시작해 운영 가능한 구조로 확장한 과정을 정리합니다.
- 내부 문서를 공개 AI에 연결할 때 필요한 안전장치문서 RAG를 관리자 화면 안에서만 사용하다가 공개 웹 서비스로 확장하면 가장 먼저 바뀌어야 하는 것은 UI가 아니라 신뢰 경계입니다.
- RAG 검색 임계값을 감으로 정하면 안 되는 이유RAG 시스템에는 검색 결과가 질문과 충분히 관련 있는지 판단하는 기준이 필요합니다. 기준이 너무 낮으면 무관한 문서를 근거로 답하고, 너무 높으면 답이 있는 질문도 “근거가 없다”고 처리합니다.