에이전트 모니터링은 인프라 워크로드입니다 | Focused Labs

나는 에이전트 모니터링(Agent Monitoring)을 SRE(Site Reliability Engineering) 운영 인프라로 넘어온 보고 업무 목록에 추가했다. 이는 짜증 나는 일이지만 충분히 현실적인 문제다. 과거의 트레이스(Trace)는 단일 요청을 설명하는 데 사용되었다. 하지만 이제는 도구 호출(Tool calls), 하위 에이전트(Subagents), 샌드박스(Sandboxes), 서비스(Services), 승인(Approvals), 재시도(Retries), 그리고 부수 효과(Side effects)를 거치는 에이전트 실행 과정을 모두 담아야 한다. 또한 아무도 세부 사항을 기억하지 못하는, 사건 발생 일주일 후쯤 트레이스를 읽는 SRE들을 지원할 수 있어야 한다. 트레이스는 롤백(Rollback)과 SRE가 수행하는 기타 운영 트러블슈팅(Troubleshooting) 작업을 지원해야 한다. 그리고 에이전트 실행에 대한 전체 로우 이벤트 로그(Raw event log)를 이미 다 읽지 않은 SRE도 이해할 수 있어야 한다.

우선, Sarah Cat은 기존 시스템은 에이전트 규모에 맞춰 설계되지 않았기 때문에 에이전트를 관리하고 모니터링하려면 인프라에 대한 재사고가 필요하다는 핵심적인 지점을 짚었다. 이어 Harrison Chase는 모니터링 측면에서도 동일한 점이 적용된다고 덧붙였다. Charity Majors는 관측성(Observability) 관점에서 이를 더 날카롭게 지적했다. 즉, 통상적인 트랜잭션(Transaction) 및 트레이스 빌딩 블록(Trace building blocks)으로는 오래 지속되는 비동기(Async) AI 세션을 추적하는 데 엄청난 문제가 있다는 것이다.

오래 지속되는 에이전트 세션에 대한 관측성은 AI 에이전트의 동작을 위한 스토리지(Storage), ID(Identity), 보존(Retention), 상관관계(Correlation) 및 컨트롤 플레인(Control-plane)으로 변모하고 있다.

좋다. 레이블이 도움이 된다면 모니터링이라고 불러도 좋다. 다만, 보고 업무(Reporting)처럼 인력을 배치하지는 마라.

트레이스가 더 큰 객체를 운반하고 있다

웹 요청은 핸들러(Handler)를 통해 들어와 데이터베이스(아마도 큐(Queue)일 수도 있음)를 호출한 다음, 요청을 보낸 사람에게 응답을 반환한다. 이것이 트랜잭션의 형태이며, 사람들이 관측성 도구를 구축해 온 방식이다. 이것은 스팬(Spans), 로그(Logs), 메트릭(Metrics), 개별 엑셈플러(Exemplars) 보기, 서비스 맵(Service map) 확인, 대시보드(Dashboard) 구축의 세계다.

LangChain의 관찰성 (Observability) 문서에 따르면, 에이전트(Agent)는 도구 (tools), 프롬프트 (prompts), 결정 (decisions), 도구 호출 (tool calls), 모델 상호작용 (model interactions), 그리고 결정 지점 (decision points)에 대한 가시성을 필요로 합니다. LangSmith의 대시보드 (Dashboard) 문서에서는 이러한 표면적인 요소들을 운영 지표 (Operating metrics)로 전환합니다: 트레이스 횟수 (trace count), 지연 시간 (latency), 에러율 (error rates), 토큰 사용량 (token usage), 비용 (cost), 도구 실행 횟수 (tool run counts), 도구 에러 (tool errors), 도구 지연 시간 (tool latency), 실행 유형 (run types), 그리고 피드백 점수 (feedback scores).

이 목록을 천천히 읽어보십시오. 이 목록은 에이전트 제어 평면 (Agent control plane)의 시작을 설명하고 있습니다.

나는 트레이스 (Trace)를 좋아합니다. 나는 대시보드 (Dashboard)를 좋아합니다. 하지만 가공되지 않은 로그 (Raw logs)가 기록의 전부인 것처럼 가장하는 것은 좋아하지 않습니다.

