P4-7.2 전처리(preprocessing)¶

Section ID: P4-7.2 Version: v2026.07.20

P4-7.1에서는 어떤 입력을 남길 것인가를 봤습니다. 이제 남긴 입력을 그대로 모델에 던지지 않고, 모델이 읽기 좋은 형태로 정리하는 단계로 넘어갑니다. 이 단계가 전처리(preprocessing)입니다.

이 절의 핵심은 복잡한 라이브러리 문법이 아닙니다. 전처리를 데이터 청소 정도로만 이해하지 않고, 입력 표현을 모델이 다룰 수 있는 형태로 바꾸는 일로 이해하는 데 있습니다.

이 절은 전처리(preprocessing), 결측치 처리(imputation), 스케일(scale) 조정, 범주형 인코딩(encoding)의 기본 뜻을 설명합니다. 뒤 절에서는 이 손잡이를 바탕으로 현재 맥락의 판단을 이어 가고, 입력 표현 변환의 기본 뜻은 이 절과 개념사전을 기준으로 다시 연결합니다.

또 한 가지 중요한 이유가 있습니다. 종종 알고리즘을 먼저 배우고, 전처리는 나중에 붙는 보조 작업이라고 생각합니다. 하지만 실제로는 반대에 가깝습니다. 입력 표현이 정리되지 않으면, 뒤에서 배우는 선형회귀(linear regression), 로지스틱 회귀(logistic regression), k-NN, SVM 같은 알고리즘의 성격도 제대로 읽기 어렵습니다.

이 절은 특정 알고리즘의 부록이 아니라, 알고리즘이 무엇을 입력으로 받는가를 정리하는 공통 기초 절입니다.

학술적으로도 전처리는 주변 작업이 아닙니다. 데이터 마이닝(data mining), 패턴 인식(pattern recognition), 머신러닝(machine learning) 교재와 도구 문서에서는 전처리를 보통 원시 데이터(raw data)를 특징 공간(feature space) 또는 모델 입력(model input)으로 옮기는 독립 단계로 다룹니다. 전처리는 모델 앞에 붙는 잡무가 아니라 학습 가능한 표현을 만드는 단계입니다.

이 관점이 중요한 이유는 간단합니다. 모델은 현실 그 자체를 배우지 않고, 전처리를 거쳐 표현된 입력을 배웁니다. 따라서 전처리를 어떻게 했는가는 모델의 경계(boundary), 거리(distance), 최적화(optimization), 해석 가능성(interpretability)에 직접 영향을 줍니다.

전처리(preprocessing)에서 닫을 질문¶

이 절은 다음 질문에 답합니다.

• 전처리(preprocessing)는 무엇을 바꾸는 단계인가?
• 왜 결측치, 스케일, 범주형 값이 그대로는 문제가 될 수 있는가?
• 어떤 모델은 스케일(scale)에 민감하고, 어떤 모델은 덜 민감한가?
• 훈련 데이터(train data)와 테스트 데이터(test data)에서 전처리를 어떻게 나눠야 하는가?

이 절은 먼저 남긴 입력을 계산 가능하고 비교 가능한 표현으로 어떻게 바꿀 것인가를 닫습니다. 개별 인코더와 스케일러의 세부 설정은 P4-9.1, P4-9.2의 하이퍼파라미터와 튜닝 문맥에서 다시 연결하고, 차원 축소의 목적과 직관은 P4-18.1, P4-18.2에서 이어집니다.

전처리(preprocessing)에서 남길 판단 기준¶

• 전처리를 원시 입력을 더 적합한 표현으로 바꾸는 단계로 설명할 수 있습니다.
• 결측치 보정, 스케일 조정, 범주형 인코딩이 왜 필요한지 말할 수 있습니다.
• 전처리의 fit과 transform을 구분하고, 테스트 데이터에 fit하면 안 되는 이유를 설명할 수 있습니다.
• 파이프라인(pipeline)과 컬럼 변환기(ColumnTransformer)가 왜 실무에서 자주 쓰이는지 입문 수준에서 이해할 수 있습니다.

학습 배경¶

Part 4의 앞 절들은 다음 흐름으로 이어졌습니다.

• P4-4: 데이터를 어떻게 나눌 것인가
• P4-5: 일반화(generalization)가 왜 어려운가
• P4-6: 무엇을 기준으로 평가할 것인가
• P4-7.1: 어떤 입력을 남길 것인가

여기까지 오면 다음 질문이 생깁니다.

남긴 입력을 어떤 형태로 모델에 전달할 것인가?

이 질문이 전처리 절의 자리입니다. 이 절은 커리큘럼상 다음 역할을 맡습니다.

전처리는 입력 설계와 모델 이해 사이를 이어 주는 절입니다.

커리큘럼적으로 보면 이 절은 Module 2와 Module 3의 성격이 바뀌는 경계이기도 합니다. Module 2에서 다룬 데이터 분리, 일반화, 평가 지표는 모델을 공정하게 비교하려면 무엇을 먼저 정리해야 하는가를 다뤘습니다. 반면 Module 3은 실제로 어떤 입력과 어떤 모델 조합으로 실험을 시작할 것인가를 다룹니다. 전처리는 바로 그 전환점에 놓여 있습니다.

이 절을 지나면 독자는 단순히 데이터를 모아 둔 상태에서 벗어나, 비교 가능한 입력 표현을 만든 뒤 모델 후보를 세우는 흐름으로 넘어가게 됩니다. 그래서 P4-7.2는 P4-8 모델 선택(model selection), P4-9 하이퍼파라미터 튜닝(hyperparameter tuning), P4-10 이후 알고리즘 절의 공통 바탕이 됩니다.

