05. 배포 판단¶
5장은 risk-classifier@candidate를 배포할지 보류할지 결정하는 장입니다. 2장에서 데이터 검증과 모델 지표를 확인했고, 3장에서 Argo CD와 KServe 배포 경로를 확인했으며, 4장에서 응답 로그와 메트릭을 확인했습니다. 이제 그 확인 결과를 한 문장으로 정리합니다.
이번 장의 목적은 새로운 도구를 더 배우는 것이 아닙니다. 목적은 “지금 배포해도 되는가”, “보류한다면 무엇을 더 확인해야 하는가”, “이미 배포했다면 어떤 기준에서 되돌릴 것인가”를 문서화하는 것입니다.
| 기준 | 내용 |
|---|---|
| 받은 업무 | risk-classifier@candidate를 배포할지 보류할지 판단 |
| 결정 압박 | 기능 테스트와 일부 metric은 좋아 보이지만 Recall, error rate, 실제 endpoint 확인이 남음 |
| 확인 결과 | 데이터 검증, MLflow run, Argo CD sync, KServe 상태, 로그와 메트릭 |
| 산출물 | 배포, 보류, 되돌림 기준이 포함된 최종 판단 문장 |
1. 앞 장 결과를 모으기¶
5장은 앞 장에서 확인한 값을 다시 모아 배포 판단으로 바꾸는 단계입니다. 후보 모델은 Precision 측면에서 좋아 보이지만, Recall과 error rate 기준을 만족하지 못할 수 있고, 실제 Argo CD/KServe 확인이 없는 환경에서는 운영 준비 완료라고 말할 수 없습니다.
| 항목 | 5장에서의 적용 |
|---|---|
| 이번 장의 역할 | 앞 장의 확인 결과를 배포/보류/되돌림 판단으로 묶음 |
| 새로 확인하는 자료 | release_approval.md, quality_issue_trace.md, ai_qa_checklist.md, Argo CD/KServe 확인 결과 |
| 약화할 후보 | 기능 테스트 통과만으로 승인 가능하다는 주장 |
| 유지할 risk | Recall 미달, error rate 초과, validation failure, 실제 endpoint 미확인 |
| 최종 문장 | 배포, 보류, 되돌림 조건 |
2. 판단 기준¶
배포 판단은 단일 점수로 결정하지 않습니다. 후보 모델이 이전 모델보다 일부 지표에서 좋아도 데이터 검증, 모델 지표, 응답 필드, 로그와 메트릭, Argo CD sync 상태를 함께 봐야 합니다.
| 기준 | 확인 질문 | 문제가 있으면 |
|---|---|---|
| 데이터 검증 | 평가 데이터 조건이 기록되고 해석 가능한가 | 지표 해석 제한 또는 보류 |
| MLflow 기록 | model URI와 version이 추적되는가 | 배포 대상 불명확 |
| 모델 지표 | Precision, Recall, error rate 기준을 만족하는가 | 배포 보류 |
| Argo CD | Application과 sync 상태가 확인되는가 | 실제 배포 미확인 |
| KServe | InferenceService Ready와 endpoint URL이 확인되는가 |
endpoint 확인 보류 |
| 로그와 메트릭 | 응답과 운영 지표가 남는가 | 운영 확인 부족 |
| 되돌림 기준 | 어떤 조건에서 이전 버전으로 되돌릴지 정의됐는가 | 배포 위험 큼 |
이 구조를 쓰면 “좋아 보인다”와 “배포한다” 사이의 간격이 보입니다. 특히 Argo CD를 쓰는 이번 과정에서는 어떤 Git 경로와 sync 상태를 확인했는지 남겨야 합니다.
3. 학습 흐름¶
학습 흐름은 4장의 관측 결과를 최종 판단 문장으로 바꾸는 순서입니다.
입력 구성과 score/prediction 변화 확인
→ 품질 이슈 후보와 owner 정리
→ 모델 지표와 응답 필드 기준 적용
→ Argo CD/KServe 실제 확인 결과 확인
→ 배포/보류/되돌림 판단
→ checklist와 report 작성
5장의 실습은 모델 성능을 끌어올리는 것이 아닙니다. 5장의 실습은 현재 확인 결과로 운영 배포를 승인하면 어떤 위험이 있고, 보류하면 어떤 비용이 있는지 균형 있게 남기는 것입니다.
4. 도구와 확인 결과 연결¶
5장에서 사용하는 도구와 산출물은 최종 판단의 근거입니다. 수강생은 보고서에 “무슨 값을 봤는가”, “어떤 기준을 만족하지 못했는가”, “누가 무엇을 확인하면 다시 판단할 수 있는가”를 남깁니다.
| 도구와 경로 | 주요 책임 | 최종 판단에서 쓰는 방식 |
|---|---|---|
| Great Expectations artifact | 데이터 검증 조건 | 데이터 조건 해석 제한 여부 |
| MLflow run/registry | 모델 기록 | model URI와 alias 확인 |
| Argo CD Application | GitOps 배포 상태 | sync revision, health, diff |
| KServe InferenceService | serving readiness | endpoint 준비 상태 |
| Observability artifacts | 운영 관측값 | error, latency, validation failure, score/prediction 분포 |
approval_rules.yaml |
판단 기준 | Precision, Recall, error rate, latency 기준 |
release_approval.md |
최종 판단 | approved 여부, 실패 기준, 미확인 항목 |
quality_issue_trace.md |
owner와 next action | 재평가 조건과 책임 |
5. 산출물과 확인 기준¶
최종 산출물은 배포 판단 리포트와 체크리스트입니다. 준비된 산출물은 uv run --group lab python labs/ch05_qa_strategy/build_qa_artifacts.py로 재생성할 수 있고, JupyterLite에서는 준비된 확인 결과를 읽는 방식으로 확인합니다.
| 산출물 | 확인 경로 | 보고서에 남길 값 |
|---|---|---|
| 입력 구성 변화 리포트 | artifacts/reports/drift_report.md |
입력 평균 변화, score 변화, prediction 비율 변화 |
| 품질 이슈 추적 | artifacts/reports/quality_issue_trace.md |
candidate risk, owner, next action |
| 배포 승인 리포트 | artifacts/reports/release_approval.md |
approved=False, failed checks, 실제 확인 결과 상태 |
| 체크리스트 | artifacts/reports/ai_qa_checklist.md |
보류 상태, 미검증 항목, 재평가 조건 |
| Argo CD 확인 결과 | argocd app get/diff/sync 또는 미검증 기록 |
Git revision과 sync status |
| KServe 확인 결과 | kubectl get inferenceservice 또는 미검증 기록 |
endpoint readiness |
예시 기준에서는 Precision은 통과하지만 Recall 0.5926 < 0.6000, error rate 0.0667 > 0.0500이 기준을 만족하지 못합니다. live /health, /predict, Argo CD sync revision, KServe readiness가 없는 환경에서는 운영 배포 준비 완료라고 쓰지 않습니다.
6. 문서 목록¶
문서 목록은 관측값을 배포 판단으로 압축하는 순서입니다.
| 순서 | 문서 | 확인할 내용 |
|---|---|---|
| 1 | 입력 데이터 분포 변화 확인 | 후보 모델 입력 구성 변화와 score 영향 후보 |
| 2 | 점수와 예측 분포 분석 | score/prediction 분포 변화 |
| 3 | 운영 이상 징후 탐지와 원인 추적 | owner, next action, 확인 결과 gap |
| 4 | AI 품질 회귀 테스트 전략 | 기준 모델 대비 candidate 후퇴 여부 |
| 5 | 테스트 데이터 설계 전략 | 정상/오류/경계 케이스 |
| 6 | 배포 승인과 운영 전환 기준 | 배포/보류/되돌림 기준 |
| 7 | 실제 장애 사례 분석 | 운영 전환 risk 사례 |
| 8 | 최종 확인 결과 정리 | 최종 체크리스트 |
| 9 | 5장 마무리 | 최종 보고서 문장 |