트레이스는 결정 (Decision)과 부수 효과 (Side effect)를 모두 따라가야 합니다.

단일 에이전트 실행 (Agent run)의 경우, 해당 실행의 로그를 로그로서 읽는 것은 괜찮습니다. 하지만 로그가 나중에 SRE(Site Reliability Engineer)나 보안 조사관의 증거가 되는 프로덕션 시스템 (Production system)을 모니터링할 때는, 로그 내의 명령을 따르는 트레이스가 에이전트가 가로지르는 경계들, 즉 도구 경계 (Tool boundaries), MCP 경계 (MCP boundaries), 샌드박스 경계 (Sandbox boundaries), 그리고 기타 런타임 경계 (Runtime boundaries)를 가로지르는 결정과 부수 효과를 함께 따라가야 합니다. 다시 한번 말씀드리지만, 에이전트 트레이스는 MCP 경계를 넘어야 합니다 (Agent Traces Need to Cross the MCP Boundary).

장기 실행 세션은 요청 중심의 사고방식을 깨뜨립니다

트랜잭션 트레이스 (Transaction trace)는 장기 실행되는 에이전트 세션 (Long-running agent session)을 담기에는 너무 작습니다.

Honeycomb는 프로덕션 환경에서의 AI 시스템 이해, 디버깅 및 개선을 주제로 2026 Innovation Week를 진행하고 있습니다. 이들의 에이전트 관찰성 (Agent observability) 출시의 핵심은 수동으로 로그를 뒤지는 과정 없이 에이전트 활동을 추적하고, 결정 경로 (Decision paths)를 재구성하며, 실패를 디버깅하는 데 집중하는 것입니다. 수동으로 로그를 뒤지는 과정은 미성숙한 에이전트 시스템이 무너지는 지점입니다.

시스템 전반에 걸친 세션 ID (Session id)가 없다면, 장애 검토 (Incident review)는 검색창을 이용한 고고학 작업으로 전락합니다. 누군가는 모델 호출을 추적하기 위해 LangSmith를 열고, 누군가는 서비스 운영을 추적하기 위해 Honeycomb을 엽니다. 누군가는 워크플로 큐 (Workflow queues)를 확인하고, 누군가는 애플리케이션 로그를 읽습니다. 누군가는 샌드박스 (Sandbox)가 여전히 존재하는지 묻고, 누군가는 승인 내역을 찾기 위해 Slack을 검색합니다. 그러고 나서 팀은 추측을 통해 조각들을 맞추기 시작합니다.

그것이 바로 검색창을 이용한 고고학입니다.

트랜잭션 추적 (Transaction trace)은 장기 실행되는 에이전트 세션 (Long-running agent session)을 담기에는 너무 작습니다.

상태 유지 에이전트 (Stateful agents)는 압박을 다시 가중시킵니다. DeltaBox 논문은 AI 에이전트를 파일 및 프로세스 상태를 포함한 전체 샌드박스 상태의 체크포인트 (Checkpoint) 및 롤백 (Rollback)에 의존하여 고빈도 상태 탐색 (High-frequency state exploration)을 수행하는 시스템으로 정의합니다. 변경 사항 기반의 샌드박스 상태를 사용하면, 논문은 14ms의 체크포인트 및 5ms의 롤백을 보고합니다. 이전 방식들은 롤백을 위해 전체 상태를 복사했으며, 이는 평가 중 수백 밀리초에서 수 초의 지연 시간 (Latency)을 추가했습니다. 결과적으로 이 시스템은 고빈도 상태 탐색을 가능하게 하며, 광범위한 애플리케이션을 지원합니다.

이는 UI 측면에서도 나타납니다. Agent UI Is Runtime Infrastructure에서 우리는 에이전트 이벤트 스트림 (Agent event stream)이 사용자가 조치를 취할 수 있는 상태를 포함하고 있다는 점을 언급했습니다. 모니터링은 이러한 식별자 (Identifiers)들을 공유해야 합니다. 백엔드 트레이스 (Backend trace)와 사용자에게 보이는 이벤트 (User-visible event)는 동일한 실행 (Run)에 속합니다.