주요 학습내용¶

전처리를 처음 들으면 이렇게 잡으면 된다¶

전처리(preprocessing)라는 말을 처음 들으면 어렵게 느껴질 수 있습니다. 하지만 아주 짧게 말하면, 모델이 바로 읽기 어려운 입력을 읽을 수 있게 바꾸는 준비 작업입니다.

사람은 다음 표를 그냥 읽을 수 있습니다.

하지만 많은 모델은 이 표를 그대로는 다루기 어렵습니다.

• 없음이 있으면 계산이 끊깁니다.
• 3200과 29는 크기 축이 너무 다릅니다.
• Seoul, Busan 같은 문자열은 바로 계산하기 어렵습니다.

그래서 전처리는 보통 다음처럼 생각하면 됩니다.

1. 비어 있는 값은 어떤 규칙으로 다룬다.
2. 숫자형 값은 비교가 공정해지도록 기준을 맞춘다.
3. 문자열이나 범주는 계산 가능한 표현으로 바꾼다.

이 과정을 거치면 같은 데이터가 대략 이런 형태의 입력으로 바뀝니다.

즉, 전처리는 새로운 정답을 만드는 일이 아니라, 원래 입력을 모델이 계산할 수 있는 형식으로 다시 쓰는 일입니다.

이 절에서는 이 생각을 세 가지 대표 장면으로 나누어 봅니다.

• 결측치 처리: 비어 있는 값을 어떻게 다룰까
• 스케일 조정: 숫자 축의 크기 차이를 어떻게 맞출까
• 인코딩: 문자열과 범주를 어떻게 계산 가능한 형태로 바꿀까

전처리는 무엇을 하는가¶

scikit-learn 전처리 문서는 raw feature vectors를 다운스트림 추정기(downstream estimator)에 더 적합한 표현으로 바꾸는 여러 함수와 변환기(transformer)를 제공한다고 설명합니다. 이 문장을 입문 수준으로 옮기면 다음과 같습니다.

전처리는 원시 입력을 모델이 더 잘 다룰 수 있는 입력 표현으로 바꾸는 단계다.

전처리는 정답(label)을 바꾸는 작업이 아니라 입력 표현을 바꾸는 작업입니다.

조금 더 학술적으로 표현하면, 전처리는 입력 공간(input space)의 표현을 바꾸어 학습 알고리즘이 더 안정적으로 작동하도록 만드는 변환 집합입니다. 여기에는 결측치 처리, 스케일링, 인코딩뿐 아니라 경우에 따라 정규화(normalization), 특징 생성(feature construction), 차원 축소(dimensionality reduction) 같은 넓은 범주도 포함될 수 있습니다. 이 절은 그중 가장 자주 마주치는 세 범주에 집중합니다.

이 절에서는 전처리를 크게 세 가지로 봅니다.

1. 결측치 처리(imputation)
2. 수치 변환과 스케일링(scaling / normalization)
3. 범주형 표현 변환(encoding)

이 세 가지는 모두 입력 표현을 바꾼다는 공통점을 가집니다. 단, 무엇을 바꾸는지는 다릅니다.

다만 실제 전처리의 종류를 조금 더 넓게 보면, 독자는 다음처럼 큰 지도를 갖고 있는 편이 좋습니다.

이 표의 목적은 전처리의 모든 기술을 한 절에 넣기 위한 것이 아닙니다. 오히려 전처리라는 말이 결측치 평균 채우기만 가리키는 좁은 말이 아니라는 점을 먼저 잡게 하려는 것입니다.

다만 이 책에서는 경계를 분명히 두기 위해, 원래 어떤 입력을 남기고 어떤 표현을 새 특징 후보로 만들 것인가는 주로 P4-7.1의 특징 설계 쪽에 두고, 이 절에서는 남긴 입력을 계산 가능하고 비교 가능한 형태로 바꾸는 일에 집중합니다. 즉, 넓게 보면 특징 생성도 전처리 큰 범주에 들어갈 수 있지만, 이 절의 중심 책임은 결측치 처리, 스케일 조정, 인코딩, 그리고 같은 규칙 재사용에 있습니다.

입문 수준에서는 다음처럼 기억해도 충분합니다.

1. 값을 채우는 전처리
2. 숫자 축을 맞추는 전처리
3. 표현 형식을 바꾸는 전처리
4. 너무 과한 값을 완화하거나 입력 수를 줄이는 전처리

즉, 전처리는 하나의 기술이 아니라 입력 표현을 계산 가능하고 비교 가능하게 만드는 여러 종류의 규칙 묶음입니다.

전처리를 처음 이해할 때는 원시 입력 한 행이 전처리 뒤 어떤 모습으로 바뀌는가를 그려 보는 것이 가장 빠릅니다.

이 비교가 보여 주는 핵심은 단순합니다.

1. 전처리는 정답(label)을 바꾸지 않습니다.
2. 전처리는 입력 한 행을 모델이 계산할 수 있는 형태로 다시 씁니다.
3. 같은 규칙이 다른 행에도 반복 적용되어야 합니다.

즉, 전처리는 데이터를 고치는 일이라기보다 입력 행을 다시 번역하는 일에 가깝습니다.

예를 들어 다음과 같은 문제가 있을 수 있습니다.

따라서 전처리는 정리이면서 동시에 표현 설계입니다.

전처리의 종류를 문제 중심으로 다시 묶으면 다음처럼 읽을 수 있습니다.

이렇게 보면 전처리는 결측치 처리 + 스케일 + 인코딩으로 끝나는 목록이 아니라, 지금 입력에 어떤 종류의 표현 문제가 있는가에 따라 가지가 갈라지는 작업입니다.

