5. 상세 목차¶
상세 목차는 실제 교안 문서의 제목과 레벨을 기준으로 정리합니다. 기존에 공지된 커리큘럼은 2일 운영 흐름을 보여주고, 이 문서는 그 흐름을 수강생이 읽게 될 장별 문서 구조로 다시 펼쳐서 보여줍니다.
5-1. 1장 AI 품질과 데이터 품질 기초¶
1장의 핵심은 모델 평가 전에 데이터가 평가 가능한 상태인지 확인하는 것입니다. AI 품질을 기존 SW 품질과 구분해서 이해하고, 데이터 품질 문제가 점수(score), 예측(prediction), 지표(metric) 해석에 어떻게 연결되는지 설명합니다.
1. AI 품질과 데이터 품질 기초
├── 1-1. AI 품질의 개요 [Core]
│ ├── 1-1-1. 기능 정상과 AI 품질 판단의 차이 [Core]
│ ├── 1-1-2. AI Software QA에서 확인 범위가 넓어지는 이유 [Core]
│ ├── 1-1-3. Software 1.0과 Software 2.0의 차이 [Core]
│ └── 1-1-4. 데이터, 모델, 운영 품질을 함께 확인하기 [Core]
├── 1-2. 데이터, 모델, 운영 품질의 연결 [Core]
│ ├── 1-2-1. 데이터 품질이 모델 판단에 미치는 영향 [Core]
│ ├── 1-2-2. 모델 점수와 임계값(threshold)의 역할 [Core]
│ ├── 1-2-3. 운영 환경 변화가 품질에 미치는 영향 [Core]
│ └── 1-2-4. AI QA의 기본 확인 흐름 [Core]
├── 1-3. 데이터 품질의 중요성 [Core]
│ ├── 1-3-1. 모델 평가 전 확인해야 할 데이터 조건 [Core]
│ ├── 1-3-2. 결측치와 이상치 [Core]
│ ├── 1-3-3. 라벨 오류와 라벨 표준화 [Core]
│ ├── 1-3-4. 클래스(class) 불균형과 분포 치우침 [Core]
│ └── 1-3-5. 데이터 오류가 지표 해석에 미치는 영향 [Core]
├── 1-4. Pandas 기반 데이터 품질 확인 실습 [Lab]
│ ├── 1-4-1. 데이터 분석 환경과 파일 불러오기 [Lab]
│ ├── 1-4-2. 필수 컬럼과 데이터 타입 확인 [Lab]
│ ├── 1-4-3. 결측치 확인 [Lab]
│ ├── 1-4-4. 이상치 탐지 [Lab]
│ ├── 1-4-5. 라벨 분포와 관심 클래스 표본 수(Positive support) 확인 [Lab]
│ └── 1-4-6. 데이터 통계 요약과 품질 리포트 생성 [Lab]
├── 1-5. 모델 평가 전 데이터 품질 결과 해석 [Core]
│ ├── 1-5-1. 데이터 품질 리포트를 읽는 관점 [Core]
│ ├── 1-5-2. 모델 평가 전 판단 표현 [Core]
│ ├── 1-5-3. 모델 입력에 쓰는 컬럼과 제외할 컬럼 구분 [Core]
│ └── 1-5-4. 모델 평가 전 판단 기록 [Core]
└── 1장 마무리: 데이터 품질을 QA 판단으로 바꾸기
1장의 완료 기준은 데이터 오류를 모델 평가 신뢰도와 연결해 설명하는 것입니다. 수강생은 결측치, 이상치, 라벨 오류, 클래스 불균형을 단순 데이터 오류가 아니라 모델 평가 신뢰도를 흔드는 요인으로 설명할 수 있어야 합니다.
5-2. 2장 데이터 검증과 모델 품질 평가¶
2장의 핵심은 정확도(Accuracy) 하나로 품질을 판단하지 않는 것입니다. 데이터 검증을 자동화하는 이유와 모델 평가 지표를 해석하는 방법을 다루며, 정밀도(Precision), 재현율(Recall), 혼동 행렬(Confusion Matrix), FP/FN, AUROC, PR-AUC를 함께 보는 관점을 설명합니다. 회귀 모델과 기타 모델 지표는 Mention 수준으로 다룹니다.
2. 데이터 검증과 모델 품질 평가
├── 2-1. 데이터 검증 자동화의 필요성 [Core]
│ ├── 2-1-1. 수동 확인과 자동 검증의 차이 [Core]
│ ├── 2-1-2. 검증 규칙(validation rule)의 의미 [Core]
│ ├── 2-1-3. 결측값, 범위, 라벨 검증 기준 [Core]
│ └── 2-1-4. 관심 클래스 표본 수와 평가 전 판단 기준 [Core]
├── 2-2. Great Expectations 기반 검증 리포트 확인 [Demo]
│ ├── 2-2-1. Great Expectations 개념 [Demo]
│ ├── 2-2-2. 기대 조건, 검증 결과, 검증 문서 이해 [Demo]
│ ├── 2-2-3. 데이터 검증 리포트 확인 [Demo]
│ └── 2-2-4. 검증 실패 결과의 QA 해석 [Demo]
├── 2-3. 모델 품질 지표 이해 [Core]
│ ├── 2-3-1. 모델 평가가 필요한 이유 [Core]
│ ├── 2-3-2. 분류 모델의 점수와 임계값 [Core]
│ ├── 2-3-3. 정확도와 클래스 불균형 [Core]
│ ├── 2-3-4. 정밀도, 재현율, F1-Score [Core]
│ ├── 2-3-5. 혼동 행렬과 FP/FN [Core]
│ ├── 2-3-6. AUROC와 PR-AUC [Core]
│ ├── 2-3-7. 보정과 점수 해석 주의 [Mention]
│ └── 2-3-8. 회귀 모델과 기타 모델 지표 개요 [Mention]
├── 2-4. scikit-learn 기반 모델 평가와 기록 실습 [Lab]
│ ├── 2-4-1. scikit-learn 기반 분류 모델 학습 [Lab]
│ ├── 2-4-2. 평가 데이터셋 기반 기준선(baseline) 평가 [Lab]
│ ├── 2-4-3. 기준 데이터셋과 품질 저하 데이터셋 비교 [Lab]
│ ├── 2-4-4. 임계값 변화에 따른 정밀도/재현율 비교 [Lab]
│ ├── 2-4-5. 혼동 행렬 표 해석 [Lab]
│ └── 2-4-6. 평가 조건과 지표 기록 [Lab]
├── 2-5. 데이터 품질과 성능 지표의 연결 [Lab]
│ ├── 2-5-1. 기준 데이터셋과 품질 저하 데이터셋 비교 [Lab]
│ ├── 2-5-2. 점수와 예측 분포 확인 [Lab]
│ ├── 2-5-3. 데이터 품질 신호와 원인 후보 연결 [Lab]
│ └── 2-5-4. QA 코멘트로 정리하기 [Lab]
├── 2-6. 평가 기록 기반 버전 비교 [Demo]
│ ├── 2-6-1. 평가 기록이 필요한 이유 [Core]
│ ├── 2-6-2. 기록 산출물과 MLflow 선택 확인 [Demo]
│ ├── 2-6-3. 평가 조건 비교 [Demo]
│ ├── 2-6-4. 지표와 오류 유형 비교 [Demo]
│ ├── 2-6-5. 산출물과 재현 가능성 확인 [Demo]
│ └── 2-6-6. 버전 비교와 품질 회귀 판단 [Core]
└── 2장 마무리: 지표를 QA 판단으로 바꾸기
2장의 완료 기준은 데이터 품질 저하를 여러 모델 지표로 해석하는 것입니다. 수강생은 데이터 품질 저하가 모델 지표에 어떤 형태로 나타나는지 보고, 단일 지표가 아니라 여러 지표를 함께 해석해야 하는 이유를 설명할 수 있어야 합니다.
5-3. 3장 AI 서비스와 모델 서빙 구조¶
3장의 핵심은 후보 모델이 MLflow 기록에서 Argo CD GitOps 배포와 KServe endpoint까지 추적 가능한지 확인하는 것입니다. 학습된 모델이 서비스로 제공될 때 어떤 실행 구조를 갖는지 확인하고, API 정상 응답뿐 아니라 MLflow alias, Argo CD sync 대상, KServe runtime, 모델 버전(model_version), 임계값, 점수, 예측이 일관되게 유지되는지를 살펴봅니다.
3. AI 서비스와 모델 서빙 구조
├── 3-1. 컨테이너 기본 개념 [Core]
│ ├── 3-1-1. 컨테이너가 필요한 이유 [Core]
│ ├── 3-1-2. 이미지(image)와 컨테이너(container)의 차이 [Core]
│ ├── 3-1-3. 컨테이너는 Linux kernel 기반 기술 [Core]
│ ├── 3-1-4. 컨테이너를 구성하는 hierarchy [Core]
│ ├── 3-1-5. Layered filesystem과 writable layer [Core]
│ ├── 3-1-6. Namespace 격리와 cgroup 제한 [Core]
│ ├── 3-1-7. 운영에서 확인할 컨테이너 증거 [Core]
│ ├── 3-1-8. 동일 실행 환경 재현 [Core]
│ └── 3-1-9. AI 서비스에서 컨테이너가 담는 것 [Core]
├── 3-2. Docker 기반 모델 컨테이너 실행 [Demo]
│ ├── 3-2-1. 제공된 Dockerfile 구조 확인 [Demo]
│ ├── 3-2-2. 모델 컨테이너 실행 흐름 [Demo]
│ ├── 3-2-3. 환경 변수와 설정값 확인 [Demo]
│ └── 3-2-4. 실행 상태 확인 [Demo]
├── 3-3. MLflow 배포 기록과 모델 버전 관리 [Demo]
│ ├── 3-3-1. 모델 registry와 alias 확인 [Demo]
│ ├── 3-3-2. 후보 모델 기록 확인 [Demo]
│ ├── 3-3-3. 지표와 threshold 비교 [Demo]
│ └── 3-3-4. 배포 판단에 남길 evidence [Demo]
├── 3-4. 모델 학습 loop와 candidate 갱신 [Core]
│ ├── 3-4-1. 데이터 검증에서 학습 loop로 이어지는 조건 [Core]
│ ├── 3-4-2. 기존 tree 기반 모델과 새 후보 모델 비교 [Core]
│ ├── 3-4-3. 성능 향상보다 release risk를 먼저 보는 이유 [Core]
│ └── 3-4-4. candidate 갱신 기준 [Core]
├── 3-5. ML Serving 구조와 runtime 선택 [Core]
│ ├── 3-5-1. API wrapper와 model server의 차이 [Core]
│ ├── 3-5-2. KServe ServingRuntime과 내부 엔진 [Core]
│ ├── 3-5-3. built-in runtime과 custom predictor 선택 [Core]
│ └── 3-5-4. endpoint contract와 transformer 필요성 [Core]
├── 3-6. Argo CD GitOps 배포 흐름 [Lab]
│ ├── 3-6-1. Argo CD Application 구조 확인 [Lab]
│ ├── 3-6-2. Kustomize overlay와 target revision 확인 [Lab]
│ ├── 3-6-3. KServe InferenceService 배포 파일 확인 [Lab]
│ └── 3-6-4. sync 전후 evidence 분리 [Lab]
├── 3-7. Kubernetes와 KServe 실행 구조 [Demo]
│ ├── 3-7-1. Linux node와 OS 개념 대응 [Core]
│ ├── 3-7-2. 상태 저장과 reconcile loop [Core]
│ ├── 3-7-3. Argo CD, Kubernetes, KServe 역할 분리 [Demo]
│ ├── 3-7-4. InferenceService에서 Pod까지 이어지는 경로 [Demo]
│ ├── 3-7-5. ServingRuntime과 내부 엔진 [Demo]
│ ├── 3-7-6. Built-in runtime의 한계 [Demo]
│ └── 3-7-7. 실행 확인 경로와 evidence 경계 [Demo]
├── 3-8. 모델 배포 흐름 확인 [Demo]
│ ├── 3-8-1. GitOps manifest render 확인 [Demo]
│ ├── 3-8-2. Argo CD sync와 health 확인 [Demo]
│ ├── 3-8-3. KServe readiness 확인 [Demo]
│ └── 3-8-4. 모델 버전과 임계값 설정 확인 [Demo]
├── 3-9. 요청/응답 계약과 운영 추적 [Core]
│ ├── 3-9-1. endpoint response contract [Core]
│ ├── 3-9-2. request_id와 model_version 추적 [Core]
│ ├── 3-9-3. validation failure와 latency 기록 [Core]
│ └── 3-9-4. 4장 observability로 넘길 evidence [Core]
└── 3장 마무리: GitOps serving 확인 결과를 배포 판단로 넘기기
3장의 완료 기준은 모델 서빙을 endpoint 호출 성공 여부만으로 판단하지 않는 것입니다. 수강생은 MLflow candidate, Argo CD 배포 파일, KServe cluster 상태, endpoint response contract가 같은 후보 모델을 가리키는지 확인해야 함을 이해해야 합니다.
5-4. 4장 운영 관측과 품질 신호¶
4장의 핵심은 운영 중 품질 변화를 로그와 메트릭으로 관측하는 것입니다. 로그, 메트릭, 대시보드는 장애 대응 도구이면서 동시에 점수 분포(score distribution)와 예측 분포(prediction distribution) 변화를 확인하는 품질 관측 도구입니다.
4. 운영 관측과 품질 신호
├── 4-1. 운영 품질의 위협 요인 [Core]
│ ├── 4-1-1. 입력 데이터 이상 [Core]
│ ├── 4-1-2. 모델 응답 지연 [Core]
│ ├── 4-1-3. API 오류와 검증 실패(validation failure) [Core]
│ ├── 4-1-4. 모델 버전 또는 임계값 설정 오류 [Core]
│ └── 4-1-5. 데이터 드리프트와 모델 드리프트 [Core]
├── 4-2. 로그, 메트릭, 트레이싱의 차이 [Core]
│ ├── 4-2-1. 로그(logging) 개념 [Core]
│ ├── 4-2-2. 메트릭(metrics) 개념 [Core]
│ ├── 4-2-3. 트레이싱(tracing) 개념 [Core]
│ └── 4-2-4. AI 서비스에서의 활용 사례 [Core]
├── 4-3. 구조화 로그와 request_id [Core]
│ ├── 4-3-1. 구조화 로그가 필요한 이유 [Core]
│ ├── 4-3-2. request_id, trace_id, model_version, score 기록 [Core]
│ ├── 4-3-3. 예측과 검증 실패 기록 [Core]
│ └── 4-3-4. 로그 기반 원인 추적 흐름 [Core]
├── 4-4. 로그와 지표 확인 도구 [Demo]
│ ├── 4-4-1. Loki에서 구조화 로그 조회 [Demo]
│ ├── 4-4-2. Prometheus 메트릭(metric) 확인 [Demo]
│ ├── 4-4-3. request_id로 추론 로그 추적 [Demo]
│ └── 4-4-4. 조회 실패 시 확인 포인트 [Demo]
├── 4-5. Grafana 대시보드 확인 [Demo]
│ ├── 4-5-1. 대시보드(dashboard) 구조 이해 [Demo]
│ ├── 4-5-2. 응답 속도와 에러율 시각화 [Demo]
│ ├── 4-5-3. 검증 실패 시각화 [Demo]
│ └── 4-5-4. 점수와 예측 분포 시각화 [Demo]
├── 4-6. 운영 품질 관측 실습 [Lab]
│ ├── 4-6-1. 정상 상태의 로그와 지표 확인 [Lab]
│ ├── 4-6-2. 요청 증가 상황 분석 [Lab]
│ ├── 4-6-3. 오류율(error rate)과 지연 시간(latency) 증가 분석 [Lab]
│ ├── 4-6-4. 검증 실패 증가 분석 [Lab]
│ └── 4-6-5. 추론 분포 변화 확인 [Lab]
└── 4장 마무리: 대시보드에서 보고서까지
4장의 완료 기준은 운영 지표와 모델 품질 신호를 함께 해석하는 것입니다. 수강생은 오류(error)와 지연 시간뿐 아니라 검증 실패, 점수 분포, 예측 분포를 함께 봐야 운영 중 품질 변화를 설명할 수 있음을 이해해야 합니다.
5-5. 5장 배포 판단과 되돌림 판단¶
5장의 핵심은 이상 징후를 배포 판단 기준으로 연결하는 것입니다. 앞에서 배운 데이터, 모델, GitOps 배포, KServe readiness, 운영 관측 정보를 하나의 품질 판단 흐름으로 묶고, candidate를 배포할지, 보류할지, 되돌림 조건을 붙일지 정리합니다. 최종 결론은 원인을 단정하는 문장이 아니라 현재 승인할 수 없는 근거, 보류로 생기는 비용, owner별 후속 확인, 같은 기준으로 재평가할 조건을 포함하는 배포 판단 의견입니다.
5. 배포 판단과 되돌림 판단
├── 5-1. 입력 데이터 분포 변화 확인 [Lab]
│ ├── 5-1-1. 입력 분포란 무엇인가 [Core]
│ ├── 5-1-2. Histogram 기반 분포 확인 [Lab]
│ ├── 5-1-3. 평균값 변화 탐지 [Lab]
│ └── 5-1-4. 입력 이상 징후 해석 [Lab]
├── 5-2. Score와 Prediction Distribution 분석 [Lab]
│ ├── 5-2-1. Score Distribution 이해 [Core]
│ ├── 5-2-2. Prediction Distribution 이해 [Core]
│ ├── 5-2-3. 특정 class 예측 급증 분석 [Lab]
│ └── 5-2-4. 임계값 기준 FP/FN 변화 해석 [Lab]
├── 5-3. 운영 이상 징후 탐지와 원인 추적 [Lab]
│ ├── 5-3-1. 정상 상태와 이상 상태 비교 [Lab]
│ ├── 5-3-2. 데이터 품질 문제와 지표 변화 연결 [Lab]
│ ├── 5-3-3. 로그 기반 원인 후보 좁히기 [Lab]
│ └── 5-3-4. 품질 이상 원인 후보 정리 [Lab]
├── 5-4. AI 품질 회귀 테스트 전략 [Core]
│ ├── 5-4-1. 품질 회귀란 무엇인가 [Core]
│ ├── 5-4-2. 데이터셋, 특성, 라벨(label) 변경 영향 분석 [Core]
│ ├── 5-4-3. 모델 버전과 임계값 변경 검증 [Core]
│ └── 5-4-4. 지표 기준과 승인 조건 정의 [Core]
├── 5-5. 테스트 데이터 설계 전략 [Core]
│ ├── 5-5-1. 정상 입력과 대표 케이스 선정 [Core]
│ ├── 5-5-2. 결측, 이상, 타입 오류 입력 설계 [Core]
│ ├── 5-5-3. 경계값과 임계값 근처 케이스 설계 [Core]
│ └── 5-5-4. class 불균형 평가 데이터 구성 [Core]
├── 5-6. 배포 승인, 보류, 되돌림 기준 [Core]
│ ├── 5-6-1. metric gate와 배포/보류 판단 [Core]
│ ├── 5-6-2. Argo CD sync gate [Core]
│ ├── 5-6-3. KServe와 endpoint gate [Core]
│ └── 5-6-4. 되돌림 trigger와 재평가 조건 [Core]
├── 5-7. 실제 장애 사례 분석 [Mention]
│ ├── 5-7-1. 데이터 품질 장애 사례 [Mention]
│ ├── 5-7-2. Drift 기반 장애 사례 [Mention]
│ ├── 5-7-3. 모델 버전 또는 임계값 설정 오류 사례 [Mention]
│ └── 5-7-4. 운영 장애 사례 [Mention]
├── 5-8. 최종 확인 결과 정리 [Lab]
│ ├── 5-8-1. 데이터 품질 체크리스트 [Lab]
│ ├── 5-8-2. 모델 품질 체크리스트 [Lab]
│ ├── 5-8-3. 임계값과 설정값 체크리스트 [Lab]
│ ├── 5-8-4. 운영 품질 체크리스트 [Lab]
│ ├── 5-8-5. Observability 체크리스트 [Lab]
│ ├── 5-8-6. 이상 징후 발견 시 보고 항목 [Lab]
│ └── 5-8-7. 최종 확인 결과 완성 [Lab]
└── 5장 마무리: Release note 완성
5장의 완료 기준은 데이터, 모델, GitOps 배포, KServe endpoint, 운영 정보를 하나의 배포 판단 기준으로 연결하는 것입니다. 수강생은 데이터 품질, 모델 지표, 임계값, API 계약, 로그와 대시보드, 실제 확인 결과 gap을 함께 보고 배포, 보류, 되돌림 조건을 설명할 수 있어야 합니다.
5-5-1. 2일 안에 완성해야 할 산출물 기준¶
2일 과정의 기준은 모든 문서를 외우는 것이 아니라 현재 품질 신호를 방어 가능한 보고서 문장으로 바꾸는 것입니다. 수강생은 각 장이 끝날 때마다 확인한 근거, 약해진 원인 후보, 남은 리스크, 다음 확인 owner를 한 줄로 남겨야 합니다.
각 장은 최종 배포 판단에 필요한 증거를 하나씩 더합니다. 1장은 기준 데이터가 평가 가능한지 확인하고, 2장은 지표를 믿을 조건과 MLflow 기록을 검토하며, 3장은 Argo CD와 KServe 배포 근거를 확인합니다. 4장은 운영 로그와 메트릭으로 이상 신호를 관측하고, 5장은 배포, 보류, 되돌림 중 어떤 판단이 방어 가능한지 정리합니다.
2일 뒤 산출물은 다음 기준을 만족해야 합니다.
| 산출물 기준 | 수강생이 남길 내용 | 완료 판단 |
|---|---|---|
| 장별 evidence row | 확인한 파일, 관측값, 가능한 판단, 금지할 결론 | 실행 결과가 보고서 문장으로 연결됨 |
| Lab과 Demo 확인 기록 | 직접 실행, prepared artifact 확인, JupyterLite sample 확인 구분 | 증거의 범위를 과장하지 않음 |
| 원인 후보 상태 | 강화된 후보, 약화된 후보, 아직 남은 후보와 이유 | 단정이 아니라 후보 좁히기로 설명됨 |
| 배포 판단 의견 | 승인, 조건부 보류, 추가 확인 중 하나와 근거 | 승인/보류 리스크, owner, next action이 포함됨 |
| 재평가 조건 | 어떤 증거가 확인되면 같은 기준으로 다시 판단할지 | 다음 회의에서 같은 기준으로 재검토 가능 |
이 기준은 강의 운영표가 아니라 수강생이 2일 후 제출할 보고서의 최소 구조입니다. 도구 실행 자체가 목표가 아니며, 각 출력이 어떤 판단을 허용하고 어떤 결론을 아직 금지하는지 설명할 수 있어야 합니다.
5-6. Appendix 최신 AI 시스템 품질 검증 확장 주제¶
Appendix는 본문에서 배운 품질 관점을 LLM, Agent, Online Evaluation, Multi-class, Ranking, Vision AI 같은 주제로 확장하기 위한 별도 자료입니다. 공개 사이트에서는 본문 1장부터 5장까지의 완성된 흐름을 먼저 제공하고, Appendix는 실습 경로와 판단 기준을 보강한 뒤 별도로 공개합니다.