MLOps로 배우는 데이터와 모델 품질관리¶
AI 서비스 품질을 데이터, 모델, 운영 관점에서 함께 판단하는 2일 과정입니다. 이 사이트는 AI 품질 관리와 운영 관측 기초를 강의 교안, 실습 흐름, 품질 판단 기준으로 정리합니다.
수강생은 생체신호 기반 위험 알림 AI 서비스의 품질/운영 담당자 역할로 학습합니다. 기준 데이터에서 시작해 현재 운영 입력 샘플의 검증 실패, 운영 입력 변화를 재현한 품질 저하 평가 데이터셋, 모델 평가 결과, API 응답, 운영 로그, 입력 구성 변화 리포트, 배포 승인 보고서를 차례로 확인합니다.
과정 전체의 반복 사건은 기능 장애가 아니라 품질 신호 변화입니다. 운영 로그에서 high_risk 비율이 크게 증가했을 때, 이 변화를 모델 문제로 단정하지 않고 실제 증거를 연결해 배포 승인, 보류, 추가 확인 판단을 설명하는 것이 최종 목표입니다.
| 항목 | 내용 |
|---|---|
| 대상 | AI 서비스 품질/운영에 관심 있는 실무자, QA 담당자 |
| 역할 | 생체신호 기반 위험 알림 AI 서비스의 품질/운영 담당자 |
| 기간 | 2일 과정 |
| 방식 | 이론 설명 + 제공 코드 기반 실습 + 운영 화면 확인 |
| 핵심 관점 | 데이터 품질, 모델 품질, 운영 품질의 연결 |
| 최종 산출물 | 배포 승인, 보류, 추가 확인 기준과 AI QA 체크리스트 |
실습 코드는 seungbaeji/tta-aiqa 저장소에서 제공합니다. 수강생은 교재의 Lab 안내를 읽은 뒤 해당 저장소의 notebook과 실행 코드를 사용해 데이터 품질 확인, 모델 평가, API 응답 확인, 운영 증거 해석 흐름을 따라갑니다. 교재에 나오는 labs/, demos/, packages/ai-quality, compose.yaml 경로는 별도 표기가 없으면 tta-aiqa 루트 기준입니다.
1. 과정에서 확인하는 것¶
이 과정의 핵심은 모델 성능 숫자만 보는 것이 아니라 실제 품질 신호를 설명할 수 있는 근거를 연결하는 것입니다. 같은 사건을 데이터 품질 리포트, 모델 지표, API 응답, 로그, 대시보드, 체크리스트로 바꾸어 보면서 원인 후보를 좁힙니다.
| 확인 관점 | 이 과정에서 확인하는 증거 | 판단 질문 |
|---|---|---|
| 데이터 품질 | 기준 데이터의 라벨, 결측치, 범위 조건 | 모델 평가를 시작할 수 있는 데이터인가 |
| 모델 품질 | 현재 운영 입력 변화를 재현한 품질 저하 평가 데이터셋의 검증 실패와 지표 변화 | 데이터 품질 저하가 지표 변화와 연결되는가 |
| 서빙 품질 | /predict 응답의 request_id, model_version, score, threshold, prediction |
평가 기준이 API 응답에서도 추적되는가 |
| 운영 관측 | 오류, 지연 시간, 점수 분포, 예측 분포 변화 | 운영 품질 신호가 같은 사건을 가리키는가 |
| 배포 판단 | 입력 구성 변화 리포트와 승인 기준 | 배포 승인보다 보류와 추가 확인이 적절한가 |
학습 흐름은 실제 관측값 → 원인 후보 → 실습/데모 출력 → QA 판단 순서로 진행합니다.
2. 2일 학습 흐름¶
1일차는 데이터와 모델 평가의 기초를 잡고, 2일차는 서빙, 운영 관측, 이상 감지와 배포 판단으로 확장합니다. 각 장은 단독으로 읽을 수 있지만, 전체 흐름은 데이터 품질 확인에서 운영 품질 판단으로 이어집니다.
용어는 각 본문에서 처음 등장할 때 간략히 설명합니다. 읽는 중에 다시 확인이 필요하면 상단 탭의 주요 용어를 사용합니다.
| 구분 | 문서 | 주요 내용 |
|---|---|---|
| 과정 안내 | 상세 과정 안내 | 과정 목표, 시간표, 실습 데이터셋, 전체 목차 |
| Day 1 | 데이터 품질 | 데이터가 평가 가능한 상태인지 확인 |
| Day 1 | 모델 품질 평가 | 모델 지표와 threshold 해석 |
| Day 2 | 모델 서빙 | API, 컨테이너, 서빙 일치성 확인 |
| Day 2 | 운영 관측 | 로그, 메트릭, 대시보드 기반 운영 관측 |
| Day 2 | 운영 이상 신호와 AI 품질 판단 | 이상 신호, 입력 구성 변화, 배포 판단 기준 |
설치 없이 notebook을 열어 핵심 증거를 확인해야 한다면 JupyterLite notebook 목차에서 바로 시작합니다. 각 notebook의 역할과 브라우저 실습의 제한 사항은 브라우저 실습 환경에 정리되어 있습니다. 브라우저 실습은 전체 산출물 재생성 경로가 아니라, 준비된 artifact와 소형 샘플로 QA 판단 흐름을 확인하는 경로입니다. 로컬에서 직접 실행해야 하는 명령은 교재 저장소와 실습 코드 저장소 구분을 먼저 확인한 뒤 tta-aiqa에서 실행합니다.
3. 전체 품질 판단 흐름¶
품질 판단은 기준 데이터에서 시작해 운영 관측과 배포 보류 판단으로 확장됩니다. 모델이 한 번 잘 동작했는지가 아니라, 데이터와 운영 환경이 바뀌어도 품질을 설명하고 추적할 수 있는지가 중요합니다.
기준 데이터 품질 확인
→ 현재 운영 입력 샘플의 검증 실패 확인
→ 품질 저하 평가 데이터셋으로 모델 지표 변화 해석
→ API 추적 정보 확인: model_version, threshold, score, prediction
→ 운영 신호 비교
→ 입력 구성 변화와 승인 기준 확인
→ 배포 판단 정리
4. 실습에서 확인하는 산출물¶
실습은 모델 성능을 높이는 것보다 품질 상태를 확인하고 해석하는 데 초점을 둡니다. 각 산출물은 운영 중 품질 문제를 설명하기 위한 근거로 사용합니다. 수강생은 먼저 아래 경로의 prepared artifact를 열어 실제 관측값을 보고서 문장으로 바꾸고, 전체 산출물을 직접 다시 만들 필요가 있을 때만 tta-aiqa에서 원본 CSV를 준비해 make labs를 실행합니다.
이 교재에서 리포트는 도구나 분석 코드가 만든 근거 산출물을 가리키고, 보고서는 사람이 근거를 해석해 승인, 보류, 추가 확인 판단으로 정리한 문서를 가리킵니다. 파일명이 drift_report.md처럼 남아 있어도 수강생이 보고서에 쓸 때는 “입력 구성 변화 리포트에서 확인한 값”처럼 역할이 드러나게 표현합니다.
make labs와 각 장의 생성 스크립트는 tta-aiqa의 data/ 또는 artifacts/ 산출물을 다시 만들 수 있습니다. 이 재생성 경로에는 data/human_vital_signs_dataset_2024.csv 원본 CSV가 필요합니다. 이미 준비된 산출물이 있는 환경에서는 먼저 아래 경로의 파일을 열어 관측값을 확인하고, 보고서에는 “해당 artifact에서 확인한 값”이라고 적습니다. 산출물을 직접 재생성하지 않았다면 “직접 생성했다”고 쓰지 않고, 재생성이 필요한 경우에만 각 장의 Lab 안내를 따라 tta-aiqa에서 실행합니다. 로그 파일은 반복 실행이나 streaming Demo로 누적될 수 있으므로, 숫자를 인용하기 전에 해당 파일이 보고서용 120건 샘플인지, 실행 중 생성한 임시 로그인지, dashboard streaming 로그인지 먼저 구분합니다.
JupyterLite 출력값은 브라우저 실습용 소형 샘플 또는 prepared evidence 확인값입니다. 최종 보고서에서 전체 과정 기준값을 인용할 때는 artifacts/reports/와 artifacts/experiments/의 prepared artifact를 기준으로 삼고, Lite에서 확인한 값은 “JupyterLite sample 기준 확인값”이라고 따로 표시합니다.
| 산출물 | 실행 또는 확인 경로 | 보고서에 옮길 필드 |
|---|---|---|
| 데이터 품질 리포트 | artifacts/reports/chapter_01_quality_report.md |
행 수, 필수 컬럼 누락 여부, high_risk/low_risk 분포, 평가 가능 여부 |
| 모델 평가 결과 | artifacts/experiments/chapter_02/model_test_eval.json |
test 데이터셋, 모델 버전, threshold, Precision, Recall, FP, FN, PR-AUC |
| 모델 품질 비교 리포트 | artifacts/experiments/chapter_02/validation_degradation_comparison.json와 artifacts/reports/chapter_02_model_quality_comparison.md |
validation 기준/품질 저하 데이터셋 Precision, PR-AUC, FP/FN 변화, score/prediction distribution, 남은 제한 사항 |
| Serving evidence | labs/ch03_serving/fastapi_serving_lab.ipynb, labs/ch03_serving/check_serving_contract.py, demos/ch03_docker_kubernetes/Dockerfile, compose.yaml |
FastAPI 요청/응답 계약, 컨테이너 실행 파일, MLflow service, endpoint contract 필드 |
| GitOps/KServe evidence | demos/ch03_docker_kubernetes/argocd/, demos/ch03_docker_kubernetes/gitops/, setup_argocd_gitops.sh, check_kserve_endpoint.sh |
GitHub Deploy key, Argo CD repository credential, Argo CD Application, KServe InferenceService, sync/health 확인. live cluster가 없으면 endpoint는 미검증으로 기록 |
| 후보 모델 endpoint 로그 | artifacts/logs/prediction_events.jsonl 또는 live endpoint smoke 결과 |
request_id, model_version, score, threshold, prediction, latency, validation_failure 필드 존재. 같은 request_id가 반복될 수 있으므로 특정 score 값을 최종 보고서 숫자로 옮기지 않음 |
| 로그와 메트릭 | uv run --group lab python labs/ch04_observability/build_observability_artifacts.py 실행 후 artifacts/logs/chapter_04_anomaly_events.jsonl, artifacts/metrics/chapter_04_anomaly.prom, artifacts/grafana/ai_quality_overview_dashboard.json, artifacts/grafana/ai_quality_details_dashboard.json 확인 |
보고서용 120건 샘플 기준 오류율, 평균 지연 시간, 검증 실패 수, 점수 분포, 예측 분포, 대표 trace. Grafana streaming Demo를 실행한 뒤에는 로그 파일의 요청 수가 달라질 수 있으므로 메트릭 파일과 행 수를 먼저 대조 |
| 최종 QA 판단 묶음 | artifacts/reports/release_approval.md, artifacts/reports/quality_issue_trace.md, artifacts/reports/ai_qa_checklist.md |
승인 여부, 실패 기준, 원인 후보, owner, audit reference, live_deployment=unverified, 재평가 조건 |
이 표는 실습 실행 목록이 아니라 보고서 작성 목록입니다. 각 장을 마칠 때 수강생은 경로에 있는 산출물에서 숫자와 필드를 확인하되, append 로그나 streaming 로그처럼 실행 이력이 섞일 수 있는 파일은 숫자 근거로 바로 쓰지 않습니다. 보고서에는 “어떤 원인 후보가 약해졌는가”, “어떤 후보가 남았는가”, “승인과 보류 중 무엇을 권고하는가”를 한 줄씩 남기고, 숫자는 어떤 artifact 기준인지 함께 적습니다.
5. 다음 단계¶
전체 일정과 상세 목차가 필요하면 상세 과정 안내를 확인합니다. 바로 학습을 시작한다면 데이터 품질부터 읽으면 됩니다.