이론적으로는 전처리를 다음 두 관점으로 동시에 봅니다.

1. 표현 변환(representation transformation)
   같은 사실을 다른 수치 표현으로 옮기는 일
2. 가정 맞춤(assumption matching)
   모델이나 학습 절차가 기대하는 입력 조건에 더 가깝게 맞추는 일

예를 들어 표준화(standardization)는 단순히 숫자를 줄 세우는 작업이 아니라, 어떤 알고리즘이 더 잘 작동하도록 입력의 중심과 분산을 맞추는 시도입니다. 원-핫 인코딩(one-hot encoding)도 문자열을 숫자로 억지 변환하는 것이 아니라, 계산 가능한 특징 표현으로 바꾸는 작업입니다.

학술적으로 전처리는 모델 앞에 놓인 입력 표현을 변환해, 학습과 추론이 가능한 공간으로 옮기는 단계라고 이해할 수 있습니다.

여기서 중요한 것은 전처리가 데이터를 예쁘게 만드는 일이 아니라 모델이 보게 될 세계를 다시 좌표화하는 일이라는 점입니다. 같은 고객 데이터라도 어떤 값은 비어 있는 상태로 남아 있고, 어떤 값은 지나치게 큰 숫자 축을 가지고 있고, 어떤 값은 문자열이라 계산 자체가 불가능합니다. 전처리는 이 셋을 모두 비교 가능하고 계산 가능한 표현으로 다시 맞추는 과정입니다.

즉, 전처리는 보조 작업이 아니라 모델이 무엇을 같은 종류의 정보로 읽을 수 있게 만들 것인가를 정하는 단계입니다.

이 관점을 더 짧게 붙잡으려면 다음 대비가 도움이 됩니다.

즉, 특징 선택이 입구를 정하는 일이라면 전처리는 그 입구로 들어온 값을 모델의 언어로 번역하는 일입니다.

전처리를 진짜로 이해하려면, 이 번역이 보통 다음 순서로 일어난다는 점도 함께 잡아야 합니다.

flowchart LR
  A["원시 표<br/>결측 / 다른 스케일 / 범주형 텍스트"]
  B["먼저 분할<br/>학습 / 검증 / 테스트"]
  C["학습에서 전처리 규칙 학습<br/>채울 값 / 스케일 통계 / 범주 맵"]
  D["같은 규칙으로 행 변환"]
  E["모델 입력용 행렬"]

  A --> B --> C --> D --> E

이 흐름의 핵심은 네 가지입니다.

1. 원시 표를 바로 모델에 넣지 않는다.
2. 먼저 데이터를 나누고, 규칙은 train에서만 배운다.
3. 배운 규칙을 다른 행들에 반복 적용한다.
4. 그 결과가 비로소 모델 입력 행렬(matrix)이 된다.

즉, 전처리는 값을 조금 손보는 단계가 아니라 원시 표를 모델이 읽을 수 있는 행렬로 재구성하는 단계입니다.

전처리가 없으면 무엇이 바로 무너지는가¶

전처리의 필요성을 가장 짧게 이해하는 방법은 전처리가 없을 때를 보는 것입니다.

즉, 전처리는 성능을 조금 더 올리는 선택 사항이 아니라, 많은 경우 모델이 입력을 읽을 수 있게 만드는 최소 조건입니다.

같은 말을 더 실무적으로 옮기면 다음과 같습니다.

1. 계산이 안 되는 입력은 학습이 안 된다.
2. 비교가 불공정한 입력은 잘못된 경계와 거리를 만든다.
3. 재현되지 않는 규칙은 배포 후 같은 입력을 다시 만들지 못하게 한다.

그래서 전처리는 모델 뒤에 붙는 화장이 아니라, 모델 앞에서 입력 세계를 성립시키는 기초 공사에 가깝습니다.

특징 선택과 전처리는 어떻게 이어지는가¶

P4-7.1에서 특징 선택이 무엇을 남길 것인가를 정하는 일이었다면, 전처리는 남긴 것을 어떻게 표현할 것인가를 정하는 일입니다.

핵심은 선택 이후에도 입력 표현을 더 다뤄야 한다는 점입니다. 남긴 특징은 결측치 처리, 스케일 조정, 인코딩 같은 변환을 거쳐야 비로소 모델이 읽기 좋은 입력 형태가 됩니다.

전처리를 하나의 기술이 아니라 입력 표현을 조정하는 여러 변환의 묶음으로 보면, 바로 다음과 같은 입력 점검 질문이 생깁니다.

• 이 값은 계산 가능한가?
• 이 값의 크기 차이가 학습을 왜곡하는가?
• 이 표현은 거리(distance), 경계(boundary), 최적화(optimization)에 어떤 영향을 주는가?
• 훈련 때 배운 변환 규칙을 추론 시점에도 그대로 재현할 수 있는가?

이 질문들이 중요한 이유는, 뒤에서 만날 알고리즘들이 입력 표현에 서로 다른 방식으로 민감하기 때문입니다.

같은 입력도 전처리 질문이 여러 갈래로 나뉜다는 점을 표로 잡아 두면 덜 헷갈립니다.

이 표는 전처리를 기술 이름이 아니라 입력 문제를 어떤 종류로 진단하고 있는가의 관점으로 다시 읽게 해 줍니다.

여기서 한 걸음 더 나가면, 전처리 판단 순서는 보통 다음처럼 고정해 둘 수 있습니다.

이 순서를 잡아 두면 전처리를 도구 적용 체크리스트보다 입력 표현 설계 절차로 더 안정적으로 이해할 수 있습니다.

