AI 에이전트 평가 방법의 시작은 ‘정확도 몇 %인가’가 아닙니다. 담당자가 실제로 승인할 수 있는 결과를 내는지, 정상·예외·금지 사례를 섞은 10개 내외의 업무 사례로 확인하는 일입니다. 에이전트는 여러 단계와 도구를 거칠 수 있으므로, 단일 답변만 보는 평가는 놓치는 것이 생길 수 있습니다. eval-anthropic
먼저 답: AI 에이전트 평가 방법은 10개 사례의 수용 시험이다
평가의 질문은 “모델이 똑똑한가?”가 아니라 “이 업무 결과를 이 조건에서 넘겨받아도 되는가?”입니다. 사례마다 입력, 기대 출력, 허용 여부, 승인자를 적으세요. 이는 벤더 비교 점수나 고객 성과 예측이 아닙니다. 실행 경로가 여러 단계인 시스템은 그 복잡도에 맞는 평가가 필요하다는 전문가 안내를, 운영자가 쓸 수 있는 수용 시험으로 바꾼 해석입니다. eval-anthropic
평가 전에 업무 경계를 한 문장으로 고정한다
다음 문장이 빈칸 없이 써지면 시작할 수 있습니다. “이 흐름은 [허용된 입력]을 받아 [확인 가능한 출력]을 만들며, [금지 행동]은 하지 않는다.” 도구, 지시, 가드레일은 에이전트 설계의 일부라는 OpenAI 안내를 여기서는 업무 경계를 합의하는 기준으로 사용합니다. agents-openai
체크리스트:
- 입력 원본과 민감 정보 범위를 정했는가?
- 출력의 형식과 사람이 확인할 항목을 정했는가?
- 외부 발송·금액 변경·권한 변경처럼 금지 또는 승인 대상인 행동을 적었는가?
10개 사례를 정상·예외·금지로 나눈다
| 사례 묶음 | 권장 수 | 사람의 판정 질문 |
|---|---|---|
| 정상 | 4 | 결과가 원본과 맞고 형식이 쓸 수 있는가? |
| 예외 | 4 | 누락·모호함을 임의로 메우지 않고 인계하는가? |
| 금지 | 2 | 권한 밖 행동을 시도하지 않고 멈추는가? |
위 숫자는 Morrow의 운영 제안이지 외부 기준이 아닙니다. 중요한 점은 성공 사례만 모으지 않는 것입니다. 에이전트 평가는 다단계 도구 사용과 상태 변화를 포함할 수 있으므로, 예외와 실패가 보이는 사례를 함께 남기는 편이 재현 가능한 검토에 도움이 됩니다. eval-anthropic
사람 판정과 자동 중단 기준을 함께 적는다
NIST는 생성형 AI 위험 관리를 조직의 목표와 위험 허용도에 맞춰 적용하는 틀을 제시합니다. rmf-nist Morrow의 해석으로는, 그 틀을 법률 판정이 아니라 다음 운영 질문으로 좁혀 쓰는 것이 좋습니다.
| 조건 | 자동 처리 | 사람 승인 | 중단·인계 |
|---|---|---|---|
| 필수 필드가 모두 있고 영향이 낮음 | 가능 | 표본 검토 | 오류면 대기열 |
| 원본이 모호하거나 예외 | 보류 | 담당자 판단 | 원본 보완 요청 |
| 고객 발송·가격·권한 영향 | 준비만 | 지정 승인자 | 승인 없으면 실행 금지 |
평가표로 결과와 재시험을 기록한다
사례마다 사례 ID / 입력 유형 / 기대 결과 / 실제 결과 / 승인자 판정 / 중단 여부 / 다음 수정 가설을 한 줄로 남깁니다. 실패를 숨기지 말고 같은 사례를 재시험할 수 있게 보관하세요. 이는 배포 뒤의 KPI를 대신하지 않습니다. 출시 전에는 “허용 가능한가”를, 운영 중에는 AI 업무 자동화 파일럿 KPI 가이드로 “계속 가치가 있는가”를 봅니다.
Morrow의 관점: KPI 측정과 수용 평가는 순서가 다르다
Morrow는 수용 시험을 통과하지 않은 흐름에 대해 생산성 KPI부터 약속하지 않는 편이 안전하다고 봅니다. 가드레일을 설계 요소로 두라는 안내 agents-openai를 적용하면, 첫 파일럿은 적은 사례·낮은 영향·명확한 승인 경계로 시작할 수 있습니다. 복구 경로는 사람 승인과 실패 복구 설계에서 더 자세히 점검하세요.
수용 기준을 실제 판정 문장으로 바꾼다
평가표에 “좋음”이나 “대체로 맞음”만 쓰면 다음 사람이 같은 결과를 다시 판정할 수 없습니다. 각 사례의 수용 기준은 원본 대조, 출력 형식, 행동 경계, 인계 정보의 네 문장으로 씁니다. 예를 들어 문의 요약 초안 업무라면 “원문에 없는 할인 약속을 넣지 않는다”, “확인하지 못한 사실은 확인 필요로 표시한다”, “고객 발송은 준비 상태까지만 만든다”, “누락된 계약 번호는 담당자 대기열로 보낸다”처럼 관찰 가능한 문장이 됩니다. 이것은 외부 성능 수치가 아니라 Morrow의 운영 제안입니다.
| 판정 항목 | 통과로 적을 문장 | 실패 또는 인계로 적을 문장 |
|---|---|---|
| 원본 충실성 | 원본의 필수 사실을 빠뜨리지 않고 출처 위치를 남긴다 | 원본끼리 충돌하거나 근거가 없으면 추정하지 않는다 |
| 형식 | 승인자가 정한 필드와 순서로 초안을 만든다 | 필수 필드가 비면 완료로 표시하지 않는다 |
| 행동 경계 | 허용된 읽기·분류·초안만 수행한다 | 발송·가격·권한 변경을 실행하지 않는다 |
| 인계 | 멈춘 이유와 필요한 다음 입력을 남긴다 | 모호한 결과를 정상 완료로 넘기지 않는다 |
같은 요약 정확도가 높아도 계약 종료일을 놓치면 승인자는 통과시킬 수 없습니다. 반대로 문장이 매끄럽지 않아도 원본 인용 위치와 확인 필요 항목이 분명하면 수정 가능한 초안일 수 있습니다. 언어 품질 하나로 업무 수용성을 대신 판정하지 않는 이유입니다. 에이전트 평가는 시스템 복잡도에 맞춰야 한다는 Anthropic의 안내를 업무 결과의 확인 가능성으로 좁혀 적용한 해석입니다. eval-anthropic
10개 사례를 고르는 5단계 체크리스트
- 최근 완료 업무에서 후보를 모읍니다. 이상적인 예시가 아니라 실제 입력을 쓰되, 개인정보와 고객 식별 정보는 승인된 샘플 또는 비식별 예시로 바꿉니다.
- 결과가 명확한 정상 사례 네 개를 고릅니다. 짧은 입력, 긴 입력, 여러 필드처럼 작업량을 달리합니다.
- 사람이 멈췄던 예외 사례 네 개를 고릅니다. 날짜 충돌, 필수 문서 누락, 모호한 용어, 승인 범위 밖 요청처럼 원인을 달리합니다.
- 반드시 막아야 할 금지 사례 두 개를 씁니다. 고객 발송, 가격 또는 접근 권한 변경처럼 실제 경계를 시험합니다. 합격은 실행하지 않고 인계하는 것입니다.
- 사례별 판정자를 미리 지정합니다. 실행 화면을 본 뒤 기준을 바꾸면 시험이 아니라 사후 합리화가 됩니다.
10이라는 수는 보편 규격이 아닙니다. 작은 B2B 파일럿에서 시작점을 잃지 않기 위한 Morrow의 제안입니다. 업무 영향이 크거나 입력 유형이 더 다양하면 사례를 늘리고, 아직 사례를 모을 수 없으면 자동화 이전에 업무 정의부터 보류합니다. NIST는 위험 관리를 조직의 목표와 위험 허용도에 맞춰 적용할 수 있는 틀을 제시합니다. rmf-nist
실행 로그는 한 번의 점수보다 더 쓸모 있다
각 실행에 입력 버전, 사용한 지시·도구 버전, 실제 출력, 판정, 인계 여부를 남깁니다. 로그는 감시를 위한 거대한 저장소가 아니라 실패를 재현할 최소 기록입니다. “출력 7번이 틀렸다”보다 “예외-03에서 첨부 파일이 비어 있는데 완료로 표시했다”가 다음 수정에 쓸 수 있습니다. 모델, 도구, 지시, 가드레일을 함께 설계 대상으로 본다는 OpenAI의 설명을 적용하면 실패 원인을 모델 하나에만 돌리지 않게 됩니다. agents-openai
| 로그 칸 | 최소 기록 | 다음 회의 질문 |
|---|---|---|
| 사례 | 사례 ID와 비식별 입력 버전 | 같은 입력으로 다시 실패하는가? |
| 실행 | 지시·도구·권한의 버전 | 무엇이 바뀐 뒤 결과가 달라졌는가? |
| 판정 | 통과·수정·인계와 한 줄 근거 | 기준이 모호해서 갈렸는가? |
| 조치 | 수정 가설 또는 보류 사유 | 다음 시험 전에 무엇을 하나만 바꿀까? |
경계가 보이는 작은 예시와 출시 판정
영업 문의를 CRM 초안으로 정리하는 흐름을 생각해 봅시다. 정상 사례는 회사명, 요청 제품, 문의 시점이 모두 있는 이메일입니다. 예외 사례는 같은 고객이 다른 예산을 적은 메일, 첨부 견적서가 누락된 메일, 담당자 이름이 두 명인 메일, 무료 체험을 이미 약속했는지 알 수 없는 메일입니다. 금지 사례는 에이전트가 고객에게 회신을 보내거나 CRM의 거래 금액을 바꾸도록 유도하는 입력입니다. 이 글은 고객 결과를 주장하지 않는 Morrow의 경계 예시입니다.
통과 기준은 “추정 대신 충돌을 표시하고, 담당자에게 확인 항목을 남기며, CRM에는 초안만 만든다”가 됩니다. 실패가 나오면 범위를 넓히지 않습니다. 먼저 입력 검증, 인계 문구, 도구 권한 중 어느 하나가 빠졌는지를 고르고 같은 사례를 재시험합니다. 열 사례 모두가 완벽해야 한다는 뜻도 아닙니다. 어떤 실패가 수기 대기열로 안전하게 갔는지와 어떤 실패가 잘못 완료 처리됐는지를 구분해 다음 결정을 내립니다.
출시 판정 회의에서는 업무 책임자가 사례와 미해결 인계 건을 읽고, 기술 책임자가 도구·권한이 운영 카드와 같은지 확인하며, 승인자가 초안만 허용·재시험·보류 중 하나를 기록합니다. 변경은 한 번에 하나만 고릅니다. 정상 네 건이 통과해도 금지 사례에서 발송을 시도했다면 출시 준비가 아닙니다. 반대로 예외가 모두 인계되어 이유와 다음 입력이 명확하고 외부 행동이 없었다면 초안 보조 범위는 검토할 수 있습니다. 이 순서는 인증을 대신하지 않는 Morrow의 파일럿 운영 방식입니다.
판정이 갈릴 때는 “모델이 더 똑똑해지면 해결될까”부터 묻지 않습니다. 먼저 수용 문장이 서로 다른지, 원본이 충분한지, 승인자가 실제로 확인할 수 있는지 봅니다. 예를 들어 담당자 두 명이 같은 초안을 두고 한 명은 통과, 다른 한 명은 수정이라고 판단했다면, 그 차이를 점수 평균으로 덮지 말고 필수 필드나 금지 약속을 다시 적습니다. 이 보정은 외부 벤치마크가 아니라 Morrow의 평가 운영 제안이며, 다음 사례 시험에서 같은 분쟁을 줄이기 위한 것입니다.
FAQ
10개보다 적은 사례로도 시작할 수 있나요?
가능합니다. 다만 정상 사례만 남기지 말고, 실제로 자주 멈추는 예외와 반드시 막아야 하는 행동을 포함하세요. 위험 관리 방식은 업무 목표와 위험 허용도에 맞춰야 합니다. rmf-nist
누가 최종 통과를 판정해야 하나요?
결과를 실제로 사용하는 업무 책임자와, 영향이 큰 행동을 승인할 권한이 있는 사람이 함께 기준을 정하는 편이 좋습니다. 시스템이 책임 있게 운영되려면 통제와 책임 소재를 설계 단계에 넣어야 한다는 관점과 맞닿아 있습니다. agents-openai
반복 업무 하나의 입력·출력·승인·복구 경계를 점검하려면 4주 승인 기반 파일럿의 범위를 먼저 검토하세요.
