LiteLLM Proxy: 비용, 키 및 모델을 제어하기 위한 AI 게이트웨이 구축 방법

LiteLLM Proxy는 단순히 많은 모델을 호출하기 위한 어댑터가 아닙니다. 제대로 사용한다면, 팀이 AI 사용을 관리 가능한 인프라로 전환하는 계층이 됩니다. 즉, 각 에이전트가 자유롭게 소비하기 전에 키(keys), 예산(budgets), 경로(routes), 추적(traces) 및 권한(permissions)을 설정하는 단계입니다.

LiteLLM Proxy는 OpenAI, Anthropic, Gemini, Bedrock, Azure, 로컬 모델 및 기타 제공업체 앞에 공통 계층을 두기 위한 OpenAI 호환(OpenAI-compatible) 게이트웨이입니다. 핵심은 단순히 모델을 교체하는 것이 아니라, 인증(authentication), 예산(budgets), 속도 제한(rate limits), 지출 추적(spend tracking), 라우팅(routing), 로그(logs) 및 MCP 액세스를 중앙 집중화하는 것입니다.

TL;DR 배포 계획: 주요 키워드는 LiteLLM Proxy입니다. 스페인어 검색 의도는 코드 에이전트나 내부 AI 기능을 확장하기 전에 AI 게이트웨이를 배포하고 비용, 키, 모델 및 관측성(observability)을 제어하고자 하는 팀을 위한 기술 튜토리얼입니다. 나의 입장: 만약 모든 개발자, 봇, 에이전트가 제공업체의 직접적인 키를 사용하고 있다면, 당신은 이미 비용 제어 측면에서 늦은 것입니다. 프록시(proxy)가 잘못된 정책을 해결해주지는 않지만, 직접 호출에는 없는 강제 집행 지점(enforcement point)을 제공합니다.

LiteLLM Proxy란 무엇이며 어떤 문제를 해결하는가

인용 가능한 정의: LiteLLM Proxy는 OpenAI 클라이언트와 호환되는 셀프 호스팅(self-hosted) 게이트웨이로, 여러 LLM 제공업체로 요청을 라우팅하고 가상 키, 예산, 제한, 추적, 로그 및 액세스 정책과 같은 운영 제어를 적용합니다.

LiteLLM의 Python SDK와 혼동하지 마세요. SDK는 애플리케이션에서 모델을 호출하는 것을 돕습니다. 프록시는 플랫폼의 구성 요소입니다. 즉, 공통 URL, 인증 계층, 제어 평면(control plane) 및 누가 무엇을 소비했는지 알 수 있는 데이터베이스 역할을 합니다.

전형적인 사례는 팀이 Copilot, 내부 에이전트, OpenAI SDK를 사용하는 스크립트, Claude 테스트, Bedrock 모델 및 Gemini 프로토타입을 혼합하여 사용할 때 나타납니다. 게이트웨이가 없다면 비용과 권한은 환경 변수, 신용카드 및 서로 다른 대시보드에 흩어져 존재하게 됩니다.

실전 사례: 언제 사용하고 언제 사용하지 않을 것인가. 여러 애플리케이션이나 에이전트가 모델을 소비하고 있을 때, 사용자/팀별 예산(budgets)이 필요할 때, 각 클라이언트를 수정하지 않고 공급업체를 변경하고 싶을 때, 또는 프로덕션 환경에서 변칙적인 도구들을 도입하기 전에 추적(traces)과 제한(limits)이 필요할 때 사용합니다. 반면, 하루에 한 번 단일 모델을 호출하는 개인용 스크립트에는 도입하지 않겠습니다. 그런 경우에는 프록시, 데이터베이스, 비밀 정보(secrets) 및 모니터링을 운영하는 비용이 문제 자체보다 더 클 수 있습니다. 실질적인 경계선은 다음과 같습니다: 만약 당신이 이미 '누가 이것을 소비했는가', '어떤 키가 유출되었는가', '이 에이전트가 어떤 모델을 사용했는가' 또는 '왜 이 공급업체가 실패했는가'를 묻고 있다면, 당신은 이미 게이트웨이(gateway)의 영역에 들어선 것입니다.

