ML vs 딥러닝 — 무엇이 줄어들고 무엇이 남는가
[[ml-problem-framing|← ML 문제 정의 프레임워크]]
## 딥러닝으로 가면 줄어드는 것
**Feature Engineering** — 가장 크게 줄어드는 부분이다. lag_1W, rolling_4W, month 같은 feature를 수동으로 설계할 필요가 줄어든다. LSTM 같은 시계열 딥러닝 모델은 raw 시계열을 그대로 입력받아 "어떤 과거 시점이 얼마나 중요한지"를 스스로 학습한다.
```
기존 ML: 날짜 + 수량 → 사람이 feature 설계 → 모델 학습
딥러닝: 날짜 + 수량 시퀀스 → 모델이 패턴 직접 학습
```
## 줄어들지 않는 것
- **목적 → 손실함수 → 모델 프레임**: LSTM으로 재고 준비를 하려면 여전히 Quantile Loss를 써야 한다. 딥러닝이 이 판단을 대신하지 않는다.
- **EDA와 데이터 이해**: 데이터 구조를 모르면 딥러닝도 망가진다.
- **Distribution shift**: 모델 문제가 아니라 데이터 문제이므로 해결되지 않는다.
- **평가 방법론**: Time Series Split은 딥러닝에서도 동일하게 적용된다.
## 오히려 늘어나는 것
- **데이터 요구량**: LSTM은 주별 500행 수준으로는 제대로 학습하기 어렵다. 일별 수천 행 이상이 필요한 경우가 많다.
- **하이퍼파라미터**: layer 수, hidden size, dropout, learning rate, batch size 등 sklearn보다 훨씬 많아진다.
- **해석 가능성**: "왜 이 예측이 나왔는가"를 설명하기 어렵다. sklearn의 feature_importance 같은 직관적 도구가 없다.
## 비교 요약
| 항목 | 기존 ML | 딥러닝 |
|------|--------|--------|
| Feature engineering | 많음 | 적음 ✅ |
| 문제 정의 (손실함수) | 필요 | 동일하게 필요 |
| 데이터 요구량 | 적어도 됨 | 더 많이 필요 |
| 하이퍼파라미터 | 적음 | 많아짐 |
| 해석 가능성 | 높음 | 낮음 |
| Distribution shift 대응 | 그대로 | 그대로 |
## 결론
딥러닝은 feature engineering 부담을 줄여주지만, ML의 핵심 사고 프레임(문제 정의, 평가, 데이터 이해)은 그대로 필요하다. 데이터가 적은 경우엔 딥러닝이 ML보다 못한 경우도 많다. 딥러닝은 ML의 대체재가 아니라 **데이터가 충분할 때 쓸 수 있는 다른 도구**다.
## 데이터 규모별 DL 적용 가이드
딱 떨어지는 기준은 없지만 실무 기준:
| 집계 단위 | DL 시도 가능 | 안정적 | 이상적 |
|---------|-----------|-------|-------|
| 일별 | ~2,000행 | ~5,000행 | ~10,000행+ |
| 주별 | ~500행 | ~1,000행 | ~2,000행+ |
| 월별 | DL 비추 | DL 비추 | DL 비추 |
계절성이 강한 데이터는 최소 3~5년 사이클을 여러 번 학습해야 한다.
## ML vs DL 이분법보다 중요한 것
LightGBM, XGBoost 같은 gradient boosting 계열은 tabular 데이터 + lag feature 구조에서 LSTM을 이기는 경우가 많다. DL이 항상 더 좋은 것이 아니다.
시계열 전용 모델:
- **Prophet** (Facebook): 계절성 + 트렌드를 명시적으로 모델링. 데이터 적어도 잘 작동하고 해석 가능.
- **N-BEATS, N-HiTS**: DL이지만 LSTM보다 적은 데이터로 작동하도록 설계됨.
## 이 데이터에서 현실적인 선택 순서
```
1. sklearn ML + feature engineering ← 기본
2. Prophet ← 계절성 강한 데이터에 적합
3. LightGBM/XGBoost ← sklearn보다 성능 우위 가능
4. LSTM ← 데이터 더 쌓이면 비교 실험
```