3장 마무리: 서빙 구조를 QA 체크로 바꾸기

3장의 결론은 API 실행 성공과 서빙 기준 일치 증거를 구분하는 것입니다. 실습 API 응답 로그에는 요청 식별자, 모델 버전, 점수, 임계값, 예측이 함께 남습니다. 이 값이 있어야 운영 로그의 품질 신호를 같은 기준으로 추적할 수 있습니다.

마무리에서는 다음 네 가지를 확인할 수 있어야 합니다.

체크	질문
API 계약(contract)	입력 스키마(schema), 정상 응답, 오류 응답이 명확한가
서빙 일치성	특성(feature), 전처리, 예측 클래스(class) 기준, 임계값(threshold)이 평가 기준과 같은가
추적 가능성	request_id, model_version, score, threshold, prediction이 남는가
배포 설정	Docker/Kubernetes 설정이 모델 버전(model_version)과 임계값을 덮어쓰지 않는가

3장에서 작성하는 QA 코멘트는 다음 형태가 좋습니다.

서빙 API는 제공된 스키마 기준으로 정상 요청과 오류 요청을 모두 처리합니다.
응답에는 `request_id`, `model_version`, `score`, `threshold`, `prediction`이 포함되어 운영 추적이 가능합니다.
학습 특성과 서빙 입력 스키마 비교 결과 누락 특성과 예상 외 특성은 확인되지 않았습니다.
Kubernetes 매니페스트(manifest)에서는 ConfigMap을 통해 모델 버전과 임계값이 주입되므로 배포 후 실제 응답값 확인이 필요합니다.

현재 증거로는 API가 단순히 200 OK를 반환하는 수준을 넘어 추적 가능한 응답 필드를 남긴다는 점까지 확인했습니다. model_version과 threshold가 응답에 남으므로, 이후 운영 로그에서도 같은 값이 유지된다면 설정 변경 가능성은 낮아집니다.

예측 이벤트 로그도 같은 결론을 뒷받침합니다. artifacts/logs/prediction_events.jsonl에는 lab-03-request-001과 server-smoke-001 같은 요청의 model_version=v1, threshold=0.5, score, prediction이 함께 남습니다. 다만 같은 Lab 요청을 반복 실행하면 같은 request_id가 여러 줄 남을 수 있습니다. 이 로그는 응답과 로그를 연결할 수 있음을 보여주지만, 운영 요청 식별자 고유성을 증명하지는 않습니다.

서빙 검증에서 피해야 할 결론은 다음과 같습니다.

피해야 할 결론	이유
서버가 떠 있으므로 배포 가능	모델 산출물(model artifact)과 임계값이 맞는지 알 수 없음
/predict가 200이므로 정상	응답 필드(field)와 특성 일치성 확인이 빠져 있음
Docker build가 성공했으므로 서빙 기준도 일치	build 성공만으로 모델 산출물, 임계값, 응답 필드 일치를 보장하지 않음
Kubernetes 배포가 되었으므로 완료	준비 상태(readiness), 환경 변수(env), Service, 응답값 확인 필요

3장 산출물은 서빙/API 품질 확인 리포트입니다. API가 살아 있는지만 확인하지 말고, 모델 산출물, 특성 스키마(feature schema), 임계값, 모델 버전, request_id가 함께 확인되어야 합니다.

보고서에서 사용할 수 있는 문장과 아직 쓰면 안 되는 문장을 분리하면 승인/보류 판단이 더 방어 가능해집니다.

구분	문장
쓸 수 있는 문장	서빙 설정과 API 계약상 model_version=v1, threshold=0.5, 학습 특성 6개와 입력 스키마의 traceability가 확인되어 API/schema/threshold mismatch 후보는 약화되었습니다
조건부 문장	Docker/Kubernetes는 live 실행을 하지 않았다면 Dockerfile/manifest inspection 기준으로만 의도된 설정 흐름을 확인했습니다
아직 쓰면 안 되는 문장	운영 request_id 고유성이 검증되었습니다
아직 쓰면 안 되는 문장	Docker/Kubernetes live deployment가 정상 동작한다고 검증되었습니다
아직 쓰면 안 되는 문장	high_risk 비율 변화의 root cause가 해결되었으므로 릴리스를 승인할 수 있습니다

다음 확인은 이 응답 필드와 로그 필드(log field)를 기반으로 운영 품질 신호를 관측하는 것입니다. model_version=v1과 threshold=0.5가 운영 로그에서도 유지되는지, 그리고 high_risk 비율 증가가 입력 변화나 검증 실패와 함께 나타나는지 확인해야 합니다.

4장으로 넘겨야 할 남은 후보는 명확합니다. 라벨(label) 뒤집힘 여부, 실행 환경의 환경 변수 덮어쓰기, live deployment mismatch, 검증 실패(validation failure), 지연 시간(latency), 점수 분포와 예측 분포 변화는 3장에서 결론 내리지 않습니다. 3장의 역할은 이 후보들을 관측 가능한 로그와 지표로 추적할 준비가 되었는지 확인하는 것입니다.