전처리 전과 후를 한 장면으로 묶어 보기¶

전처리를 더 구체적으로 이해하려면, 같은 작은 표가 어떻게 바뀌는지를 한 번에 보는 편이 좋습니다.

이 표는 사람 눈으로는 읽을 수 있지만, 모델 입장에서는 바로 쓰기 어렵습니다.

• 없음이 있어 계산이 끊깁니다.
• age와 income은 크기 축이 다릅니다.
• channel은 문자열이라 직접 계산하기 어렵습니다.

같은 표가 전처리 뒤에는 대략 이런 식의 입력으로 바뀝니다.

여기서 봐야 할 핵심은 숫자값 자체보다 구조 변화입니다.

1. 결측치는 규칙에 따라 채워졌습니다.
2. 수치형 값은 같은 비교 축 위로 옮겨졌습니다.
3. 범주형 값은 계산 가능한 열 묶음으로 펼쳐졌습니다.
4. 그 결과 각 행이 같은 형식의 입력 벡터(vector)로 정렬됩니다.

즉, 전처리의 결과는 더 깨끗한 표가 아니라 모델이 같은 구조로 읽을 수 있는 입력 행렬입니다.

이 장면을 붙잡으면 전처리를 부분 기술 세 개로 보지 않고, 서로 다른 값들을 같은 계산 세계로 옮기는 통합 작업으로 이해하기 쉬워집니다.

결측치(missing value)는 왜 먼저 다뤄야 하는가¶

현실 데이터는 자주 비어 있습니다.

• 사용자가 답하지 않은 값
• 센서가 읽지 못한 값
• 나중에만 기록되는 값
• 수집 실패로 빠진 값

이 값들을 그대로 두면 많은 모델과 연산이 바로 진행되지 않습니다. 그래서 전처리 첫 단계에서 빈 값을 어떻게 다룰지를 정하게 됩니다.

scikit-learn의 SimpleImputer 문서는 평균(mean), 최빈값(most frequent), 상수(constant) 같은 전략으로 결측치를 채우는 예를 제공합니다.

여기서 중요한 것은 무조건 채운다가 아닙니다. 왜 그 규칙으로 채우는가입니다.

예를 들어 소득(income) 칼럼은 극단값이 많을 수 있어 평균보다 중앙값이 더 나을 수 있습니다. 반대로 시험 점수처럼 분포가 비교적 고르면 평균이 더 직관적일 수도 있습니다.

업무 장면으로 바꾸면 더 쉽게 읽을 수 있습니다.

결측치는 단순한 빈칸이 아니라 왜 비었는가를 함께 읽어야 하는 입력 상태입니다.

결측치 처리의 종류도 아주 거칠게는 다음처럼 나눠 생각할 수 있습니다.

즉, 결측치 처리는 무엇으로 채울까만의 문제가 아니라, 빈칸의 흔적을 남길까, 아예 버릴까, 대표값으로 근사할까의 선택 문제이기도 합니다.

결측치를 잘못 다루면 어떤 일이 생기는가¶

결측치를 너무 빨리 평균으로 채우면 끝이라고 생각하면 중요한 차이를 놓칠 수 있습니다.

즉, 결측치 처리는 빈칸을 감추는 일이 아니라 빈칸이 어떤 종류의 사건인가를 해석하는 일에 더 가깝습니다.

또 한 가지 중요한 점은, 결측치를 채운 뒤 그 값이 원래 관측값처럼 보이기 시작한다는 점입니다. 그래서 가능하면 독자는 이 칼럼은 관측값인가, 보정값인가를 항상 의식해야 합니다. 전처리는 현실을 그대로 보존하는 작업이 아니라, 계산 가능한 근사 표현을 만드는 작업이기 때문입니다.

이 때문에 결측치 처리에서는 보통 다음 질문을 붙여 두는 편이 좋습니다.

1. 이 칼럼의 결측은 우연한 누락인가, 행동/수집 사건인가?
2. 대표값으로 채워도 의미 왜곡이 크지 않은가?
3. 결측 여부 자체를 별도 신호로 남겨야 하는가?

이 세 질문을 빼면 결측치 처리는 기술 적용이 되기 쉽고, 넣으면 입력 해석이 됩니다.

스케일(scale)은 왜 문제를 만들 수 있는가¶

모든 숫자형 특징이 같은 단위로 움직이지는 않습니다.

예를 들어 다음 두 칼럼을 생각할 수 있습니다.

• 나이(age): 20, 35, 41
• 월소득(monthly_income): 2,000,000 / 4,500,000 / 8,000,000

둘 다 숫자지만 크기 범위가 크게 다릅니다. 어떤 알고리즘은 이런 차이를 그대로 받으면 큰 숫자 축을 더 중요하게 여기기 쉽습니다.

scikit-learn 전처리 문서는 선형 모델(linear models) 같은 여러 학습 알고리즘이 표준화(standardization)의 이점을 보며, 특징 분산이 크게 다르면 목적 함수(objective function)에서 특정 특징이 과도하게 지배할 수 있다고 설명합니다.

스케일 조정은 숫자를 예쁘게 맞추는 일이 아니라, 특징들 사이의 영향력 균형을 다시 맞추는 일이다.

이 설명은 뒤 이론과도 직접 연결됩니다.

• k-NN에서는 거리 계산이 달라집니다.
• SVM에서는 경계가 달라질 수 있습니다.
• 선형 모델과 로지스틱 회귀에서는 최적화가 더 안정적일 수 있습니다.

스케일 조정은 단순 전처리 요령이 아니라, 뒤 알고리즘 절을 이해하는 준비 단계이기도 합니다.