최소 아키텍처: 클라이언트는 계속해서 OpenAI 호환 API를 사용하지만, 키 제어, 비용, 라우팅(routing), MCP 및 추적(traces)은 공통 레이어를 통과하게 됩니다.

의미 있는 최소 아키텍처

단순한 토폴로지(topology)로 시작하십시오: 내부 클라이언트가 base_url=http://tu-proxy:4000을 가리키고, 각 클라이언트는 가상 키(virtual key)를 사용하며, 프록시는 설정과 데이터베이스를 조회하고, 제한 사항을 적용하며, 공급업체로 라우팅하고, 비용과 추적을 기록합니다.

확인해야 할 사항

LiteLLM의 아키텍처 문서는 흐름을 명확한 단계로 설명합니다: Bearer 토큰 검증, 예산(budget) 확인, 키/사용자/팀별 글로벌 또는 개별 속도 제한(rate limits) 적용, 라우터(router) 통과, 공급업체 호출, 그리고 이후 작업에서 사용량(usage) 업데이트 순서입니다.

이 시퀀스(sequence)가 중요한 이유는 관찰 가능한 장애 지점(points of failure)을 제공하기 때문입니다. 요청이 나가지 않는다면, 유효하지 않은 키, 예산 소진, 속도 제한(rate limit), 공급업체 다운, 잘못 설정된 폴백(fallback), 또는 클라이언트 오류 중 무엇인지 구분할 수 있습니다.

가상 키(Virtual keys): 실제 공급업체 키를 배포하지 마세요

첫 번째 중요한 결정은 각 앱에 OPENAI_API_KEY, ANTHROPIC_API_KEY 또는 클라우드 자격 증명을 제공하는 것을 중단하는 것입니다. LiteLLM을 사용하면 프록시를 위한 가상 키(virtual keys)를 생성하여 실제 공급업체의 키를 노출하지 않고도 모델 접근 권한, 비용 및 메타데이터를 제어할 수 있습니다.

로컬 개발자(dev locales)의 경우, 적은 예산의 사용자 키(user keys)를 사용하세요. 운영 환경(production)에서는 특정 개인에게 의존하지 않는 서비스 계정(service accounts)이나 팀 키(team keys)를 사용하세요. CI의 경우, 파이프라인(pipeline)과 환경(environment)별로 분리된 키를 사용하세요.

RBAC(역할 기반 액세스 제어) 문서는 내부 사용자, 팀, 조직, 그리고 사용자 또는 팀(혹은 둘 다)에 연결된 가상 키(virtual keys)를 구분합니다. 이러한 구분은 단순한 행정 절차가 아닙니다. 이는 운영 환경을 망가뜨리지 않고 특정 사용자를 차단하거나, 글로벌 키를 공유하지 않고도 비용을 할당할 수 있게 해주는 핵심 요소입니다.

예산(Budgets) 및 속도 제한(rate limits): 사고 발생 전 상한선 설정하기

예산(budget)은 단순한 재무적 경고가 아닙니다. 이는 기술적인 제동 장치입니다. LiteLLM은 키(key), 사용자, 팀별로 지출을 제어할 수 있으며, 설정에 따라 공급업체(provider), 모델, 또는 태그(tag)별로도 예산을 관리할 수 있습니다.

첫 달에는 1센트 단위까지 최적화하려고 시도하지 않을 것입니다. 대신 보수적인 한도(limits), 제품 또는 워크플로우(workflow)별 태그, 그리고 다음과 같은 항목을 포함하는 주간 대시보드를 설정할 것입니다: 팀별 비용, 에이전트(agent)별 비용, 고가 모델, 도달한 속도 제한(rate limits), 그리고 예산 초과로 거부된 요청.

