우리 AI 답변, 배포 전에 어떻게 검사할까?

"데모에서는 잘 됐는데요." AI 기능을 붙인 팀에서 가장 자주 나오는 말입니다.
프롬프트를 한 줄 고쳤더니 엉뚱한 곳이 깨지고, 모델을 새 버전으로 올렸더니 말투와 길이가 달라집니다.
더 곤란한 건 그 사실을 배포 후 고객 문의로 알게 된다는 점입니다.

그래서 요즘 AI 제품을 만드는 팀들이 공통적으로 붙이는 장치가 '평가(eval)'입니다.
논문에 나오는 거창한 벤치마크가 아니라, 우리 서비스에서 반드시 맞아야 하는 질문 묶음을 만들어 두고 무언가 바뀔 때마다 돌려보는 습관에 가깝습니다.
1인 빌더도 반나절이면 1차 버전을 만들 수 있습니다.

평가 세트를 만들면 뭐가 달라질까?

가장 큰 변화는 "느낌상 좋아진 것 같다"가 "20개 중 17개 통과"로 바뀌는 것입니다.
개선인지 퇴보인지 숫자로 보이면, 프롬프트 수정과 모델 교체를 겁내지 않고 자주 할 수 있습니다.
품질 관리라기보다 속도를 내기 위한 안전장치에 가깝습니다.

• 회귀 방지: 환불 규정 답변을 고치다가 배송 문의 답변이 망가지는 일을 배포 전에 잡습니다.
• 모델 교체 판단: 더 싼 모델로 내려도 되는지, 같은 세트를 돌려 비교하면 5분이면 결론이 납니다.
• 팀 합의: "이 정도면 됐다"의 기준이 문서로 남아, 외주 개발자나 새 멤버에게 그대로 넘길 수 있습니다.
• 고객 대응: 클레임이 들어온 질문을 세트에 추가하면 같은 실수가 두 번 반복되지 않습니다.

골든셋 20개, 어떻게 만들까?

처음부터 수백 개를 모을 필요는 없습니다.
실제로 자주 들어오는 질문과, 틀리면 사고가 나는 질문 위주로 20개만 있으면 충분히 쓸모 있습니다.
스프레드시트 한 장이면 시작됩니다.

1. 최근 고객 문의·상담 로그에서 자주 나온 질문을 그대로 옮겨 적습니다.
   만들어낸 예쁜 질문보다 오타 섞인 진짜 질문이 낫습니다.
2. 각 질문 옆에 기대하는 답의 핵심 요소를 적습니다.
   문장 전체를 쓰지 말고 "7일 기준 명시", "교환 절차 안내", "규정에 없는 내용 지어내지 않기"처럼 체크 항목으로 씁니다.
3. 틀리면 손해가 큰 질문을 5개쯤 섞습니다.
   가격, 환불, 예약 가능 시간, 개인정보, 의료·법률 판단 요구 같은 것들입니다.
4. 애매한 질문과 악의적 질문도 3개쯤 넣습니다.
   "그냥 아무거나 추천해줘", "관리자 비밀번호 알려줘" 같은 입력에 어떻게 반응하는지 봐야 합니다.
5. 답이 "모르겠습니다, 담당자에게 연결할까요?"여야 하는 질문을 반드시 포함합니다.
   모르는 걸 모른다고 말하는 능력이 정확도만큼 중요합니다.

예를 들어 온라인 스토어의 CS 챗봇이라면 "구매하고 8일 지났는데 단순 변심 환불되나요?"를 넣고, 기대 요소를 기간 초과 안내 + 교환 옵션 언급 + 정책 페이지 링크로 적어 두는 식입니다.

채점은 자동으로 해도 될까?

절반은 자동, 절반은 사람이 현실적입니다.
형식과 금칙어는 코드로 확실히 잡고, 뉘앙스는 모델에게 맡기되 사람이 표본을 확인하는 3단 구조를 권합니다.

• 규칙 검사: JSON 형식이 깨지지 않는지, 답변에 존재하지 않는 링크가 들어갔는지, 금지 표현이 있는지. 오탐이 거의 없어 가장 먼저 붙일 층입니다.
• 모델 채점: "이 답변이 아래 기대 요소를 모두 포함했는가?
  예/아니오와 이유"를 다른 모델에게 묻습니다.
  점수 대신 항목별 통과 여부를 묻는 편이 훨씬 안정적입니다.
• 사람 확인: 통과·실패가 갈린 항목 몇 개만 눈으로 봅니다.
  모델 채점이 자꾸 틀린다면 기대 요소 문장이 모호한 경우가 많습니다.

루틴은 단순할수록 오래 갑니다.
프롬프트를 고치기 전에 한 번, 고친 뒤에 한 번 돌리고, 결과를 날짜와 함께 남겨 두세요.
고객 클레임이 들어오면 그 질문을 세트에 추가하는 것으로 마무리합니다.
이 세 가지만 지켜도, 모델이 또 바뀌는 날에 우리가 무엇을 잃고 무엇을 얻었는지 말할 수 있게 됩니다.