LiteLLM vs OpenRouter: 두 서비스를 모두 사용해보고 발견한 각각의 한계점

요약 (TL;DR)

• LiteLLM과 OpenRouter는 경쟁 제품이 아닙니다. LiteLLM은 직접 실행하는 셀프 호스팅(self-hosted) 오픈 소스 프록시(proxy)이며, OpenRouter는 관리형 클라우드 애그리게이터(aggregator)입니다. 이 비교는 여러분이 실제로 해결하려는 문제가 무엇인지 이해하고 있을 때만 의미가 있습니다.
• LiteLLM의 한계: SSO 및 팀 단위 예산 집행 기능은 엔터프라이즈 라이선스(enterprise license)에 포함되어 있으며, 분산 속도 제한(distributed rate limiting)을 위한 Redis 의존성은 반드시 알아두어야 할 장애 모드(failure mode)를 가지고 있습니다. 또한, 규모가 커지면 YAML 설정이 다루기 힘들어집니다.
• OpenRouter의 한계: 모든 것이 OpenRouter의 인프라 내에서 작동하며, 셀프 호스팅 모델을 사용할 수 없고, 팀 단위의 거버넌스(governance) 기능이 없으며, 높은 거래량에서는 누적되는 5.5%의 크레딧 구매 수수료가 발생합니다.
• 우리의 결론: 우리 설정에는 둘 다 장기적인 정답이 아니었습니다. 이 포스트는 그 이유를 설명합니다.

약 1년 전 LLM 라우팅 옵션을 평가하기 시작했을 때, 제가 발견한 대부분의 "LiteLLM vs OpenRouter" 콘텐츠는 단순히 기능들을 매트릭스(matrix)로 비교하고 끝내는 수준이었습니다. 이는 더 중요한 질문을 놓치고 있었기에 유용하지 않았습니다. 즉, 이 도구들은 근본적으로 다른 아키텍처(architecture), 다른 배포 모델(deployment models), 그리고 다른 한계점(ceilings)을 가지고 있다는 점입니다. 이들 사이에서 선택하는 것은 "어느 것이 더 많은 기능을 가졌는가"의 문제라기보다 "지금 당장 당신이 실제로 해결하려는 문제가 무엇인가"의 문제입니다.

저는 약 6주 동안 스테이징(staging) 환경에서 LiteLLM을 실행했고, 병렬 워크로드(parallel workload)로 OpenRouter를 사용했습니다. 제가 실제로 발견한 내용은 다음과 같습니다.

각 도구의 정체 (중요한 아키텍처 차이점)

기능 비교에 앞서: LiteLLM과 OpenRouter는 동일한 카테고리의 제품이 아닙니다.

LiteLLM은 직접 호스팅하는 오픈 소스 Python 라이브러리이자 프록시 서버(proxy server)입니다. 100개 이상의 모델 제공업체 앞에 통합된 OpenAI 호환 API를 제공합니다. pip install로 설치하고 Docker 컨테이너로 실행하며, 여러분의 인프라 내에서 동작합니다. 가동 시간(uptime), 확장성(scaling), 그리고 설정을 여러분이 직접 관리합니다. Anthropic 및 OpenAI 자격 증명(credentials)은 여러분의 환경 내에 존재합니다. 여러분이 허용하지 않는 한 그 어떤 것도 여러분의 네트워크를 벗어나지 않습니다.

OpenRouter는 관리형 클라우드 서비스 (managed cloud service)입니다. 계정을 생성하고, 크레딧을 구매한 뒤, OpenAI SDK의 엔드포인트를 https://openrouter.ai/api/v1로 설정하고 OpenRouter API 키를 사용하면 됩니다. 여러분은 아무것도 실행할 필요가 없습니다. 모델 요청은 OpenRouter의 인프라를 통해 전달되며, 해당 모델을 제공하는 프로바이더 (provider)로 라우팅됩니다. 이들의 비즈니스 모델은 크레딧 구매 시 5.5%의 수수료를 부과하며, 프로바이더의 토큰 요율은 마진 없이 그대로 전달됩니다.

