B컷전문 | 개발과 인생의 이야기

고객 문의를 요약해 담당자에게 전달하는 AI 기능을 출시했다고 해보자. 처음에는 보기 좋은 요약이 나왔다. 그런데 프롬프트를 조금 고친 뒤, 환불 기한이 지난 문의에서 “환불 가능”이라고 단정하는 답이 생겼다. 데모에서 잘 보였던 몇 건만 다시 확인해서는 이런 변화를 잡기 어렵다.

AI 결과물은 같은 입력에도 표현이 달라질 수 있다. 따라서 모든 문장을 정답 문자열과 비교하기보다, 지켜야 할 조건과 허용 가능한 변동을 분리한 평가셋을 만들고 변경 전후를 비교해야 한다. 이번 글은 특정 평가 서비스의 사용법보다, 제품에 남길 회귀 테스트의 설계를 다룬다.

1. 평가셋은 예쁜 질문 모음이 아니라 업무 계약이다

평가셋의 한 행에는 입력만이 아니라 당시의 정책, 기대 행동, 금지 행동, 판단 근거가 있어야 한다. 고객 문의 요약이라면 “짧게 요약한다”만으로는 부족하다. 문의의 핵심 사실을 보존하고, 없는 환불 약속을 만들지 않으며, 판단할 근거가 없으면 확인 필요라고 표시해야 한다.

필드	고객 문의 예시	왜 필요한가
입력과 맥락	배송 지연 문의, 주문 상태, 적용 정책 버전	같은 질문도 정책과 상태에 따라 답이 달라진다
기대 행동	지연 사실 요약, 보상 가능 여부는 담당자 확인	하나의 정답 문장 대신 수용 조건을 정의한다
금지 행동	확인되지 않은 환불 확약, 주문번호 외 개인정보 노출	치명적 실패를 평균 점수에 묻히지 않는다
사례 메타데이터	case_id, 출처, 검토자, 등록일, 위험도	실패를 재현하고 기준 변경을 추적한다

실제 고객 기록을 평가셋에 옮길 때는 사용 목적과 접근 권한을 먼저 확인하고 식별 정보를 가리거나 합성 사례로 대체하자. 평가 데이터 자체도 운영 자산이다.

2. 정상 사례와 실패 경로를 함께 담는다

처음부터 수백 건을 모으기보다, 실제로 자주 들어오는 요청과 손실이 큰 경계 사례를 나눠 시작하자. 예를 들면 정상 배송 문의, 환불 기한 경계, 정보가 부족한 문의, 정책 문서가 충돌하는 경우, 긴 대화에서 앞선 정정을 반영해야 하는 경우다. 최근 장애나 사용자 피드백에서 나온 실패는 재현 가능한 사례로 고정한다.

• 대표성: 실제 요청 유형과 빈도를 반영하되, 드물어도 피해가 큰 사례를 별도 묶음으로 둔다.
• 독립성: 프롬프트를 고칠 때 사용한 몇 건만으로 성능을 선언하지 않는다. 탐색용과 최종 확인용 사례를 구분한다.
• 버전: 평가셋과 정책 문서, 프롬프트, 모델, 검색 인덱스의 버전을 함께 기록한다.
• 검토: 정답 기준이 애매한 사례는 담당자와 합의하고, 기준을 바꾸면 변경 이유를 남긴다.

OpenAI의 데이터셋 안내는 입력 열과 기준값을 함께 두고 평가자를 연결하는 흐름을 보여준다. Anthropic의 평가 글은 하나의 작업에 여러 판정기를 둘 수 있고, 변동이 있는 작업은 여러 번 시도해 결과를 보라고 설명한다. 도구가 무엇이든 핵심은 사례와 판정 기준을 사람이 설명할 수 있게 만드는 것이다.

3. 점수 하나보다 판정 기준의 층위를 나눈다

요약문의 단어가 기준 답안과 정확히 같지 않다고 실패로 볼 필요는 없다. 반대로 “그럴듯하다”는 전체 인상만으로는 잘못된 금액이나 날짜를 놓친다. 판정 방법을 다음처럼 나눠 보자.

