운영 중 품질을 흔드는 요인¶
이 페이지는 4장 본편의 선택 읽기입니다. 5교시 본편에서 신호 종류, 도구와 비교 조건을 정한 뒤, 6교시 본편에서 대표 요청을 고를 때 입력, API, 지연과 모델 정보 가운데 어떤 원인 후보를 더 확인할지 판단하는 데 사용합니다. 최종 승인과 보류 판단 자체는 이 페이지의 범위가 아닙니다.
기존 운영 모델의 high_risk 예측 비율 증가는 조사 시작 신호이지 원인 자체가 아닙니다. 입력 구성, API 검증, 지연 시간, 모델 정보와 임계값 가운데 하나 이상이 달라졌을 수 있으므로 운영 자료로 원인 후보를 차례로 좁혀야 합니다.
운영 중에는 정답을 바로 얻기 어렵기 때문에 모델 품질 지표를 새로 계산할 수 없습니다. 이 페이지에서는 어떤 변화가 어떤 관측값으로 나타나는지, 다음에 어느 담당 팀이 무엇을 확인해야 하는지를 설명합니다.
원인 후보를 다루는 원칙
- 관측값은 원인 후보를 강화하거나 약화할 뿐, 한 번에 원인을 확정하지 않습니다.
- 입력 변화, API 오류와 실행 모델 불일치는 서로 다른 자료와 담당 범위를 가집니다.
- 정답이 없으면 모델 드리프트와 새로운 재현율과 정밀도를 계산하지 않습니다.
입력 데이터 이상과 요청 구성 변화¶
입력 데이터 이상은 특성이 빠지거나 자료형이 달라지는 명시적 오류와, 형식은 맞지만 값의 분포가 달라지는 변화를 모두 포함합니다. 명시적 오류는 HTTP 422와 missing|extra|type|other로 제한한 검증 분류에서 확인하고, 분포 변화는 정상 응답 뒤의 집계 신호에서 살펴봅니다.
기준 상태와 다른 연령, 심박수, 젖산, GCS 조합이 더 많이 들어오면 같은 모델에서도 점수와 예측 비율이 달라질 수 있습니다. 이때 예측 비율 증가는 모델이 바뀌었다는 증거가 아니라 입력 구성이 달라졌을 가능성을 강화합니다.
입력 분포를 비교할 때는 모델 버전과 시간대를 고정합니다. 서로 다른 모델이나 서로 다른 요청 시나리오를 한 그래프에 섞으면 입력 변화와 모델 변화를 구분할 수 없습니다.
입력 변화가 보이면 다음 순서로 해석합니다.
- 모델, 임계값과 시간대가 같은지 확인합니다.
- 422인지, 형식은 맞지만 분포가 달라진 정상 요청인지 나눕니다.
- 대표 요청과 원본 및 변환 과정을 확인할 데이터 또는 서빙 담당자를 정합니다.
관측값은 일부 원인 후보를 강화할 뿐, 아직 확인하지 않은 결론까지 확정하지 않습니다.
| 관측값 | 먼저 확인할 자료 | 강화되는 원인 후보 | 아직 모르는 것 |
|---|---|---|---|
| 422 증가 | 상태 코드별 요청 수, 오류 코드와 제한된 검증 분류 | 입력 누락, 추가, 자료형 범주 | 민감한 원본 입력과 모델 성능 저하 |
| 빠진 특성 수 P95 증가 | 누락 특성 히스토그램, 대표 요청 | 입력 생성 또는 전송 과정 변화 | 원본 데이터의 결측 원인 |
| 점수 P95와 예측 비율 동시 변화 | 같은 모델, 시간대의 점수와 예측 분포 | 입력 구성 또는 임계값 변화 | 정답 기준 정밀도, 재현율 변화 |
| 특정 시나리오에서만 변화 | 시나리오별 지표와 로그 | 해당 입력 시나리오의 영향 | 전체 사용자 요청의 동일한 변화 |
입력 변화를 확인해도 행을 자동 삭제하거나 모델을 곧바로 교체하지 않습니다. 데이터 팀은 원본과 변환 과정을, 서빙 팀은 API 입력 규약을 확인하고, 품질 검토자는 같은 범위의 정답을 확보할 수 있을 때 별도 평가를 요청합니다.
지연 시간과 API 오류¶
지연 시간 증가는 모델 계산, 외부 의존 서비스, CPU, 메모리 부족, 트래픽 증가 등 여러 원인에서 생길 수 있습니다. P95 지연 시간은 느린 요청이 늘었는지 보여 주지만 어느 구성 요소가 느린지는 알려 주지 않습니다.
HTTP 422와 5xx는 원인과 대응이 다릅니다. 422는 입력이 공개 API 규약을 통과하지 못했다는 뜻이고, 5xx는 서버가 정상 요청을 처리하는 과정에서 실패했다는 뜻입니다. 두 값을 하나의 오류율로 합치면 입력 문제와 서비스 장애의 담당자를 잘못 지정할 수 있습니다.
조사는 지표에서 시간대를 고른 뒤 로그와 추적 기록으로 요청 하나를 좁혀 가는 순서가 효율적입니다.
- 422는 입력 검증 실패이므로 입력과 API 규약을 먼저 봅니다.
- 5xx는 정상 요청 처리 실패이므로 오류 로그, 추적 기록, 준비 상태를 봅니다.
- P95 지연 시간은 느린 요청 증가 신호이므로 경로별 시간, 자원, 의존 서비스를 봅니다.
각 신호는 확인 책임이 있는 팀의 다음 행동으로 이어져야 합니다.
| 신호 | 가능한 원인 | 다음 확인 | 담당 팀 |
|---|---|---|---|
| P95 지연 시간 증가 | 트래픽 증가, 모델 계산, 의존 서비스, 자원 부족 | 경로별 추적 시간, Pod 자원과 이벤트 | 서빙, 플랫폼 |
| 422 증가 | 누락, 추가, 자료형 오류 범주 | validation_category와 대표 요청 |
데이터, 서빙 |
| 5xx 증가 | 애플리케이션 예외, KServe 실패, 설정, 모델 파일 문제 | 오류 로그, 추적 기록, 준비 상태 | 서빙, 플랫폼 |
| 준비 상태 실패 | 모델 패키지, 예상 해시값, 설정, 자원 문제 | 시작 로그, 이벤트, 배포 선언 | 서빙, 플랫폼 |
지연과 오류가 늘어도 공식 평가 수치 자체가 바뀐 것은 아닙니다. 다만 운영 추가 확인이 필요한 신호이므로 확인한 범위, 담당 팀과 다음 자료를 기록하고, 최종 승인과 보류 판단은 5장 본편의 기준에서 따로 작성합니다.
모델 버전과 임계값 불일치¶
모델 정보 불일치는 2장에서 승인한 결과를 실행 중인 서비스에 적용할 수 없게 만듭니다. API의 프로필, 버전, 임계값, 배포 선언의 모델 SHA-256과 PVC 경로가 같은 릴리스를 가리켜야 합니다.
임계값이 달라지면 모델 점수가 같아도 최종 예측 비율이 달라질 수 있습니다. 따라서 예측 비율 증가를 볼 때 모델 파일뿐 아니라 임계값도 함께 확인합니다. 프로필 이름 하나만 맞는 것으로는 충분하지 않습니다.
배포 선언과 API 정보가 다르면 운영 환경의 불일치가 확인된 것입니다. 이 사실은 Candidate B의 공식 평가가 틀렸다는 뜻이 아니라, 승인한 모델과 다른 실행 상태가 관측됐다는 뜻입니다.
불일치는 다음 순서로 대조합니다.
- 공식 릴리스와 오버레이의
profile, 모델 SHA-256, 고정 경로를 비교합니다. - 오버레이와 대상 API의
profile,version,threshold를 비교합니다. - API 정보와 운영 기록이 같은 시간대를 가리키는지 확인합니다.
비교 기준이 달라지면 생기는 위험과 다음 조치도 달라집니다.
| 비교 대상 | 일치해야 할 값 | 불일치가 뜻하는 위험 | 다음 조치 |
|---|---|---|---|
| 공식 릴리스와 오버레이 | 프로필, 모델 SHA-256, 고정 경로 | 승인하지 않은 모델 패키지를 선언할 위험 | 모델, 플랫폼 팀이 선언 수정 |
| 오버레이와 API | 프로필, 버전, 임계값 | 선언과 다른 실행 상태 | GitOps, 서빙 연결 확인 |
| API와 운영 기록 | 모델 정보, 시간대 | 다른 모델의 지표를 현재 모델로 해석할 위험 | 조회 범위를 다시 선택 |
| Candidate B와 되돌리기 설정 | 서로 다른 고정 경로 | 복구 대상이 불명확해질 위험 | 모델과 플랫폼 팀이 고정 경로와 실행 기록 대조 |
실행 모델 정보가 일치하지 않으면 target_verified를 사용할 수 없고,
rollback_required 여부도 이 페이지에서 임의로 정하지 않습니다. 불일치를
뒷받침한 자료와 아직 확인하지 못한 환경과 시간대를 분리해 적고, 일치하는 모델
정보와 새 시간대의 운영 기록을 확보한 뒤 판단을 갱신합니다.
데이터 드리프트와 모델 드리프트¶
데이터 드리프트(data drift)는 운영 입력의 분포가 기준 분포와 달라지는 현상입니다. 모델 드리프트(model drift)는 같은 평가 기준에서 모델의 정답 기준 품질이 시간이 지나며 달라지는 현상을 가리킵니다. 두 현상은 관련될 수 있지만 같은 뜻은 아닙니다.
운영 요청에 정답이 없으면 입력 분포와 점수, 예측 분포의 변화는 확인할 수 있어도 모델 드리프트는 확정하기 어렵습니다. 정답을 나중에 확보하고 같은 범위에서 정밀도, 재현율과 오류 유형을 다시 계산해야 모델 품질 변화 여부를 판단할 수 있습니다.
예측 비율 변화는 입력 드리프트, 임계값 변화, 모델 버전 불일치, 요청 시나리오 변화가 모두 만들 수 있습니다. 따라서 “예측 비율이 늘었으므로 모델 드리프트다”라는 문장은 근거 범위를 넘습니다.
드리프트를 기록할 때는 다음 구분을 유지합니다.
- 입력, 점수와 예측 분포 변화: 운영 자료로 확인할 수 있는 신호
- 모델 드리프트: 같은 기준의 정답을 확보해 재평가한 뒤에만 판단할 수 있는 품질 변화
- 원인 조사: 여러 근거를 모아 강화되거나 약화되는 후보를 기록하는 단계
조사 단계마다 필요한 자료와 끝까지 남는 한계를 구분합니다.
| 확인 단계 | 필요한 자료 | 가능한 판단 | 남은 한계 |
|---|---|---|---|
| 입력 분포 비교 | 같은 특성 정의와 기준, 현재 시간대 | 데이터 드리프트 신호가 있는가 | 품질 지표에 미친 영향 |
| 점수, 예측 분포 비교 | 같은 모델 정보와 임계값 | 모델 출력 구성이 달라졌는가 | 정답 기준 오류 변화 |
| 정답 확보 후 재평가 | 같은 데이터 규약과 평가 기준 | 정밀도, 재현율, FP/FN이 달라졌는가 | 변화의 단일 원인 |
| 원인 조사 | 데이터, 모델, 서빙, 운영 근거 | 어떤 후보가 강화, 약화되는가 | 추가 실험이 필요한 후보 |
보고서에는 관측한 드리프트 신호와 모델 품질 변화 판단을 분리합니다. 현재 정답이 없다면 데이터와 운영 담당자가 동일 범위의 입력과 정답을 확보하도록 요청하고, 모델 승인 결과는 새 평가가 나오기 전까지 기존 범위에 한정해 유지합니다.