2026년 3월 31일, Claude Code의 npm 릴리스에 실수로 소스맵이 포함되어 방대한 양의 내부 TypeScript 소스가 노출됐다는 보도가 나왔다. Ars Technica, Zscaler 등 여러 매체는 약 1,900개의 TypeScript 파일에 걸쳐 약 512,000~513,000줄이 노출됐다고 전했다. Anthropic은 이번 노출이 릴리스 패키징 과정에서 발생한 문제이며, 민감한 고객 데이터나 자격 증명은 포함되지 않았다고 밝혔다.
초기 보도 대부분은 메모리 시스템, 숨겨진 모드, 미공개 기능, 내부 명칭 등 가장 눈에 띄는 발견에 초점을 맞췄다. 하지만 더 오래 남을 교훈은 조용한 곳에 있다. 노출된 코드에 대한 공개 분석은 프로덕션급 코딩 에이전트가 모델 주변에 얼마나 많은 엔지니어링을 필요로 하는지를 보여준다. 권한 관리, 텔레메트리, 애널리틱스, 세션 트레이싱, 툴 실행, IDE 통합, MCP 통합, 백그라운드 작업, 멀티 에이전트 오케스트레이션이 그것이다.
이는 새롭게 떠오르는 분야, 즉 **에이전트 행동 분석(Agent Behavior Analysis, ABA)**을 가리킨다. 그 목표는 모든 상호작용, 모델 호출, 툴 호출, 승인 대기, 차단 상태, 세션 관계, 거버넌스 이벤트를 조회하고 상호 연관 짓고 검토할 수 있는 텔레메트리로 전환하는 것이다.
프로덕션 에이전트는 단순한 모델 래퍼가 아니다
Claude Code는 흔히 CLI 코딩 어시스턴트로 여겨진다. 하지만 유출된 소스코드에 대한 공개 분석은 그 이면에 훨씬 더 큰 런타임이 존재한다는 것을 보여줬다. 권한 레이어, 메모리 레이어, 백그라운드 작업, IDE 브리지, MCP 경로, 그리고 모델을 둘러싼 멀티 에이전트 오케스트레이션이다.
정확한 줄 수 분석은 공식 아키텍처 문서가 아니라 소스코드에서 도출된 분석으로 받아들여야 한다. 그럼에도 방향성은 분명하다. 프로덕션 에이전트에서 모델을 직접 호출하는 부분은 극히 일부에 불과하며, 나머지는 런타임 엔지니어링이다.
엔터프라이즈 팀에게 이는 중요한 문제다. 운영 리스크는 모델의 응답에만 국한되지 않고, 그 주변 시스템 전반에 존재하기 때문이다.
- 에이전트가 어떤 툴을 호출했는가?
- 어떤 권한 경계가 적용됐는가?
- 사람이 해당 작업을 승인했는가?
- 에이전트가 사용자 입력을 기다리며 차단됐는가?
- 하위 에이전트가 올바른 컨텍스트를 상속받았는가?
- 이 작업은 어떤 세션 또는 상위 세션에 속했는가?
- 어떤 데이터가 트레이스에 포함됐고, 어떤 데이터가 마스킹됐는가?
이는 옵저버빌리티에 관한 질문이지만, 일반적인 APM 질문은 아니다.
에이전트 옵저버빌리티의 세 가지 레이어는 무엇인가?
소스코드 기반의 공개 분석은 Claude Code 내부에 세 가지 별도의 옵저버빌리티 레이어가 존재한다고 설명했다. 이 구분은 자체 에이전트 런타임을 처음부터 구축하는 팀에게도 그대로 적용된다.
| 레이어 | 답하는 질문 | 예시 |
|---|---|---|
| 제품 애널리틱스 이벤트 | 사용자에게 보이는 어떤 행동이 발생했는가? | OAuth 플로우 시작, 플러그인 설치, 세션 재개 |
| 표준 텔레메트리 | 인프라가 어떻게 동작하고 있는가? | 요청 수, 지연 시간, 오류율, 익스포터 상태(OTel, Prometheus, OTLP) |
| 세션 단위 에이전트 트레이싱 | 하나의 사용자 상호작용이 런타임 내부에서 어떻게 전개됐는가? | 상호작용, LLM 요청, 툴 호출, 승인 대기로 차단된 툴, 툴 실행, 훅 실행 |
제품 애널리틱스와 런타임 트레이스는 섞여서는 안 된다. 제품 이벤트와 모델 실행 스팬이 동일한 세션에서 발생할 수는 있지만, 이 둘은 서로 다른 질문에 답한다.
세션 단위 트레이싱은 에이전트 특유의 조사를 위해 구축된 레이어다. 기본 단위는 단순한 HTTP 요청이 아니라 사용자 상호작용이다. 하나의 턴(turn)에는 프롬프트 처리, 여러 차례의 모델 호출, 여러 차례의 툴 호출, 승인 대기, 훅, 재개 로직이 포함될 수 있다. 상호작용 단위의 루트 스팬이 없으면 조사는 서로 연결되지 않은 이벤트 더미로 전락한다.
로그를 더 쌓는 것보다 상관관계 키가 중요한 이유
에이전트 시스템을 조사하기 어려운 이유는 동일한 작업이 여러 형태로 나타날 수 있기 때문이다. 에이전트는 다음과 같은 형태일 수 있다.
- 로컬 하위 에이전트
- 스웜(swarm) 내 팀 구성원
- 독립 실행 프로세스
- 프레임워크가 관리하는 워커
- IDE 내부의 코딩 어시스턴트
- MCP를 통해 호출되는 워크플로 참여자
이를 이해하려면 안정적인 상관관계 키가 필요하다.
user.idsession.idorganization.idagentIdparentSessionIdagentTypeteamName
이 식별자들 덕분에 백엔드는 최소한의 관계 그래프를 구성할 수 있다. 어떤 세션이 활성 상태인지, 어떤 에이전트가 해당 작업을 수행했는지, 어떤 상위 세션이 이를 소유하는지, 어떤 팀이나 워크스페이스에 속하는지를 알 수 있는 것이다. 에이전트 행동 분석은 바로 여기서 시작된다. 모든 이벤트가 평면적인 로그 한 줄로만 도착한다면, 팀은 멀티 에이전트 교착 상태, 비용 급증, 툴 오남용 사고를 조사할 수 없다.
함수 단위 타이밍보다 시맨틱 스팬이 낫다
전통적인 트레이싱은 함수, 요청, 데이터베이스 호출에서 시작한다. 반면 에이전트 트레이싱에는 더 상위 수준의 분류 체계가 필요하다.
agent.interactionagent.llm_requestagent.toolagent.tool.blocked_on_useragent.tool.executionagent.hook
blocked_on_user 스팬은 특별히 주목할 가치가 있다. 에이전트 시스템에서 시간은 단순히 기계가 소비하는 시간만을 의미하지 않는다. 승인 대기, 수동 확인, 중단된 턴, 사람의 의사결정 모두가 런타임 경로의 일부다.
이 시간을 분리해내면 팀은 더 날카로운 질문에 답할 수 있다.
- 모델이 느려서 턴이 느려졌는가?
- 툴 실행이 느렸는가?
- 에이전트가 사용자 승인을 기다리고 있었는가?
- 고위험 툴이 자주 거부됐는가?
- 하위 에이전트가 권한 부족으로 멈췄는가?
이것이 에이전트 행동 분석의 핵심 가치다. 어떤 API가 호출됐는지만 보여주는 것이 아니라, 에이전트의 행동이 어떻게 전개됐는지, 어디서 멈췄는지, 어떤 경계가 다음에 일어난 일을 규정했는지를 보여준다.
분류 체계가 곧 거버넌스다
에이전트 옵저버빌리티는 고차원적이고 반정형적이며 카디널리티가 높은 데이터를 만들어낸다. 모든 프롬프트, 툴 이름, 서버 이름, 파일 경로, 사용자 메시지, 내부 변수를 무분별하게 저장하면 플랫폼은 비용이 많이 들고 노이즈가 심하며 위험해진다.
좋은 분류 체계는 거버넌스 메커니즘이다. Claude Code에 대한 소스코드 기반 공개 분석은 엔터프라이즈 시스템에 중요한 패턴들을 짚어냈다.
- 메타데이터는 타입으로 제약돼야 한다
- 민감한 문자열은 명시적인 처리가 필요하다
- 비공개 페이로드 필드는 외부로 전파되기 전에 제거돼야 한다
- 사용자 정의 MCP 서버 및 툴 이름은 정규화가 필요할 수 있다
- 프롬프트 텍스트, 툴 콘텐츠, 툴 파라미터는 명시적인 스위치로 제어돼야 한다
- 카디널리티가 높은 식별자는 의도적으로 관리돼야 한다
이는 단순한 데이터 모델링 문제가 아니다. 프라이버시, 비용, 백엔드 안정성, 사고 검토가 동시에 걸린 문제다.
TrueWatch가 이 패턴에서 얻은 것
앞서 설명한 설계 방향은 TrueWatch가 AI 에이전트 옵저버빌리티에 접근하는 방식과 맞닿아 있다.
유연한 데이터, 고정되지 않은 에이전트 형태. 에이전트의 정체성은 고정돼 있지 않다. 팀은 OpenClaw, Claude Code, Codex, 내부 에이전트, MCP 연동 어시스턴트, 제품별 워크플로 등을 운영할 수 있으며, 각각 서로 다른 필드를 내보낸다. TrueWatch는 이런 이질적인 옵저버빌리티 데이터를 수신해 처음부터 모든 팀을 동일한 경직된 스키마에 억지로 맞추지 않고도 조회 가능하게 만들도록 설계됐다. 다음에 유용해질 필드가 sessionId, parentSessionId, skillName, teamName, approvalState, 혹은 아직 팀이 필요로 하지 않은 어떤 것일 수도 있기 때문이다.
수집과 처리는 분리된다. DataKit은 대상 환경에서 텔레메트리를 수집하고, 파이프라인 처리 단계는 데이터가 플랫폼에 도달하기 전에 이를 파싱, 필터링, 보강, 마스킹한다. 이는 Claude Code 분석에서 얻은 교훈과 일맥상통한다. 거버넌스는 데이터가 이미 모든 싱크에 퍼진 이후가 아니라 수집 단계 가까이에서 시작돼야 한다는 것이다.
DQL은 운영자에게 단일 쿼리 플레인을 제공한다. 에이전트 행동은 여러 데이터 유형을 넘나든다. 하나의 조사에 트레이스 스팬, 토큰 메트릭, 로그, 이벤트, 승인 기록, 서비스 데이터가 모두 필요할 수 있다. DQL은 툴 호출, 트레이스 ID, 토큰 급증, 오류 로그, 서비스 의존성을 서로 무관한 시스템을 오가지 않고도 연결한다.
높은 카디널리티는 신중하게 다뤄야 한다. 세션 ID, 트레이스 ID, 에이전트 ID, 툴 이름, 모델 버전, 프롬프트 변형, 워크스페이스 식별자는 빠르게 폭증할 수 있다. TrueWatch는 카디널리티를 각주가 아니라 아키텍처 문제로 다룬다. 덕분에 팀은 옵저버빌리티 백엔드를 새로운 사고의 원인으로 만들지 않으면서도 유용한 세부 정보를 유지할 수 있다.
에이전트 행동 분석의 4가지 엔터프라이즈 시나리오
1. 토큰 비용 귀속(Attribution)
고객 서비스 에이전트가 프로덕션에 배포된다. 월말이 되자 모델 API 비용이 예상보다 훨씬 높게 나온다. 애플리케이션 로그는 총 사용량은 보여주지만, 어떤 스킬, 프롬프트 버전, 모델, 혹은 세션 패턴이 비용 증가를 이끌었는지라는 진짜 질문에는 답하지 못한다.
에이전트 행동 분석을 활용하면 팀은 토큰 사용량을 애플리케이션, 모델, 스킬, 세션, 툴, 프롬프트 버전별로 그룹화할 수 있다. 원인은 종종 사소한 것에서 비롯된다. 예를 들어 새로 추가된 주문 이력 스킬이 턴마다 지나치게 많은 컨텍스트를 싣고 있었다는 식이다. 수정 자체는 대개 쉽다. 어려운 것은 가시성을 확보하는 일이다.
2. 위험한 툴 사용과 긴급 정지
운영 에이전트가 데이터베이스 유지보수 작업을 실행할 권한을 갖고 있다. 경계 조건이 잘못 설정되면서 에이전트가 위험한 유형의 SQL 작업을 시도하기 시작한다.
CPU와 메모리 차트는 정상으로 보일 수 있다. 하지만 에이전트 스팬은 실제 행동을 보여준다. 고위험 툴에 대한 반복적인 호출, 대상 데이터베이스, 명령 유형, 세션, 권한 컨텍스트까지 드러난다. 적절한 알림 정책을 갖추면 플랫폼은 담당자에게 알리고, 인시던트를 개설하고, 거버넌스를 갖춘 워크플로를 통해 자격 증명을 폐기할 수 있다. 그리고 사고 후 검토는 흩어진 로그에서 이야기를 재구성하는 대신 트레이스를 그대로 따라가면 된다.
3. 멀티 에이전트 교착 상태
한 팀이 요구사항 에이전트, 코딩 에이전트, 테스트 에이전트로 구성된 스웜을 운영한다. 워크플로가 멈춘다. 요구사항 에이전트는 작업이 이미 인계됐다고 판단하지만, 테스트 에이전트는 결코 도착하지 않는 코드 출력을 계속 기다리고 있다.
parentSessionId, agentId 같은 상관관계 키 덕분에 플랫폼은 이러한 작업들을 하나의 토폴로지로 연결할 수 있다. 팀은 코딩 에이전트가 git_commit 툴 호출 도중 사용자 승인을 기다리며 차단됐고, 그 상태를 상위로 보고하지 못했다는 사실을 발견할 수도 있다. 행동 분석이 없다면 이는 그저 침묵처럼 보인다. 세션 트레이싱이 있다면 교착 상태는 정확한 위치를 갖는다.
4. 컴플라이언스 감사와 과잉 권한 탐지
한 금융 서비스 팀이 마스킹된 데이터셋에만 접근해야 하는 리포팅 에이전트를 도입한다. 감사관들은 이 에이전트가 원본 고객 데이터를 조회한 적이 없다는 증거를 필요로 한다.
에이전트 행동 분석은 각 단계에서 어떤 MCP 서버, 툴, 데이터셋, 권한 범위가 사용됐는지 기록할 수 있다. 승인되지 않은 서버나 원본 데이터 소스를 호출하려는 시도는 기록되고 차단되고 검토될 수 있다. 이는 단순한 모니터링이 아니라 컴플라이언스 통제 체계의 일부다.
자주 묻는 질문
Q: 에이전트 행동 분석이란 무엇인가? A: 에이전트 행동 분석(Agent Behavior Analysis, ABA)은 모델 호출, 툴 호출, 승인 대기, 차단 상태, 세션 관계를 포함한 모든 에이전트 상호작용을, 에이전트 활동을 단순한 평면 로그로 취급하는 대신 조회하고 상호 연관 짓고 검토할 수 있는 텔레메트리로 전환하는 작업 방식이다.
Q: Claude Code 소스 유출로 실제로 무엇이 노출됐는가? A: 공개 보도에 따르면 Claude Code의 npm 릴리스에서 발생한 패키징 문제로 인해 약 1,900개의 TypeScript 파일에 걸쳐 약 512,000~513,000줄에 이르는 소스맵이 노출됐다. Anthropic은 민감한 고객 데이터나 자격 증명은 노출되지 않았다고 밝혔다.
Q: 왜 표준 APM만으로는 AI 에이전트에 충분하지 않은가? A: 표준 APM은 요청, 지연 시간, 인프라 상태를 추적한다. 에이전트 시스템에는 단순한 HTTP 요청이 아니라 하나의 사용자 상호작용에 고정된 채 툴 호출, 승인 대기, 훅 실행 같은 비즈니스 시맨틱을 모델링하는 세션 단위 레이어가 필요하다.
Q: 에이전트 옵저버빌리티에서 상관관계 키란 무엇인가? A: 상관관계 키는 sessionId, agentId, parentSessionId, teamName과 같은 안정적인 식별자로, 옵저버빌리티 플랫폼이 어떤 에이전트가 어떤 세션 안에서 무엇을 했는지, 어떤 상위 세션이나 팀에 속하는지를 재구성할 수 있게 해준다.
Q: TrueWatch는 카디널리티가 높은 에이전트 데이터를 어떻게 처리하는가? A: TrueWatch는 카디널리티를 나중에 고려할 부수적 문제가 아니라 아키텍처 차원의 문제로 다룬다. 덕분에 팀은 백엔드를 불안정하게 만들지 않으면서도 조사에 필요한 수준의 세부 정보로 세션 ID, 트레이스 ID, 에이전트 ID, 프롬프트 변형을 보존할 수 있다.
모든 프로덕션 에이전트에는 행동 분석이 필요하다
Anthropic의 공식 입장에 따르면 Claude Code 소스맵 사건은 고객 데이터 유출이 아니라 패키징 오류였다. 하지만 이 사건이 주는 더 큰 교훈은 에이전트 런타임 엔지니어링에 관한 것이다.
프로덕션급 에이전트는 설계 단계에서부터 옵저버빌리티를 내장해야 한다. 제품 애널리틱스, 표준 텔레메트리, 세션 단위 트레이싱, 시맨틱 스팬, 상관관계 키, 프라이버시 통제, 카디널리티 관리, 장애 정리는 마무리 손질이 아니라 인프라 그 자체다.
Claude Code는 대체로 자신의 런타임만을 관찰한다. 엔터프라이즈 옵저버빌리티는 더 어려운 과제를 안고 있다. 화이트박스 에이전트, 프레임워크 에이전트, 폐쇄형 내부 에이전트, MCP 연동 툴 등 다양한 종류의 에이전트를 관찰하면서도 데이터를 조회 가능하고 상호 연관되며 거버넌스가 적용된 상태로 유지해야 한다.
이것이 바로 Toby AI Agents 옵저버빌리티가 지향하는 방향이다. 모든 상호작용, 툴 호출, 모델 호출, 승인 대기, 차단 상태, 세션 관계를 팀이 디버깅하고 감사하고 운영할 수 있을 만큼 충분히 가시화하는 것이다.