실무 장면에서는 이렇게 읽을 수 있습니다.

어떤 모델이 스케일에 더 민감한가¶

모든 모델이 같은 정도로 스케일에 민감한 것은 아닙니다.

이 차이는 뒤 장에서 더 분명해집니다.

• P4-10 선형회귀(linear regression)
• P4-11 로지스틱 회귀(logistic regression)
• P4-12 k-NN
• P4-13 SVM
• P4-14, P4-15 트리와 앙상블

전처리는 모든 모델에서 똑같이 중요하게 작동하는 것이 아니라, 모델 종류에 따라 더 중요해지기도 합니다.

짧은 대조로 보면 스케일 문제는 더 선명합니다.

즉, 스케일 조정은 작은 숫자를 키우는 기술이 아니라 여러 특징이 비교될 때 어느 축이 과잉 발언하고 있는지 조정하는 기술입니다.

이 때문에 스케일 조정은 단독 기술이라기보다 모델이 어떤 비교 방식을 쓰는가와 함께 읽어야 합니다. 거리를 쓰는 모델이면 더 민감하고, 분할 규칙을 쓰는 트리 계열이면 상대적으로 덜 민감합니다. 전처리는 항상 데이터만의 문제가 아니라 데이터와 모델의 상호작용 문제이기도 합니다.

스케일 조정도 종류를 아주 거칠게 구분하면 다음처럼 볼 수 있습니다.

이 표를 외우는 것이 목표는 아니지만, 스케일링도 하나의 기술명이 아니라 어떤 기준으로 축을 다시 맞출 것인가의 선택이라는 점은 잡아 둘 필요가 있습니다.

또 스케일 조정은 다음처럼 읽으면 덜 헷갈립니다.

즉, 스케일 조정은 비교 기준을 맞추는 도구이지, 특징 선택이나 누수 점검을 대신하는 도구는 아닙니다.

범주형(categorical) 값은 왜 그대로 넣기 어려운가¶

도시 이름, 회원 등급, 상품 카테고리처럼 범주형 값은 현실에서는 자연스럽지만, 많은 모델은 문자열 자체를 직접 계산하지 못합니다.

그래서 범주형 값은 보통 인코딩(encoding)을 거쳐 수치 표현으로 바꿉니다.

범주형 인코딩은 각 범주를 계산 가능한 수치 표현으로 바꾸는 과정입니다.

이런 방식은 보통 원-핫 인코딩(one-hot encoding)이라고 부릅니다.

중요한 점은 문자열을 숫자로 번역했다가 아니라, 모델이 계산 가능한 형태로 표현을 바꿨다는 점입니다.

여기서도 초심자가 자주 헷갈리는 점은 숫자로 바꾸면 순서도 생긴다고 생각하는 것입니다. 하지만 Seoul=1, Busan=2, Incheon=3처럼 임의 번호를 주는 방식은, 실제로 없는 크기 비교를 모델이 오해하게 만들 수 있습니다. 그래서 원-핫 인코딩은 범주 차이는 남기되, 없는 순서를 억지로 만들지 않으려는 선택으로 읽는 편이 맞습니다.

즉, 인코딩은 글자를 숫자로 바꾸는 일이 아니라 범주의 차이를 어떤 수치 구조로 보이게 할 것인가를 정하는 일입니다. 이 점을 놓치면 전처리는 형식 변환처럼 보이지만, 실제로는 의미 보존 문제를 다루고 있다는 사실을 놓치게 됩니다.

인코딩 방식도 입문 수준에서는 다음처럼 구분해 볼 수 있습니다.

이 절에서는 원-핫 인코딩을 중심으로 보지만, 핵심은 범주에 실제 순서가 있는가 없는가를 먼저 구분하는 습관입니다.

예를 들어 다음 두 경우는 겉으로 모두 문자열이지만 읽는 방식이 다를 수 있습니다.

즉, 인코딩은 문자열을 없애는 기술이 아니라 범주의 의미를 계산 가능한 구조로 보존하는 기술입니다.

업무 장면으로 보면 다음과 같습니다.

세부 학습내용¶

실무에서는 전처리를 어떤 문제로 만나게 되는가¶

전처리는 평균 채우기, 스케일러 적용, 인코더 선택처럼 개별 기술 이름으로 외우기 쉽습니다. 하지만 실무에서는 반대로 무슨 입력 문제가 생겼는가에서 출발합니다. 앞에서 본 결측치, 스케일, 범주형 표현 문제도 결국 이 현장 질문의 다른 모습입니다.

즉, 현장에서는 보통 다음 순서로 생각합니다.

1. 지금 들어오는 값에 무엇이 불안정한가?
2. 그 불안정함이 학습과 평가를 어떻게 왜곡하는가?
3. 어떤 전처리 규칙으로 그 왜곡을 줄일 수 있는가?

이 흐름을 가장 단순한 도식으로 그리면 다음과 같습니다.

flowchart TB
  A["원시 입력<br/>결측 / 스케일 차이 / 범주형 텍스트"]
  B["입력 문제 진단<br/>계산 가능한가?<br/>비교가 공정한가?<br/>규칙 재사용이 가능한가?"]
  C["전처리 규칙 선택<br/>보정 / 스케일 / 인코딩"]
  D["일관된 모델 입력<br/>학습과 테스트가 같은 규칙 사용"]

  A --> B
  B --> C
  C --> D

이 도식의 핵심은 전처리가 기술 적용 순서 암기가 아니라 입력 문제 진단 -> 변환 규칙 선택 -> 일관된 입력 재구성의 흐름이라는 점입니다.

