P3-6.4 요약 표의 모든 열이 왜 특징은 아닌가¶
Section ID:
P3-6.4Version:v2026.09.19
요약 표에는 비교값, 입력 후보, 결과, 식별·문맥 정보가 함께 들어갑니다. 열의 이름이나 숫자 형식만으로 모델 입력 여부를 결정할 수는 없습니다. 무엇을 언제 예측하는지 정한 뒤, 그때 실제로 얻을 수 있는 값인지 확인해야 합니다. 한 열이 비교값이면서 입력 후보일 수도 있습니다.
동작 종료 시점에 다음 7일을 예측한다¶
자체 가상 사례에서 동작 종료 직후 다음 7일 안에 고장 기록이 생길지를 예측한다고 하겠습니다. 현재 동작의 센서 집계는 종료 시점에 완료되고, 기준선은 그 이전 동작만 사용해 미리 계산되어 있다고 가정합니다. 현재 평균을 나중에 다시 계산하는 상황이라면 이 가용성 가정부터 다시 확인해야 합니다.
결과 열 failure_within_7d는 종료 뒤 7일 이내(종료 시점 제외, 7일째까지 포함)에 고장 기록이 하나라도 있으면 1입니다. 7일 추적을 마쳤고 기록이 없을 때만 0입니다. 아래 A·B는 추적 완료 후 결과를 붙인 학습용 표이며, 실제 예측 시점에는 결과 열을 모릅니다.
| event_id | mid_flow_mean | baseline_mid_flow_mean | delta_from_baseline | failure_within_7d |
|---|---|---|---|---|
| A | 2.40 | 3.05 | −0.65 | 1 |
| B | 2.55 | 2.60 | −0.05 | 0 |
유량 단위는 L/min입니다. A의 차이는 2.40−3.05=−0.65 L/min으로, 과거 기준보다 0.65 낮다는 뜻입니다. B는 2.55−2.60=−0.05 L/min입니다. 음수 자체가 고장 판정은 아니며, 두 행만으로 예측 규칙이나 성능을 확정할 수도 없습니다.
비교 목적과 입력 후보 여부를 따로 표시한다¶
다음 표는 위 예측 문제에 대한 판단입니다. “후보”는 입력으로 검토할 수 있다는 뜻이며 채택이나 유용성을 보증하지 않습니다. 비교 사용은 모델 학습과 별개로 보고서에서 값과 조건을 확인하는 역할입니다.
| 열·표현 | 비교에 사용 | 입력 후보 | 종료 시점에 사용 가능 |
|---|---|---|---|
| mid_flow_mean | 현재 수준 확인 | 예 | 집계 완료 가정에서 예 |
| baseline_mid_flow_mean | 과거 기준 확인 | 예 | 과거 자료로 미리 계산했다면 예 |
| delta_from_baseline | 기준 대비 차이 확인 | 예 | 두 원천 값이 모두 그때 있다면 예 |
| event_id | 원기록 연결·중복 확인 | 이 사례에서는 제외 | 예 |
| 종료 시각에서 얻은 시간대 | 시간대별 조건 비교 | 목적에 따라 후보 | 시각 기록이 즉시 있다면 예 |
| failure_within_7d | 추적 완료 후 결과 비교 | 이 예측의 입력에서 제외 | 아니오 |
event_id를 제외한 이유는 이 사례에서 단순 식별자로 쓰기 때문입니다. 식별자라는 이름만으로 모든 문제에서 영구히 금지되는 것은 아닙니다. 장비 ID처럼 반복되는 대상 정보가 의미를 갖는 경우도 있지만, 새 장비에도 적용할지와 식별자 암기 가능성을 따로 확인해야 합니다. 기록 시각도 그대로 쓰거나 시간대를 추출할 수 있으므로 “문맥 열은 입력이 될 수 없다”는 규칙은 성립하지 않습니다.
같은 차이 열도 기준선의 시점이 다르면 달라진다¶
A의 기준선 3.05가 동작 종료 이후 일주일의 자료까지 섞어 계산되었다고 바꾸어 보겠습니다. 계산 결과가 똑같이 −0.65여도 종료 시점에는 그 기준선을 만들 수 없었습니다. 이 값은 사후 비교에는 사용할 수 있지만, 종료 시점 예측 입력으로 사용하면 미래 정보를 섞게 됩니다.
반대로 기준선이 과거 자료만 사용했어도 집계 작업이 다음 날 끝났다면 종료 직후에는 사용할 수 없습니다. 원천 자료의 발생 시점과 계산 결과의 사용 가능 시점은 둘 다 확인해야 합니다. 학습용 표에서도 당시 알 수 있었던 기준선 버전을 연결해야 하며, 전체 자료로 한꺼번에 다시 만든 평균을 과거 각 행에 붙이지 않습니다.
예측 시점을 동작 시작 직전으로 바꾸면 현재 동작의 중반 평균도 아직 없습니다. 표의 이름과 값은 같아도 입력 후보 목록이 달라지는 이유입니다. 이 경우 과거 기준선은 후보로 남을 수 있지만 현재 중반 평균과 그 기준선 차이는 사용할 수 없습니다.
열 역할과 계산 근거를 함께 남긴다¶
flowchart TD
A["예측 목적과 시점"] --> B["열의 역할과 계산 근거 확인"]
B --> C{"그 시점에 사용 가능한가?"}
C -->|아니오| D["사후 비교·결과·추적용으로 보존"]
C -->|예| E["목적에 맞는 입력 후보 검토"]
delta_from_baseline에 “비교에 사용/입력 후보/그때 사용 가능”을 표시해 보세요. 과거 자료로 만든 기준선을 즉시 이용할 수 있는 첫 사례는 세 항목 모두 예입니다. 미래 자료를 넣거나 계산이 늦어진 사례는 사후 비교만 가능하고 해당 예측 시점 입력에서는 제외합니다. 비교 열이라는 이유로 입력에서 빼거나 숫자라는 이유로 넣는 것이 아닙니다.
결과를 나중에 학습용 표에 붙이는 것 자체는 문제가 아닙니다. 입력 열과 목표 열을 분리해 사용해야 합니다. 추적이 덜 끝난 B에 고장 기록이 없다는 이유로 0을 붙여도 될까요? 답은 아니오입니다. 추적 완료 여부를 별도 기록하고 미완료 결과는 보류해야 합니다.
원천 사건 ID, 기준선에 포함한 기간, 기준선 버전, 집계 완료 시각을 남기면 각 차이값이 어떻게 만들어졌는지 다시 확인할 수 있습니다. 역할은 한 개만 고르는 이름표가 아니라 사용 목적과 시점에 따른 기록입니다.
체크리스트¶
- A와 B의 기준선 차이를 단위와 함께 계산하는가?
- 비교값과 입력 후보 역할이 겹칠 수 있음을 설명하는가?
- 미래 자료 포함 여부와 집계 완료 시점을 모두 확인하는가?
- 예측을 동작 시작 전으로 옮기면 제외할 열을 고를 수 있는가?
관련 개념: 요약 표(summary table), 특징(feature).
출처와 참고 자료¶
- Google for Developers,
Machine Learning Glossary의labeled example. labeled example을 features와 label의 결합으로 설명하므로, 입력 설명 열과 결과 열 후보를 구분해야 한다는 기본 틀을 제공합니다. https://developers.google.com/machine-learning/glossary / 확인일: 2026-07-20 - Google for Developers,
Machine Learning Glossary의label leakage. feature가 label의 proxy가 되는 설계 결함을 설명하므로,failure_within_7d같은 결과 후보 열을 무심코 feature로 섞지 말아야 한다는 근거가 됩니다. https://developers.google.com/machine-learning/glossary / 확인일: 2026-07-20 - W3C,
PROV-Overview. provenance information을 별도로 기록하고 추적하는 표준 문맥을 제공하므로,event_id,captured_at같은 식별·문맥 열은 샘플을 설명하는 feature와 다른 역할의 정보로 남길 수 있다는 일반 근거로 참고할 수 있습니다. https://www.w3.org/TR/prov-overview/ / 확인일: 2026-07-20