패시브 디스커버리는 프록시가 잡아낼 만한 것을 놓치지 않습니까?

완전히 협조적인 경로에서는 두 방식이 사실상 같은 결과로 수렴합니다. 프록시는 자신이 종단하는 흐름의 모든 바이트를 볼 수 있는 반면, 패시브 디스커버리는 에이전트나 그 호스트가 방출하는 텔레메트리와 감사 추적에 의존합니다. 격차는 거의 아무것도 방출하지 않는 비협조적 경로에서 나타납니다. 바로 그 지점을 위해 eBPF 커널 백스톱이 존재합니다. 소켓이나 파일을 건드리는 syscall은 애플리케이션이 무엇을 로깅하기로 선택했든 관계없이 관측 가능합니다. 증거가 빈약한 곳에서는 액세스 맵이 해당 엣지를 귀속(attributed)이 아니라 근사(approximate)로 표시하므로, 신뢰도가 낮은 관측이 결코 확실한 사실인 양 포장되지 않습니다.

컬렉터가 장애를 일으키면 제 에이전트가 망가집니까?

아닙니다. 패시브 컬렉터는 설계상 요청 경로 바깥에 있습니다. OpenTelemetry, 네이티브 감사 추적, 커널 신호를 대역 외(out-of-band)로 읽을 뿐이며, 에이전트의 트래픽을 종단하거나 전달하지 않습니다. 컬렉터가 멈추더라도 에이전트는 이전과 똑같이 계속 동작합니다. 잃는 것은 컬렉터가 복구될 때까지의 최신 가시성일 뿐, 운영 환경 자체가 아닙니다. 데이터 경로에 상방 리스크가 없는 이 비대칭성이야말로 읽기 우선(read-first) 수집의 핵심입니다.

패시브 디스커버리 vs 프록시: 데이터 경로에 끼어들지 않고 AI 에이전트 인벤토리 구축하기

대부분의 팀은 같은 불편한 사실을 같은 순서로 발견합니다. 먼저, AI 에이전트가 이미 자사 인프라 전반에 걸쳐 모델을 호출하고, MCP 서버를 열고, 데이터베이스와 객체 스토리지에 손을 뻗으며 동작하고 있다는 사실을 깨닫습니다. 그다음 이를 인벤토리로 정리하려다 그런 목록이 아예 없다는 것을 알게 됩니다. 독립 업계 조사(CSA/Token, n=418)는 이 격차에 수치를 부여합니다. 조직의 약 82%가 자신도 모르는 사이에 에이전트를 운영하고 있으며, 실시간 인벤토리를 유지하는 곳은 약 21%에 불과합니다. 이 모든 것을 거버넌스하려면, 그 전에 먼저 볼 수 있어야 합니다. 문제는 상황을 더 나쁘게 만들지 않으면서 어떻게 그 가시성을 확보하느냐입니다.

솔직한 답은 두 가지이며, 둘은 리스크 스펙트럼의 양 끝에 자리합니다.

에이전트를 들여다보는 두 가지 방법

첫 번째는 인라인 프록시입니다. 에이전트의 트래픽을 여러분이 통제하는 컴포넌트를 통해 라우팅하고, 모든 요청과 응답이 그 컴포넌트를 통과하므로 실시간으로 보고, 형태를 다듬고, 차단할 수 있습니다. 이는 정당하고 강력한 설계입니다. 오늘날 상당수의 이그레스 필터링, 시크릿 브로커링, 요청 수준 정책이 이 방식으로 시행됩니다.

두 번째는 패시브 디스커버리입니다. 흐름 안에 서는 대신 곁에서 관측합니다. 에이전트가 이미 방출하는 OpenTelemetry, 에이전트가 건드리는 시스템의 네이티브 감사 추적(PostgreSQL pgAudit, AWS CloudTrail 같은 클라우드 감사 로그, Kubernetes 감사), 그리고 그라운드 트루스 백스톱으로서 eBPF를 통한 커널 수준 신호를 활용합니다. 연결을 결코 종단하지 않습니다. 무슨 일이 일어났는지 지켜보고, 누가 무엇을 건드렸는지 재구성합니다.

여기서 중요한 차이는 각 방식이 최선의 경우에 얼마나 많이 볼 수 있느냐가 아닙니다. 가시성 계층 그 자체가 장애를 일으켰을 때 무슨 일이 벌어지느냐입니다.

