Tabular Data와 Machine Learning Pipeline 정리

Tabular Data에 대해 정리해보고자 한다.

Tabular Data란?

Tabular Data는 쉽게 말하면
행과 열로 구성된 표 형태의 데이터를 말한다.

우리가 엑셀이나 데이터베이스에서 자주 보는 형태가 바로 Tabular Data다.

예를 들어 고객 이탈 예측 문제를 생각해보자.

ID | Age | Charge | Contract | Tenure | Churned
1  | 34  | 75     | Monthly  | 6      | Yes
2  | 52  | 45     | 2-year   | 48     | No
3  | 28  | 120    | Monthly  | 2      | Yes

여기서 하나의 행(row)은 한 명의 고객을 의미한다.

그리고 각각의 열(column)은
그 고객에 대한 속성을 의미한다.

예를 들어 Age, Charge, Contract, Tenure는 feature가 될 수 있고,
Churned는 우리가 예측하고 싶은 target이 될 수 있다.

정리하면 다음과 같다.

row = 하나의 관측치, 샘플, record, instance
column = feature, attribute, variable
target = 예측하고 싶은 정답 column

즉, Tabular Data는
여러 개의 feature를 가진 row들을 모아둔 데이터라고 할 수 있다.

---

Tabular Data의 특징

Tabular Data는 단순히 표 형태라는 점만 중요한 것이 아니다.

생각보다 다루기 까다로운 특징들이 많다.

---

1. Feature의 종류가 다양하다

Tabular Data는 하나의 row 안에
서로 다른 종류의 feature가 함께 들어갈 수 있다.

예를 들어 고객 데이터가 있다고 해보자.

Age: 숫자형
Country: 범주형
Subscribed: 이진형
SignupDate: 날짜형
Review: 텍스트형

이처럼 하나의 데이터 안에
숫자, 문자열, 날짜, yes/no, 텍스트 등이 함께 들어갈 수 있다.

대표적인 feature type은 다음과 같다.

Feature Type	예시
Numerical	나이, 가격, 온도, 자녀 수
Categorical	국가, 색상, 직업, 교육 수준
Binary	Yes/No, True/False, 0/1
Datetime	날짜, 시간, timestamp
Text	사용자 리뷰, 댓글
Others	이미지, 비디오 등

이 점이 이미지 데이터나 텍스트 데이터와 다른 부분이다.

이미지는 대부분 픽셀이라는 동일한 형태의 데이터가 모여 있고,
텍스트는 단어의 순서가 중요하다.

하지만 Tabular Data는
각 column마다 성격이 완전히 다를 수 있다.

그래서 모델은 서로 다른 통계적 성질을 가진 feature들을
함께 처리할 수 있어야 한다.

---

2. Column 순서 자체에는 큰 의미가 없다

이미지에서는 옆에 있는 픽셀들이 서로 관련이 있다.

텍스트에서는 단어의 순서가 중요하다.

예를 들어

나는 밥을 먹었다.
밥은 나를 먹었다.

두 문장은 단어는 비슷하지만 순서가 바뀌면서 의미가 완전히 달라진다.

하지만 Tabular Data에서는 column의 순서가 바뀐다고 해서
데이터의 의미가 바뀌지는 않는다.

예를 들어 다음 두 데이터는 본질적으로 같은 정보를 담고 있다.

Age | Salary | Gender
25  | 3000   | Male

Salary | Gender | Age
3000   | Male   | 25

column의 순서는 바뀌었지만
각 feature의 의미만 잘 유지된다면 데이터 자체의 의미는 같다.

즉, Tabular Data는 이미지나 텍스트처럼
자연스러운 공간적 구조나 순차적 구조가 있는 데이터가 아니다.

이 때문에 Tabular Data를 학습하는 모델은
feature의 순서에 과도하게 의존하면 안 된다.

---

3. 데이터 크기가 작거나 중간 정도인 경우가 많다

이미지나 텍스트 분야에서는
수백만 개, 수십억 개의 데이터로 학습하는 경우도 많다.

하지만 Tabular Data는
현실적으로 몇 천 개에서 몇 만 개 정도의 row를 가진 경우도 많다.

