1. 과정 한눈에 보기¶
1-1. AI 품질 판단의 핵심 문제¶
품질 판단의 출발점은 API 정상 응답과 운영 품질 신호를 구분하는 것입니다. AI 서비스 품질/운영에 관심 있는 실무자와 QA 담당자는 데이터 조건, 모델 지표(metric), API 응답, 로그, 대시보드를 연결해 배포 승인, 조건부 보류, 추가 확인 기준을 설명하는 관점을 학습합니다.
수강생은 생체신호 기반 위험 알림 AI 서비스의 품질/운영 담당자 역할로 과정을 따라갑니다. 기준 모델은 평가 기록을 남겼고, 2일차에는 새 후보 모델을 MLflow에서 확인한 뒤 Argo CD와 KServe로 배포할 수 있는지 봅니다. 운영 로그에서 high_risk 비율이 크게 증가한 상태이므로, 이 변화를 모델 문제로 단정하지 않고 실제 확인 결과를 모아 릴리스 회의에서 배포, 보류, 되돌림 중 무엇을 제안할지 판단합니다.
반복해서 다룰 사건은 공통 운영 시나리오의 후보 모델 배포 판단입니다. 기준 데이터와 기준 모델 평가는 1~2장에서 확인하고, 3~5장에서는 후보 모델이 Argo CD/KServe 배포 경로와 운영 관측 기준을 만족하는지 확인합니다.
확인해야 할 신호는 한곳에 모여 있지 않습니다. 데이터 검증 실패는 Great Expectations 리포트에 있고, 모델 지표 변화는 평가 결과에 있으며, API 응답과 운영 로그에는 모델 버전(model_version), 임계값(threshold), 요청 ID(request_id)가 남아야 합니다.
품질 판단은 개별 신호를 모으는 데서 끝나지 않습니다. high_risk 예측 증가는 하나의 관측값일 뿐이고, 이 값이 데이터 변화, 모델 지표 변화, 설정 변경, 운영 입력 변화 중 무엇과 연결되는지 확인해야 합니다.
각 장은 같은 판단 사건을 서로 다른 증거로 나누어 확인합니다. 다음 표는 과정 전체에서 어떤 증거를 모아 최종 판단으로 연결하는지 보여줍니다.
| 장 | 확인하는 증거 | 판단으로 연결되는 질문 |
|---|---|---|
| 1장 데이터 품질 | 기준 데이터의 라벨, 결측치, 범위 조건 | 현재 데이터로 모델 평가를 시작해도 되는가 |
| 2장 모델 품질 평가 | 검증 실패, 모델 지표, FP/FN, PR-AUC(AUPRC) | 모델 지표 변화가 데이터 조건 변화와 연결되는가 |
| 3장 모델 서빙 | MLflow candidate, Argo CD Application, KServe InferenceService, endpoint contract | 후보 모델이 추적 가능한 배포 경로로 올라갈 수 있는가 |
| 4장 운영 관측 | 로그, 메트릭, 검증 실패, 점수/예측 분포, KServe 상태 | 후보 모델 endpoint가 운영 기준선과 다른 신호를 보이는가 |
| 5장 배포 판단 | 입력 구성 변화, 모델 지표, live sync, endpoint smoke, 되돌림 조건 | 배포, 보류, 되돌림 중 무엇이 타당한가 |
이 표의 기준은 장별 주제를 분리해서 외우기 위한 것이 아닙니다. 데이터, 모델, 서빙, 운영 관측, 승인 기준이 하나의 품질 판단으로 이어진다는 점을 먼저 잡기 위한 기준입니다.
1-2. 대상과 진행 방식¶
주요 대상은 AI 서비스 품질을 확인하거나 운영 품질을 이해해야 하는 실무자입니다. 수강생은 AI 모델 개발자나 MLOps 엔지니어가 아니어도 학습 흐름을 따라올 수 있습니다. 다만 AI 서비스 품질을 확인하려면 데이터, 모델 평가, API, 운영 관측이 서로 어떻게 연결되는지 이해해야 하므로, 각 도구는 “사용법”보다 “품질 판단에 필요한 정보”를 중심으로 다룹니다.
| 항목 | 내용 |
|---|---|
| 대상 | AI 서비스 품질/운영에 관심 있는 실무자, QA 담당자 |
| 기간 | 2일 과정 |
| 방식 | 이론 설명 + 제공된 코드 기반 실습 + 운영 화면 확인 |
| 핵심 관점 | 데이터 품질, 모델 품질, 운영 품질의 연결 |
| 실습 방향 | 직접 구현보다 품질 확인과 이상 징후 해석에 초점 |
| 역할 | 생체신호 기반 위험 알림 AI 서비스의 품질/운영 담당자 |
| 최종 산출물 | 후보 모델 배포, 보류, 되돌림 기준과 체크리스트 |
학습 방향은 모델 성능 개선보다 품질 확인과 이상 징후 해석에 초점을 둡니다. AI 모델을 직접 고도화하는 교육이 아니라, AI 시스템에서 어떤 품질 문제가 발생할 수 있는지 이해하고, 문제가 발생했을 때 데이터, 모델, API, 로그, 대시보드 중 어디를 확인해야 하는지 판단할 수 있도록 구성합니다.
각 장은 관측값 → 확인 증거 → 원인 후보 → 실습/데모 출력 → 판단 산출물 순서로 읽습니다. 이 구조는 개념을 먼저 설명한 뒤 조작 가능한 실습으로 확인하는 방식과, 하나의 ML 시스템을 데이터 관리, 테스트, 배포, 모니터링까지 이어서 다루는 방식의 장점을 가져온 것입니다.
1-3. 학습 목표¶
수강생은 교육 후 배포/운영 판단 사건을 장별 근거로 나누어 설명할 수 있어야 합니다. 이를 위해 필요한 학습 목표는 데이터 확인, 모델 평가, 서빙 추적, 운영 관측, 최종 판단으로 나누어 정리합니다.
| 학습 목표 | 확인할 근거 | 설명할 수 있어야 하는 판단 |
|---|---|---|
| AI 품질 이해 | 코드, 데이터, 모델, 운영 환경 | 기존 SW 품질과 AI 품질의 확인 범위 차이 |
| 데이터 품질 확인 | 결측치, 이상치, 라벨 오류, 클래스 분포 | 현재 데이터가 모델 평가에 적합한지 여부 |
| 모델 평가 해석 | Accuracy, Precision, Recall, F1-Score, Confusion Matrix, AUROC, PR-AUC | 단일 지표가 아니라 오류 유형과 함께 보는 이유 |
| 임계값 이해 | 점수, 임계값, 예측 | 모델 점수가 최종 예측으로 바뀌는 기준 |
| 실험 관리 이해 | 데이터셋 버전, 모델 버전, threshold, 평가 지표 | 평가 조건과 결과를 함께 남겨야 하는 이유 |
| AI 서비스 구조 이해 | Batch/Realtime 추론, Docker, MLflow, Argo CD, KServe | 학습 결과가 운영 서비스로 제공되는 구조 |
| 운영 품질 관측 | 로그, 메트릭, 대시보드, 검증 실패 | 오류, 지연, 분포 변화가 품질 신호가 되는 이유 |
| 이상 징후 분석 | 드리프트(drift), score 분포, prediction 분포 | 배포 승인, 보류, 추가 확인 기준으로 정리하는 방법 |
도구는 품질 판단에 필요한 정보를 확인하기 위한 수단으로 다룹니다. Kubernetes, Prometheus, Loki, Grafana, MLflow 같은 도구는 과정 중에 등장하지만, 도구 자체를 깊게 운영하는 것이 목적은 아닙니다. 품질 관점에서 어떤 정보를 확인해야 하는지, 그리고 그 정보가 품질 판단에 어떻게 연결되는지를 중심으로 다룹니다.
1-4. 핵심 메시지¶
핵심 메시지는 AI 품질을 데이터, 모델, 운영이 연결된 문제로 보는 것입니다. 각 장의 실습 결과는 다음 다섯 가지 메시지로 다시 연결됩니다.
| 핵심 | 의미 |
|---|---|
| AI 품질은 연결된 문제 | 데이터 품질, 모델 품질, 운영 품질의 상호 연결 |
| 데이터 품질은 모델 성능을 흔드는 요인 | 결측치, 이상치, 라벨 오류, 클래스 불균형이 모델 지표에 미치는 영향 |
| Accuracy만으로는 부족한 품질 판단 | Precision, Recall, FP/FN, AUROC, PR-AUC를 함께 보는 평가 관점 |
| 운영 endpoint에는 추적 정보가 필요 | 점수, 임계값, 모델 버전, 요청 ID(request_id), 배포 revision 기반 품질 문제 추적 |
| 로그와 대시보드는 품질 관측 도구 | 오류(error), 지연 시간(latency), 점수 분포, 예측 분포를 함께 보는 운영 관측 |
이 메시지는 각 장에서 반복해서 확인합니다. 데이터 품질 문제는 모델 지표에 영향을 주고, 모델 지표는 임계값 판단으로 이어지며, 임계값과 모델 버전은 운영 API 응답과 로그에 남아야 추적할 수 있습니다.
1-5. 전체 품질 판단 흐름¶
AI QA에서 중요한 것은 “모델이 한 번 잘 동작했는가”가 아니라 “배포와 운영 과정에서 품질 근거를 계속 설명할 수 있는가”입니다. 품질 판단 흐름은 데이터가 평가 가능한지 확인한 뒤, 모델 판단, API 추적 정보, 운영 관측, 최종 승인 기준으로 범위를 넓혀 갑니다.
과정 전체 사건은 단일 수치 변화가 아니라 여러 신호의 조합으로 다룹니다. 기준 데이터는 평가 가능하지만 현재 운영 입력 샘플에서는 검증 실패가 나타나고, 후보 모델은 MLflow candidate로 등록되어 Argo CD와 KServe 배포 후보가 됩니다. 아래 흐름은 이런 신호를 순서대로 좁혀 최종 판단으로 연결하는 기준입니다.
기준 데이터 품질 확인
→ 현재 운영 입력 샘플의 검증 실패 확인
→ 품질 저하 평가 데이터셋으로 모델 지표 변화 해석
→ MLflow 모델과 threshold 기록 확인
→ Argo CD Application과 KServe InferenceService 확인
→ 후보 모델 endpoint 로그와 메트릭 변화 확인
→ drift와 승인 기준 적용
→ 배포, 보류, 되돌림 조건 정리
품질 확인 질문은 데이터, 모델, 운영 추적 가능성으로 요약됩니다. 데이터가 평가 가능한 상태인지, 모델 판단이 지표로 설명되는지, 운영 중에도 같은 정보를 추적할 수 있는지를 확인하는 것입니다. 보류 판단은 끝이 아니라 담당 owner의 후속 확인과 같은 approval rule 재평가 조건까지 포함해야 방어 가능한 판단이 됩니다.
| 단계 | 품질 확인 질문 |
|---|---|
| 데이터 품질 확인 | 특성(feature)과 정답(label)이 모델 평가에 사용할 수 있는 상태인가 |
| 모델 평가 지표 해석 | Accuracy 외에 Precision, Recall, FP/FN, PR-AUC를 함께 확인했는가 |
| 임계값 기준 품질 판단 | 점수가 어떤 기준으로 예측으로 바뀌는가 |
| GitOps 배포 구조 확인 | Argo CD sync 대상과 KServe endpoint가 모델 버전, 임계값, 요청 ID를 추적할 수 있는가 |
| 로그와 메트릭 수집 | 오류, 지연 시간, 점수 분포, 예측 분포를 추적할 수 있는가 |
| 대시보드 기반 이상 징후 탐지 | 기준선(baseline)과 다른 변화가 보이는가 |
| 배포 판단 체크리스트 정리 | 배포, 보류, 되돌림 기준을 설명할 수 있는가 |
이 표는 이후 장을 읽을 때 기준점으로 사용할 수 있습니다. 어떤 도구를 보더라도 최종 질문은 “품질 이상을 설명하고 추적할 수 있는가”로 돌아옵니다.