실질적인 시사점은 다음과 같습니다: 만약 여러분의 프롬프트 (prompts)가 반드시 여러분의 인프라 내에 머물러야 한다면, OpenRouter는 즉시 고려 대상에서 제외됩니다. 반면, 인프라 오버헤드 (infrastructure overhead)가 전혀 없기를 원하며 단 10분 만에 하나의 API 키로 200개 이상의 모델에 접근하고 싶다면, LiteLLM은 OpenRouter보다 설정 곡선 (setup curve)이 더 가파릅니다.

이 차이점을 이해하고 나면, 비교가 훨씬 명확해집니다.

LiteLLM: 진정으로 뛰어난 점과 한계가 드러나는 지점

잘 작동하는 부분

프로바이더 커버리지 (Provider coverage) 및 SDK 호환성. LiteLLM은 단일 OpenAI 호환 형식을 통해 OpenAI, Anthropic, AWS Bedrock, Google Vertex, Mistral, Groq, Cohere, Together AI, Ollama 등 100개 이상의 프로바이더를 지원합니다. 표준 OpenAI SDK 코드를 한 번만 작성하면, 모델 문자열 (model string)을 변경하는 것만으로 다른 프로바이더로 라우팅할 수 있습니다. 자체 호스팅 모델 (self-hosted models)을 사용하는 팀에게 이는 특히 유용한데, LiteLLM이 클라우드 프로바이더와 동일한 인터페이스로 여러분의 자체 엔드포인트 (endpoints)로 라우팅해주기 때문입니다.

배포 환경 간의 로드 밸런싱 (Load balancing). 프로바이더나 리전 (regions)에 걸쳐 동일한 모델의 여러 배포 (deployments)를 정의할 수 있으며, LiteLLM은 simple-shuffle, least-busy, latency-based, cost-based와 같이 설정 가능한 전략을 통해 이들 사이에서 로드 밸런싱을 수행합니다. 이는 클라우드와 자체 호스팅 인프라를 모두 관리하는 팀에게 적절한 수준의 제어력을 제공합니다.

키별 예산 설정이 가능한 가상 키 (Virtual keys). 각 가상 키는 고유한 예산 (budget)과 속도 제한 (rate limit)을 가질 수 있습니다. 한 명의 엔지니어가 게이트웨이 설정을 담당하는 소규모 팀에게는 이 정도면 충분합니다. 서비스별로 키를 발급하고 예산을 설정하면 끝입니다.

한계가 드러나는 지점

대규모 환경에서의 YAML (YAML at scale). LiteLLM 설정은 YAML 기반입니다. 세 개의 모델을 사용하는 1인 엔지니어에게는 괜찮습니다. 하지만 서로 다른 모델 접근 권한 요구사항을 가진 4개의 스쿼드(squad)와 40명의 엔지니어를 관리하는 플랫폼 팀에게는 이는 조정(coordination)의 문제가 됩니다. 스쿼드가 새로운 모델 라우팅 규칙(routing rule)을 필요로 할 때마다 누군가는 동일한 YAML 파일을 수정하고, 변경 사항을 테스트하고, 다시 배포해야 합니다. 저희는 일주일 사이에 두 번의 머지 충돌(merge conflict)을 겪었습니다.

SSO는 엔터프라이즈(Enterprise) 전용입니다. 저희는 Okta가 필요했습니다. 하지만 이는 엔터프라이즈 라이선스에 포함되어 있습니다. 오픈 소스 버전은 기업용 SSO를 지원하지 않습니다. 일정 규모 이상의 대부분의 조직에서 이는 선호 사항이 아닌 필수 요구사항입니다.