예를 들어 병원 데이터, 제조 결함 데이터, 기업 내부 고객 데이터는
데이터 수가 생각보다 많지 않을 수 있다.

데이터가 적으면 문제가 생긴다.

- 모델이 쉽게 과적합될 수 있다.
- 복잡한 딥러닝 모델이 오히려 성능이 낮을 수 있다.
- 제한된 데이터에서 일반화 성능을 확보해야 한다.

그래서 Tabular Data에서는
XGBoost, LightGBM, CatBoost 같은 tree-based ensemble 모델이
자주 사용된다.

이 모델들은 비교적 작은 데이터에서도 강한 성능을 내는 경우가 많다.

---

4. Missing Value가 자주 발생한다

현실 데이터는 깨끗하지 않다.

Tabular Data에는 결측치가 매우 자주 등장한다.

예를 들어 다음과 같은 상황이 있을 수 있다.

- 사용자가 설문 문항을 건너뜀
- 센서가 고장 나서 값이 기록되지 않음
- 여러 데이터 소스를 합치면서 일부 column이 비어 있음
- 특정 고객의 정보가 아직 수집되지 않음

예를 들어 고객 데이터가 다음과 같다고 해보자.

ID | Age | Income | City
1  | 25  | 3000   | Seoul
2  |     | 4200   | Busan
3  | 31  |        | Seoul

여기서 Age와 Income에 빈 값이 있다.

이런 결측치를 어떻게 처리하느냐가
모델 성능에 큰 영향을 줄 수 있다.

---

5. Label이 완벽하지 않을 수 있다

Tabular Data의 label은
현실 세계의 과정에서 만들어지는 경우가 많다.

그래서 label이 항상 완벽하다고 볼 수 없다.

예를 들어 대출 심사 데이터에서
어떤 사람이 실제로 위험한 고객인지 아닌지는
시간이 지나야 알 수 있다.

또 회사의 정책이 바뀌면
예전에는 위험 고객으로 분류되던 사람이
이후에는 다른 기준으로 분류될 수도 있다.

즉, label 자체가 noisy할 수 있다.

또 하나 조심해야 할 것은 leakage다.

예를 들어 고객 이탈 예측을 하는데
이탈 이후에 기록된 정보를 feature로 넣어버리면
모델이 정답을 미리 보고 학습하는 꼴이 된다.

이런 경우 모델 성능은 좋아 보이지만,
실제로는 사용할 수 없는 모델이 된다.

---

6. Class Imbalance가 자주 발생한다

Tabular Data에서는 class imbalance도 자주 발생한다.

예를 들어 신용카드 사기 탐지 문제를 보자.

전체 거래 중 대부분은 정상 거래다.

사기 거래는 매우 적다.

정상 거래: 99.5%
사기 거래: 0.5%

이런 상황에서 모델이 모든 거래를 정상이라고 예측해도
accuracy는 99.5%가 나올 수 있다.

하지만 이 모델은 아무 쓸모가 없다.

정작 중요한 사기 거래를 하나도 잡지 못하기 때문이다.

그래서 imbalanced classification 문제에서는
accuracy만 보면 안 된다.

Precision, Recall, F1 Score, PR-AUC 같은 metric을 함께 봐야 한다.

---

Tabular Data로 할 수 있는 Task

Tabular Data는 다양한 머신러닝 문제로 연결될 수 있다.

대표적으로 다음과 같은 task들이 있다.

---

1. Prediction

Prediction은 주어진 데이터로부터 target을 예측하는 문제다.

즉, training set이 다음과 같이 주어졌다고 해보자.

x = feature
y = target

모델은 새로운 record x가 들어왔을 때
알 수 없는 target y를 예측해야 한다.

Prediction 문제는 크게 두 가지로 나눌 수 있다.

Regression: 연속적인 값을 예측
Classification: 정해진 class 중 하나를 예측

예를 들어 집값 예측은 regression 문제다.

입력: 면적, 위치, 방 개수, 건축 연도
출력: 집값

반대로 고객 이탈 여부 예측은 classification 문제다.

