짧은 trial은 AI 도구가 유망해 보이는지 알려줄 수 있습니다. 그러나 반복 업무, 입력 변화, 알려진 실패 방식과 실제 검토 조건에서도 계속 유용한지는 보여주지 못합니다.
작은 평가 세트는 이 간격을 줄입니다. 실제 업무를 대표하는 사례와 고정 입력, 기대 근거, 승인 기준, 검토 기록을 묶은 작은 시험 모음입니다. 목적은 보편적인 benchmark를 만드는 것이 아닙니다. 한 팀의 도입 판단을 기억, 시연, 인상적인 한 번의 답변보다 재현 가능하게 만드는 것입니다.
NIST의 AI 시험·평가 활동은 의미 있는 과제, 사용 맥락, 측정 한계와 지속적인 재평가를 강조합니다. AI RMF도 사용 목적을 정의하는 과정과 성능을 측정하고 진행 여부를 결정하는 과정을 구분합니다. NIST AI 800-3은 고정 benchmark의 결과가 비슷한 미래 업무 전체의 성능을 자동으로 의미하지 않는다고 설명합니다. 따라서 작은 평가 세트는 제한된 결정을 지원해야 하며, 특정 도구가 일반적으로 최고라는 결론을 만들면 안 됩니다.
1. 평가가 지원해야 할 결정을 먼저 정의하기
시험 프롬프트보다 결정을 먼저 씁니다.
예시는 다음과 같습니다.
사람이 발송 전에 승인하는 고객 문의 답변 초안 업무에서 이 도구를 4주 pilot으로 진행할지 결정한다.
좋은 결정 문장에는 다음이 포함됩니다.
- 반복 업무;
- 실제 사용자;
- 만들어지는 결과나 의사결정;
- 최종 검토자;
- 허용할 데이터;
- 통과했을 때 허용되는 다음 단계.
“글쓰기 품질을 평가한다”처럼 모호하게 쓰면 결과를 본 뒤 기준을 바꾸기 쉽습니다.
작은 평가 세트의 통과는 보통 더 긴 pilot만 허용해야 합니다. Production 승인, 사람 검토 제거, 더 넓은 데이터 접근 권한을 의미하지 않습니다.
2. 쉬운 예제가 아니라 실제 업무 분포에서 표본 만들기
실제로 발생하는 업무에서 사례를 가져옵니다. 짧고 깨끗하고 익숙한 사례만 고르지 않습니다.
초기 screening에서는 12~30개 정도의 작은 세트도 서로 다른 업무 유형을 포함한다면 유용할 수 있습니다. 이 숫자는 통계적 보증이 아닙니다. 보기 좋은 표본 수보다 범위가 중요합니다.
최소한 다음 네 그룹을 포함합니다.
| 그룹 | 목적 | 예시 |
|---|---|---|
| 일반 사례 | 반복 업무의 기본 유용성 확인 | 필요한 맥락이 모두 있는 일반 문의 |
| 어려운 사례 | 모호함·긴 문맥·충돌 요구 시험 | 서로 모순되는 요구가 포함된 요청 |
| 실패 사례 | 알려진 위험 노출 | 근거 없는 사실 주장이 섞인 문서 |
| 거절·에스컬레이션 사례 | 권한과 경계 시험 | 법률·보안·관리자 검토가 필요한 요청 |
여러 언어, 부서, 문서 유형, 사용자 역할이 있다면 각각 포함합니다. 영어 사례 하나로 전체 업무를 대표한다고 가정하지 않습니다.
각 항목을 왜 포함했는지도 기록합니다. 나중에 어려운 사례를 쉬운 사례로 교체하는 것을 막아줍니다.
3. 입력·문맥·설정·시험일 고정하기
같은 질문도 모델, 요금제, system instruction, 검색 자료, 도구, conversation history가 바뀌면 결과가 달라질 수 있습니다.
각 실행에서 다음을 기록합니다.
- 공급자와 제품;
- 화면에 표시되는 모델 또는 모델 계열;
- 요금제와 계정 유형;
- 활성화된 도구와 connector;
- system 또는 workspace instruction;
- 입력 파일과 원출처 버전;
- 시험일과 지역;
- 첫 실행인지 재시도인지.
입력과 출력은 분리해 보관합니다. 화면 캡처만으로는 정확한 질문, 생략된 문맥, 설정을 확인하기 어렵습니다.
공급자 설정을 고정할 수 없다면 부분 통제 상태로 표시합니다. 결정론적 소프트웨어 테스트처럼 동일하다고 취급하면 안 됩니다.
4. 도구를 실행하기 전에 승인 기준 작성하기
각 항목은 답변을 본 뒤 새 기준을 만들지 않고도 검사할 수 있어야 합니다.
결정론적 검사와 사람 검토를 함께 사용합니다.
결정론적 검사의 예시는 다음과 같습니다.
- 필수 필드가 모두 존재함;
- 금지 필드가 없음;
- 날짜와 합계가 원출처와 일치함;
- 링크가 승인된 domain을 사용함;
- 출력이 정해진 schema를 따름;
- 비밀 정보나 개인정보 식별자가 노출되지 않음.
사람 검토 기준은 다음과 같습니다.
- 실제 사용자 요청에 답함;
- 문체가 상황에 적합함;
- 불확실성이 드러남;
- 추천이 제공된 근거와 연결됨;
- 검토자가 누락된 문맥을 다시 만들지 않고 승인할 수 있음.
두 검토자가 비슷하게 적용할 수 있을 정도로 기준을 짧고 구체적으로 유지합니다.
5. 치명적 실패와 품질 선호를 분리하기
작은 문체 문제와 개인정보 노출을 같은 점수로 처리하면 안 됩니다.
시험 전에 결과 등급을 정합니다.
| 심각도 | 의미 | 예시 | 기본 조치 |
|---|---|---|---|
| Critical | 안전하지 않거나 권한을 넘은 결과 | 민감정보 노출, 승인 없는 실행 | 차단 |
| Major | 큰 수정 없이는 승인 불가 | 최종 추천에 근거 없는 사실 포함 | 항목 실패 |
| Minor | 제한된 수정 후 사용 가능 | 형식 또는 문체 문제 | 수정 시간 기록 |
| Preference | 주관적 개선 | 다른 표현 선호 | 필수 조건이 아니면 실패 아님 |
쉬운 사례 19개를 통과하고 한 사례에서 비밀정보를 노출했다면 단순히 성공률 95%라고 표현하면 안 됩니다. critical failure를 별도로 표시해야 합니다.
6. 반복 실행하고 전체 출력 기록 남기기
생성 결과는 달라질 수 있습니다. 위험하거나 불안정한 항목은 가능한 범위에서 반복 실행합니다.
다음을 보존합니다.
- 모든 원출력;
- 표시된 tool call과 citation;
- 지연 시간과 오류;
- 재시도 횟수;
- 검토자의 수정 내용;
- 항목별 최종 판정.
가장 좋은 결과만 남기면 평가는 홍보 자료로 바뀝니다.
초기 screening에서는 중요한 항목을 2~3회 반복해도 불안정성을 발견할 수 있습니다. 더 큰 의사결정에는 더 많은 실행과 정식 분석이 필요할 수 있습니다. 적은 반복으로 미래 변동 전체를 측정했다고 주장하지 않습니다.
7. 현재 baseline과 비교하고 승인 결과를 측정하기
중요한 질문은 답변이 세련되어 보이는지가 아닙니다. 현재 대안보다 업무를 개선하는지입니다.
Baseline은 다음 중 하나가 될 수 있습니다.
- 현재 수동 절차;
- 더 단순한 모델;
- AI 없는 template;
- 기존 승인 도구;
- 자동화하지 않는 방식.
최소한 다음을 측정합니다.
- 승인율;
- critical·major failure 수;
- 검토자 수정 시간;
- 전체 완료 시간;
- 승인 결과당 비용;
- 남은 불확실성;
- 필요한 경우 사용자·검토자 선호.
첫 초안이 빨라도 검증 시간이 늘어나면 전체 업무는 느려질 수 있습니다. 품질이 높은 모델도 데이터·권한 요구를 충족하지 못하면 도입할 수 없습니다.
8. 불확실성을 기록하고 보편적 결론을 피하기
작은 평가 세트는 다음과 같은 제한된 문장을 지원합니다.
2026년 7월의 고객 문의 초안 사례 20개에서 설정 A는 15개가 경미한 수정 이하로 승인됐고, major factual failure 2건이 있었으며, 시험 범위에서는 critical data handling failure가 관찰되지 않았다.
다음과 같은 문장은 지원하지 못합니다.
설정 A의 고객 지원 정확도는 75%다.
두 번째 문장은 표본 밖 업무로 일반화하고 항목 난이도 차이를 숨길 수 있습니다. NIST AI 800-3은 고정 benchmark 성능과 더 넓은 유사 항목 집단의 성능을 구분합니다.
다음을 함께 기록합니다.
- 표본에 포함되지 않은 업무;
- 측정하지 못한 위험;
- 통제하지 못한 설정;
- 반복 실행 횟수;
- 결정을 바꿀 수 있는 추가 증거.
작은 평가 세트 템플릿
| 필드 | 기록 내용 |
|---|---|
| Item ID | 변하지 않는 식별자 |
| 업무 유형 | 일반·어려움·실패·에스컬레이션 |
| 입력 버전 | 정확한 질문과 파일 hash 또는 버전 |
| 기대 근거 | 원출처·계산·schema·검토 요구 |
| Critical rule | 발생하면 도입을 차단할 조건 |
| Major criteria | 승인에 필요한 조건 |
| 실행 설정 | 모델·요금제·도구·날짜·설정 |
| 원출력 | 수정하지 않은 전체 결과 |
| 검토 결과 | Pass·minor·major·critical·unresolved |
| 수정 시간 | 승인까지 필요한 시간 |
| 비고 | 실패 패턴과 후속 조치 |
평가 세트를 다시 갱신해야 하는 시점
다음 상황에서 갱신합니다.
- 모델이나 제품이 크게 변경됨;
- prompt, 검색, 도구, system instruction이 바뀜;
- pilot 또는 운영에서 새로운 실패가 발견됨;
- 실제 업무 분포가 바뀜;
- 정책·개인정보·승인 요구가 달라짐;
- 검토자가 행동을 평가하지 않고 정답을 외우기 시작함.
중요한 regression을 나타내는 이전 항목은 유지합니다. 어려운 과거 사례를 조용히 삭제하지 않습니다.
짧은 체크리스트
작은 평가 세트를 신뢰하기 전에 확인합니다.
- 결정과 다음 단계가 정의됨;
- 실제 일반 업무와 어려운 업무가 포함됨;
- 실패·에스컬레이션 사례가 최소 하나씩 있음;
- 결과를 보기 전에 기준을 작성함;
- critical failure와 선호를 분리함;
- 원출력과 재시도를 보존함;
- 현재 baseline을 측정함;
- 표본과 불확실성 한계를 결론에 표시함;
- 담당자와 갱신 조건이 있음.
좋은 평가 세트는 질문 수가 많아서 유용한 것이 아닙니다. 각 항목이 실제 의사결정 경계를 대표하고 나중에 다시 검토할 수 있는 증거를 남기기 때문에 유용합니다.