Redis 의존성. LiteLLM의 분산 속도 제한 (Distributed rate limiting)은 Redis를 필요로 합니다. 일반적인 운영 상황에서는 문제가 없습니다. 하지만 예외적인 상황(edge case)이 있습니다. 만약 Redis에 가용성 문제가 발생하면, LiteLLM의 속도 제한 기능이 'fail open'될 수 있습니다. 즉, 제한이 적용되지 않은 채 요청이 그대로 통과됩니다. 제어 불능 상태의 작업(runaway job) 시나리오가 발생하면, 가장 잘못된 순간에 안전망이 사라진다는 것을 의미합니다. 저희가 이를 테스트해 보았습니다. 문서에 명시된 대로 동작했는데, 이는 해당 동작이 의도된 것임을 의미하지만, 운영 환경(production)에서 이를 의존하기 전에 반드시 이해해 둘 가치가 있습니다.

팀 단위 예산 강제 (Team-level budget enforcement). 키(key)별 예산 설정은 작동합니다. 하지만 플랫폼 팀이 서로 다른 사업 부문에 비용을 청구(charge back)하기 위해 필요한 방식, 즉 공유된 상한선을 가진 여러 키에 걸친 팀 단위 예산 설정은 더 많은 설정 작업이 필요하며, 엔터프라이즈 티어(enterprise tier)에서 이를 깔끔하게 처리합니다.

가장 적합한 대상: 자체 호스팅(self-hosted) 모델 접근을 프로토타이핑하는 1인 엔지니어 및 소규모 팀. MIT 라이선스, 벤더 관계 없음, 완전한 인프라 제어 가능. SSO 및 거버넌스(governance) 기능은 엔터프라이즈 티어를 결제하면 사용할 수 있습니다. 10명 이상의 엔지니어가 이를 사용한다면 해당 비용을 예산에 반영하십시오.

OpenRouter: 진정으로 뛰어난 점과 한계가 드러나는 지점

잘 작동하는 부분

첫 요청까지 설정이 필요 없음 (Zero setup to first request). 계정을 생성하고, 크레딧을 구매하고, Base URL을 변경하면 끝입니다. 실행해야 할 인프라도, 유지 관리할 컨테이너도, 작성해야 할 YAML 파일도 없습니다. 빠른 프로토타이핑 (Prototyping)이나 해커톤 (Hackathon)을 진행할 때 적절한 노력 수준입니다.

모델의 폭 (Model breadth). 하나의 API 키로 300개 이상의 모델에 접근할 수 있습니다. Mistral, Nous, Perplexity 등 별도의 제공업체(Provider)를 통해 개별 API 계정이 필요했을 모델들도 OpenRouter를 통해 직접적인 API 접근이 용이해지기 전부터 이미 이용 가능했습니다. 최첨단 모델 (Frontier models)들을 대상으로 실험할 때 이는 진정으로 유용합니다.

지능적인 라우팅 옵션 (Intelligent routing options). OpenRouter의 라우팅 접미사 (Routing suffixes)는 훌륭한 추상화 (Abstraction)를 제공합니다: :nitro는 가장 높은 처리량 (Throughput)을 가진 제공업체로 라우팅하고, :floor는 가장 저렴한 곳으로, :online은 웹 검색 결과를 주입합니다. 또한 폴백 (Fallback) 우선순위가 포함된 models 배열을 전달할 수도 있습니다. 제공업체 선택을 고민하고 싶지 않은 팀에게는 기본 설정이 잘 작동합니다.

통합 결제 (Unified billing). 사용하는 모든 제공업체에 대해 하나의 인보이스 (Invoice)와 하나의 크레딧 잔액으로 관리됩니다. 여러 제공업체의 회계 처리가 골칫거리인 팀에게 이는 실질적인 단순화입니다.

한계가 드러나는 지점 (Where it breaks)

모든 것이 OpenRouter의 인프라에 존재합니다. 사용자의 프롬프트 (Prompt), 응답 (Response), API 키가 모두 OpenRouter의 시스템을 통과합니다. 데이터 거주성 (Data residency) 요구 사항이 있거나, 규제 대상 워크로드 (Regulated workloads), 또는 추론 데이터 (Inference data)가 이동할 수 있는 위치를 명시해야 하는 컴플라이언스 (Compliance) 의무가 있는 팀에게 이는 강력한 차단 요소 (Hard blocker)입니다. 셀프 호스팅 (Self-hosted) 옵션이나 VPC 배포 경로가 없습니다.