AI SRE는 장애 발생 프롬프트 이전부터 시작됩니다

“AI SRE”라는 용어는 2026년에 오용될 가능성이 높지만, 유용한 의미는 평범합니다. 즉, AI 에이전트 (AI agent)가 소프트웨어 운영을 돕고, 해당 소프트웨어는 에이전트가 상황을 해석하는 데 장애 예산 (Incident budget)을 낭비하지 않도록 충분한 구조를 제공한다는 것입니다.

Causely 논문은 SRE 분야의 AI에 관한 구체적인 수치를 제시합니다. 저자들은 논문에서 AI를 사용하는 워크플로 (Workflows)가 가공되지 않은 텔레메트리 (Raw telemetry)로부터 환경 상태를 도출하는 방식과, 그 대가로 지불해야 하는 토큰 (Tokens), 지연 시간 (Latency), 그리고 해석 오류 (Interpretation errors)에 대해 설명합니다. 결함이 주입된 24개의 마이크로서비스 (Microservice) OpenTelemetry 데모 애플리케이션에서, 인과적 근거 설정 (Causal grounding)을 통해 평균 진단 시간 (Mean time to diagnosis)을 63% 단축하고, 토큰 소비를 60% 줄였으며, 도구 호출 (Tool calls)을 78% 감소시켰고, 근본 원인 정확도 (Root-cause accuracy)를 75%에서 100%로 향상시켰습니다.

AI SRE는 오용될 것이지만, 유용한 프레임워크는 간단합니다. 에이전트가 소프트웨어 운영을 돕고, 소프트웨어는 해당 에이전트가 해석에 장애 예산을 소진하지 않도록 충분한 구조를 제공하는 것입니다.

에이전트를 모니터링한다는 것은 에이전트를 실행하는 서비스를 위한 프로덕션 모니터링 (Production monitoring)을 구축하는 것을 의미합니다. 그 작업은 데이터 모델링 (Data modeling), 보존 (Retention), ID 전파 (Identity propagation), 상관관계 (Correlation), 저장 (Storage), 스키마 (Schema), 그리고 권한 (Permissions)에 관한 것입니다. 지루한 작업이죠. 그래서 아무도 하고 싶어 하지 않습니다. 하지만 그 작업이 지루한 상태로 유지되고 AI SRE라는 가짜 약 (Snake oil)으로 변하지 않는 한, 바로 그렇기 때문에 중요합니다.

또한 신호(signal)에서 이슈(issue)로 이어지는 루프를 완성해야 합니다. 신호는 티켓(ticket)을 생성하고 해당 티켓에 증거를 첨부해야 하며, 그 후 사람이 해당 작업에 대해 수행하는 조치에 따라 평가자(evaluator) 또는 릴리스 게이트(release gate)를 계속 업데이트해야 합니다. 우리는 에이전트 실패는 티켓을 생성해야 한다 (Agent Failures Should Open Tickets)에서 에이전트 실패가 어떻게 티켓을 생성해야 하는지에 대해 작성한 바 있습니다.

소유권은 대시보드 아래에 존재해야 합니다

에이전트 모니터링은 소유권이 대시보드 내부에만 존재할 때 실패합니다.

Who Owns This Agent?는 에이전트의 동작은 영향을 받는 당사자들에게 보이지만, 책임 있는 운영자나 계정은 식별할 수 없는 귀속 격차(attribution gap)를 관찰합니다. 엔터프라이즈 버전의 경우는 매우 명백합니다. 금융 에이전트가 고객 기록을 업데이트합니다. 보안 에이전트가 티켓을 수정합니다. 코딩 에이전트가 풀 리퀘스트(pull request)를 생성합니다. 지원 에이전트가 이메일을 보냅니다. 각 사례에서 기록에는 시스템, 계정, 정책(policy), 그리고 운영자(operator)가 명시되어야 합니다.

그 답이 "로그를 확인하라"가 되어서는 안 됩니다. 제발 부탁입니다.

