생성형 테스트 데이터: 샘플 수보다 커버리지부터 검증하기

테스트 생성이 쉬워질수록 빠진 조건을 세어야 합니다

Anthropic의 Bloom은 지정한 행동을 살펴보기 위해 다양한 평가 상황을 자동 생성하는 접근을 공개했습니다. 생성량을 늘릴 수 있다는 변화는 테스트 준비에 유용하지만, 만들어진 사례가 업무 범위를 골고루 다룬다는 뜻은 아닙니다. NIST의 조합 테스트 관점을 함께 적용하면 문장의 다양성과 입력 조건의 커버리지를 구분해 검토할 수 있습니다.

• Anthropic · Introducing Bloom: Automated behavioral evaluations
• NIST SP 800-142 · Practical Combinatorial Testing

가상의 반품 접수 서비스에서 고객의 말투만 다른 사례를 많이 생성하면 모든 문장이 정상 반품에 집중될 수 있습니다. 부분 배송, 사용한 쿠폰, 반품 기간 경과, 이미 환불된 주문처럼 판단이 달라지는 조건을 먼저 정해야 합니다. 생성 모델에는 이 조건표의 빈칸을 채우게 하고, 결과를 다시 조건별로 분류해 실제로 의도한 사례가 만들어졌는지 확인합니다.

업무 요인과 조합을 먼저 설계합니다

입력 요인은 주문 상태, 결제 방식, 고객 권한과 요청 시점처럼 결과에 영향을 주는 값으로 나눕니다. 모든 조합을 만들기 어렵다면 두 요인이나 세 요인이 함께 바뀌는 조합을 선택할 수 있지만, 그 선택이 모든 오류를 포괄하지는 않습니다. 돈이나 권한이 걸린 고위험 조합은 별도로 지정하고, 존재할 수 없는 조합은 제약으로 표시합니다.

생성 결과에는 자연어 설명뿐 아니라 요인 값과 기대한 실패 유형을 붙입니다. 이 메타데이터도 모델이 틀릴 수 있으므로 가능한 항목은 코드로 검사하세요. 예를 들어 이미 환불된 주문이라는 설명과 실제 상태 필드가 일치하는지 확인합니다. 같은 의미의 문장 변형은 하나의 사례군으로 묶어 샘플 수가 커버리지를 부풀리지 않게 합니다.

기대 결과는 입력과 독립적으로 확인합니다

생성 모델이 입력과 정답을 동시에 만들면 잘못 이해한 정책이 두 곳에 똑같이 들어갈 수 있습니다. 금액은 계산 규칙으로, 권한은 역할표로, 상태 전이는 명시된 전이 조건으로 검사하는 방식이 필요합니다. 자연어 답변의 판단이 필요한 부분은 업무 담당자 검토나 보정한 평가자를 붙이되 생성 모델과의 일치만으로 정답을 확정하지 않습니다.

정답 한 줄을 만들기 어려운 경우에는 반드시 성립해야 하는 성질을 검사할 수 있습니다. 예를 들어 같은 환불 요청을 다시 보내도 환불 총액이 늘어나지 않아야 하고, 관련 없는 메모를 바꿔도 금액 계산이 변하지 않아야 합니다. 이런 관계 검사는 생성된 문장의 그럴듯함보다 시스템이 지켜야 할 규칙을 직접 확인하는 데 도움이 됩니다.

테스트 분포와 실제 고객 분포를 구분합니다

희귀한 오류를 찾으려고 실패 사례를 많이 만든 테스트 집합은 운영 성공률을 추정하는 데 그대로 사용할 수 없습니다. 정상·예외 비중을 인위적으로 조정했기 때문입니다. 출시 전 결함 탐색용 묶음과 실제 입력 분포를 반영한 성능 확인 묶음을 따로 관리하세요. 생성 설정과 씨앗 자료, 사람이 수정한 이력을 남겨야 반복 검증에서도 같은 기준을 사용할 수 있습니다.

• 생성 전 업무 요인과 고위험 조합을 정했는가
• 메타데이터와 입력 내용의 일치를 검사했는가
• 기대 결과를 독립된 규칙이나 검수로 확인했는가
• 결함 탐색용 비율을 운영 성능처럼 해석하지 않는가