일반적이고 합리적인 self-hosted 스택은 LLM gateway(예: LiteLLM)와 LLM 관측성 플랫폼(예: Langfuse)을 조합합니다. 이미 하나를 갖고 있다면, 컨트롤 플레인이 필요한지 합리적으로 의문을 가질 수 있습니다. 이 페이지는 이에 솔직하게 답합니다 — 답이 아니오인 경우를 포함하여.
TL;DR: LiteLLM과 Langfuse는 귀사의 애플리케이션이 수행하는 모델 호출에 관한 것입니다: 라우팅, 추적, 프롬프트 관리, 호출당 비용 추적. Olivares AI는 귀사 인프라의 모든 에이전트와 에이전트가 읽거나 쓰는 모든 것 — 데이터베이스, 오브젝트 스토어, MCP 서버, 도구, 파일 — 그리고 이것이 정책이 허용하는 것과 일치하는지에 관한 것입니다. 다른 고도입니다. 상호 보완됩니다; 이들이 내보내고 소비하는 동일한 OpenTelemetry gen-ai 신호를 우리도 수집합니다.
이 스택이 잘하는 것 (이 용도로 사용하십시오)
- LiteLLM — 다수 공급자 앞의 통합 OpenAI 호환 gateway: 라우팅, fallback, 재시도, 가상 키, 키별 예산 및 rate limit, 그리고 통과하는 모델 호출의 비용 회계.
- Langfuse — LLM 엔지니어링 및 관측성: 요청/응답 트레이스, 프롬프트 관리 및 버저닝, 평가, 데이터셋, 체인 디버깅을 위한 개발자 중심 UI.
문제가 *“내 앱의 LLM 호출을 계측하고, 프롬프트를 디버깅하고, 하나의 엔드포인트에서 모델 접근을 관리하는 것”*이라면, 이 스택은 훌륭하며 self-host 가능합니다. 이를 위해 컨트롤 플레인이 필요하지 않으며, 달리 가장하지 않겠습니다.
Olivares AI가 구조적으로 다른 점
| 차원 | LLM gateway + 관측성 | Olivares AI |
|---|---|---|
| 관심 단위 | 모델 호출 (prompt → completion) | 에이전트와 에이전트가 읽거나 쓰는 모든 리소스 — DB, 오브젝트 스토어, MCP, 도구, 파일 |
| 관측 지점 | 요청 경로 내 (프록시/SDK); 앱이 보내는 것을 봄 | 대역 외, read-first; 텔레메트리, 네이티브 감사, 커널 백스톱을 관찰 — 데이터 경로에 절대 위치하지 않음 |
| 진실의 원천 | 앱/프록시가 보고하는 것 | 자기 보고 텔레메트리를 시스템 자체의 원장과 대조 확인 — pgAudit(읽기 vs 쓰기), CloudTrail(오브젝트 접근), eBPF 백스톱 |
| 핵심 질문 | ”이 프롬프트가 무엇을 했고, 비용은 얼마인가?" | "이 에이전트가 아무도 부여하지 않은 접근을 사용하고 있는가?” — Permitted-vs-Observed 드리프트 |
| Enforcement | Gateway가 모델 호출을 게이트할 수 있음 (키, 예산) | 행위 및 리소스 접근에 대한 deny-closed 게이트: 승인, Claude Code hooks PEP, MCP 도구 게이팅, kill switch |
| 감사 산출물 | 디버깅용 트레이스 / 로그 | Append-only, 해시 체인, Ed25519 서명 원장, 오프박스 검증 가능, OSCAL 증거 패키지로 내보내기 가능 |
| 배포 형태 | Self-host 가능 | Self-hosted 또는 air-gapped; 데이터 플레인이 귀사의 경계를 벗어나지 않음; AGPL, source-available |
본질적인 차이는 ground truth입니다. 관측성 트레이스는 애플리케이션이 수행했다고 말한 것을 알려줍니다. 트레이스에서 언급되지 않은 테이블에 에이전트가 접근했는지는 알려줄 수 없습니다. Olivares AI는 협력적 신호를 데이터 플레인과 교차 검증하므로, “에이전트가 접촉한 것”은 자기 보고가 아닌 대조 확인된 사실입니다.
”또는”이 아닌 “그리고”입니다 — 귀사의 텔레메트리를 수집합니다
Olivares AI는 귀사의 gateway나 트레이싱 도구를 대체하지 않으며, 이들이 차지하는 요청 경로에 위치하려 하지 않습니다. 동일한 신호를 소비합니다: 컨트롤 플레인은 OpenTelemetry GenAI 시맨틱 컨벤션 스팬을 수집합니다 — 이 도구들이 내보내고 소비하는 동일한 gen-ai 텔레메트리입니다. 따라서 건전한 구성은:
- LiteLLM을 모델 gateway로, Langfuse를 개발자 중심 트레이싱 및 프롬프트 작업용으로 유지합니다.
- OTel gen-ai 스트림을 대조 소스로 Olivares AI에 전달하고, 접근 맵, 드리프트 탐지, 원장이 그 위에서 인프라 전체 거버넌스 레이어를 제공하도록 합니다.
Olivares AI에 손을 뻗지 말아야 할 경우
솔직함은 양방향으로 작동합니다. 이 컨트롤 플레인이 필요하지 않을 가능성이 높은 경우:
- 유일한 목표가 하나 또는 두 개의 앱에서 LLM 호출을 추적하고 디버깅하는 것이며, 프롬프트 플레이그라운드가 필요한 경우 — Langfuse 단독이 더 적합합니다.
- 다중 공급자 gateway와 예산 및 failover만 필요한 경우 — 이것은 LiteLLM의 역할이며, 우리는 이 패턴과 통합하지 재구현하지 않습니다.
- 거버넌스할 인프라가 없는 경우: 단일 서비스, 단일 모델, 데이터베이스/오브젝트 스토어/MCP에 접촉하는 에이전트가 없고, 감사 또는 규제 의무가 없는 경우.
Olivares AI는 질문이 인프라 전체적이고 적대적이 될 때 그 가치를 발휘합니다: 어떤 에이전트가 존재하고, 각각이 실제로 무엇에 도달할 수 있고, 접근이 정책에서 어디로 이탈하고 있고, 감사인에게 증명할 수 있고, 잘못된 행위를 deny-closed로 중단할 수 있는지 — 이 모든 것을 타사 클라우드로 보내지 않고 수행할 수 있는지.