인사이트 / 블로그

AI 에이전트 시리즈 · 3/6

도입 전에 반드시 검증해야 할 4가지 기준

고객이 항공권 예약 취소를 요청했습니다.

AI 에이전트가 예약 정책을 확인한 뒤, 취소와 환불이 어렵다고 안내합니다. 답변은 자연스럽습니다. 거절 사유도 맞고, 필요한 설명도 빠지지 않았습니다.

하지만 에이전트 평가는 여기서 멈추면 안 됩니다. 이제 봐야 할 질문은 세 가지입니다.

1. 답변과 업무 처리 결과가 일치하는가?

취소 불가를 안내했다면, 실제 예약도 취소되지 않은 상태로 남아 있어야 합니다.

2. 허용된 도구와 절차 안에서 처리했는가?

조회만 필요한 상황에서 승인 없이 취소 API를 호출했다면 위험한 실행입니다.

3. 같은 조건에서 같은 결론을 내는가?

같은 예약과 같은 정책이라면 다시 실행해도 같은 안내가 나와야 합니다. 즉, 이 사례에서 봐야 할 것은 답변의 자연스러움만이 아닙니다.

답변과 처리 결과, 실행 절차, 반복 안정성을 함께 봐야 합니다.

LLM 평가와 에이전트 평가의 차이

기존 LLM 평가는 주로 단일 응답의 품질을 검사합니다. 질문에 맞는지, 문장이 자연스러운지, 논리가 일관된지를 확인하는 텍스트 품질 검사에 가깝습니다.

하지만 에이전트는 답변만 남기지 않습니다. 외부 도구를 호출합니다.

DB(데이터베이스)에서 고객 정보를 조회합니다. 파일과 시스템의 상태를 직접 변경합니다.

기업의 보안 정책에 따라 실행을 중단하기도 합니다.

그래서 에이전트 평가는 "무슨 말을 했는가"보다 "업무 프로세스가 어떤 상태로 끝났는가"를 추적해야 합니다.

LLM 평가가 엔진 자체의 성능 검사라면, 에이전트 평가는 자동차가 실제 도로 위에서 제동, 조향, 센서와 맞물려 안전하게 주행하는지 검증하는 일입니다. 엔진이 아무리 좋아도 제어 장치가 엉망이면 사고가 납니다.

AI 에이전트도 마찬가지입니다.

LLM 평가와 에이전트 평가의 차이

도입 전에 던져야 할 4가지 질문

업무용 AI 에이전트를 도입하려면 다음 4가지 축을 동시에 검증해야 합니다. 첫째, Behavior(수행 결과)입니다.

목표한 태스크를 실제로 완수했는가를 봐야 합니다. 최종 결과물이 정확한지, Latency(처리 속도)가 업무 기준에 맞는지도 함께 확인해야 합니다.

둘째, Capabilities(수행 역량)입니다.

필요한 도구와 절차를 올바르게 거쳤는지 봐야 합니다. 불필요한 API 호출을 반복하지 않았는지, 비용과 시간을 낭비하지 않는 경로로 움직였는지도 평가 대상입니다.

셋째, Reliability(반복 안정성)입니다.

같은 일을 여러 번 맡겨도 일관된 품질을 유지하는지 봐야 합니다. 모호한 요청이나 예외 상황에서도 규칙적으로 작동하는지가 중요합니다.

넷째, Safety & Alignment(정책 준수)입니다.

권한과 가이드라인의 경계를 지키는지 확인해야 합니다. Prompt Injection(프롬프트 인젝션) 방어, 개인정보 보호, 내부 승인 절차 준수 여부가 여기에 들어갑니다. 우연히 맞춘 정답은 다음 실행에서 바로 무너집니다.

과정이 통제되지 않는 에이전트는 사용량이 늘어날수록 비용 관리와 품질 관리가 어려워집니다.

에이전트 평가 4축

좋은 평가는 하나의 점수로 끝나지 않습니다

에이전트 평가 환경을 설계할 때는 실제 업무 인프라도 함께 고려해야 합니다.

먼저 User Simulator(사용자 시뮬레이터)가 필요할 수 있습니다. 실제 고객은 처음부터 정보를 정확히 주지 않습니다. 중간에 말을 바꾸거나 애매하게 요구합니다. 동적인 대화 속에서 안정성을 보려면 테스트용 시뮬레이터가 필요합니다.

