콘텐츠로 이동

2-2. Great Expectations 기반 검증 리포트 확인

검증 리포트는 모델 지표(metric)를 계산하기 전에 평가 조건의 흔들림을 확인하는 첫 산출물입니다. Great Expectations Demo의 목적은 현재 운영 입력 샘플의 실패 양상을 validation 기준에서 재현한 품질 저하 데이터셋에서 어떤 기대 조건(expectation)이 실패했는지 확인하고, 그 실패가 평가 가능, 조건부 평가, 평가 보류 중 어떤 판단에 가까운지 정리하는 것입니다. 핵심은 Great Expectations 프로젝트를 구성하는 방법이 아니라, 기대 조건, 검증 결과(validation result), 검증 문서(Data Docs)를 QA 판단 근거로 읽는 것입니다.

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

  • 도구 역할: Great Expectations를 데이터 기준과 검증 결과를 남기는 도구로 이해
  • 핵심 용어: 기대 조건, 검증 결과, 검증 문서의 역할 구분
  • Demo 산출물: vital_signs_valid_degraded.csv 검증 결과의 통과/실패 항목 확인
  • QA 해석: 실패한 규칙이 모델 평가 전 판단과 지표 해석에 미치는 영향 판단

2-2에서는 아직 모델 성능을 계산하지 않습니다. 먼저 vital_signs_valid_degraded.csvheart_rate 결측과 oxygen_saturation 범위 오류를 확인하고, 이 실패가 뒤에서 계산할 점수(score), 예측(prediction), 지표에 어떤 제한 사항을 남기는지 정리합니다. 이 파일은 실제 운영 DB 덤프가 아니라, 운영 입력에서 나타날 수 있는 실패 양상을 validation 비교용으로 재현한 artifact입니다.

2-2-1. Great Expectations 개념

Great Expectations는 데이터가 미리 정한 기대 조건을 만족하는지 확인하고 결과를 남기는 도구입니다. 여기서 기대 조건은 “label은 비어 있으면 안 된다”, “oxygen_saturation0에서 100 사이여야 한다”, “라벨(label)은 high_risklow_risk만 허용한다” 같은 데이터 기준입니다.

2-2의 범위는 Great Expectations 설치와 운영법을 깊게 다루는 데 있지 않습니다. QA 관점에서 중요한 것은 검증 결과를 보고 모델 평가 전 판단에 어떤 영향을 주는지 해석하는 것입니다. 도구 이름보다 중요한 것은 검증 실패가 평가 가능, 조건부 평가, 평가 보류 중 어디에 가까운지 설명하는 일입니다.

수동 Pandas 확인은 데이터 상태를 직접 이해하는 데 좋지만, 콘솔 출력이나 노트북 결과로 끝나기 쉽습니다. Great Expectations 같은 검증 도구를 사용하면 어떤 기준을 적용했는지, 어떤 기준이 실패했는지, 실패한 컬럼과 비율이 무엇인지 산출물(artifact)로 남길 수 있습니다. 이 기록은 나중에 모델 지표가 흔들렸을 때 데이터 조건을 되짚는 근거가 됩니다.

Great Expectations 공식 문서는 GX Core의 핵심 구성 요소와 데이터 검증 흐름(workflow)을 설명합니다. 2-2에서는 수강생이 GX 프로젝트를 직접 구성하지 않습니다. 대신 Great Expectations의 설명 방식을 빌려 기대 조건, 검증 결과, 검증 문서를 보고, 실패한 규칙을 QA 판단으로 읽는 부분에 집중합니다.

2-2 Demo에서 Great Expectations를 사용하는 방식은 다음과 같습니다.

관점 2-2 Demo에서의 의미 QA가 확인할 것
기준 명시 검증 규칙(validation rule)을 설정 파일과 기대 조건으로 기록 어떤 데이터 조건을 통과 기준으로 삼았는가
반복 실행 vital_signs_valid_degraded.csv에 같은 기준을 적용 데이터가 바뀌어도 같은 기준이 적용되는가
결과 기록 검증 결과와 검증 문서를 산출물로 저장 어떤 기준이 실패했고 실패 비율은 얼마인가
판단 연결 실패한 규칙을 모델 평가 전 판단으로 해석 평가 가능, 조건부 평가, 평가 보류 중 어디에 가까운가

