데이터 오류와 검증¶
모델 평가 수치는 어느 원본 데이터와 특성, 데이터 분할에서 나왔는지를 확인해야 안전하게 해석할 수 있습니다. 이 실습에서는 로컬 환경에 준비된 데이터가 어떤 범위와 규칙을 따르는지 확인합니다. 원본 데이터를 다시 설계하거나 특성을 조정하지 않고, 노트북에서 데이터 분할과 데이터 규칙을 살펴본 뒤 보고서에 기록할 사실과 아직 판단할 수 없는 사실을 구분합니다.
강의 순서에서의 위치
Pandas 관찰과 자동 검증은 같은 데이터 근거를 서로 다른 수준에서 보강합니다. 1일차 오전 3교시에는 원시 측정값과 데이터 오류를, 1일차 오후 4교시에는 데이터 검증 자동화를 진행한 뒤 데이터 품질 근거를 갱신합니다.
실습 목표¶
보고서의 데이터 품질 근거에는 원본 관측값, 가공한 특성, 데이터 분할, 구조 검증이 각각 보여 주는 범위를 구분해 적어야 합니다. 이 실습을 마치면 이 구분을 보고서 한 행으로 설명할 수 있습니다. 원본 행이 특성으로 바뀌는 과정이 낯설다면 AI 품질과 이상 신호와 데이터 역할과 분할을 먼저 읽습니다.
실습에서 할 일
- 로컬 데이터 준비 상태를 확인합니다.
- 노트북에서 원본·특성·분할·결측·라벨 구조를 확인합니다.
- 자동 구조 검증을 실행하고 성공 또는 실패의 범위를 기록합니다.
- 모델 승인이나 대상 환경 상태로 확장하지 않고 데이터 품질 근거를 작성합니다.
실습 전 확인
모든 명령은 tta-aiqa 저장소 루트에서 실행합니다. 실습 환경 준비에서 저장소 위치와 노트북 실행 환경을 확인하고, 과거 평가 자료를 덮어쓰거나 최종 평가 데이터를 다시 사용하지 않습니다.
이 실습의 근거는 로컬 데이터 준비 상태와 평가 범위에만 적용됩니다. 검증이 모두 성공해도 모델 승인이나 대상 환경 실행 상태를 판단할 수 없으며, 완료 기준은 데이터 범위와 규칙이 어긋났을 때의 담당자를 보고서에 기록하는 것입니다.
1. 실습 자료와 범위¶
로컬 데이터 상태가 설명한 평가 범위와 같아야 노트북에서 본 수치를 근거로 기록할 수 있습니다. DVC(Data Version Control)는 데이터와 처리 단계의 준비 상태를 확인하는 도구이며, 이 실습에서는 로컬 DVC 환경의 원본 데이터와 가공 데이터, 현재 데이터 분할 정보를 확인합니다. 이 자료는 로컬 데이터 준비 상태를 확인하는 데 쓰며, docs/evidence/에 있는 준비된 읽기 전용 근거를 갱신하는 용도로 사용하지 않습니다.
원본 관측값, 가공한 특성 표, 데이터 분할 정보는 서로 다른 역할을 합니다. 원본 데이터와 가공 데이터는 현재 구조 검증의 대상이고, 데이터 분할 정보는 최종 평가 데이터와 정답이 없는 운영용 입력을 나누는 기준입니다.
이 단계에서 남길 메모는 다음 세 가지입니다.
- 로컬 DVC 상태가 문서의 데이터 범위와 같은지
- 노트북이 확인할 분할과 특성 표가 무엇인지
- 과거 배포 판단 자료를 다시 만들거나 수정하지 않았는지
2. 로컬 데이터 준비 상태 확인¶
로컬 데이터 준비 상태가 최신인지 확인해야 노트북과 구조 검증의 결과를 현재 데이터 범위의 증거로 쓸 수 있습니다. 아래 명령은 그 준비 상태를 확인합니다.
uv run --group dev dvc status
Data and pipelines are up to date.는 현재 체크아웃의 DVC 추적 의존성과 산출물에 변경이 감지되지 않았다는 뜻입니다. 이것만으로 수업 revision이나 과거 승인 자료와 같다고 판단하지 않고 분할 revision과 지문을 함께 대조합니다. 준비가 필요한 파일이 확인되면 아래 명령으로 로컬 데이터를 다시 준비합니다.
uv run python labs/run/prepare_data.py
로컬 데이터를 다시 준비해도 준비된 읽기 전용 근거 파일은 바뀌어서는 안 됩니다. 이 명령으로 준비하는 원본 데이터와 가공 데이터, Git에서 추적하지 않는 결과 파일은 로컬 환경에만 적용됩니다. docs/evidence/의 근거 파일을 다시 만들거나 수정하지 않습니다. 네트워크나 원본 데이터 준비가 막히면 후속 명령을 성공한 것처럼 기록하지 않고 BLOCKED로 남긴 뒤 준비된 근거를 확인합니다.
원시 측정값과 데이터 오류¶
노트북의 숫자는 모델 평가가 적용되는 데이터 범위를 확인하는 근거이며, 모델 성능 자체의 결론은 아닙니다. VS Code에서 다음 노트북을 열고 위에서 아래로 실행해 평가 수치가 나온 데이터의 구성과 각 데이터 묶음의 역할을 확인합니다.
labs/chapters/ch01/01_physionet_data_quality_eda.ipynb
Pandas는 표 형태의 데이터를 불러오고, 열별 결측과 값의 분포를 계산하는 Python 라이브러리입니다. 이 실습에서는 문법을 외우기보다 read_csv, value_counts, isna, quantile 결과가 어떤 품질 질문에 답하는지 확인합니다.
이 값들은 평가 결과의 적용 범위와 운영에서 아직 답할 수 없는 질문을 구분하는 근거입니다. 특히 역할별 건수와 결측 상태는 최종 평가 데이터와 정답 없는 운영용 입력을 섞지 않는 기준입니다. 라벨과 이상치 후보 점검은 데이터 오류를 자동으로 확정하는 규칙이 아니라, 2장의 지표를 해석하기 전에 더 확인할 항목을 정하는 활동입니다.
노트북에서 확인한 값은 보고서에 남길 데이터 범위와 조사 대상을 정하는 근거입니다. 이 값만으로 모델 품질이나 실제 API 입력 상태를 판단하지 않습니다.
| 확인할 항목 | 예상 결과 | 보고서에 적는 이유 |
|---|---|---|
| 원본 예시 | Time/Parameter/Value, -1 결측 표식, 48시간 이내 시각 |
관측값과 결측 표식을 데이터 규칙 위반과 구분합니다. |
| 대상 집합 구성 | 4,000행, 모델 입력에 사용하는 특성 133개, 교육용 target 554건 |
모델 평가에 사용한 데이터와 특성의 범위를 밝힙니다. |
| 역할별 건수 | train 2,900, valid 600, test 400, operational 100 |
최종 평가 데이터와 정답 없는 운영용 입력을 구분합니다. |
| 결측 비율 표 | 결측 표시가 높은 특성 | 실제 API 입력 상태를 조사할 후보로 남기되 원인으로 단정하지 않습니다. |
| 라벨 구조와 클래스별 건수 | 결측 0, 허용값 위반 0, 중복 식별자 0, low_risk 3,446건, high_risk 554건 |
라벨 연결 구조와 클래스 불균형을 지표 해석 조건으로 남깁니다. |
| 관측 행 수의 이상치 후보 | 노트북이 읽은 원본 표본에서 계산한 IQR 범위와 후보 건수 | 원본을 더 확인할 후보이며 자동 삭제나 구조 실패가 아님을 기록합니다. |
노트북의 assertion은 예상한 조건이 맞는지 확인하는 검증식입니다. 이 검증식이 실패하면 숫자만 고치지 않습니다. 실행한 저장소 버전, DVC 상태, 원본 데이터 규칙과 분할 정보의 경로를 보고서에 남기고 데이터 담당자에게 알립니다.
데이터 검증 자동화¶
데이터 규칙 위반을 모델 품질 변화로 오인하지 않으려면 원본 데이터와 가공 데이터의 구조를 따로 검증해야 합니다. Great Expectations(GE)은 이 구조가 정해 둔 규칙을 충족하는지 검사하는 도구입니다. 아래 명령은 원본 적재와 가공 데이터 준비 과정이 이 규칙을 통과하는지 확인합니다.
uv run python labs/run/validate_data.py
검증 결과는 성공 여부뿐 아니라 어떤 규칙을 점검했는지 추적할 수 있어야 보고서 근거가 됩니다. 아래 로컬 파일에서 검증 결과와 세부 내용을 확인합니다.
artifacts/data-quality/great-expectations/validation-summary.json
artifacts/data-quality/great-expectations/raw/gx/uncommitted/data_docs/
artifacts/data-quality/great-expectations/processed/gx/uncommitted/data_docs/
로컬 환경에서는 원본 적재 8개와 가공 데이터 준비 57개 검증 항목이 모두 성공해야 합니다. 이 결과는 원본 데이터와 가공 데이터의 구조를 확인한 자료이며 V2 분할 역할을 검증한 결과는 아닙니다. 데이터 역할과 최종 평가 범위는 configs/data/split-v2.yaml과 docs/evidence/data-v2/split-revision.json에서 따로 확인합니다.
같은 품질 질문을 반복 가능한 규칙으로 바꾸기¶
자동화하려면 관찰한 문제를 검사 대상과 조건으로 구체화해야 합니다. “시간이 이상하다”는 메모만으로는 다음 배치에서 같은 문제를 찾기 어렵습니다. 관측 시간 열을 분 단위로 해석하고, 하한 0과 상한 2,880을 포함하는지 확인하며, 벗어난 레코드와 값을 결과에 남겨야 실행 가능한 규칙이 됩니다. Great Expectations의 Expectation 설명도 데이터에 대한 검증 가능한 조건을 정의하는 방식으로 연결됩니다.
검사는 구조, 값 범위, 관계를 나누어 설계합니다. 필요한 열이 있는지는 구조 질문이고, 관찰 시간이 계약 범위에 드는지는 값 질문이며, 레코드와 정답이 올바른 키로 연결되는지는 관계 질문입니다. 서로 다른 실패를 찾으므로 한 종류의 성공을 전체 데이터 품질로 확대하지 않습니다.
| 규칙 종류 | 이 과정에서 확인하는 예 | 실패하면 먼저 조사할 대상 |
|---|---|---|
| 구조 | 원본 Time/Parameter/Value, 가공 표의 특성 열 |
읽은 파일과 처리 단계, 스키마 변경 |
| 값 범위 | 분 단위 관측 시간 0 <= minute <= 2880 |
단위 변환과 관찰 구간 |
| 관계 | 레코드 식별자와 정답 연결, 역할 중복 여부 | 조인 키, 중복, 분할 이력 |
성공률은 실행한 규칙 수와 함께 읽어야 합니다. 준비된 요약의 원본 검사는 8개 중 8개, 가공 검사는 57개 중 57개가 성공했습니다. 몇 규칙을 제거해도 성공률은 100%일 수 있으므로 evaluated_expectations와 규칙 식별값까지 비교합니다. 현재 요약의 publish_blocking_gate=false는 이 검증 결과가 게시를 자동으로 막거나 승인하는 gate로 연결되지 않았다는 뜻입니다.
실행 환경이나 원본 데이터가 준비되지 않았으면 읽기 전용 근거로 같은 해석을 연습합니다. 구조 검증은 docs/evidence/data-quality/ge-validation-summary.json, 데이터 역할은 docs/evidence/data-v2/split-revision.json에서 확인합니다. 이때 새 산출물을 생성한 것은 아닙니다. raw_ingestion, processed_readiness, 집계와 규칙의 SHA-256을 읽고 데이터 품질 근거에 “준비된 결과 확인”, offline, 직접 실행하지 못한 조건을 적습니다. 환경이 준비되면 앞의 명령으로 로컬 결과를 생성해 비교하고, 제공된 요약을 덮어쓰지 않습니다.
5. 결과 해석과 다음 조치¶
검증 결과는 성공 또는 실패만으로 결론 내리지 않습니다. 확인한 사실과 다음 조치를 함께 기록해야 데이터 규칙 위반과 모델 품질 문제를 혼동하지 않습니다.
결과를 기록할 때는 아래 순서를 따릅니다.
- DVC·노트북·GE 가운데 실제로 실행한 항목을 적습니다.
- 성공 또는 실패가 가리키는 데이터 규칙을 적습니다.
- 모델 품질 또는 대상 환경 상태는 이 실습에서 확인하지 않았다고 명시합니다.
- 실패했다면 데이터 담당자와 필요한 원본·경로를 남깁니다.
확인한 상황마다 지금 할 일과 다음 확인을 맡을 담당자를 구분해 기록합니다.
| 확인한 상황 | 지금 할 일 | 담당자와 다음 할 일 |
|---|---|---|
| DVC 상태가 최신이 아님 | 로컬 환경의 데이터가 문서에서 설명한 데이터와 같은지 확인합니다. | 데이터 담당자: 안전하게 데이터를 다시 준비하는 방법을 확인합니다. |
| 원본 또는 가공 데이터 검증 실패 | 품질 지표가 나빠진 원인이라고 단정하지 않고, 어느 데이터 규칙이 어긋났는지 기록합니다. | 데이터 담당자: 원본, 열 구조, 결측 표시 규칙을 조사합니다. |
| 결측 표식 또는 높은 결측 비율 | 관찰한 사실로 남기고, 원인으로 확정하지 않습니다. | 데이터와 서빙 담당자: 이후 API 입력도 같은 특성 조건인지 비교합니다. |
| 라벨 결측, 허용값 위반, 중복 발견 | 혼동 행렬과 품질 지표를 계산할 조건이 깨졌다고 기록합니다. | 데이터 담당자: 정답 연결 키와 허용 클래스 규칙을 수정한 뒤 다시 검증합니다. |
| IQR 범위 밖의 관측 빈도 발견 | 값을 자동 삭제하지 않고 기록 ID와 원본 시간 범위를 확인합니다. | 데이터 담당자: 수집 특성인지 규칙 위반인지 확인합니다. |
| 클래스 구성의 치우침 확인 | 정확도만으로 다음 장의 모델을 판단하지 않습니다. | 검토 담당자: 정밀도, 재현율, FP와 FN을 함께 비교합니다. |
| 모든 검증 항목 성공 | 구조 검증 결과를 보고서에 남깁니다. | 검토 담당자: 2장에서 같은 데이터 분할의 모델 평가 결과를 확인합니다. |
실습 결과 정리¶
로컬 환경과 준비된 자료로는 평가 데이터의 범위와 구조 검증 결과까지만 기록할 수 있습니다. 아래 행은 로컬 환경에서 확인한 데이터 구조와 평가 범위를 정리합니다. 대상 환경의 요청 품질이나 특정 후보의 운영 환경 확인 상태를 뜻하지는 않습니다.
| 단계 | 확인한 사실 | 확인한 범위 | 아직 모르는 것 |
|---|---|---|---|
| 데이터 | 4,000행, 모델 입력에 사용하는 특성 133개, 교육용 target 554건, 역할별 건수 2,900/600/400/100, 원본 데이터 8/8과 가공 데이터 57/57 구조 검증 |
비교 기준 모델과 후보를 대조할 데이터 범위 | 실제 API 입력 상태, 품질 지표 변화의 원인, 대상 환경에서 실행 중인 모델 정보 |
GE 검증 성공은 어떤 후보를 배포해도 된다는 결론을 뒷받침하지 않습니다. GE 검증은 원본 데이터와 가공 데이터의 구조를 확인한 결과입니다. 모델 승인에는 2장의 공식 평가 자료가, 대상 환경 배포 상태에는 3~5장의 별도 확인 자료가 필요합니다.
보고서의 데이터 품질 근거는 확인한 구조와 아직 판단하지 않은 범위를 함께 남겨야 합니다. 아래 문장을 실제로 확인한 값으로 완성해 기록합니다.
데이터 품질 근거에 기록할 분할은 [분할 정보 경로]이며, [4,000/133/554] 구성과 원본 데이터 및 가공 데이터의 GE [직접 실행 결과/준비된 결과]를 확인했다. 이 결과는 [확인한 데이터 구조]를 보여 주지만, [품질 지표 변화의 원인 또는 대상 환경의 실행 상태]은 아직 판단하지 않는다.
완성한 문장은 작업본 artifacts/reports/release-decision-record.md의 데이터 품질 근거에 남겨 다음 모델 승인 판단의 적용 범위를 추적할 수 있게 합니다. 다음 장에서는 같은 데이터 범위에서 Candidate A와 Candidate B가 사전에 정한 보호 기준을 통과했는지 확인합니다.