콘텐츠로 이동

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장의 핵심은 학습과 서빙 사이의 일치성을 확인하는 것입니다. 학습된 모델이 서비스로 제공될 때 어떤 실행 구조를 갖는지 확인하고, API 정상 응답뿐 아니라 입력 스키마(schema), 모델 버전(model_version), 임계값, 점수, 예측이 일관되게 유지되는지를 살펴봅니다.

3. AI 서비스와 모델 서빙 구조
├── 3-1. 컨테이너 기본 개념 [Core]
│   ├── 3-1-1. 컨테이너가 필요한 이유 [Core]
│   ├── 3-1-2. 이미지(image)와 컨테이너(container)의 차이 [Core]
│   ├── 3-1-3. 동일 실행 환경 재현 [Core]
│   └── 3-1-4. AI 서비스에서 컨테이너가 담는 것 [Core]
├── 3-2. 모델 서빙 구조와 실행 단위 [Core]
│   ├── 3-2-1. 모델 파일과 실행 환경의 분리 [Core]
│   ├── 3-2-2. 예측 API, 모델 로더, 전처리 코드의 역할 [Core]
│   ├── 3-2-3. 점수, 임계값, 예측 생성 위치 [Core]
│   └── 3-2-4. 설정값과 모델 버전의 위치 [Core]
├── 3-3. FastAPI 기반 예측 API 확인 [Lab]
│   ├── 3-3-1. 예측 API의 역할 [Core]
│   ├── 3-3-2. 입력 스키마와 API 계약(contract) [Lab]
│   ├── 3-3-3. 제공 코드 확인과 API 호출 [Lab]
│   ├── 3-3-4. OpenAPI 문서 확인 [Lab]
│   └── 3-3-5. 오류 응답 구조 확인 [Lab]
├── 3-4. 요청과 응답 흐름 이해 [Core]
│   ├── 3-4-1. 클라이언트(client)와 서버(server) 구조 [Core]
│   ├── 3-4-2. 요청(request)과 응답(response) 이해 [Core]
│   ├── 3-4-3. JSON 기반 데이터 전달 [Core]
│   └── 3-4-4. request_id 기반 추적 흐름 [Core]
├── 3-5. Docker 기반 모델 컨테이너 실행 [Demo]
│   ├── 3-5-1. 제공된 Dockerfile 구조 확인 [Demo]
│   ├── 3-5-2. 모델 컨테이너 실행 흐름 [Demo]
│   ├── 3-5-3. 환경 변수와 설정값 확인 [Demo]
│   └── 3-5-4. 실행 상태 확인 [Demo]
├── 3-6. Train-Serving Skew와 서빙 일치성 검증 [Core]
│   ├── 3-6-1. Train-Serving Skew의 의미 [Core]
│   ├── 3-6-2. 특성(feature) 목록과 입력 스키마 일치 확인 [Core]
│   ├── 3-6-3. 전처리 방식과 파생 특성 일치 확인 [Core]
│   └── 3-6-4. 라벨 기준과 임계값 설정 일치 확인 [Core]
├── 3-7. Kubernetes 실행 구조 이해 [Mention]
│   ├── 3-7-1. Kubernetes가 필요한 이유 [Mention]
│   ├── 3-7-2. Pod와 Deployment 역할 [Mention]
│   ├── 3-7-3. 제공된 매니페스트(manifest) 구조 확인 [Mention]
│   └── 3-7-4. 운영 환경과 실습 환경의 차이 [Mention]
├── 3-8. 모델 배포 흐름 확인 [Demo]
│   ├── 3-8-1. Docker 기반 모델 컨테이너 실행 [Demo]
│   ├── 3-8-2. 제공된 매니페스트 기반 배포 흐름 확인 [Demo]
│   ├── 3-8-3. 배포 후 API 응답 확인 [Demo]
│   └── 3-8-4. 모델 버전과 임계값 설정 확인 [Demo]
└── 3장 마무리: 서빙 구조를 QA 체크로 바꾸기

3장의 완료 기준은 모델 서빙을 API 호출 성공 여부만으로 판단하지 않는 것입니다. 수강생은 학습과 서빙 사이의 특성, 전처리, 라벨 기준, 임계값 일치성까지 확인해야 함을 이해해야 합니다.

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장 Drift와 이상 감지, AI QA 전략

5장의 핵심은 이상 징후를 배포 판단 기준으로 연결하는 것입니다. 앞에서 배운 데이터, 모델, 운영 관측 정보를 하나의 품질 판단 흐름으로 묶고, 이상 징후를 발견했을 때 원인 후보를 좁히는 체크리스트를 정리합니다. 최종 결론은 원인을 단정하는 문장이 아니라 현재 승인할 수 없는 근거, 보류로 생기는 비용, owner별 후속 확인, 같은 기준으로 재평가할 조건을 포함하는 release gate 의견입니다.

