LiteLLM (SDK + Proxy Gateway) 설정하기

최근 저는 여러 LLM 제공업체(OpenAI, Anthropic, Vertex 등)를 단일 인터페이스 아래로 통합하기 위해 LiteLLM을 설정하는 데 시간을 보냈습니다.

핵심 아이디어는 간단했습니다:

제공업체 간의 결합(coupling)을 줄이고 모델 불가지론적(model-agnostic)인 LLM 추상화 계층으로 이동하는 것입니다.

SDK 설정 (간단한 부분)

Python SDK 설치는 간단했습니다:

uv add litellm

기본 사용법:

from litellm import completion

completion(
...

여기서 눈에 띄는 점은 다음과 같습니다:

• 제공업체 전반에 걸쳐 동일한 API 사용
• 최소한의 설정
• SDK 파편화 없음

이 부분은 마찰 없이 즉시 작동했습니다.

흥미로운 부분: LiteLLM Proxy

진정한 가치는 프록시(LLM Gateway 계층)를 탐색할 때 시작되었습니다.

litellm --model gpt-4o

이것은 로컬의 OpenAI 호환 엔드포인트(endpoint)를 노출합니다:

이 단계에서 LiteLLM은 라이브러리처럼 느껴지는 것을 넘어 인프라(infrastructure)처럼 작동하기 시작합니다.

핵심 추상화: YAML 설정

라우팅 계층은 설정을 사용할 때만 명시적으로 드러납니다:

model_list:
  - model_name: gpt-4o
    litellm_params:
...

이 지점에서 사고 모델(mental model)이 전환됩니다:

LiteLLM은 단순한 클라이언트가 아니라 — 모델 라우팅 시스템이 됩니다.

프로덕션 설정 (Docker)

Docker에서 프록시를 실행하는 것은 간단하지만, 설정 및 환경 해석(environment resolution)에 민감합니다:

docker run \
  -v $(pwd)/litellm_config.yaml:/app/config.yaml \
  -e OPENAI_API_KEY=your-key \
...

이것이 중요한 이유

실행되고 나면, 어떤 OpenAI 호환 클라이언트라도 게이트웨이(gateway)와 상호작용할 수 있습니다:

• 모델 추상화가 중앙 집중화됩니다
• 라우팅이 구성 가능해집니다
• 제공업체 전환이 투명해집니다
• 인프라 관련 관심사가 애플리케이션 코드에서 분리됩니다

핵심 요약

처음에는 단순한 SDK처럼 보이지만, 빠르게 경량 LLM 인프라 계층이 됩니다.

핵심적인 사고의 전환:

모델을 직접 호출하는 것에서 → 모델 라우팅을 인프라로서 관리하는 것으로

마치며

LiteLLM의 가장 흥미로운 부분은 SDK 그 자체라기보다, 다음과 같은 기능을 가능하게 하는 프록시 계층 (proxy layer)입니다:

• 멀티 프로바이더 라우팅 (multi-provider routing)
• 중앙 집중식 제어 (centralized control)
• 배포 유연성 (deployment flexibility)

이는 LLM을 고립된 API가 아닌 인프라 구성 요소 (infrastructure components)로 취급하기 위한 실질적인 단계입니다.