5-5. 테스트 데이터 설계 전략 [Core]

테스트 데이터 설계의 목적은 품질 기준을 흔들 수 있는 입력 조건을 빠뜨리지 않는 것입니다. 5-4에서 회귀 테스트의 비교 조건을 정했다면, 5-5에서는 그 조건을 실제로 확인할 데이터 묶음을 설계합니다.

AI QA에서 테스트 데이터는 하나의 파일만 의미하지 않습니다. 운영에서 자주 들어오는 정상 입력, API 계약(contract)을 깨는 입력, 임계값(threshold) 근처에서 예측(prediction)이 바뀔 수 있는 입력, 관심 클래스(Positive class)를 충분히 포함한 분석용 평가 데이터가 서로 다른 역할을 가집니다.

이 문서를 읽을 때는 다음 기준을 중심으로 확인합니다.

설계 기준	핵심 질문
대표성	운영에서 자주 등장하는 정상 입력이 포함되어 있는가
실패 조건	결측, 타입 오류, 범위 오류처럼 API 계약을 깨는 입력이 포함되어 있는가
민감 구간	임계값 근처 점수(score)를 만드는 입력이 포함되어 있는가
평가 목적	운영 비율 데이터와 분석용 보강 데이터를 구분하고 있는가

5-5-1. 정상 입력과 대표 케이스 선정

테스트 데이터는 정상 입력부터 잡아야 합니다. 정상 입력은 API가 받아야 하는 필드(field)를 모두 포함하고, 값의 범위가 허용 기준 안에 있으며, 운영에서 자주 등장하는 특성(feature) 조합을 가진 샘플(sample)입니다. 정상 케이스가 있어야 오류 입력이나 드리프트(drift) 입력을 비교할 기준선(baseline)이 생깁니다.

대표 케이스는 단순 평균값 하나가 아닙니다. 생체신호 기반 위험 알림 예제라면 heart_rate, oxygen_saturation, body_temperature처럼 모델 판단에 영향을 주는 특성 조합을 함께 봐야 합니다. 평균에 가까운 입력만 모으면 운영에서 자주 등장하는 경계 상황이나 클래스(class) 구분에 중요한 조합을 놓칠 수 있습니다.

정상 대표 입력은 다음처럼 역할별로 나누어 둡니다.

대표 입력 유형	포함 이유	QA 확인
운영 빈도 높은 입력	실제 요청에서 자주 등장하는 값 조합	기본 API 응답과 지표(metric) 기준선 확인
high_risk 대표 입력	관심 클래스로 분류되는 전형적 조합	재현율(Recall)과 FN 위험 확인
low_risk 대표 입력	비교 클래스(Negative class)로 분류되는 전형적 조합	정밀도(Precision)와 FP 위험 확인
임계값 근처 입력	작은 점수 변화로 예측이 바뀔 수 있는 조합	운영 기준 변경 민감도 확인

QA 관점에서는 “정상 입력 통과”를 기능 성공으로만 보지 않습니다. 같은 정상 입력에 대해 score, threshold, prediction, model_version, request_id가 함께 남아야 이후 회귀 테스트와 운영 추적에 사용할 수 있습니다.

5-5-2. 결측, 이상, 타입 오류 입력 설계

운영에서는 잘못된 입력이 들어올 수 있습니다. QA 테스트 데이터에는 결측, 이상, 타입 오류를 의도적으로 포함해야 API 계약과 데이터 검증이 실제로 동작하는지 확인할 수 있습니다.

오류 입력은 모델 지표를 일부러 낮추기 위한 데이터가 아닙니다. 목적은 잘못된 요청이 조용히 모델 입력으로 들어가지 않고, 검증 실패(validation failure)나 명확한 오류 응답으로 처리되는지 보는 것입니다. 예를 들어 숫자 필드에 문자열이 들어왔는데 API가 이를 0으로 바꾸어 예측을 계속하면, 대시보드에서는 정상 예측처럼 보일 수 있습니다.

오류 입력은 다음처럼 API 요청 문제와 평가 데이터 문제를 구분합니다.

그룹	포함할 케이스	확인할 결과
결측 입력	필수 특성 누락, 빈 값, null	검증 실패 또는 오류 응답
타입 오류	숫자 필드에 문자열 입력	타입 검증 실패와 오류 메시지
범위 오류	허용 범위를 벗어난 값	범위 검증 실패와 로그 기록
평가 라벨(label) 오류	평가 데이터에 허용되지 않은 정답 값 포함	지표 계산 전 데이터 검증 실패

