5장 마무리: 최종 산출물의 형태

AI QA 전략의 최종 목표는 품질 이상 징후를 근거 있는 판단 문서로 정리하는 것입니다. 이번 실습 사건의 최종 판단은 조건부 보류입니다. drift_report.md는 current batch에서 heart_rate 평균 +10.4917, oxygen_saturation 평균 -1.4698이 관측되었음을 보여주고, label_basis_check.md는 라벨 허용값과 표본 수가 평가 가능한 상태임을 남깁니다. release_approval.md는 recommendation=conditional_hold, approved=False, 실패 기준 recall, error_rate의 관측값과 기준값, live_deployment=unverified 리스크, 승인/보류 리스크와 재평가 조건을 남깁니다.

이번 장에서는 입력 분포 변화, 점수(score)와 예측(prediction) 분포 변화, 원인 후보, 조건부 보류 판단, 최종 체크리스트를 하나의 판단으로 연결했습니다. 마무리에서는 이 산출물이 서로 따로 남지 않고 “왜 지금은 승인하지 않는가”와 “무엇을 확인하면 재평가할 수 있는가”를 설명하는지 확인합니다.

1. 산출물 연결 기준

마무리에서는 다음 산출물이 준비되었는지 확인합니다.

확인 기준	산출물
데이터 변화 근거	drift_report.md: current batch heart_rate +10.4917, oxygen_saturation -1.4698
라벨 기준 근거	label_basis_check.md: invalid_count=0, missing_count=0, high_risk=37, low_risk=33
모델 출력 변화 근거	평균 점수 0.5020→0.6402, high_risk 비율 0.2167→0.4583
원인 후보 정리 여부	quality_issue_trace.md: input_case_mix_shift로 기록된 current batch 입력 구성 변화, prediction_shift, api_validation, service_latency, owner, audit reference
조건부 보류 판단 기록	release_approval.md: recommendation=conditional_hold, approved=False, precision 1.0000 >= 0.6000, recall 0.5926 < 0.6000, error_rate 0.0667 > 0.0500, live_deployment=unverified, 승인/보류 리스크
현업 적용 체크리스트	ai_qa_checklist.md: 릴리스 준비 상태=blocked, status=hold, owner, next action

각 산출물은 서로 다른 질문에 답합니다. drift_report.md는 current batch 입력 구성이 기준선과 달라졌는지 설명하고, label_basis_check.md는 라벨 기준이 뒤집혔다는 후보를 약화합니다. 예측 변화 출력은 모델 출력이 바뀌었는지 설명합니다. quality_issue_trace.md는 원인 후보, owner, audit reference를 나누고, release_approval.md는 현재 기준에서 승인 가능한지와 승인/보류 각각의 리스크를 판단합니다. ai_qa_checklist.md는 이 흐름을 이번 릴리스의 sign-off와 다음 릴리스의 반복 점검 기준으로 남깁니다.

2. 최종 QA 코멘트 예시

최종 QA 코멘트는 결론부터 쓰고, 그 뒤에 근거와 다음 조치를 붙입니다. 조건부 보류 판단은 다음처럼 근거를 붙여 남깁니다.

조건부 보류 판단입니다.
`drift_report.md`에서는 current batch의 `heart_rate` 평균이 기준선보다 10.4917 높고, `oxygen_saturation` 평균이 1.4698 낮습니다.
운영 로그에서는 `high_risk` 비율이 0.2167에서 0.4583으로 증가했고, 평균 점수도 0.5020에서 0.6402로 상승했습니다.
`model_version`과 `threshold`는 기존 기준과 일치하므로 설정 오류 가능성은 낮습니다.
라벨 기준은 `label_basis_check.md`에서 `high_risk`와 `low_risk` 허용값, invalid 0건, missing 0건으로 확인되었습니다.
다만 검증 실패(validation failure)도 일부 증가했으므로 클라이언트 페이로드(client payload) 변경 여부를 추가 확인해야 합니다.
live deployment smoke evidence는 아직 없으므로 운영 배포 검증 완료를 승인 근거로 쓰지 않습니다.
보류로 인한 릴리스 지연 리스크는 release owner에게 공유하고, `Data Engineering`, `ML Engineering`, `Client Integration`, `Platform/MLOps`의 확인 결과가 모이면 같은 approval rule로 재평가합니다.

조금 더 완성된 최종 QA 코멘트는 다음 형태가 좋습니다.

입력 특성(feature) 분포 변화와 점수, 예측 분포 변화가 함께 확인되었습니다.
`label_basis_check.md`에서는 `invalid_count=0`, `missing_count=0`, `high_risk=37`, `low_risk=33`가 확인되어 라벨 값 기준 변경 가능성은 낮습니다.
`model_version=v1`과 `threshold=0.5`는 기준과 일치하므로 설정 오류 가능성은 낮지만, 검증 실패 증가가 일부 동반되어 클라이언트 페이로드(client payload) 변경 여부를 확인해야 합니다.
승인 기준 적용 결과 `precision=1.0000`은 최소 기준 `0.6000`을 통과했지만, `recall=0.5926`은 최소 기준 `0.6000`에 근소하게 미달했고 `error_rate=0.0667`은 최대 기준 `0.0500`을 초과했습니다. 또한 live `/health`, `/predict`, Pod readiness, 응답 `model_version`, `threshold` 증거는 아직 없으므로 운영 배포 준비 완료를 승인 근거로 쓰지 않습니다. 현재 상태에서는 배포 승인보다 데이터 수집 경로, 입력 스키마(schema) 변경 여부, live smoke evidence를 먼저 확인하는 것이 적절합니다.
다만 precision, latency와 준비된 API 계약은 통과했으므로 보류 사유는 전체 서비스 실패가 아니라 recall 기준 근소 미달, 오류율 기준 미충족, 미검증 운영 배포 증거로 제한해 설명합니다.

이 문장은 확정 원인과 후보 원인을 구분합니다. 입력 분포 변화와 예측 분포 변화는 관측된 근거이고, 클라이언트 페이로드 변경 여부는 다음 확인 후보입니다. 설정 오류 가능성이 낮다는 판단도 model_version과 threshold가 기준과 일치한다는 근거가 있을 때만 쓸 수 있습니다.

3. 완료 기준

5장의 완료 기준은 모든 가능성을 다 설명하는 것이 아니라, 근거를 기준으로 우선순위를 정하는 것입니다.

완료 기준	확인 질문
근거 연결	입력, 점수, 예측, 운영 신호가 같은 시간대와 기준선으로 연결되는가
원인 후보 분리	데이터, 모델, 설정, 운영 원인을 구분했는가
승인 판단	승인, 조건부 보류, 추가 확인 중 어떤 판단인지 설명했는가
다음 조치	누가 무엇을 확인해야 하는지 남겼는가
재사용 가능성	체크리스트가 다음 배포나 이상 징후에도 반복 사용 가능한가

최종 체크리스트는 실습의 끝이 아니라 현업 적용의 시작점입니다. 같은 형식으로 데이터셋, 모델, 임계값(threshold), API 계약(contract), 운영 관측을 반복 확인할 수 있어야 AI QA 전략이 실제 품질 관리 흐름으로 이어집니다.