4장 마무리: 운영 확인 결과 정리

4장의 결론은 대시보드를 봤다는 사실이 아니라 후보 모델 endpoint의 운영 상태를 설명할 근거를 만들었다는 점입니다. 3장에서 Argo CD와 KServe 배포 경로를 확인했다면, 4장에서는 그 endpoint가 요청 처리 중 어떤 로그, 메트릭, trace, dashboard 값을 남겨야 하는지 확인했습니다.

기존 observability 자산은 그대로 사용합니다. chapter_04_anomaly_events.jsonl, Prometheus text, Grafana dashboard JSON, trace payload는 유지하되 해석의 중심을 “도구 화면 확인”에서 “배포 판단에 필요한 운영 값 확인”으로 좁힙니다.

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

4장에서 남겨야 할 확인 결과는 request 단위와 집계 단위를 함께 포함해야 합니다. request 단위 로그가 없으면 대표 실패를 추적하기 어렵고, metric이 없으면 시간 흐름과 비율을 설명하기 어렵습니다. dashboard는 둘을 함께 비교하는 화면입니다.

확인 결과	경로	사용 방식
request log	artifacts/logs/chapter_04_anomaly_events.jsonl	대표 요청의 request_id, model_version, score, prediction, validation_failure 확인
metric	artifacts/metrics/chapter_04_anomaly.prom	error rate, latency, validation failure, prediction ratio 확인
dashboard	artifacts/grafana/ai_quality_overview_dashboard.json	여러 신호를 한 화면에서 비교
trace	artifacts/traces/chapter_04_tempo_payload.json	latency가 어느 처리 구간에서 생겼는지 확인
issue trace	artifacts/reports/quality_issue_trace.md	5장 owner와 next action의 입력

이 확인 결과가 모두 있어도 배포가 자동 승인되는 것은 아닙니다. 4장은 운영 관측이 가능한지 보여 주고, 5장은 그 값을 기준에 대입해 배포, 보류, 되돌림 필요 여부를 판단합니다.

2. 5장으로 넘기는 판단

5장으로 넘길 판단은 “observability 정상” 같은 단순 문장이 아닙니다. 어떤 신호는 기준을 통과했고, 어떤 신호는 추가 확인이 필요하며, 어떤 확인은 아직 실행되지 않았는지 분리해야 합니다.

4장 결과	5장 기준에서의 의미
model_version과 threshold가 로그에 있음	후보 모델과 기준 모델 혼선 가능성을 줄임
validation failure가 늘어남	input/API contract owner 확인 필요
latency 평균은 기준 안이나 여유 감소	배포 후 관측 조건으로 남김
score/prediction 분포가 기준과 다름	모델 지표와 함께 해석 필요
live telemetry가 없고 prepared artifact만 있음	실제 운영 확인은 미검증으로 기록

보고서 문장은 다음처럼 씁니다.

4장 운영 확인 결과에서는 후보 모델 endpoint 판단에 필요한 `request_id`, `model_version`, `score`, `threshold`, `prediction`, `latency_ms`, `validation_failure` 필드를 확인했습니다. prepared artifact 기준으로 validation failure와 prediction 분포 변화가 남아 있으므로, 5장 배포 판단에서 배포 여부를 모델 지표와 live 확인 상태로 다시 판단합니다.