콘텐츠로 이동

2-1. 데이터 검증 자동화의 필요성

데이터 검증 자동화는 1장에서 사람이 직접 확인한 데이터 품질 기준을 반복 가능한 검증 규칙(validation rule)으로 바꾸는 과정입니다. 기준 validation 데이터셋과 품질 저하 validation 데이터셋을 비교할 때마다 사람의 기억과 수동 확인에만 의존하면, 어떤 데이터 조건을 같은 기준으로 확인했는지 흔들릴 수 있습니다.

1장에서 만든 데이터 품질 리포트는 “현재 데이터로 모델 평가를 시작할 수 있는가”를 설명했습니다. 2-1에서는 그 판단을 한 번의 리포트로 끝내지 않고, 다음 평가 데이터에도 같은 기준을 적용할 수 있도록 규칙으로 바꿉니다.

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

  • 수동 확인과 자동 검증의 차이: 탐색과 반복 적용의 역할 구분
  • 검증 규칙의 의미: 모델 평가 전에 만족해야 하는 데이터 조건
  • 기본 검증 기준: 결측값(missing value), 범위, 라벨(label), 스키마(schema) 확인
  • 평가 전 판단 기준: 관심 클래스 표본 수(Positive support)와 조건부 평가, 평가 보류 판단

2-1에서 하는 일은 품질 저하 validation 데이터셋의 지표(metric)를 아직 계산하는 것이 아닙니다. 먼저 2장의 작은 사례를 “어떤 데이터 조건을 반복해서 확인해야 하는가”라는 규칙 문제로 바꿉니다. 이 기준이 있어야 검증 실패를 읽고, 이후 지표 변화와 연결할 수 있습니다.

2-1-1. 수동 확인과 자동 검증의 차이

수동 확인은 기준을 발견하고, 자동 검증은 그 기준을 반복 적용합니다. 1장에서는 Pandas로 데이터 품질을 직접 확인했습니다. 이 수동 확인은 데이터가 어떤 모양인지 이해하고, 결측치나 이상치가 어떤 방식으로 나타나는지 학습하는 데 적합합니다.

하지만 실무에서는 데이터가 한 번만 들어오지 않습니다. 학습 데이터가 갱신되고, 평가 데이터가 바뀌고, 운영 로그에서 추출한 데이터가 다시 평가에 사용됩니다. 현재 운영 입력 샘플처럼 결측과 범위 오류가 섞인 데이터가 들어왔을 때 사람이 매번 같은 코드를 실행하고 같은 기준으로 판단하면 누락이나 해석 차이가 생길 수 있습니다.

1장 기준 데이터에서는 결측치와 범위 오류가 주요 제한 사항으로 나오지 않았습니다. 그러나 1장에서 확인한 방식은 다음 평가 데이터에도 그대로 필요합니다. 예를 들어 현재 운영 입력 실패 양상을 validation 기준에서 재현한 vital_signs_valid_degraded.csv에서 heart_rate 결측치나 oxygen_saturation 범위 오류가 나타난다면, “어떤 컬럼이 비어 있으면 실패인가”, “어떤 값 범위를 벗어나면 실패인가”, “실패하면 어떤 제한 사항을 남겨야 하는가”가 규칙으로 남아 있어야 합니다.

수동 확인과 자동 검증은 경쟁 관계가 아닙니다. 수동 확인은 기준을 찾는 과정이고, 자동 검증은 찾은 기준을 실행 가능한 형태로 고정하는 과정입니다.

구분 수동 확인 자동 검증
목적 데이터 상태와 원인 후보를 직접 이해 같은 기준을 반복 적용
장점 탐색과 맥락 파악에 좋음 재현성과 회귀 확인에 좋음
한계 사람마다 판단이 달라질 수 있음 규칙 설계가 부정확하면 잘못된 통과가 발생
산출물 분석 노트, 임시 코드, 품질 리포트 검증 규칙, 검증 결과, 실패 사유
QA 활용 품질 문제의 맥락 파악 배포 전 품질 기준과 평가 전 관문으로 사용

1장에서 만든 품질 리포트는 자동 검증으로 넘어가는 출발점입니다. 사람이 먼저 “무엇을 봐야 하는지”를 이해한 뒤, 반복해야 할 항목만 규칙으로 옮깁니다.

1장에서 확인한 항목 2장에서 규칙으로 바꿀 항목 자동 검증이 남기는 결과
필수 컬럼 존재 label 컬럼 존재, 모델 입력 컬럼 존재 컬럼 누락 여부
라벨 기준 high_risk, low_risk만 허용 허용되지 않은 라벨 수
특성(feature) 결측치 모델 입력 특성 결측 없음 결측 건수와 실패 비율
값의 허용 범위 oxygen_saturation 0~100, heart_rate 1~250 허용 범위 초과 건수
관심 클래스 표본 수 최소 high_risk 샘플(sample) 수 기준 지표 해석 가능성

