AX LABS
← 블로그 AX Ops 방법론

에이전트는 네 지표로 산다

trace보다 운영 지표가 먼저다

AX LABS 7분 읽기

에이전트를 운영에 올린 팀이 가장 먼저 겪는 문제는 장애가 아니다. 대시보드는 초록색인데 현장은 찜찜하다. 응답은 나갔고 API도 정상인데, 고객 요청은 끝나지 않았거나 담당자가 뒤에서 다시 처리한다. 이 상태를 observability라고 부르면 운영이 무너진다.

프로덕션 에이전트는 LLM 호출 묶음이 아니다. 목표를 이해하고, 컨텍스트를 읽고, 도구를 호출하고, 필요하면 사람에게 넘기는 실행 시스템이다. 그래서 지표도 모델 중심이 아니라 업무 실행 중심으로 잡아야 한다.

성공은 응답이 아니라 완료다

첫 번째 지표는 Task Completion이다. 에이전트가 답을 했는지가 아니라 사용자의 업무가 끝났는지를 본다.

완료 지표는 세 층으로 잡는다. 사용자가 의도한 목표, 시스템에 남은 완료 이벤트, 사후 평가 결과다. 상담 종료, 티켓 처리, 견적 생성, 결재 상신처럼 업무마다 완료 정의가 다르다. 이 정의가 없으면 모든 응답이 성공처럼 보인다.

LangSmith는 2025년 10월 Multi-turn Evals를 소개하며 전통적인 uptime 관측만으로는 에이전트가 사용자의 목표를 달성했는지 알 수 없다고 못 박았다. 에이전트 평가는 단일 응답보다 session/thread 단위에서 시작해야 한다. (langchain.com)

반드시 볼 지표 운영 질문 놓치면 생기는 일
Task Completion 업무가 끝났는가 응답은 많은데 현장 재작업이 는다
Tool Execution Integrity 도구 호출이 의도대로 끝났는가 잘못된 조회·수정·전송이 숨어든다
Context Grounding 어떤 근거와 기억으로 판단했는가 오래된 정보가 자신 있게 재사용된다
Run Budget Burn 성공 한 건에 얼마의 시간·토큰·재시도가 들었는가 비용과 지연이 조용히 번진다

도구 호출은 에이전트의 손이다

두 번째 지표는 Tool Execution Integrity다. 에이전트가 어떤 도구를 왜 불렀고, 결과가 무엇이었고, 실패 후 어떻게 복구했는지 남겨야 한다.

OpenAI Agents SDK의 tracing은 에이전트 실행 중 LLM generation, tool call, handoff, guardrail, custom event를 수집한다. 이는 프로덕션 관측의 최소 구조다. tool call이 trace 밖에 있으면 에이전트의 실제 행동이 빠진다. (openai.github.io)

OpenTelemetry의 GenAI semantic conventions도 GenAI span, metric, event를 통해 공급자·모델·작업명·도구 호출을 공통 형식으로 남기도록 정리하고 있다. 특정 벤더 화면보다 중요한 것은 나중에 바꿔도 해석 가능한 실행 기록이다. (opentelemetry.io)

여기서 봐야 할 것은 단순 실패율이 아니다. schema mismatch, 권한 거절, 빈 결과, retry, rollback, human approval 대기까지 같은 trace 안에 들어와야 한다. 에이전트 사고는 대개 모델 응답문이 아니라 도구 경계에서 난다.

컨텍스트 실패는 로그에 늦게 나타난다

세 번째 지표는 Context Grounding이다. 에이전트가 어떤 문서, 메모리, 검색 결과, 사용자 상태를 근거로 판단했는지 보는 지표다.

현장에서 자주 보는 실패는 hallucination보다 오래된 컨텍스트다. 모델은 멀쩡하게 답한다. trace의 LLM call도 정상이다. 그런데 검색된 문서 버전이 낡았거나, memory에 남은 과거 조건이 현재 업무를 오염시킨다.

그래서 retrieval id, 문서 버전, 생성 시각, memory read/write, 권한 범위를 실행 단위에 붙인다. Google Cloud Vertex AI Agent Engine도 OpenTelemetry 기반 telemetry를 통해 agent, model, tool call 흐름을 추적하도록 안내한다. 운영에서 필요한 것은 예쁜 transcript가 아니라 판단 근거의 계보이다. (docs.cloud.google.com)

에이전트 observability의 단위는 API 호출이 아니라 “업무 한 건이 끝날 때까지의 실행 경로”다.

비용과 지연은 성공 건 기준으로 본다

네 번째 지표는 Run Budget Burn이다. 평균 latency나 총 token만 보면 운영 판단이 흐려진다. 성공한 업무 한 건을 끝내는 데 들어간 시간, token, tool wait, retry, loop depth를 함께 봐야 한다.

Datadog은 2025년 6월 agentic AI monitoring 기능을 발표하며 latency, token usage, error, 평가 프레임워크를 에이전트 운영 관측의 핵심으로 묶었다. AWS OpenSearch의 2026년 글도 OpenTelemetry 기반 agent debugging에서 execution flow graph, token tracking, tool invocation visibility를 강조한다. (datadoghq.com)

비용 지표는 절감용이 아니다. runaway loop, 불필요한 tool fan-out, 과도한 context 주입을 잡는 안전 지표다. 특히 성공 건 기준으로 보지 않으면 “비싸지만 유용한 업무”와 “실패했는데 비싼 실행”이 섞인다.

참고와 다음 행동은 지표 설계에서 시작한다

참고한 최근 자료는 아래와 같다.

AX Ops에서 observability는 개발팀의 로그 과제가 아니다. 운영 책임자, 현업 프로세스 오너, 보안·감사 조직이 같은 실행 기록을 보고 같은 결정을 내리게 만드는 장치다. 네 지표를 먼저 합의한 뒤 trace, eval, alert, review queue를 붙여야 한다. 에이전트를 운영 자산으로 다루려면 지표 설계부터 다시 잡아야 한다: AX Ops 방법론 →