흔한 오해는 Great Expectations를 쓰면 데이터 품질 문제가 자동으로 해결된다고 생각하는 것입니다. 이 도구는 문제를 고치지 않습니다. 정의한 기준에 따라 문제를 발견하고 기록할 뿐입니다. 어떤 실패를 평가 보류 사유로 볼지는 QA와 운영 기준에서 결정해야 합니다.

2-2-2. 기대 조건, 검증 결과, 검증 문서 이해

Demo 산출물은 기준, 원자료, 검토 화면으로 나누어 읽습니다. 기대 조건은 데이터가 만족해야 하는 기준이고, 검증 결과는 그 기준을 데이터에 적용한 성공/실패 원자료이며, 검증 문서는 결과를 사람이 읽기 좋게 정리한 화면입니다.

용어 구분은 도구 내부 구조보다 수강생이 확인할 산출물과 판단 질문을 기준으로 잡아야 합니다. 아래 표는 용어를 도구 내부 구조가 아니라 수강생이 확인할 산출물 기준으로 정리한 것입니다.

용어 의미 이번 Demo에서 확인할 것
기대 조건 데이터가 만족해야 하는 기준 label 존재, label 결측 없음, oxygen_saturation 범위
검증 결과 각 기준의 성공/실패 원자료 실패 여부, 실패 건수, 실패 비율
검증 문서 사람이 읽을 수 있는 검토 화면 실패한 기준을 빠르게 확인

Demo 코드는 다음 위치에 있습니다. 이 스크립트는 교육용 산출물을 생성해 Great Expectations의 핵심 읽기 흐름을 재현합니다. 시간이 있는 수강생은 직접 실행하고, 시간이 부족하면 준비된 산출물을 열어 실패 항목과 평가 제한 사항을 해석합니다.

uv run python demos/ch02_great_expectations/run_demo.py

생성되는 산출물은 artifacts/great_expectations 아래에 저장됩니다. 수강생은 Great Expectations 프로젝트를 직접 구성하지 않아도, 제공 스크립트와 준비된 산출물을 통해 어떤 기대 조건이 실패했는지 확인할 수 있습니다.

구분 실행 또는 확인 경로 수강생이 확인할 것
기대 조건 chapter_02_expectations.json 어떤 기준을 적용했는가
검증 결과 chapter_02_validation_result.json 어떤 기준이 실패했고 실패 건수는 얼마인가
검증 요약 chapter_02_validation_summary.md QA 보고에 쓸 핵심 결과는 무엇인가
검증 문서 역할 화면 chapter_02_data_docs.html 실패한 검증 항목을 빠르게 찾을 수 있는가

Demo에서 중요한 확인 포인트는 도구 화면의 위치가 아니라 판단 근거입니다. 같은 실패라도 라벨 기준이 깨졌는지, 모델 입력 특성(feature)이 흔들렸는지에 따라 다음 판단이 달라집니다.

확인 포인트 확인 질문 판단에 미치는 영향
기대 조건 목록 어떤 데이터 기준을 적용했는가 평가 전에 확인한 기준의 범위 파악
검증 결과 어떤 기준이 실패했는가 실패한 기준을 원인 후보로 기록
실패 컬럼 실패가 라벨, 특성, 스키마(schema) 중 어디에 해당하는가 정답 기준 문제인지 입력 품질 문제인지 구분
실패 비율 일부 제한 사항인지, 평가를 흔들 수준인지 조건부 평가평가 보류 판단 근거
후속 확인 항목 이후 Lab에서 어떤 지표와 분포를 볼 것인가 점수, 예측, FP/FN 확인 계획

이 Demo는 1장의 Pandas 기반 확인을 자동화된 리포트로 바꿔 보는 과정입니다. 수동 확인으로 찾은 기준이 기대 조건이 되고, 그 결과가 모델 평가 전 QA 보고에 사용할 수 있는 근거가 된다는 점을 이해하면 됩니다.

2-2-3. 데이터 검증 리포트 확인

Demo 리포트는 vital_signs_valid_degraded.csv에서 6개 기대 조건 중 2개가 실패했음을 보여줍니다. 이 데이터는 교육 목적으로 결측치와 범위 오류를 포함합니다. 따라서 수강생은 “실패했다”에서 멈추지 않고, 어떤 실패가 모델 지표 해석에 영향을 줄 수 있는지 읽어야 합니다.