폭발 반경이 진짜 축이다

인라인 프록시는 구조상 데이터 경로 안에 있습니다. 이는 실시간 통제를 제공하지만, 그 대가로 공유 장애 모드를 떠안게 됩니다. 프록시가 느리면 에이전트도 느려집니다. 프록시가 쓰러지면 안전한 기본값은 보통 페일 클로즈(fail closed), 즉 에이전트가 멈추는 것이거나, 페일 오픈(fail open), 즉 가장 나쁜 순간에 통제가 조용히 사라지는 것입니다. 어느 쪽이든 가시성 컴포넌트가 이제 운영 환경과 폭발 반경을 공유하게 됩니다. 또한 모든 호출에 지연(latency) 한 홉을 추가하며, 누군가가 크리티컬 패스 위에서 운영하고, 스케일링하고, 패치해야 하는 배포 표면을 더합니다.

패시브 디스커버리는 정반대의 프로필을 가집니다. 컬렉터는 대역 외(out-of-band)이며 읽기 우선(read-first)입니다. 텔레메트리, 감사 추적, 커널 이벤트를 읽을 뿐, 에이전트의 트래픽을 전달하거나 재작성하지 않습니다. 컬렉터가 성능 저하를 겪거나 죽더라도 요청 경로에서는 아무것도 변하지 않습니다. 복구될 때까지 잃는 것은 최신 가시성일 뿐이며, 처리량도 가용성도 아닙니다. 읽기 우선, 낮은 비대칭 리스크가 실무에서 의미하는 바가 바로 이것입니다. 오직 지켜보는 것만이 임무인 대상으로부터 운영 환경에 가해지는 상방 리스크가 존재하지 않는다는 뜻입니다.

	인라인 프록시	패시브 디스커버리
위치	데이터 경로 안	대역 외, 경로 곁
실시간 차단	네이티브 지원	액세스 포인트에서의 시행 필요
추가 지연	있음, 모든 호출마다	없음
장애 시	에이전트가 멎거나 통제가 사라짐	가시성이 낡아짐; 에이전트는 영향 없음
사일런트 경로 커버리지	높음(흐름을 종단함)	방출 신호 + eBPF 백스톱에 의존

제품의 입장이 “프록시는 쓸모없다”가 아니라 **필수 프록시 없음(no mandatory proxy)**인 이유가 바로 이것입니다. 인라인 컴포넌트가 정답인 경로가 있고, 둘은 함께 구성될 수 있습니다. 그러나 인벤토리 대상을 결코 다운시켜서는 안 되는 부분인 디스커버리는, 크리티컬 패스에 갖다 붙이기에 잘못된 작업입니다.

솔직하게 말하는 트레이드오프

패시브 디스커버리에는 진짜 약점이 있으며, 이를 모른 척하는 것이야말로 설계를 조용히 불신받게 만드는 종류의 허수아비 논법입니다. 흐름을 종단하는 프록시는 그 흐름의 모든 바이트를 봅니다. 패시브 컬렉터는 에이전트, 그 런타임, 또는 리소스가 방출하기로 선택한 것만 봅니다. 거의 로깅하지 않고 쓸 만한 텔레메트리도 방출하지 않는 완전히 비협조적인 경로에서는 애플리케이션 수준의 디스커버리가 얇아집니다. 무언가 일어났다는 것은 추론할 수 있지만, 귀속(attribution)은 더 어려워집니다.

두 가지가 이를 치명적이지 않은, 솔직한 상태로 유지합니다.

첫 번째는 eBPF 커널 백스톱입니다. 애플리케이션 로그는 불완전하거나, 지연되거나, 적대적인 경우에는 의도적으로 억제될 수 있습니다. 하지만 커널에게 syscall을 잊어달라고 정중히 부탁할 수는 없습니다. 데이터베이스로 소켓을 여는 에이전트나 파일을 쓰는 에이전트는 자신의 로깅이 무엇을 기록하기로 선택했든 관계없이 syscall 경계에 흔적을 남깁니다. 이것이 eBPF를 우회 방지(anti-evasion) 그라운드 트루스로 만듭니다. 상위 수준 신호가 서로 어긋나거나 침묵할 때, 커널 관점이 이를 교차 검증하는 계층이 됩니다. readOnlyHint나 destructiveHint 같은 MCP 도구 어노테이션이 힌트로서는 유용하지만 MCP 스펙에 따라 신뢰할 수 없는(untrusted) 것으로 취급되는 이유도 바로 이것입니다. 읽기 전용이라고 주장하면서 실제로는 쓰기를 하는 것이 관측된 도구야말로, 정확히 드러내야 할 불일치입니다. 그리고 그 주장을 실제로 일어난 일과 교차 검증해야만 이를 잡아낼 수 있습니다.

