대부분의 모델은 숫자만 이해하지만, 실제 데이터는 범주로 가득합니다: 도시, 요금제, 기기 유형. 인코딩은 그 범주를 숫자 열로 변환하고 — 고르는 방법이 모델이 거기서 배울 수 있는 것을 바꿉니다.
Note
위험은 숫자로 바꾸는 것 자체가 아니라 — 존재하지 않는 순서를 만들거나, 조용히 타깃을 누수시키는 방식으로 바꾸는 것입니다.
세 가지 주요 방법
| 방법 | 하는 일 |
|---|---|
| 원-핫 | 범주마다 하나의 0/1 열 — 가짜 순서 없음 |
| 레이블 | 각 범주 → 정수 — 순서를 암시 |
| 타깃 | 범주 → 그 평균 타깃값 — 강력하지만 쉽게 누수 |
위 그림의 원-핫은 명목 범주의 안전한 기본값입니다 — C가 A보다 크다고 암시하지 않습니다.
각각 언제 맞나
- 원-핫: 값이 적은 명목 범주
- 레이블: 진짜 순서형 범주(소 < 중 < 대)
- 타깃: 고카디널리티 특성 — 단, 신중한 교차검증과 함께만
Watch out
명목 데이터에 레이블 인코딩을 절대 쓰지 마세요. 서울=1, 부산=2, 인천=3은 모델에게 인천이 서울의 '세 배'라고 말하는 것 — 존재하지 않는 관계입니다.
고카디널리티 함정
수백 개 범주를 가진 열을 원-핫하면 수백 개의 희소 열로 폭발합니다. 고카디널리티 특성은 드문 범주를 "기타"로 묶거나, 타깃 인코딩을 — 정답을 누수시킬 수 있으니 신중히 — 쓰세요.
Watch out
전체 데이터로 계산한 타깃 인코딩은 타깃을 학습으로 누수시킵니다. 교차검증 겹 안에서 계산하지 않으면 모델 정확도를 과장하게 됩니다.
SKARI 데이터 편집기의 인코딩
데이터 편집기의 인코딩 도구는 코드 없이 범주형 열을 변환합니다: 열과 방법을 고르고, 새 열을 미리 보고, 전처리 파이프라인의 추적되는 단계로 적용합니다.
- 어떤 범주형 열에도 원-핫·레이블 인코딩
- 적용 전 결과 열 미리보기
- 파이프라인 이력에 기록되어 재현 가능한 모든 단계
Takeaway
각 범주가 무엇이 되는지 정확히 봅니다 — 그리고 그 단계가 스크립트에 묻히지 않고 파이프라인에 남습니다.
자주 묻는 질문
원-핫과 레이블 중?
명목 범주는 원-핫, 레이블은 범주에 진짜 순서가 있을 때만.
트리 모델에 원-핫이 필요한가요?
덜합니다 — 트리는 레이블 값으로 분기할 수 있지만, 명목 데이터엔 원-핫이 여전히 안전하고 선형 모델엔 필수입니다.
타깃 인코딩은 언제 가치 있나요?
원-핫이 폭발하는 고카디널리티 특성 — 단, 누수를 피하려 교차검증 안에서 계산할 때만.
결론
인코딩은 텍스트가 모델이 배울 수 있는 무언가가 되는 지점입니다. 방법을 범주 유형에 맞추고, 카디널리티를 살피고, 누수를 막으면 — 특성이 조작된 순서가 아니라 진짜 신호를 담습니다.
Takeaway
순서를 만들지 않고 범주를 숫자로 — 애매하면 원-핫, 필요할 때만 누수 안전한 타깃 인코딩.
특성 공학
숫자가 된 뒤 무엇을 만들지
데이터 정규화
방금 만든 숫자의 스케일링
교차검증
타깃 인코딩이 살아야 할 곳