5.5%의 크레딧 수수료가 복리로 작용합니다. OpenRouter는 크레딧 구매 시 5.5%를 부과합니다. 제공업체의 토큰 요율은 마진 없이 그대로 전달됩니다. 사용량이 적을 때는 괜찮습니다. 하지만 월 추론 비용이 $50,000라면, 모델 비용 외에 OpenRouter에 플랫폼 수수료로 매달 $2,750를 지불하게 됩니다. 월 $200,000라면 매달 $11,000가 됩니다. 이를 프로덕션 라우팅 레이어 (Production routing layer)로 확정하기 전에 반드시 계산해 볼 가치가 있습니다.

팀 단위 거버넌스(Team-level governance) 부재. OpenRouter에는 "팀 A는 이 모델들만 사용할 수 있다"라거나 "개발자 X는 월 $500의 한도를 가진다"와 같은 개념이 없습니다. 액세스 제어(Access control)는 API 키 단위로 이루어집니다. 예산 관리(Budget management)는 계정 수준에서 이루어집니다. 개인 개발자에게는 이 방식이 괜찮을 수 있습니다. 하지만 서로 다른 액세스 요구 사항을 가진 40명의 엔지니어를 관리하는 플랫폼 팀에게는, OpenRouter로부터 거버넌스를 얻는 것이 아니라 OpenRouter 위에 별도의 거버넌스 체계를 직접 구축해야 한다는 것을 의미합니다.

자체 호스팅 모델(Self-hosted model) 지원 불가. 만약 자체 인프라에서 파인튜닝된 모델(Fine-tuned model)을 실행하고 있다면, OpenRouter는 해당 모델로 라우팅할 수 없습니다. OpenRouter(클라우드 제공업체용)와 다른 시스템(자체 모델용) 사이에서 라우팅을 분리하게 되면, 관측성(Observability), 비용 추적(Cost tracking), 거버넌스(Governance)가 모두 파편화됩니다. 저희는 이 문제를 겪었으며, 이는 생각보다 훨씬 더 심각했습니다.

가장 적합한 대상: 인프라 구축 없이 많은 모델에 빠르게 접근하고 싶은 개인 개발자 및 소규모 팀. 또한, 자체 모델을 위한 자체 호스팅 솔루션과 병행하여 클라우드 제공업체 라우팅 레이어로 사용하는 팀에게도 진정으로 유용합니다. 다만, 이 경우 두 개의 시스템을 관리해야 한다는 점을 의미합니다.

프로덕션에서 중요한 요소들에 대한 정면 비교

	LiteLLM	OpenRouter
배포 모델 (Deployment model)	자체 호스팅 (Docker, pip)	관리형 클라우드 전용
...

두 서비스의 한계에 부딪힌 후 우리가 선택한 방향

저희는 약 6주 동안 LiteLLM을 운영했습니다. YAML 설정(YAML config) 문제는 감당할 수 있는 수준이었습니다. 하지만 SSO 요구 사항은 그렇지 않았습니다. 저희는 Okta가 필요했는데, Redis의 failure-open 에지 케이스(edge case)가 여전히 존재하고 자체 호스팅 모델에 대한 네이티브 관측성(Native observability)이 없는 게이트웨이를 위해 엔터프라이즈 라이선스 비용을 지불할 수는 없었습니다.

같은 기간 동안 병렬 데이터 강화(Data enrichment) 워크로드에는 OpenRouter를 사용했습니다. 처음 두 달 동안은 매우 훌륭했습니다. 하지만 워크로드가 확장되고, 법무팀으로부터 데이터 레지던시(Data residency) 문제가 제기되었으며, 저희의 실행 속도(Run rate) 기준 5.5%의 수수료가 실제 스프레드시트 상에서 실질적인 숫자로 다가오기 시작했습니다.

