LiteLLM 대안(2026) — 호스팅 게이트웨이, BYO-key 제어 플레인 및 계속 사용할 시점

LiteLLM은 직접 운영하는 오픈 소스 OpenAI 호환 프록시입니다. 자체 공급자 계정 앞에 배치하여 코드에 하나의 엔드포인트와 하나의 키 형식을 제공합니다(공식 문서). 팀이 대안을 찾는 이유는 서로 관련 없는 두 가지입니다. 운영: 자체 호스팅 프록시는 패치하고 확장하고 장애 알림을 받아야 하는 서비스가 하나 더 생긴다는 뜻입니다. 공급망: 2026년 3월 24일 공격자가 백도어가 삽입된 LiteLLM 릴리스 두 개를 PyPI에 게시했고, 이 사건으로 "빌드에 포함된 패키지"의 공격 표면을 비용으로 산정하지 않았던 많은 팀이 그 위험을 인식하게 되었습니다. 이 비교 글은 각 동기에 실제로 답하는 도구를 연결합니다. 여기에는 계속 사용하는 방안도 포함되며, 그 근거는 이 검색에서 보이는 7개의 공급업체 목록형 글이 시사하는 것보다 더 강합니다.

편향을 먼저 밝히면 다음과 같습니다. Kunavo는 당사의 제품이며 첫 번째로 소개합니다. 아래의 다른 모든 도구에는 실제 추천 의견과 검증한 세부 사항이 비교 페이지에 정리되어 있고, 평가하지 않은 두 도구는 자체 사이트에 명시된 수준에서만 설명합니다.

최종 후보

대부분의 판단을 좌우하는 구분

LiteLLM은 한 번에 두 가지 역할을 수행하지만, 대부분의 대체 도구는 그중 하나만 수행합니다. LiteLLM은 프록시(여러 공급자 앞의 단일 엔드포인트)이자 BYO 키 도구(공급자 계정은 사용자의 소유로 유지됨)입니다. 호스팅 추론 게이트웨이인 Kunavo와 OpenRouter는 두 역할을 모두 대체합니다. 게이트웨이가 상위 공급자의 자격 증명을 보관하고 사용량에 따라 요금을 청구하므로 실행할 프록시도, 보유할 공급자 계정도 없습니다. 호스팅 제어 플레인인 Portkey와 TrueFoundry는 첫 번째 역할만 대체합니다. 프록시 운영은 중단하지만 계정은 유지합니다. 어느 쪽을 대체하려는지 알면 이 목록의 대부분이 정리됩니다. 이 패턴은 LLM 게이트웨이 가이드에서 자세히 설명합니다.

실제로 사람들이 검색하게 된 계기

이 검색의 첫 번째 결과는 목록형 글이 아니라 공급망 공격에 관한 Reddit 스레드입니다. 다음은 LiteLLM 자체의 보안 업데이트에 따른 사건 경과입니다. 2026년 3월 24일, 공격자가 악성 코드를 배포된 wheel에 삽입한 litellm==1.82.7 및 litellm==1.82.8을 PyPI에 게시했습니다. 해당 패키지는 PyPI가 격리하기 전까지 10:39 UTC부터 약 40분 동안 공개되어 있었습니다. 침해 원인은 LiteLLM의 CI/CD 보안 검사 워크플로에 포함된 Trivy 의존성으로 추적되었습니다. 공격자는 공식 릴리스 워크플로를 우회하고 PyPI에 직접 업로드했습니다. SecurityWeek에 따르면 2,500개가 넘는 조직이 영향을 받았습니다.

LiteLLM의 대응 조치는 공개적으로 기록되어 있으며 상당한 규모였습니다. 침해된 패키지를 제거하고, 유지관리자 자격 증명을 교체했으며, 포렌식을 위해 Mandiant를 참여시켰습니다. 또한 격리된 빌드 환경, 강화된 릴리스 게이트, cosign 서명 Docker 이미지를 갖춘 재구축된 CI/CD 파이프라인을 통해 v1.83.0을 릴리스했습니다. 1.83.0 이상을 사용하고 있으며 해당 40분 동안 악성 버전을 실행하지 않았다면, 이 사고는 귀하에게 종료된 문제입니다.