입력: 나이, 요금제, 사용 기간, 월 사용량
출력: 이탈 여부 Yes/No

즉, target이 연속적인 숫자라면 regression,
target이 class라면 classification이라고 볼 수 있다.

---

2. Anomaly Detection

Anomaly Detection은 이상치를 탐지하는 문제다.

즉, 대부분의 데이터와 다른
희귀하고 비정상적인 record를 찾는 것이다.

대표적인 예시는 신용카드 사기 탐지다.

TxnID | Amount | Merchant    | Country | Last
1     | 42.5   | Coffee Shop | KR      | 3.0 hours
2     | 38.0   | Grocery     | KR      | 2.1 hours
3     | 2890.0 | Electronics | RU      | 0.1 hours
4     | 12.0   | Restaurant  | KR      | 5.4 hours

여기서 3번 거래는 조금 이상해 보인다.

금액이 너무 크고,
국가도 갑자기 바뀌었고,
이전 거래와의 시간 간격도 짧다.

이런 데이터를 찾아내는 것이 anomaly detection이다.

Anomaly Detection은 보통 unsupervised 방식으로 많이 다뤄진다.

왜냐하면 정상 데이터는 많지만,
정확히 label이 붙은 이상치 데이터는 매우 적거나 없을 수 있기 때문이다.

---

3. Clustering

Clustering은 label 없이
비슷한 record끼리 그룹화하는 문제다.

예를 들어 고객 데이터를 보고
비슷한 구매 패턴을 가진 고객끼리 묶을 수 있다.

Customer | Avg Purchase | Visits | Online Ratio | Preferred Category
1        | 180          | 8      | 95%          | Electronics
2        | 45           | 12     | 10%          | Groceries
3        | 320          | 2      | 80%          | Luxury
4        | 52           | 14     | 5%           | Groceries

이 데이터를 clustering하면
다음과 같은 그룹을 찾을 수 있다.

- 온라인 전자제품 구매 고객
- 오프라인 식료품 반복 구매 고객
- 고가 상품 구매 고객

이렇게 그룹화한 결과를 바탕으로
마케팅 전략이나 비즈니스 로직을 세울 수 있다.

예를 들어 고가 상품 구매 고객에게는 프리미엄 쿠폰을 보내고,
식료품 반복 구매 고객에게는 정기배송 서비스를 추천할 수 있다.

대표적인 clustering 알고리즘은 다음과 같다.

- k-means
- GMM
- DBSCAN
- hierarchical clustering

---

4. Table Question Answering

Table Question Answering은
자연어 질문과 table이 함께 주어졌을 때
그 table을 바탕으로 답을 생성하는 문제다.

예를 들어 다음과 같은 매출 데이터가 있다고 하자.

Order ID | Region | Quarter | Product | Revenue
1        | Asia   | Q1      | A       | 1200
2        | Asia   | Q2      | B       | 2400
3        | Europe | Q1      | A       | 800
4        | Asia   | Q3      | A       | 1800
5        | Europe | Q3      | B       | 1100

질문이 다음과 같이 들어올 수 있다.

Q. Asia 지역의 Q3 매출은 얼마인가?

그러면 모델은 table에서
Region = Asia, Quarter = Q3인 row를 찾고
Revenue를 확인해야 한다.

A. 1800

이 task는 단순히 table만 이해하면 되는 것이 아니라
자연어 질문도 이해해야 한다.

즉, 자연어 이해와 tabular reasoning이 함께 필요하다.

최근 LLM의 발전으로
이런 Table Question Answering도 점점 가능해지고 있다.

---

5. Synthetic Data Generation

Synthetic Data Generation은
진짜 데이터와 비슷한 가짜 데이터를 생성하는 task다.

중요한 점은
그냥 아무 데이터를 만드는 것이 아니라,
원본 데이터의 통계적 특성을 유지하면서도
개인정보는 보호해야 한다는 것이다.

예를 들어 헬스케어 데이터를 생각해보자.

Patient ID | Age | BMI  | BPSystolic | Diabetes?
1          | 62  | 28.4 | 148        | Yes
2          | 35  | 22.1 | 120        | No
3          | 71  | 31.5 | 160        | Yes

