5-6. 배포 승인과 운영 전환 기준 [Core]¶
5-6의 판단은 후보 모델을 배포할지, 보류할지, 문제가 생기면 되돌릴지 결정하는 것입니다. Argo CD를 쓰는 이번 과정에서는 모델 지표뿐 아니라 Git revision, sync status, KServe readiness, 로그와 메트릭 확인 결과를 함께 봅니다.
배포 승인은 “모델 지표가 기준을 넘었는가”보다 넓은 질문입니다. 후보 모델이 MLflow Registry에 있고 Argo CD manifest가 있어도 실제 endpoint 확인이 없으면 운영 전환 완료라고 말할 수 없습니다.
5-6-1. 배포 판단 항목¶
배포 판단에서는 확인하지 않은 항목을 통과로 처리하지 않습니다. 준비된 artifact로 확인한 항목과 live 환경에서 확인한 항목을 분리해야 합니다.
| 항목 | 기준 | 예시 상태 | 판단 |
|---|---|---|---|
| 데이터 검증 | 검증 산출물과 실패 해석 존재 | prepared 확인 결과 있음 | 조건부 통과 |
| MLflow 기록 | model URI와 run 조건 존재 | models:/risk-classifier@candidate |
통과 |
| 모델 지표 | Precision, Recall, error rate 기준 만족 | Recall 미달, error rate 초과 | 실패 |
| Argo CD sync | sync revision과 health 확인 | 환경에 따라 미검증 | 미검증 항목 |
| KServe readiness | InferenceService Ready |
환경에 따라 미검증 | 미검증 항목 |
| 로그와 메트릭 | request, log, metric 필드 존재 | prepared telemetry 있음 | 조건부 통과 |
| 되돌림 기준 | 되돌릴 조건과 이전 revision 정의 | 문서화 필요 | 보강 필요 |
이 표에서 하나라도 실패하면 무조건 폐기한다는 뜻은 아닙니다. 실패 항목이 운영 risk인지, 보류 사유인지, 제한적 canary 조건인지 판단해야 합니다.
5-6-2. 모델 지표 기준¶
모델 지표 기준은 후보 모델이 이전 모델 대비 후퇴하지 않는지 확인합니다. 예시 기준은 minimum_precision: 0.6, minimum_recall: 0.6, maximum_error_rate: 0.05, maximum_latency_average_ms: 250입니다.
| Metric | 기준 | 후보 모델 예시 | 결과 |
|---|---|---|---|
| Precision | >= 0.6000 |
1.0000 |
통과 |
| Recall | >= 0.6000 |
0.5926 |
실패 |
| Error rate | <= 0.0500 |
0.0667 |
실패 |
| Average latency | <= 250ms |
223.750ms |
통과 |
이 결과는 배포를 막을 충분한 근거입니다. Precision이 좋아도 Recall과 error rate가 기준을 통과하지 못하면 운영 alias 전환을 바로 승인하기 어렵습니다.
5-6-3. Argo CD 확인 기준¶
Argo CD 확인 기준은 후보 모델 manifest를 어떤 Git revision에서 sync했는지 확인하는 것입니다. 이 확인이 없으면 운영에 올라간 resource가 어떤 파일과 commit에서 왔는지 추적하기 어렵습니다.
| 확인 항목 | 확인 경로 | 실패 시 판단 |
|---|---|---|
| Application source | argocd app get ai-quality-risk-classifier |
Git source 미확인 |
| diff | argocd app diff ai-quality-risk-classifier |
변경 범위 미확인 |
| sync | argocd app sync ai-quality-risk-classifier |
live deployment 미완료 |
| revision | Argo CD app status | 되돌릴 대상 미확인 |
| health | Argo CD health status | serving readiness 추가 확인 필요 |
교육장에 Argo CD가 없으면 이 항목을 통과로 처리하지 않습니다. manifest inspection은 “배포 파일 확인”이고, Argo CD sync는 “실제 배포 확인”입니다.
5-6-4. KServe와 endpoint 확인 기준¶
KServe 확인 기준은 InferenceService가 Ready인지, endpoint가 필요한 응답 필드를 반환하는지 확인하는 것입니다. KServe built-in runtime은 모델 inference를 수행하지만, custom response field를 자동으로 보장하지 않으므로 response contract를 따로 확인해야 합니다.
| 확인 항목 | 통과 기준 | 실패 시 조치 |
|---|---|---|
InferenceService Ready |
Ready condition true | events, storageUri, runtime 확인 |
| predictor runtime | sklearn/MLServer 등 expected runtime | ServingRuntime 확인 |
| endpoint response | model alias, score, threshold, prediction 반환 | transformer 또는 custom predictor 보강 |
| structured log | request_id와 prediction event 기록 | telemetry layer 보강 |
| Prometheus metric | error, latency, validation failure 노출 | instrumentation 보강 |
이 확인은 4장 운영 관측과 직접 연결됩니다. endpoint가 필드를 남기지 못하면 4장 dashboard도 배포 판단에 필요한 근거를 만들 수 없습니다.
5-6-5. 되돌림 기준¶
되돌림 기준은 배포 이후 문제가 생겼을 때 Argo CD가 어떤 revision 또는 manifest로 돌아가야 하는지 정합니다. 되돌림 조건이 없으면 배포 결정은 운영 risk를 과소평가합니다.
| 되돌림 조건 | 기준 예시 | 조치 |
|---|---|---|
| error rate | > 0.05가 15분 이상 지속 |
이전 Git revision sync |
| validation failure rate | 기준선 대비 2배 이상 | client payload owner 확인, 후보 모델 traffic 중단 |
| latency average | > 250ms 지속 |
KServe resource와 runtime 부하 확인 |
| prediction shift | high_risk 비율 기준선 대비 급증 |
threshold/model alias 확인 후 보류 |
| missing telemetry | request_id 또는 model alias 누락 | 배포 중단, instrumentation 수정 |
되돌림은 실패를 인정하는 절차가 아니라 운영 안전장치입니다. 특히 Argo CD 기반 배포에서는 이전 Git revision과 Argo CD app history가 되돌림 근거가 됩니다.
5-6-6. 최종 판단 문장¶
현재 준비된 예시에서는 배포보다 보류가 적절합니다. Recall과 error rate가 기준을 만족하지 못하고, 실제 Argo CD/KServe 확인이 없는 환경에서는 운영 배포 준비 완료라고 말할 수 없습니다.
risk-classifier@candidate는 MLflow 기록과 GitOps manifest가 확인되었지만, 모델 지표에서 Recall과 error rate 기준을 만족하지 못했습니다.
또한 live Argo CD sync, KServe readiness, endpoint response가 미검증이면 운영 전환 완료로 판단할 수 없습니다.
따라서 운영 alias 전환은 보류하고, metric 실패 원인 확인과 live sync/smoke 확인 후 같은 기준으로 재평가합니다.
제한적 canary를 허용하려면 조건을 더 붙입니다. 예를 들어 traffic 비율, 되돌림 조건, owner, 관측 기간, stake보류er 승인 조건이 문서화되어야 합니다.