에이전트 귀속(attribution)은 권한 상태(permission state), 세션 ID(session identity), 그리고 배포의 롤백 컨텍스트(rollback context)와 함께 모니터링의 일부를 구성합니다. 사용자에게 보이는 이벤트와 이를 유발한 백엔드 작업은 공유된 기록을 가져야 합니다. 슈퍼바이저(Supervisor) 및 스웜(swarm) 시스템은 서로 다른 책임을 가진 에이전트들에게 결정을 분산시키며, 이것이 바로 멀티 에이전트 오케스트레이션(multi-agent orchestration)이 단순한 느낌(vibe)이 아니라 아키텍처 선택이어야 하는 이유입니다.

프로덕션 기록은 대시보드 외부에서도 생존해야 합니다. 저는 탐정 놀이 없이도 다음과 같은 지루한 질문에 답할 수 있는 원장(ledger)을 원합니다: 어떤 실행(run)인지, 어떤 소유자인지, 어떤 권한인지, 어떤 도구(tool)인지, 어떤 체크포인트(checkpoint)인지, 어떤 평가자(evaluator)인지, 어떤 부작용(side effect)인지 말입니다. 대시보드는 단순한 뷰(view)로 남을 수 있습니다. 하지만 기록은 기질(substrate)이 되어야 합니다.

에이전트 함대가 도착하기 전에 모니터링 기질을 구축하십시오

AI 에이전트를 모니터링하는 것은 플랫폼 역량(platform capability)이며, 그 자체의 소유권(ownership), 예산(budget), 그리고 장애 모드(failure modes)를 가집니다. 이를 그러한 방식으로 취급해야 결국 벤더 비교(vendor comparisons)가 유용해집니다. 스티어링 데크(steering deck)는 나중에 해도 됩니다.

장애 추적(incident tracking)과 모니터링이 제대로 작동하려면 증거에 구조(structure)가 필요합니다. Agent Failures Should Open Tickets에서 주장했듯이, 전체 프롬프트(prompt)를 저장하는 것이 안전하지 않을 수 있으며, 가공되지 않은 로그(raw logs)만으로는 충분하지 않습니다. 장애 대응(incident response)을 가능하게 하는 필드들을 저장하십시오: 호출된 도구(tool called), 거부된 대안(rejected alternatives), 인간의 정책 결정(human policy decision), 권한(permissions), 세션 비용(session cost), 재시도 이유(retry reason), 체크포인트 포인터(checkpoint pointer), 평가 결과(evaluator result), 그리고 최종 부수 효과(final side effect)입니다. 민감한 정보는 거버넌스(govern)를 적용하고, 운영 정보는 쿼리(queryable)가 가능하도록 유지하십시오.

모니터링을 복구 작업(repair work)과 연결하는 것도 중요합니다. 실패한 평가기(evaluators)는 이슈(issues)를 생성해야 합니다. 비용 이상(cost anomalies)은 소유자에게 페이지(page)를 보내거나 워크플로(workflow)를 제한(throttle)해야 합니다. 반복적인 도구 오류(tool errors)는 복구 루프(repair loop)를 열어야 합니다. 롤백(rollback) 시에는 체크포인트(checkpoint), 차이점(diff), 그리고 인간의 결정 경로(human decision path)가 반드시 첨부되어야 합니다. 고객 데이터를 수정하기 위한 인간의 승인(human approval)은 Slack의 스크린샷이 아니라 트레이스(trace)에 첨부되어야 합니다.

이것이 AI 에이전트 인프라(infrastructure)의 화려하지 않은 부분입니다. 하지만 바로 이 지점에서 프로덕션 에이전트(production agents)가 관리 가능한 수준이 됩니다. 에이전트는 영리할 수 있습니다. 하지만 런타임(runtime)은 느슨해서는 안 됩니다.

AI 에이전트를 모니터링하는 것은 인프라 워크로드(infrastructure workload)입니다. 에이전트는 메모리(memory), 부수 효과(side effects), 비용(cost), 소유권(ownership), 상태(state), 그리고 판단 루프(judgment loops)를 가진 실행 중인 시스템입니다. 대시보드(dashboard)는 연기를 보고할 수 있습니다. 하지만 모니터링 기질(monitoring substrate)은 불이 왜 났는지 설명할 수 있어야 합니다.