다음은 시스템 기록과 판단 기준의 분리입니다. DB 값이 바뀌었는지 같은 정량적 사실은 시스템 로그로 확인할 수 있습니다. 반면 정책 설명이 충분했는지, 거절 사유가 적절했는지 같은 정성적 영역은 별도의 평가 기준으로 나누어 관리해야 합니다. 필요하다면 LLM-as-a-Judge(평가 LLM)를 보조적으로 쓸 수 있습니다.

마지막은 Sandbox(샌드박스) 환경입니다. 파일 수정, DB 변경, 메일 발송처럼 권한이 넓은 에이전트를 실제 환경에 바로 붙이면 업무 피해가 생길 수 있습니다. 격리된 모의 환경에서 안전하게 반복 실행하며 평가해야 합니다.

좋은 평가 환경은 모든 것을 하나의 점수로 밀어 넣지 않습니다.

시스템 기록으로 확인할 것은 기록으로 봅니다. 정책이나 맥락처럼 단순 비교가 어려운 것은 별도 기준으로 봅니다. 실제 환경이 필요한 평가와 격리가 필요한 평가도 나눕니다.

평가 환경을 설계하는 3가지 선택

벤치마크는 점수표가 아니라 설계 도면입니다

업계에서 자주 언급되는 GAIA, Tool Decathlon, OSWorld, τ-bench 같은 벤치마크의 순위나 점수 자체가 중요한 것은 아닙니다.

우리가 주목해야 할 것은 각 벤치마크가 어떤 실패 유형을 잡아내려고 설계되었는가입니다.

우리 업무에서 AI가 실패했을 때 가장 치명적인 지점이 어디인지 먼저 정의해야 합니다.

고객 안내 오류가 문제인지, 실제 데이터 변경이 문제인지, 권한 없는 작업이 문제인지, 특정 예외 조건에서만 반복되는 실패가 문제인지 봐야 합니다.

그 실패 유형이 정리되어야 우리만의 Harness(평가 하네스)를 설계할 수 있습니다.

실패 로그는 점검 자산입니다

지난 글에서 Harness(에이전트 실행 시스템)를 다루었습니다. 평가는 이 시스템이 정말 나아지고 있는지 검증하는 가장 현실적인 방법입니다.

모델을 바꿨습니다. 프롬프트를 튜닝했습니다. 도구를 추가했습니다. 권한 정책을 수정했습니다.

이런 변경 뒤에 겉보기 답변이 더 자연스러워졌다고 안심할 수는 없습니다. 실제로는 내부 정책 위반이 늘었거나, 특정 예외 케이스에서 같은 절차를 반복하고 있을 수도 있습니다.

실서비스 운영 중 발견한 단 한 번의 실패는 단순 에러 로그로 버려져서는 안 됩니다.

다음 빌드의 새로운 Regression Test(회귀 테스트) 기준이 되어야 합니다. 그래야 코드나 프롬프트가 바뀌어도 같은 실수를 반복하지 않는지 확인할 수 있습니다.

에이전트가 진짜 업무 도구가 될수록, 평가는 답변 품질 검사에서 운영 상태 검사로 이동합니다.

결국 에이전트 평가는 솔루션 검증을 넘어 리스크 관리 영역입니다.

언어모델의 문장력에 감탄하던 관점에서 벗어나, 이 AI가 우리 회사의 데이터와 프로세스를 어떻게 바꾸는지 추적하는 관점으로 이동해야 합니다.

지금 AI 에이전트 도입을 준비 중이라면 "답변이 자연스러운가"라는 질문에서 한 걸음 더 나아가야 합니다.

잘못된 실행으로 인한 검토 비용과 복구 비용을 통제할 수 있을 때, 비로소 안전하게 비즈니스에 적용할 준비가 됩니다.

다음 글에서는 에이전트가 단발성 실행을 넘어 연속성 있게 업무를 처리하기 위한 핵심 축, Memory(메모리)를 다룹니다. Memory를 단순한 데이터 저장소가 아니라 운영 정책으로 바라봐야 하는 이유를 살펴보겠습니다.

AI 에이전트 시리즈