AI 에이전트가 “완료했습니다”라고 답했다고 해서 일이 끝난 것은 아닙니다. 파일을 엉뚱한 폴더에 저장했거나, 승인받지 않은 도구를 호출했거나, 우연히 한 번만 성공했을 수 있습니다. 답변이 그럴듯한지 보는 평가는 챗봇에는 유용하지만, 외부 시스템에서 행동하는 에이전트에는 충분하지 않습니다.
Anthropic은 에이전트 평가를 입력과 채점 로직의 조합으로 설명하며 모델만이 아니라 프롬프트, 도구, 실행 환경을 포함한 전체 하네스를 함께 시험해야 한다고 강조합니다. Google Cloud도 목표 달성, 최종 응답, 도구 사용, 환각과 안전을 별도 축으로 봅니다. NIST는 도구 호출과 중간 상태가 숨어 있는 다단계 워크플로에는 행동 경로와 증거를 볼 수 있는 감사 흔적이 필요하다고 지적합니다.
이 글은 특정 평가 제품의 순위가 아니라, 작은 자동화부터 업무용 에이전트까지 적용할 수 있는 5단계 평가 설계를 제시합니다.
1단계: 성공 조건을 관찰 가능한 계약으로 바꾼다
“고객 문의를 잘 처리한다”는 평가할 수 없는 목표입니다. 먼저 성공을 시스템에서 확인할 수 있는 상태로 바꿉니다.
- 답변에 주문 번호와 환불 조건이 정확히 포함됐는가
- 티켓 상태가 실제로 ‘처리 완료’로 변경됐는가
- 같은 고객에게 중복 메일을 보내지 않았는가
- 허용된 도구와 데이터만 사용했는가
- 정해진 시간과 비용 안에 끝났는가
평가 한 건은 초기 상태 → 사용자 목표 → 허용 행동 → 성공 상태 → 금지 조건으로 작성하는 것이 좋습니다. 정답 문장 하나를 기대하기보다, 여러 표현으로도 동일한 업무 상태에 도달할 수 있게 설계합니다.
평가 세트에는 정상 사례만 넣지 않습니다. 필수 필드 누락, 모순된 요청, 도구 오류, 권한 부족, 긴 대화, 악의적 지시처럼 실제 운영에서 만날 경계·적대 사례를 함께 둡니다. 기능마다 소수의 대표 사례로 시작한 뒤 운영 장애가 생길 때마다 재현 사례를 추가하면 살아 있는 회귀 세트가 됩니다.
2단계: 말이 아니라 최종 상태를 결정적으로 검사한다
에이전트의 마지막 문장은 결과에 대한 주장일 뿐입니다. 가능한 항목은 코드로 검사하세요.
- 데이터베이스 행과 필드가 기대 상태인지
- 생성된 파일이 올바른 경로, 형식과 스키마인지
- API가 실제로 한 번만 호출됐는지
- 금액, 날짜와 식별자가 원본 데이터와 일치하는지
- 작업 실패 시 되돌리기 또는 안전한 중단이 이뤄졌는지
문장 품질을 LLM 심사자에게 맡길 수는 있지만, 존재 여부·합계·권한·호출 횟수처럼 규칙으로 확인 가능한 항목까지 맡길 이유는 없습니다. 결정적 검사는 빠르고 재현 가능하며, 모델이 바뀌어도 기준이 흔들리지 않습니다.
예를 들어 “회의를 예약했다”는 응답을 채점하지 말고 일정 시스템에 참석자, 시간대, 중복 여부와 화상회의 링크가 실제로 저장됐는지 봅니다. 이 검사를 통과한 뒤에만 어조와 설명의 명료성을 평가합니다.
3단계: 도구 호출 경로와 금지 행동을 함께 본다
같은 결과에 도달해도 경로의 안전성은 다를 수 있습니다. 고객 주소를 찾기 위해 승인된 CRM을 조회한 경우와, 권한 밖의 문서를 검색한 경우는 같은 점수를 받을 수 없습니다.
경로 평가에는 다음을 기록합니다.
- 호출한 도구와 순서
- 각 호출의 입력·출력 요약과 오류
- 읽거나 변경한 리소스
- 재시도 횟수와 중단 이유
- 사람 승인을 요청한 지점
“정확한 순서만 정답”으로 만들면 합리적인 다른 경로를 오답 처리할 수 있습니다. 그래서 필수 체크포인트, 허용 가능한 경로 집합, 절대 호출하면 안 되는 도구를 나누는 편이 좋습니다. 성공률과 함께 금지 행동 0건, 불필요한 쓰기 감소, 승인 우회 없음 같은 안전 지표를 둡니다.
NIST는 에이전트가 채점기의 허점을 이용해 실제 목표가 아닌 점수만 높이는 ‘grader gaming’ 가능성도 경고합니다. 테스트 파일 이름이나 정답 패턴을 노출하지 말고, 실행 기록을 표본 감사하며, 평가 환경의 권한을 운영보다 더 넓게 주지 마세요.
4단계: 품질·근거·안전·비용을 분리해 채점한다
하나의 종합 점수는 실패 원인을 숨깁니다. 최소한 다음 축은 따로 보세요.
| 평가 축 | 확인 질문 | 권장 채점 |
|---|---|---|
| 목표 달성 | 실제 업무 상태가 완료됐는가 | 결정적 검사 우선 |
| 근거성 | 주장과 사용 데이터가 연결되는가 | 출처 대조 + 표본 검토 |
| 도구 사용 | 적절한 도구·인수·순서를 사용했는가 | 실행 추적 규칙 |
| 안전 | 금지 데이터·행동·권한을 피했는가 | 실패 시 즉시 불합격 |
| 효율 | 지연, 토큰, 호출 수와 비용이 한도 안인가 | 수치 임계값 |
| 표현 품질 | 정확하고 명료하며 사용자에게 유용한가 | 루브릭 + 사람 표본 |
LLM 심사자는 열린 문장의 명료성이나 근거성을 대규모로 점검하는 데 유용하지만, 절대적인 판정자가 아닙니다. 모델·프롬프트에 따라 점수가 달라지고 장황함을 품질로 오해할 수 있습니다. 명확한 루브릭과 좋은·나쁜 예시를 제공하고, 심사자 점수를 정기적으로 사람 판단과 비교하세요.
보안 항목은 평균에 섞지 않는 것이 중요합니다. 개인정보 노출이나 승인 없는 결제처럼 치명적인 실패는 다른 항목의 높은 점수로 상쇄될 수 없는 게이트 조건이어야 합니다.
5단계: 회귀 평가를 배포와 운영 피드백에 연결한다
평가는 출시 전 한 번의 행사가 아닙니다. 모델, 시스템 프롬프트, 도구 스키마, 검색 인덱스 중 하나만 바뀌어도 행동이 달라집니다.
권장 운영 흐름은 다음과 같습니다.
- 코드 변경 때 빠른 핵심 세트를 실행한다.
- 배포 후보에는 전체 정상·경계·적대 세트를 실행한다.
- 성공률뿐 아니라 안전 실패, 비용과 지연의 변화도 비교한다.
- 저신뢰·고위험 작업은 사람 검토 대기열로 보낸다.
- 운영 실패를 익명화·정리해 새 회귀 사례로 추가한다.
- 평가 세트 자체도 주기적으로 중복, 누출과 현실성을 검토한다.
단일 실행의 성공률만 보지 말고 중요한 사례는 여러 번 실행해 변동성을 확인합니다. 새 모델이 평균 점수를 높여도 특정 고객군, 긴 문맥 또는 도구 오류에서 퇴행할 수 있으므로 구간별 결과를 보존하세요.
바로 적용하는 최소 평가 명세
첫 버전은 거대할 필요가 없습니다. 에이전트 기능 하나당 다음 문서와 데이터를 준비하면 됩니다.
- 정상 5건, 경계 3건, 적대 2건의 시나리오
- 각 사례의 초기 상태와 성공 상태
- 결정적 검사와 안전 게이트
- 허용 도구, 금지 도구와 승인 조건
- 품질 루브릭 3~5개와 사람 검토 표본 비율
- 지연·호출 수·비용 한도
- 실패 재현 사례를 추가할 담당자와 절차
배포 기준도 사전에 적습니다. 예를 들면 “목표 달성 95% 이상, 안전 게이트 실패 0건, p95 지연 20초 이하, 기존 핵심 사례 퇴행 없음”처럼 정합니다. 수치는 업무 위험과 비용에 맞게 조정하되 결과를 보고 나중에 유리하게 바꾸지 않습니다.
결론: 신뢰는 답변이 아니라 증거에서 나온다
좋은 에이전트 평가는 “똑똑해 보이는가”를 묻지 않습니다. 원하는 상태를 만들었는가, 허용된 방법을 썼는가, 위험할 때 멈췄는가, 다음 버전에서도 반복되는가를 확인합니다.
최종 문장, 실제 상태, 행동 경로, 안전·비용, 회귀라는 다섯 층을 분리하면 실패가 어디서 생겼는지 알 수 있습니다. 작은 결정적 검사부터 시작해 운영 사고를 평가 사례로 되돌리는 루프를 만드세요. 에이전트에 대한 신뢰는 인상적인 데모가 아니라 축적된 실행 증거에서 생깁니다.
참고 자료
- Anthropic — Demystifying evals for AI agents
- Google Cloud — Evaluate agents
- NIST — Security Considerations for AI Agents 의견 분석
- NIST — Cheating on AI Agent Evaluations
- NIST — Building Evaluation Probes into Agentic AI
평가 지표와 임계값은 업무 위험, 데이터 민감도와 법적 요구에 맞게 조정해야 합니다. 고위험 의사결정과 되돌리기 어려운 작업에는 독립적인 보안 검토와 사람 승인을 유지하세요.