Agent Observability(에이전트 관측성)

한 줄 정의

Agent Observability라는 말은 배포된 AI 에이전트가 어떤 추론 단계를 거치고, 어떤 모델을 부르고, 어떤 도구 사용을 실행하고, 어디서 느려지거나 실패했는지 따라보는 운영 개념이야. 에이전트가 한 번 답하고 끝나는 챗봇이 아니라 여러 턴, 도구 호출, MCP 서버, 다른 에이전트까지 오가는 구조가 되면 로그 한 줄로는 원인을 찾기 어렵거든.

Google Cloud 문맥에서는 이 말이 Agent Platform의 최적화 묶음에 들어가. 공식 문서는 배포된 에이전트와 MCP 서버의 성능, 행동, 상태를 지표, 실행 흔적, 로그로 본다고 설명해. 2026년 5월 5일 문서 기준 Preview 기능이라서, 지금은 정식 안정화 기능처럼 단정하기보다 운영 관측이 어디까지 열렸는지 확인하는 말로 읽는 게 좋아.

어떻게 작동하나

기본 재료는 telemetry, 그러니까 실행 상태를 남기는 데이터야. 에이전트와 MCP 서버가 OpenTelemetry 형식으로 실행 흔적, 지표, 로그를 Google Cloud Observability 쪽 저장소에 보내야 대시보드와 관계 그래프가 채워져. 그래서 이 개념은 “나중에 로그를 보면 되겠지”보다 앞에 있어. 설계할 때부터 어떤 작업 단계 기록(span), 토큰 사용량, 도구 호출, 오류 요약을 남길지 정해야 운영자가 원인을 찾을 수 있어.

관측 화면은 보통 이렇게 나눠 읽으면 돼.

• 개요 화면은 세션 수, 평균 turn 수, 호출 수, 입력·출력 토큰 사용량, 트래픽, 오류율, p50·p95·p99 지연을 보여 줘.
• 모델 화면(Models)은 기반 모델별 p95 지연, 호출 수, 오류율, 할당량 실패, 토큰 사용량을 따로 보여 줘.
• 도구 화면(Tools)은 연결된 외부 도구와 서비스별 p95 지연, 호출 수, 오류율을 보여 줘. 도구를 아예 호출하지 않은 대화 빈도도 여기서 확인할 수 있어.
• 평가 화면(Evaluation)은 응답 품질, 안전성, 환각 비율, 도구 사용 품질 같은 온라인 모니터를 보여 줘.

실행 흔적 화면(Traces)은 한 세션이나 한 요청을 span 그래프로 펼쳐. 모델 입력, 응답, 도구 호출, 부가 정보가 순서대로 남기 때문에 “답이 틀렸다”에서 멈추지 않고 어느 단계에서 잘못된 도구를 골랐는지, 어느 외부 API가 늦었는지, 어떤 입력이 다음 판단을 흔들었는지 볼 수 있어. 에이전트 디버깅은 여기서 일이 시작돼.

관계 화면(Topology)은 여러 에이전트와 MCP 서버 사이의 관계를 그래프나 표로 보여 줘. 전체 시스템 지도로 의존성을 보고, 단일 에이전트 관계도로 특정 에이전트의 들어오고 나가는 의존성을 따로 볼 수 있어. 다만 관계 그래프도 telemetry와 등록 정보에 기대기 때문에, 처음부터 계측하지 않은 실행 경로는 비어 보일 수 있어.

왜 중요한가

에이전트 운영에서 자주 막히는 문제는 “실패했는데 왜 실패했는지 모르는 상태”야. 모델이 답을 잘못 만든 건지, 도구 호출이 권한 오류로 막힌 건지, MCP 서버가 느린 건지, 여러 턴 대화에서 상태가 꼬인 건지, Runtime이 밀린 건지 한 화면에서 갈라야 해. 관측성은 이 판단을 평균 점수나 최종 답변이 아니라 실행 흔적으로 옮겨.

예를 들어 고객지원 에이전트가 환불 정책을 잘못 안내했다면 최종 답변만 봐서는 원인이 좁혀지지 않아. 실행 흔적을 보면 사용자 세션, 검색 단계, 도구 호출, 모델 응답이 이어져 있고, 평가 화면에서는 응답 품질, 안전성, 환각 비율, 도구 사용 품질 같은 온라인 모니터를 같이 볼 수 있어. 그러면 프롬프트를 고칠지, 도구 권한을 고칠지, 검색 데이터를 고칠지 판단이 빨라져.

또 하나는 비용과 지연이야. agent는 단일 API 호출보다 더 비싸고 느려지기 쉬워. 한 번의 요청 안에서 모델 호출, 도구 호출, MCP 서버 왕복이 여러 번 겹치면 평균 응답 시간보다 p95와 도구별 오류율이 더 중요해질 수 있어. 실행 흔적이 없으면 “모델이 느리다”로 뭉개기 쉽고, 실제로는 특정 도구 하나가 병목일 수도 있어.

주의해서 볼 점

먼저 관측성과 Eval의 차이를 분명히 봐야 해. Eval은 품질을 점수화하고, 관측성은 실행 흔적과 운영 상태를 보여 줘. p95는 느린 요청을 찾는 지연 지표고, 도구 사용 기록은 외부 API나 업무 도구가 어디서 실패했는지 알려 줘. MCP는 도구 서버와 에이전트 사이의 경계를 잡아 주는 쪽이야. 이 넷을 같이 봐야 “무엇이 나빴는지”와 “어디서 나빴는지”가 맞물린다.

두 번째는 데이터 노출이야. 실행 흔적과 프롬프트·응답 로그에는 모델 입력, 응답, 도구 호출, 실행 요약이 들어갈 수 있어. 사내 문서, 고객 정보, 결제 정보가 도구 호출 안에 섞인다면 로그 마스킹, 보관 기간, 접근 권한, 감사 로그를 먼저 정해야 해. 관측을 켰다가 민감한 데이터를 더 넓게 복제하면 그건 관측이 아니라 운영 사고에 가까워져.

세 번째는 표준과 벤더 경계야. OpenTelemetry는 생성 AI 에이전트 span, 모델 span, 지표, event 같은 공통 형식을 제시하지만, 2026년 5월 기준 생성 AI semantic conventions는 development 상태로 표시돼. Google Cloud 안에서 시작하더라도 나중에 다른 관측 저장소로 옮길 계획이 있다면 어떤 속성이 표준이고 어떤 속성이 Google Cloud 전용인지 확인해야 해.