검사	적합한 기준	예시
결정적 검사	형식, 필수 필드, 허용된 상태값	JSON 파싱, case_id 포함, 금지된 개인정보 패턴 검사
사실·업무 검사	원본과 정책에 비춰 보존할 사실	환불 기한, 배송일, 확약 금지 여부를 항목별 판정
사람 검토	애매한 표현, 유용성, 판정기 오류	실패 표본과 경계 사례를 이중 검토

모델을 평가자로 쓴다면 판정 질문을 좁히고, 근거와 판정 사유를 남기며, 사람이 채점한 표본과 주기적으로 대조해야 한다. 자동 판정이 사람의 판단을 완전히 대신한다는 뜻은 아니다. 특히 개인정보 노출이나 잘못된 승인처럼 비용이 큰 위반은 평균 품질 점수와 별도의 차단 조건으로 두자.

4. 실전 예시: 고객 문의 요약의 회귀 게이트

다음은 프레임워크 코드가 아닌 평가 사례의 설계 예시다. 정책상 환불 가능 여부를 단정할 수 없는 상황을 의도적으로 넣었다.

{
  "case_id": "refund-boundary-07",
  "input": "고객: 배송이 늦었으니 환불해 주세요. 주문 상태: 배송 중",
  "context": "환불 정책 v3: 배송 중 건은 담당자 확인 필요",
  "must_include": ["배송 지연 요청", "담당자 확인 필요"],
  "must_not": ["환불 확정", "이미 환불 처리"],
  "risk": "high"
}

평가 실행에서는 후보 버전과 현재 운영 버전을 같은 사례·같은 기준으로 돌린다. 형식 오류와 금지 행동은 사례별 실패로 표시하고, 사실 보존율과 사람 검토 결과는 유형별로 비교한다. 위 사례에서 문장이 매끄러워져도 “환불 확정”이 들어갔다면 배포를 멈추고 원인을 살핀다. 반대로 표현만 달라졌고 필수 사실과 경계가 지켜졌다면 문자열 불일치만으로 실패시키지 않는다.

배포 규칙은 조직의 위험 허용치에 맞춰 미리 정하자. 예를 들어 고위험 사례는 금지 행동 0건을 요구하고, 나머지는 기준 버전 대비 악화된 사례를 검토 대상으로 올릴 수 있다. 숫자 임계값을 보편적 정답처럼 복사하지 말고, 사례 수와 오판 비용을 함께 보아야 한다.

5. 문제가 생길 때의 개선 팁

• 전체 점수는 올랐는데 중요한 사례가 나빠진다: 유형·위험도별 결과를 분리하고, 사례별 변경 목록을 본다.
• 판정기가 “좋음”만 반복한다: 평가 기준을 한 번에 하나의 주장으로 좁히고, 맞음·틀림·판단 보류 예시로 사람 판정과 교정한다.
• 실행마다 결과가 흔들린다: 입력 환경과 버전을 고정해 비교하고, 변동이 큰 사례는 반복 실행해 분포와 실패 빈도를 본다.
• 오래된 정책의 정답이 남아 있다: 정책 버전을 사례에 연결하고, 기준 변경을 검토한 뒤 평가셋을 갱신한다.
• 배포 뒤 처음 보는 실패가 나온다: 민감정보를 제거한 재현 사례와 기대 행동을 추가해 다음 변경의 회귀 테스트로 만든다.

LangSmith 문서는 배포 전의 오프라인 회귀 테스트와 운영 중의 온라인 평가를 구분한다. 전자는 알려진 사례의 악화를 잡고, 후자는 새 실패를 발견해 평가셋으로 되돌리는 역할이다. 테스트 통과가 운영 품질의 영구 보증은 아니다.

요약

AI 기능을 바꿀 때 “이번 답이 더 자연스럽다”는 감상만으로 배포하지 말자. 입력과 정책, 기대·금지 행동이 적힌 평가셋을 만들고, 형식 검사는 코드로, 사실과 경계는 항목별로, 애매한 품질은 사람 검토로 나눈다. 같은 사례에서 현재 버전과 후보 버전을 비교하고, 위험한 회귀는 평균 점수와 별도로 막는다. 좋은 평가셋은 한 번에 완성되는 시험지가 아니라, 실제 실패를 학습해 계속 다듬는 업무의 안전망이다.

참고 자료

• OpenAI, Getting started with datasets
• Anthropic, Demystifying evals for AI agents
• LangChain, Evaluation types