들어가며
1편에서는 Tabular 데이터가 무엇인지, 어떤 특징이 있는지, 그리고 어떤 종류의 문제에 쓰이는지를 살펴봤다. 2편에서는 실제로 머신러닝 모델을 만들기 위해 거치는 전체 파이프라인을 단계별로 이해한다.
머신러닝 파이프라인이란?
머신러닝 프로젝트는 단순히 "모델을 학습시키는" 것이 전부가 아니다. 원시 데이터가 실제 예측 서비스로 변환되기까지는 여러 단계를 거쳐야 한다. 이 흐름을 ML 파이프라인(Machine Learning Pipeline) 이라고 한다.
데이터 수집 (Data Collection)
↓
탐색적 데이터 분석 (EDA)
↓
전처리 (Preprocessing)
↓
모델링 (Modeling)
↓
평가 (Evaluation)
↓
배포 및 모니터링 (Deployment & Monitoring)
각 단계를 하나씩 살펴보겠다.
1단계 — 데이터 수집 (Data Collection)
모든 머신러닝의 시작은 데이터를 모으는 것이다.
- 여러 테이블 결합: 실제 현장 데이터는 하나의 테이블에 담겨 있지 않다. 고객 테이블, 주문 테이블, 상품 테이블 등을 연결(join)해야 한다.
- 외부 데이터 활용: 예를 들어 특정 시점의 타임스탬프에 날씨 정보를 결합하면 예측 정확도가 높아질 수 있다.
- 재현성(Reproducibility) 확보: 데이터를 언제, 어디서, 어떻게 수집했는지 명확히 문서화해야 한다. 나중에 같은 방식으로 다시 수집할 수 있어야 한다.
2단계 — 탐색적 데이터 분석 (EDA, Exploratory Data Analysis)
모델을 바로 학습시키기 전에, 데이터를 충분히 이해하는 과정이 필요하다. 이것이 EDA이다.
EDA에서 확인하는 것들:
- 요약 통계: 평균, 중앙값, 사분위수, 표준편차 등
- 결측값 패턴: 어떤 열에 결측이 많은가? 결측이 랜덤인가, 아니면 특정 조건에서만 발생하는가?
- 분포 시각화: 히스토그램, 커널 밀도 추정(KDE) 그래프로 각 열의 분포를 확인한다
- 상관관계 분석: 특성들끼리, 그리고 특성과 타겟 변수 사이의 상관관계를 파악한다
- 이상치 및 클래스 불균형: 극단적인 값이나 클래스 불균형이 있는지 확인한다
EDA를 통해 데이터에 대한 직관을 쌓고, 모델링 전에 잠재적 문제를 미리 파악한다.
3단계 — 전처리 (Preprocessing)
원시 데이터를 모델이 학습할 수 있는 형태로 변환하는 단계이다. 전처리는 Tabular ML에서 특히 중요하다.
핵심 원칙 — 데이터 누수(Data Leakage) 방지
전처리를 할 때 반드시 지켜야 할 규칙이 있다. 전처리 변환(예: 스케일링)은 훈련 데이터로만 학습시키고,
검증/테스트 데이터에는 그 결과를 적용만 해야 한다.# 잘못된 방법 (데이터 누수 발생) X = scaler.fit_transform(X) # 전체에 먼저 적용 X_train, X_test = split(X, ...) # 올바른 방법 X_train, X_test = split(X, ...) X_train = scaler.fit_transform(X_train) # 훈련 데이터로만 학습 X_test = scaler.transform(X_test) # 테스트에는 적용만
잘못하면 모델이 미래 정보를 미리 보는 셈이 되어 실제 성능과 다른 낙관적인 평가가 나온다.
여기서 데이터 누수(Data Leakage)란?
수능 시험을 앞두고 학생이 실수로 실제 시험지를 미리 보게 됐다고 상상해보자.
당연히 모의고사에서 만점이 나온다. 하지만 이 점수는 실력이 아니다. 실전에서 새로운 문제가 나오면 여전히 못 푼다.
머신러닝에서 데이터 누수도 똑같다. 전처리 단계에서 "테스트 데이터의 정보"가 "훈련 데이터"로 흘러들어가면,
평가 점수는 높게 나오지만 실제 서비스에서는 형편없는 성능을 낸다. 연습 때만 잘하는 선수가 되는 것이다.
전처리 ①: 결측값 처리 (Handling Missing Values)
| 방법 | 설명 | 특징 |
|---|---|---|
| 삭제(Deletion) | 결측이 있는 행/열 제거 | 정보 손실이 생긴다 |
| 상수 채우기 | "Unknown"으로 채우기 | 결측 자체를 하나의 범주로 표현한다 |
| 통계적 대체 | 평균, 중앙값, 최빈값으로 채우기 | 간단하고 빠르다 |
| 모델 기반 대체 | k-NN 등으로 다른 특성을 이용해 예측 | 정확도가 높지만 복잡하다 |
| 기본 지원 | XGBoost, LightGBM 등 트리 모델은 결측을 직접 처리 | 별도 처리 없이도 작동한다 |
전처리 ②: 범주형 변수 인코딩 (Encoding Categorical Variables)
머신러닝 모델은 기본적으로 숫자를 입력받는다. 따라서 "서울", "부산", "대구" 같은 텍스트 범주를 숫자로 변환해야 한다.
| 방법 | 아이디어 | 특징 |
|---|---|---|
| 원-핫 인코딩 (One-Hot Encoding) |
각 범주마다 0/1 이진 열을 추가 | 단순하고 순서를 강제하지 않는다. 하지만 범주가 많으면 열 수가 폭발적으로 늘어난다 |
| 순서 인코딩 (Ordinal Encoding) |
범주를 순서 있는 정수로 매핑 | 티셔츠 사이즈처럼 자연스러운 순서가 있을 때 유용하다 |
| 타겟 인코딩 (Target Encoding) |
각 범주를 그 범주의 평균 타겟값으로 대체 | 정보량이 많다. 과적합 위험에 주의해야 한다 |
| 임베딩 인코딩 (Embedding) |
각 범주에 대한 벡터 표현을 학습 | 딥러닝 모델에서 사용한다 |
전처리 ③: 수치형 특성 변환 (Numerical Feature Transformations)
스케일링(Scaling): 많은 모델들(예: 선형 회귀, SVM, 신경망)은 특성의 크기에 민감하다.
나이(0~100)와 연봉(0~1억)이 그대로 입력되면 연봉 열이 모델을 지배해버린다.
- 표준화(Standardization): $x' = \frac{x - \mu}{\sigma}$ — 평균을 0, 표준편차를 1로 만든다
- 최솟값-최댓값 정규화(Min-Max Scaling): $x' = \frac{x - \min}{\max - \min}$ — 0과 1 사이로 변환한다
단, 의사결정 트리 기반 모델(XGBoost, LightGBM 등)은 스케일에 영향을 받지 않으므로 스케일링이 불필요하다.
여기서 스케일링(Scaling)이라고 한다면,
피겨스케이팅 대회에서 두 심판이 점수를 매긴다고 해보자.
한 심판은 0~10점 기준, 다른 심판은 0~1,000점 기준으로 채점한다.
두 점수를 그냥 합산하면, 1,000점 기준 심판의 점수가 결과를 거의 혼자 결정해버린다.
10점짜리 심판의 의견은 묻혀버린다.
머신러닝 모델도 마찬가지다. 나이(0~100)와 연봉(0~1억)을 그대로 쓰면,연봉이 모델의 판단을 지배한다.
스케일링은 이 심판들의 채점 기준을 동일하게 맞추는 작업이다.
분포 변환(Distribution Transformation):
- 로그 변환(Log Transform): 수입, 가격, 카운트처럼 오른쪽으로 긴 꼬리(right-skewed)를 가진 분포에 효과적이다
- 분위수 변환(Quantile Transform): 값을 분포 내 순위로 변환한다. 이상치에 강건(robust)하다
구간화(Binning/Discretization): 연속형 수치를 구간으로 나누는 방법으로, 선형 모델이 비선형 패턴을 잡는 데 도움을 준다.
전처리 ④: 피처 엔지니어링 (Feature Engineering)
도메인 지식을 활용해 원시 데이터에서 새로운 유용한 특성을 직접 만들어내는 작업이다. 모델이 스스로 학습하기 어려운 패턴을 사람이 직접 표현해주는 것이다.
| 패턴 | 예시 |
|---|---|
| 집계(Aggregations) | 최근 30일 평균 구매 금액 |
| 비율(Ratios) | 부채-소득 비율 (Debt-to-Income Ratio) |
| 시간 차이 | 마지막 로그인 이후 경과 일수 |
| 날짜 분해 | 월, 요일, 공휴일 여부 |
| 상호작용(Interactions) | 가격 × 수량 = 총 매출 |
| 도메인 특화 | 의료에서 BMI, 금융에서 각종 재무 지표 |
피처 엔지니어링은 때로 모델 선택보다 더 큰 성능 차이를 만들어낸다.
여기서 피처 엔지니어링는
형사가 용의자를 수사할 때, 원시 증거만 나열하는 것과 단서를 조합해서 새로운 사실을 끌어내는 것은 전혀 다르다.
"용의자가 은행 근처에 있었다" + "그날 큰 금액을 인출했다" + "평소와 다른 경로로 이동했다" → "수상한 금융 활동" 이라는 강력한 단서가 된다.
피처 엔지니어링도 이와 같다. 날짜에서 "공휴일 여부"를 추출하거나, 가격과 수량을 곱해 "총 매출"을 만드는 것처럼, 원시 데이터에서 숨겨진 의미를 꺼내 모델이 더 쉽게 배울 수 있도록 돕는다.
4단계 — 모델링 (Modeling)
전처리된 데이터로 실제 모델을 선택하고 학습시키는 단계이다. Tabular 데이터에 사용되는 주요 모델 계열은 다음과 같다.
| 모델 유형 | 예시 | 특징 |
|---|---|---|
| 선형/로지스틱 회귀 | Linear Regression, Logistic Regression | 해석이 쉽고 기준선(baseline)으로 적합하다 |
| 트리 기반 앙상블 | XGBoost, LightGBM, CatBoost | Tabular ML에서 대부분의 현실 문제에 강력하다 |
| 딥러닝 / 기반 모델 | 신경망, LLM, TabPFN | 대규모 데이터나 새로운 패러다임에서 주목받고 있다 |
현재 많은 현실 문제에서는 XGBoost, LightGBM, CatBoost 같은 그래디언트 부스팅(Gradient Boosting) 계열 트리 앙상블 모델이 최고의 성능을 보인다. 이 모델들은 Kaggle 같은 데이터 경진대회에서도 압도적으로 많이 쓰인다.
5단계 — 평가 (Evaluation)
좋은 모델을 만들기 위해서는 신뢰할 수 있는 평가가 필수다.
교차 검증 (Cross-Validation, CV)
데이터를 단순히 훈련/테스트로 나누는 것보다 더 신뢰할 수 있는 방법이다. 데이터를 여러 개의 폴드(fold)로 나누고, 돌아가며 검증 세트로 사용한다.
전체 데이터
├── 훈련 데이터 ──→ CV로 하이퍼파라미터 최적화 ──→ 최적 모델
└── 별도 테스트 세트 ──→ 최종 성능 평가 (딱 한 번만!)
흔한 함정들:
- 훈련-테스트 오염: 전처리에서 테스트 데이터 정보가 훈련에 흘러들어가는 것
- 단일 검증 세트 과적합: 하나의 검증 세트로만 수천 번의 하이퍼파라미터 조합을 시험하면,
그 검증 세트에 특화된 모델이 나온다
평가 지표 (Evaluation Metrics)
문제 유형에 맞는 지표를 선택해야 한다.
회귀(Regression) 지표:
- MAE (Mean Absolute Error): 평균 절대 오차. 직관적으로 이해하기 쉽다
- MSE (Mean Squared Error): 평균 제곱 오차. 큰 오차에 더 큰 패널티를 준다
- R² Score: 모델이 데이터의 분산을 얼마나 설명하는지.
$R^2 = 1 - \frac{\sum(y_i - \hat{y}_i)^2}{\sum(y_i - \bar{y})^2}$
분류(Classification) 지표:
| 지표 | 계산식 | 의미 |
|---|---|---|
| 정확도 (Accuracy) | (TP + TN) / 전체 | 전체 중 맞춘 비율 |
| 정밀도 (Precision) | TP / (TP + FP) | "양성"이라고 예측한 것 중 실제 양성 비율 |
| 재현율 (Recall) | TP / (TP + FN) | 실제 양성 중 맞게 예측한 비율 |
| F1 Score | Precision과 Recall의 조화 평균 | 둘의 균형 |
- AUC-ROC: 임계값에 관계없이 모델의 전반적 변별력을 측정한다
- AUC-PR (Precision-Recall): 클래스 불균형이 심할 때 AUC-ROC보다 더 유용하다
문제에 맞는 지표 선택이 중요하다
| 문제 유형 | 추천 지표 | 이유 |
|---|---|---|
| 사기 탐지 (희귀 양성) | PR-AUC, 고정 정밀도에서의 재현율 | 정확도는 의미없다 (99%가 정상이면 모두 정상이라 해도 99% 정확) |
| 의료 검진 (놓치면 심각) | Recall (재현율) 최적화 | 환자를 놓치는 것이 치명적이다 |
| 스팸 필터 (오탐이 비용) | Precision (정밀도) 최적화 | 정상 메일을 스팸으로 분류하는 것이 더 나쁘다 |
최선의 지표는 현실에서 오류 비용을 가장 잘 반영하는 지표이다.
6단계 — 배포 및 모니터링 (Deployment & Monitoring)
좋은 모델을 만들었다고 해서 끝이 아니다. 실제 서비스에 적용하고 지속적으로 관리해야 한다.
배포 시 고려사항:
- 배치(Batch) vs 온라인(Online) 추론: 대량 데이터를 한꺼번에 처리할지, 요청이 올 때마다 실시간으로 처리할지 결정한다
- 학습-배포 일관성: 학습 때 적용한 전처리 단계가 배포 환경에서도 반드시 동일하게 적용되어야 한다. 그렇지 않으면 모델이 이상한 값을 예측한다
모니터링 항목:
- 데이터 드리프트(Data Drift): 입력 데이터의 분포가 시간이 지나며 변한다 (예: 고객 행동 패턴의 변화)
- 컨셉 드리프트(Concept Drift): 입력-출력 관계 자체가 변한다 (예: 경제 상황 변화로 인한 신용 기준 변화)
- 성능 저하(Performance Degradation): 실시간 지표가 학습 때보다 떨어지는지 모니터링한다
- 공정성 지표(Fairness Metrics): 특정 집단에 대한 차별적 예측이 발생하지 않는지 확인한다
문제가 감지되면 모델을 재학습하거나 업데이트해야 한다.
데이터 드리프트는
2019년에 만들어진 내비게이션 지도로 2026년 도로를 달린다고 상상해보자.
그사이 새 도로가 생기고, 일방통행이 바뀌고, 공사 구간이 추가됐다. 내비게이션은 자신있게 길을 안내하지만,
현실과 점점 어긋난다.
머신러닝 모델도 같다. 세상은 계속 변하는데 모델은 과거 데이터로만 학습되어 있다.
데이터 드리프트는 입력 데이터의 분포가 바뀌는 것이고,
컨셉 드리프트는 "이런 패턴이면 이런 결과"라는 관계 자체가 바뀌는 것이다. 모델을 배포하고 끝이 아니라, 지속적으로 지도를 업데이트해야 한다.
해석 가능성 (Interpretability)
높은 예측 성능만으로는 충분하지 않을 때가 많다. 특히 금융, 의료, 법률 분야에서는 왜 그런 예측을 했는지 설명할 수 있어야 한다.
해석 가능성
병원에서 의사가 "당신은 암일 확률이 87%입니다"라고 말한다. 환자가 "왜요?"라고 물었더니 의사가 "AI가 그렇게 판단했어요" 라고만 답한다.
납득할 수 있는가? 대출 심사에서 "당신의 대출은 거절됐습니다"라는 결과만 주고 이유를 알려주지 않는다면?
법적으로도, 도덕적으로도 문제가 된다.
해석 가능성은 "모델이 왜 이 예측을 했는지 인간이 이해할 수 있게 만드는 것" 이다.
성능이 아무리 좋아도 설명할 수 없다면, 실제 현장에서 신뢰받기 어렵다.
두 가지 수준의 해석이 필요하다:
- 전역(Global) 해석: 모델 전체에서 어떤 특성이 중요한가?
- 지역(Local) 해석: 이 특정 샘플에 대해 왜 이런 예측이 나왔는가?
주요 기법:
| 기법 | 설명 |
|---|---|
| 순열 중요도 (Permutation Importance) |
특정 특성을 무작위로 섞었을 때 성능이 얼마나 떨어지는지 측정한다. 많이 떨어질수록 중요한 특성이다 |
| SHAP | 각 특성이 개별 예측에 얼마나 기여했는지 수치로 계산한다. 트리 기반 모델에 특히 효율적으로 계산된다 |
도구 및 데이터셋
Tabular ML을 시작하기 위한 실용적인 자원을 소개한다.
주요 라이브러리:
- NumPy, Pandas: 데이터 처리의 기본
- scikit-learn: 전처리, 모델링, 평가를 포괄하는 파이썬 ML 표준 라이브러리
- XGBoost, LightGBM, CatBoost: 그래디언트 부스팅 트리 앙상블
- Optuna: AutoML, 하이퍼파라미터 최적화
- PyTorch: 딥러닝
공개 데이터셋 및 벤치마크:
- Kaggle: 실제 기업 문제를 다루는 최대 데이터 경진대회 플랫폼
- UCI Machine Learning Repository: 고전적인 ML 벤치마크 데이터셋 모음
- OpenML: 오픈소스 ML 실험 공유 플랫폼
- AI Hub: 한국 AI 데이터 허브
앞으로의 여정 — 강의 로드맵
이 글에서 다룬 내용은 Tabular ML의 입문이다. 이후 배울 내용들을 미리 살펴보면:
- 고전적 ML 모델 — 결정 트리, 랜덤 포레스트, 그래디언트 부스팅 등
- 딥러닝 아키텍처 — Tabular 데이터를 위한 신경망 구조
- Tabular 표현 학습 — 비지도 사전학습을 통한 성능 향상
- LLM과 Tabular 데이터 — 대형 언어 모델을 테이블 문제에 적용하기
- 새로운 패러다임: TabPFN — 소규모 Tabular 데이터를 위한 사전 학습된 트랜스포머
마무리
Tabular ML 파이프라인을 정리하면 다음과 같다.
데이터 수집 → EDA → 전처리 → 모델링 → 평가 → 배포 및 모니터링
각 단계가 독립적이지 않고 서로 긴밀하게 연결되어 있다. 특히:
- 전처리는 모델만큼 중요하다. 데이터 누수 없이 잘 만들어진 전처리가 성능을 크게 좌우한다.
- 평가 프로토콜은 모델 선택만큼 중요하다. 신뢰할 수 없는 평가로는 올바른 모델을 선택할 수 없다.
- 해석 가능성과 모니터링은 실제 서비스 환경에서 필수적이다.
Tabular 데이터는 가장 흔하면서도, 잘 다루기 위해서는 도메인 지식과 ML 지식을 균형 있게 갖춰야 하는 분야이다. 앞으로의 강의에서 각 주제를 더 깊이 파고들 예정이다.
참고: 성균관대학교 Efficient Learning Lab, Hankook Lee 교수 강의 자료 기반
'AI > ML&DL' 카테고리의 다른 글
| [ML] Tabular - 표 형식 데이터 1 (0) | 2026.06.24 |
|---|