이 사건이 여전히 사람들을 이 검색으로 이끄는 이유는 LiteLLM 자체보다는 구조적인 문제에 있습니다. 자체 호스팅 프록시는 빌드에 포함된 패키지이므로 CI/CD와 클러스터가 그 영향 범위에 포함됩니다. 이 문장은 곱씹어 볼 가치가 있습니다. MLflow AI Gateway를 포함해 이 페이지의 모든 자체 호스팅 대안에도 똑같이 적용되며, 호스팅 엔드포인트가 제거하는 유일한 요소이기도 합니다. HTTPS URL을 호출하므로 오염시킬 패키지가 없고, 게이트웨이의 실행 구성 요소가 네트워크 내부에서 동작하지 않습니다.

솔직히 말해 나머지 절반도 있습니다. 호스팅 게이트웨이가 더 안전한 것은 아니며, 노출 방식이 다를 뿐입니다. API 키와 프롬프트 텍스트가 다른 회사의 인프라를 통과하고, 직접 패치해야 하는 위험 대신 해당 회사의 침해 위험을 떠안게 됩니다. 프롬프트 텍스트가 인프라 밖으로 나갈 수 없다면 자체 호스팅이 올바른 답이며, 이 페이지의 나머지 내용은 선택해서는 안 되는 절충안에 관한 것입니다.

1. Kunavo — 프록시 없음, 공급자 계정 없음

Kunavo는 호스팅 추론 게이트웨이입니다. 하나의 OpenAI 호환 base URL, 하나의 sk-kn- 키, 하나의 종량제 잔액을 제공하며, 상위 공급자의 자격 증명은 사용자가 아니라 당사가 보관합니다. LiteLLM과 비교하면 역할 분담이 다릅니다. 프록시를 운영할 필요가 없고 Anthropic, Google, OpenAI에 별도의 계정을 유지할 필요도 없습니다.

가격: 카탈로그의 대부분은 공급자의 공식 요금보다 낮은 가격으로 표시됩니다 — Claude Sonnet 4.6은 1M 토큰당 $2.10 / $10.50이며, Anthropic의 요금은 $3.00 / $15.00입니다. LiteLLM은 아무것도 재판매하지 않으므로 마크업이 없습니다. 사용자가 지불하는 금액은 자신의 공급자 계약에 따른 금액이므로, 비교 기준은 0이 아니라 당사 요금과 사용자의 직접 요금입니다. 지원 범위: 동일한 키와 잔액으로 채팅, 이미지, 비디오 및 음악 모델을 사용할 수 있습니다. 지원하지 않는 기능: 사용자의 공급자 키 라우팅입니다. LiteLLM이 유지하는 BYO 키 역할이며 당사는 이를 대체하지 않습니다. 자세한 내용은 Kunavo와 LiteLLM 비교를 참조하세요.

2. OpenRouter — 가장 긴 모델 목록

또 다른 호스팅 추론 게이트웨이이며, 단가보다 카탈로그의 폭이 중요할 때 선택할 도구입니다. 하나의 지갑에서 대규모 공급자 집합의 수백 개 모델을 사용할 수 있고, 무료 티어와 Kunavo에는 없는 BYO 키 라우팅도 제공합니다. 계정 보유를 중단하기 위해 LiteLLM을 떠나는 경우 OpenRouter와 Kunavo가 현실적인 두 가지 형태입니다. Kunavo와 OpenRouter 비교에서 두 도구를 나란히 비교하며, OpenRouter 개요에서 해당 분야의 나머지 내용을 다룹니다.

3. Portkey — 키는 유지하고 운영은 중단

이미 보유한 공급자 계정 위에 제공되는 호스팅 제어 플레인입니다. 자체 프록시를 운영하지 않고도 라우팅, 장애 조정, 가드레일 및 관측 기능을 제공합니다. LiteLLM을 라우팅 및 예산 기능 때문에 선택했고 실제로 포기하고 싶은 것이 운영뿐이라면 가장 가까운 대체 도구입니다. 자세한 내용은 Kunavo와 Portkey 비교를 참조하세요.

4. Helicone — 이유가 관측성뿐이었다면

많은 LiteLLM 배포는 요청 로그와 팀별 비용 귀속이 필요했고, 이를 얻는 방법으로 프록시를 사용했기 때문에 존재합니다. 이러한 경우라면 기존 공급자 호출 위에 관측성 계층을 추가하는 편이 게이트웨이보다 훨씬 작은 운영 부담입니다. 자세한 내용은 Kunavo와 Helicone 비교를 참조하세요.

5. TrueFoundry — 구매 부서가 공급업체를 요구하는 경우

