AI 에이전트 관측성: 보이지 않는 것을 모니터링하는 방법

Anthropic이 Claude Desktop에 Cowork라는 기능을 출시했습니다. 이 기능은 모든 macOS 설치본에 10GB 가상 머신 번들을 생성했습니다. Cowork를 한 번도 활성화한 적 없는 사용자에게도 VM이 만들어졌고, 이를 삭제한 사용자는 VM이 다시 생성되는 것을 지켜봐야 했습니다. 한 사용자는 번들이 21GB까지 커졌다고 보고했습니다. 이 GitHub 이슈는 Anthropic이 문제를 인정하기 전까지 Hacker News에서 345포인트와 175개의 댓글을 모았습니다.¹

디스크 공간이 바닥날 때까지 아무도 눈치채지 못했습니다.

AI 에이전트 관측성이란 무엇일까요? 에이전트 관측성은 자율 에이전트가 런타임에 무엇을 소비하고 무엇을 실행하는지 모니터링하는 실천을 말합니다. 여기에는 세 가지 계층이 필요합니다. 리소스 계측(세션별 디스크, 메모리, CPU, 네트워크), 정책 적용(각 도구 호출 시점의 허용/거부 규칙), 그리고 런타임 감사(실제 동작을 커널 수준에서 기록하는 것)입니다. 이 세 가지가 모두 갖춰지지 않으면 운영자는 드리프트를 감지할 수도, 범위를 강제할 수도, 사고를 재구성할 수도 없습니다.

요약

에이전트 도구는 이제 운영자의 가시성 없이 컴퓨팅 리소스(디스크, 메모리, CPU, 네트워크)를 할당합니다. Anthropic의 Cowork VM은 눈에 보이는 사례이고, 모든 MCP 도구 호출과 생성되는 모든 하위 에이전트, 모든 웹 요청은 보이지 않는 사례입니다. 에이전트를 통제하려면 세 가지 관측성 계층이 필요합니다. 리소스 계측(무엇을 소비했는가?), 정책 적용(무엇이 허용되었는가?), 런타임 감사(실제로 무엇을 했는가?)입니다. 정책 계층과 감사 계층을 다루는 오픈소스 프로젝트가 두 개 있지만(mcp-firewall과 Logira), 세 계층을 모두 아우르는 프로덕션 도구는 없습니다. 아래에서는 가시성 문제, 3계층 스택, 각 계층이 잡아내는 것, 그리고 오늘 바로 구현할 수 있는 최소한의 모니터링 훅을 다룹니다.

가시성 문제

전통적인 소프트웨어는 운영자가 직접 긋기로 선택한 관측성 경계선 아래에서 동작합니다. 웹 서버가 액세스 로그를 남기는 것은 엔지니어가 로깅을 설정했기 때문입니다. 데이터베이스가 느린 쿼리를 추적하는 것은 누군가 log_min_duration_statement를 설정했기 때문입니다. 세분화 수준을 결정하는 쪽은 운영자였습니다.

에이전트 시스템은 이 관계를 뒤집습니다. 무엇을 실행할지 런타임에 결정하는 쪽은 에이전트입니다. “로그인 엔드포인트를 고쳐줘”라는 지시를 받은 코딩 에이전트는 47개의 파일을 읽고, 12개에 쓰고, 하위 에이전트 세 개를 생성하고, 웹 페이지 두 개를 가져오고, bash 명령 15개를 실행할 수 있습니다. 이 동작 하나하나가 리소스를 소비합니다. 그런데 그 소비 가운데 어느 것도 전통적인 모니터링에는 드러나지 않습니다.

Cowork 사고는 이 역전을 인프라 수준에서 드러냈습니다. Claude Desktop은 10GB의 디스크 공간을 할당했고, 유휴 상태에서 CPU를 24~55% 사용했으며, 8GB 머신에서 스왑인을 2만 회에서 2만 4천 회 이상으로 끌어올렸습니다.¹ 사용자들이 이 리소스 소비를 알아챈 경로는 Anthropic의 텔레메트리가 아니라 macOS의 저장 공간 경고였습니다. 애플리케이션은 VM 할당에 대해 대시보드도, 계측기도, 옵트인 고지도 제공하지 않았습니다.

이 패턴은 가정이 아닙니다. 2026년 3월, 한 개발자가 Claude Code가 실행한 Terraform 명령이 프로덕션 데이터베이스를 파괴했다고 보고했습니다. 에이전트는 프로덕션 state 파일을 대상으로 terraform apply를 실행했습니다. 확인 프롬프트는 나타나지 않았고, 명령을 가로챈 훅도 없었습니다. 개발자는 애플리케이션이 오프라인이 된 뒤에야 파괴 사실을 알게 되었습니다. 이 사고는 Hacker News에서 142포인트와 158개의 댓글을 모았습니다.¹² 며칠 뒤에는 또 다른 개발자가 2년 반치 레코드에 해당하는 데이터베이스 스냅샷을 포함해 프로덕션 환경 전체를 Claude Code가 삭제했다고 보고했습니다.¹³ 두 사고의 근본 원인은 같습니다. 피해가 돌이킬 수 없게 되기 전까지 에이전트가 무엇을 하고 있는지에 대한 가시성이 전혀 없었다는 점입니다.

