3장 마무리: 모델 배포 경로 정리

3장의 결론은 후보 모델을 실제 API 응답 후보로 만들려면 모델 기록, 배포 파일, 클러스터 리소스, 응답 필드가 이어져야 한다는 점입니다. 모델 파일만 있거나, Kubernetes YAML만 있거나, Argo CD 화면만 있는 상태는 각각 부분 확인입니다. QA가 보고서에 쓸 수 있는 문장은 이 확인들이 같은 모델을 가리킬 때 만들어집니다.

이번 장에서는 모델 구조를 새로 바꾸지 않았습니다. 기존 Tree 기반 분류 모델을 유지하고, 학습 결과를 MLflow에 남긴 뒤 Argo CD와 KServe로 배포 후보를 선언하는 흐름을 정리했습니다. 핵심은 새 알고리즘을 보여 주는 것이 아니라 risk-classifier@candidate가 어떤 평가 기록에서 나왔고, 어떤 Git 경로와 KServe 리소스로 이어지는지 확인하는 것입니다. 실제 실행 코드는 tta-aiqa에서 관리하며, GitOps/KServe 자산이 아직 없다면 live 확인을 완료했다고 쓰지 않습니다.

1. 3장에서 남길 확인 결과

3장에서 남겨야 할 것은 명령 성공 목록이 아니라 같은 후보 모델을 추적할 수 있는 연결 정보입니다. 수강생은 “이 모델은 어디서 왔고, 어떤 파일에 선언됐고, 어떤 런타임이 응답하며, 응답에 어떤 필드가 남는가”를 설명할 수 있어야 합니다.

연결 구간	핵심 산출물	보고서 문장
평가 결과 → MLflow	평가 지표, threshold, MLflow run	후보 모델의 평가 기준과 지표가 기록됐습니다
MLflow → Git	models:/risk-classifier@candidate, KServe manifest	배포 파일은 후보 모델 URI를 가리킵니다
Git → Argo CD	Argo CD Application, source.path, targetRevision	배포 기준 파일과 revision을 추적할 수 있습니다
Argo CD → KServe	InferenceService, sync/health 확인	배포 파일이 클러스터 리소스로 반영됐는지 확인합니다
KServe → 응답 필드	model_version, score, threshold, prediction	4장에서 로그와 메트릭으로 다시 확인할 필드입니다

이 표의 핵심은 각 도구가 서로 다른 질문에 답한다는 점입니다. MLflow는 모델 출처를 설명하고, Argo CD는 어떤 파일이 배포 기준인지 보여 주며, KServe는 모델 API 리소스를 제공합니다. 4장에서는 이 흐름이 실제 요청 로그와 메트릭으로 이어지는지 확인합니다.

2. Argo CD와 KServe 확인 기준

Argo CD 확인 기준은 Git에 있는 배포 파일이 실제 클러스터 상태와 맞는지 보는 것입니다. 수동 kubectl apply는 초기 설정이나 교육장 사전 준비에만 남기고, 수강생이 확인할 핵심은 Application이 어떤 Git 경로를 바라보는지입니다.

확인 항목	통과 기준	미통과 시 처리
repoURL	실제 교육장 repository로 설정	placeholder면 live sync를 했다고 쓰지 않음
source.path	demos/ch03_docker_kubernetes/gitops/overlays/dev	다른 path면 배포 후보 불일치, 파일이 없으면 tta-aiqa 실습 자산 추가 필요
destination.namespace	ai-quality	namespace 정책 확인
argocd app diff	의도한 KServe 변경만 표시	불필요한 변경이면 sync 보류
argocd app wait	sync와 health 조건 만족	KServe status와 event 확인

KServe 확인 기준은 추상화 이름을 외우는 것이 아니라 어떤 엔진이 실제로 요청을 처리하는지 이해하는 것입니다. KServe는 InferenceService라는 Kubernetes 리소스로 모델 API를 선언하게 해 주고, 내부에서는 Knative, Kubernetes Pod, 선택한 ServingRuntime이 실제 실행을 담당합니다. 따라서 QA는 InferenceService Ready 상태, runtime, storageUri, 응답 필드를 함께 확인해야 합니다.

3. 4장으로 넘길 항목

4장으로 넘길 것은 endpoint 운영 관측을 시작하기 위한 확인 항목입니다. 교육장에 live cluster가 없었다면 live_sync=unverified로 남기고, 4장에서는 준비된 로그와 메트릭으로 관측 흐름을 실습합니다. 실제 cluster가 있다면 같은 항목에 Argo CD sync revision과 KServe Ready 상태를 채웁니다.

field	예시 값	상태
check_scope	후보 모델 배포 확인	보고서 범위
model_uri	models:/risk-classifier@candidate	inspection 확인
gitops_path	demos/ch03_docker_kubernetes/gitops/overlays/dev	inspection 확인 또는 자산 추가 필요
argocd_app	ai-quality-risk-classifier	inspection 또는 live 확인
kserve_resource	InferenceService/ai-quality-risk-classifier-dev	inspection 또는 live 확인
response_fields	request_id, model_version, score, threshold, prediction, latency_ms, validation_failure	4장 확인 대상
live_sync	verified 또는 unverified	5장 판단에 사용

보고서 문장은 다음처럼 마무리합니다.

3장에서는 `risk-classifier@candidate`의 배포 경로를 확인했습니다. Argo CD Application은 `demos/ch03_docker_kubernetes/gitops/overlays/dev`를 source path로 사용하고, KServe `InferenceService`는 candidate model URI와 응답 필드를 선언합니다. live sync 상태는 [verified/unverified]이며, endpoint 로그와 메트릭은 4장에서 확인합니다.