자동 검증의 핵심은 도구를 쓰는 것이 아니라 “무엇을 실패로 볼 것인가”를 명확히 정하는 것입니다. 같은 결측치라도 사용하지 않는 참고 컬럼의 결측치와 모델 입력 특성의 결측치는 영향이 다릅니다. 같은 범위 오류라도 한두 건의 수집 오류와 특정 시간대에 집중된 오류는 다른 조치로 이어질 수 있습니다. 그래서 자동 검증은 품질 저하 validation 데이터셋의 지표 변화를 바로 모델 자체 문제로 단정하지 않게 하는 기본 관문입니다.

따라서 자동 검증은 QA 판단을 대체하지 않습니다. 자동 검증은 QA 판단을 일관되게 만들기 위한 장치입니다. 검증 결과를 보고 평가 가능, 조건부 평가, 평가 보류 중 무엇이 적절한지 판단하는 일은 여전히 사람이 해야 합니다.

2-1-2. 검증 규칙의 의미

검증 규칙은 데이터가 모델 평가 전에 만족해야 하는 조건입니다. 여기서 규칙은 단순한 파일 형식이나 컬럼 존재 여부만 뜻하지 않습니다. 모델 지표 해석에 영향을 주는 라벨, 특성, 관심 클래스 표본 수, 허용 범위도 검증 규칙으로 관리해야 합니다.

실습에서는 두 종류의 설정 파일을 구분해서 봅니다. configs/validation/data_quality_rules.yaml은 과정 전체에서 공유하는 데이터 품질 기준이고, configs/validation/great_expectations_rules.yaml은 2-2 Demo에서 실제 검증 리포트로 보여줄 대표 기대 조건(expectation)입니다. 두 파일의 목적은 도구 문법을 외우는 것이 아니라, 모델 평가 전에 확인할 품질 기준을 파일로 남기는 것입니다.

두 파일은 같은 품질 관점을 다루지만 쓰임이 다릅니다. 공통 기준은 1장 리포트, 2장 비교, 이후 실습에서 반복해서 참조합니다. Demo 기준은 그중 일부를 Great Expectations 형태의 산출물로 보여줍니다.

파일 역할 확인할 기준
data_quality_rules.yaml 과정 전체에서 공유하는 공통 기준 허용 라벨, 관심 클래스 표본 수, 결측 허용 비율, 수치 범위
great_expectations_rules.yaml 2-2 Demo에서 리포트로 확인할 대표 기준 label 존재, label 결측 없음, heart_rate 결측 없음, oxygen_saturation 범위

따라서 2-1에서는 먼저 공통 기준을 이해하고, 2-2에서는 그 기준이 검증 요약과 검증 문서(Data Docs)에서 어떻게 보이는지 확인합니다. 모든 공통 기준이 2-2 Demo의 기대 조건으로 들어가지는 않습니다. 관심 클래스 표본 수처럼 모델 지표 해석에 필요한 기준은 2-4 모델 평가와 2-5 데이터 품질 비교에서 다시 확인합니다.

이 구분은 문서 흐름을 이해하는 데 중요합니다. 2-2의 검증 리포트는 “데이터 조건이 흔들렸다”는 첫 증거이고, 2-4와 2-5의 Lab은 “그 조건에서 지표와 예측(prediction) 분포가 어떻게 달라졌는가”를 확인하는 단계입니다.

중요한 순서는 QA 기준이 먼저이고 도구가 나중이라는 점입니다. Great Expectations는 이 기준을 실행하고 리포트로 남기는 도구 중 하나입니다. 수강생은 “도구 문법을 얼마나 아는가”보다 “어떤 규칙이 실패하면 모델 평가에 제한 사항을 남겨야 하는가”를 먼저 이해해야 합니다.

아래 규칙은 1장에서 확인한 품질 기준을 파일로 옮긴 예입니다. 이 값들은 “통과/실패 이름”을 외우기 위한 것이 아니라, 평가 전 판단을 일관되게 만들기 위한 기준입니다.

allowed_labels:
  - high_risk
  - low_risk

minimum_positive_support: 30
maximum_missing_ratio: 5.0

valid_ranges:
  heart_rate:
    min: 1
    max: 250
  oxygen_saturation:
    min: 0
    max: 100

이 예시에서 allowed_labels는 모델 평가에 허용할 라벨 목록입니다. minimum_positive_support는 관심 클래스 표본 수가 너무 적으면 high_risk 평가가 불안정하다는 기준입니다. maximum_missing_ratio는 결측치 비율이 일정 수준을 넘으면 입력 조건이나 평가 신뢰도가 흔들릴 수 있다는 기준입니다.