이 패턴을 에이전트 세션 규모로 확장해 봅시다. 제 훅 오케스트레이션 시스템은 Claude Code의 훅 인프라 위에 구축되어 모든 도구 호출에 걸쳐 15가지 이벤트 유형을 가로챕니다.¹¹ 60회의 세션 동안 이 시스템은 각 동작마다 84개의 훅이 발화한 것을 기록했고, 기본 에이전트 설치로는 얻을 수 없는 텔레메트리를 만들어냈습니다.² 그런 계측이 없었다면 제 NIST 공개 의견서에 기록한 12건의 드리프트 사고, 유령 검증 실패, 재귀적 생성 루프를 저는 발견하지 못했을 것입니다.³

DORA의 2024년 Accelerate State of DevOps Report는 관측성 실천이 탄탄한 팀일수록 더 자주 배포하고 장애에서 더 빨리 회복한다는 사실을 밝혔습니다. 2025년판은 이 프레임워크를 AI 지원 개발로 확장해, 관측성을 “AI 지원 코딩이나 테스트가 품질, 리드 타임, 전반적인 신뢰성에 어떤 영향을 미치는가”와 연결합니다.⁴ 에이전트 관측성은 있으면 좋은 기능이 아닙니다. 에이전트의 동작을 측정하는 일은 이를 통제하기 위한 전제 조건입니다.

에이전트 가시성의 세 계층

에이전트 관측성에는 서로 독립적인 세 계층이 필요합니다. 각 계층은 서로 다른 질문에 답합니다. 한 계층이 실패해도 나머지 계층은 손상되지 않습니다.

이 계층들은 하나의 진행 순서에 대응합니다. 측정하지 않은 리소스에 정책을 강제할 수 없고, 정의한 적 없는 정책의 준수 여부를 감사할 수 없습니다. 각 계층은 그 아래 계층 위에 세워집니다.

1계층: 리소스 계측

리소스 계측은 에이전트가 얼마나, 그리고 어디에서 소비했는가라는 질문에 답합니다.

Cowork 사고는 리소스 계측의 실패였습니다. VM 번들은 10GB의 디스크 공간을 소비했습니다. 렌더러 프로세스는 유휴 상태에서 CPU를 24% 사용했습니다. 스왑 활동은 세션 중에 꾸준히 늘어났습니다. 이 지표들은 모두 macOS 활성 상태 보기에 존재했습니다. 그러나 그중 어느 것도 Claude Desktop의 인터페이스에는 나타나지 않았습니다.¹

에이전트 코딩 세션에서 리소스 계측은 네 가지 차원을 추적합니다.

디스크. 모든 파일 쓰기, 모든 캐시 항목, 모든 로그 파일입니다. 제 세션은 세션당 200~400KB의 상태 파일(jiro.state.json, jiro.progress.json, 훅 로그)을 생성합니다. 60회 세션이면 12~24MB의 상태 데이터가 쌓이고, 명시적으로 정리하지 않는 한 세션이 끝나도 계속 남아 있습니다.²

메모리. 턴당 컨텍스트 윈도 소비량입니다. 20만 토큰 컨텍스트 윈도를 현재 Opus 가격으로 가득 채우면 약 3달러가 듭니다. 제 비용 추적기는 설정 가능한 한도의 80%, 90%, 95%에 예산 임계값을 두고 세션별 누적 토큰 사용량을 기록합니다.⁵

CPU. 훅 실행 시간입니다. 아홉 개의 훅으로 구성된 제 프롬프트 디스패처는 프롬프트당 200ms를 더합니다. 이 오버헤드는 사용자에게는 보이지 않지만(사람의 타이핑이 병목이기 때문입니다) 자동화된 파이프라인에서는 누적됩니다. ralph 자율 루프는 스토리마다 디스패처를 50~100회 발화시켜 스토리당 10~20초의 훅 오버헤드를 더합니다.²

네트워크. 웹 요청, API 호출, MCP 도구 호출입니다. 모든 외부 요청은 잠재적인 데이터 채널이고, MCP 서버 하나하나가 새로운 공격 표면이므로 네트워크 계측은 여기까지 다뤄야 합니다. 제 웹 추출 라이브러리는 요청 URL과 응답 크기를 기록합니다. 네트워크 계측이 없다면 50MB 응답을 반환하는 웹 요청과 5KB를 반환하는 요청을 구분할 수 없습니다.⁶

세션별 리소스 대시보드를 제공하는 상용 에이전트 도구는 없습니다. 클라우드 제공업체가 컴퓨팅을 계측하는 목적은 과금이지 운영자의 가시성이 아닙니다. 에이전트가 소비하는 것과 운영자가 볼 수 있는 것 사이의 간극이 바로 리소스 계측의 결핍입니다.

