콘텐츠로 이동

P4-7.3 보충학습: 전처리 입력 문제 구분

Section ID: P4-7.3 Version: v2026.07.23

보조제목: 결측치, 스케일, 인코딩은 각각 어떤 입력 문제에서 출발하는가

P4-7.2에서는 전처리(preprocessing)가 원시 입력을 모델이 계산할 수 있는 표현으로 바꾸는 일이라는 큰 뜻을 잡았습니다. 그런데 전처리를 처음 배우면 바로 이런 혼란이 생깁니다. 어떤 칼럼은 비어 있고, 어떤 칼럼은 숫자 크기가 제각각이고, 어떤 칼럼은 문자열인데, 이 셋을 왜 같은 전처리라는 한 단어 아래에서 다루는지 잘 감이 오지 않습니다.

이 보충학습의 목적은 전처리 기술 이름을 더 많이 늘리는 데 있지 않습니다. 오히려 지금 입력에 생긴 문제가 무엇인가를 먼저 보고, 그 문제에 맞는 전처리 종류를 나눠 떠올리는 기준을 만드는 데 있습니다.

보충학습: 결측치, 스케일, 인코딩을 어떤 입력 문제로 구분하는가에서 구분할 경계

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

  • 결측치 처리, 스케일 조정, 인코딩은 각각 어떤 입력 문제에 답하는가?
  • 한 칼럼을 볼 때 무엇을 먼저 확인해야 하는가?
  • 같은 칼럼에 전처리 규칙이 하나만 필요한가, 여러 규칙이 함께 붙을 수 있는가?
  • 전처리 종류를 구분한 뒤에도 왜 train에서 배운 규칙을 다시 써야 하는가?

이 절은 먼저 결측치 처리, 스케일 조정, 인코딩을 어떤 입력 문제로 구분할 것인가를 닫습니다. 필터, 래퍼, 임베디드, 차원 축소 구분은 다음 절 P4-7.4에서 이어집니다.

보충학습: 결측치, 스케일, 인코딩을 어떤 입력 문제로 구분하는가에서 복구할 연결

  • 전처리 종류를 기술 이름이 아니라 입력 문제의 종류로 구분할 수 있습니다.
  • 한 칼럼을 보고 비어 있는가, 크기 축이 흔들리는가, 계산 불가능한 표현인가를 먼저 점검할 수 있습니다.
  • 같은 칼럼에도 결측치 처리와 인코딩처럼 여러 규칙이 이어질 수 있다는 점을 설명할 수 있습니다.
  • 전처리 종류를 나눈 뒤에도 규칙 학습은 train에서만 해야 한다는 점을 다시 연결할 수 있습니다.

큰 구도부터 잡기

전처리 종류는 보통 칼럼 이름으로 구분하지 않고, 지금 무엇이 계산을 막고 있는가로 구분합니다.

입력에서 먼저 보이는 문제 먼저 떠올릴 전처리 핵심 질문
값이 비어 있다 결측치 처리(imputation) 이 빈칸을 어떤 규칙으로 다룰까
숫자 크기 축이 너무 다르다 스케일 조정(scaling) 이 숫자들을 어떻게 공정하게 비교할까
문자열, 범주, 등급이 섞여 있다 인코딩(encoding) 이 값을 어떻게 계산 가능한 표현으로 바꿀까

핵심은 전처리 종류가 칼럼의 겉모양이 아니라 계산을 막는 이유를 기준으로 갈린다는 점입니다.

예를 들어 age는 숫자형 칼럼이지만 빈값이 있으면 결측치 처리도 필요합니다. membership_tier는 범주형 칼럼이므로 인코딩이 필요할 수 있고, 그 안에 빈값이 있으면 결측치 처리도 먼저 붙을 수 있습니다. 즉, 한 칼럼에는 전처리 규칙이 하나만 붙는다고 생각하면 금방 막힙니다.

한 칼럼을 볼 때 무엇부터 묻는가

전처리를 처음 나눌 때는 칼럼 하나를 보며 아래 순서로 묻는 편이 가장 안전합니다.

  1. 이 값은 비어 있는가
  2. 이 값은 숫자로 바로 계산 가능한가
  3. 숫자라면 다른 칼럼과 비교할 때 크기 축이 과하게 다른가
  4. 이 값은 순서가 있는 범주인가, 없는 범주인가

이 순서를 고객 표 예시로 보면 다음과 같습니다.

