현장에서 에이전트 PoC 결과표를 보면 가장 먼저 completion rate가 올라온다. 요청을 처리했는지, 문서를 만들었는지, 티켓을 닫았는지 본다. 그런데 운영 회의에서 진짜 문제가 되는 것은 “못 했다”가 아니다. “끝내긴 했는데 그렇게 하면 안 됐다”다.
완료율은 운영 리스크를 가린다
task completion은 필요한 지표다. 하지만 단독 지표가 되면 위험하다. 완료율은 결과만 본다. 어떤 권한으로 조회했는지, 어떤 데이터를 노출했는지, 승인 없이 어떤 tool을 호출했는지, 예외 상황을 사람에게 넘겼는지는 놓친다.
최근 에이전트 평가 연구도 같은 방향으로 움직인다. IBM Research의 ST-WebAgentBench는 raw task success를 넘어 Completion Under Policy, 즉 정책을 지킨 완료만 인정하는 지표를 제안했다. 같은 문제의식이다. “완료”와 “허용된 완료”는 다르다.
AX Ops에서 성공은 업무 결과와 운영 규칙을 동시에 통과한 상태다. 둘 중 하나만 맞으면 아직 성공이 아니다.
unsafe-success는 실패보다 늦게 발견된다
실패는 눈에 띈다. 답을 못 했고, tool call이 깨졌고, 사용자가 다시 문의한다. 그래서 로그에 남고 개선 backlog가 된다.
unsafe-success는 조용하다. 고객에게 답변이 나갔고, 내부 시스템 상태가 바뀌었고, 사용자는 만족했다. 하지만 나중에 감사, 보안 점검, 고객 민원, 현업 예외 처리에서 발견된다. 이때는 이미 “그 방식으로 해도 된다”는 사용 패턴이 조직 안에 남는다.
그래서 평가는 2축으로 쪼개야 한다.
| 구분 | task completion | policy compliance | 판정 |
|---|---|---|---|
| 정상 성공 | 통과 | 통과 | 운영 허용 |
| 일반 실패 | 실패 | 통과 | 기능 개선 |
| 안전 차단 | 실패 | 통과 | 올바른 거절 또는 에스컬레이션 |
| unsafe-success | 통과 | 실패 | 운영 차단 |
이 표에서 가장 중요한 칸은 마지막이다. 성과 보고서에는 성공으로 보이지만 운영 책임자에게는 사고 후보인 영역이다.
평가는 답변이 아니라 궤적을 봐야 한다
에이전트가 단순 답변을 넘어 tool을 쓰면 최종 문장만 평가해서는 부족하다. 어떤 context를 읽었는지, 어떤 memory를 참조했는지, 어떤 tool을 어떤 인자로 호출했는지, 중간에 승인 조건을 만났는지 봐야 한다.
AgentCanary는 에이전트 평가가 최종 응답이나 단일 tool call이 아니라 전체 trajectory를 소비해야 한다고 설명한다. Outcome Safety, Security Awareness, Task Utility처럼 차원을 분해해 보는 접근도 같은 맥락이다.
AX Ops에서는 unsafe-success eval을 다음 네 층으로 설계한다.
- 업무 완료 검증: 요청된 일이 실제 시스템 상태에서 끝났는지 확인한다.
- 정책 위반 검증: 권한, 데이터 범위, 승인, 금지 행위를 별도 판정한다.
- 에스컬레이션 검증: 거절해야 할 때 거절했는지, 사람에게 넘겨야 할 때 넘겼는지 본다.
- 재현 로그 검증: 같은 입력과 상태에서 판정 근거를 다시 확인할 수 있게 남긴다.
Microsoft의 agent evaluation 문서도 test case, assertion, quality signal, grader를 분리해 반복 가능한 평가 루프를 만들라고 설명한다. 기업 현장에서는 여기에 policy compliance assertion을 독립 축으로 박아 넣어야 한다.
지표 이름부터 운영 언어로 바꿔야 한다
unsafe-success eval은 모델 품질팀만의 일이 아니다. 업무 오너, 보안, 준법, IT 운영이 같은 표를 봐야 한다. 그래서 지표 이름은 연구 용어보다 운영 언어가 낫다.
예시는 단순하다.
- TCR: Task Completion Rate
- PCR: Policy Compliance Rate
- SSR: Safe Success Rate, 완료와 정책 준수를 모두 통과한 비율
- USR: Unsafe Success Rate, 완료했지만 정책을 위반한 비율
경영진에게는 TCR보다 SSR을 보고해야 한다. 운영 책임자에게는 USR backlog가 필요하다. 개발팀에는 USR을 만든 trace, tool, policy rule, test case가 내려가야 한다.
이렇게 나누면 논쟁이 줄어든다. “모델이 좋아졌는가”가 아니라 “업무를 끝내면서도 지켜야 할 선을 지켰는가”로 회의가 바뀐다.
참고
- IBM Research, “ST-WebAgentBench: A Benchmark for Evaluating Safety and Trustworthiness in Web Agents”, 2026: https://research.ibm.com/publications/st-webagentbench-a-benchmark-for-evaluating-safety-and-trustworthiness-in-web-agents--1
- Microsoft Research, “Optimizing Agent Planning for Security and Autonomy”, 2026: https://www.microsoft.com/en-us/research/publication/optimizing-agent-planning-for-security-and-autonomy/
- arXiv, “AgentCanary: A Security Evaluation Framework for Autonomous AI Agents in Real Executable Environments”, 2026: https://arxiv.org/abs/2606.10484
- arXiv, “Adversarial Pragmatics for AI Safety Evaluation”, 2026: https://arxiv.org/abs/2607.01153
- Microsoft Learn, “Agent evaluation overview”, 2026: https://learn.microsoft.com/it-ch/microsoft-365/copilot/extensibility/evaluation-overview
완료율을 올리는 일과 운영 가능한 성공을 정의하는 일은 다르다. AX LABS는 이 차이를 평가 지표와 운영 루프로 고정한다. AX Ops 방법론 →