여러분은 이미 에스테이트의 나머지 모든 것에 대한 대시보드를 운영하고 있습니다: 호스트, 큐, 데이터 스토어, 요청 경로까지 말입니다. 그러던 어느 날 십여 개의 AI 에이전트가 등장합니다 — 코파일럿, MCP 서버, 스케줄 작업, 누군가가 프로덕션에 연결해 둔 Claude Code 인스턴스 — 그리고 운영자의 첫 번째 질문에 답해 줄 단일 지점이 어디에도 없습니다: 무엇이 실행 중이고, 각각이 실제로 어디까지 도달할 수 있는가?
이것은 관리되지 않는 섀도우 인프라와 동일한 패턴이지만, 다른 점은 그 워크로드가 자격 증명을 보유하고 스스로 행동한다는 것입니다. AI 관련 침해를 겪은 조직 가운데 약 97%가 적절한 AI 액세스 제어를 갖추지 못했습니다(IBM Cost of a Data Breach 2025, Ponemon). 이제 업계에는 그 원인을 가리키는 용어가 생겼습니다 — 에이전트 스프롤(agent sprawl) — 그리고 Gartner는 에이전틱 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 것으로 전망하는데(Gartner), 그 이유는 흔히 에이전트가 늘어난 뒤에는 아무도 그것들을 안전하게 운영할 수 없었기 때문입니다.
운영자가 얻는 것
Olivares AI는 여러분의 에이전트가 실행되는 곳에서 동작하는 개방형, 셀프 호스팅 가능한 플랫폼입니다. 에이전트를 발견하고, 각 에이전트가 무엇을 건드리는지에 대한 read/write 액세스 맵을 구성하며, 그 액세스를 거버넌스하고 감사할 수 있는 제어 수단을 제공합니다. SRE나 sysadmin에게는 기능 목록보다 다섯 가지 속성이 더 중요합니다.
수동형(Passive) — 요청 경로에 끼어들지 않음
발견은 **대역 외(out of band)**에서 텔레메트리와 소스 네이티브 감사 데이터로 구성됩니다. 헬스 및 신뢰성 뷰는 인프라로 소켓을 여는 프로버가 아니라 이벤트 버스의 소비자입니다 — liveness는 관측된 활동으로부터 추론되며, 방출(emit)을 멈춘 에이전트 자체가 하나의 신호가 됩니다. Olivares는 에이전트 앞단의 프록시나 사이드카가 아니기 때문에, Olivares 장애가 에이전트를 다운시킬 수 없습니다. 인라인에 위치하는 유일한 표면은 사용자가 연결하기로 선택한 선택적 액추에이션 게이트뿐이며, 그것들은 fail closed로 동작합니다.
단일 셀프 호스팅 정적 바이너리
웹 콘솔이 내장된 단일 정적 바이너리로 배포됩니다 — 푸시해야 할 에이전트 플릿도, 돌봐야 할 컨트롤 플레인 Kubernetes 오퍼레이터도 없습니다. 스토어는 순수 Go SQLite(멀티 테넌트의 경우 Postgres)이므로, 씨름해야 할 C 툴체인이 없습니다. 파일 하나를 설치하고, 전용 서비스 사용자로 실행하면, 콕핏을 손에 넣게 됩니다. 설치 및 셀프 호스팅을 참조하십시오.
컨트롤 플레인은 여러분의 경계 안에서 실행되며 에어갭(air-gapped) 환경에서 실행할 수 있습니다 — 거버넌스 및 관측 데이터는 결코 외부로 나가지 않습니다. 운영자가 반드시 유념해야 할 한 가지 단서가 있습니다: 이것은 오프라인 AI가 아닙니다. Claude와 같은 호스팅 모델은 여전히 제공자의 API에 접근합니다. 에어갭이란 여러분의 에스테이트 데이터가 집 안에 머문다는 뜻이지, 모델이 로컬에서 실행된다는 뜻이 아닙니다. 진정으로 셀프 호스팅이 가능한 모델(vLLM, Ollama)만이 완전히 오프라인으로 동작합니다. 자세한 내용은 보안과 아키텍처를 참조하십시오.
OTel 네이티브 인제스트
인제스트 경로는 OpenTelemetry GenAI 시맨틱 컨벤션을 OCSF, SIEM 포맷,
W3C Trace Context와 함께 고정합니다 — 따라서 여러분이 이미 방출하고 있는 텔레메트리가
바로 이 시스템이 읽는 텔레메트리입니다. 솔직히 짚어 둘 경계가 하나 있습니다: Olivares는 거버넌스 대상
이벤트 원장(ledger)을 W3C trace_id로 상관 짓지만, 전체 OTel 스팬을 저장하지는 않습니다.
트레이스 뷰의 소요 시간과 상태는 재구성된 스팬 데이터가 아니라 원장 이벤트 윈도우입니다.
전체 스팬은 마땅히 있어야 할 곳, 즉 여러분 자신의 OTLP 컬렉터에 남아 있습니다. Olivares는 누가
무엇을 건드렸고 그것이 허용되었는지를 알려 줍니다 — 여러분의 트레이싱 백엔드를 대체하는 것이 아닙니다.
(LiteLLM/Langfuse 옆에서 어디에 위치하는지는 비교 페이지를 참조하십시오.)
여러분이 운영하는 여느 서비스처럼, 프로브와 헬스
이 바이너리는 여러분의 오케스트레이터가 이미 기대하는 엔드포인트를 노출합니다:
GET /livez liveness — is the process up
GET /readyz readiness — is it serving (and not a cold standby)
GET /healthz setup-exempt liveness for scrapers
GET /metrics Prometheus exposition/readyz는 백킹 스토어에 도달할 수 없을 때 멈춰 있는 대신 503을 반환하므로,
로드 밸런서가 해당 노드를 블랙홀로 만들지 않고 드레인합니다. 그 위에, 모듈 XXII는
에이전트와 MCP 서버 자체의 헬스, SLA, 가동 시간을 추적합니다 — 무엇이 정상이고, 무엇이 성능 저하 상태이며,
무엇이 무엇에 의존하는지를 추적하고 — down/degraded/recovered/SLA-breach 핀딩을 여러분의 기존 채널(Slack, PagerDuty, SIEM)로
방출합니다. 신호를 생성할 뿐, 여러분의 알림 시스템이 되려고 하지는 않습니다.
Read-first, 그리고 실제로 작동하는 에스테이트 전반 정지
Olivares는 기본적으로 탐지형(detective)이며 deny-closed입니다. 폭넓게 관측하고 거버넌스하지만, 폭넓게 액추에이트하지는 않습니다. 그러나 새벽 3시에 에이전트가 잘못 동작할 때, 운영자에게는 요란한 절차 없이 작동하는 단일 레버 하나가 필요합니다 — 그래서 킬 스위치는 실재하며 실제로 쓰이도록 만들어졌습니다:
- 작동(engage)은 비용이 낮습니다. Admin 등급, 필수 사유 하나, 클릭 한 번. 작동 시점에는 승인 게이트도, 스텝업도 없습니다 — 정족수를 기다리는 비상 정지는 정지가 아닙니다. 에스테이트 전반 범위는 해당 테넌트의 모든 거버넌스 대상 액추에이션 표면을 거부하고, 에이전트 범위는 해당 에이전트를 지명할 수 있는 모든 표면에서 정지시킵니다.
- 재활성화는 그렇지 않습니다. 정지를 해제하려면 이중 통제(dual-control)(서로 다른 두 명의 사람)가 필요하며, 그 뒤에는 관여하지 않은 제3자가 반드시 서명해야 하는 필수 사후 검토가 따릅니다. “에스테이트는 정지 상태로 유지된다”가 안전한 상태입니다.
- fail closed로 동작합니다. 모든 액추에이션 게이트는 호출마다 실시간 정지 상태를 조회하며 읽기 오류 시 거부합니다 — 읽을 수 없는 정지 상태는 결코 “통과”를 의미하지 않습니다.
범위에 대해 스스로 솔직해지십시오: 정지는 여러분이 연결한 게이트만큼만 넓습니다. Olivares가 접점(seam)을 갖지 못한 표면은 동결할 수 없습니다. 이것이 read-first 시스템의 의도된 트레이드오프이며 — 발견과 맵이 먼저 오는 이유이기도 합니다.
이것이 무엇이며 — 무엇이 아닌지
- 이것은 수동형 셀프 호스팅 콕핏입니다: 에이전트를 발견하고, 그들의 read/write 액세스를 매핑하며, 헬스를 관찰하고, 에스테이트 전반 정지를 클릭 한 번 거리에 둡니다.
- 이것은 인라인 프록시도, 트레이싱 백엔드도, 여러분의 에이전트를 조용히 재배선하는 시스템도 아닙니다. 액추에이션은 옵트인이고, 온디맨드이며, deny-closed입니다 — 여러분이 각 접점을 의도적으로 연결합니다.
- 이것은 pre-1.0이며 open-core입니다. 카탈로그에는 23개의 역량 모듈이 나열되어 있으며, 현재 약 스무 개가 연결되어 있고 나머지는 설계 단계이거나 post-v1입니다. 모듈 레퍼런스가 무엇이 라이브 상태인지 표시합니다.
- 이것은 인증을 받은 상태가 아닙니다. Olivares는 SOC 2, ISO/IEC 42001, EU AI Act를 지향하여 설계되었지만 — 해당 인증을 보유하고 있지 않으며, 보유한다고 주장하지도 않을 것입니다. 솔직한 입장은 보안을 참조하십시오.
- 충실도(fidelity)는 단계화되어 있으며 그대로 표시됩니다. Read 대 write 커버리지는 네이티브 감사를 갖춘 스토어에서는
clean, 일부 문서/벡터 스토어에서는lossy, 수동적으로 재구성할 수 없는 경우(Redis, SQLite, D1)에는unknown입니다. 에이전트별 귀속(attribution)은 신호가 뒷받침할 때만firm이고, 공유 계정 뒤에서는approximate입니다. 추측하는 것은 아무것도 없습니다. 충실도를 참조하십시오.