이런 실제 환자 데이터를 그대로 공개하면
개인정보 문제가 발생할 수 있다.

그래서 원본 데이터와 비슷한 분포를 가지지만
개별 환자 정보가 직접 드러나지 않는 synthetic data를 생성할 수 있다.

이렇게 생성된 데이터는
연구나 모델 학습에 사용할 수 있다.

활용 예시는 다음과 같다.

- 개인정보 보호가 필요한 데이터 공유
- 작은 데이터셋 보강
- 연구용 데이터 생성

---

결국 핵심 질문

여기까지 정리하면 핵심 질문은 이것이다.

어떻게 해야 Tabular Data를 가지고
ML을 사용하여 문제를 해결하거나 모델을 구축할 수 있을까?

이를 위해서는 단순히 모델만 고르면 안 된다.

raw data를 모으고,
데이터를 이해하고,
전처리하고,
모델을 학습시키고,
평가하고,
실제 환경에 배포한 뒤 모니터링하는 전체 pipeline이 필요하다.

---

Tabular ML Pipeline

Tabular Data를 활용해 머신러닝 모델을 만드는 과정은
대략 다음과 같은 pipeline으로 정리할 수 있다.

1. Data Collection
2. Exploratory Data Analysis, EDA
3. Preprocessing
4. Modeling
5. Evaluation
6. Deployment & Monitoring

하나씩 정리해보자.

---

1. Data Collection

가장 먼저 해야 할 일은 데이터를 모으는 것이다.

이때 중요한 것은
관련 있는 데이터를 신뢰할 수 있는 출처에서 수집하는 것이다.

예를 들어 고객 이탈 예측 문제를 푼다고 해보자.

고객 정보만 가지고는 부족할 수 있다.

customers table
orders table
products table
payment table

이런 여러 table을 결합해야
더 의미 있는 feature를 만들 수 있다.

예를 들어 다음과 같은 feature를 만들 수 있다.

- 최근 30일 구매 횟수
- 평균 주문 금액
- 마지막 로그인 이후 지난 일수
- 특정 카테고리 구매 비율

또 외부 데이터를 활용할 수도 있다.

예를 들어 매출 예측 문제라면
날씨 데이터나 공휴일 정보를 추가할 수 있다.

timestamp + weather information
date + holiday information

특히 중요한 것은 reproducibility다.

데이터를 어떻게, 언제, 어디서 수집했는지 기록해야 한다.

나중에 모델 성능이 달라졌을 때
데이터 수집 방식이 바뀐 것인지,
모델이 바뀐 것인지 추적할 수 있어야 하기 때문이다.

---

2. EDA

EDA는 Exploratory Data Analysis의 약자다.

말 그대로 모델링 전에
데이터를 탐색하고 이해하는 과정이다.

EDA에서는 다음과 같은 것을 확인한다.

- 평균
- 중앙값
- 사분위수
- 표준편차
- 결측치 패턴
- feature 분포
- feature와 target의 상관관계
- outlier
- class imbalance

예를 들어 고객 이탈 예측 문제에서
Tenure라는 feature가 있다고 해보자.

이 feature는 고객이 서비스를 이용한 기간을 의미한다.

EDA를 통해 다음을 확인할 수 있다.

- 이탈한 고객의 평균 Tenure는 얼마인가?
- 이탈하지 않은 고객과 차이가 있는가?
- Tenure가 너무 작거나 큰 이상치가 있는가?
- 특정 구간에서 이탈률이 높아지는가?

또 classification 문제에서는
target class의 비율도 반드시 봐야 한다.

예를 들어 다음과 같다면 문제가 있다.

Churned = Yes: 5%
Churned = No: 95%

이 경우 모델이 전부 No라고 예측해도
accuracy는 95%가 나온다.

하지만 실제로는 이탈 고객을 잡지 못하는 쓸모없는 모델이 될 수 있다.

그래서 class imbalance가 있는 경우
평가지표도 신중하게 선택해야 한다.

EDA는 단순히 그래프를 그리는 과정이 아니다.

