5-7. 실제 장애 사례 분석 [Mention]

5-7은 공개된 ML 운영 가이드에서 반복적으로 언급되는 장애 패턴을 앞의 확인 흐름에 연결하는 Mention 절입니다. 특정 회사의 사건을 길게 분석하기보다, 실제 운영에서 자주 나타나는 문제를 데이터, 드리프트(drift), 설정, 운영 신호로 나누어 정리합니다.

Google Rules of Machine Learning은 모델을 내보내기 전에 기본 점검(sanity check)을 하고, 조용한 실패(silent failure)와 학습-서빙 불일치(training-serving skew)를 주의해야 한다고 설명합니다. 5-7에서는 이 관점을 생체신호 기반 위험 알림 예제에 맞춰 “무엇을 먼저 확인할 것인가”로 바꿔 봅니다.

핵심은 장애를 “모델 자체 문제” 하나로 단정하지 않는 것입니다. 같은 high_risk 예측 증가라도 입력 데이터 변화, 점수(score) 분포 이동, 임계값(threshold) 설정 오류, API 검증 실패, 지연 시간(latency) 증가가 서로 다른 원인이 될 수 있습니다.

5-7-1. 데이터 품질 장애 사례

데이터 품질 장애는 결측값 증가, 라벨(label) 기준 오류, 입력 범위 변화로 발생할 수 있습니다. API는 정상 응답을 반환하더라도 모델 입력이 달라지면 점수와 예측(prediction)이 흔들릴 수 있습니다.

기능 응답이 정상이어도 입력 분포와 검증 실패가 함께 변하면 운영 품질 이상으로 봐야 합니다. 예를 들어 운영 요청에서 oxygen_saturation 값의 분포가 평소와 달라졌는데 API가 계속 200 응답을 반환한다고 가정합니다. 기능 테스트만 보면 정상처럼 보이지만, high_risk 예측 비율과 검증 실패(validation failure)가 함께 늘었다면 데이터 수집 경로, 전처리, 입력 범위 검증을 먼저 봐야 합니다.

데이터 품질 장애는 다음처럼 확인합니다.

관측 신호	장애 해석	먼저 확인할 것
특정 특성(feature) 평균 급변	입력 데이터 조건 변화 가능성	입력 출처(source), 전처리, 수집 단위 변경
검증 실패 증가	API 계약(contract) 또는 클라이언트 요청 문제	API 스키마(schema), 클라이언트 페이로드(payload)
high_risk 예측 급증	데이터 변화 또는 임계값 영향 가능성	점수 분포, 임계값, 모델 버전(model_version)

QA 보고에서는 “데이터 문제”라고만 쓰지 않습니다. 어떤 특성이 얼마나 변했고, 그 변화가 점수와 예측 분포에 어떻게 연결되었는지를 함께 남겨야 합니다.

5-7-2. Drift 기반 장애 사례

드리프트 기반 장애는 운영 입력 분포가 학습이나 평가 때와 달라지면서 발생합니다. 모델 파일과 API 코드는 그대로여도 운영 입력이 바뀌면 점수 분포와 예측 분포가 달라질 수 있습니다.

5-1과 5-2에서는 기준선(baseline)과 현재 상태를 비교해 heart_rate, oxygen_saturation, 평균 점수, high_risk 비율 변화를 확인했습니다. 이런 변화는 확정 원인이 아니라 원인 후보입니다. 드리프트가 보이면 모델을 바로 교체하기보다 입력 출처, 수집 기간, 사용자 그룹, 전처리 변경 여부를 함께 확인합니다.

드리프트 장애는 다음 신호를 묶어 봅니다.

관측 신호	근거로 볼 자료	QA 질문
특성 평균 변화	drift_report.md의 평균과 변화율	운영 입력 조건이 바뀌었는가
히스토그램(histogram) 이동	기준선과 현재 분포 비교	일부 구간의 입력이 급증했는가
점수 평균 상승	예측 변화 리포트(prediction shift report)	모델 출력이 전반적으로 한쪽으로 이동했는가
high_risk 비율 증가	예측 분포(prediction distribution)	임계값 영향과 분리했는가

QA 해석에서는 “드리프트 때문에 장애가 났다”라고 단정하지 않습니다. 드리프트는 입력 분포가 달라졌다는 신호이고, 장애 판단은 서비스 영향, 오류율(error rate), 지연 시간, 승인 기준과 함께 내려야 합니다.

5-7-3. 모델 버전 또는 임계값 설정 오류 사례

모델 버전 또는 임계값 설정 오류는 API가 정상 응답을 반환하기 때문에 늦게 발견될 수 있습니다. 배포된 model_version이 실험 기록과 다르거나 임계값이 승인 기준과 다르면 예측 비율이 급격히 달라질 수 있습니다.

이 문제는 모델 출력이 갑자기 달라진 것처럼 보이지만, 실제로는 운영 설정이 평가 기준과 달라진 상황일 수 있습니다. 같은 점수라도 임계값이 낮아지면 high_risk 예측이 늘고, 임계값이 높아지면 FN이 늘 수 있습니다.

설정 오류는 다음처럼 확인합니다.

관측 신호	먼저 확인할 설정	판단 기준
model_version 불일치	실험 기록, 배포 설정, 응답 필드(field)	승인된 모델이 배포되었는가
임계값 불일치	평가 리포트, 환경 변수, API 응답	평가 기준과 운영 기준이 같은가
예측 비율 급변	점수 분포와 임계값	모델 출력 변화인지 기준 변경인지 분리했는가

QA는 로그와 응답 필드에서 model_version, threshold, score, prediction, request_id를 함께 확인해야 합니다. 이 필드가 없으면 설정 변경과 모델 출력 변화를 분리하기 어렵습니다.

5-7-4. 운영 장애 사례

운영 장애는 오류율, 지연 시간, 검증 실패 증가로 나타납니다. 이 경우 모델 지표(metric)보다 API 상태와 입력 계약(contract)을 먼저 확인해야 합니다.

운영 장애 신호가 섞인 상태에서는 모델 평가보다 서비스 상태를 먼저 분리해야 합니다. 예를 들어 오류율과 지연 시간이 함께 증가하면 모델 평가 리포트를 먼저 다시 읽기보다 API 처리 실패, 검증 실패, 서비스 부하, 외부 의존성 지연을 확인해야 합니다. 운영 장애가 섞인 상태에서 계산한 예측 분포는 품질 판단을 왜곡할 수 있습니다.

운영 장애는 다음처럼 분리합니다.

관측 신호	가능 원인	먼저 볼 자료
오류율 증가	API 오류, 검증 실패, 의존성 실패	오류 로그와 request_id
지연 시간 증가	서비스 부하, 모델 실행 시간 증가, 외부 호출 지연	대시보드와 지연 시간 메트릭(metric)
검증 실패 증가	입력 스키마 또는 클라이언트 페이로드 변경	API 계약과 오류 응답
점수와 오류가 함께 증가	입력 이상이 모델 출력까지 영향	로그, 입력 구성 변화 리포트, 예측 분포

핵심은 장애를 “모델 자체 문제” 하나로 단정하지 않는 것입니다. 데이터, 모델, 서빙 설정, 운영 환경을 분리해서 근거를 확인해야 5-8의 최종 체크리스트가 실제 조치로 이어집니다.