AI 업무를 배포하기 전에 작은 평가 사례집부터 만드는 법
대표 사례와 경계 사례, 실패 사례를 작은 평가 사례집으로 묶어 AI 업무의 배포 범위와 검증 기준을 정하는 방법을 살펴본다.
AI로 생성한 개념 이미지이며, 실제 업무 현장이나 시스템의 기록이 아니다.
팀이 회의록 요약 봇을 시연한다. 첫 번째 회의에서는 결정과 담당자를 잘 뽑았다. 두 번째 회의에서는 발언자를 한 명 틀렸지만 문장은 자연스러웠다. 세 번째 회의에서는 “나중에 논의하자”는 말을 확정된 결정으로 바꿨다. 누군가는 충분히 유용하다고 하고, 누군가는 아직 위험하다고 한다. 모델의 출력보다 먼저 흔들리는 것은 팀의 합격 기준이다.
배포 전 평가는 거대한 벤치마크를 만드는 일로 오해되기 쉽다. 그래서 데이터가 많아질 때까지 미루거나, 몇 개 결과를 함께 보고 느낌으로 결정한다. 그러나 작은 업무에서는 수십만 건의 시험보다 서로 다른 실패를 대표하는 사례와 명시적인 판정 기준이 먼저 필요하다. 평가 사례집은 모델의 지능 점수를 매기는 시험지가 아니라, 이 업무에서 무엇을 통과로 볼지 팀이 합의하는 작업 문서다.
OpenAI의 평가 모범 사례 문서는 평가 목표, 데이터셋, 지표, 비교 실행, 지속 평가를 하나의 흐름으로 제시하고, 실제 분포를 반영하지 않는 데이터셋이나 “되는 것 같다”는 감각 중심 평가를 피하라고 안내한다.[8] 별도의 데이터셋 안내는 출력에 대한 사람의 주석이 원하는 행동의 기준이 되고, 도메인 전문가가 그 주석을 맡을 때 전문 지식을 평가에 넣을 수 있다고 설명한다.[9] 이 문서들은 특정 플랫폼의 기능도 소개하지만, 사례와 판정 기준을 먼저 만들라는 원칙은 도구와 무관하게 적용할 수 있다.
사례집은 의견이 갈린 출력에서 시작한다
처음부터 완벽한 정답 모음을 만들 필요는 없다. 최근 업무에서 팀이 자주 고치거나 의견이 갈렸던 사례를 모은다. 성공 사례만 고르면 시스템은 쉬운 입력에서만 좋아 보인다. 반대로 극단적인 함정만 모으면 실제 사용 가치를 판단하기 어렵다.
첫 사례집은 다음 범주로 구성해 볼 수 있다.
- 평소 자주 들어오는 대표 사례
- 입력이 짧거나 모호한 사례
- 자료끼리 충돌하는 사례
- 반드시 거절하거나 사람에게 넘겨야 하는 사례
- 과거에 실제로 수정이 컸던 사례
- 형식은 맞지만 사실이 틀리기 쉬운 사례
처음에는 각 범주에서 두 건씩, 모두 열두 건 정도로 시작할 수 있다. 열두 건은 연구가 보장한 최소 표본이 아니라 회의를 실제 판정으로 바꾸기 위한 저자의 시작값이다. 업무가 다양하거나 영향이 크면 더 많은 사례와 정식 통계 설계가 필요하다.
중요한 것은 사례 수보다 차이다. 같은 길이와 같은 난이도의 문서만 모으면 점수는 안정돼 보여도 배포 현장의 변동을 담지 못한다. 대표 사례와 실패 경계를 함께 넣어야 한다.
한 사례에는 입력과 정답만 있지 않다
생성형 업무에서 하나의 모범 답안만 정답으로 두면 문체 차이를 오류로 오인할 수 있다. 대신 각 사례에 다음 정보를 붙인다.
- 업무 목적: 이 출력이 다음에 어떤 결정을 돕는가
- 입력 묶음: 모델이 실제로 볼 자료와 보지 말아야 할 자료
- 필수 조건: 반드시 포함하거나 지켜야 할 항목
- 금지 조건: 만들면 안 되는 사실, 실행하면 안 되는 행동
- 허용 범위: 표현이 달라도 통과할 수 있는 부분
- 판정자: 누가 어떤 전문성으로 판단하는가
- 실패 꼬리표: 누락, 왜곡, 근거 없음, 권한 초과처럼 원인을 분류하는 말
회의록 요약이라면 필수 조건은 확정된 결정, 담당자, 기한을 원문대로 연결하는 것일 수 있다. 금지 조건은 제안을 결정으로 바꾸거나 발언하지 않은 사람에게 책임을 붙이는 일이다. 문장 길이나 어조는 허용 범위 안에서 달라질 수 있다.
이렇게 쓰면 “좋은 요약”이라는 추상적 지시가 판정 가능한 계약으로 바뀐다. 자동 검사할 항목과 사람만 판단할 항목도 분리된다. 이름·날짜·필수 섹션은 프로그램으로 확인할 수 있지만, 모호한 발언을 결정으로 해석했는지는 원문을 읽는 사람이 판단해야 할 수 있다.
통과 사례와 실패 사례를 나란히 적는다
판정 기준만 읽고도 평가자가 같은 판단을 하리라고 기대하면 안 된다. [8]은 사람 검토로 자동 점수를 보정하고, 서로 다른 점수 수준의 예시를 보여주는 방식을 권한다.[8] 작은 사례집에서도 “통과”, “수정 후 통과”, “보류”, “실패”의 실제 예시를 함께 둔다.
예를 들어 원문에 “김 팀장이 금요일까지 견적을 확인하기로 했다”가 있다면 다음을 비교할 수 있다.
- 통과: “김 팀장 — 금요일까지 견적 확인”
- 수정 후 통과: “견적 확인 예정 — 담당 김 팀장”처럼 뜻은 맞지만 형식을 고쳐야 하는 경우
- 실패: “금요일까지 김 팀장이 견적을 승인”처럼 확인을 승인으로 바꾼 경우
- 보류: 금요일이 어느 날짜인지 문서만으로 알 수 없어 사람 확인이 필요한 경우
실패 사례는 부끄러운 기록이 아니라 평가 기준을 가장 빨리 가르치는 자료다. 통과 예시만 두면 평가자는 경계를 짐작해야 한다. 실패가 왜 실패인지 한 줄로 적으면 다음 모델 변경에서도 같은 오류를 찾을 수 있다.
평가자를 먼저 평가한다
자동 채점기는 규모를 키우는 데 유용하지만 기준이 나쁘면 오류를 빠르게 승인한다. 문자열 일치, 코드 실행, 모델 판정은 각각 잘 보는 것이 다르다. [9]도 정확 일치, 텍스트 유사도, 모델 점수, 분류 라벨, Python 코드 실행처럼 여러 grader 유형을 구분한다.[9]
작은 사례집에서는 먼저 두 사람이 일부 사례를 독립적으로 판정해 본다. 의견이 다르면 모델을 탓하기 전에 기준 문장을 고친다. “간결해야 한다” 대신 “핵심 결정 세 건을 500자 안에 적는다”처럼 관찰 가능한 조건으로 바꾼다. 그래도 주관성이 남는 항목은 단일 자동 점수로 통과시키지 않고 사람 판정을 유지한다.
모델을 평가자로 쓴다면 사람이 붙인 라벨과 얼마나 일치하는지 먼저 확인한다. 길고 유창한 답을 선호하거나, 자기와 비슷한 문체를 높게 평가할 수 있다. 자동 평가 결과에는 근거 문장이나 실패 이유를 함께 남겨 사람이 표본을 재검토할 수 있게 한다. 자동화의 목적은 사람의 기준을 없애는 것이 아니라 반복 가능한 부분을 맡기는 데 있다.
배포 게이트는 평균점수 하나가 아니다
평균이 높아도 절대 발생하면 안 되는 실패가 한 건 있으면 배포를 멈춰야 할 수 있다. 반대로 사소한 형식 오류 몇 건 때문에 유용한 보조 기능 전체를 막을 필요는 없을 수 있다. 따라서 사례마다 위험 등급과 통과 규칙을 다르게 둔다.
가상의 회의록 봇이라면 다음처럼 정할 수 있다.
- 존재하지 않는 결정 생성: 한 건이라도 발생하면 보류
- 담당자 오지정: 한 건이라도 발생하면 보류
- 필수 섹션 누락: 자동 수정 후 재평가 가능
- 문체 선호 불일치: 배포 차단이 아니라 편집 개선 항목
이 수치는 특정 업무의 권장 임계값이 아니라 규칙의 형태를 보여주는 예시다. 실제 기준은 오류의 영향, 사람 검토의 강도, 사용 범위에 따라 정해야 한다.
배포 판단에는 기존 방식도 함께 놓는다. 사람이 만든 회의록도 누락과 오해가 있을 수 있다. AI가 완벽한가만 묻지 말고 현재 방식과 비교해 어떤 오류가 줄고 늘었는지, 검토 부담이 어디로 이동하는지를 본다. 다만 기존 방식이 나쁘다는 사실이 새로운 위험을 자동으로 정당화하지는 않는다.
변경이 생길 때마다 사례집을 다시 연다
모델, 프롬프트, 검색 자료, 도구 권한, 출력 형식 가운데 하나가 바뀌면 결과도 달라질 수 있다. 사례집은 출시 전에 한 번 쓰고 닫는 문서가 아니다. [8]은 변경마다 평가하고 운영 중 발견한 비결정적 사례를 추가하는 지속 평가를 권한다.[8]
운영에서 새로운 실패가 나오면 입력과 민감정보를 안전하게 정리해 회귀 사례로 넣는다. 어떤 변경이 그 실패를 고쳤다면 기존 대표 사례를 망가뜨리지 않았는지도 함께 본다. 사례집의 버전, 실행한 시스템 버전, 판정자, 결과를 연결해야 “지난달에는 통과했다”는 말을 재현할 수 있다.
평가 데이터가 실제 고객이나 직원의 자료라면 개인정보와 이용 목적을 먼저 검토한다. 필요한 부분만 남기고 식별자를 제거하며 접근 권한을 제한한다. 합성 사례는 민감정보를 줄이는 데 도움이 되지만 실제 표현과 예외를 놓칠 수 있다. 합성, 과거 기록, 전문가 작성 사례를 섞되 각각의 출처와 한계를 표시하는 편이 안전하다.
오늘 만들 수 있는 첫 사례집
첫날에는 업무 담당자와 평가 담당자가 최근 출력 열두 건을 모은다. 둘째 날에는 성공 기준과 금지 조건을 붙이고 독립 판정을 해본다. 셋째 날에는 의견이 갈린 기준을 고치고 현재 시스템을 기준선으로 실행한다. 그 뒤 한 가지 변경만 적용해 다시 비교한다.
결과 보고서는 “정확도 87점” 한 줄로 끝내지 않는다. 어떤 범주가 개선됐고, 어떤 치명적 실패가 남았으며, 어떤 항목은 사람이 계속 봐야 하는지 적는다. 배포 범위도 평가 결과에 맞춰 제한한다. 회의록 전체 자동 발행이 위험하면 결정 후보 표시와 초안 생성까지만 허용할 수 있다.
작은 평가 사례집의 가치는 모델을 서열화하는 데 있지 않다. 팀이 품질을 두고 같은 언어로 대화하고, 변경 전후를 비교하며, 실패를 다음 시험으로 남기는 데 있다. 배포 전에 이 문서를 만들면 “될 것 같다”는 기대가 “어디까지 통과했고 어디서 멈춰야 하는가”라는 운영 판단으로 바뀐다.
이 글의 근거와 한계
[8]과 [9]는 OpenAI의 공식 평가 문서이며 일부 제품 기능과 현재 플랫폼 정책을 포함한다. 평가 원칙은 참고할 수 있지만 특정 평가 도구의 지속성이나 조직 적합성을 보장하지 않는다. 열두 건 시작값, 사례 필드, 배포 게이트 예시는 저자의 제안이다. 고위험·대규모 배포에는 통계, 법률, 안전, 도메인 전문가가 참여하는 더 엄격한 평가가 필요하다.
참고 자료
[8] OpenAI API — Evaluation best practices [9] OpenAI API — Getting started with datasets