검증 산출물은 같은 결과를 요약, 원자료, 검토 화면이라는 서로 다른 수준으로 보여줍니다. 먼저 chapter_02_validation_summary.md로 전체 실패 위치를 보고, chapter_02_validation_result.json으로 정확한 unexpected_count, unexpected_ratio, observed_value를 확인한 뒤, chapter_02_data_docs.html에서 실패 항목을 눈으로 확인하는 순서가 가장 빠릅니다.

현재 Demo 요약은 다음 값으로 시작합니다.

항목 해석
데이터셋 vital_signs_valid_degraded.csv 운영 입력 실패 양상을 validation에서 재현한 품질 저하 평가 데이터
행(row) 수 30003 평가 대상 규모 확인
전체 성공 여부 False 하나 이상의 기대 조건이 실패
통과한 기대 조건 4 모든 기준이 실패한 것은 아님
실패한 기대 조건 2 실패 항목의 성격을 해석해야 함

검증 결과를 조금 더 자세히 보면 다음과 같습니다.

기대 조건 컬럼 결과 실패 건수 실패 비율 QA 해석
컬럼 존재 label 통과 0 0.00% 라벨 컬럼은 존재
결측 없음 label 통과 0 0.00% 정답 기준 결측 없음
결측 없음 heart_rate 실패 1501 5.00% 특성 결측이 점수에 영향 가능
허용 라벨 label 통과 0 0.00% 허용되지 않은 라벨 없음
허용 범위 oxygen_saturation 실패 1201 4.00% 범위 오류가 점수 분포를 왜곡 가능
허용 범위 heart_rate 통과 0 0.00% 범위 오류는 없지만 결측 실패는 존재

이 결과에서 가장 중요한 점은 라벨 허용값 검증과 정답 기준 신뢰를 분리해서 읽어야 한다는 점입니다. 라벨 검증이 통과했다는 말은 label 값이 허용 목록 안에 있고 결측이 없다는 뜻이지, 모든 행의 정답이 실제 상태와 완전히 일치한다는 뜻은 아닙니다. 따라서 이번 Demo에서는 라벨 결측이나 허용되지 않은 라벨로 인한 평가 보류 사유는 약하지만, 뒤에서 품질 저하 validation 데이터셋의 라벨 반전 후보를 볼 때는 정답 기준 흔들림 가능성을 별도로 기록해야 합니다.

허용 라벨 검증 결과는 다음처럼 해석 범위를 제한해서 보고서에 씁니다.

확인 항목 이번 결과 쓸 수 있는 판단 쓰면 안 되는 판단
label 결측 0 정답 기준 결측으로 인한 평가 보류 사유는 없음 모든 라벨이 실제 상태와 일치함
허용 라벨 실패 0 high_risk, low_risk 기준으로 지표 계산 가능 라벨 반전 가능성이 없음
특성 결측과 범위 heart_rate, oxygen_saturation 실패 입력 특성이 점수와 지표를 흔들 수 있음 모델 자체 결함으로 확정

이 제한을 붙이면 라벨 기준은 통과했지만 특성 기준은 실패했다는 판단이 과잉 확신으로 흐르지 않습니다. heart_rate 결측과 oxygen_saturation 범위 오류는 모델 입력을 흔들 수 있으므로, 뒤에서 계산할 점수, 예측, 지표에 제한 사항을 붙여야 합니다.

heart_rate는 범위 검증에서는 통과했지만 결측값 검증에서는 실패했습니다. 이 차이가 중요합니다. “값이 있을 때 범위는 정상”이라는 사실과 “일부 행에 값이 없다”는 사실은 서로 다른 품질 문제입니다. QA는 하나의 컬럼도 결측값, 범위, 라벨 기준처럼 서로 다른 검증 관점으로 나누어 읽어야 합니다.

QA는 검증 리포트를 다음 순서로 읽습니다.

순서 확인 내용 이유
1 검증 대상 데이터셋과 행 수 비교 대상과 규모 확인
2 통과/실패 기대 조건 수 전체 실패 여부보다 실패 위치 파악
3 실패 컬럼 분류 라벨, 특성, 스키마 중 어디가 흔들렸는지 확인
4 실패 비율과 모델 영향 조건부 평가인지 평가 보류인지 판단
5 2-4/2-5 Lab에서 확인할 주의 사항 지표, 점수, 예측 분포 해석 제한 사항 기록