이 검색에서 자체 LiteLLM 비교 글과 함께 2위를 차지합니다. 지연 시간 오버헤드, 배포 유연성, SLA, 거버넌스 및 감사 대응 제어 기능을 내세워 판매되는 엔터프라이즈 AI 게이트웨이입니다(제품 페이지). 당사는 이를 평가하지 않았으므로 이 항목은 추천이 아니라 참고용 안내입니다. 오픈 소스 프록시에 지원 계약이 없다는 점이 장애 요인이라면 이 범주가 그 문제를 해결하며, 해당 비교 글을 작성자가 직접 작성했다는 점을 염두에 두고 읽을 가치가 있습니다.

6. MLflow AI Gateway — 동일한 유형의 오픈 소스 교체

3위이며, 이 페이지에서 LiteLLM 자체와 가장 가까운 도구입니다. 오픈 소스 자체 호스팅 게이트웨이로, 자체 공급자 키 앞에 배치되고 MLflow 프로젝트의 일부로 유지관리됩니다. 분명히 말하면, 하나의 자체 호스팅 프록시를 다른 자체 호스팅 프록시로 교체하면 배포 모델이 유지되며 따라서 위에서 설명한 공격 표면도 그대로 남습니다. 이는 정당한 선택입니다. 싫었던 것이 모델이 아니라 프로젝트였다면 선택할 만한 방법입니다.

7. Cloudflare AI Gateway — 엣지에서 캐싱과 제한 제공

이미 보유한 공급자 계정 앞에 배치하는 얇은 프록시입니다. 추론을 재판매하지 않고 응답 캐싱, 속도 제한, 재시도 및 분석 기능을 제공합니다. Kunavo나 OpenRouter를 포함해 어떤 추론 소스와도 조합할 수 있으며, 추론 소스를 대체하지는 않습니다. 자세한 내용은 Kunavo와 Cloudflare AI Gateway 비교를 참조하세요.

LiteLLM이 여전히 올바른 선택인 경우

• 프롬프트 텍스트가 인프라 밖으로 나갈 수 없습니다. 규제 데이터, 망분리 환경 또는 호스팅 게이트웨이로는 충족할 수 없는 정책이 이에 해당합니다. 자체 호스팅이 답이며, 유일한 질문은 어떤 자체 호스팅 프록시를 선택할지입니다.
• 공급자 계약을 협상해 두었습니다. Anthropic, OpenAI 또는 Google의 약정 사용액이나 엔터프라이즈 요금은 재판매업체가 제시하는 어떤 요금보다 가치가 큽니다. BYO 키 도구를 사용하면 해당 계약을 계속 이용할 수 있습니다.
• 키별 예산과 팀 라우팅을 사용합니다. 이러한 기능이 많은 LiteLLM 배포가 존재하는 이유입니다. base-URL 교체만으로 마이그레이션이 끝난다고 가정하기 전에 대체 도구가 해당 기능을 지원하는지 확인하세요.
• 직접 읽고 수정할 수 있는 소스를 원합니다. 직접 통제하는 오픈 소스 프록시는 실제 속성입니다. 2026년 3월 사고도 이를 없애지 않습니다. 해당 사고는 이후 조치가 완료된 릴리스 파이프라인 침해였지, 프록시 자체의 결함이 아니었습니다.

전환은 두 줄입니다

여기에서 추론을 재판매하는 모든 대안은 OpenAI 와이어 프로토콜을 사용하므로 LiteLLM 프록시에서 벗어나는 작업은 base_url 및 키 교체입니다. 요청 및 응답 형식은 변경되지 않습니다.

# Before: your own LiteLLM proxy, your own provider keys,
# your own container to patch.
client = OpenAI(
    api_key=os.environ["LITELLM_MASTER_KEY"],
    base_url="http://litellm.internal:4000",
)

# After: a hosted endpoint. No package in your build, no proxy to run.
client = OpenAI(
    api_key=os.environ["KUNAVO_API_KEY"],
    base_url="https://api.kunavo.com/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

두 줄로 끝나지 않는 부분은 LiteLLM이 라우팅을 넘어 수행하던 기능, 즉 키별 예산, 팀별 분배, 사용자 지정 콜백입니다. 먼저 이를 목록으로 정리하세요. 와이어 수준의 세부 사항은 OpenAI 호환 API 가이드에 있으며, 게이트웨이가 대신 처리해야 할 기능에서 대체 도구와 비교할 기능 집합을 다룹니다.

자주 묻는 질문