ML Systems Data Leakage
머신러닝 모델은 오프라인 평가에서 성능이 좋아도 프로덕션에서는 무용지물이 될 수 있습니다. 그 대표 원인 중 하나가 데이터 누수(Data Leakage)입니다. 데이터 누수는 정답(label)에 관한 정보가 어떤 형태로든 입력(feature)으로 새어 들어가 모델이 평가 과정에서 “부정확한 방식으로” 높은 성능을 내는 현상을 뜻합니다. 문제는 이 정보가 실제 추론(inference) 시점에는 존재하지 않거나 동일하게 재현되지 않는다는 점이며, 그 결과 모델은 잘되는 것처럼 보이다가 현장에서 급격히 망가질 수 있습니다.
문제 제기: 코로나19 모델 실패 사례로 보는 데이터 누수
2021년 7월 MIT Technology Review는 “코로나19를 잡기 위한 수백 개의 AI 도구가 있었지만 실제로 도움 된 것은 없었다”는 취지의 기사를 소개했습니다. 의료 스캔으로 COVID-19 위험을 예측하던 많은 모델이 평가에서는 잘 나왔지만 실제 환경에서는 사용 불가능했던 사례가 반복되었다는 내용입니다.
환자 자세(leak) 예시
서서 찍은 스캔과 누워서 찍은 스캔을 섞어 학습했는데, 누워서 촬영된 환자가 더 중증일 확률이 높았습니다. 그 결과 모델은 질병 신호가 아니라 “자세(누웠는지/섰는지)”로 중증 위험을 예측하게 되었습니다.
즉, 라벨과 강하게 결합된 촬영 조건이 입력에 포함되면서 정답 정보가 사실상 누수된 것입니다.
병원 글꼴(font) 누수 예시
모델이 병원마다 스캔에 찍히는 텍스트 글꼴(폰트)을 학습해버린 경우도 있었습니다. 특정 병원은 중증 환자 비율이 높고, 그 병원 특유의 폰트가 일정한 패턴으로 나타나면 모델은 “질병”이 아니라 “병원 폰트”로 위험을 예측하게 됩니다. 이 역시 라벨과 우연히 결합된 특성이 입력을 통해 누수된 사례입니다.
데이터 누수의 정의와 위험성
정의
데이터 누수는 라벨의 한 형태가 입력 특성(feature)으로 유출(leak)되어 모델이 예측에 활용하게 되는 현상입니다. 그리고 그 정보가 실제 추론 시점에는 동일하게 제공되지 않을 때 문제가 됩니다.
왜 어려운가
데이터 누수는 대개 비자명(non-obvious)합니다. 정답 컬럼을 삭제했더라도, 데이터 생성/수집/전처리 과정에서 라벨과 강하게 연결된 대리변수(proxy)가 남아 있을 수 있습니다.
왜 위험한가
누수는 모델이 평가에서 “치팅(cheating)”을 하도록 만들고, 광범위한 검증을 통과한 뒤에도 배포 후 예상치 못한 형태로 성능이 붕괴하게 만들 수 있습니다. 특히 의료처럼 환경 차이가 큰 도메인에서는 한 기관에서는 잘 되다가 다른 기관에서는 급락하는 문제가 자주 발생합니다.
CT 폐암 예시: 병원 A에서는 잘 되고 병원 B에서는 망가지는 이유
폐 CT에서 암 여부를 예측하는 모델을 만든다고 가정합니다.
1) 병원 A 데이터로 학습하고, 의사 진단(라벨)을 제거한 뒤 모델을 학습합니다. 2) 병원 A 테스트에서는 성능이 매우 잘 나옵니다. 3) 그러나 병원 B 데이터에서는 성능이 크게 떨어집니다.
조사 결과 병원 A에서는 의사가 암을 의심하면 더 고급 CT 장비로 보내고, 그 장비는 출력 이미지 특성이 미묘하게 달랐습니다. 모델은 “암의 소견”이 아니라 “어떤 장비로 촬영했는지(장비 특성)”를 통해 암을 맞히는 방향으로 학습한 것입니다.
반면 병원 B는 환자를 임의로 장비에 배정해 장비가 라벨을 암시하지 않으므로, 병원 B에서는 모델이 기대던 신호가 사라져 성능이 붕괴합니다. 이 상황이 바로 “라벨 정보가 장비 특성이라는 형태로 입력에 누수된” 사례입니다.
주의 사례: Kaggle Ion Switching 대회에서의 누수
2020년 University of Liverpool이 Kaggle에서 Ion Switching 대회를 열었고, 테스트 데이터가 학습 데이터로부터 합성되어 생성되었습니다. 일부 참가자는 생성 과정을 역공학해 테스트 라벨을 누수로부터 복원할 수 있었고, 상위 팀들이 그 누수를 활용했다고 소개됩니다. 즉, 데이터 생성 방식 자체가 “테스트 라벨을 유추 가능하게” 만들면 평가가 무너질 수 있음을 보여주는 사례입니다.
데이터 누수의 흔한 원인과 예방
책은 대표적인 누수 원인을 데이터 분할 / 전처리 / 중복 / 그룹 / 수집 과정 관점에서 정리합니다.
시간 상관(time-correlated) 데이터를 랜덤 분할
시간에 따라 데이터 분포가 달라지는 경우, 랜덤 분할은 미래 정보가 학습으로 섞이는 누수를 만들 수 있습니다.
가능하면 시간 기준 분할을 우선 고려해야 합니다(예: 1~4주 학습, 5주 검증/테스트).
분할 전에 스케일링(scaling)
스케일링은 전역 통계(평균/분산)가 필요합니다. 전체 데이터로 통계를 만든 뒤 분할하면 테스트 통계가 학습 과정에 누수됩니다.
따라서 분할 → train 통계 산출 → 모든 split에 동일 적용 순서를 지켜야 합니다.
결측치 대치(imputation)를 전체 데이터로 수행
결측치 채움(평균/중앙값 대치)을 전체 데이터로 하면 테스트 분포 정보가 누수됩니다.
스케일링과 동일하게 train 기준 통계만 사용합니다.
중복(duplication) 처리 미흡
중복/근접중복이 제거되지 않은 채 분할되면 같은 샘플이 train과 test에 동시에 포함될 수 있습니다.
- 중복 제거는 분할 전에 수행하고
- 분할 후에도 교차 중복이 없는지 재점검하며
- 오버샘플링은 반드시 분할 이후에 수행합니다.
그룹 누수(group leakage)
같은 환자/세션/객체에서 생성된 샘플은 라벨이 강하게 연관될 수 있습니다. 이를 서로 다른 split에 분산시키면 누수가 발생합니다.
따라서 split 단위를 샘플이 아니라 환자/케이스/세션 단위(group-wise split)로 설계하는 것이 안전합니다.
데이터 생성 과정으로부터의 누수
장비/기관/프로토콜이 라벨과 결합되어 입력에 남는 누수는 데이터 수집/운영을 깊이 이해하지 않으면 찾기 어렵습니다.
완전한 해결책은 없지만 다음을 통해 위험을 줄일 수 있습니다.
- 데이터 출처(source)와 수집/처리 과정을 체계적으로 기록합니다.
- 서로 다른 출처 간 통계 차이를 줄이도록 정규화합니다.
- 장비/해상도 등 출처 식별 신호를 표준화해 모델이 출처를 맞히기 어렵게 합니다.
- 도메인 전문가(SME)를 설계 과정에 참여시켜 누수 가능성을 점검합니다.
데이터 누수 탐지 방법
데이터 누수는 데이터 생성부터 피처 엔지니어링까지 어디서든 발생할 수 있으므로 라이프사이클 전반에서 모니터링해야 합니다.
피처-라벨 상관성 점검
특정 피처(또는 피처 조합)가 라벨을 과도하게 잘 예측한다면 생성 과정을 반드시 확인해야 합니다.
예를 들어 시작일과 종료일을 함께 쓰면 근속 기간(라벨)을 직접 계산할 수 있어 누수가 됩니다.
Ablation study로 피처 의존성 확인
피처를 제거했을 때 성능이 비정상적으로 크게 떨어지면, 그 피처가 누수 신호일 가능성을 의심해야 합니다. 전체 조합이 어렵다면 의심되는 피처 집합부터 주기적으로 수행합니다.
새 피처 추가 후 성능 급등에 주의
새 피처 추가로 성능이 크게 좋아졌다면, 정말 좋은 피처일 수도 있지만 라벨이 새어 들어간 피처일 수도 있습니다. 성능 급등은 반드시 “생성 과정 검증”으로 이어져야 합니다.
테스트셋 사용을 엄격히 제한
테스트셋은 최종 성능 보고를 위한 용도로만 사용합니다. 테스트셋으로 피처 아이디어를 얻거나 하이퍼파라미터를 튜닝하면 누수 위험이 커집니다.
좋은 피처 엔지니어링: “많을수록 좋다”의 함정
피처가 많아지면 성능이 올라갈 수 있지만, 동시에 다음 비용과 위험이 증가합니다.
- 누수 가능성 증가
- 과적합 증가
- 서빙 비용(메모리/인프라) 증가
- 온라인 피처 추출로 인한 지연(latency) 증가
- 불필요한 피처로 인한 기술부채 증가
이론적으로 L1 규제 등이 불필요한 피처 가중치를 0으로 만들 수 있지만, 실무에서는 불필요/해로운 피처를 제거하는 편이 학습 안정성과 효율 측면에서 유리할 수 있습니다.
좋은 피처를 평가하는 두 축: 중요도와 일반화
중요도(Importance)
중요도는 해당 피처를 제거했을 때 성능이 얼마나 떨어지는지로 이해할 수 있습니다.
- 트리 모델: XGBoost의 중요도 기능 활용
- 모델-불문: SHAP 등으로 전역 중요도/개별 예측 기여도를 해석 가능
일반화(Generalization)
일반화는 정량화가 어렵고 직관과 도메인 지식이 중요합니다.
- 커버리지(coverage): 값이 존재하는 샘플 비율
- 값의 분포(distribution): train에서 본 값과 test에서 본 값이 겹치는지
일반화와 특이성 사이에는 트레이드오프가 있으며(예: HOUR_OF_THE_DAY vs IS_RUSH_HOUR), 문제 특성에 맞는 적절한 추상화가 필요합니다.
맺음말
데이터 누수는 모델 성능을 좋아 보이게 만들지만, 실제 배포 환경에서는 예상치 못한 방식으로 성능을 무너뜨릴 수 있는 위험한 문제입니다. 특히 의료 영상처럼 데이터 생성 과정(장비, 기관, 촬영 프로토콜)이 라벨과 결합되기 쉬운 도메인에서는 누수 탐지와 예방이 필수적입니다. 따라서 시간/그룹 단위 분할, train 기준 전처리, 중복 및 그룹 누수 점검, 피처 상관/ablation/성능 급등 검증, 테스트셋 사용 엄격화를 통해 누수 가능성을 라이프사이클 전반에서 관리해야 합니다. 마지막으로 피처의 중요도와 일반화라는 두 축을 함께 고려하여, 성능뿐 아니라 현장 재현성과 안정성을 갖춘 피처 설계를 지향해야 합니다.