이 흐름을 지키면 검증 리포트가 단순한 도구 출력이 아니라 QA 판단 문서가 됩니다. 특히 나중에 모델 지표가 낮게 나오면, heart_rate 결측과 oxygen_saturation 범위 오류가 점수 분포를 흔들었는지 먼저 확인할 수 있습니다.

2-2-4. 검증 실패 결과의 QA 해석

검증 실패는 모델 평가를 무조건 중단하라는 뜻이 아니라, 어떤 판단에 제한을 걸어야 하는지 알려주는 신호입니다. 이번 Demo에서는 라벨 기준은 통과했고 특성 기준에서 실패가 발생했습니다. 따라서 “정답 기준이 깨졌다”가 아니라 “입력 특성이 점수를 흔들 수 있다”는 해석이 더 적절합니다.

이번 결과를 QA 판단으로 바꾸면 다음과 같습니다.

실패 결과 모델 평가 영향 가능한 QA 판단
heart_rate 결측 1501 해당 특성을 사용하는 모델의 점수가 불안정해질 수 있음 조건부 평가, 결측 처리 방식 확인
oxygen_saturation 범위 오류 1201 허용 범위 밖 값이 점수 분포를 왜곡할 수 있음 조건부 평가, 수집/가공 경로 확인
label 결측 0 정답 기준 결측은 확인되지 않음 라벨 결측으로 인한 평가 보류 사유는 아님
허용되지 않은 label 0 이진 분류(binary classification) 라벨 기준은 유지됨 지표 계산 기준은 유지

이 결과만으로 모델 품질이 나쁘다고 단정하면 안 됩니다. 아직 모델 지표를 계산하지 않았고, 실패한 데이터가 점수와 예측에 얼마나 영향을 주는지도 확인하지 않았기 때문입니다. 다만 vital_signs_valid_degraded.csv를 같은 모델과 임계값(threshold)으로 평가하고 점수와 예측 분포를 비교할 때는 결측과 범위 오류를 원인 후보로 함께 기록해야 합니다.

검증 실패의 심각도는 다음 기준으로 나눌 수 있습니다.

심각도 의미 예시 판단
높음 평가 자체를 신뢰하기 어려움 label 결측, 필수 컬럼 누락 평가 보류
중간 제한 사항을 기록하고 평가 가능 일부 특성 결측, 낮은 비율의 범위 오류 조건부 평가
낮음 즉시 평가 영향은 작지만 기록 필요 사용하지 않는 참고 컬럼 결측 기록 후 진행

이번 Demo는 중간 심각도에 가깝습니다. 라벨 기준은 유지되지만 모델 입력 특성에 결측과 범위 오류가 있으므로, QA 코멘트에는 조건부 평가와 “특성 품질 이슈로 인한 지표 해석 제한”을 남기는 것이 자연스럽습니다.

예시 QA 코멘트는 다음과 같습니다.

vital_signs_valid_degraded.csv 검증 결과, `label` 컬럼 존재, `label` 결측 없음,
허용 라벨 기준은 통과했습니다. 다만 `heart_rate` 결측 1501건과
`oxygen_saturation` 범위 오류 1201건이 확인되었습니다.

QA 판단: 조건부 평가
판단 근거: 정답 기준은 유지되지만, 모델 입력 특성 품질 이슈가
점수와 지표 해석에 영향을 줄 수 있습니다.
후속 조치: 기준 validation 데이터셋과 품질 저하 validation 데이터셋의
지표 차이를 비교하고, 점수와 예측 분포까지 확인합니다.
결측/범위 오류는 지표 변화의 원인 후보로 기록합니다.

QA는 실패를 발견했을 때 “누가 고쳐야 하는가”보다 “어떤 판단을 보류하거나 제한해야 하는가”를 먼저 정리해야 합니다. 데이터 생성, 모델 평가, 운영 수집 중 어느 지점에서 조치가 필요한지는 이후 원인 분석에서 확인하더라도, 검증 리포트 단계에서는 모델 지표를 어떤 조건에서 읽어야 하는지 먼저 남겨야 합니다.