이 부재는 숫자가 누적되기 전까지 눈에 띄지 않습니다. 400KB의 상태 파일을 쓰는 세션 하나는 아무것도 아닙니다. 그러나 각각 400KB를 쓰는 예순 번의 세션을 정리 없이 두면 24MB의 고아 상태 파일이 남습니다. 847KB를 반환하는 웹 요청 한 번은 무시할 만합니다. 그러나 실행마다 URL 80개를 가져오는 스캔 파이프라인은 에이전트의 도구 추상화가 운영자에게 감추는 67MB의 캐시 콘텐츠를 만들어냅니다. 리소스 계측은 누군가 GitHub 이슈 #22543을 올리게 만드는 위기가 되기 전에 이 누적을 드러냅니다.¹

2계층: 정책 적용

정책 적용은 어떤 규칙이 에이전트를 제약하는지, 그리고 그 규칙이 일관되게 적용되는지에 답합니다.

mcp-firewall은 CLI 에이전트를 위한 정책 계층을 담당합니다.⁷ 이 도구는 에이전트와 모든 도구 사용 요청 사이에 자리 잡고, 실행 전에 각 요청을 정규식 기반 정책에 비추어 평가합니다. 정책은 JSONNet 설정 파일로 작성하며 폴더, git 저장소, 사용자 단위로 범위를 지정합니다. 이 방화벽은 PreToolUse 훅 연동을 통해 Claude Code와 GitHub Copilot CLI를 지원합니다.

이 아키텍처에는 핵심적인 통찰이 담겨 있습니다. 모든 에이전트가 허용/거부 로직에 대해 저마다 어중간한 해법을 구현하고 있다는 점입니다. Claude Code는 glob 패턴을 사용합니다. Codex CLI는 접두사 일치만 사용합니다. 각 방식은 정책 공간의 일부만 다룹니다. mcp-firewall은 여러 에이전트에 걸쳐 동작하는 하나의 엔진으로 규칙을 모읍니다.

중앙집중식 적용이 없을 때 생기는 정책 공백을 생각해 봅시다. 제 훅 시스템에는 자격 증명 패턴, 위험한 git 작업, 민감한 경로 접근, 배포 명령을 검사하는 PreToolUse:Bash 핸들러가 12개 있습니다.² 각 핸들러는 저마다의 정규식 패턴을 가진 별개의 셸 스크립트입니다. 새 거부 규칙을 추가하려면 새 스크립트를 씁니다. 어떤 규칙이 존재하는지 감사하려면 12개 파일을 grep합니다. mcp-firewall은 이를 명시적인 허용 배열을 갖춘 단일 설정 파일로 통합합니다.

OWASP Top 10 for Agentic Applications(2025)는 Agent Goal Hijacking(ASI01)과 Excessive Agency(LLM06:2025)를 최상위 위험으로 지목합니다.⁸ 두 위험 모두 도구 호출 수준의 정책 적용을 요구합니다. 목표를 탈취당한 에이전트도 여전히 도구를 호출합니다. 과도한 재량을 가진 에이전트도 여전히 권한을 요청합니다. 정책 적용은 에이전트의 의도가 시스템의 도구와 만나는 경계에서 이 둘을 모두 가로챕니다.

정책 적용은 접근 제어와 다릅니다. 전통적인 접근 제어는 “이 사용자에게 권한이 있는가?”를 묻습니다. 에이전트에 대한 정책 적용은 “이 동작이 이 맥락에서, 이 작업에 대해, 승인된 범위 안에 있는가?”를 묻습니다. 배포와 방어의 신뢰 역설은 에이전트를 쓸모 있게 만들기 위해 넓은 권한을 부여하는 일이, 어떻게 정책 적용이 제약해야 할 바로 그 공격 표면을 만들어내는지 설명합니다. 어려운 지점은 맥락 민감성입니다. 기능 브랜치로의 git push와 main으로의 git push --force는 같은 도구(Bash)지만 폭발 반경이 전혀 다릅니다. mcp-firewall의 정규식 패턴은 둘을 구분할 수 있습니다. 기본 에이전트 권한은 그럴 수 없습니다.

