P3-6.6 같은 열 이름과 다른 특징¶
Section ID:
P3-6.6Version:v2026.09.20
보조제목: 측정 방식이나 단위가 바뀌면 왜 같은 이름의 열도 다른 특징이 될 수 있는가
특징(feature)을 설계하다 보면 놓치기 쉬운 함정이 하나 더 있습니다. 열 이름이 같으니 같은 특징이겠지라고 생각하는 순간입니다. 하지만 현실 데이터에서는 같은 flow_mean이라는 이름 아래에서도 센서 버전이 바뀌었거나, 단위가 바뀌었거나, 계산 규칙이 달라졌을 수 있습니다. 이런 변화가 있으면 숫자는 있어도 더 이상 같은 특징이라고 보기 어렵습니다.
특징은 열 이름이 아니라, 무엇을 어떤 규칙과 단위로 측정한 값인가까지 포함해 같은 특징인지 판단해야 합니다.
같은 열 이름이 같은 특징을 뜻하지 않는 경우¶
같은 열 이름만 보고 같은 특징이라고 넘기면, 실제로는 특징 의미가 이미 달라졌는데도 같은 비교표와 같은 기준선에 올리기 쉽습니다.
| 겉으로 보이는 상태 | Part 3에서 먼저 확인할 질문 |
|---|---|
| 열 이름이 그대로다 | 계산 규칙과 단위도 그대로인가 |
| 평균값 분포가 갑자기 달라졌다 | 실제 변화인가, 측정 방식 변화인가 |
| 유지보수 이후 값이 달라졌다 | 공정 상태 변화인가, 센서 정의 변화인가 |
즉 특징 이름이 같다는 사실만으로는 같은 비교 구조가 유지된다고 말할 수 없습니다.
무엇이 바뀌면 같은 특징이 아니게 되는가¶
같은 열 이름이라도 아래 중 하나가 바뀌면, Part 3에서는 먼저 같은 특징인가를 다시 물어야 합니다.
| 바뀐 것 | 왜 중요한가 |
|---|---|
| 측정 단위 | 숫자 크기 비교 자체가 달라지기 때문 |
| 센서 위치나 센서 버전 | 같은 이름이어도 다른 물리량에 가까워질 수 있기 때문 |
| 구간 계산 규칙 | 같은 평균이라도 다른 구간을 평균 낸 것일 수 있기 때문 |
| 운영 정의 | 같은 정상 범위라도 기준이 달라졌을 수 있기 때문 |
이 네 가지는 모두 모델 기법 문제가 아니라, 지금 남긴 특징이 무엇을 뜻하는가의 문제입니다.
열 이름에서 측정 정의로 비교 기준 옮기기¶
| event_id | flow_mean | flow_unit | sensor_version | segment_rule | ops_definition |
|---|---|---|---|---|---|
| A | 2.4 | L/min | v1 | early-mid-late | normal-band-v1 |
| B | 2.5 | L/min | v1 | early-mid-late | normal-band-v1 |
| C | 41.0 | mL/s | v2 | early-mid-late | normal-band-v1 |
| D | 39.5 | mL/s | v2 | quartile-4bin | normal-band-v2 |
이 표를 보면 모두 flow_mean이라는 이름을 쓰지만 실제로는 두 가지 이상이 동시에 바뀌었습니다.
A,B와C,D는 단위가 다릅니다.C,D는 센서 버전도 다릅니다.D는 구간 계산 규칙도 다릅니다.D는 운영 정의도 달라 같은 기준선 메모로 바로 묶기 어렵습니다.
즉 이 네 행을 같은 특징 한 열로 그대로 읽으면, 숫자가 비슷한지 아닌지를 말하기 전에 특징 뜻부터 흔들리게 됩니다. 그래서 여기서 먼저 붙잡아야 할 결론은 단순합니다. 같은 열 이름은 같은 특징 정의를 보장하지 않습니다.
flowchart TD
A["원래 값·단위·정의 메모 보존"] --> B["단위 차이는 변환하고 변환식 기록"]
B --> C{"측정 대상·보정·집계 범위가 대응하는가?"}
C -->|확인됨| D["같은 물리량 비교 후보"]
C -->|미확인 또는 불일치| E["추가 자료·보정·재집계 확인"]
D --> F["운영 판정 버전은 별도로 비교"]
단위만 다르면 변환으로 비교를 회복할 수 있습니다. 41 mL/s = 41×60/1000 = 2.46 L/min이므로 C의 값이 A보다 약 17배 커진 것은 아닙니다. 다만 센서 위치·보정·계산 구간까지 같다는 뜻은 아니므로, 단위 통일 뒤에도 그 조건을 확인해야 합니다. 운영 판정 규칙만 바뀌었다면 원래 물리 특징은 같고 출력 라벨의 의미만 달라졌을 수도 있습니다.
문자열 일치와 물리적 비교 가능성을 나눈다¶
앞의 네 행은 자체 가상 자료입니다. A·B의 메모가 같아도 센서 위치·보정 이력·결측 처리까지 검증된 것은 아닙니다. early-mid-late라는 이름만으로 어느 구간의 어떤 평균인지도 충분히 알 수 없습니다. 메모 일치는 검토할 후보를 모으는 방법이지 비교 가능성을 인증하는 결과가 아닙니다.
| 확인한 수준 | 이 사례에서 알 수 있는 것 | 아직 확인할 것 |
|---|---|---|
| 선택한 정의 문자열 일치 | A·B의 기록된 필드가 같음 | 생략된 측정 위치·보정·평균 계산 규칙 |
| 단위 변환 완료 | C=2.46, D=2.37 L/min | 센서 v1/v2의 측정 대상과 보정 대응 |
| 구간 정의 차이 발견 | D의 quartile-4bin은 다른 규칙 이름 | 같은 범위를 원시 자료에서 다시 집계할 수 있는지 |
| 운영 판정 버전 차이 발견 | D는 normal-band-v2로 판정 | 물리 측정 변경인지 판정 경계만 변경인지 |
D도 39.5×60/1000=2.37 L/min으로 변환할 수 있습니다. 변환된 값이 A의 2.4와 가깝다는 사실은 측정 정의가 같다는 증거가 아닙니다. 단위만 달랐고 측정 대상·위치·보정·집계 규칙이 같다고 확인된 경우에 단위 통일로 수치 비교를 회복합니다. 센서가 달랐다면 대응 측정이나 보정 기록을, 구간이 달랐다면 정확한 경계와 재집계 가능성을 확인해야 합니다.
운영 판정은 측정 정의와 별도로 기록한다¶
물리 측정 규칙을 바꾸지 않고 “2.50 L/min 이상”이라는 판정 기준만 “2.40 L/min 이상”으로 바꾸는 가상 사례를 생각해 보세요. 2.46 L/min이라는 측정값은 그대로지만 판정은 기준 미만에서 기준 이상으로 바뀝니다. 이것은 측정 변화가 아니라 판정 규칙 변화입니다. 실제 normal-band-v1/v2의 경계는 위 표에 없으므로 이 숫자를 그 버전의 실제 정의로 읽지는 않습니다.
| 기록 묶음 | 남길 항목의 예 |
|---|---|
| 측정·집계 정의 | 물리량, 센서 위치·버전, 보정 이력, 구간 경계, 평균 계산법, 결측 처리 |
| 단위 변환 | 원래 값·단위, 변환식, 변환 후 값·단위 |
| 운영 판정 | 판정 규칙 버전, 적용 시점, 결과 라벨 |
C는 원래 41.0 mL/s와 변환식 ×60/1000, 변환 후 2.46 L/min을 함께 보존합니다. 단위 열만 L/min으로 바꾸고 숫자 41.0을 남기면 잘못된 자료가 됩니다. 센서 버전 문자열을 v1로 고치는 것도 보정을 수행한 것이 아닙니다.
필드를 줄여 그룹이 합쳐져도 정의는 같아지지 않는다¶
앞 표를 이름만으로 묶으면 A·B·C·D 한 그룹입니다. 단위·센서 버전·구간 규칙·운영 판정까지 문자열로 비교하면 A·B / C / D의 세 그룹입니다. 운영 판정 필드를 빼도 D의 구간 규칙이 달라 세 그룹 그대로입니다. 운영 판정과 구간 규칙을 모두 빼면 A·B / C·D의 두 그룹으로 줄어듭니다.
C·D가 같은 그룹이 되었으니 같은 기준선에 넣어도 될까요? 답은 아직 아니오입니다. 비교에서 구간 필드를 숨겼을 뿐 실제 집계 규칙은 바꾸지 않았습니다. 반대로 판정 규칙만 달랐고 측정 정의가 같다는 근거가 있다면 물리 특징 비교와 결과 라벨 비교를 나누어 다룰 수 있습니다.
C와 A를 비교하려면 어떤 추가 자료가 필요한지 적어 보세요. 단위 변환만으로는 부족하며 센서 위치·보정과 실제 구간·평균 규칙의 대응이 필요합니다. D까지 넣으려면 quartile-4bin과 early-mid-late가 같은 측정 범위를 대표하는지도 확인해야 합니다. 원시 자료가 없어 정의를 맞출 수 없다면 비교를 보류하거나 별도 집단으로 남깁니다.
체크리스트¶
- C와 D의 값을 L/min으로 변환하고 원래 값·단위를 보존하는가?
- 메모 문자열 일치와 실제 비교 가능성을 구분하는가?
- 운영 판정만 달라진 경우와 측정·집계가 달라진 경우를 나누는가?
- 그룹 수 감소가 보정이나 재집계를 대신하지 않는 이유를 설명하는가?
출처와 참고 자료¶
- W3C,
PROV-Overview. provenance information을 통해 데이터가 어떤 과정과 버전을 거쳐 생성되었는지 추적하는 일반 틀을 제공하므로, 특징도 이름만이 아니라 생성 규칙과 버전까지 함께 남겨야 비교 가능성이 유지된다는 설명을 보강합니다. https://www.w3.org/TR/prov-overview/ / 확인일: 2026-07-20 - Google for Developers,
Machine Learning Glossary의feature engineering. feature가 원시 값을 그대로 쓰는 것이 아니라 선택된 변환의 결과라는 점을 설명하므로, 단위나 계산 규칙이 달라지면 같은 열 이름이어도 같은 특징 정의라고 보기 어렵다는 이 절의 핵심을 뒷받침합니다. https://developers.google.com/machine-learning/glossary / 확인일: 2026-07-20