이미 AI gateway나 하이퍼스케일러의 Guardrails에 투자하셨다면, 가장 먼저 솔직하게 말씀드려야 할 것은 그대로 유지하십시오. Olivares AI는 이를 대체하려는 것이 아닙니다. Gateway의 역할은 모델 호출 — 라우팅, 캐싱, 밸런싱, 예산 관리입니다. Guardrails의 역할은 해당 호출에 대한 콘텐츠 안전성입니다. 둘 다 실질적이고, 둘 다 자신의 영역에서 뛰어나며, 둘 다 Olivares가 하는 일이 아닙니다.
TL;DR: Olivares AI는 범용 AI 게이트웨이가 아닙니다. 모델 트래픽을 캐싱하거나 로드 밸런싱하지 않으며, 공급자·모델·라우팅의 보편적 매트릭스를 주장하지 않습니다. 라우팅 정책을 순서가 정해진 폴백 체인으로 해석하고, 측정된 실행 경로 하나를 가집니다. deny-closed이며 사용자가 구성한 Claude Messages 호환 클라이언트를 통해서만 동작합니다(직접 또는 게이트웨이 엔드포인트를 Messages 기본 URL로). 그 경로를 넘어서면 거버넌스와 증적 플레인입니다. 에이전트 런타임 내 인프로세스 시행, 변조 탐지 가능한 원장, 비인간 아이덴티티 수명주기, 그리고 활성 세션에 대한 human-in-the-loop / break-glass / kill-switch. 이미 운영 중인 게이트웨이를 대체하지 않고 함께 구성됩니다.
이 페이지는 두 범주가 전혀 겹치지 않는다고 서술했습니다. 이제는 양방향 모두 정확하지 않습니다. 여러 게이트웨이가 자체 에이전트 표면을 문서화하고 있으며, Olivares에도 좁고 측정된 실행 경로가 있습니다. 제품별 상세 내용은 인용과 열람 날짜와 함께 영어판이 정본입니다.
Gateway와 Guardrails가 잘하는 것 (이 용도로 사용하십시오)
이것들은 표준화되어 잘 알려진 기능이며, 벤더들이 명확하게 설명합니다:
- AI gateway는 모델 호출을 위한 요청 경로 관리자입니다. LiteLLM은 “OpenAI Proxy Server (LLM Gateway) to call 100+ LLMs in a unified interface & track spend, set budgets per virtual key/user” (LiteLLM); Cloudflare AI Gateway는 “Connect to any model, dynamically route requests, and manage usage, billing, and logs from one unified gateway” (Cloudflare); Portkey는 “records real-time API requests, including cost” (Portkey)를 제공합니다. 라우팅, fallback, 캐싱, 가상 키, 키별 예산, 요청 로깅 — 이것이 이들의 영역입니다.
- 하이퍼스케일러 Guardrails는 콘텐츠 안전 필터입니다. Bedrock Guardrails는 *“provides configurable safeguards to help you build safe generative AI applications”*이며 “detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses” — 콘텐츠 필터, 거부 주제, 단어 필터, PII 마스킹, 맥락 기반 그라운딩 및 자동 추론 검사를 수행합니다 (AWS).
문제가 *“여러 모델에 하나의 엔드포인트를 제공하되, 예산, 캐싱, 콘텐츠 필터링을 갖추는 것”*이라면, 이 스택으로 해결되며 컨트롤 플레인이 필요하지 않습니다. 우리는 이 패턴과 통합하지, 재구현하지 않습니다.
각 제품이 현재 문서화하는 내용
2026-09-12에 각 공급사 자체 페이지에서 확인했습니다. 읽은 페이지의 범위이며, 제품 전체에 대한 주장도 순위도 아닙니다.
| 제품 | 문서화된 에이전트 관련 표면 | 해당 페이지가 다루지 않는 범위 |
|---|---|---|
| LiteLLM | 프록시 문서에 다음 섹션이 있습니다: “Agent & MCP Gateway”, 그리고 Guardrails, Policies, Authentication, Budgets + Rate Limits; “Scoped per user and team, with built-in access control” (LiteLLM) | 읽은 페이지는 프록시 표면을 문서화합니다. 프록시를 거치지 않는 에이전트 런타임 내부의 시행은 그 범위 밖입니다 |
| Portkey | 제품 목록에 다음이 포함됩니다: Agents, MCP Gateway, Guardrails, Security & Compliance; “records real-time API requests, including cost and guardrail violations” (Portkey) | 읽은 페이지는 기능 개요입니다. 자산 전반의 허용 대 관측 접근 지도는 설명하지 않습니다 |
| Cloudflare AI Gateway | ”An intelligent control plane for your AI applications” — “Connect to any model, dynamically route requests, and manage usage, billing, and logs”, “fallback routing, rate limiting, and safety guardrails” (Cloudflare) | 읽은 페이지는 제품 개요입니다. 해당 플레인의 자체 호스팅이나 에어갭 운영은 설명되어 있지 않습니다 |
| Bedrock Guardrails | ”configurable safeguards” — “detect and filter undesirable content and protect sensitive information”, 인라인으로 사용하거나 “directly through the ApplyGuardrail API without invoking the foundation models” (AWS, AWS) | 콘텐츠 안전 페이지입니다. 에이전트 아이덴티티 수명주기, 세션 중 개입, 승인은 주제가 아니며 문서화되어 있지 않습니다 |
따라서 이전 서술은 틀렸습니다. “게이트웨이는 에이전트를 보지 못한다”는 위 페이지들 앞에서 성립하지 않습니다. LiteLLM과 Portkey는 에이전트와 MCP 표면을 문서화하고, Cloudflare는 자사 게이트웨이를 컨트롤 플레인이라 부릅니다. 남는 차이는 어디서 시행되고 어떤 종류의 기록이 남는가이며, 이는 부재 주장이 아니라 아키텍처 비교입니다.
아키텍처가 여전히 다른 지점
보편적이 아니라 조건부입니다. 각 행은 왼쪽 조건이 성립할 때 적용됩니다.
| 에이전트가… | 요청 경로 제품은 | Olivares AI는 |
|---|---|---|
| …프록시를 통해서만 모델에 도달한다 | 보이는 모든 호출을 요청 시점에 통제합니다 | 요청 경로 자체에는 거의 더하지 않습니다 |
| …로컬에서도 실행되어 DB, 오브젝트 스토어, MCP, 파일에 직접 도달한다 | 거치지 않는 호출은 볼 수 없습니다 | 도구 실행 전에 에이전트 내 프로세스 안에서 deny-closed로 시행합니다 |
| …감사자가 외부에서 검증할 수 있는 기록이 필요하다 | 요청 로그를 남기며, 이는 변경 가능한 기록입니다 | 추가 전용, 해시 체인, Ed25519 서명 원장으로 외부 검증이 가능합니다 |
| …세션 중간에 중지되어야 한다 | 활성 세션을 멈추는 지점이 아닙니다 | HITL 승인, break-glass, 이중 통제 재활성화가 있는 kill switch |
| …전체 수명 동안 식별되어야 한다 | virtual key는 예산 항목입니다 | 비인간 아이덴티티 수명주기: 노후화 차단, 오프보딩 연쇄, 이중 통제 교체 |
| …경계 안에 머물러야 한다 | SaaS 플레인은 그 트래픽을 자사 클라우드에서 처리합니다 | 자체 호스팅 또는 에어갭. 데이터 플레인은 경계를 벗어나지 않습니다 |
Olivares 실행 경로와 실제 한계
Olivares는 추론에 관여합니다. 단 측정된 한 지점에서만이며, 정직한 설명은 현재 측정 자체가 담고 있는 내용입니다.
- 경로
POST /routing-policies/{id}/execute는 구조적으로 deny-closed이며, Claude Messages 호환 클라이언트를 통해서만 동작합니다. 직접 또는 해석된 게이트웨이 엔드포인트를 Messages 기본 URL로 사용할 수 있으므로, 기존 게이트웨이가 그 엔드포인트가 될 수 있습니다. - 정책 해석은 순서가 정해진 폴백 체인을 만듭니다. 모듈은 항상 경로를 해석하고 executor 포트를 통해서만 동작하며, 기본 executor는 연결되어 있지 않아 운영자가 구성할 때까지 공급자 호출 없이 라우팅이 해석됩니다.
- 두 개의 deny-closed 범위 게이트와 kill-switch 중지 게이트가 FinOps 예산 게이트 앞에서 실행되고, 예산 게이트는 executor 앞에서 실행됩니다.
그리고 같은 기록의 표현으로, 명시적으로 성립시키지 않는 것은 다음과 같습니다.
- 공급자나 모델의 보편적 매트릭스 없음 — Claude Messages 프로토콜은 구성된 하나의 경로를 성립시키며 매트릭스가 아닙니다.
- 중앙 집중식 키 보관 없음 — 공급자 키 필드는 참조입니다.
- 콘솔에서의 실행 없음 — 콘솔은 정책을 해석하고 테스트하며 실행 호출이 없습니다.
이것은 현재 소스에 대한 측정이며 기능 승인이 아닙니다. 현행 클레임 기록은 이 기능을 포함한 모든 기능을 구현됨 및 미승인 상태로 두며, 실행 영수증은 없습니다. 인증된 기능이 아니라 경로의 형태로 읽어 주십시오.
Guardrails에 대해 구체적으로: 콘텐츠 안전은 hook이지, 경쟁자가 아닙니다
Bedrock Guardrails는 두 가지 방식으로 적용할 수 있습니다 — Bedrock 추론 호출 중
인라인으로, 또는 *“directly through the ApplyGuardrail API without invoking the
foundation models”*로, 이는 *“with any foundation model whether hosted on Amazon
Bedrock or self-hosted models”*에서 작동합니다
(AWS). 이는 진정으로 유용하며,
Olivares는 콘텐츠 안전을 플러그인하는 검출기로 취급합니다. Guardrails
대신에 선택하라고 요구하는 벽이 아닙니다. 두 가지 솔직하고 구별되는 사실:
- 인라인 추론 프록시는 **콘텐츠 검사 심(seam)**을 노출합니다 — 콘텐츠 / DLP 검출기가 판정을 반환하면 deny-closed 결정기가 이에 따라 행동하는 플러그 가능 지점입니다. 콘텐츠 안전은 경쟁 필터로 재구현되는 것이 아니라 파이프라인의 그 자리에 속합니다.
- Olivares는 귀사의 Guardrails가 내린 자체 결정을 read-first로 읽어들입니다.
AWS 커넥터는 Bedrock guardrail 결정을 CloudWatch / S3 로그에서 포스처와 증거로
수집합니다; 의도적으로 유료
ApplyGuardrail런타임 자체를 호출하지 않습니다. 귀사의 콘텐츠 판정은 변조 방지 기록의 일부가 됩니다.
따라서 콘텐츠 안전은 이미 운영 중인 것과 조합됩니다. Guardrails가 문서화하지 않는 것 — 그리고 거버넌스 격차가 열려 있는 곳 — 은 에이전트 수명의 나머지입니다: Bedrock 페이지는 에이전트 신원, 세션 관리, 인간 승인, 비용 거버넌스를 문서화하지 않습니다(해당 페이지에서 미문서화, 2026-09-12 확인). Olivares는 정확히 그 보완재입니다: 신원, 세션 제어, 승인, 증거를 담당하며; 콘텐츠 필터는 이미 있는 곳에 머무릅니다.
구성 방법
건전한 구성은 각 도구를 자신의 영역에 유지합니다:
- 귀사의 gateway를 유지하십시오 (LiteLLM / Portkey / Kong / Cloudflare) — 모델 호출 플레인으로서 라우팅, 캐싱, 가상 키, 요청에 대한 예산을 담당합니다.
- 귀사의 Guardrails를 유지하십시오 (Bedrock / Azure Content Safety) —
콘텐츠 안전 검출기로서, Olivares PEP는 콘텐츠 검사 심에서 플러그 가능 검출기를
실행하고 귀사의 Guardrails 자체 결정을 read-first로 증거로 읽어들입니다;
ApplyGuardrail을 자체적으로 호출하지 않습니다. - Olivares를 그 옆에 추가하십시오 — 거버넌스 및 증거 플레인으로서: 귀사의 gateway를 경유하지 않는 에이전트에 대한 인프로세스 PEP, 전체 인프라에 걸친 접근 맵, 변조 방지 원장, 그리고 라이브 HITL/break-glass/kill 제어를 제공합니다.
Olivares가 추론에 관여하는 유일한 지점은 좁고 명시적입니다 — 원시 SDK/curl
호출자를 위한 API-key 전용 gateway 경로이며,
구독 인증 에이전트 거버넌스에
설명되어 있습니다. 귀사의 다른 도구가 도달할 수 없는 트래픽을 거버넌스하기
위해 존재하며, 라우팅에서 경쟁하기 위해 존재하지 않고, 절대로 구독
자격 증명을 전송하지 않습니다.
귀사의 gateway로 충분한 경우
솔직함은 양방향으로 작동합니다. 귀사의 에이전트가 모두 gateway를 통해서만 모델을 호출하고, 콘텐츠 안전 요구가 Guardrails로 충족되며, 데이터베이스 / 오브젝트 스토어 / MCP에 직접 접근하는 self-hosted 또는 노트북 에이전트가 없고, 주권 또는 변조 방지 증거 요건이 없다면 — 귀사의 gateway와 해당 로그, 그리고 Guardrails만으로 충분할 수 있으며, 컨트롤 플레인을 그 자체로 추가할 필요가 없습니다.
Olivares는 질문이 인프라 전체적이고 적대적이 될 때 그 가치를 발휘합니다: 어떤 에이전트가 존재하고 각각이 실제로 무엇에 접근했는지, 잘못된 행위를 에이전트 단에서 deny-closed로 중단할 수 있는지, 위험한 행위를 누가 승인했는지, 감사인에게 불변의 증거를 전달할 수 있는지 — 이 모든 것을 타사 클라우드로 보내지 않고 수행할 수 있는지. 인접한 두 비교의 심층 분석은 vs AI control towers 및 vs LLM observability를 참조하십시오.