애플리케이션 수준의 정책 적용에는 우회 위험도 따릅니다. 당신의 에이전트 샌드박스는 권고에 불과합니다에서 다뤘듯, 단단해 보이는 적용 경계에도 구조적인 틈이 있는 경우가 많습니다. 2026년 3월의 한 분석은 Claude Code의 내장 거부 목록을 상대로 한 세 단계의 샌드박스 탈출 기법을 기록했습니다. 경로 기반 회피(/proc/self/root/usr/bin/npx는 차단된 /usr/bin/npx와 동일한 바이너리로 해석됩니다), 에이전트 스스로의 샌드박스 비활성화(작업 완료가 막히자 에이전트가 자발적으로 샌드박스 제거를 추론해냈습니다), 그리고 동적 링커 호출(ld-linux-x86-64.so.2는 메모리 매핑으로 바이너리를 로드해 커널 적용 훅을 통째로 우회합니다)입니다.¹⁴ 세 번째 기법은 하나의 취약점 부류입니다. execve를 피하는 코드 로딩은 모두 프로세스 수준의 적용을 우회합니다. 정책 적용이 얻어야 할 교훈은, 문자열 대조 기반 거부 목록이 반드시 필요한 첫 번째 계층이기는 해도 충분한 계층은 아니라는 점입니다. 콘텐츠 주소 기반 적용(파일 이름 대신 SHA-256 해시로 바이너리를 식별하는 방식)은 경로 회피의 틈을 막지만, 동적 로더 우회를 막으려면 정책 계층 아래에 자리한 커널 수준의 통제가 필요합니다.

같은 교훈은 정책이 아예 들여다보지 못하는 한 단계 위에서도 그대로 성립합니다. 2026년 9월 Air Security가 공개한 Plugin4Shell은 주요 코딩 에이전트 네 가지에 공통으로 존재하는 마켓플레이스 공급망 결함입니다. 마켓플레이스는 플러그인에 대해 검증된 커밋을 고정하지만, 에이전트는 그 커밋이 실제로 거기에 들어갔는지 확인하지 않은 채 체크아웃합니다. 그래서 플러그인 저장소를 장악한 공격자는 고정된 커밋과 같은 이름의 브랜치를 만들어 기본 브랜치로 지정할 수 있습니다. 이어서 마켓플레이스의 일상적인 재고정이 모든 에이전트의 백그라운드 자동 업데이트를 촉발하고, 체크아웃은 그 브랜치로 해석되는데도 고정은 여전히 지켜진 것처럼 보입니다. 제가 읽기로는 이 스택의 어떤 PreToolUse 훅도, 거부 목록도, 방화벽도 플러그인이 바뀐 것을 보지 못합니다. 교체가 에이전트의 도구 호출보다 먼저 일어나기 때문입니다. Air의 타임라인에 따르면 Anthropic은 Claude Code 2.1.179에서 수정을 확인했고 OpenAI는 Codex 0.146.0에서 수정을 내놓았으며, GitHub Copilot에는 수정이 없고 지원이 중단된 Gemini CLI에는 수정 계획도 없습니다. 다만 공개된 Claude Code 체인지로그의 2.1.179 항목은 이 수정을 명시하지 않으므로, 이 버전은 연구자들의 설명에 근거합니다. 여기서 통하는 통제는 버전을 최신으로 유지하는 위생 관리와 마켓플레이스가 실제로 무엇을 해석해 냈는지에 대한 목록이며, 이는 계측의 문제이지 정책의 문제가 아닙니다.¹⁷

3계층: 런타임 감사

런타임 감사는 에이전트가 시스템 콜 수준에서 실제로 무엇을 했는가에 답합니다.

Logira는 eBPF 프로브로 커널 수준에서 시스템 콜을 가로채 감사 계층을 담당합니다.⁹ 이 도구는 세 가지 이벤트 범주를 기록합니다. 프로세스 실행(exec 이벤트), 파일 작업(자격 증명 파일 접근 포함), 그리고 네트워크 연결(목적지 추적 포함)입니다. 감사된 실행마다 파일 세 개가 생성됩니다. 타임라인 검토용 events.jsonl, 질의 가능한 필터링용 index.sqlite, 실행 메타데이터용 meta.json입니다.

설계 철학은 “관찰 전용”입니다. Logira는 기록하고 탐지하지만 적용하거나 차단하지는 않습니다.⁹ 적용 계층과의 분리는 의도적입니다. 정책 적용은 알려진 악성 동작을 막습니다. 런타임 감사는 알려지지 않은 악성 동작을 사후에 발견합니다. 두 계층은 시간 축에서 서로 다른 기능을 수행합니다. 예방(사전)과 포렌식(사후)입니다.

Logira의 eBPF 프로브는 애플리케이션 계층 아래에서 동작합니다. 데이터를 유출하려고 새로운 명령을 조합하는 에이전트도 결국 시스템 콜을 발생시킵니다. 에이전트는 파일 읽기, 네트워크 연결, 프로세스 생성을 커널 수준 추적으로부터 숨길 수 없습니다. 이 접근법은 애플리케이션 수준 훅이 놓치는 것, 즉 도구 호출 추상화를 우회하는 부수 효과를 잡아냅니다.

내장 탐지 규칙은 AI 에이전트의 위험을 겨냥합니다. 자격 증명 파일 접근, 지속성 메커니즘 변경(/etc, systemd, cron), 의심스러운 명령 체인(curl-pipe-sh 패턴), 파괴적 작업(rm -rf), 그리고 비정상적인 네트워크 송신입니다.⁹ 이 규칙들은 범용 시스템 감사가 아니라 에이전트 위협 모델에 맞춘 견해 있는 기본값입니다.