1장 기준 데이터에서는 high_risk 표본 수가 10416건으로 minimum_positive_support: 30을 충분히 넘습니다. 그래서 1장에서는 관심 클래스 표본 수 부족이 지표 해석을 크게 제한하지 않는다고 판단했습니다. 반대로 이후 평가 데이터에서 high_risk가 10건뿐이라면, 같은 모델 지표라도 관심 클래스(Positive class) 해석은 훨씬 불안정해집니다.

검증 규칙은 크게 세 가지 성격으로 나눌 수 있습니다.

규칙 성격 예시 QA 관점
구조 규칙 필수 컬럼 존재, 데이터 타입 모델 입력과 라벨이 준비되었는지 확인
값 규칙 결측값, 허용 범위, 허용 라벨 데이터 오류가 점수(score)와 지표를 왜곡하는지 확인
평가 전 판단 규칙 관심 클래스 표본 수, 클래스(class) 비율 지표 해석이 가능한 표본 조건인지 확인

좋은 검증 규칙은 실패했을 때 다음 조치를 결정할 수 있어야 합니다. 예를 들어 heart_rate 범위 오류가 2건이면 해당 행(row)을 확인하고 제한 사항을 남긴 평가가 가능할 수 있습니다. 그러나 label 결측치가 많거나 허용되지 않은 라벨이 섞여 있으면 지표 계산을 신뢰하기 어렵기 때문에 평가 전에 라벨 기준을 먼저 보완해야 합니다.

반대로 너무 많은 규칙을 처음부터 만들면 운영하기 어렵습니다. 초기 학습 단계에서는 모델 평가에 직접 영향을 주는 규칙부터 다룹니다. 필수 컬럼, 결측값, 범위, 라벨, 관심 클래스 표본 수를 중심으로 시작하고, 이후 운영 로그나 서비스 요구에 따라 규칙을 확장하는 방식이 현실적입니다.

2-1-3. 결측값, 범위, 라벨 검증 기준

결측값, 범위, 라벨 검증은 모델 평가 신뢰도를 지키는 기본 기준입니다. 기본이라는 말은 단순하다는 뜻이 아닙니다. 이 세 가지가 흔들리면 이후 모델 지표와 운영 품질 판단도 함께 흔들립니다.

결측값은 데이터에서 값이 비어 있는 상태입니다. 모델 입력 특성에 결측값이 많으면 모델이 점수를 안정적으로 계산하지 못하거나, 전처리 과정에서 임의 값으로 대체되어 점수 분포가 왜곡될 수 있습니다. 라벨에 결측값이 있으면 예측과 정답을 비교할 수 없기 때문에 지표 계산 자체가 불안정해집니다.

범위 오류는 값이 존재하지만 의미상 허용하기 어려운 상태입니다. 예를 들어 oxygen_saturation이 135라면 데이터 타입은 숫자이고 결측도 아니지만 값의 의미는 잘못되었습니다. 이런 값은 모델이 평가할 때 특성 분포를 왜곡할 수 있습니다.

라벨 오류는 AI QA에서 특히 중요합니다. 라벨은 모델 평가의 정답 기준입니다. 허용되지 않은 라벨이나 라벨 기준 오류가 있으면 모델이 맞게 예측해도 틀린 것으로 계산될 수 있고, 반대로 잘못 예측했는데 맞은 것으로 계산될 수도 있습니다.

검증 실패는 다음처럼 해석합니다.

검증 기준 실패 예시 QA 해석 다음 조치
결측값 label 누락 지표 계산을 신뢰하기 어려움 라벨 생성과 허용 라벨 기준 확인
범위 oxygen_saturation = 135 특성 오류가 점수 분포를 왜곡 가능 수집 오류인지 유효 극단값인지 구분
라벨 unknown 관심 클래스와 비교 클래스(Negative class) 기준이 흔들림 허용 라벨 목록과 라벨 기준 확인
스키마 heart_rate 컬럼 누락 모델 입력 미준비 데이터 추출 또는 스키마 변경 확인

이 표에서 중요한 것은 실패 항목마다 심각도와 조치가 다르다는 점입니다. QA는 “검증 실패”라는 하나의 표현으로 끝내지 말고, 어떤 실패가 모델 평가를 막는지, 어떤 실패는 제한 사항을 기록하고 평가할 수 있는지 구분해야 합니다.

2-2 Demo에서는 이 기준을 vital_signs_valid_degraded.csv에 적용합니다. 예를 들어 label 검증은 통과하지만 heart_rate 결측과 oxygen_saturation 범위 검증은 실패합니다. 이 경우 정답 기준 붕괴로 설명하기는 어렵지만, 모델 입력 특성이 점수와 지표를 흔들 수 있으므로 조건부 평가 판단과 제한 사항 기록이 필요합니다.