모델링 전에
데이터에 어떤 문제가 있는지 발견하고,
어떤 전처리가 필요한지 판단하는 과정이다.

---

3. Preprocessing

Preprocessing은 Tabular ML에서 매우 중요하다.

raw data는 모델이 바로 이해할 수 있는 형태가 아닐 수 있다.

그래서 데이터를 모델이 학습할 수 있는 형태로 바꾸어야 한다.

PDF에서도 preprocessing은
신뢰할 수 있는 ML pipeline을 만들기 위한 critical step이라고 설명한다.

아무리 강한 모델을 사용해도
입력 데이터가 제대로 준비되어 있지 않으면
성능이 제대로 나오지 않을 수 있다.

Preprocessing에서 주로 다루는 것은 다음과 같다.

1. Missing Value 처리
2. Categorical Variable Encoding
3. Numerical Feature Transformation
4. Feature Engineering

---

3-1. Missing Value 처리

현실 데이터에는 결측치가 많다.

결측치를 처리하는 방법은 여러 가지가 있다.

1. 삭제
2. 특정 값으로 채우기
3. 평균, 중앙값, 최빈값으로 대체
4. 모델 기반 대체
5. 결측치를 직접 처리할 수 있는 모델 사용

예를 들어 Age에 결측치가 있다고 해보자.

ID | Age | Income
1  | 25  | 3000
2  |     | 4200
3  | 31  | 3900

간단한 방법은 평균값으로 채우는 것이다.

Age 평균 = 28

그러면 결측치를 28로 대체할 수 있다.

하지만 무조건 평균으로 채우는 것이 좋은 것은 아니다.

어떤 경우에는 결측 자체가 의미를 가질 수 있다.

예를 들어 고객이 소득 정보를 입력하지 않은 것이
특정 행동 패턴과 관련 있을 수도 있다.

이 경우에는 Unknown 같은 값으로 채우거나,
결측 여부를 나타내는 feature를 추가할 수도 있다.

---

3-2. Categorical Variable Encoding

대부분의 ML 모델은 숫자 입력을 받는다.

따라서 범주형 변수는 숫자로 바꿔줘야 한다.

예를 들어 Contract라는 feature가 있다고 해보자.

Monthly
1-year
2-year

이 값을 그대로 모델에 넣을 수는 없다.

대표적인 encoding 방법은 다음과 같다.

방법	기본 아이디어
One-Hot Encoding	각 category를 binary feature로 변환
Ordinal Encoding	category를 순서 있는 정수로 변환
Target Encoding	category를 target 평균값으로 변환
Embedding Encoding	category마다 vector representation 학습

One-Hot Encoding을 사용하면 다음처럼 바뀐다.

Contract = Monthly

Contract_Monthly = 1
Contract_1year = 0
Contract_2year = 0

One-Hot Encoding은 category 사이에
인위적인 순서를 부여하지 않는다는 장점이 있다.

하지만 category 종류가 너무 많으면
column 수가 지나치게 늘어날 수 있다.

예를 들어 상품 ID가 10만 개라면
one-hot encoding을 그대로 쓰기 어렵다.

반대로 category에 자연스러운 순서가 있다면
Ordinal Encoding을 사용할 수 있다.

예를 들어 티셔츠 사이즈는 순서가 있다.

small < medium < large < x-large

이 경우 다음처럼 숫자로 바꿀 수 있다.

small = 0
medium = 1
large = 2
x-large = 3

---

3-3. Numerical Feature Transformation

숫자형 feature도 그대로 쓰면 안 되는 경우가 있다.

대표적으로 scale 문제가 있다.

예를 들어 다음 두 feature를 보자.

Age: 20 ~ 80
Income: 1,000,000 ~ 100,000,000

두 feature의 값 범위가 너무 다르다.

일부 모델은 feature scale에 민감하다.

그래서 scaling을 적용할 수 있다.

대표적인 방법은 다음과 같다.

Standardization
Min-Max Scaling

Standardization은 평균을 0, 표준편차를 1로 맞추는 방법이다.

x' = (x - mean) / std

Min-Max Scaling은 값을 0과 1 사이로 바꾸는 방법이다.

x' = (x - min) / (max - min)