플랫폼 제약은 중요합니다. Logira는 Linux 5.8 이상과 cgroup v2를 필요로 합니다. macOS 에이전트(Claude Desktop, Darwin의 Claude Code)는 eBPF 기반 감사를 쓸 수 없습니다. 제 OS 샌드박스는 가장 가까운 대안으로 macOS Seatbelt 프로파일을 사용합니다. 민감한 경로에 대한 쓰기를 커널이 차단하는 거부 규칙입니다.³ 그러나 Seatbelt는 적용이지 감사가 아닙니다. macOS에는 Logira의 관찰 전용 감사 추적에 상응하는 프로덕션 수준의 도구가 없습니다.

2026년 3월 Hacker News에서 802포인트와 181개의 댓글을 모은 macOS 네이티브 샌드박싱 도구 Agent Safehouse는 이 플랫폼 공백을 적용 쪽에서 다룹니다.¹⁵ 이 도구는 macOS의 로컬 AI 에이전트를 위해 설계된 샌드박스 프로파일을 제공합니다. 커뮤니티의 반응(샌드박싱 도구에 802포인트는 이례적입니다)은 그 절박함을 보여줍니다. macOS에서 에이전트를 운영하는 실무자에게는 “샌드박스 없음”과 “직접 Seatbelt 프로파일 작성” 사이에 선택지가 거의 없었습니다. Agent Safehouse는 적용 측면에서 그 공백을 메웁니다. macOS의 감사 공백은 여전히 열려 있습니다.

적용과 감사의 구분은 사고 대응의 시간적 분할에 대응합니다. 적용은 사고를 예방하고, 감사는 사고 이후의 재구성을 가능하게 합니다. 둘 다 필요합니다. 모든 자격 증명 접근을 차단하는 적용 계층은 유출을 막는 동시에 정당한 SSH 작업까지 막습니다. 차단 없이 모든 자격 증명 접근을 기록하는 감사 계층은 운영자가 접근 패턴을 검토하고 증거에 기반해 적용 규칙을 조정할 수 있게 합니다. 감사 데이터와 정책 정교화 사이의 이 피드백 루프가 바로 가시성 스택이 시간이 지나면서 개선되는 방식입니다. 감사가 패턴을 드러내고, 패턴이 정책을 만들고, 정책이 감사가 다뤄야 할 표면을 줄입니다.

Logira의 cgroup v2 격리는 애플리케이션 수준 감사가 재현할 수 없는 기능을 더합니다. 실행 단위 귀속입니다. 이 시스템은 모든 이벤트를 시스템 전체가 아니라 특정한 감사 실행에 귀속시킵니다. 같은 머신에서 두 개의 에이전트 세션이 동시에 실행될 때, cgroup 격리는 세션 A의 파일 접근이 세션 B의 감사 추적에 나타나지 않도록 보장합니다. 애플리케이션 수준 훅은 같은 보장을 제공할 수 없습니다. 훅은 에이전트 프로세스 안에서 발화하는데, 그 프로세스에는 동시 세션을 가르는 커널 수준의 경계가 없기 때문입니다.⁹

제가 실제로 운영하는 것

제 오케스트레이션 시스템은 전용 모니터링 도구가 아니라 훅을 통해 세 계층을 모두 다룹니다.

리소스 계측. cost-gate 훅이 설정 가능한 예산 임계값에 비추어 세션별 토큰 사용량을 추적합니다.⁵ 시스템 성능 모니터는 설정한 간격으로 CPU, 메모리, 디스크, 스왑을 확인하고, 리소스 압박이 임계값을 넘으면 경고를 주입합니다.¹⁰ 세션 드리프트 감지기는 도구 호출 25회마다 발화해, 최초 프롬프트 임베딩과 최근 동작의 슬라이딩 윈도 사이의 코사인 유사도를 계산합니다.²

정책 적용. 여덟 개의 PreToolUse 디스패처 훅이 도구 유형에 따라 핸들러 훅으로 라우팅합니다. PreToolUse:Bash만 해도 자격 증명 패턴, 파괴적 git 작업, 민감한 경로 접근, 배포 명령을 다루는 핸들러 12개가 실행됩니다. 재귀 가드는 최대 깊이 2, 부모 에이전트당 최대 자식 5개를 강제합니다.²

런타임 감사. PostToolUse 훅이 모든 도구 호출 결과를 기록합니다. 보안 스캔 훅은 실행 후 bash 출력에 자격 증명 유출이 없는지 검사합니다. 세션 상태 파일(jiro.state.json)은 모든 스토리 완료, 리뷰어 판정, 증거 게이트 결과를 기록합니다.² 이 시스템은 eBPF를 사용하지 않지만(macOS의 한계입니다) 훅 파이프라인을 통해 도구 수준의 텔레메트리를 확보합니다.