두 도구 모두 틀리지 않았습니다. 둘 다 우리가 구축하던 초기 단계에는 적합했습니다. 문제는 우리가 거의 동시에 두 서비스 모두의 한계점(Ceiling)에 도달했다는 점이었습니다.

결국 저희는 TrueFoundry의 AI Gateway를 선택하게 되었습니다. 저희 상황에서 중요했던 구체적인 요소들은 다음과 같습니다:

Redis 의존성 없는 인메모리 속도 제한 (In-memory rate limiting). 인증(Auth), 예산 확인(Budget checks), 속도 제한(Rate limits)이 모두 게이트웨이 프로세스 내에서 인메모리(In-memory) 방식으로 처리됩니다. 즉, 핫 패스(Hot path)에서 외부 의존성이 없으며, Redis 부하 상황에서도 실패 허용(Failure-open)과 같은 예외 케이스가 발생하지 않습니다. 벤치마크 결과에 따르면 단일 vCPU에서 350+ RPS(초당 요청 수)일 때 약 3~4ms의 지연 시간(Latency)이 추가되었으며, 이는 저희의 자체 테스트 결과와도 일치했습니다.

전체 VPC 배포 (Full VPC deployment). 모든 것이 저희의 Kubernetes 클러스터 내부에서 실행됩니다. 추론 데이터(Inference data)나 컨트롤 플레인(Control plane) 트래픽이 저희 인프라를 벗어나지 않습니다. 이는 법적/컴플라이언스(Compliance) 문제를 깔끔하게 해결해 주었습니다.

• 인프라에 대한 완전한 제어권과 MIT 라이선스 오픈 소스 (Open Source)를 원하는 경우
• 클라우드 제공업체와 동일한 시스템을 통해 라우팅해야 하는 셀프 호스팅 (Self-hosted) 모델을 보유한 경우
• YAML 설정 (Config) 관리 및 게이트웨이 (Gateway)의 가동 시간 (Uptime)을 직접 관리하는 데 거부감이 없는 경우
• SSO 및 팀 거버넌스 (Team Governance)가 필요할 때 엔터프라이즈 라이선스 비용을 감당할 수 있는 경우

다음과 같은 경우에는 OpenRouter를 사용하세요:

• 관리할 인프라가 전혀 없고, 첫 요청까지 가장 빠른 경로를 원하는 경우
• 소규모 제공업체의 최신 모델을 포함하여 다양한 모델에 대한 접근이 필요한 경우
• 워크로드에 데이터 레지던시 (Data Residency) 또는 컴플라이언스 (Compliance) 요구 사항이 없는 경우
• 계정 수준의 빌링 (Billing)으로 충분하며, 팀별 거버넌스가 필요하지 않은 경우

다음과 같은 경우에는 두 서비스 모두를 넘어선 대안을 고려하세요:

• 법무 또는 컴플라이언스 부서에서 추론 데이터 (Inference Data)가 어디에 저장되는지 묻고, "OpenRouter의 서버"라는 답변이 허용되지 않는 경우
• 클라우드 제공업체의 트래픽과 동일한 거버넌스가 필요한 셀프 호스팅 모델을 보유한 경우
• 여러 팀이 비용을 지출한 후가 아니라, 지출하기 전에 별도의 예산 한도 (Budget Caps)를 적용받아야 하는 경우
• Redis의 페일 오픈 (Failure-open) 시나리오가 속도 제한 (Rate Limiting) SLA에 실질적인 위험이 되는 경우

LiteLLM이나 OpenRouter 중 무엇이 여러분을 선택하게 만들었나요? 그리고 무엇 때문에 계속 사용하거나 떠나게 되었나요? 두 개의 별도 관측성 스택 (Observability Stacks)을 운영하지 않고, 두 서비스 모두(LiteLLM을 통한 셀프 호스팅 + OpenRouter를 통한 클라우드)에 걸쳐 거버넌스를 통합할 수 있는 깔끔한 방법을 찾은 분이 계신가요? 댓글로 알려주세요.