[AI]LiteLLM: 하나의 인터페이스로 여러 LLM 사용하기

개요

LiteLLM은 여러 LLM 제공자의 API를 OpenAI 호환 형식으로 호출할 수 있게 해주는 오픈소스 도구이다. OpenAI, Azure OpenAI, Anthropic, Vertex AI, Bedrock, Ollama 같은 모델을 하나의 방식으로 다루는 데 초점이 있다.

LLM을 서비스에 붙이다 보면 제공자마다 인증 방식, 요청 형식, 응답 구조, 에러 처리 방식이 다르다. 처음에는 SDK를 각각 붙여도 되지만, 모델이 늘어나고 팀이 많아지면 관리가 복잡해진다.

LiteLLM은 이 문제를 Python SDK와 Proxy Server 방식으로 해결한다. 개인 개발자는 SDK로 빠르게 테스트할 수 있고, DevOps나 플랫폼 팀은 Proxy Server를 LLM Gateway처럼 운영할 수 있다.

애플리케이션은 LiteLLM Proxy만 바라보고, 실제 모델 라우팅과 API Key 관리는 Proxy에서 처리한다.

주요 특징

LiteLLM의 핵심은 "모델 제공자가 달라도 애플리케이션 호출 방식은 최대한 유지한다"는 점이다.

OpenAI 호환 API 형식을 제공하므로 기존 OpenAI SDK 기반 코드와 함께 쓰기 쉽다. 예를 들어 애플리케이션은 /v1/chat/completions로 요청을 보내고, LiteLLM이 뒤에서 OpenAI, Bedrock, Anthropic 같은 백엔드 모델로 전달한다.

Proxy Server를 사용하면 팀별 API Key, 비용 추적, Rate Limit, 인증 훅을 중앙에서 관리할 수 있다. 여러 서비스가 각자 모델 키를 들고 있는 구조보다 관리 지점이 줄어든다.

또한 Router 기능을 통해 재시도, fallback, 여러 배포 대상 간 라우팅을 구성할 수 있다. 운영 환경에서는 특정 모델 장애나 Rate Limit 상황을 고려해야 하므로 이런 기능이 필요하다.

관측성도 중요하다. LiteLLM은 Langfuse, MLflow, Helicone 같은 도구와 연동해 요청, 비용, 지연 시간을 추적할 수 있다. LLM 사용량이 비용으로 바로 이어지는 환경에서는 이 부분이 특히 중요하다.

사용이 필요한 상황

여러 LLM 제공자를 같은 방식으로 호출해야 하는 경우
OpenAI SDK 기반 코드를 유지하면서 Bedrock, Anthropic, Vertex AI 등을 붙이고 싶은 경우
팀별 LLM 사용량과 비용을 확인해야 하는 경우
모델별 API Key를 애플리케이션마다 직접 배포하고 싶지 않은 경우
PoC 단계에서 모델을 빠르게 바꿔 테스트해야 하는 경우
운영 환경에서 인증, 로그, Rate Limit, fallback 구성이 필요한 경우

설치 또는 시작 방법

Python SDK로 시작하려면 패키지를 설치하고 completion()을 호출하면 된다.

uv add litellm

uv tool install 'litellm[proxy]'
litellm --model openai/gpt-5

첫 번째 명령은 Python 프로젝트에 LiteLLM 패키지를 추가한다. 두 번째와 세 번째 명령은 LiteLLM Proxy 실행 도구를 설치하고 로컬 Proxy를 실행한다. 기본적으로 http://0.0.0.0:4000에서 요청을 받는다.

Docker로 구성하려면 설정 파일을 먼저 만든다. 운영에 가까운 형태로 테스트하려면 단일 실행 명령보다 config.yaml을 사용하는 방식이 낫다.

litellm_settings:
  master_key: sk-local-test

model_name은 클라이언트가 호출할 이름이다. litellm_params.model은 LiteLLM이 실제로 호출할 백엔드 모델이다.

운영에서는 이 매핑을 이용해 클라이언트 코드 변경 없이 백엔드 모델을 바꿀 수 있다.

docker run \
  -v $(pwd)/litellm_config.yaml:/app/config.yaml \
  -e OPENAI_API_KEY=$OPENAI_API_KEY \
  -p 4000:4000 \
  docker.litellm.ai/berriai/litellm:main-latest \
  --config /app/config.yaml

현재 디렉터리의 설정 파일을 컨테이너 안의 /app/config.yaml로 연결한다.

4000 포트를 열기 때문에 애플리케이션은 http://localhost:4000을 OpenAI 호환 API 엔드포인트처럼 사용할 수 있다.

