AI 에이전트 PoC 평가표: 데모를 운영 증거로 바꾸는 법
AI 에이전트 데모는 대개 가장 잘 준비된 질문과 정상적인 도구 상태에서 한 번 실행됩니다. 실제 운영은 다릅니다. 입력은 애매하고, 권한은 만료되고, API는 느려지며, 같은 요청에도 결과가 달라집니다.
PoC의 성공은 멋진 데모 한 번이 아닙니다. 대표 과제를 반복 수행했을 때 품질·일관성·사람 부담·비용·권한·복구가 사전에 정한 기준 안에 드는가로 판단해야 합니다.
평가 단위부터 맞춘다
Anthropic의 에이전트 평가 가이드를 실무 언어로 옮기면 다섯 단위를 구분할 수 있습니다.
- Task: 에이전트에게 주는 하나의 과제와 시작 상태
- Trial: 같은 task의 한 번의 실행. 결과 변동 때문에 여러 번 필요
- Grader: 성공을 판정하는 자동 규칙, 모델 또는 사람
- Trace: 답변, 도구 호출, 승인, 오류, 재시도와 중간 상태의 기록
- Evaluation set: 실제 업무 분포와 실패 사례를 담은 task 묶음
초기에는 20~50개의 실제 과제로 시작할 수 있습니다. 이것은 충분성을 보장하는 표준이 아니라 구조를 만들기 위한 시작점입니다. 쉬운 정답 예제만 모으지 말고 과거 오류, 애매한 정책, 긴 맥락, 권한 부족, 도구 장애와 악의적 입력을 넣어야 합니다.
결과를 보기 전에 실험 계약을 쓴다
| 항목 | 작성 내용 |
|---|---|
| 문제·사용자 | 누가 어떤 업무를 더 잘하려는가 |
| 현재 기준선 | 시간, 품질, 비용, 오류, 대기, 만족도 |
| 평가 모집단 | 기간, 업무 유형, 난이도, 제외 기준 |
| 성공 정의 | grader, 증거, 허용 오차 |
| trial 수 | 과제별 반복 횟수와 실행 설정 |
| 위험 한도 | 절대 허용하지 않는 실패·행동 |
| 후보 비교 | 기존 프로세스, 단순 자동화, AI 후보 |
| Go 기준 | 사전에 합의한 임계값과 결정권자 |
산업과 업무 위험이 다르므로 “정확도 90%면 합격” 같은 보편 숫자는 없습니다. 중요한 것은 테스트 결과를 본 뒤 기준을 낮추지 않는 일입니다.
100점 PoC 평가표
| 평가 영역 | 가중치 | 핵심 지표 | 판단 질문 |
|---|---|---|---|
| 결과 품질 | 25 | task success, 정확성, 정책 준수 | 성공의 실제 증거가 있는가 |
| 일관성·강건성 | 15 | pass@1, pass^k, 난이도별 분산 | 반복·예외·공격 입력에서도 안정적인가 |
| 사람 부담 | 15 | 검토분, 개입률, 승인 대기, 재작업률 | 절감 시간보다 새 감독 시간이 적은가 |
| 지연·사용성 | 10 | p50/p95 latency, 중도이탈 | 업무 흐름 안에서 기다릴 만한가 |
| 검증 성공당 원가 | 10 | cost per verified success | 재시도·도구·검토까지 포함해 경제적인가 |
| 보안·권한 | 15 | 무단 행동, 데이터 노출, 승인 우회 | 최소권한과 실행 전 승인이 작동하는가 |
| 운영·복구 | 10 | 관측성, MTTR, rollback, 공급자 장애 | 실패를 발견·중단·복구할 수 있는가 |
각 영역을 1~5점으로 평가해 점수 ÷ 5 × 가중치로 계산합니다. 다만 치명적 실패는 총점으로 상쇄하지 않습니다.
자동 탈락 조건
- 승인되지 않은 시스템·데이터·수신자에 접근하거나 전송했다.
- 비밀·개인정보를 노출했거나 사용자·테넌트 데이터가 섞였다.
- 비가역 고영향 행동을 승인 없이 실행했다.
- 결과, 도구 호출과 승인 기록을 재구성할 로그가 없다.
- 실패를 멈추거나 복구할 방법이 없다.
- 평가 과제가 개발 과정에 반복 노출되어 결과가 오염됐다.
- 모델·프롬프트·도구 변경 뒤 회귀 평가를 할 수 없다.
하나라도 발생하면 “평균 92점”은 의미가 없습니다.
지표를 계산하는 법
품질과 일관성
- Task success rate = 성공 task 수 ÷ 전체 task 수
- pass@k는 k번 중 한 번 이상 성공하는 탐색 능력을 봅니다.
- pass^k는 k번 모두 성공하는 반복 일관성을 봅니다.
성공 확률이 75%인 작업을 세 번 연속 성공할 확률은 약 42%입니다. 평균 성공률 하나로 반복 운영의 신뢰성을 설명할 수 없는 이유입니다.
사람 부담
- Human intervention rate = 사람이 개입한 task ÷ 전체 task
- Net time saved = 기존 처리시간 - AI 대기 - 검토 - 수정 - 예외 처리
승인 클릭 수만 세지 말고 승인자가 읽고 판단하는 시간을 재야 합니다.
비용
검증 성공당 원가 = 모델 + 도구/API + 인프라 + 재시도 + 평가·모니터링 + 사람 검토 + 실패 복구 비용 ÷ 검증된 성공 건수
토큰당 비용은 공학 지표이고 검증 성공당 원가는 경영 지표입니다.
운영
- p50/p95 지연
- tool/API error rate
- rollback success rate
- MTTD와 MTTR
- 모델·프롬프트·도구 변경 전후 회귀 점수
평가셋 구성 시작안
| 묶음 | 비중 시작안 | 예시 |
|---|---|---|
| 정상 대표 과업 | 40% | 가장 흔한 상위 업무 |
| 긴 꼬리·예외 | 20% | 드문 정책, 애매한 요청 |
| 과거 실패 | 15% | 실제 재작업·클레임 원인 |
| 도구·환경 장애 | 10% | API timeout, 권한 만료, 부분 실패 |
| 보안·악의 입력 | 10% | prompt injection, 대상 바꾸기 |
| 경계·거절 | 5% | 하면 안 되는 요청, 사람 이관 |
비중도 고정 표준이 아닙니다. 실제 운영 분포와 실패 피해를 기준으로 조정합니다.
결과 보고서는 한 장으로 끝낸다
- 기준선과 비교 후보
- 평가셋 구성과 trial 수
- 7개 영역 점수와 원시 지표
- 난이도·업무 유형별 분포
- 치명적 실패와 near miss
- 사람 부담과 검증 성공당 원가
- 알려진 한계와 미검증 영역
- Go·Revise·Stop 권고와 다음 책임자
PoC에서 자주 놓치는 것은 최종 답 뒤의 과정입니다. 답은 맞았지만 잘못된 시스템을 조회했거나, 권한 우회를 시도했거나, 사람의 수정 시간이 더 많이 들었다면 운영 후보가 아닙니다.
PoC 점수는 출시를 축하하기 위한 숫자가 아니라 중단할 근거까지 만드는 장치입니다.