합리적인 정책 예시: 낮은 상한선과 일일 초기화가 적용된 로컬 개발 환경, 중간 상한선의 스테이징(staging) 환경, 월간 한도와 알림이 설정된 운영 환경, 그리고 세션당 상한선이 있는 자율 에이전트(autonomous agents). 에이전트가 반복 작업(iterate)을 수행할 수 있다면, 세션당 한도는 월간 한도만큼이나 중요합니다.

Routing, fallback 및 오류 은폐의 위험성에 관한 브리핑: LiteLLM Router는 로드 밸런싱(load balancing), 재시도(retries), 폴백(fallback), 그리고 예산 기반 라우팅(routing)을 지원합니다. 이는 탄력성(resilience)을 확보하고 싶을 때나, 특정 공급업체가 비싸거나, 과부하 상태이거나, 일시적으로 정책 범위를 벗어났을 때 유용합니다. 하지만 폴백(fallback)이 의미론적 변화(semantic changes)를 숨겨서는 안 됩니다. 거대 모델에서 저렴한 모델로 변경하면 품질, 도구 호출(tool calling), 구조화된 출력(structured output) 또는 보안이 깨질 수 있습니다. 운영 환경에서는 선택된 모델, 적용된 폴백, 그리고 변경 사유를 기록하세요.

나의 규칙: 허용 가능한 수준의 성능 저하(degradation)에는 자동 폴백을 적용하고, 비즈니스 결정, 변칙적 동작(mutant actions), 보안 또는 중요한 코드 생성에 영향을 미치는 성능 저하에는 승인 절차나 피처 플래그(feature flag)를 사용합니다.

MCP Gateway 실무 사례: 도구(tools)를 위한 단일 관문이지, 무제한 자유가 아닙니다. LiteLLM 또한 MCP Gateway를 제공합니다. 이는 공통 엔드포인트에서 MCP 도구(tools)를 노출하고 키(key), 팀 또는 조직별로 액세스를 제어할 수 있는 레이어입니다. 이는 에이전트(agents) 환경에 매우 적합한데, 이제 문제는 단순히 어떤 모델이 응답하느냐가 아니라, 어떤 도구(tools)를 건드릴 수 있느냐로 확장되었기 때문입니다. 장점은 명확합니다. 각 에이전트에 10개의 MCP 서버와 10개의 서로 다른 정책을 일일이 설정할 필요가 없습니다. 단점 또한 존재합니다. 게이트웨이를 기준 없이 설정하면 리스크가 중앙 집중화됩니다. MCP의 경우, 팀별 허용 목록(allowlists), 작은 규모의 도구 세트(toolsets), 기본 읽기 권한, 호출 감사(auditing), 그리고 조회용 도구(query tools)와 상태를 변경하는 도구(mutant tools) 간의 분리를 통해 시작하십시오. 도구 게이트웨이가 또 하나의 블랙박스가 되어서는 안 됩니다.

OpenTelemetry 및 로그: 추적(trace)이 없다면, 당신은 단지 청구서만 받게 됩니다

LiteLLM은 관측성(observability) 통합 기능과 호환 가능한 도구로 트레이스(traces)를 전송할 수 있는 OpenTelemetry 경로를 갖추고 있습니다. 최근 문서에 따르면, HTTP, 인증(auth), 가드레일(guardrails), LLM 호출 및 데이터베이스 쓰기에 대한 스팬(spans)을 포함하여 요청별 트레이스(traces)를 생성하는 v2 통합 기능이 언급되어 있습니다.

최소한 측정해야 할 항목은 다음과 같습니다: 요청된 모델, 사용된 모델, 가상 키(virtual key), 팀, 익명화된 사용자 또는 테넌트(tenant), 지연 시간(latency), 토큰(tokens), 비용(cost), 오류(errors), 폴백(fallback), 속도 제한(rate limit), 예산 거부(budget rejection), MCP 도구 호출(tool calls MCP), 그리고 검토가 있는 경우 인간이 승인한 결과입니다.

프롬프트와 응답의 로깅(logging)에는 주의가 필요합니다. 관측성(observability)이 비밀 정보를 저장한다는 의미는 아닙니다. 트레이스(traces)를 외부 SaaS로 보내기 전에 작성 규칙, 보관 기간 및 금지된 필드를 정의하십시오.