칼럼 먼저 보이는 문제 먼저 붙는 판단
age 일부 값이 비어 있다 결측치 처리 여부를 먼저 본다
monthly_spend 숫자 범위가 매우 크다 스케일 조정이 필요한지 본다
city 문자열 범주다 인코딩이 필요하다
membership_tier 범주지만 순서 의미가 있을 수 있다 인코딩 방식이 순서 의미를 보존해야 하는지 본다

이 표의 목적은 정답 전처리를 외우게 하는 것이 아닙니다. 칼럼마다 먼저 던질 질문이 다르다는 감각을 잡게 하는 데 있습니다.

여기서 한 가지를 더 붙잡아 두는 편이 좋습니다. 숫자형 칼럼이라고 해서 모두 같은 처리 대상은 아닙니다.

숫자처럼 보이는 칼럼 바로 붙잡을 질문 전처리 판단 예
monthly_spend=3200, 6100 다른 숫자 칼럼과 크기 축 차이가 큰가 스케일 조정 검토
age=29, 35 빈값이 있는가, 단위 차이가 과한가 결측치 처리 우선, 스케일은 상황에 따라
zip_code=06236 이 값이 크기를 뜻하는가, 범주 식별자인가 숫자로 보여도 범주/식별자일 수 있어 인코딩 또는 제외 검토

즉, 전처리는 데이터 타입 이름만 보고 정하는 일이 아니라 이 숫자가 실제로 어떤 의미를 갖는가까지 함께 읽는 일입니다.

범주형 값도 같은 방식입니다. 문자열이면 모두 같은 인코딩이라고 생각하면 곧바로 헷갈립니다.

범주형 예 먼저 붙잡을 질문 더 자연스러운 판단
city = Seoul, Busan, Incheon 서로 크고 작음의 순서가 있는가 보통 순서 없는 범주로 보고 인코딩
membership_tier = bronze, silver, gold 단계 순서를 보존해야 하는가 순서 의미를 살릴지 먼저 검토
status = pending, approved, rejected 상태 전이와 의미 차이가 순서인가 구분인가 업무 의미를 먼저 읽고 인코딩 방식 검토

즉, 인코딩 판단도 문자열이다에서 멈추지 않고, 이 범주가 구분만 필요한가, 순서도 중요한가까지 한 번 더 내려가야 합니다.

같은 칼럼에도 여러 규칙이 붙을 수 있다

전처리를 처음 접하면 이 칼럼은 인코딩 대상, 저 칼럼은 스케일 대상처럼 한 칼럼에 한 종류만 붙는다고 생각하기 쉽습니다. 실제로는 그렇지 않습니다.

예를 들어 membership_tier가 문자열 범주이면서 일부 값이 비어 있다면 다음처럼 읽어야 합니다.

  1. 빈값을 어떻게 처리할지 정한다.
  2. 그다음 범주 표현을 어떤 방식으로 인코딩할지 정한다.

숫자형 칼럼도 비슷합니다.

  1. 빈값이 있으면 먼저 결측치 처리 여부를 정한다.
  2. 숫자 축 차이가 크면 스케일 조정을 검토한다.

즉, 전처리 종류는 서로 배타적인 메뉴가 아니라 같은 입력 행에 차례로 붙을 수 있는 규칙 묶음입니다.

flowchart TD
  A["한 칼럼"]
  B["결측이 있는가?"]
  C["수치형으로 계산 가능한가?"]
  D["스케일 차이가 너무 큰가?"]
  E["결측 보정 규칙"]
  F["인코딩 규칙"]
  G["스케일 조정 규칙"]
  H["학습한 규칙을 검증/테스트에 재사용"]

  A --> B
  B -->|예| E --> C
  B -->|아니오| C
  C -->|아니오| F --> H
  C -->|예| D
  D -->|예| G --> H
  D -->|아니오| H

이 흐름은 전처리 종류를 어떻게 구분할까라는 질문이 결국 입력 문제를 어떤 순서로 진단할까라는 질문과 같다는 점을 보여 줍니다.

전처리 종류를 잘못 고르면 어떤 오해가 생기는가

전처리 구분이 헷갈리는 이유는, 문제를 잘못 읽어도 겉으로는 뭔가 처리한 것처럼 보일 수 있기 때문입니다.

잘못된 읽기 실제 문제 왜 위험한가
문자열 칼럼이니 아무 숫자나 붙이면 된다 범주 의미를 잘못 표현한 인코딩 문제 모델이 없는 순서를 있다고 읽을 수 있다
숫자 칼럼이니 스케일만 맞추면 된다 빈값이 남아 있는 결측치 문제 계산이 여전히 끊기거나 왜곡된다
값이 비어 있으니 일단 평균으로 채우면 끝이다 빈값 자체가 중요한 신호일 수 있는 문제 결측의 의미를 지워 버릴 수 있다