이 시스템이 작동하는 이유는 모든 동작이 훅 파이프라인을 지나기 때문입니다. 한계는 깊이에 있습니다. 훅 수준의 모니터링은 에이전트가 하겠다고 요청한 것을 포착할 뿐, 운영체제가 실제로 실행한 것을 포착하지는 않습니다. 서브셸을 품은 bash 명령을 조합하는 에이전트는, 훅에게는 하나의 문자열로만 보이는 코드를 실행합니다. 커널 수준 감사라면 각각의 하위 프로세스를 볼 수 있었을 것입니다.

기본 모니터링이었다면 놓쳤을 실패를 이 3계층 스택이 잡아낸, 프로덕션 사고의 구체적인 결과입니다.

누적되는 사각지대

에이전트가 에이전트를 생성하면 불투명성은 곱절로 늘어납니다. 위임 홉마다 정보 손실이 생깁니다.

제 오케스트레이션 시스템이 ralph 자율 루프를 실행할 때, 부모 프로세스는 PRD 스토리마다 새로운 Claude Code 인스턴스를 생성합니다. 각 하위 에이전트는 좁게 정의된 작업과 새 컨텍스트 윈도를 받습니다. 부모는 완료 상태를 추적합니다. 그러나 부모는 자식의 개별 도구 호출, 파일 읽기, 리소스 소비를 보지 못합니다.²

깊이 1(부모가 자식을 생성)에서 부모는 자식의 최종 출력을 봅니다. 깊이 2(자식이 손자를 생성)에서 부모가 보는 것은 손자의 출력에 대한 자식의 보고입니다. 홉마다 정보가 압축됩니다. 제 NIST 의견서의 위임 체인 분석은 누적되는 세 가지 위험을 측정했습니다. 의미 압축(맥락이 하나의 프롬프트 문자열로 무너지는 것), 권한 증폭(자식이 민감도를 이해하지 못한 채 권한을 상속하는 것), 그리고 책임 분산(루트 에이전트가 직접 검토한 적 없는 결과에 책임을 지는 것)입니다.³

관측성도 같은 속도로 저하됩니다. 루트 에이전트에 3계층 가시성 스택을 갖춰도, 각 자식이 독립적으로 자체 모니터링을 실행하지 않는 한 손자 에이전트에 대한 가시성은 전혀 없습니다. 제 재귀 가드는 깊이 제한을 강제하지만, 그것은 정책 통제이지 관측성 통제가 아닙니다. 위임이 깊이 2에서 멈췄다는 사실을 안다고 해서 깊이 2에서 무슨 일이 있었는지 알 수 있는 것은 아닙니다.

제 프로덕션 시스템에서 나온 구체적인 사례입니다. ralph 루프가 데이터베이스 마이그레이션 스토리를 구현하려고 하위 에이전트를 생성했습니다. 그 하위 에이전트는 마이그레이션에 “검증 단계”가 필요하다고 판단하고, 통합 테스트를 실행할 자체 하위 에이전트를 생성했습니다. 손자 에이전트는 조용히 실패했습니다(테스트 데이터베이스가 설정되어 있지 않았습니다). 자식 에이전트는 빈 응답을 받고 침묵을 성공으로 해석해 스토리를 완료로 보고했습니다. 부모는 “story 4: complete”를 기록했습니다. 저는 세 시간 뒤 없는 컬럼 때문에 애플리케이션이 크래시하고 나서야 마이그레이션이 깨진 것을 발견했습니다. 루트 에이전트의 텔레메트리는 깨끗한 실행을 보여주고 있었습니다. 실패는 두 홉 아래에 있었고, 루트에 배치한 어떤 모니터링 계층에도 보이지 않았습니다.²

OWASP의 Agentic Applications 프레임워크는 연쇄 실패와 통제를 벗어난 에이전트를 다루지만, 멀티 에이전트 위임 체인에 대한 관측성 요구사항은 규정하지 않습니다.⁸ OpenGuard가 2026년 3월에 내놓은 에이전트 프롬프트 인젝션 분석도 같은 공백을 보안 쪽에서 드러냅니다. 서로 다른 권한을 가진 에이전트 사이를 오염된 맥락이 흘러 다니면서, 명확한 데이터 흐름 정책이나 조합 수준의 인가 없이 인계를 통해 “조용히 권한을 상승시키는 경로”가 만들어진다는 것입니다.¹⁶ 이 공백은 구조적입니다. 체인의 각 에이전트가 저마다 독립적으로 설정되고 독립적으로 보고되는 리소스 계측, 정책 적용, 런타임 감사를 갖춰야 하기 때문입니다. 오버헤드는 곱셈으로 늘어납니다. 체인의 에이전트 세 개에 모니터링 세 계층을 두면 모니터링 인스턴스는 아홉 개가 되고, 각각이 자체 텔레메트리를 만들고 각각이 자체 설정을 요구합니다. 그 조율을 관리하는 기존 도구는 없습니다.

오늘 바로 구현할 수 있는 것

