AX LABS
← 블로그 AX Ops 방법론

에이전트는 지표로 운영된다

프로덕션 관찰성은 로그가 아니라 운영 체계다

AX LABS 5분 읽기

현장에서 에이전트 PoC를 운영으로 넘길 때 가장 먼저 깨지는 것은 모델 성능이 아니다. “왜 이 답을 했는지”, “어느 도구에서 틀어졌는지”, “비용이 왜 갑자기 튀었는지”를 아무도 즉시 말하지 못한다. 로그는 있다. 대시보드도 있다. 그런데 운영 판단에 필요한 지표가 없다.

에이전트 observability는 trace를 저장하는 일이 아니다. 운영자가 오늘 중단할지, 제한할지, 사람에게 넘길지 판단하게 만드는 계기판이다.

성공률은 응답률이 아니라 업무 완료율이다

첫 번째 지표는 Task Completion Rate다. 단순히 API가 200을 반환했는지 보지 않는다. 사용자의 의도가 업무 결과로 닫혔는지 본다.

에이전트는 긴 경로를 돈다. LLM 호출, retrieval, tool call, handoff, guardrail이 한 실행 안에 섞인다. OpenAI Agents SDK도 agent run에서 LLM generation, tool call, handoff, guardrail, custom event를 trace로 수집한다고 문서화한다. LangSmith도 trace를 여러 run의 묶음으로 보고, multi-turn은 thread로 연결한다. 이 구조를 업무 완료 지표로 묶지 않으면 trace는 디버깅 화면에 머문다.

완료율은 세 값으로 나눠야 한다.

  • 완료: 사용자가 요청한 업무 산출물이 만들어졌다.
  • 미완료: 중간 실패, 루프, 포기, 정책 차단이 발생했다.
  • 전환: 사람, 다른 시스템, 다른 에이전트로 넘겼다.

전환은 실패가 아니다. 전환을 실패와 섞으면 운영자는 좋은 에스컬레이션을 나쁜 성능으로 오해한다.

도구 지표가 없으면 에이전트 원인을 못 찾는다

두 번째 지표는 Tool Success Rate다. 에이전트 장애의 상당수는 모델이 아니라 도구 경계에서 난다. 권한이 없고, schema가 바뀌고, 외부 API가 느리고, MCP 서버가 연결되지 않는다.

Anthropic Claude Code SDK 문서는 MCP 서버 연결 실패와 실행 중 오류를 별도 상태로 다루는 예시를 제시한다. OpenTelemetry GenAI semantic conventions도 tool execution span을 별도로 정의하고, 자동 instrumentation이 덮지 못하는 도구 호출은 애플리케이션 개발자가 직접 instrument하라고 권고한다.

도구 지표는 최소한 네 가지를 분리한다.

지표 운영 질문
tool call success 도구가 정상 응답했는가
retry count 같은 일을 반복하고 있는가
timeout/error type 느린가, 실패하는가, 권한 문제인가
wrong-tool rate 호출은 성공했지만 선택이 틀렸는가

에이전트 운영에서 “모델이 틀렸다”는 말은 대부분 너무 늦은 진단이다. 먼저 도구 경계를 봐야 한다.

컨텍스트 품질은 별도 지표로 빼야 한다

세 번째 지표는 Context Grounding Score다. RAG를 붙였다고 grounding이 생기지 않는다. 에이전트가 어떤 문서, 어떤 검색 결과, 어떤 memory를 읽었고 그것이 답변에 실제로 쓰였는지 봐야 한다.

Phoenix 문서는 trace가 model call, retrieval, tool use, custom logic을 포착해 어느 단계에서 시간이 쓰였고 행동이 발생했는지 보게 한다고 설명한다. 여기서 retrieval span을 품질 지표와 연결해야 한다. 검색이 성공했다는 사실과 좋은 근거를 가져왔다는 사실은 다르다.

운영 지표는 이렇게 잡는다.

  • source coverage: 답변 핵심 주장에 근거가 붙었는가
  • context freshness: 오래된 문서나 폐기된 정책을 참조했는가
  • retrieval miss: 필요한 근거가 없는데 답을 생성했는가
  • memory contamination: 이전 대화나 사용자 상태가 잘못 섞였는가

컨텍스트 지표가 없으면 hallucination은 사후 평가 항목으로 밀린다. 프로덕션에서는 사후 평가만으로 부족하다. 잘못된 context가 들어오는 순간 runtime에서 잡아야 한다.

비용과 지연은 품질 지표와 같이 봐야 한다

네 번째 지표는 Run Efficiency다. latency, token, tool count, loop depth, sandbox time을 한 실행 단위로 본다. 비용 대시보드와 품질 대시보드를 분리하면 운영 판단이 깨진다. 비싼 실행이 더 좋은 결과를 냈는지, 실패한 실행이 왜 토큰을 태웠는지 연결되지 않는다.

2026년 4월 OpenAI는 Agents SDK에 controlled workspace와 native sandbox execution을 확장했다고 발표했다. 장기 실행, 파일 작업, command 실행, sandbox 재시작이 운영 범위로 들어오면 비용·지연은 단순 LLM token 문제가 아니다. harness, compute, tool, storage가 함께 비용을 만든다.

AX Ops에서는 이 네 지표를 한 장의 운영판으로 묶는다.

축 반드시 보는 지표
업무 Task Completion Rate
실행 Tool Success Rate
근거 Context Grounding Score
효율 Run Efficiency

요약하면, 에이전트 observability는 trace 수집 프로젝트가 아니다. 운영 책임자가 매일 보는 지표 설계다. 먼저 네 지표를 정의하고, 그다음 도구를 붙여야 한다. AX LABS는 이 순서로 PoC 이후 운영 정착까지 설계한다. AX Ops 방법론 →

참고