라벨은 운영 API 입력이 아니라 평가 데이터의 정답 기준입니다. 따라서 라벨 오류는 API 요청 검증과 같은 표에 넣더라도 해석이 다릅니다. API 입력 오류는 서비스 계약 문제이고, 평가 라벨 오류는 지표를 계산하기 전 데이터 품질 문제입니다.

5-5-3. 경계값과 임계값 근처 케이스 설계

임계값 근처 점수를 만드는 입력은 운영 기준 변경에 민감합니다. 점수가 0.49인 샘플과 0.51인 샘플은 모델 출력은 비슷하지만, 임계값이 0.50이면 서로 다른 예측이 됩니다.

이 구간의 목적은 모델을 일부러 어렵게 만드는 것이 아니라 운영 기준의 영향을 확인하는 것입니다. 임계값을 0.50에서 0.45로 낮추면 high_risk 예측이 늘 수 있고, 0.55로 높이면 줄 수 있습니다. 이 변화는 모델을 다시 학습하지 않아도 발생합니다.

경계값 테스트는 입력 값의 허용 범위와 모델 점수 기준을 모두 포함합니다. 입력 경계값은 API와 데이터 검증을 확인하고, 임계값 근처 점수는 모델 예측의 민감도를 확인합니다. 여기서 FP는 불필요한 high_risk 예측이고, FN은 high_risk 샘플을 놓친 예측입니다.

케이스	이유	QA 해석
점수가 임계값 바로 아래	임계값 하향 시 관심 클래스 전환 가능	FP 증가 가능성 확인
점수가 임계값 바로 위	임계값 상향 시 비교 클래스 전환 가능	FN 증가 가능성 확인
점수가 극단적으로 낮음	비교 클래스 안정성 확인	불필요한 high_risk 예측 증가 여부 확인
점수가 극단적으로 높음	관심 클래스 안정성 확인	관심 클래스 샘플 유지 여부 확인

QA 보고서에는 “임계값 변경 시 예측 수가 바뀐다”보다 어떤 오류 유형이 늘 수 있는지를 적어야 합니다. 낮은 임계값은 관심 클래스를 더 많이 잡을 수 있지만 FP가 늘 수 있고, 높은 임계값은 FP를 줄일 수 있지만 FN이 늘 수 있습니다.

5-5-4. 클래스 불균형 평가 데이터 구성

클래스 불균형은 정확도(Accuracy) 착시를 만들 수 있습니다. low_risk가 대부분인 데이터에서는 모델이 거의 모두 low_risk로 예측해도 정확도는 높아 보일 수 있습니다. 하지만 이 경우 관심 클래스인 high_risk를 놓치는 FN이 늘어도 잘 보이지 않을 수 있습니다.

평가 데이터에는 운영 비율을 반영한 데이터와 분석용 보강 데이터가 모두 필요할 수 있습니다. 운영 비율 데이터는 실제 운영 환경에 가까운 전체 품질을 보게 해주고, 관심 클래스 보강 데이터는 재현율, FN, PR-AUC 같은 지표를 안정적으로 해석하게 해줍니다.

두 데이터는 목적이 다르므로 결과를 섞어 말하면 안 됩니다. 관심 클래스 보강 데이터에서 재현율을 자세히 분석했다고 해서 운영 전체 비율에서도 같은 지표가 나온다고 단정할 수는 없습니다.

데이터 유형	목적	주의할 점
운영 비율 데이터	실제 운영 분포에 가까운 지표 확인	관심 클래스 표본 수(Positive support)가 너무 작으면 Recall 해석이 불안정
관심 클래스 보강 데이터	재현율, FN 분석 안정성 확보	운영 비율 지표처럼 말하지 않기
오류 케이스 데이터	검증 실패와 API 계약 확인	모델 지표와 분리해서 해석
합성 또는 수동 보강 케이스	드문 오류, 경계값, 임계값 근처 조건 확인	운영 분포나 실제 성능 지표처럼 말하지 않기

QA는 평가 데이터의 목적을 명확히 해야 합니다. 모든 테스트 데이터가 같은 목적을 갖는 것은 아니며, 5-6의 배포 승인 판단에서는 어떤 데이터 묶음에서 어떤 기준을 만족했는지 함께 기록해야 합니다.

합성 데이터는 품질 확인의 빈틈을 메우는 보조 수단입니다. 실제 운영 분포를 대신하는 데이터가 아니라, 누락, 범위 오류, 임계값 근처 입력, 드문 조합처럼 운영 로그에 충분히 나타나지 않은 조건을 재현하기 위한 케이스로 다룹니다. 따라서 합성 케이스에서 통과했다는 사실은 “특정 위험 조건을 확인했다”는 뜻이지, 운영 전체 성능이 좋아졌다는 뜻이 아닙니다.