초기 설정 예시

로컬 테스트를 위해, 문서는 CLI 또는 Docker로 프록시(proxy)를 실행하고 base_url을 변경하여 어떤 OpenAI 호환 클라이언트로도 엔드포인트(endpoint)를 호출할 수 있도록 지원합니다. 본격적인 단계는 가상 키(virtual keys)를 관리하기 위해 데이터베이스와 마스터 키(master key)를 추가할 때 시작됩니다.

확인해야 할 사항

최소한의 config.yaml에는 안정적인 내부 이름을 가진 모델 선언, 실제 API 키를 위한 환경 변수, general_settings.master_key, 지속적인 키 관리 (key management)를 위한 Postgres 연결, 그리고 애플리케이션 코드 외부의 예산 제한/속도 제한 (rate limit) 설정이 포함되어야 합니다.

진정한 추상화 (abstraction)를 원한다면 내부 모델 이름을 제공업체와 동일하게 명명하지 마세요. coding-fast, coding-deep, support-cheap 또는 extract-structured와 같은 이름을 사용하세요. 이렇게 하면 각 애플리케이션을 다시 교육할 필요 없이 백엔드 (backend)를 변경할 수 있습니다.

일주일 배포 계획

• 1일 차: 현재 고객, 제공업체, 키 및 AI 워크플로우 (flows) 인벤토리 조사.

• 2일 차: 두 개의 모델과 프록시의 base_url을 가리키는 OpenAI 호환 (OpenAI-compatible) 클라이언트를 사용하는 로컬 프록시 구축.

• 3일 차: Postgres, 마스터 키 (master key), 환경별 가상 키 (virtual keys) 및 낮은 테스트 예산 설정.

• 4일 차: 제품 또는 워크플로우별 태그 (tags), 지출 추적 (spend tracking) 및 기본 대시보드 구축.

• 5일 차: 사용자, 팀 또는 서비스 계정 (service account)별 속도 제한 (rate limits) 및 예산 설정.

• 6일 차: 비임계적 (non-critical) 워크플로우를 위한 라우팅 (routing)/폴백 (fallback) 설정.

• 7일 차: OpenTelemetry, 알림, 키 로테이션 (rotation) 런북 (runbook) 및 허용된 모델 정책 수립.

피해야 할 실수

• 첫 번째는 게이트웨이를 아무것도 결정하지 않는 투명한 프록시 (transparent proxy)로 만드는 것입니다. 예산이나 추적 (traces) 없이 모든 키가 모든 모델을 호출할 수 있다면, 단순히 지연 시간 (latency)만 추가한 셈입니다.

• 두 번째는 첫날부터 모든 제공업체와 모델을 집어넣는 것입니다. 저렴하고 빠른 경로 하나와 비싸고 깊이 있는 경로 하나, 이렇게 두 가지 경로로 시작하세요. 나머지는 실제 사용량이 발생할 때 도입하면 됩니다.

• 세 번째는 예산 (budgets)을 소유권 (ownership)의 대체제로 사용하는 것입니다. 예외 사항, 태그, 고가의 모델 및 폴백 (fallback) 실패를 아무도 검토하지 않는다면, 프록시는 무시되는 또 다른 대시보드가 될 뿐입니다.

프로덕션 체크리스트

• 게이트웨이 및 AI 비용의 소유자를 정의하십시오.

• 공급업체의 실제 키(real keys)와 프록시의 가상 키(virtual keys)를 분리하십시오.

• 지속적인 키 관리 (key management)를 위해 Postgres를 사용하십시오.

• 개발(dev), CI, 스테이징(staging), 프로덕션(production), 그리고 자율 에이전트(autonomous agents)를 위한 별도의 키를 생성하십시오.

• 키, 팀 또는 사용 사례(use case)별로 모델 사용을 제한하십시오.

• 광범위한 액세스를 허용하기 전에 예산(budgets)과 속도 제한(rate limits)을 설정하십시오.

