04. 배포된 모델의 운영 확인

4장은 배포된 후보 모델 endpoint가 운영에서 확인 가능한 상태인지 보는 장입니다. 3장에서 MLflow Model, Docker image, Argo CD, KServe InferenceService를 다뤘다면, 4장에서는 그 endpoint가 실제 요청을 처리할 때 어떤 로그와 메트릭을 남기는지 봅니다.

이 장의 초점은 데이터 결측이나 feature 처리 설명을 반복하는 것이 아닙니다. 이미 2장에서 데이터 검증 결과를 만들었고, 3장에서 모델 배포 단위를 정했습니다. 이제 확인할 것은 risk-classifier@candidate가 운영 요청을 받을 때 model_version, threshold, score, prediction, latency, validation_failure, request_id가 남는가입니다.

기준	내용
맡는 일	후보 모델 endpoint의 운영 신호를 로그, 메트릭, dashboard로 확인
이번 장의 상황	endpoint가 요청을 처리하지만 필요한 필드가 모두 남는지 확인 필요
확인 자료	JSONL event, Prometheus metric, Loki query, Grafana dashboard, trace preview
산출물	운영 관측 리포트와 5장으로 넘길 미확인 항목

1. 이번 장의 역할

4장은 “배포는 됐는데 운영 중 확인할 수 있는가”를 묻는 단계입니다. 모델을 registry에 올리고 KServe manifest를 만들었다고 해서 운영 준비가 끝난 것은 아닙니다. 배포된 endpoint가 어떤 모델 버전으로 어떤 기준을 적용했고, 요청 처리 중 어떤 실패와 지연이 있었는지 남겨야 합니다.

항목	4장에서의 적용
이번 장의 역할	후보 모델 endpoint의 live 또는 prepared telemetry를 확인
새로 확인하는 자료	chapter_04_anomaly_events.jsonl, Prometheus text, Grafana dashboard JSON, trace payload
약화할 후보	model version 또는 threshold가 로그에 없어서 판단을 못 하는 상태
유지할 후보	validation failure 증가, latency 여유 감소, score/prediction 분포 변화
5장으로 넘길 질문	로그와 메트릭으로 배포/보류 판단을 쓸 수 있는가

2. 이번 장에서 다룰 운영 확인 상황

운영 확인 사건은 후보 모델 endpoint가 기능적으로 응답하지만 필요한 신호가 충분한지 확인하는 상황입니다. API 200 응답만으로는 충분하지 않습니다. 같은 요청에 대해 request_id로 로그를 찾을 수 있고, 메트릭에서 오류율과 지연 시간이 보이며, 대시보드에서 score와 prediction 분포가 확인되어야 합니다.

후보 모델 endpoint 응답 확인
→ request_id로 구조화 로그 조회
→ Prometheus metric으로 error/latency/validation_failure 집계
→ Grafana dashboard에서 분포 변화 확인
→ 5장 배포 판단으로 미확인 항목 전달

이 장은 도구 사용법을 많이 외우게 만들지 않습니다. Loki, Prometheus, Grafana, trace preview는 각각 다른 질문에 답합니다. 로그는 한 요청을 다시 찾게 하고, 메트릭은 시간 흐름의 비율을 보여 주며, trace는 지연 구간을 설명하고, dashboard는 여러 신호를 한 화면에서 비교하게 합니다.

3. 중복을 제거한 관측 범위

4장에서 반복하지 않을 내용과 새로 볼 내용을 분리합니다. 데이터 결측의 의미, feature 기본 설명, 모델 지표 정의는 앞 장의 책임입니다. 4장은 그 결과가 운영 신호로 남는지 확인합니다.

4장에서 반복하지 않는 것	4장에서 새로 확인하는 것
결측값이 무엇인지 설명	validation failure가 어떤 요청과 owner로 남았는지
Precision, Recall 정의 반복	배포 판단에 필요한 metric 값을 수집할 수 있는지
FastAPI 구현 방법 반복	endpoint가 어떤 runtime이든 동일한 응답/로그 필드를 남기는지
데이터 품질 원인 단정	score/prediction 분포 변화와 로그를 연결할 수 있는지
Grafana 계정 개설 절차	dashboard JSON과 query가 어떤 운영 질문에 답하는지

이 분리가 없으면 4장은 1장과 2장의 결측 설명을 반복하게 됩니다. 이번 개정에서는 4장을 “관측 가능한 endpoint인가”라는 질문 하나로 묶습니다.

4. 핵심 질문

핵심 질문은 5장에서 다시 사용할 수 있는 확인 결과를 만드는 데 맞춥니다.

확인 관점	핵심 질문
요청 추적	request_id와 trace_id로 대표 요청을 다시 찾을 수 있는가
모델 기준	model_version, model_alias, threshold가 응답과 로그에 남는가
운영 안정성	error rate, latency, timeout, validation failure를 시간 흐름으로 볼 수 있는가
모델 출력	score와 prediction 분포를 기준선과 비교할 수 있는가
미확인 항목	live 환경에서 확인하지 못한 항목을 5장에 넘겼는가

5. 학습 흐름

학습 흐름은 endpoint telemetry를 낮은 수준의 이벤트에서 dashboard까지 올려 보는 순서입니다.

운영 관측 위협 요인 정리
→ 로그, 메트릭, trace 책임 구분
→ 구조화 로그와 request_id 확인
→ Loki/Prometheus 조회 기준 확인
→ Grafana dashboard로 신호 비교
→ 5장 배포 판단용 확인 결과 정리

이 흐름의 결론은 “대시보드를 만들었다”가 아닙니다. 결론은 “배포하거나 보류할 때 인용할 운영 확인 결과가 있다”입니다.

6. 도구와 산출물

4장에서 관측 도구는 배포 판단의 입력입니다. live telemetry를 전송하지 못하는 교육장에서는 준비된 artifact를 inspection하고, live 확인이 필요한 항목은 미검증 항목으로 분리합니다.

도구와 경로	주요 책임	5장에 넘길 확인 결과
JSONL event	요청별 request_id, model_version, score, prediction	대표 요청 추적 가능 여부
Prometheus metric	error, latency, validation failure, score bucket	기준선 대비 운영 상태
Loki query	request_id와 validation failure 조회	원인 후보 좁히기
Grafana dashboard	score/prediction, error, latency 한 화면 확인	배포/보류 판단 근거
Trace preview	요청 처리 구간 확인	지연 원인 후보

운영 관측 산출물은 5장에서 그대로 인용됩니다. 수강생은 모든 도구를 live로 연결하지 못해도 준비된 artifact를 읽고 어떤 결론이 가능한지 구분해야 합니다.

7. 문서 목록

문서 목록은 endpoint telemetry를 좁혀 가는 순서입니다. 이 장이 끝나면 수강생은 후보 모델 endpoint의 운영 확인 결과를 5장으로 넘길 수 있어야 합니다.

순서	문서	확인할 내용
1	운영 품질의 위협 요인	endpoint에서 볼 운영 risk
2	로그, 메트릭, 트레이싱의 차이	신호별 역할
3	구조화 로그와 request_id	요청 추적 필드
4	로그와 지표 확인 도구	Loki, Prometheus, Tempo 확인 경로
5	Grafana 대시보드 확인	배포 판단에 필요한 dashboard panel
6	운영 품질 관측 실습	prepared/live artifact 확인
7	4장 마무리	운영 확인 결과를 5장으로 정리