하지만 모든 모델에 scaling이 중요한 것은 아니다.

Tree-based model은 scale에 비교적 둔감한 경우가 많다.

반면 linear model, logistic regression, neural network, k-NN 같은 모델은
scale의 영향을 더 크게 받을 수 있다.

또 분포 변환도 사용할 수 있다.

예를 들어 소득, 가격, 구매 횟수 같은 변수는
오른쪽으로 긴 꼬리를 가진 분포를 가지는 경우가 많다.

이런 경우 log transform을 사용할 수 있다.

income → log(income)

이렇게 하면 극단적으로 큰 값의 영향을 줄일 수 있다.

---

3-4. Feature Engineering

Feature Engineering은
raw data에서 더 의미 있는 feature를 만들어내는 작업이다.

PDF에서도 feature engineering은
domain knowledge를 활용해 informative feature를 만드는 과정이라고 설명한다.

예를 들어 고객 구매 데이터가 있다고 해보자.

단순히 주문 기록만 쓰는 것이 아니라
다음과 같은 feature를 만들 수 있다.

- 최근 30일 평균 구매 금액
- 최근 7일 방문 횟수
- 마지막 로그인 이후 지난 일수
- 총 구매 금액 / 방문 횟수
- 주말 구매 비율

대표적인 feature engineering 패턴은 다음과 같다.

Pattern	Example
Aggregations	최근 30일 평균 구매 금액
Ratios	부채 대비 소득 비율
Time differences	마지막 로그인 이후 지난 일수
Date decomposition	월, 요일, 공휴일 여부
Interactions	가격 * 수량
Domain-specific features	BMI, 금융 지표

예를 들어 헬스케어 데이터에서는
키와 몸무게만 있는 것보다
BMI를 feature로 만드는 것이 더 유용할 수 있다.

BMI = weight / height^2

금융 데이터에서는
단순 소득보다 부채 대비 소득 비율이
더 중요한 feature가 될 수도 있다.

Debt-to-income ratio = Debt / Income

결국 Tabular ML에서는
모델 선택보다 feature engineering이 더 중요해질 때도 있다.

---

Preprocessing에서 가장 조심해야 할 것: Data Leakage

Preprocessing에서 가장 흔한 실수 중 하나가
data leakage다.

특히 scaling이나 imputation을 할 때 조심해야 한다.

잘못된 예시는 다음과 같다.

X = scaler.fit_transform(X)
X_train, X_test = split(X, ...)

이렇게 하면 전체 데이터에 대해 평균과 표준편차를 계산한 뒤
train/test를 나누게 된다.

문제는 test data의 정보가
preprocessing 과정에서 train data에 섞인다는 것이다.

즉, 모델이 미래의 정보를 미리 본 것과 비슷해진다.

올바른 방식은 다음과 같다.

X_train, X_test = split(X, ...)
X_train = scaler.fit_transform(X_train)
X_test = scaler.transform(X_test)

중요한 점은 다음과 같다.

fit은 training data에만 한다.
validation/test data에는 transform만 적용한다.

왜냐하면 실제 서비스 환경에서는
미래에 들어올 test data의 평균이나 분포를 미리 알 수 없기 때문이다.

이 부분을 잘못 처리하면
모델 성능이 실제보다 과장될 수 있다.

---

4. Modeling

전처리가 끝나면 모델을 선택하고 학습을 진행한다.

Tabular Data에서는 여러 모델을 사용할 수 있다.

대표적으로 다음과 같은 모델들이 있다.

- Linear Regression
- Logistic Regression
- Random Forest
- XGBoost
- LightGBM
- CatBoost
- Deep Neural Networks
- TabPFN

Linear Regression이나 Logistic Regression은
해석이 쉬운 baseline 모델로 사용할 수 있다.

Tree-based ensemble 모델은
Tabular Data에서 강력한 성능을 보이는 경우가 많다.

특히 XGBoost, LightGBM, CatBoost는
Kaggle이나 실무 Tabular ML 문제에서 자주 사용된다.

