Agentic AI를 도입하기 전에 준비해야 할 Observability 기준

요약

Agentic AI를 운영 환경에 붙일 때 가장 먼저 준비해야 할 것은 모델 선택이 아니라 관측 가능성, 즉 Observability 기준이다. Agent는 단순히 답변을 생성하는 것을 넘어 도구를 호출하고, 외부 시스템을 조회하고, 여러 단계의 판단을 거쳐 결과를 만든다.

그래서 운영자는 "정답이 나왔는가"만 볼 수 없다. 어떤 사용자 요청에서 시작됐고, 어떤 Agent 버전이 동작했고, 어떤 도구를 어떤 권한으로 호출했으며, 실패했을 때 어느 단계가 원인이었는지를 추적할 수 있어야 한다.

이 글을 읽으면 좋은 사람

클라우드 운영, DevOps, SRE, 플랫폼 엔지니어링, LLMOps 업무에서 Agentic AI 도입을 검토하는 분들을 위한 글이다.

특히 AWS Bedrock Agent, Bedrock AgentCore, Azure AI Foundry, 사내 Runbook 자동화, RAG 기반 운영 도우미를 실제 업무에 연결하려는 팀이라면 도입 전에 어떤 로그와 지표를 준비해야 하는지 점검하는 데 도움이 된다.

왜 지금 Observability가 중요한가

기존 애플리케이션의 Observability는 대체로 로그, 메트릭, 트레이스 세 가지 축으로 설명된다. 요청이 들어오고, 서비스가 처리하고, 데이터베이스나 외부 API를 호출한 뒤 응답하는 흐름을 추적한다.

Agentic AI도 표면적으로는 비슷해 보인다. 사용자가 질문하고, 모델이 응답하고, 결과가 반환된다. 하지만 실제 운영 흐름은 훨씬 복잡하다.

예를 들어 "어제 밤 장애 원인을 정리해줘"라는 요청을 받은 Agent는 다음과 같은 단계를 거칠 수 있다.

사용자 요청
  -> Agent 정책 확인
  -> 로그 조회 도구 선택
  -> CloudWatch 또는 Azure Monitor 조회
  -> Kubernetes 이벤트 확인
  -> 이전 장애 기록 검색
  -> 원인 후보 정리
  -> 조치 제안 또는 승인 요청

이때 최종 답변만 저장하면 운영자는 중요한 질문에 답할 수 없다.

• Agent가 어떤 로그를 근거로 원인을 판단했는가
• 어떤 도구 호출이 실패했는가
• 모델 응답이 틀렸는가, 검색 결과가 부족했는가, 권한이 막혔는가
• 같은 요청을 다시 실행했을 때 왜 다른 결과가 나왔는가
• 사용자의 요청과 Agent의 실제 행동 사이에 위험한 차이가 있었는가

Agentic AI의 운영 리스크는 "AI가 틀릴 수 있다"보다 넓다. 설명 불가능한 실행, 추적되지 않는 도구 호출, 권한과 연결된 자동 조치, 근거 없는 요약이 모두 운영 리스크가 된다.

Agentic AI Observability는 무엇을 봐야 하는가

Agentic AI의 Observability는 단순한 챗봇 로그가 아니다. 최소한 다음 다섯 계층을 나눠서 봐야 한다.

계층	기록해야 할 내용	운영 질문
요청 계층	사용자, 세션, 요청 의도, 입력 채널	누가 어떤 업무를 요청했는가
Agent 계층	Agent 이름, 버전, 정책, 시스템 지시문 버전	어떤 Agent가 어떤 기준으로 판단했는가
모델 계층	모델 이름, 프롬프트 버전, 토큰 사용량, 응답 지연	비용과 품질이 어디서 흔들렸는가
도구 계층	호출한 API, Runbook, 검색 도구, 권한, 결과	실제 시스템에 어떤 접근이 있었는가
평가 계층	성공 여부, 사용자 피드백, 안전성 점검, 회귀 테스트 결과	운영 품질이 좋아지고 있는가

전통적인 APM에서는 HTTP 요청 하나의 latency와 error rate가 핵심일 수 있다. Agentic AI에서는 "한 요청 안에서 몇 번의 reasoning 단계와 tool call이 발생했는가"가 더 중요해진다.

운영 전에 정해야 할 핵심 신호

1. Trace ID와 Session ID

Agentic AI는 한 번의 사용자 요청이 여러 모델 호출, 검색 요청, API 호출, 승인 대기로 이어질 수 있다. 이 흐름을 하나로 묶는 Trace ID가 없으면 장애 분석이 어렵다.

준비해야 할 기준은 간단하다.

• 사용자 요청마다 고유한 Trace ID를 만든다.
• 대화형 Agent라면 Session ID 또는 Thread ID를 함께 남긴다.
• 모델 호출, 검색 호출, 도구 호출, 승인 이벤트가 같은 Trace ID로 연결되게 한다.
• 운영 대시보드에서 Trace ID 하나로 전체 실행 흐름을 볼 수 있게 한다.