Demo 산출물인 artifacts/great_expectations/chapter_02_validation_summary.md에서는 이 차이가 실패 건수와 실패 비율로 나타납니다. 2-1에서는 정확한 숫자를 외우는 것이 아니라, 어떤 검증 실패가 정답 기준 문제인지 입력 특성 문제인지 구분하는 것이 중요합니다. 정확한 건수와 비율은 2-2 Demo에서 검증 리포트를 보며 확인합니다.

Demo에서 볼 실패 관측값 2-1에서 가져갈 해석
heart_rate 결측 일부 모델 입력 특성 결측 입력 정보 부족이 점수를 흔들 수 있음
oxygen_saturation 범위 오류 일부 허용 범위 초과 의미상 불가능한 값이 점수 분포를 왜곡할 수 있음
label 결측과 허용 라벨 검증 통과 정답 기준 자체가 무너진 상황은 아님

실무에서는 결측과 범위 오류가 동시에 나타날 수 있습니다. 예를 들어 특정 입력 경로에서 heart_rate가 비어 있고 oxygen_saturation에는 불가능한 값이 들어온다면 단순 데이터 오류가 아니라 수집 경로 문제일 수 있습니다. 이런 경우에는 데이터 검증 결과를 운영 로그와 연결해 원인을 추적해야 합니다.

2-1-4. 관심 클래스 표본 수와 평가 전 판단 기준

관심 클래스 표본 수는 관심 있게 평가할 클래스(Positive class)의 샘플이 얼마나 있는지를 뜻합니다. 이진 분류(binary classification)는 결과를 두 클래스 중 하나로 나누는 모델입니다. 예제에서는 high_risk를 관심 클래스로 보고, low_risk를 비교 클래스로 봅니다.

관심 클래스 표본 수가 너무 작으면 재현율(Recall), PR-AUC(AUPRC), 혼동 행렬(Confusion Matrix) 해석이 불안정합니다. 예를 들어 high_risk 샘플이 5개뿐인 데이터에서 모델이 4개를 맞히면 재현율은 80%입니다. 숫자로는 높아 보일 수 있지만 샘플 하나가 바뀌면 재현율이 크게 달라집니다. 반대로 high_risk 샘플이 500개인 데이터에서 재현율 80%라면 훨씬 안정적인 해석이 가능합니다.

관심 클래스 표본 수는 검증 리포트 하나로 끝낼 기준이 아니라, 모델 지표를 읽기 전에 계속 확인해야 하는 평가 전제입니다. 실습에서는 공통 데이터 품질 기준인 minimum_positive_support를 표본 조건의 기준으로 둡니다. Great Expectations Demo는 결측값, 범위, 라벨 기준을 대표로 보여주고, 관심 클래스 표본 수는 모델 평가와 데이터 품질 비교에서 지표 해석 조건으로 다시 확인합니다.

관심 클래스 표본 수 상태 지표 해석 QA 판단
충분함 재현율, PR-AUC, 혼동 행렬 해석이 비교적 안정적 모델 지표 해석 진행
부족함 관심 클래스 탐지 품질을 판단하기 어려움 조건부 평가 또는 데이터 보강 검토
없음 관심 클래스 관련 지표를 계산하거나 해석하기 어려움 평가 보류 또는 평가 데이터 재구성

관심 클래스 표본 수가 부족하면 정확도(Accuracy)가 특히 위험한 지표가 됩니다. 비교 클래스가 대부분인 데이터에서는 모두 비교 클래스로 예측해도 정확도가 높게 나올 수 있습니다. 이때 QA가 정확도만 보고 품질 기준을 충족한다고 판단하면 관심 클래스를 놓치는 문제를 발견하지 못합니다.

QA 판단은 다음처럼 정리할 수 있습니다.

확인 질문 판단
관심 클래스 표본 수 최소 기준을 충족하는가 재현율과 PR-AUC 해석 가능성 판단
관심 클래스 비율이 지나치게 낮은가 정확도 착시 가능성 확인
관심 클래스 샘플이 특정 구간에 편중되는가 평가 데이터 대표성 확인
관심 클래스 라벨 오류가 집중되는가 관심 클래스 평가 왜곡 가능성 확인

관심 클래스 표본 수는 2-4 모델 평가 실습의 임계값(threshold) 분석과도 연결됩니다. 임계값을 낮추거나 높이면 오탐(FP)과 미탐(FN)이 달라질 수 있는데, 관심 클래스 표본 수가 부족하면 그 변화도 안정적으로 해석하기 어렵습니다. FP/FN의 세부 의미는 2-3에서 혼동 행렬과 함께 다룹니다.

2-1의 결론은 간단합니다. 수동 확인으로 발견한 데이터 품질 기준을 검증 규칙으로 만들면 같은 기준을 반복 적용할 수 있습니다. 2-2에서는 이 규칙을 Great Expectations 리포트로 확인하고, 실패 결과를 QA 판단으로 해석합니다.