5. Drift와 이상 감지, AI QA 전략
├── 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. 지표 기준과 배포 가능/보류 판단 [Core]
│   ├── 5-6-2. API 계약과 설정값 확인 [Core]
│   ├── 5-6-3. 로그와 대시보드 기반 운영 준비 확인 [Core]
│   └── 5-6-4. 배포 전후 품질 비교 기준 [Core]
├── 5-7. 실제 장애 사례 분석 [Mention]
│   ├── 5-7-1. 데이터 품질 장애 사례 [Mention]
│   ├── 5-7-2. Drift 기반 장애 사례 [Mention]
│   ├── 5-7-3. 모델 버전 또는 임계값 설정 오류 사례 [Mention]
│   └── 5-7-4. 운영 장애 사례 [Mention]
├── 5-8. AI QA 체크리스트 정리 [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. AI QA 전체 흐름 정리 [Lab]
└── 5장 마무리: 최종 산출물의 형태

5장의 완료 기준은 데이터, 모델, 운영 정보를 하나의 배포 판단 기준으로 연결하는 것입니다. 수강생은 데이터 품질, 모델 지표, 임계값, API 계약, 로그와 대시보드를 함께 보고 배포 승인, 조건부 보류, 추가 확인 기준을 설명할 수 있어야 합니다.

5-5-1. 2일 강의 운영과 판매 패키징 기준

유료 강의로 운영할 때는 상세 목차만으로 충분하지 않고, 수강생이 제한된 시간 안에 보고서 판단까지 도달하도록 진행 기준을 분리해야 합니다. 본 교안은 문서만 읽어도 따라갈 수 있는 상세 교재로 작성되어 있으므로, 강의 현장에서는 모든 문단을 순서대로 낭독하기보다 필수 판단 흐름, Lab 실행, prepared artifact 확인, 최종 보고서 작성 시간을 분리해 운영합니다.

강사는 각 장을 시작할 때 이번 장이 최종 release gate 판단에 어떤 증거를 더하는지 먼저 설명해야 합니다. 예를 들어 1장은 기준 데이터가 평가 가능한지 확인하고, 2장은 지표를 믿을 조건을 검토하며, 3장은 서빙 응답의 계약과 설정값을 확인합니다. 4장은 운영 로그와 메트릭으로 이상 신호를 관측하고, 5장은 승인, 조건부 보류, 추가 확인 중 어떤 판단이 방어 가능한지 정리합니다.

유료 과정 운영에 필요한 패키지는 다음 기준으로 준비합니다.

구성 요소 강의 운영에서의 역할 준비 상태 확인 기준
필수 진행 경로 2일 안에 반드시 다룰 Core, Lab, Demo 흐름 각 장의 완료 기준과 최종 보고서 문장이 연결됨
선택 확인 경로 시간이 남을 때 직접 실행할 Demo 또는 Appendix 실행하지 않아도 prepared artifact로 같은 판단 가능
강사용 체크포인트 장별 질문, 흔한 오해, 다음 장으로 넘길 원인 후보 수강생이 과잉 단정하지 않고 후보 상태를 말함
수강생 산출물 장별 evidence row와 최종 release gate 의견 근거 파일, 관측값, owner, next action이 포함됨
평가 루브릭 보고서가 승인 가능한지 확인하는 기준 숫자 정합성, 제한 사항, 승인/보류 리스크를 구분함

이 기준을 적용하면 본 교안은 단순한 읽기 자료가 아니라 현장 보고서 작성 훈련으로 판매할 수 있습니다. 다만 강의 상품으로 배포할 때는 각 Lab의 실행 환경 점검표, prepared artifact 사용 조건, 예시 Learner Evidence Packet, 예시 reviewer 피드백을 함께 제공해야 수강생이 “도구를 실행했다”에서 멈추지 않고 “근거 있는 보류 판단을 보고했다”까지 도달할 수 있습니다.

5-6. Appendix 최신 AI 시스템 품질 검증 확장 주제

Appendix는 본문에서 배운 품질 관점을 LLM, Agent, Online Evaluation, Multi-class, Ranking, Vision AI 같은 주제로 확장하기 위한 별도 자료입니다. 공개 사이트에서는 본문 1장부터 5장까지의 완성된 흐름을 먼저 제공하고, Appendix는 실습 경로와 판단 기준을 보강한 뒤 별도로 공개합니다.