PoC에서는 에이전트가 그럴듯하게 답하면 박수를 받는다. 운영에서는 다르다. 답이 맞아도 근거가 비어 있으면 멈춰야 하고, 근거가 좋아도 정책을 어기면 실행을 막아야 한다. 현장에서 반복되는 문제는 모델 성능 부족이 아니다. 신뢰를 측정하는 위치가 너무 늦다는 점이다.
2026년 TechRxiv에 공개된 preprint는 ARS, RGC, ACR, PAAS를 LLM agent inference loop 안에 넣어야 한다고 정리한다. OpenAI의 trace grading 문서도 agent trace에 구조화된 점수와 라벨을 붙여 오류 지점을 찾는 방식을 설명한다. AWS AgentCore 역시 runtime invocation, latency, error, span, application log를 관측 대상으로 둔다. 방향은 같다. 운영 신뢰는 배포 전 벤치마크가 아니라 실행 중 trace에서 나온다. (d197for5662m48.cloudfront.net)
네 지표는 점수가 아니라 제어 신호다
ARS는 최종 업무가 맞게 끝났는지 본다. RGC는 답변의 사실 주장과 검색·문서 근거가 붙어 있는지 본다. ACR은 인용해야 할 판단 단위 중 실제 attribution이 완성된 비율이다. PAAS는 실행하려는 action이 정책을 위반하지 않는지 본다.
| 지표 | 보는 것 | 런타임에서 잡아야 할 신호 | 낮을 때 조치 |
|---|---|---|---|
| ARS | 업무 완결성과 정답성 | task outcome, evaluator score, 재시도 결과 | 자동 완료 금지, human review |
| RGC | 근거 기반성 | claim-evidence match, 검색 신선도, 문서 충돌 | 재검색, 불확실성 표시 |
| ACR | 출처 완결성 | 인용 누락, 출처-주장 매핑 누락 | 답변 보류, citation 보강 |
| PAAS | 정책 부합성 | 금지 action, 권한 초과, 승인 누락 | tool call 차단, escalation |
Runtime trust metrics는 대시보드 지표가 아니라 실행 권한을 조절하는 브레이크다.
이 네 지표를 평균 내서 하나의 ‘신뢰 점수’로 만들면 실패한다. ARS가 높아도 PAAS가 낮으면 실행하면 안 된다. RGC가 낮은데 ACR만 높으면 틀린 문서에 성실히 출처를 단 셈이다. 운영 설계에서는 지표별 임계값과 조치가 분리되어야 한다.
측정 지점은 출력 이후가 아니라 tool call 전이다
많은 조직이 최종 답변만 평가한다. 그 방식은 보고서 생성에는 쓸 수 있지만, 주문 변경·환불·계정 수정·승인 요청 같은 side effect 업무에는 늦다. 에이전트가 tool을 호출하기 전, 호출한 후, 최종 응답 전 세 지점에 trust check를 둬야 한다.
OpenAI Agents SDK의 guardrails는 input, output, tool guardrail과 tripwire 개념을 제공한다. 특히 blocking mode는 guardrail이 통과하기 전 agent 실행을 시작하지 않게 해 side effect를 줄이는 구조다. Claude Agent SDK hooks도 PreToolUse, PostToolUse 같은 실행 이벤트에 개입할 수 있게 한다. 이 기능들은 그 자체가 방법론은 아니다. 그러나 AX Ops에서는 이 지점을 ARS·RGC·ACR·PAAS 계산 위치로 고정한다. (openai.github.io)
실전 적용 순서는 단순하다.
- 업무를 action class로 나눈다. 조회, 제안, 초안, 변경, 승인 요청은 같은 위험이 아니다.
- action class별로 PAAS 정책을 먼저 쓴다. 금지·허용·조건부 허용을 코드화한다.
- RGC와 ACR은 claim 단위로 남긴다. 문단 단위 채점은 너무 거칠다.
- ARS는 업무 결과 기준으로 본다. 말이 자연스러운지는 보조 신호다.
- 네 지표의 하락이 어떤 제동으로 이어지는지 runbook에 박는다.
임계값보다 중요한 것은 처분 규칙이다
현장에서 지표 논의가 길어지는 이유는 숫자를 먼저 정하기 때문이다. 먼저 정해야 할 것은 처분이다. 어느 경우에 재검색할지, 어느 경우에 사람에게 넘길지, 어느 경우에 실행을 중단할지 합의해야 한다.
예를 들어 RGC가 낮으면 답변을 꾸미지 말고 검색을 다시 한다. ACR이 낮으면 인용을 보강하기 전까지 외부 발송을 막는다. PAAS가 낮으면 ARS와 관계없이 tool call을 차단한다. ARS가 낮으면 결과를 폐기하고 동일 trace를 평가 데이터로 보낸다.
이때 dashboard는 운영팀용이고, gate는 시스템용이다. dashboard만 있으면 회고가 된다. gate가 있어야 운영 통제가 된다. AX Ops는 두 가지를 분리하지 않는다. trace, score, policy decision, human override, incident record를 한 흐름으로 묶는다.
참고
- 2026 TechRxiv preprint, “A Unified Evaluation and Governance Framework for Trustworthy LLM Agents” — ARS, RGC, ACR, PAAS를 정의하고 runtime governance loop를 제안: https://doi.org/10.36227/techrxiv.176799772.28164151/v1 (d197for5662m48.cloudfront.net)
- OpenAI Developers, “Trace grading” — agent trace에 구조화된 score와 label을 붙여 평가하는 방식: https://developers.openai.com/api/docs/guides/trace-grading (platform.openai.com)
- OpenAI Agents SDK, “Guardrails” — input, output, tool guardrail과 tripwire 구조: https://openai.github.io/openai-agents-python/guardrails/ (openai.github.io)
- AWS Docs, “AgentCore generated runtime observability data” — invocation, latency, errors, spans, application logs 등 runtime 관측 항목: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/observability-runtime-metrics.html (docs.aws.amazon.com)
요약하면 ARS·RGC·ACR·PAAS는 평가팀의 리포트 항목이 아니다. 에이전트가 실행 권한을 얻고 잃는 운영 규칙이다. 이 규칙을 업무 trace에 심는 설계가 필요하다면 AX Ops 방법론 →