대표적인 장면을 표로 묶어 보면 다음과 같습니다.

이 표의 목적은 새 기술을 더 추가하는 데 있지 않습니다. 앞에서 본 결측치 처리, 스케일 조정, 인코딩이 실제 업무에서 어떤 문제로 다시 나타나는지 연결해서 읽게 하는 데 있습니다.

조금 더 구체적으로 보면, 실무 예시는 대개 다음 세 가지 판단으로 다시 묶입니다.

그래서 전처리는 단순한 준비 작업이 아니라, 현실 데이터를 계산 가능하고 비교 가능하며 재현 가능한 입력으로 만드는 설계 단계입니다.

전처리에서 자주 생기는 오해¶

실무 초반에는 다음 오해가 특히 자주 나옵니다.

훈련 데이터와 테스트 데이터에서 왜 같은 규칙을 써야 하는가¶

전처리에서 가장 자주 생기는 실수 중 하나는 훈련 데이터와 테스트 데이터를 섞는 것입니다.

scikit-learn의 common pitfalls 문서는 다음을 강하게 권고합니다.

• 데이터를 먼저 훈련/테스트로 나눈다.
• fit과 fit_transform은 훈련 데이터에서만 한다.
• 테스트 데이터에는 같은 규칙으로 transform만 한다.
• 파이프라인(pipeline)을 쓰면 이 경계를 지키기 쉽다.

테스트 데이터는 평가를 위한 데이터이지, 전처리 규칙을 배우는 데 쓰는 데이터가 아니다.

이를 단순화하면 다음과 같습니다.

flowchart TD
  A["학습 분할"]
  B["전처리 학습 적합<br/>채울 값 / 스케일 / 인코딩 규칙 학습"]
  C["학습 변환"]
  D["테스트 분할"]
  E["테스트 변환<br/>학습한 규칙만 재사용"]

  A --> B --> C
  B --> E
  D --> E

이 도식의 핵심은 fit이 한 번만 훈련 데이터에서 일어난다는 점입니다.

이 차이는 실제로 성능 착시를 만들 수 있습니다.

즉, 전처리의 누수(leakage)는 모델 구조를 안 바꿔도 평가 숫자를 왜곡할 수 있습니다.

이 차이를 더 직접적으로 보면 다음처럼 읽을 수 있습니다.

즉, 전처리 규칙을 어디에서 배웠는가는 모델 선택만큼이나 중요한 평가 조건입니다.

파이프라인(pipeline)과 컬럼 변환기(ColumnTransformer)는 왜 자주 나오는가¶

실무에서는 숫자형과 범주형 칼럼을 다르게 처리해야 하는 경우가 많습니다.

• 숫자형 칼럼: 결측치 보정 + 스케일 조정
• 범주형 칼럼: 결측치 보정 + 원-핫 인코딩

scikit-learn의 Pipeline 문서는 fit과 transform 단계를 연결해 주고, ColumnTransformer 문서는 서로 다른 칼럼 묶음에 서로 다른 변환을 적용하는 예를 보여 줍니다.

즉, 전처리는 개별 기술만 아는 것으로 끝나지 않고, 같은 규칙을 반복 가능하게 적용하는 구조까지 함께 가야 합니다.

커리큘럼 관점에서도 이 구조는 중요합니다. 뒤 절에서 모델 선택(model selection)과 튜닝(tuning)을 배울 때, 실제로는 모델만 바꾸는 것이 아니라 전처리 + 모델 묶음을 함께 비교하게 되는 경우가 많기 때문입니다.

어떤 전처리 질문을 먼저 던져야 하는가¶

전처리는 기술 이름을 외우는 일보다, 현재 입력이 어떤 문제를 만들고 있는지 빠르게 진단하는 일이 먼저입니다.

이 표는 전처리를 도구 적용 목록이 아니라 입력 문제에 대한 응답 규칙으로 읽게 해 줍니다.

좋은 전처리 설명은 보통 다음 문장으로 요약할 수 있어야 합니다.

1. 어떤 입력 문제가 있었는가
2. 왜 그 문제가 모델 계산을 방해했는가
3. 어떤 규칙으로 바꾸었는가
4. 그 규칙을 train과 test에 어떻게 동일하게 재사용했는가

이 네 문장이 설명되지 않으면, 전처리는 기술 이름만 남고 판단 이유는 비어 있을 가능성이 큽니다.

여기에 한 문장을 더 붙이면 더 완전해집니다.

1. 이 규칙이 어떤 모델 계열에서 특히 중요해지는가

예를 들어 스케일 조정은 k-NN, SVM, 선형 모델에서 더 민감하고, 인코딩은 문자열을 직접 못 읽는 다수 모델에서 필수에 가깝습니다. 즉, 전처리 설명은 입력 문제로 시작하지만, 항상 모델 연결까지 가야 밀도가 생깁니다.

사례 및 예시¶

사례 1. 같은 고객 데이터라도 전처리 규칙이 없으면 비교가 무너질 때¶

이커머스 팀이 고객 이탈 예측 실험을 하고 있습니다. 사람이 먼저 보던 기준은 최근 구매 금액, 방문 횟수, 유입 채널, 회원 등급 같은 입력이었습니다.

문제는 이 값들이 제각각이라는 점입니다. 구매 금액은 수천 단위 숫자이고, 방문 횟수는 한 자릿수일 수 있으며, 유입 채널은 문자열이고, 일부 고객은 소득이나 지역 정보가 비어 있습니다. 이 상태로 모델에 바로 넣으면 어떤 칼럼은 계산이 불가능하고, 어떤 칼럼은 거리 계산이나 최적화에서 과도한 영향력을 가지게 됩니다.