Deep Learning 모델도 사용할 수 있지만,
Tabular Data는 데이터 크기가 작고 feature type이 다양하기 때문에
항상 딥러닝이 좋은 것은 아니다.

따라서 처음부터 복잡한 모델을 쓰기보다는
baseline 모델부터 시작하는 것이 좋다.

---

5. Evaluation

모델을 학습했다면 평가해야 한다.

Evaluation에서 중요한 것은
단순히 점수 하나를 보는 것이 아니다.

내가 풀고자 하는 task에 맞는 metric을 선택해야 한다.

---

Regression Metric

Regression 문제에서는
연속적인 값을 예측한다.

대표적인 metric은 다음과 같다.

MAE
MSE
RMSE
R2 Score

예를 들어 집값 예측 문제에서는
예측 집값과 실제 집값의 차이를 평가해야 한다.

MAE는 오차의 절댓값 평균이다.

MAE = 평균(|실제값 - 예측값|)

RMSE는 큰 오차에 더 민감하다.

RMSE = sqrt(평균((실제값 - 예측값)^2))

---

Classification Metric

Classification 문제에서는
class를 예측한다.

대표적인 metric은 다음과 같다.

Accuracy
Precision
Recall
F1 Score
AUC-ROC
AUC-PR

이진 분류에서는 다음과 같은 개념이 중요하다.

TP = 실제 Positive를 Positive로 예측
FP = 실제 Negative를 Positive로 예측
FN = 실제 Positive를 Negative로 예측
TN = 실제 Negative를 Negative로 예측

Precision은 모델이 Positive라고 예측한 것 중
실제로 Positive인 비율이다.

Precision = TP / (TP + FP)

Recall은 실제 Positive 중에서
모델이 Positive로 잘 잡아낸 비율이다.

Recall = TP / (TP + FN)

F1 Score는 Precision과 Recall의 조화평균이다.

F1 = Precision과 Recall의 조화평균

---

Metric은 현실의 비용을 반영해야 한다

평가지표는 문제 상황에 따라 달라져야 한다.

예를 들어 사기 탐지 문제에서는
사기 거래가 매우 적다.

이 경우 accuracy만 보면 안 된다.

Fraud Detection → PR-AUC, recall at fixed precision

의료 스크리닝에서는
실제 질병이 있는 사람을 놓치는 것이 치명적일 수 있다.

Medical Screening → Recall 중요

스팸 필터링에서는
정상 메일을 스팸으로 잘못 분류하면 문제가 될 수 있다.

Spam Filtering → Precision 중요

즉, 가장 좋은 metric은
현실에서 어떤 오류가 더 치명적인지를 반영하는 metric이다.

---

Cross-Validation과 Hyperparameter Tuning

Tabular Data는 데이터가 작거나
불규칙한 패턴을 가지는 경우가 많다.

그래서 한 번의 train/test split만으로
모델 성능을 판단하기 어려울 수 있다.

이때 cross-validation을 사용할 수 있다.

Cross-validation은 데이터를 여러 fold로 나누고
여러 번 학습과 검증을 반복하는 방식이다.

Fold 1: train / validation
Fold 2: train / validation
Fold 3: train / validation
...

이렇게 하면
특정 split에만 운 좋게 잘 맞는 모델을 피할 수 있다.

Hyperparameter tuning도
가능하면 cross-validation 성능을 기준으로 해야 한다.

하지만 주의할 점이 있다.

Test set은 최종 평가용으로 남겨두어야 한다.

즉, test set을 hyperparameter tuning에 사용하면 안 된다.

그렇게 하면 test set에 overfitting되는 문제가 생긴다.

---

6. Deployment & Monitoring

모델을 평가해서 성능이 좋다고 끝나는 것은 아니다.

실제 환경에 배포할 때는
training 환경과 deployment 환경이 일관되어야 한다.

예를 들어 학습할 때 scaling을 했다면
서비스에서도 같은 scaling을 적용해야 한다.

Training preprocessing == Deployment preprocessing

이게 맞지 않으면
모델이 학습 때와 전혀 다른 입력을 받게 된다.

배포 이후에는 monitoring도 필요하다.

Monitoring에서는 다음과 같은 것을 추적한다.

