P3-9.9 실제 목표와 대리 타깃은 어떻게 구분하는가¶
Section ID:
P3-9.9Version:v2026.09.20
P3-9.8에서 모델 점수와 검토 배정 정책을 나누었습니다. 그런데 그 모델이 잘 맞히는 값이 정말 알고 싶은 결과와 같은지도 확인해야 합니다. 고장을 줄이고 싶어 만든 모델이라도 학습의 정답이 검토 요청이라면, 직접 배우는 대상은 고장 자체가 아니라 검토 요청입니다. 이처럼 원하는 결과를 대신해서 쓰는 열을 대리 타깃이라고 합니다.
고장 감소·고장 예측·검토 요청을 나눈다¶
| 구분 | 이번 사례의 질문 | 확인에 필요한 기록 |
|---|---|---|
| 궁극적 목적 | 운영 중 고장을 줄이고 싶다 | 실제 고장과 운영 조건, 조치 및 비교 근거 |
| 직접 알고 싶은 예측 대상 | 예측 시점 이후 7일 안에 고장이 생기는가? | 기간이 명시된 고장·정비 기록 |
| 현재 관측 가능한 대리값 | 담당자가 추가 검토를 요청했는가? | 요청 여부·담당자·시각·판정 기준 |
“고장을 줄인다”는 성과 목표이고, failure_within_7d는 맞히려는 결과 열입니다. review_requested는 사람이 남긴 중간 판단입니다. 요청이 있었다고 고장이 확정된 것도 아니고, 요청이 없었다고 고장이 없었던 것도 아닙니다. 이 세 질문을 한 이름으로 묶으면 모델이 무엇을 잘했는지 알기 어렵습니다.
같은 세 대상을 결과가 도착한 뒤 다시 본다¶
다음은 이 절 안에서만 사용하는 가상 장비 A·B·C입니다. 각 샘플은 장비 한 대의 2026-09-01 10:00 KST 상태이고 입력은 그때 사용 가능했던 정보로 제한합니다. 같은 날 10:20에 기록된 검토 요청을 대리 라벨로 쓰려는 상황입니다. review_requested=1은 요청 있음, 0은 담당자가 이번 판정을 완료하고 요청하지 않기로 기록한 경우입니다. 기록 누락이나 미검토는 0으로 채우지 않습니다.
원래 알고 싶은 결과는 P3-9.7의 failure-v1 정의를 따릅니다. 장비 자체의 이상으로 예정 동작을 완료하지 못하고 원인이 정비 기록에서 확인된 고장을 대상으로 하며 계획 정지는 제외합니다. 결과 기간은 9월 1일 10:00 이상, 9월 8일 10:00 미만입니다. 처음에는 세 대상 모두 이 기간의 결과가 미확인입니다.
| 장비 | 9월 1일 10:20의 review_requested | 나중에 확인한 failure_within_7d | 확인된 경과 |
|---|---|---|---|
| A | 1 | 0 | 9월 1일 10:30 설정 조정. 전체 기간을 추적해 고장 없음 확인 |
| B | 0 | 1 | 별도 조치 없음. 9월 4일 고장 발생, 정비로 확인 |
| C | 1 | 1 | 별도 조치 없음. 9월 5일 고장 발생, 정비로 확인 |
뒤의 결과 열은 9월 8일 11:00에 연결했다고 가정하며, 이 교육용 표에서는 세 장비의 관측과 확인에 누락이 없다고 둡니다. 요청받은 A·C만 추적했다면 요청이 없던 B의 고장을 놓쳤을 것입니다. 대리값의 적절성을 보려면 요청 여부가 다른 대상들의 후속 결과도 확인해야 합니다.
A는 요청이 있었지만 관측된 고장은 없고, B는 요청이 없었지만 고장이 있습니다. A의 0만 보고 요청이 불필요했다고 단정할 수도 없습니다. 조정하지 않았을 때의 결과는 이 표에 없으므로, 조정이 고장을 막았는지도 이 사례만으로는 알 수 없습니다. 관측 결과와 조치 효과를 구분하는 이유는 P3-8.7과 같습니다.
대리값을 모두 맞혀도 고장을 모두 맞힌 것은 아니다¶
어떤 가상 모델이 요청 라벨 1·0·1을 세 건 모두 맞혔다고 가정합시다. 요청에 대한 정답률은 3 / 3 = 100%입니다. 그런데 그 출력값을 그대로 고장 예측이라고 이름만 바꾸면, 실제 결과 0·1·1과 일치하는 것은 C 한 건뿐이므로 1 / 3 ≈ 33.3%입니다.
이는 세 행으로 만든 반례이지 모델 성능 추정이나 일반적인 비율이 아닙니다. 같은 출력도 무엇을 정답으로 삼는지에 따라 평가의 뜻이 달라진다는 점을 보여 줍니다. 더구나 고장을 정확히 예측하는 것과 조치를 통해 고장을 줄이는 성과도 다르므로, 요청 예측 점수만으로 고장 감소를 입증할 수 없습니다.
검토 요청 자체가 업무량 예측이나 담당자 배정의 직접 목적이라면 review_requested는 그 문제의 정식 타깃이 될 수 있습니다. 고장을 대신해서 쓰고 있을 때 대리 타깃이라고 부르는 것입니다. 값이 빨리 도착한다는 이유만으로 적절한 대리값이 되는 것은 아닙니다.
관측 가능한 대리값과 실제 목표 연결하기¶
flowchart TD
A["궁극적 목적: 고장 감소"]
B["직접 알고 싶은 결과: 7일 내 고장"]
C["현재 대리값: 검토 요청"]
D["현재 모델: 요청 라벨 예측"]
E["양쪽 요청 집단의 후속 고장·조치 기록"]
F["요청과 고장 불일치 및 관측 조건 확인"]
G["고장 감소 성과는 별도 비교 근거로 확인"]
A --> B
C --> D
B --> E
C --> F
E --> F
A --> G
E --> G
도식의 연결은 질문과 확인 자료의 관계이며, 요청이 고장을 일으킨다는 인과관계가 아닙니다. 후속 결과가 도착하면 원래 요청 라벨을 덮어쓰지 않고 장비 ID와 예측 시점을 기준으로 별도의 고장 결과 열을 연결합니다. 요청 판단의 기준과 실제 고장의 정의도 각각 보존합니다.
“대리값의 한계”를 확인할 기록으로 바꾼다¶
| 인계 메모 | 이 사례에서 적을 내용 |
|---|---|
business_goal | 운영 중 고장 감소 |
| 직접 예측하려는 결과 | failure_within_7d, failure-v1, 시작 포함·끝 제외의 7일 |
proxy_target와 proxy_reason | review_requested; 요청 기록은 먼저 있고 고장 결과는 아직 미확인 |
proxy_gap | A는 요청 1·고장 0, B는 요청 0·고장 1. 요청 기준과 조치가 관계에 영향을 줄 수 있음 |
| 추가 확인할 기록 | 요청 있음·없음 양쪽의 고장·정비 기록, 관측 완료 여부, 조치 종류와 시각, 요청 기준 버전 |
review_owner | 요청 기준과 후속 결과를 대조할 담당자 지정. 실제 인계 때 이름·역할 기입 |
입력의 하강률이 어떤 기준을 넘으면 1이라는 규칙으로 라벨을 만들었다면, 그 입력에서 라벨을 맞히는 모델은 우선 그 규칙을 재현하는 셈입니다. 규칙을 직접 적용할 수 있는지도 먼저 살펴야 합니다. 규칙 재현 점수가 높아도 독립적인 고장 기록을 확인하지 않았다면 고장 예측의 근거가 되지 않습니다.
연습: 요청 0인 B의 후속 고장 기록이 아직 도착하지 않았다면 고장 결과를 0으로 채워도 될까요? 모델이 요청을 모두 맞혔다는 이유로 “고장을 모두 예측했다”고 보고해도 될까요?
해설: B의 고장 결과는 미확인으로 남깁니다. 요청 0은 고장 0을 대신하지 않습니다. 현재 보고할 수 있는 것은 요청 라벨을 얼마나 맞혔는지이며, 고장 예측을 평가하려면 요청 여부와 별개로 확인한 후속 결과가 필요합니다. 늦게 도착하는 결과와 관측 미완료 상태는 P3-9.10에서 이어집니다.
체크리스트¶
- 궁극적 목적, 직접 예측하려는 결과, 현재 학습하는 대리 열을 각각 적을 수 있는가?
- 같은 1·0·1이 요청에는 3/3, 고장에는 1/3만 일치하는 이유를 설명할 수 있는가?
- 대리값을 점검할 후속 결과와 조치 기록을 정하고, 결과 미확인을 0으로 바꾸지 않을 수 있는가?
출처와 참고 자료¶
- Google, Machine Learning Glossary,
label,derived label,proxy labels. 지도학습의 라벨이 예시의 답 또는 결과 부분이며, 실제 라벨이 없을 때 proxy label을 신중하게 골라야 한다는 용어 기준을 확인하는 데 참고했습니다. https://developers.google.com/machine-learning/glossary / 확인일: 2026-07-20