이때 전처리는 입력을 모델이 다룰 수 있는 표현으로 바꾸는 규칙이 됩니다. 결측치는 어떤 기준으로 채울지 정하고, 숫자형은 필요하면 스케일을 맞추고, 범주형은 인코딩해 동일한 규칙으로 훈련 데이터와 테스트 데이터에 적용해야 합니다. 특히 테스트 데이터에 fit하지 않고 훈련 데이터에서 배운 규칙만 재사용하는 점이 중요합니다.

확인 가능한 결과는 전처리 전후 비교와 데이터 분할 절차에서 드러납니다. 스케일 조정 전후의 모델 성능 차이, 문자열 칼럼 인코딩 여부, 훈련 데이터에서 계산한 중앙값을 테스트 데이터에도 그대로 썼는지 등을 확인하면 왜 전처리가 단순 청소가 아니라 입력 표현 설계인지 설명할 수 있습니다.

이 사례를 흐름으로 그리면, 전처리는 데이터 청소 한 번이 아니라 칼럼 상태별 규칙을 세우고 같은 규칙을 다시 쓰는 과정이라는 점이 더 잘 보입니다.

flowchart TD
  A["고객 표<br/>결측 / 수치형 / 범주형이 섞임"]
  B["결측치 규칙<br/>학습 통계로 채움"]
  C["수치형 규칙<br/>선택 칼럼 스케일 조정"]
  D["범주형 규칙<br/>채널 / 등급 인코딩"]
  E["같은 변환 규칙<br/>검증 / 테스트에 재사용"]
  F["비교 가능한 모델 입력"]

  A --> B
  A --> C
  A --> D
  B --> E
  C --> E
  D --> E
  E --> F

사례 및 예시¶

작은 예시로 전처리 장면을 읽어 보기¶

다음 데이터를 생각해 보겠습니다.

여기서 독자가 먼저 보게 되는 질문은 다음과 같습니다.

1. 비어 있는 값은 어떻게 할 것인가?
2. age와 income은 크기 차이가 큰데 조정이 필요한가?
3. city는 문자열인데 어떻게 표현할 것인가?

가능한 입문적 판단은 다음과 같습니다.

이 예시는 실제 정답 하나를 강요하지는 않습니다. 중요한 것은 칼럼별로 다른 질문을 던진다는 점입니다.

같은 데이터를 다른 모델에 넣는다고 상상하면 판단이 더 분명해집니다.

따라서 전처리는 데이터만 보고 끝나는 절이 아니라 모델 후보와 함께 다시 읽는 절이기도 합니다.

이 지점이 중요한 이유는, 같은 데이터라도 전처리 + 모델 조합이 함께 하나의 실험 단위가 되기 때문입니다. 즉 로지스틱 회귀를 비교한다는 말은 실제로는 결측 처리 + 스케일 조정 + 인코딩 + 로지스틱 회귀 묶음을 비교하는 경우가 많습니다.

연습 및 예제¶

Python 예제로 결측치, 스케일, 인코딩을 순서대로 보기¶

아래 예제는 개념을 보여 주기 위해 순수 Python으로 단순화한 전처리 흐름입니다.

문제 상황:

• 전처리는 한 번에 끝나는 마법이 아니라 결측치 처리, 스케일 조정, 인코딩을 차례로 거치는 과정이다

입력(input):

• 결측치가 섞인 행 목록 rows

기대 출력(output):

• 결측치를 채운 결과
• 스케일 조정된 숫자형 값
• 인코딩된 범주형 값

확인할 개념:

• 전처리는 데이터를 계산 가능한 입력 행렬로 바꾸는 순차 작업이다
• 각 단계 결과를 따로 출력해 보면 어떤 변화가 일어났는지 더 분명해진다

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

# 결측치, 범주 인코딩, 스케일 조정으로 모델 입력을 전처리하는 예제입니다.
rows = [
    {"age": 29, "income": 3200, "city": "Seoul"},
    {"age": 41, "income": 6100, "city": "Busan"},
    {"age": None, "income": 5800, "city": "Seoul"},
    {"age": 35, "income": None, "city": "Incheon"},
]

def median(values):
    sorted_values = sorted(values)
    n = len(sorted_values)
    mid = n // 2
    if n % 2 == 0:
        return (sorted_values[mid - 1] + sorted_values[mid]) / 2
    return sorted_values[mid]

age_fill = median([row["age"] for row in rows if row["age"] is not None])
income_fill = median([row["income"] for row in rows if row["income"] is not None])

filled_rows = []
for row in rows:
    filled_rows.append({
        "age": row["age"] if row["age"] is not None else age_fill,
        "income": row["income"] if row["income"] is not None else income_fill,
        "city": row["city"],
    })

ages = [row["age"] for row in filled_rows]
incomes = [row["income"] for row in filled_rows]

age_mean = sum(ages) / len(ages)
income_mean = sum(incomes) / len(incomes)

age_std = (sum((x - age_mean) ** 2 for x in ages) / len(ages)) ** 0.5
income_std = (sum((x - income_mean) ** 2 for x in incomes) / len(incomes)) ** 0.5

cities = sorted({row["city"] for row in filled_rows})

processed_rows = []
for row in filled_rows:
    city_vector = [1 if row["city"] == city else 0 for city in cities]
    processed_rows.append({
        "age_z": round((row["age"] - age_mean) / age_std, 2),
        "income_z": round((row["income"] - income_mean) / income_std, 2),
        "city_onehot": city_vector,
    })

print("age_fill   :", age_fill)
print("income_fill:", income_fill)
print("cities     :", cities)
print()
print("processed rows:")
for row in processed_rows:
    print(row)