이 표가 보여 주는 핵심은 단순합니다. 전처리는 처리했다가 중요한 것이 아니라, 무슨 문제를 처리했다고 판단했는가가 중요합니다.

모델을 먼저 보기보다 입력 문제를 먼저 본다

전처리 설명을 읽다 보면 이 모델은 스케일에 민감하다, 저 모델은 덜 민감하다 같은 문장을 빨리 만나게 됩니다. 이 정보는 중요하지만, 초심자에게 첫 질문은 아닙니다.

먼저는 입력 문제가 무엇인가를 봐야 합니다.

  • 빈값이 있으면 결측치 처리를 먼저 본다.
  • 문자열 범주가 있으면 인코딩을 먼저 본다.
  • 숫자 축 차이가 크면 스케일 조정을 검토한다.

그다음에야 어떤 모델은 이 문제에 더 민감한가를 붙이는 편이 안정적입니다. 예를 들어 거리(distance) 기반 모델이나 경사 기반 최적화는 스케일의 영향을 더 직접적으로 받을 수 있지만, 그 전에 이미 스케일이 다른 숫자축이 문제인가를 먼저 알아야 합니다.

즉, 전처리의 첫 순서는 모델 이름 -> 기술 선택이 아니라 입력 문제 -> 전처리 종류 -> 모델 민감도 확인입니다.

train에서 배운 규칙을 다시 쓰는 이유는 왜 여기서도 중요한가

전처리 종류를 잘 나눴다고 해도, 그 규칙을 어디서 배웠는지가 틀리면 다시 문제가 생깁니다.

예를 들어:

  • 결측치 중앙값을 train이 아니라 test까지 합쳐 계산하면 평가가 새어 나갑니다.
  • 인코딩 범주 목록을 전체 데이터로 먼저 만들면 실제 배포 장면보다 유리한 정보를 미리 본 셈이 됩니다.
  • 스케일 기준을 전체 데이터 평균과 분산으로 잡으면 비교가 공정하지 않게 됩니다.

따라서 전처리 종류를 나누는 판단과 규칙을 학습하는 위치는 따로 기억해야 합니다.

질문 답해야 하는 위치
어떤 전처리 종류가 필요한가 입력 문제를 읽는 현재 절
그 규칙을 어디서 배워야 하는가 P4-7.2의 train 기준 재사용 원칙

이렇게 나누면 무슨 규칙이 필요한가와 그 규칙을 어디서 배웠는가를 섞지 않게 됩니다.

사례 및 예시

예시 1. 같은 고객 표라도 칼럼마다 먼저 붙는 전처리 질문이 다르다

간단한 고객 표를 다시 보겠습니다.

age monthly_spend city membership_tier
29 3200 Seoul gold
없음 6100 Busan silver
35 없음 Incheon 없음

이 표를 볼 때 전처리 판단은 보통 다음처럼 나뉩니다.

칼럼 입력 문제 먼저 떠올릴 규칙
age 빈값이 있다 결측치 처리
monthly_spend 빈값이 있고 숫자 범위가 클 수 있다 결측치 처리 후 스케일 검토
city 문자열 범주다 인코딩
membership_tier 빈값이 있고 범주이며 순서 의미 검토가 필요하다 결측치 처리 후 인코딩 방식 검토

여기서 중요한 것은 전처리 기술 4개를 외우는 것이 아니라, 같은 표를 봐도 칼럼마다 먼저 붙는 질문이 다르다는 점입니다.

체크리스트

  • 전처리 종류를 칼럼 이름이 아니라 입력 문제의 종류로 구분하고 있는가?
  • 지금 보고 있는 칼럼은 빈값, 크기 축, 계산 불가능한 표현 중 무엇이 먼저 문제인가?
  • 한 칼럼에도 결측치 처리와 인코딩처럼 여러 규칙이 차례로 붙을 수 있다는 점을 이해했는가?
  • 전처리의 첫 순서를 입력 문제 -> 전처리 종류 -> 모델 민감도 확인으로 설명할 수 있는가?
  • 한 칼럼에 하나의 전처리만 붙는다고 단순화하고 있지 않은가?
  • 무슨 규칙이 필요한가와 그 규칙을 어디서 배웠는가를 구분하고 있는가?
  • 전처리 규칙 학습은 train에서만 해야 한다는 점을 놓치고 있지 않은가?

출처와 참고 자료