- Data drift
- Concept drift
- Performance degradation
- Fairness metrics

Data drift는 입력 데이터의 분포가 바뀌는 것이다.

예를 들어 고객의 평균 구매 금액이
시간이 지나면서 크게 바뀔 수 있다.

Concept drift는
feature와 target의 관계 자체가 바뀌는 것이다.

예를 들어 예전에는 특정 행동이 이탈과 관련 있었지만,
서비스 정책이 바뀌면서 더 이상 관련이 없어질 수 있다.

이런 변화가 발생하면
모델을 재학습하거나 업데이트해야 한다.

---

Interpretability

Tabular ML에서는 해석 가능성도 중요하다.

모델 성능이 높다고 해서 항상 충분한 것은 아니다.

특히 금융, 의료, 제조, 교육 같은 분야에서는
모델이 왜 그런 예측을 했는지 설명할 수 있어야 한다.

해석 가능성은 크게 두 가지 관점에서 볼 수 있다.

Global interpretability
Local interpretability

Global interpretability는
전체 모델에서 어떤 feature가 중요한지 보는 것이다.

예를 들어 고객 이탈 예측 모델에서
가장 중요한 feature가 Tenure인지, Monthly Charge인지 확인하는 것이다.

Local interpretability는
특정 sample 하나에 대해
왜 이런 예측이 나왔는지 보는 것이다.

예를 들어 특정 고객 A가 왜 이탈할 것으로 예측되었는지
그 이유를 설명하는 것이다.

대표적인 방법은 다음과 같다.

- Permutation Importance
- SHAP

Permutation Importance는
특정 feature를 섞었을 때 모델 성능이 얼마나 떨어지는지 보는 방식이다.

성능이 많이 떨어진다면
그 feature가 중요하다고 볼 수 있다.

SHAP은 각 feature가 예측에 얼마나 기여했는지
sample 단위로 설명하는 데 많이 사용된다.

---

Tools & Datasets

Tabular ML을 할 때 자주 사용하는 도구는 다음과 같다.

- NumPy
- Pandas
- scikit-learn
- Optuna
- PyTorch

공개 데이터셋이나 benchmark는 다음과 같은 곳에서 찾을 수 있다.

- Kaggle
- UCI Machine Learning Repository
- OpenML
- AI Hub

특히 Kaggle은 Tabular Data 문제를 연습하기 좋다.

실제 비즈니스 문제처럼
feature engineering, missing value 처리, metric 선택 등을
직접 경험할 수 있기 때문이다.

---

정리

Tabular Data는 우리 주변에서 가장 흔하게 볼 수 있는 데이터 형태다.

고객 데이터, 금융 데이터, 의료 데이터, 제조 데이터, 교육 데이터 등
대부분의 조직 데이터는 행과 열의 형태로 저장된다.

하지만 흔하다고 해서 쉽지는 않다.

Tabular Data는 다음과 같은 어려움을 가진다.

- Feature type이 다양하다.
- Column 순서에 자연스러운 의미가 없다.
- 데이터가 작거나 중간 규모인 경우가 많다.
- Missing value가 자주 발생한다.
- Label이 noisy할 수 있다.
- Class imbalance가 자주 발생한다.
- Domain-specific pattern이 많다.

그래서 Tabular ML에서는
모델만 잘 고르는 것이 중요한 게 아니다.

데이터를 어떻게 모으고,
어떻게 분석하고,
어떻게 전처리하고,
어떤 metric으로 평가하고,
배포 후 어떻게 모니터링할 것인지가 모두 중요하다.

결국 핵심은 이것이다.

Tabular ML은 단순히 표 데이터를 모델에 넣는 작업이 아니라,
raw data를 신뢰할 수 있는 예측 시스템으로 바꾸는 전체 과정이다.

이번 내용을 정리하면서
Tabular Data가 왜 현실 문제에서 중요하게 다뤄지는지 알 수 있었다.

앞으로 Tabular ML을 공부할 때는
모델 성능만 보는 것이 아니라,
데이터 수집부터 전처리, 평가, 배포, 모니터링까지
전체 pipeline 관점에서 바라봐야겠다.