실행 결과는 다음과 같습니다.

1
2
3
4
5
6
7
8
9

age_fill   : 35
income_fill: 5800
cities     : ['Busan', 'Incheon', 'Seoul']

processed rows:
{'age_z': -1.43, 'income_z': -1.61, 'city_onehot': [0, 0, 1]}
{'age_z': 1.39, 'income_z': 1.03, 'city_onehot': [1, 0, 0]}
{'age_z': 0.0, 'income_z': 0.76, 'city_onehot': [0, 0, 1]}
{'age_z': 0.0, 'income_z': -0.18, 'city_onehot': [0, 1, 0]}

이 예제는 세 가지를 한 번에 보여 줍니다.

• 결측치는 채웠다.
• 숫자형 값은 비교 가능한 스케일로 옮겼다.
• 범주형 값은 계산 가능한 벡터로 바꿨다.

즉, 전처리는 데이터를 더 예쁘게 만드는 작업이 아니라 계산 가능한 입력 행렬(matrix)로 바꾸는 과정입니다.

Python 예제로 스케일이 거리 계산을 어떻게 바꾸는지 보기¶

스케일 조정이 왜 중요한지는 거리(distance)를 계산해 보면 더 직관적입니다.

문제 상황:

• 거리 기반 모델에서는 어떤 축의 값 범위가 더 큰지에 따라 가까움 판단이 왜곡될 수 있다

입력(input):

• 원본 점 point_a, point_b, point_c
• 스케일 조정 뒤 점 scaled_a, scaled_b, scaled_c

기대 출력(output):

• 원본 거리 raw_ab, raw_ac
• 스케일 조정 뒤 거리 scaled_ab, scaled_ac

확인할 개념:

• 스케일 조정 전후에는 같은 샘플도 거리 관계가 달라질 수 있다
• 전처리는 모델 입력을 더 예쁘게 만드는 일이 아니라 계산 기준을 맞추는 일이다

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 결측치, 범주 인코딩, 스케일 조정으로 모델 입력을 전처리하는 예제입니다.
point_a = {"age": 20, "income": 2000}
point_b = {"age": 40, "income": 2200}
point_c = {"age": 21, "income": 8000}

def distance(p, q):
    return ((p["age"] - q["age"]) ** 2 + (p["income"] - q["income"]) ** 2) ** 0.5

raw_ab = round(distance(point_a, point_b), 2)
raw_ac = round(distance(point_a, point_c), 2)

scaled_a = {"age": 0.0, "income": 0.0}
scaled_b = {"age": 1.0, "income": 0.03}
scaled_c = {"age": 0.05, "income": 1.0}

scaled_ab = round(distance(scaled_a, scaled_b), 2)
scaled_ac = round(distance(scaled_a, scaled_c), 2)

print("raw distance A-B   :", raw_ab)
print("raw distance A-C   :", raw_ac)
print("scaled distance A-B:", scaled_ab)
print("scaled distance A-C:", scaled_ac)

실행 결과는 다음과 같습니다.

1
2
3
4

raw distance A-B   : 201.0
raw distance A-C   : 6000.0
scaled distance A-B: 1.0
scaled distance A-C: 1.0

이 예시는 원래 거리 계산에서 소득(income) 축이 거의 전부를 지배하다가, 스케일 조정 후에는 나이(age)와 소득이 더 비슷한 비중으로 읽힐 수 있음을 보여 줍니다.

이 때문에 k-NN, SVM, 선형 모델 같은 절에서는 전처리 설명이 다시 중요해집니다.

세부 학습내용 보충¶

scikit-learn에서 자주 보는 전처리 도구 이름¶

이름을 전부 외울 필요는 없지만, 어떤 범주가 있는지는 알아 두면 이후 절의 예제를 읽기 쉬워집니다.

여기서 남길 기준은 API 암기가 아닙니다. 먼저 각 도구가 어떤 표현 문제를 해결하려고 등장했는가를 이해해야 합니다.

체크리스트¶

• 지금 마주한 입력 문제를 결측치, 스케일, 범주형 표현 중 어디로 분류할 수 있는가?
• 테스트 데이터가 전처리 규칙을 배우는 데 섞이지 않도록 fit과 transform을 구분하고 있는가?
• 전처리를 모델 앞의 청소가 아니라 재현 가능한 입력 표현 설계로 설명할 수 있는가?
• 전처리가 입력을 더 적합한 표현으로 바꾸는 단계이며, 결측치·스케일·범주형 표현은 서로 다른 문제라는 점을 설명할 수 있는가
• fit은 훈련 데이터에서만 하고 테스트 데이터에는 같은 규칙으로 transform만 해야 하는 이유를 설명할 수 있는가
• 파이프라인과 컬럼 변환기가 전처리 규칙을 반복 가능하게 유지해 주는 구조라는 점을 설명할 수 있는가

출처와 참고 자료¶

• scikit-learn, 8.3. Preprocessing data, scikit-learn User Guide, 확인 날짜: 2026-06-26. https://scikit-learn.org/stable/modules/preprocessing.html
• scikit-learn, 8.4. Imputation of missing values, scikit-learn User Guide, 확인 날짜: 2026-06-26. https://scikit-learn.org/stable/modules/impute.html
• scikit-learn, 8.1. Pipelines and composite estimators, scikit-learn User Guide, 확인 날짜: 2026-06-26. https://scikit-learn.org/stable/modules/compose.html
• scikit-learn, 12. Common pitfalls and recommended practices, scikit-learn User Guide, 확인 날짜: 2026-06-26. https://scikit-learn.org/stable/common_pitfalls.html