AX LABS
← 블로그 AX Ops 방법론

신뢰는 런타임에서 측정된다

에이전트 평가는 대시보드가 아니라 제어 신호다

AX LABS 5분 읽기

현장에서 AI 에이전트 PoC가 멈추는 지점은 비슷하다. 데모에서는 답을 잘한다. 그런데 운영 회의로 들어가면 질문이 바뀐다. 이 답을 믿어도 되는가. 어떤 근거로 말했는가. 이 도구 호출은 승인된 행위인가. 사고가 나면 누가 재현할 수 있는가.

이 질문에 “모델을 더 좋은 것으로 바꾸겠다”는 답은 부족하다. 운영에 들어간 에이전트는 문장을 생성하는 시스템이 아니라 행동하는 시스템이다. 그래서 신뢰도는 배포 전 평가표가 아니라 런타임 제어 신호로 다뤄야 한다.

네 지표는 품질 점수가 아니라 브레이크다

ARS, RGC, ACR, PAAS는 서로 다른 불안을 나눠서 본다. 하나의 “정확도” 숫자로 묶으면 운영자가 아무 결정을 못 한다.

지표 보는 질문 낮을 때의 조치
ARS: Agent Reliability Score 주어진 목적을 안정적으로 완수했는가 재시도, 플랜 재작성, 사람 검토
RGC: RAG Grounding Confidence 답변이 검색 근거에 붙어 있는가 재검색, 불확실성 표시, 답변 보류
ACR: Attribution Completeness Ratio 주요 주장에 출처가 충분히 붙었는가 인용 보강, 주장 삭제, 초안 전환
PAAS: Policy-Aligned Action Score 행위가 정책·권한·목적에 맞는가 도구 호출 차단, 승인 요청, 권한 축소

최근 프리프린트인 “A Unified Evaluation and Governance Framework for Trustworthy LLM Agents”는 이 네 지표를 에이전트 추론 루프 안에서 계산하고, 낮은 RGC나 PAAS가 나오면 검색 재구성·불확실성 표시·사람 개입·안전하지 않은 도구 실행 차단으로 연결하는 구조를 제안한다. 핵심은 점수 자체가 아니다. 점수가 다음 행동을 바꾼다는 점이다.

런타임 trust metrics는 보고용 KPI가 아니라 에이전트의 권한을 조절하는 운영 장치다.

먼저 계측하고 나중에 평가하지 않는다

많은 조직이 순서를 거꾸로 잡는다. 먼저 에이전트를 만들고, 나중에 로그를 붙이고, 마지막에 평가 대시보드를 얹는다. 이 방식은 운영 사고를 설명할 수는 있어도 막지는 못한다.

실전 순서는 반대다.

  1. 업무별 허용 행위를 먼저 정의한다.
  2. 답변·근거·도구 호출·승인 흐름을 trace 단위로 남긴다.
  3. 네 지표를 세션 중간에 계산한다.
  4. 임계값에 따라 자율권을 축소하거나 사람에게 넘긴다.

OpenAI Agents SDK는 LLM generation, tool call, handoff, guardrail, custom event를 trace로 남기는 구조를 제공한다. AWS Bedrock AgentCore도 invocation, latency, error, session 같은 runtime observability 지표를 문서화한다. 이런 도구가 의미 있으려면 로그 수집에서 끝나면 안 된다. ARS·RGC·ACR·PAAS가 trace 위에서 계산되고, guardrail이나 tool gate로 되돌아가야 한다.

PAAS가 낮으면 답변 품질은 의미 없다

현장에서는 답변이 맞아도 실행이 틀리는 경우가 더 위험하다. 고객 정보를 조회할 권한이 없는 세션에서 조회 도구를 호출한다. 결재 전 단계인데 외부 발송 API를 실행한다. 사용자의 원래 목적과 다른 방향으로 subagent가 작업을 확장한다.

이때 필요한 것은 “나중에 감사하자”가 아니다. 실행 직전에 막는 runtime control이다. AARM v1 사양은 AI-driven action을 실행 전에 intercept, authorize, audit하는 시스템 범주를 정의하고, identity binding, semantic distance tracking, telemetry export, least privilege 같은 요구사항을 제시한다. PAAS는 이 레이어와 붙어야 살아난다.

PAAS 운영 규칙은 단순해야 한다.

  • 정책 위반 후보는 실행하지 않는다.
  • 목적 이탈 신호가 있으면 권한을 줄인다.
  • 고위험 도구는 승인 없이는 호출하지 않는다.
  • 차단·수정·승인·실행 결과를 receipt로 남긴다.

복잡한 윤리 선언보다 이 네 줄이 운영에 더 가깝다.

도입은 네 지표를 게이트로 묶는 일이다

AX Ops에서 runtime trust metrics 도입은 평가 프로젝트가 아니다. 운영 설계다. 업무 프로세스, 권한 모델, RAG 품질, trace 스키마, 승인 흐름을 한 번에 맞춘다.

첫 적용 범위는 좁게 잡는다. 내부 문서 질의, 리포트 초안, 코드 리뷰, 영업 제안서 검토처럼 근거와 정책을 분리해 볼 수 있는 업무가 좋다. 여기서 ARS는 완료 품질을 보고, RGC와 ACR은 근거 품질을 보고, PAAS는 행위 허용성을 본다. 네 점수가 함께 움직일 때 운영자는 “믿을지 말지”가 아니라 “어디까지 맡길지”를 결정한다.

참고

AI 에이전트를 운영에 올릴 조직은 모델 비교표보다 먼저 런타임 게이트를 설계해야 한다: AX Ops 방법론 →