두 번째는 솔직한 신뢰도 수준입니다. 모든 관측이 같은 무게를 가질 자격이 있는 것은 아니므로, 액세스 맵은 그런 척하지 않습니다. 커널 신호와 일치하는 감사 항목으로 뒷받침되는 엣지는 *귀속(attributed)*으로 표시됩니다. 부분적인 텔레메트리에서 추론된 엣지는 *근사(approximate)*로 표시됩니다. 제품은 추측을 사실로 둔갑시키지 않습니다. 리뷰어는 각 행을 얼마나 신뢰해야 하는지를 한눈에 알아볼 수 있어야 합니다.

관측에서 중요한 차이(diff)로

디스커버리는 입력일 뿐입니다. 출력은 정책이 허용하는 것인 PERMITTED와 컬렉터가 실제로 본 것인 OBSERVED 사이의 비교입니다. 그 차이가 곧 최소 권한 드리프트(least-privilege drift)이며, 가장 두드러진 사례는 정책이 부여한 적도 없고 아무도 검토하지 않은, 관측된 쓰기입니다.

액세스 피드에서 가져온 몇 줄이 이를 구체적으로 보여줍니다. 읽기는 일상적이고, 플래그가 붙은 쓰기가 핵심 이야기입니다.

agent             action  resource                outcome   confidence
data-export-job   READ    s3://billing-exports    allowed   attributed
data-export-job   READ    prod-postgres           allowed   attributed
data-export-job   WRITE   prod-postgres           flagged   attributed
support-rag       READ    internal-wiki-mcp       allowed   approximate

익스포트 작업이 운영 데이터베이스를 읽는 것은 특별할 게 없습니다. 정책이 오직 읽기만 부여했는데 같은 작업이 거기에 쓰기를 한다면, 이는 검토 없이 결코 통과되어서는 안 되는 종류의 엣지입니다. 이 쓰기는 커널 경계에서 교차 검증되었으므로 어물쩍 넘긴 추정이 아니라 귀속(attributed)으로 표시됩니다.

드리프트를 보는 것은 작업의 절반이고, 그것을 닫는 것이 나머지 절반입니다. 시행은 액세스 포인트에 속하며, 코드형 정책(policy-as-code)으로 표현되어야 합니다. 그래야 규칙이 검토 가능하고, 위반이 단순히 로깅되는 데 그치지 않고 실제로 조치됩니다.

policy "data-export-readonly" {
  agent        = "data-export-job"
  resource     = "prod-postgres"
  allow        = ["read"]
  deny         = ["write"]
  on_violation = "block + alert"
}

패시브 디스커버리는 허용되지 않은 쓰기를 찾아내고, 정책은 에이전트를 최소 권한으로 다시 고정하여 다음 쓰기를 차단합니다. 가시성과 통제는 별개의 관심사로 유지되며, 바로 그렇기 때문에 디스커버리 계층이 읽기 우선이어도 무방한 것입니다.

핵심 정리

AI 에이전트에 대한 가시성은 기능 결정이기 이전에 리스크 결정입니다. 인라인 프록시는 운영 환경과 폭발 반경을 공유하는 대가로 실시간 통제를 제공합니다. 패시브 디스커버리는 사일런트 경로에서 일부 도달 범위를 포기하는 대신 결코 운영 환경을 다운시킬 수 없으며, 그렇게 포기한 도달 범위의 대부분을 eBPF 그라운드 트루스 백스톱과, 실제로 본 것에 대해 솔직함을 유지하는 신뢰도 수준으로 메웁니다. 오직 지켜보는 것만이 임무인 계층인 인벤토리에게, 그 비대칭성은 올바른 기본값입니다.

컬렉터, 액세스 맵, 감사 원장이 어떻게 맞물리는지 전체 그림을 보고 싶다면, 아키텍처 개요가 처음부터 끝까지 안내합니다.