4-1. 운영 품질의 위협 요인¶
운영 품질 위협은 API 장애처럼 보이는 문제와 모델 품질 변화처럼 보이는 문제가 섞여 나타나는 상황입니다. 4-1에서는 입력 이상, 지연 시간(latency), API 오류, 설정 오류, 드리프트(drift)를 구분해 어떤 로그와 메트릭을 먼저 확인해야 하는지 정리합니다.
이 문서를 읽을 때는 다음 기준을 중심으로 확인합니다.
- 입력 이상: 검증 실패(validation failure)와 입력 필드(field) 오류 확인
- 서비스 성능: 지연 시간, 오류율(error rate), 요청 수(request count) 확인
- 설정 오류: 모델 버전(model_version), 임계값(threshold), 예측 클래스(class) 기준 확인
- 드리프트 준비: 점수 분포(score distribution)와 예측 분포(prediction distribution)를 볼 수 있는 관측 필드 준비
4-1-1. 입력 데이터 이상¶
운영 중 입력 특성(feature)의 결측, 타입 오류, 범위 오류가 늘면 API의 validation_failure가 증가할 수 있습니다. 입력 오류가 API에서 걸러지지 않으면 점수 분포와 예측 분포도 함께 흔들릴 수 있습니다.
입력 데이터 이상은 모델 자체 문제처럼 보이는 경우가 많습니다. 예를 들어 특정 시간 이후 high_risk 예측(prediction)이 급증했다면 모델 판단 기준이 달라진 것처럼 보일 수 있습니다. 그러나 실제 원인은 상위 클라이언트(upstream client)가 oxygen_saturation 값을 잘못 보내거나, 특정 특성이 null로 들어오기 시작한 것일 수 있습니다.
| 관측 신호 | 의심할 원인 | QA 확인 포인트 |
|---|---|---|
validation_failure 증가 |
입력 스키마(schema) 불일치, 클라이언트 페이로드(client payload) 변경 | 실패한 요청(request)의 입력 필드와 오류 응답을 확인 |
score 평균 증가 |
입력 분포 변화, 전처리 오류 | 기준선(baseline) 대비 점수 분포를 비교 |
특정 prediction 급증 |
입력 데이터 편향, 임계값 설정 오류 | 예측 클래스 기준과 임계값 값을 함께 확인 |
입력 데이터 이상을 확인할 때는 오류 요청과 정상 요청을 분리해야 합니다. 검증 실패가 발생한 요청을 점수(score) 분포 계산에 섞으면 모델 품질 변화처럼 보일 수 있습니다. QA는 먼저 API 계약(contract) 위반이 있는지 확인하고, 그다음 정상 처리된 요청의 점수와 예측 분포를 봐야 합니다.
운영에서 입력 이상이 발견되면 다음 질문을 던집니다.
| 질문 | 이유 |
|---|---|
| 특정 필드 실패 집중 여부 | 클라이언트 페이로드(client payload) 변경이나 스키마 불일치 확인 |
| 특정 시간대 실패 시작 여부 | 배포나 데이터 수집 변경과 연결 |
| 특정 클라이언트(client) 또는 출처(source) 실패 집중 여부 | 상위 시스템(upstream) 문제 분리 |
| 정상 요청의 점수 분포 변화 | 입력 품질 문제가 모델 결과까지 영향을 줬는지 확인 |
4-1-2. 모델 응답 지연¶
API 응답이 성공해도 지연 시간이 커지면 운영 품질은 낮아집니다. 사용자는 예측 결과가 맞더라도 너무 늦게 도착하면 서비스를 신뢰하기 어렵습니다. 운영 QA에서는 정확도뿐 아니라 응답 시간도 품질 신호로 봐야 합니다.
지연 시간 증가는 여러 원인으로 발생할 수 있습니다. 모델 로딩이 매 요청마다 반복될 수도 있고, 외부 저장소 접근이 느려질 수도 있고, 트래픽(traffic) 증가로 CPU 자원이 부족할 수도 있습니다. AI 서비스에서는 모델 추론(inference) 자체가 무거워져 지연 시간이 늘어나는 경우도 있습니다.
| 관측 신호 | 해석 |
|---|---|
| 지연 시간만 증가 | 서비스 부하, 하위 의존성 지연, 모델 실행 시간 증가를 의심 |
| 지연 시간과 오류(error)가 함께 증가 | API 장애, 타임아웃(timeout), 검증 실패 증가를 함께 확인 |
| 지연 시간은 정상이고 예측만 변화 | 서비스 성능보다 입력 분포, 모델 버전, 임계값 우선 확인 |
지연 시간을 볼 때 평균값만 보면 부족합니다. 일부 요청만 매우 느린 경우 평균으로는 문제가 작아 보일 수 있습니다. 실습에서는 교육 단순화를 위해 평균 지연 시간을 사용하지만, 실무에서는 p95, p99 같은 백분위(percentile) 지표도 함께 봅니다.
QA 관점에서는 지연 시간 증가가 모델 품질 지표와 어떻게 연결되는지도 봐야 합니다. 예를 들어 타임아웃(timeout)이 늘면 예측 자체가 반환되지 않을 수 있고, 대체(fallback) 응답이 있다면 실제 모델 예측과 다른 결과가 사용자에게 전달될 수 있습니다.
4-1-3. API 오류와 검증 실패¶
API 오류는 서비스 실패 신호이고, validation_failure는 입력이 API 계약을 만족하지 못했다는 신호입니다. 둘은 같이 볼 수 있지만 의미는 다릅니다.
4xx 오류는 보통 요청 형식이나 권한 문제를 나타내고, 5xx 오류는 서버 내부 오류를 나타냅니다. 검증 실패는 일반적으로 입력 스키마나 타입 검증에서 발생합니다. QA는 오류율이 증가했을 때 4xx, 5xx, 검증 실패를 구분해야 합니다.
| 항목 | 의미 | 대표 확인 대상 |
|---|---|---|
status_code |
API 처리 결과 | 4xx, 5xx 비율 |
validation_failure |
입력 검증 실패 여부 | 필수 필드 누락, 타입 오류, 범위 오류 |
failed_field |
검증 실패 입력 필드 | heart_rate, oxygen_saturation 등 |
client_id, source_system |
실패 요청의 출처 | 특정 client 또는 upstream 변경 |
request_id |
하나의 요청 식별자 | 특정 요청의 원인 추적 |
trace_id |
여러 로그를 묶는 흐름 식별자 | API, model loader, downstream 호출 연결 |
검증 실패가 증가하면 모델 지표(metric)보다 입력 계약(contract)을 먼저 확인합니다. 잘못된 요청이 모델까지 도달하지 못했기 때문에, 이것을 모델 지표 저하로 해석하면 안 됩니다. 이때 failed_field, client_id, source_system이 있어야 API schema owner와 upstream client owner 중 누가 먼저 확인해야 하는지 정할 수 있습니다. 반대로 검증 실패는 정상인데 예측 분포가 바뀌었다면 입력 분포, 모델 버전, 임계값을 봐야 합니다.
API 오류와 검증 실패를 함께 보는 이유는 원인 범위를 좁히기 위해서입니다. 오류가 늘었지만 검증 실패가 늘지 않았다면 서버 내부나 의존성 문제일 수 있습니다. 검증 실패만 늘었다면 클라이언트 페이로드(client payload) 또는 스키마 변경 가능성이 큽니다.
4-1-4. 모델 버전 또는 임계값 설정 오류¶
AI 서비스는 코드만 배포되는 것이 아니라 model_version, 특성 묶음(feature set), 예측 클래스 기준, threshold도 함께 바뀝니다. 설정값이 의도와 다르면 같은 score에서도 prediction이 달라집니다.
모델 버전 오류는 이전 모델이 계속 응답하거나 검증되지 않은 모델이 배포되는 상황입니다. 임계값 설정 오류는 점수를 클래스로 바꾸는 기준이 의도와 다른 상황입니다. 둘 다 API는 정상 응답을 반환할 수 있기 때문에 상태 확인(health check)만으로는 발견하기 어렵습니다.
| 확인 항목 | 잘못됐을 때의 증상 |
|---|---|
model_version |
이전 모델 또는 검증되지 않은 모델이 응답 |
threshold |
high_risk/low_risk 비율의 급격한 변화 |
| 예측 클래스 기준 | 점수 해석과 예측 값이 뒤집힐 가능 |
| 입력 스키마 | 특성 누락으로 검증 실패 또는 점수 변화가 발생 |
QA는 배포 직후 /health, /predict, 로그 샘플을 모두 확인해야 합니다. /health에서 model_version을 확인하고, /predict에서 threshold와 prediction을 확인하며, 로그에서 같은 값이 기록되는지 봅니다.
흔한 실패는 설정 파일과 실행 환경의 값이 다른 경우입니다. configs/operations/serving.yaml에는 임계값이 0.5인데 Kubernetes ConfigMap이나 환경 변수에서 0.7로 덮어쓰면 실제 운영 기준은 0.7입니다. QA는 문서나 파일 값이 아니라 실행 중인 값으로 판단해야 합니다.
4-1-5. 데이터 드리프트와 모델 드리프트¶
드리프트는 운영 환경에서 데이터나 모델 품질이 시간이 지나며 변하는 현상입니다. 이 절에서는 드리프트를 직접 판정하기보다 드리프트를 감지할 수 있는 관측 필드를 준비합니다.
데이터 드리프트는 입력 특성 분포가 학습과 평가 때와 달라지는 상황입니다. 모델 드리프트는 모델의 예측 품질이 시간이 지나며 낮아지는 상황입니다. 운영 중에는 라벨(label)을 즉시 알 수 없는 경우가 많기 때문에, 점수와 예측 분포를 먼저 관측하고 원인 후보를 좁힙니다.
| 운영 관측 필드 | 이후 판단에서의 활용 |
|---|---|
score |
점수 분포 변화 확인 |
prediction |
예측 분포 변화 확인 |
validation_failure |
입력 품질 변화 확인 |
model_version, threshold |
설정 변경과 품질 변화 분리 |
드리프트를 볼 때 가장 위험한 해석은 “예측 비율이 바뀌었으니 모델 자체 문제다”라고 단정하는 것입니다. 예측 비율 변화는 입력 분포 변화, 임계값 변경, 모델 버전 변경, 클라이언트 페이로드(client payload) 변경으로도 발생할 수 있습니다. 그래서 로그와 메트릭(metric)을 제대로 남기는 것이 이후 원인 분석으로 이어집니다.