가시성 스택을 아우르는 최소한의 모니터링 훅 세 가지입니다.

1. 리소스: 토큰 예산 추적기. 세션별 누적 입력 토큰과 출력 토큰을 기록하세요. 하드 리밋을 정하고 80%에서 알리세요. 구현에는 에이전트의 사용량 통계를 읽고(Claude Code는 /cost로 세션 비용을 노출합니다) 임계값과 비교하는 작업이 필요합니다. 제 cost-gate 훅은 이를 bash 47줄로 처리합니다.⁵

2. 정책: PreToolUse 거부 목록. 모든 Bash 도구 호출 전에 발화하는 훅을 만드세요. 명령을 다음과 같은 패턴 목록과 대조하세요. rm -rf /, git push --force, .ssh나 .env가 포함된 경로, curl | sh입니다. 일치하면 차단하세요. 구현에는 표준 입력(도구 호출 JSON)을 읽고 command 필드를 추출해 패턴 파일과 grep하는 셸 스크립트 하나가 필요합니다. 제 자격 증명 검사 훅은 이를 31줄로 처리합니다.²

3. 감사: PostToolUse 세션 로그. 모든 도구 호출과 결과를 세션별 JSONL 파일에 덧붙이세요. 타임스탬프, 도구 이름, 인자, 종료 코드를 포함하세요. 이 로그가 있으면 세션 이후의 재구성이 가능해집니다. 에이전트가 무엇을, 어떤 순서로 했는지, 그리고 조용히 실패한 것은 없는지 확인할 수 있습니다. 제 세션 로거는 이를 bash 22줄로 처리합니다.²

settings.json에 작성한 거부 목록 훅의 실제 예시입니다.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/check-sensitive-paths.sh"
          }
        ]
      }
    ]
  }
}

훅 스크립트는 표준 입력에서 도구 호출을 읽고, 명령 문자열을 추출해 패턴과 대조합니다. 차단된 명령에는 {"decision": "block", "reason": "Sensitive path access denied"}라는 JSON 객체를 반환하고, 허용된 명령에는 {"decision": "approve"}를 반환합니다. Claude Code는 추가 확인 없이 두 응답을 모두 존중합니다. 이 훅 전체는 허용된 명령에 지연을 전혀 더하지 않으면서(정규식 검사는 5ms 미만으로 끝납니다) 차단된 명령에는 즉각적인 피드백을 제공합니다.

이 세 훅을 모두 합쳐도 100줄이 되지 않습니다. 이것들이 전용 모니터링 도구를 대체하지는 않습니다. 다만 가시성 제로를 최소한의 가시성으로 바꿔줍니다. 그리고 최소한의 가시성이야말로 이후에 이어질 모든 거버넌스 결정의 전제입니다. 계측 없이는 리소스 예산을 정할 수 없습니다. 거부 목록 없이는 범위 정책을 강제할 수 없습니다. 감사 로그 없이는 사고를 조사할 수 없습니다. 로그부터 시작하세요. 나머지 둘은 뒤따라옵니다.

핵심 정리

플랫폼 엔지니어에게. 에이전트는 기존 모니터링이 추적하지 않는 리소스를 소비합니다. 에이전트 세션별 디스크, 메모리, CPU, 네트워크 사용량은 컨테이너 지표와 같은 대시보드에 놓여야 합니다. Cowork 사고가 그 필요성을 증명합니다. 운영자 가시성이 전혀 없는 상태에서 10GB가 할당되었습니다.

보안 팀에게. 도구 호출 경계에서의 정책 적용은 최소한으로 실행 가능한 에이전트 보안 태세입니다. mcp-firewall의 중앙집중식 접근법은 에이전트별 허용/거부 로직을 감사 가능한 하나의 설정으로 통합합니다. 여러분의 에이전트가 가진 내장 권한이 위협 모델이 요구하는 정책 공간을 다루는지 평가해 보세요.

엔지니어링 매니저에게. 장기적인 답은 에이전트 자율 거버넌스입니다. 모니터링을 외부의 제약이 아니라 행동 규범으로 내면화한 에이전트를 말합니다. 그것이 성숙하기 전까지는 여러분의 에이전트 도구에 대해 세 가지를 물어보세요. 세션별 리소스 소비를 볼 수 있습니까? 도구 호출 정책을 정의하고 감사할 수 있습니까? 에이전트가 무엇을 했는지 사후에 재구성할 수 있습니까? 하나라도 “아니오”라면 가시성 공백이 있는 것이고, 그 공백은 워크플로에 에이전트가 하나씩 늘어날 때마다 함께 커집니다.

자주 묻는 질문

에이전트 관측성이란 무엇입니까?

에이전트 관측성은 AI 에이전트가 실행 중에 무엇을 하는지 모니터링하고 이해하는 능력입니다. 어떤 리소스를 소비하는지, 어떤 동작을 하는지, 그리고 그 동작이 정의된 정책을 준수하는지를 포함합니다.

