1-2. 데이터, 모델, 운영 품질의 연결¶
데이터, 모델, 운영 품질은 하나의 판단 흐름으로 이어집니다. 1-2에서는 데이터 상태가 모델 출력에 영향을 주고, 모델 출력이 운영 기준을 지나 예측(prediction)이 되는 기본 구조를 확인합니다.
여기서 점수(score)는 모델이 입력 데이터를 보고 만든 Positive class 가능성 값이고, 임계값(threshold)은 그 점수를 최종 예측으로 바꾸는 기준입니다. 1-2에서는 이 두 값을 분리해서 보는 이유를 먼저 이해합니다.
이 문서를 읽을 때는 다음 연결을 중심으로 확인합니다.
- 데이터 조건: 특성(feature), 라벨(label), 관심 클래스 표본 수(Positive support)가 평가 전제에 미치는 영향
- 점수와 임계값: 모델 출력과 운영 기준의 기본 구분
- 운영 신호: 데이터와 모델 출력 변화가 운영 기록에 남는 방식
- QA 흐름: 데이터, 모델, API, 로그를 하나의 원인 후보 분석으로 연결
1-2-1. 데이터 품질이 모델 판단에 미치는 영향¶
데이터 품질은 모델이 점수를 만들기 전에 확인해야 하는 입력 조건입니다. 같은 모델을 사용하더라도 입력 특성이 깨져 있거나 라벨 기준이 흔들리면, 모델 평가는 신뢰하기 어렵습니다. 데이터 품질은 모델 평가를 시작하기 전의 준비 작업이 아니라, 모델 품질 판단의 일부입니다.
실습 예제는 Kaggle의 Human Vital Sign Dataset을 실습용 스키마(schema)로 가공하여 사용합니다. high_risk는 생체신호 예제에서 관심 있게 찾는 클래스(class)이고, low_risk는 비교 기준이 되는 클래스입니다. 모델 평가 문맥에서는 관심 있게 찾는 클래스를 관심 클래스(Positive class)라고 부르며, 다른 도메인에서는 fraud, defect, delayed, churn 같은 값이 관심 클래스가 될 수 있습니다.
데이터 문제는 서로 다른 경로로 모델 판단에 영향을 줍니다. 특성 문제는 모델 입력을 흔들고, 라벨 문제는 정답 기준을 흔들며, 클래스 불균형은 평가 결과를 해석하기 어렵게 만듭니다. 여기서 관심 클래스 표본 수는 평가 데이터 안에 high_risk 샘플(sample)이 얼마나 있는지를 뜻합니다. 이 값은 2장에서 support라는 이름으로 다시 사용합니다.
| 데이터 문제 | 모델 평가에서 흔들리는 지점 | 관측 가능한 신호 | QA 확인 |
|---|---|---|---|
| 특성 결측치 증가 | 모델 입력 정보 부족 | 예측 실패 또는 특정 클래스 증가 | 결측 비율, 필수 컬럼, 전처리 기본값 |
| 특성 이상치 증가 | 점수 분포 왜곡 | 점수 분포(score distribution) 이동, 예측 분포 변화 | 범위 규칙, 이상치 row, 입력 수집 경로 |
| 라벨 값 표준화 오류 | 학습/평가 정답 기준 왜곡 | 평가 결과를 믿기 어려움 | 원본 라벨, 라벨 값 표준화 규칙, 클래스 건수 |
| 관심 클래스 표본 수 부족 | 관심 클래스 평가 근거 부족 | 작은 표본 때문에 결과가 크게 흔들림 | high_risk 건수, 클래스 불균형(class imbalance) |
| 운영 입력 분포 변화 | 학습 때 본 패턴과 운영 입력의 차이 | 예측 비율 변화 | 특성 히스토그램(feature histogram), 출처(source), timestamp |
숫자 타입이 맞아도 의미상 불가능한 값은 모델 점수를 왜곡할 수 있습니다. 예를 들어 산소포화도(oxygen saturation)를 담는 oxygen_saturation 값이 135처럼 불가능한 범위로 들어왔다고 하겠습니다. API는 이 값을 숫자로 받을 수 있으므로 기술적으로는 처리할 수도 있습니다. 그러나 모델 입장에서는 학습 때 거의 보지 못한 값이 들어온 것입니다. 이 값이 전처리 없이 점수 계산에 사용되면 특정 클래스로 과도하게 기울어진 점수가 나올 수 있습니다.
라벨 품질은 또 다른 방식으로 모델 판단을 흔듭니다. 특성 오류는 모델 입력을 흔들지만, 라벨 오류는 정답 기준을 흔듭니다. 모델이 올바른 패턴을 학습했더라도 라벨이 잘못되어 있으면 평가 지표(metric)는 낮게 나올 수 있습니다. 반대로 잘못된 모델이 우연히 잘못된 라벨과 맞아떨어져 지표가 좋아 보일 수도 있습니다.
따라서 데이터 품질을 확인할 때는 “데이터가 깨끗한가”보다 “이 데이터로 모델 평가를 해석할 수 있는가”를 물어야 합니다. 결측치, 이상치, 라벨 오류, 클래스 불균형은 단순 데이터 오류가 아니라 점수, 예측, 지표 해석의 전제 조건입니다. 1장에서는 전제 조건을 확인하고, 2장에서 실제 지표를 계산합니다.
1-2-2. 모델 점수와 임계값의 역할¶
AI 예측은 모델이 만든 점수와 운영 기준인 임계값이 함께 결정합니다. 분류 모델(classification model)은 입력 샘플을 미리 정해진 클래스 중 하나로 나누는 모델입니다. 예를 들어 생체신호 기반 위험 알림 예제에서는 각 샘플을 high_risk 또는 low_risk 중 하나로 분류합니다.
이번 실습에서 다루는 모델은 두 개의 클래스만 구분하는 이진 분류 모델(binary classification model)입니다. 이진 분류에서는 보통 관심 있게 찾는 클래스를 Positive class, 비교 기준이 되는 클래스를 Negative class라고 부릅니다. 이 실습에서는 high_risk가 Positive class이고 low_risk가 Negative class입니다.
이진 분류 모델은 보통 최종 클래스를 바로 반환하지 않습니다. 먼저 Positive class에 속할 가능성을 점수로 계산하고, 이후 임계값을 적용해 최종 예측을 만듭니다.
입력 데이터
→ 모델 점수 생성
→ 임계값 적용
→ 최종 예측 생성
→ 응답과 로그에 기록
같은 점수라도 임계값이 달라지면 최종 예측은 달라집니다. 예를 들어 모델이 특정 샘플에 대해 risk_score = 0.72를 출력했다고 하겠습니다. 임계값이 0.50이면 이 샘플은 high_risk가 되고, 임계값이 0.80이면 같은 점수라도 low_risk가 됩니다.
| 점수 | 임계값 | 최종 예측 | QA 해석 |
|---|---|---|---|
| 0.72 | 0.50 | high_risk |
점수가 기준보다 높아 Positive class로 분류 |
| 0.72 | 0.80 | low_risk |
같은 점수지만 기준이 높아 Negative class로 분류 |
high_risk 예측 비율이 늘었다면, 이것은 원인이 아니라 관측된 결과입니다. 이 결과를 설명하려면 먼저 임계값이 바뀌었는지, 그 다음 점수 분포가 바뀌었는지 확인합니다.
| 확인할 값 | 확인 질문 | 달라졌다면 먼저 볼 것 |
|---|---|---|
| 임계값 | high_risk로 바꾸는 기준이 달라졌는가? |
설정 파일, 환경 변수, 배포 기록 |
| 점수 분포 | 모델이 내는 점수가 전반적으로 달라졌는가? | 입력 특성 분포, 모델 버전(model_version) |
여기서는 운영 로그를 직접 분석하지 않고, 공통 운영 시나리오의 high_risk_prediction_shift 관측값으로 판단 순서만 연습합니다. 이 시나리오에서는 예측 비율이 0.2167에서 0.4583로 늘고, 평균 점수도 0.5020에서 0.6402로 상승합니다. 임계값이 0.50에서 0.30으로 낮아졌다면 운영 기준 변경을 먼저 확인해야 하지만, 이후 서빙과 운영 관측 실습에서 확인할 로그의 threshold가 0.5로 유지된다면 점수 분포를 움직인 입력 데이터나 모델 버전을 먼저 확인합니다.
임계값의 방향은 아래처럼 읽을 수 있습니다. 1장에서는 예측 비율이 어느 방향으로 움직이는지만 확인하고, 오류 유형과 모델 지표는 2장에서 라벨과 비교해 계산합니다.
| 임계값 변화 | 바로 나타날 수 있는 변화 | 1장에서 확인할 기록 |
|---|---|---|
| 낮아짐 | high_risk 예측 증가 가능 |
threshold 설정값, 배포 기록 |
| 높아짐 | high_risk 예측 감소 가능 |
threshold 설정값, 배포 기록 |
| 그대로 | 예측 비율 변화는 점수 쪽 원인 가능 | 점수 분포, 입력 특성 분포 |
따라서 QA는 예측 비율만 보고 모델 자체 문제라고 단정하지 않아야 합니다. 예측 비율은 최종 결과이고, 그 앞에는 점수와 임계값이 있습니다. 이 둘을 분리해야 모델 출력 변화와 운영 기준 변경을 구분할 수 있습니다.
1-2-3. 운영 환경 변화가 품질에 미치는 영향¶
운영 환경에서는 정답인 라벨이 즉시 없기 때문에 간접 신호로 품질 변화를 관측합니다. 오프라인 평가(offline evaluation)는 저장된 데이터의 라벨과 예측을 비교하는 평가입니다. 그러나 운영 중인 서비스에서는 요청이 들어오는 순간 정답인 라벨이 항상 존재하지 않습니다.
운영 품질은 로그와 지표를 통해 관측됩니다. 1장에서는 세부 대시보드 설계보다 “어떤 값이 기록되어야 나중에 원인을 확인할 수 있는가”만 잡습니다. 일반적인 오류율(error rate)뿐 아니라 점수, 임계값, 예측, 모델 버전을 함께 기록해야 품질 문제를 추적할 수 있습니다.
| 운영 신호 | 확인 의미 | 단독 해석의 한계 | 다음 확인 증거 |
|---|---|---|---|
| 점수 분포 이동 | 모델 출력 분포 변화 | 입력 변화와 모델 버전 변경을 구분해야 함 | 특성 히스토그램(feature histogram), model_version |
| 예측 분포(prediction distribution) 급변 | 특정 클래스 예측 증가 | 임계값 변경 또는 입력 분포 변화 가능 | threshold, 출처(source), timestamp |
| 오류율 증가 | API 처리 실패 증가 | 모델 판단 품질 문제와 구분 필요 | 상태 코드(status code), 오류 응답(error response) |
| 데이터 입력 오류 증가 | 요청 스키마 또는 입력 품질 문제 | 모델 지표 저하와 직접 동일하지 않음 | 실패 필드(field), request_id, client payload |
간접 신호는 원인을 바로 알려주지 않습니다. 예측 비율이 바뀌었다는 사실은 입력 데이터가 바뀌었을 수도 있고, 임계값이 바뀌었을 수도 있고, 모델 버전이 바뀌었을 수도 있다는 뜻입니다. 오류율이 늘었다는 사실도 모델 지표 저하가 아니라 API 계약(API contract) 위반 증가일 수 있습니다.
AI 서비스에서 로그와 지표를 설계할 때는 나중에 어떤 질문에 답해야 하는지를 먼저 생각해야 합니다. “어떤 모델이 응답했는가”, “어떤 임계값이 적용되었는가”, “점수가 어느 범위였는가”, “입력 검증 실패가 있었는가”, “응답 시간이 길었는가” 같은 질문에 답할 수 있어야 운영 품질 문제를 추적할 수 있습니다.
운영 신호는 원인 후보를 좁히는 출발점입니다. 점수 평균이 증가했는데 임계값이 같다면 입력 특성 분포 변화나 모델 버전 변경을 먼저 봅니다. 점수 평균은 비슷한데 임계값만 낮아졌다면 설정 파일, 환경 변수, 배포 기록을 먼저 확인합니다. 1장에서는 이 구분을 개념으로만 잡고, 4장에서 로그와 대시보드로 확장합니다.
1-2-4. AI QA의 기본 확인 흐름¶
AI QA의 기본 흐름은 데이터에서 시작해 모델 출력과 운영 관측으로 이어집니다. 데이터 품질 저하는 모델 점수 분포를 바꾸고, 점수 분포 변화는 같은 임계값에서도 최종 예측을 바꿀 수 있습니다. 1장에서는 여기까지의 연결을 이해하고, 예측이 맞았는지 틀렸는지는 2장에서 라벨과 비교합니다.
데이터 품질 저하
→ 모델 점수 분포 변화
→ 임계값 기준의 최종 예측 변화
→ 라벨과 비교할 준비
→ 2장에서 모델 지표 계산
→ 운영 품질 확인으로 확장
이 흐름은 순서대로 한 번만 실행하는 체크리스트가 아닙니다. 실제 품질 분석에서는 앞뒤로 오가며 확인합니다. 예측 분포가 갑자기 바뀌었다면 임계값, 모델 버전, 입력 특성 분포를 다시 확인해야 합니다.
1-2에서 가져갈 확인 흐름은 다음과 같습니다. 이 표는 이후 장에서 실습과 도구로 확장될 기본 순서입니다.
| 단계 | 확인 내용 | 이후 연결 |
|---|---|---|
| 1 | 데이터 구조와 필수 컬럼 확인 | 1장 데이터 품질 확인 |
| 2 | 결측치, 이상치, 라벨 오류 확인 | 1장/2장 검증 리포트 |
| 3 | 관심 클래스 표본 수와 클래스 불균형 확인 | 2장 모델 지표 해석 |
| 4 | 점수와 임계값 기준 확인 | 2장/3장 평가와 서빙 |
| 5 | 모델 지표 계산과 오류 유형 확인 | 2장 모델 품질 평가 |
| 6 | 운영 로그와 예측 분포 확인 | 4장 운영 관측 |
| 7 | 데이터, 모델, 운영 중 원인 후보 정리 | 5장 QA 판단 기준 |
초기 실무자에게 가장 중요한 습관은 하나의 숫자만 보고 결론을 내리지 않는 것입니다. 데이터 품질 결과, 모델 지표, API 응답, 운영 로그가 서로 같은 방향을 가리킬 때 품질 판단의 신뢰도가 올라갑니다.
1-2의 핵심은 데이터, 모델, 운영이 분리된 주제가 아니라는 점입니다. 데이터는 점수를 만들고, 점수는 임계값을 지나 예측이 되며, 예측은 운영 로그와 대시보드(dashboard)에 남습니다. 이 연결을 이해해야 이후 실습에서 나오는 코드와 산출물을 단순 실행 결과가 아니라 품질 근거로 읽을 수 있습니다.