AI 에이전트를 평가할 때 가장 흔한 실수는 일반 챗봇처럼 “정답을 잘 말했는가”만 보는 것입니다. 에이전트는 모델의 답변을 넘어 검색, 데이터 조회, 코드 실행, 외부 도구 호출, 승인 요청, 재시도와 종료 판단까지 연속된 행동을 수행합니다. 최종 문장이 자연스러워도 잘못된 계정에 메시지를 보내거나, 같은 작업을 반복해 비용을 키우거나, 중간 실패를 성공으로 보고하면 운영 시스템으로서는 실패입니다.
따라서 평가의 단위도 한 번의 응답이 아니라 완료된 유효 과업이어야 합니다. 사용자가 원한 결과가 정확한 권한과 절차 안에서 만들어졌는지, 허용된 시간과 비용 안에 끝났는지, 실패했을 때 안전하게 멈추거나 복구했는지를 함께 확인해야 합니다.
NIST AI 위험관리 프레임워크는 AI 위험을 거버넌스, 맥락 파악, 측정, 관리의 연결된 활동으로 다루며, 생성형 AI 프로필은 위험이 설계·개발·배포·운영·폐기 등 수명주기 전반에서 나타날 수 있다고 설명합니다. 이 관점은 에이전트 평가를 단발성 벤치마크가 아니라 운영 체계로 설계해야 하는 이유를 보여줍니다.
평균 정확도가 높은 에이전트보다, 중요한 실패를 구분하고 사람에게 넘길 줄 아는 에이전트가 실제 업무에서는 더 안전할 수 있습니다. 평가는 성능 경쟁이 아니라 배포 가능한 행동 범위를 정하는 과정입니다.
답변 평가와 에이전트 평가는 무엇이 다른가
일반적인 질의응답 평가는 입력과 출력의 관계를 중심으로 봅니다. 반면 에이전트는 목표를 해석하고 계획을 세운 뒤 여러 도구를 호출하며 상태를 바꿉니다. 각 단계는 별도의 실패 가능성을 갖고, 앞 단계의 작은 오류가 뒤에서 실제 행동으로 확대될 수 있습니다.
이 흐름에서 “모델이 맞는 말을 했다”는 것은 일부에 불과합니다. 실무 평가는 최소한 다음 질문에 답해야 합니다.
- 목표와 금지 조건을 올바르게 해석했는가.
- 필요한 도구만 선택하고 올바른 인수로 호출했는가.
- 읽기와 쓰기 권한을 구분했는가.
- 외부 결과를 그대로 믿지 않고 검증했는가.
- 반복과 재시도가 통제됐는가.
- 실패를 숨기지 않고 안전하게 멈췄는가.
- 사람이 개입해야 할 순간을 제대로 판단했는가.
첫 번째 지표는 ‘완료된 유효 과업’이다
에이전트 평가의 분모를 요청 수로 두고, 분자를 성공 응답 수로 두면 그럴듯한 성공률을 만들 수 있습니다. 하지만 성공의 정의가 느슨하면 지표는 현실을 가립니다. 예를 들어 회의 일정을 잡는 에이전트가 시간을 제안했지만 실제 캘린더에는 등록하지 않았다면, 대화는 자연스러워도 과업은 완료되지 않았습니다.
먼저 업무별 완료 조건을 기계적으로 확인할 수 있게 정의해야 합니다.
| 업무 | 완료 조건 | 실패로 보는 사례 |
|---|---|---|
| 고객 문의 답변 | 승인된 근거를 사용하고 필수 안내를 포함해 답변 초안 생성 | 근거 없는 환불 약속, 정책 누락 |
| 회의 일정 등록 | 참석자·시간대·회의실을 검증한 뒤 캘린더 이벤트 생성 | 중복 일정, 잘못된 시간대, 등록 없이 완료 보고 |
| 데이터 분석 | 지정 데이터와 기간을 사용해 재현 가능한 계산 결과 생성 | 다른 기간 사용, 계산식 누락, 출처 불명 |
| 코드 변경 | 테스트 통과, 변경 범위 준수, 리뷰 가능한 diff 생성 | 관련 없는 파일 수정, 테스트 우회, 비밀정보 노출 |
| 비용 결재 보조 | 한도·증빙·승인자를 확인하고 사람 승인 단계까지 전달 | 자동 승인, 한도 초과, 증빙 누락 |
실무에서 유용한 최상위 지표는 다음과 같습니다.
유효 과업 성공률 = 모든 필수 완료 조건을 충족한 과업 수 ÷ 전체 평가 과업 수
부분 성공은 별도 상태로 보관하는 편이 좋습니다. 성공과 실패 사이에 “사람 이관”, “안전 중단”, “복구 후 성공”, “외부 시스템 오류”를 두면 모델 문제와 운영 환경 문제를 분리할 수 있습니다.
여덟 개 축으로 평가표를 만든다
평가표는 하나의 종합 점수보다 서로 다른 실패를 보여주는 여러 축으로 구성해야 합니다. 다음 여덟 축이면 대부분의 기업용 에이전트에서 시작점으로 사용할 수 있습니다.
| 평가 축 | 대표 지표 | 확인하려는 질문 |
|---|---|---|
| 과업 성공 | 유효 과업 성공률, 완전 완료율 | 실제 목표를 끝냈는가 |
| 결과 품질 | 사실 일치, 근거 충실도, 형식 준수 | 결과를 믿고 사용할 수 있는가 |
| 도구 실행 | 호출 성공률, 인수 정확도, 불필요 호출 수 | 올바른 도구를 효율적으로 썼는가 |
| 비용 | 성공 1건당 총비용, 재시도 비용 비중 | 결과에 비해 비용이 합리적인가 |
| 지연 | 완료 시간 P50·P95·P99, 첫 유효 행동 시간 | 사용자가 기다릴 수 있는가 |
| 안전성 | 권한 위반, 데이터 노출, 위험 행동, 정책 위반 | 허용 범위를 넘지 않는가 |
| 복구력 | 오류 탐지율, 복구 성공률, 무한 반복 발생률 | 실패를 인지하고 정상화하는가 |
| 사람 협업 | 이관 정확도, 불필요 승인 요청, 검토 시간 | 사람을 적절한 순간에 참여시키는가 |
평균만 보면 긴 꼬리의 위험을 놓칩니다. 지연은 P95와 P99를 보고, 비용은 성공 과업과 실패 과업을 나눠야 합니다. 안전성은 평균 점수보다 중대 사고 건수와 사고율을 별도로 관리해야 합니다.
골든 세트는 정상 질문 모음이 아니다
좋은 평가 데이터셋은 평소 잘되는 예시만 모으지 않습니다. 최소 네 종류의 시나리오가 필요합니다.
1. 정상 시나리오
가장 자주 발생하고 업무 가치가 큰 요청입니다. 실제 운영 분포를 반영해 전체 평가셋의 중심을 구성합니다. 단순 예제보다 입력 길이, 첨부파일, 사용자 표현, 데이터 결측 등 현실적인 변형을 포함해야 합니다.
2. 경계 시나리오
업무 규칙이 모호하거나 조건이 충돌하는 상황입니다. 예산은 맞지만 증빙이 없거나, 사용자의 요청과 조직 정책이 충돌하거나, 여러 도구가 서로 다른 결과를 반환하는 사례가 여기에 해당합니다. 좋은 에이전트는 억지로 완료하지 않고 부족한 정보를 요청해야 합니다.
3. 공격 시나리오
프롬프트 인젝션, 권한 상승 유도, 민감정보 추출, 외부 문서 속 악성 지시, 위험한 도구 인수처럼 의도적으로 시스템을 흔드는 입력입니다. OWASP의 LLM 애플리케이션 위험 목록은 공격 시나리오를 설계할 때 유용한 출발점이 됩니다.
4. 복구 시나리오
API 시간 초과, 중복 요청, 일부 도구 실패, 네트워크 단절, 잘못된 중간 상태처럼 운영에서 반복되는 장애를 넣습니다. 여기서는 첫 시도의 성공보다 오류 탐지, 재시도 제한, 상태 롤백, 사람 이관이 평가 대상입니다.
출시 전 골든 세트만 반복하면 실제 사용자 실패가 반영되지 않습니다. 운영 중 발생한 실패를 개인정보 제거 후 원인별로 분류하고, 재현 가능한 테스트 사례로 추가해야 회귀를 막을 수 있습니다.
자동 채점과 사람 검토를 계층화한다
모든 사례를 사람이 읽으면 비용이 커지고, 모든 사례를 모델 심사자에게 맡기면 판단 편향을 놓칠 수 있습니다. 검사 방법을 확실성에 따라 층으로 나누는 편이 효율적입니다.
결정적 검사
정답을 코드로 판정할 수 있는 항목입니다. 도구 이름, JSON 스키마, 필수 필드, 데이터베이스 상태, 파일 변경 범위, 수치 오차, 금지된 권한 사용 등을 검사합니다. 가능하면 가장 먼저 늘려야 하는 평가 방식입니다.
규칙 기반 검사
필수 문구, 금지 표현, 출처 존재, 승인 단계, 재시도 횟수처럼 업무 규칙으로 판정합니다. 규칙이 너무 많아지면 실제 품질보다 형식 맞추기에 치우칠 수 있으므로, 사용자 결과와 직접 연결되는 규칙만 남겨야 합니다.
모델 기반 심사
요약의 충실도, 설명의 명확성, 답변 간 우열처럼 코드로 판단하기 어려운 항목에 사용합니다. 다만 심사 모델의 점수를 진실로 취급하면 안 됩니다. 사람이 평가한 표본과 일치율을 확인하고, 순서 편향과 장문 선호 같은 편향을 교정해야 합니다. 절대 점수 하나보다 평가 기준별 점수와 판단 근거를 저장하는 편이 좋습니다.
사람 검토
고위험 업무, 새로운 실패 유형, 자동 채점 간 불일치, 사용자 불만이 발생한 사례를 우선 검토합니다. 무작위 표본도 일정 비율 유지해야 자동 평가가 놓치는 패턴을 발견할 수 있습니다.
실제 업무 결과
고객 재문의율, 처리 시간, 수정률, 승인 반려율, 장애 티켓, 매출 또는 비용 절감처럼 업무 결과와 연결합니다. 오프라인 점수가 좋아도 사용자 결과가 나빠지면 평가셋이나 성공 정의가 현실을 반영하지 못하는 것입니다.
비용은 토큰이 아니라 성공 결과당 계산한다
에이전트는 여러 모델 호출과 도구 실행을 거치므로 호출 1회의 가격만 비교하면 왜곡됩니다. 실패한 시도, 재시도, 검색, 코드 실행, 외부 API, 사람 검토 시간까지 포함해야 합니다.
성공 1건당 총비용 = 모델 비용 + 도구·인프라 비용 + 실패·재시도 비용 + 사람 검토 비용 ÷ 유효 성공 건수
계산할 때는 다음 항목을 분리해 기록합니다.
- 입력·출력 토큰과 모델별 호출 수
- 검색, 브라우저, 코드 실행, 벡터 조회 등 도구별 비용
- 성공 전 재시도 횟수와 실패 종료 비용
- 캐시 적중률과 중복 호출률
- 사람 승인·수정에 걸린 시간
- 과업 유형과 난이도
저렴한 모델이 더 자주 실패하면 성공 결과당 비용은 오히려 높아질 수 있습니다. 반대로 비싼 모델을 모든 단계에 쓰기보다 분류와 형식 검사는 작은 모델, 고난도 판단은 큰 모델, 확정적 계산은 코드로 분리하면 품질과 비용을 함께 개선할 수 있습니다.
지연은 평균이 아니라 사용자 흐름으로 본다
에이전트의 지연은 한 번의 모델 응답 시간과 다릅니다. 계획, 도구 대기, 재시도, 승인 대기까지 누적됩니다. 다음 네 시간을 따로 측정하면 병목을 찾기 쉽습니다.
- 첫 유효 행동 시간: 사용자가 요청한 뒤 첫 진행 상태나 유용한 결과가 나오기까지의 시간
- 도구 대기 시간: 외부 시스템 응답을 기다린 시간
- 모델 처리 시간: 모델 호출 전체에 사용한 시간
- 완료 시간: 완료 조건을 모두 충족하기까지의 총시간
평균 완료 시간만 보면 일부 사용자가 겪는 긴 지연이 가려집니다. P50은 일반 경험, P95는 빈번한 불만 구간, P99는 장애와 용량 계획에 유용합니다. 재시도 횟수와 함께 보면 느린 이유가 모델인지 외부 도구인지 분리할 수 있습니다.
안전성은 별도 통과 조건으로 둔다
안전성을 종합 점수에 섞으면 높은 정확도가 위험 행동을 상쇄하는 문제가 생깁니다. 예를 들어 과업 성공률이 95%라도 민감정보를 외부로 전송한 사례가 있다면 그대로 배포하기 어렵습니다. 중대 안전 항목은 가중치가 아니라 독립적인 릴리스 게이트로 두어야 합니다.
최소한 다음 항목을 테스트합니다.
- 외부 문서나 웹페이지의 지시를 시스템 명령보다 우선하지 않는가.
- 읽기 권한과 쓰기 권한을 구분하고, 위험한 쓰기 작업 전에 확인을 받는가.
- 사용자·고객·회사 기밀을 불필요하게 프롬프트나 로그에 남기지 않는가.
- 도구 인수를 허용 목록과 스키마로 검증하는가.
- 금액, 수신자, 삭제 범위처럼 되돌리기 어려운 필드를 실행 직전에 재확인하는가.
- 반복 횟수, 예산, 실행 시간, 호출 가능한 도구에 상한이 있는가.
- 오류가 발생하면 성공한 것처럼 보고하지 않고 상태를 명확히 설명하는가.
- 즉시 중단, 권한 회수, 로그 보존, 사람 이관 절차가 있는가.
NIST 생성형 AI 프로필은 위험이 모델 자체뿐 아니라 사용 맥락, 인간과의 상호작용, 구성요소 통합, 운영 단계에서 달라질 수 있음을 강조합니다. 따라서 같은 모델을 사용하더라도 이메일 작성 에이전트와 결제 실행 에이전트의 안전 임계값은 달라야 합니다.
회귀 평가와 릴리스 게이트를 설계한다
새 모델이나 프롬프트가 전체 평균을 올려도 특정 핵심 업무가 나빠질 수 있습니다. 릴리스 비교는 전체 점수, 업무군별 점수, 고위험 시나리오, 비용·지연을 모두 봐야 합니다.
예시 기준은 다음과 같습니다. 숫자는 설명용이며 실제 임계값은 조직의 위험 허용도와 기준 버전으로 정해야 합니다.
| 항목 | 예시 릴리스 기준 | 차단 조건 |
|---|---|---|
| 유효 과업 성공률 | 기준 버전 이상, 핵심 업무군 90% 이상 | 핵심 업무군 3%p 이상 하락 |
| 근거 충실도 | 검증 표본 95% 이상 | 출처와 다른 핵심 주장 발견 |
| 도구 인수 정확도 | 99% 이상 | 잘못된 쓰기 대상 1건 이상 |
| 성공 1건당 비용 | 기준 버전 대비 10% 이내 | 품질 향상 없이 20% 이상 증가 |
| 완료 시간 P95 | 서비스 목표 이내 | 타임아웃 또는 무한 반복 발생 |
| 중대 안전 사고 | 0건 | 권한 위반·민감정보 노출 1건 이상 |
| 사람 이관 | 필요한 사례의 95% 이상 | 고위험 사례를 자동 실행 |
릴리스 전에는 동일한 평가셋을 현재 버전과 후보 버전에 모두 실행하고, 통계적 변동과 시나리오 구성을 확인합니다. 릴리스 후에는 소수 트래픽에서 시작해 운영 지표를 비교하고, 안전 임계값을 넘으면 자동으로 이전 버전이나 사람 처리로 전환해야 합니다.
운영 대시보드에 필요한 최소 이벤트
평가를 지속하려면 에이전트의 추론 전문을 모두 저장할 필요는 없지만, 과업과 행동의 구조화된 이벤트는 남겨야 합니다. 민감정보를 제거한 뒤 다음 필드를 기록하는 방식이 실용적입니다.
| 이벤트 필드 | 목적 |
|---|---|
| 과업 ID·유형·난이도 | 사례별 추적과 비교 |
| 모델·프롬프트·도구 버전 | 회귀 원인 확인 |
| 시작·종료·단계별 시간 | 지연 병목 분석 |
| 도구명·결과 상태·재시도 | 외부 의존성과 복구 분석 |
| 완료 상태·실패 분류 | 성공률과 실패 원인 계산 |
| 토큰·도구·인프라 비용 | 성공 결과당 비용 계산 |
| 사람 개입 시점과 결과 | 이관 품질 측정 |
| 안전 정책 판정과 차단 이유 | 사고 예방과 감사 |
로그에는 원문 개인정보나 인증정보를 기본적으로 남기지 말고, 보존 기간과 접근 권한을 정해야 합니다. 평가용 재현 데이터도 실제 운영 데이터와 분리해 관리하는 편이 안전합니다.
4주 도입 순서
1주차: 성공 정의와 실패 분류
가장 가치가 큰 과업 3~5개를 고르고, 각각의 완료 조건과 금지 조건을 문서화합니다. 최근 운영 사례에서 대표 성공과 실패를 모아 실패 원인을 모델, 도구, 데이터, 권한, 사용자 입력, 외부 시스템으로 나눕니다.
2주차: 골든 세트와 자동 검사
과업별 정상·경계·공격·복구 사례를 만들고, 정답을 코드로 확인할 수 있는 항목부터 자동화합니다. 모든 사례에 중요도와 위험 등급을 붙입니다. 고위험 사례는 수가 적어도 별도 통과 조건으로 둡니다.
3주차: 기준선과 릴리스 게이트
현재 운영 버전의 성공률, 비용, 지연, 안전성, 사람 개입률을 측정합니다. 한 번의 최고 기록이 아니라 여러 차례 반복해 변동 범위를 확인합니다. 그 뒤 업무별 하한선과 차단 조건을 정합니다.
4주차: 운영 연결과 회귀 루프
배포 전 자동 평가, 소수 트래픽 배포, 운영 모니터링, 실패 사례의 평가셋 환류를 연결합니다. 새로운 모델이나 프롬프트는 같은 절차를 통과하게 하고, 평가셋 변경 이력도 코드처럼 리뷰합니다.
실무 체크리스트
- 성공을 자연스러운 답변이 아니라 검증 가능한 완료 조건으로 정의했는가.
- 정상·경계·공격·복구 시나리오가 모두 포함돼 있는가.
- 과업 성공률과 부분 성공, 사람 이관, 안전 중단을 구분하는가.
- 모델 오류와 도구·데이터·네트워크 오류를 분리하는가.
- 성공 1건당 비용과 실패·재시도 비용을 계산하는가.
- 평균 지연뿐 아니라 P95와 P99를 보는가.
- 중대 안전 항목을 종합 점수와 분리해 릴리스 게이트로 두는가.
- 모델 기반 심사 점수를 사람 평가 표본으로 보정하는가.
- 운영 실패를 재현 테스트로 되돌리는 절차가 있는가.
- 모델·프롬프트·도구·평가셋 버전을 함께 기록하는가.
평가 체계가 에이전트의 실제 제품 경계를 만든다
AI 에이전트는 더 많은 자율성을 줄수록 가치와 위험이 함께 커집니다. 평가가 약하면 팀은 데모에서 보이는 자연스러운 결과를 과신하고, 장애가 난 뒤에야 권한과 복구 조건을 설계하게 됩니다. 반대로 완료 조건, 비용, 지연, 안전성, 사람 이관을 미리 측정하면 어느 업무까지 자동화하고 어디서 멈출지 구체적으로 결정할 수 있습니다.
처음부터 거대한 벤치마크를 만들 필요는 없습니다. 핵심 과업 몇 개의 완료 조건을 명확히 하고, 실제 실패를 골든 세트로 되돌리며, 중대 위험을 별도 통과 조건으로 두는 것부터 시작하면 됩니다. 이후 기업의 자율형 AI 에이전트 활용 사례와 AI 에이전트 기술 흐름을 함께 보면 평가 지표를 도입 우선순위와 연결하기 쉽습니다.
이 글의 조사·작성 방식은 TOPICDEEP 에디토리얼 정책에 따라 참고 자료와 갱신 기준을 공개합니다. 실제 배포 전에는 조직의 보안 정책, 법률 요구, 업무 위험도, 운영 데이터를 기준으로 별도 검증해야 합니다.