Docker Compose로 관리하려면 services.litellm에 이미지, 포트, 환경변수, 설정 파일 마운트를 정의하면 된다.

이후 docker compose up -d로 실행한다.

Compose를 쓰면 팀에서 같은 테스트 환경을 재현하기 쉽다.

실습

간단한 시나리오는 "애플리케이션이 LiteLLM Proxy를 통해 모델을 호출한다"로 잡을 수 있다.

사전 조건
Docker 실행 환경이 필요하다. 사용할 모델 제공자의 API Key도 준비한다.
설치
위의 Docker 실행 방식을 사용한다. OPENAI_API_KEY는 로컬 환경변수로 먼저 설정한다.
설정
litellm_config.yaml에 default-chat 모델을 등록한다. 운영에서는 모델명을 서비스 기준으로 정하는 편이 관리하기 쉽다.
실행
컨테이너를 실행한 뒤 4000 포트가 열려 있는지 확인한다.
결과 확인
다음 요청으로 Proxy 호출을 확인한다.

curl http://localhost:4000/v1/chat/completions \
  -H "Authorization: Bearer sk-local-test" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "default-chat",
    "messages": [
      {"role": "user", "content": "LiteLLM을 한 문장으로 설명해줘"}
    ]
  }'

Authorization 헤더에는 litellm_settings.master_key 값을 넣는다.

model에는 설정 파일의 model_name을 사용한다. 응답에서는 choices[0].message.content를 확인하면 된다.

알아야 할 사항

테스트 환경에서는 간단히 실행할 수 있지만, 운영 환경에서는 인증 방식과 로그 저장 위치를 함께 고려해야 한다.

LiteLLM Proxy는 여러 모델 제공자의 API Key를 다룬다. 따라서 Proxy 자체가 중요한 보안 경계가 된다. 네트워크 접근 제어, Secret 관리, 로그 마스킹, 관리자 권한 분리를 확인해야 한다.

팀별 비용 추적, 사용자별 키 관리, Admin UI 같은 기능을 쓰려면 데이터베이스 구성이 필요할 수 있다. 단순 Proxy 실행과 DB 기반 운영 기능을 구분해서 설계하는 편이 좋다.

Bedrock이나 Vertex AI처럼 클라우드 권한이 필요한 제공자를 붙일 때는 IAM 권한, 리전, 모델 접근 권한을 따로 확인해야 한다. 모델명과 지원 파라미터는 자주 바뀔 수 있으므로 공식 문서 기준으로 확인해야 한다.

대체 도구로는 OpenRouter, 각 클라우드의 자체 AI Gateway, LangChain이나 LlamaIndex의 Provider 추상화가 있다. LiteLLM은 OpenAI 호환 Proxy와 SDK를 함께 제공한다는 점에서 쓰임새가 다르다.

장점과 아쉬운 점

장점:

여러 LLM 제공자를 같은 API 형식으로 호출할 수 있다.
Proxy를 두면 모델 키와 라우팅을 중앙에서 관리할 수 있다.
비용 추적, Rate Limit, fallback 같은 운영 기능을 붙일 수 있다.
OpenAI SDK 기반 코드와 함께 쓰기 쉽다.

아쉬운 점:

단일 모델만 쓰는 작은 프로젝트에는 설정이 더 늘어날 수 있다.
운영 환경에서는 Proxy 자체의 보안과 가용성을 관리해야 한다.
제공자별 고유 기능은 완전히 동일하게 추상화되지 않을 수 있다.
모델명, 파라미터, 지원 API는 공식 문서 확인이 필요하다.

정리

LiteLLM은 여러 LLM 제공자를 하나의 OpenAI 호환 인터페이스로 묶기 위한 도구이다. 개발자는 SDK로 빠르게 시작할 수 있고, DevOps나 플랫폼 팀은 Proxy Server를 LLM Gateway처럼 운영할 수 있다.

특히 여러 팀이 LLM을 함께 쓰고, 비용과 권한을 관리해야 하는 환경에서 의미가 있다. 바로 운영에 넣기보다는 로컬 Docker Proxy와 작은 테스트 서비스로 먼저 검증하는 편이 좋다. 이후 인증 방식, 로그 저장 위치, DB 구성, 네트워크 접근 제어를 차례대로 정리하면 된다.

최신 설치 방법, 지원 모델, 엔터프라이즈 기능은 공식 문서와 GitHub 릴리즈 노트를 기준으로 확인하는 것이 좋다.

참고 자료

'AI > LLM' 카테고리의 다른 글

[AI] Claude Haiku 4.5 출시 (0)	2025.10.16