OpenTelemetry의 GenAI semantic conventions는 GenAI 모델, Agent, 도구 실행, 이벤트, 메트릭을 다루는 방향으로 확장되고 있다. 다만 일부 GenAI 규약은 아직 development 상태이므로, 운영팀은 외부 표준을 참고하되 내부 로그 스키마 버전을 함께 관리하는 편이 안전하다.

2. Agent 버전과 정책 버전

Agentic AI는 모델만 바뀌어도 결과가 달라질 수 있지만, 실제로는 Agent 정책, 도구 설명, 프롬프트, 승인 조건, 검색 인덱스가 모두 결과에 영향을 준다.

운영 로그에는 다음 값이 남아야 한다.

• Agent 이름
• Agent 버전
• 프롬프트 또는 시스템 지시문 버전
• 연결된 도구 목록의 버전
• 승인 정책 버전
• 배포 환경

이 값이 없으면 "지난주에는 정상 동작했는데 오늘은 왜 다르게 답했는가"를 설명하기 어렵다. Agentic AI 운영에서 버전 관리는 코드 릴리스 관리와 거의 같은 수준으로 다뤄야 한다.

3. Tool Call 로그

Agentic AI의 핵심은 외부 도구 호출이다. 도구 호출을 추적하지 않으면 Agent의 실제 영향 범위를 알 수 없다.

Tool Call 로그에는 다음 정보가 필요하다.

항목	예시
도구 이름	cloudwatch_log_query, aks_event_reader, runbook_search
호출 목적	장애 원인 확인, 배포 상태 조회, 비용 이상 탐지
입력 파라미터	리전, 클러스터명, 시간 범위, 검색 키워드
실행 권한	IAM Role, Service Principal, Managed Identity
결과 요약	성공, 실패, timeout, permission denied
민감정보 처리	마스킹 여부, 저장 제외 필드

중요한 것은 "Agent가 어떤 생각을 했는가"를 과도하게 저장하는 것이 아니라, "Agent가 어떤 행동을 했고 그 행동이 어떤 결과를 만들었는가"를 재구성할 수 있게 하는 것이다.

4. 비용과 성능 지표

Agentic AI는 한 번의 사용자 요청 안에서 여러 번 모델을 호출할 수 있다. 그래서 일반적인 API latency만 봐서는 실제 비용과 병목을 알기 어렵다.

운영 지표는 다음처럼 나눠서 봐야 한다.

• 전체 요청 처리 시간
• 모델 호출별 latency
• 도구 호출별 latency
• 토큰 사용량
• 요청당 모델 호출 횟수
• 요청당 도구 호출 횟수
• 캐시 hit ratio
• 실패한 tool call 비율
• 사용자 요청당 예상 비용

특히 장애 대응, 로그 분석, 보안 이벤트 분석처럼 컨텍스트가 긴 업무에서는 토큰 사용량과 검색 호출 횟수가 빠르게 늘 수 있다. 비용 대시보드는 월말 정산용이 아니라 운영 품질 지표로 봐야 한다.

5. 평가 지표와 피드백 루프

Agentic AI는 "응답이 반환됐다"는 것만으로 성공을 판단하기 어렵다. 사용자가 보기에는 그럴듯하지만 실제로는 잘못된 로그를 근거로 설명했을 수 있다.

그래서 운영 전부터 평가 기준을 정해야 한다.

• 답변이 근거 로그나 문서와 연결되는가
• 위험한 조치를 사람 승인 없이 제안하거나 실행하지 않는가
• 실패 원인을 모를 때 모른다고 말하는가
• 같은 유형의 장애에서 일관된 Runbook을 제안하는가
• 운영자가 수정한 피드백이 다음 평가 데이터셋에 반영되는가

LangSmith 같은 LLM 애플리케이션 운영 도구는 tracing, dashboard, alert, offline evaluation, online evaluation 같은 기능을 통해 품질 모니터링과 평가 흐름을 지원한다. 특정 도구를 반드시 써야 한다는 뜻은 아니지만, Agentic AI 운영에서는 로그 수집과 평가 체계를 분리해서 생각하면 안 된다는 점을 보여준다.

AWS와 Azure 관점에서 보면

AWS에서는 Amazon Bedrock AgentCore Observability가 Agent 실행 경로, 중간 출력, 병목, 실패, 세션 수, latency, duration, token usage, error rate 같은 데이터를 CloudWatch 기반으로 확인할 수 있도록 설명하고 있다. 또한 OpenTelemetry 호환 telemetry를 내보낼 수 있다는 점은 기존 Observability 스택과 연결할 때 중요한 기준이 된다.

AWS 환경에서 운영팀이 먼저 확인할 것은 다음이다.