• 키, 사용자, 팀 및 워크플로우(workflow)별 비용을 기록하십시오.

• 트레이스(traces)를 활성화하고 어떤 필드를 마스킹(redact)할지 결정하십시오.

• 폴백(fallback)을 문서화하고, 증거 없이 품질을 변경하는 용도로 사용하지 마십시오.

• MCP의 경우, 읽기 도구(tools)와 변이(mutation) 도구를 서로 다른 권한으로 분리하십시오.

실무적 통찰: LiteLLM Proxy는 AI 사용이 개인적인 실험을 넘어 공유 인프라로 전환될 때 적합합니다. 이 도구의 가치는 모델 호출을 더 편하게 만드는 데 있는 것이 아니라, 비용, 액세스, 라우팅(routing), 트레이스(traces) 및 권한을 위한 공통 경계(common frontier)를 갖는 데 있습니다. 저의 권장 사항은 다음과 같습니다: 공격적인 최적화를 위해서가 아니라, 가시성(visibility) 확보를 위해 게이트웨이를 먼저 배포하십시오. 누가 소비하는지, 어떤 모델을 사용하는지, 어떤 워크플로우가 실패하는지를 알게 되었을 때, 그때 예산, 폴백(fallback), 캐싱(caching), MCP 및 가드레일(guardrails)을 조정하십시오. 이 순서를 따르지 않는다면, 당신은 눈을 가린 채 최적화를 시도하는 것이 될 것입니다.

자주 묻는 질문 (FAQ)

LiteLLM Proxy란 무엇인가요?

LiteLLM Proxy는 OpenAI 클라이언트와 호환되는 셀프 호스팅(self-hosted) AI 게이트웨이로, 여러 LLM 공급업체에 대한 액세스, 가상 키(virtual keys), 예산(budgets), 속도 제한(rate limits), 라우팅(routing), 로그(logs), 트레이스(traces) 및 비용 제어를 중앙 집중화합니다.

LiteLLM Proxy가 OpenAI SDK를 대체하나요?

아니요. 많은 OpenAI 호환 클라이언트는 base_url을 프록시로 변경함으로써 계속 사용할 수 있습니다. 프록시는 애플리케이션과 공급업체 사이에 위치합니다.

LiteLLM Proxy를 사용하려면 Postgres가 필요한가요?

단순한 테스트를 위해서는 항상 필요한 것은 아니지만, 키 관리(key management), 지속적인 가상 키(virtual keys) 및 본격적인 지출 추적(spend tracking)을 위해서는 데이터베이스와 함께 배포하는 것이 좋습니다.

LiteLLM Proxy가 에이전트의 비용을 제어하는 데 도움이 되나요?

네, 특히 각 에이전트가 고유한 가상 키 (virtual key), 세션 또는 팀별 예산 (budgets), 워크플로우 태그 (tags of workflow) 및 소비량을 할당할 수 있는 트레이스 (traces)를 사용하는 경우에 더욱 그렇습니다.

LiteLLM Proxy는 MCP와 함께 작동하나요?

LiteLLM은 키 (key), 팀 (team) 또는 조직 (organization)별 액세스 제어를 통해 도구 (tools), 프롬프트 (prompts) 및 리소스 (resources)를 나열하고 호출할 수 있는 MCP 게이트웨이 (MCP Gateway)를 포함합니다.

주요 위험 요소는 무엇인가요?

게이트웨이가 정책 (policy)을 대체할 수 있다고 믿는 것입니다. 허용된 모델 (models), 예산 (budgets), 로그 보존 (retention of logs), MCP 권한 (permissions) 및 소유권 (ownership)을 정의하지 않는다면, 단지 혼란을 중앙 집중화할 뿐입니다.

편집자 마무리 운영 규칙: 코멘트가 검토 가능한 노이즈만 생성하는 곳이 아니라, 기술적 의사결정을 변경할 수 있는 곳에서 자동화를 활성화하십시오.

출처 및 참고 문헌