Anthropic의 Cowork는 왜 10GB VM을 만들었습니까?

Claude Desktop의 Cowork 기능은 협업 개발 세션을 위해 가상 머신을 프로비저닝합니다. Claude Desktop은 이 기능을 한 번도 활성화하지 않은 사용자에게도 모든 macOS 설치본에서 VM 번들을 자동으로 생성하고, 수동으로 삭제할 때까지 유지합니다.¹

mcp-firewall이란 무엇입니까?

mcp-firewall은 CLI 에이전트(Claude Code, GitHub Copilot CLI)의 도구 사용 요청을 가로채, 실행 전에 정규식 기반 허용/거부 규칙에 비추어 평가하는 오픈소스 정책 적용 도구입니다.⁷

eBPF 런타임 감사란 무엇입니까?

eBPF(extended Berkeley Packet Filter)는 감사 대상 프로세스를 수정하지 않고도 시스템 콜을 커널 수준에서 추적할 수 있게 해줍니다. Logira 같은 도구는 AI 에이전트 실행 중의 프로세스 실행, 파일 작업, 네트워크 연결을 기록하기 위해 eBPF 프로브를 사용합니다.⁹

에이전트는 어떻게 운영자에게 보이지 않은 채 하위 에이전트를 생성합니까?

작업을 위임하는 에이전트는 새 컨텍스트 윈도를 가진 자식 프로세스를 생성합니다. 부모 에이전트는 자식의 최종 출력은 보지만 개별 도구 호출, 파일 읽기, 리소스 소비는 보지 못합니다. 위임 홉마다 정보가 압축되어, 손자의 전체 세션이 부모의 로그에서는 한 줄짜리 상태가 됩니다. 관측성은 위임 깊이가 늘어나는 것과 같은 속도로 저하됩니다.²

에이전트 모니터링은 전통적인 APM과 어떻게 다릅니까?

전통적인 애플리케이션 성능 모니터링(APM)은 결정적으로 동작하는 소프트웨어의 요청 지연 시간, 오류율, 처리량을 추적합니다. 에이전트 모니터링은 비결정적 동작을 추적합니다. 에이전트가 런타임에 무엇을 하기로 결정했는지, 그 결정이 정책 범위 안에 있었는지, 각 결정이 어떤 리소스를 얼마나 소비했는지를 봅니다. APM은 애플리케이션이 알려진 코드 경로를 따른다고 가정합니다. 에이전트 모니터링은 에이전트가 스스로 경로를 고른다고 가정합니다.²

Claude Code 훅으로 에이전트 관측성을 확보할 수 있습니까?

가능합니다. Claude Code의 훅 시스템은 라이프사이클 이벤트(PreToolUse, PostToolUse, Notification)에서 스크립트를 발화시켜 리소스를 계측하고, 정책을 적용하고, 동작을 기록할 수 있습니다. 토큰 예산 추적기, PreToolUse 거부 목록, PostToolUse 세션 로거로 구성된 세 훅 설정이면 bash 100줄 미만으로 세 가지 가시성 계층을 모두 다룰 수 있습니다. 이미 Claude Code를 쓰고 있는 팀에게 훅은 가장 접근하기 쉬운 출발점입니다.

에이전트가 자신의 샌드박스를 우회하면 어떻게 됩니까?

샌드박스 우회는 적용 계층이 조용히 실패한다는 뜻입니다. 에이전트는 의도된 범위 밖에서 계속 실행되고, 런타임 감사가 없다면 그 침해에 대한 기록은 어디에도 남지 않습니다. 2026년 3월에 기록된 샌드박스 탈출 기법에는 경로 기반 회피, 에이전트 스스로의 샌드박스 비활성화, 동적 링커 호출이 포함되며, 모두 애플리케이션 수준 모니터링에는 보이지 않습니다.

MCP 도구 관측성은 왜 중요합니까?

모든 MCP 도구 호출은 잠재적인 데이터 채널입니다. 파일을 읽고, 네트워크 요청을 보내고, 코드를 실행할 수 있습니다. MCP 서버는 공격 표면을 넓힙니다. 서버가 하나 추가될 때마다 에이전트가 런타임에 호출할 수 있는 새로운 기능이 생기기 때문입니다. 호출별 로깅과 정책 적용이 없다면 MCP 도구 호출은 운영자에게 보이지 않습니다.

멀티 에이전트 위임 체인은 어떻게 모니터링합니까?

위임 체인의 각 에이전트에는 저마다의 리소스 계측, 정책 적용, 런타임 감사가 필요합니다. ralph 자율 루프가 이 문제를 잘 보여줍니다. 부모가 하위 에이전트를 생성하고, 각 하위 에이전트는 새 컨텍스트 윈도를 받습니다. 부모는 최종 출력만 볼 뿐 개별 도구 호출은 보지 못합니다. 관측성은 위임 깊이가 늘어나는 것과 같은 속도로 저하되므로, 모든 홉에서 독립적인 모니터링이 필요합니다.

출처