요약: Gemini Enterprise Agent Platform의 Agent Observability가 GA가 되면서 신규 ADK 에이전트에는 OpenTelemetry tracing이 기본 활성화됩니다. 하지만 trace가 자동으로 생긴다고 디버깅이 자동으로 쉬워지는 것은 아닙니다. span 이름, attribute, payload 저장 정책, PII 마스킹, 실패 단계 분류를 설계해야 실제 장애 대응에 쓸 수 있습니다.
에이전트 장애는 일반 API 장애보다 원인이 복잡합니다. 사용자의 요청이 모델 계획으로 바뀌고, 모델이 tool을 고르고, tool이 외부 API를 호출하고, 결과가 다시 모델로 들어가며, 마지막에 응답이나 작업 결과가 만들어집니다. 이 흐름에서 한 단계만 실패해도 최종 결과는 이상해집니다.
Google Cloud는 2026년 6월 18일 Gemini Enterprise Agent Platform 릴리스에서 Agent Observability GA를 발표했습니다. 핵심 업데이트로 신규 ADK 에이전트의 OpenTelemetry tracing 기본 활성화, GCS를 기본 payload 저장 선택지로 권장, session execution을 단계별로 보고 trace span의 DAG를 확인하는 기능을 설명했습니다.
이 변화는 “로그를 많이 남기자”가 아닙니다. 에이전트 실행을 그래프로 보자는 뜻입니다. 어떤 판단 뒤에 어떤 tool이 호출됐고, 그 tool 결과가 어떤 응답으로 이어졌는지 연결해서 봐야 합니다.
많은 팀이 OpenTelemetry를 붙이고도 디버깅에 실패합니다. 이유는 trace가 너무 추상적이기 때문입니다. span 이름이 request, call, execute, process뿐이면 아무 의미가 없습니다. attribute도 user_id, status 정도만 있으면 원인 분석이 어렵습니다.
에이전트 trace에서는 최소한 다음 정보가 필요합니다. 사용자 요청 유형, agent version, prompt version, model, tool name, tool input summary, tool result size, retry count, refusal 여부, fallback 여부, 최종 action type입니다. 민감한 원문을 그대로 넣을 필요는 없지만, 실행 경로를 식별할 수 있는 요약은 있어야 합니다.
또 다른 문제는 payload와 trace의 분리입니다. trace에는 “tool result 200 OK”만 있고 실제 결과가 어디 저장됐는지 모르면 문제를 재현할 수 없습니다. 반대로 payload는 저장했지만 trace ID와 연결하지 않으면 찾을 수 없습니다.
에이전트 실행 하나를 root span으로 둡니다. 이름은 agent.run 정도로 통일하되 attribute에 agent_name, agent_version, user_segment, request_type, environment를 넣습니다.
그 아래에는 planning span을 둡니다. 모델이 어떤 작업 계획을 세웠는지 원문 전체가 아니라 단계 수, 선택한 전략, 필요한 tool 목록을 요약합니다. 다음으로 tool call span을 둡니다. tool.name, tool.category, input_bytes, output_bytes, status_code, latency_ms, retry_count를 넣습니다.
모델 재호출이 있다면 model.generate span을 분리합니다. model_name, input_tokens, output_tokens, cached_tokens, reasoning_effort, stop_reason을 남깁니다. 마지막에는 agent.finalize span을 두고 최종 결과 유형을 기록합니다. 예를 들어 answer_only, draft_created, external_write_requested, external_write_completed처럼 분류합니다.
이 구조를 쓰면 “응답이 이상하다”는 신고가 왔을 때 최종 답변만 보지 않아도 됩니다. planning이 잘못됐는지, tool 결과가 비었는지, 모델이 거절했는지, fallback이 엉뚱하게 탔는지 바로 좁힐 수 있습니다.
Google 릴리스 노트는 멀티모달 prompt와 response payload 저장에 GCS를 권장합니다. 이유는 대형 payload와 lifecycle management 때문입니다. 하지만 저장소가 생기면 개인정보 처리도 같이 설계해야 합니다.
원칙은 세 가지입니다. 첫째, trace attribute에는 민감 원문을 넣지 않습니다. 검색 가능한 요약과 hash만 넣습니다. 둘째, payload는 별도 bucket에 저장하고 접근 권한을 제한합니다. 셋째, 보관 기간을 짧게 시작합니다. 디버깅 목적이면 7일 또는 30일로도 충분한 경우가 많습니다.
PII 마스킹은 저장 전에 처리하는 편이 좋습니다. 나중에 분석 도구에서 가리는 방식은 원본이 이미 퍼진 뒤입니다. 이메일, 전화번호, 주민등록번호, 계좌번호, API key 패턴은 저장 전 필터링해야 합니다.
trace를 남겼다면 대시보드는 단순 latency만 보면 안 됩니다. 에이전트 운영에는 다음 지표가 필요합니다.
이 지표가 있어야 “모델이 나빠졌다” 같은 막연한 결론을 피할 수 있습니다. 실제 원인은 특정 MCP 서버 latency, prompt version 변경, tool output schema 변경일 수 있습니다.