• Bedrock Agent 또는 AgentCore Runtime의 trace가 CloudWatch에서 어떻게 보이는가
• Lambda, Systems Manager Automation, Step Functions, EKS API 호출과 Agent trace를 어떻게 연결할 것인가
• IAM Role 단위로 tool call을 구분할 수 있는가
• CloudTrail, CloudWatch Logs, Agent trace가 같은 사건을 서로 다른 관점에서 설명할 수 있는가

Azure에서는 Azure Monitor Application Insights가 OpenTelemetry 기반 telemetry 수집과 Application Map, Live Metrics, Failures, Performance, Logs, Workbooks 같은 분석 경험을 제공한다. Microsoft Learn 문서에서는 AI Agents도 Application Insights의 데이터 수집 진입점 중 하나로 다루고 있다.

Azure 환경에서는 다음을 점검해야 한다.

• Azure AI Foundry 또는 사내 Agent 앱의 trace를 Application Insights와 연결할 수 있는가
• Azure Monitor Logs에서 Agent 요청, 모델 호출, 도구 호출을 같은 correlation ID로 조회할 수 있는가
• Entra ID, Managed Identity, Key Vault 접근 기록과 Agent 실행 기록을 함께 감사할 수 있는가
• 업무형 Agent라면 Microsoft 365, Copilot Studio, 사내 API 호출 기록을 어떻게 분리하고 보존할 것인가

핵심은 특정 벤더 콘솔을 잘 쓰는 것이 아니다. Agent가 어떤 요청으로 시작해서 어떤 권한으로 어떤 시스템을 건드렸는지, 나중에 운영자가 같은 경로를 다시 따라갈 수 있어야 한다.

도입 전 체크리스트

• Agent 요청마다 Trace ID, Session ID, User ID를 남긴다.
• Agent 이름, 버전, 프롬프트 버전, 정책 버전을 기록한다.
• 모델 호출, 검색 호출, tool call을 하나의 trace로 연결한다.
• tool call에는 도구 이름, 입력 범위, 실행 권한, 결과 상태를 남긴다.
• 민감정보가 prompt, retrieval result, trace, log에 저장되는 범위를 정한다.
• 토큰 사용량, 요청당 비용, 모델 호출 횟수, tool call 횟수를 지표화한다.
• 실패 유형을 model error, retrieval error, permission error, tool error, policy block으로 나눈다.
• 운영자가 검토한 실패 사례를 evaluation dataset으로 되돌리는 절차를 만든다.
• CloudTrail, Azure Activity Log, Kubernetes audit log 같은 기존 감사 로그와 연결한다.
• 사람 승인 지점과 자동 실행 지점을 trace에서 구분한다.

흔한 실수

• 최종 답변만 저장한다: 답변만 있으면 근거와 실행 경로를 확인할 수 없다. 최소한 tool call과 trace는 함께 남겨야 한다.
• 모델 지표만 본다: latency와 token usage도 중요하지만, 운영 리스크는 권한, 도구 호출, 승인 흐름에서 더 자주 발생한다.
• 프롬프트를 무조건 전체 저장한다: 디버깅에는 도움이 되지만 개인정보, 계정 정보, 내부 문서가 노출될 수 있다. 저장 범위와 마스킹 기준을 먼저 정해야 한다.
• 평가를 배포 전 테스트로만 본다: Agent는 운영 데이터와 사용자 피드백을 통해 실패 양상이 드러난다. 온라인 평가와 피드백 루프가 필요하다.
• 기존 모니터링 도구에 이름만 붙인다: Agentic AI는 일반 API와 다른 실행 단계를 가진다. Agent, model, retrieval, tool, approval 단위를 구분해서 계측해야 한다.

마무리

Agentic AI를 운영에 도입할 때 Observability는 나중에 붙이는 부가 기능이 아니다. 권한 설계와 마찬가지로, 운영 전에 먼저 정해야 하는 안전장치다.

좋은 Agent 운영 체계는 "AI가 얼마나 똑똑한가"보다 "AI가 무엇을 보고, 무엇을 호출했고, 왜 그런 결과가 나왔는지 설명할 수 있는가"에서 출발한다. 로그와 trace가 준비되지 않은 Agent는 자동화 도구라기보다 추적하기 어려운 실행 주체가 될 수 있다.

운영팀이 지금 준비해야 할 기준은 거창하지 않다. 요청, Agent 버전, 모델 호출, 검색 근거, 도구 호출, 권한, 평가 결과를 하나의 흐름으로 연결하는 것이다. 이 기준이 있어야 Agentic AI를 실험 단계에서 실제 운영 환경으로 옮길 수 있다.

참고자료

• OpenTelemetry - Semantic conventions for generative AI systems
• OpenTelemetry - GenAI agent and framework spans
• AWS Documentation - Observe your agent applications on Amazon Bedrock AgentCore Observability
• Microsoft Learn - Application Insights OpenTelemetry observability overview
• LangSmith Docs - Observability
• LangSmith Docs - Evaluation
• arXiv - From Agent Traces to Trust: Evidence Tracing and Execution Provenance in LLM Agents