데이터 전처리

데이터셋을 이해했다고 해서 바로 좋은 모델이 나오는 것은 아닙니다. 이제 남은 일이 하나 있습니다. 데이터를 모델이 읽을 수 있는 형태로 바꾸는 일입니다. 이 과정을 전처리라고 부릅니다.

처음 머신러닝을 배울 때 전처리는 종종 귀찮은 준비 작업처럼 보입니다. 빈칸을 채우고, 문자열을 숫자로 바꾸고, 값의 크기를 맞추는 반복 작업처럼 느껴지기 쉽습니다. 하지만 실무에서는 오히려 이 단계가 모델의 성능과 안정성을 크게 갈라놓습니다. 같은 알고리즘을 써도 전처리가 다르면 결과는 꽤 달라집니다.

쉽게 말해 전처리는 재료 손질과 비슷합니다. 같은 냄비와 같은 레시피를 써도 재료를 어떻게 손질했는지에 따라 음식 맛이 달라지듯, 같은 모델도 데이터를 어떻게 다듬었는지에 따라 전혀 다른 성능을 냅니다. 그래서 전처리는 모델 앞의 청소가 아니라, 모델이 배울 세계를 설계하는 일입니다.

전처리는 데이터를 모델의 언어로 번역하는 일이다

사람은 서울, VIP, 미입력, 좋아요, 보통, 배송이 느려요 같은 표현을 곧바로 이해할 수 있습니다. 하지만 많은 머신러닝 모델은 그렇지 않습니다. 모델은 보통 숫자 벡터, 즉 계산 가능한 형태의 입력을 기대합니다.

문제는 현실의 데이터가 그렇게 단정하지 않다는 데 있습니다. 어떤 열은 값이 비어 있고, 어떤 열은 범주가 너무 많고, 어떤 숫자 열은 단위 차이가 너무 큽니다. 나이는 20, 30, 40 수준인데 매출은 수만, 수십만 단위일 수 있습니다. 주소는 문자열이고, 리뷰는 문장이고, 가입일은 날짜입니다. 이 복잡한 현실을 모델이 소화할 수 있게 바꾸는 과정이 바로 전처리입니다.

좋은 전처리는 두 가지를 동시에 만족해야 합니다. 첫째, 모델이 계산할 수 있어야 합니다. 둘째, 원래 데이터가 가진 의미를 너무 많이 훼손하지 않아야 합니다. 계산은 쉬워졌는데 의미가 사라지면, 모델은 숫자를 잘 다뤄도 현실 문제를 잘 풀지 못합니다.

결측치는 빈칸이 아니라 해석의 문제다

전처리에서 가장 먼저 마주치는 것은 결측치입니다. 엑셀의 빈칸, 데이터베이스의 null, 판다스의 NaN 같은 것들입니다. 초보자는 여기서 흔히 "일단 평균으로 채우면 되지 않나?"라고 생각합니다. 틀린 말은 아니지만, 항상 좋은 선택은 아닙니다.

결측치를 다룬다는 것은 사실 빈칸을 메우는 일이 아니라, 비어 있는 이유를 해석하는 일에 가깝습니다. 값이 왜 비었는지에 따라 처리 전략도 달라져야 하기 때문입니다.

예를 들어 고객 연봉 정보가 비어 있다고 해봅시다. 이 빈칸은 입력 실수일 수도 있지만, 애초에 입력이 선택 사항이었기 때문일 수도 있습니다. 병원 데이터에서 특정 검사값이 없는 경우는 장비 문제 때문일 수도 있고, 의사가 그 검사를 아예 시행하지 않았기 때문일 수도 있습니다. 즉 결측은 단순한 오류가 아니라 수집 과정의 흔적일 수 있습니다.

평균 대체는 가장 단순하지만 가장 조심해야 한다

평균 대체는 결측값을 해당 열의 평균으로 채우는 방법입니다. 구현이 쉽고 빠르다는 큰 장점이 있습니다. 데이터 양이 많고 결측 비율이 낮을 때, 그리고 값의 분포가 크게 치우치지 않았을 때는 꽤 실용적입니다.

하지만 평균은 극단값에 약합니다. 예를 들어 고객 소비 금액 데이터처럼 일부 고액 사용자 때문에 분포가 한쪽으로 길게 늘어진 경우, 평균은 현실의 전형적인 값을 잘 대표하지 못할 수 있습니다. 이럴 때 평균으로 채우면 실제보다 큰 값이 결측 구간에 들어가 모델을 헷갈리게 만들 수 있습니다.

또한 평균 대체는 결측이 가진 개별적인 차이를 지워 버립니다. 빈칸이 많을수록 값들이 평균 근처로 몰리기 때문에 데이터의 분산이 줄고, 모델이 배울 수 있는 신호도 약해질 수 있습니다.

평균 대체는 간단하고 빠르지만, "모든 빈칸을 평범한 값으로 취급하겠다"는 가정을 깔고 있습니다. 그 가정이 문제에 맞는지 항상 먼저 생각해야 합니다.

중앙값 대체는 튀는 값이 많은 데이터에서 더 안전하다

중앙값 대체는 결측값을 가운데 값으로 채우는 방법입니다. 평균보다 덜 화려하지만, 실무에서는 종종 더 믿음직합니다. 특히 소득, 결제 금액, 사용 시간처럼 극단값이 섞이기 쉬운 데이터에서는 중앙값이 더 안정적입니다.

예를 들어 대부분의 주문 금액은 1만 원에서 5만 원 사이인데, 아주 일부 대량 주문이 100만 원 이상인 상황이라면 평균은 위로 끌려갑니다. 이런 경우 중앙값은 보통 사용자에 더 가까운 값이 됩니다.

그렇다고 중앙값이 만능은 아닙니다. 분포의 꼬리가 중요한 문제에서는 너무 평평한 값으로 채우는 셈이 될 수 있습니다. 그래도 평균과 중앙값 중 하나를 골라야 한다면, 값이 치우쳐 있을 가능성이 큰 실무 데이터에서는 중앙값부터 검토하는 경우가 많습니다.

별도 범주 처리는 결측 자체를 신호로 남긴다

범주형 데이터에서는 결측을 아예 하나의 범주로 다루는 방법이 자주 쓰입니다. 예를 들어 직업 열이 비어 있으면 미입력 또는 알 수 없음이라는 새 범주를 만드는 식입니다.

이 방식의 장점은 분명합니다. 결측 자체가 의미를 가질 수 있다는 사실을 모델에 그대로 전달할 수 있습니다. 예를 들어 프로필 정보를 잘 채우지 않는 사용자가 특정 행동 패턴을 보인다면, 미입력이라는 상태가 하나의 예측 신호가 될 수 있습니다.

다만 이 방법도 해석이 필요합니다. 정말 미입력이 하나의 의미 있는 상태인지, 아니면 단순한 시스템 누락인지 구분해야 합니다. 아무 생각 없이 새로운 범주만 만들면, 실제로는 같은 이유가 아닌 여러 종류의 결측을 하나로 뭉개 버릴 수도 있습니다.

숫자형 데이터에서도 비슷한 아이디어를 쓸 수 있습니다. 값을 중앙값으로 채우되, 동시에 is_missing 같은 결측 여부 열을 추가하는 것입니다. 그러면 모델은 채운 값과 결측 여부를 함께 볼 수 있습니다. 실무에서 꽤 유용한 패턴입니다.

어떤 결측치 처리가 좋은지는 데이터의 성격이 결정한다

결측치 처리에는 정답 하나가 있는 것이 아닙니다. 대신 판단 기준은 있습니다.

• 결측 비율이 매우 낮고 분포가 안정적이면 단순 대체가 실용적입니다.

• 값의 치우침이 크면 평균보다 중앙값이 더 안전할 수 있습니다.

• 결측 자체가 행동 신호일 수 있으면 별도 범주나 결측 여부 표시가 유리합니다.

• 결측이 너무 많고 이유도 불분명하면 해당 열을 아예 쓰지 않는 편이 나을 때도 있습니다.

중요한 것은 결측치를 없애는 것이 목표가 아니라, 결측이 있는 현실을 모델이 다룰 수 있게 만드는 것이 목표라는 점입니다.

범주형 데이터는 숫자로 바꿔야 하지만, 아무 숫자나 넣으면 안 된다

머신러닝 초보자가 자주 하는 실수 중 하나는 문자열 범주를 임의의 숫자로 바꾸는 것입니다. 예를 들어 서울=1, 부산=2, 대전=3처럼 치환하는 방식입니다. 보기에는 깔끔하지만, 많은 모델은 이 숫자들 사이에 크기와 순서가 있다고 받아들일 수 있습니다. 그러면 모델은 부산이 서울보다 크고 대전은 그 중간쯤이라는 식의 이상한 구조를 상상하게 됩니다.

그래서 범주형 데이터는 대개 인코딩이라는 과정을 거쳐야 합니다. 인코딩은 범주를 모델이 다룰 수 있는 수치 표현으로 바꾸는 방법입니다. 중요한 것은 범주의 의미와 개수, 그리고 사용할 모델에 따라 적절한 인코딩 방식이 달라진다는 점입니다.

원-핫 인코딩은 가장 직관적이고 가장 자주 쓰인다

원-핫 인코딩은 범주마다 별도의 열을 만들어 해당 범주이면 1, 아니면 0으로 표시하는 방법입니다. 예를 들어 결제 수단이 카드, 계좌이체, 간편결제라면 세 개의 열을 만들고 각 행에서 하나만 1이 됩니다.

이 방식의 장점은 해석이 쉽다는 데 있습니다. 범주 사이에 가짜 순서를 만들지 않고, 각 범주를 독립적으로 표현할 수 있습니다. 로지스틱 회귀나 선형 모델처럼 입력 열의 의미가 비교적 직접적인 모델에서는 특히 잘 어울립니다.

하지만 범주의 종류가 너무 많아지면 문제가 생깁니다. 예를 들어 상품 코드가 수만 개, 지역 코드가 수천 개인 경우 원-핫 인코딩을 하면 열이 지나치게 많아집니다. 이렇게 만들어진 데이터는 대부분 0이고 일부만 1인 희소 행렬이 됩니다. 저장과 계산이 비효율적일 뿐 아니라, 드물게 등장하는 범주에 대해 모델이 일반화하기도 어려워집니다.

즉 원-핫 인코딩은 범주 수가 적거나 중간 정도일 때 가장 편안한 선택입니다. 직관적이지만, 범주가 폭발적으로 많아지는 순간 부담이 커집니다.

빈도 인코딩은 범주 수가 많을 때 현실적인 타협안이다

빈도 인코딩은 각 범주를 그 범주의 등장 빈도나 비율로 바꾸는 방법입니다. 예를 들어 서울이 전체의 40퍼센트, 부산이 20퍼센트라면 각각 0.4, 0.2 같은 값으로 바꾸는 식입니다.

이 방식의 장점은 열 수가 늘어나지 않는다는 점입니다. 범주가 수천 개여도 하나의 숫자 열로 표현할 수 있습니다. 그래서 카드사 코드, 상품 ID, 판매자 ID처럼 고유값이 많은 열에서 가볍게 시도해 볼 수 있습니다.

다만 빈도는 범주의 의미 자체를 직접 표현하지는 않습니다. 등장 빈도가 비슷한 두 범주는 같은 숫자에 가까워질 수 있고, 빈도가 높다고 해서 예측과 더 관련 있다는 뜻도 아닙니다. 즉 이 방법은 의미를 풍부하게 보존한다기보다, 모델이 다룰 수 있는 형태로 압축하는 타협에 가깝습니다.

그래도 범주 수가 너무 많아 원-핫 인코딩이 부담스러울 때는 꽤 실용적입니다. 특히 트리 계열 모델과 함께 쓸 때 의외로 잘 버티는 경우가 있습니다.

해싱은 새로운 범주가 계속 들어오는 환경에서 강하다

해싱 인코딩은 범주 값을 해시 함수로 일정한 개수의 칸에 매핑하는 방법입니다. 쉽게 말해 범주가 아무리 많아도 미리 정한 크기의 숫자 공간에 집어넣는 방식입니다.

이 방법은 매우 큰 범주 공간이나 계속 새 값이 생기는 환경에서 강점을 보입니다. 예를 들어 검색어, 사용자 ID, URL, 로그 이벤트처럼 종류가 끝없이 늘어나는 데이터에서는 원-핫 인코딩을 유지하기가 어렵습니다. 해싱은 이런 문제를 꽤 우아하게 처리합니다.

대신 단점도 분명합니다. 서로 다른 범주가 같은 칸에 떨어지는 충돌이 생길 수 있습니다. 그리고 어떤 해시 칸이 원래 어떤 범주였는지 해석하기가 어렵습니다. 즉 실용성과 해석 가능성을 맞바꾸는 셈입니다.

그래서 해싱은 "의미를 세밀하게 읽어야 하는 분석"보다는 "대규모 시스템에서 안정적으로 처리해야 하는 입력"에 더 잘 어울립니다.

인코딩 방식은 범주의 개수와 모델의 성격으로 고른다

범주형 인코딩을 고를 때는 몇 가지 현실적인 질문을 던지면 판단이 쉬워집니다.

• 범주의 종류가 적은가, 많은가?

• 새로운 범주가 운영 중에도 계속 생기는가?

• 해석 가능성이 중요한가?

• 계산 비용과 메모리 사용량이 민감한가?

대체로 범주 수가 적으면 원-핫 인코딩이 가장 무난합니다. 범주 수가 아주 많으면 빈도 인코딩이나 해싱을 고려할 수 있습니다. 운영 환경에서 처음 보는 값이 자주 등장한다면 해싱의 장점이 커집니다. 반대로 모델의 입력을 사람이 해석해야 한다면 원-핫처럼 직관적인 방식이 더 좋습니다.

중요한 것은 인코딩이 단지 기술 선택이 아니라, 데이터의 의미를 어떤 방식으로 압축할지 결정하는 표현 선택이라는 점입니다.

숫자형 데이터는 값의 크기보다 비율과 거리 때문에 문제를 일으킨다

숫자형 열은 이미 숫자니까 손댈 것이 없어 보일 수 있습니다. 하지만 실제로는 숫자형 데이터도 자주 전처리가 필요합니다. 가장 대표적인 이유가 스케일 차이입니다.

예를 들어 고객 데이터에 나이, 월 방문 수, 누적 구매 금액이 있다고 해봅시다. 나이는 보통 20에서 70 사이, 방문 수는 0에서 30 사이, 구매 금액은 수십만 원에서 수백만 원 사이일 수 있습니다. 이 상태로 모델에 넣으면 어떤 알고리즘은 금액 열에 훨씬 더 크게 끌릴 수 있습니다. 값의 의미 때문이 아니라 숫자 크기 자체가 커서 그렇게 되는 것입니다.

모델이 이런 차이에 민감한 경우, 스케일을 맞춰 주는 작업이 필요합니다. 이때 많이 쓰는 것이 정규화와 표준화입니다.

정규화는 값을 일정한 범위로 맞춘다

정규화는 보통 값을 0과 1 사이 같은 일정한 범위로 압축하는 방법을 말합니다. 가장 작은 값은 0, 가장 큰 값은 1에 가깝게 가도록 바꾸는 방식입니다.

이 방법은 거리 계산이 중요한 모델에서 특히 직관적입니다. 예를 들어 KNN이나 K-means처럼 샘플 간 거리를 직접 사용하는 알고리즘은 특정 열의 숫자 범위가 너무 크면 그 열이 거리 계산을 거의 지배해 버립니다. 그러면 다른 열의 정보는 사실상 묻혀 버립니다. 정규화는 이런 불균형을 줄여 줍니다.

다만 정규화는 최소값과 최대값에 민감합니다. 극단값이 하나만 있어도 전체 스케일이 눌릴 수 있습니다. 그래서 이상치가 많은 데이터에서는 예상보다 덜 안정적일 수 있습니다.

표준화는 평균과 표준편차를 기준으로 맞춘다

표준화는 각 열의 평균을 0, 표준편차를 1에 가깝게 맞추는 방법입니다. 쉽게 말하면 각 값이 평균에서 얼마나 떨어져 있는지를 비슷한 기준으로 표현하는 것입니다.

표준화는 경사 하강법을 사용하는 모델에서 자주 도움이 됩니다. 선형 회귀, 로지스틱 회귀, 신경망처럼 파라미터를 조금씩 업데이트하며 학습하는 모델은 입력 특성들의 스케일이 크게 다르면 학습이 불안정하거나 느려질 수 있습니다. 어떤 축으로는 아주 조금 움직이고, 어떤 축으로는 지나치게 크게 움직이는 식이 되기 때문입니다. 표준화는 이런 불균형을 줄여 학습을 더 매끄럽게 만드는 데 도움이 됩니다.

또한 표준화는 정규화보다 극단값에 약간 덜 민감한 편이지만, 완전히 자유로운 것은 아닙니다. 이상치가 심한 경우에는 평균과 표준편차 자체가 흔들릴 수 있으므로 주의가 필요합니다.

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

스케일링을 배울 때 자주 생기는 오해가 하나 있습니다. "어떤 모델을 쓰든 무조건 정규화나 표준화를 해야 한다"는 생각입니다. 꼭 그렇지는 않습니다.

거리 기반 모델은 스케일에 매우 민감합니다. 가까운 점과 먼 점을 구분해야 하므로, 단위 차이가 크면 결과가 쉽게 왜곡됩니다. 경사 하강 기반 모델도 입력 스케일이 들쭉날쭉하면 학습 속도와 안정성에 영향을 받기 쉽습니다.

반면 결정 트리, 랜덤 포레스트, 그라디언트 부스팅 같은 트리 계열 모델은 대체로 스케일링에 덜 민감합니다. 이 모델들은 값을 직접 비교해 분할 기준을 정하기 때문에, 단위가 조금 다르다고 해서 거리 기반 모델만큼 큰 영향을 받지는 않습니다.

그렇다고 스케일링을 전혀 신경 쓰지 않아도 된다는 뜻은 아닙니다. 같은 프로젝트 안에서 여러 모델을 비교할 수도 있고, 전처리 파이프라인을 일관되게 유지해야 할 때도 있습니다. 다만 "왜 하는지"를 이해한 채 적용하는 것이 중요합니다. 스케일링은 의식처럼 하는 절차가 아니라, 모델의 계산 방식에 맞춘 조정입니다.

텍스트 전처리는 많이 지우는 것보다 잘 남기는 것이 중요하다

표 데이터에서도 텍스트 열은 자주 등장합니다. 상품 리뷰, 고객 문의, 검색어, 자유 입력 메모 같은 열들입니다. 이런 데이터는 문자열 그대로는 대부분의 전통적 모델이 다루기 어렵기 때문에 추가 전처리가 필요합니다.

가장 기본적인 단계는 텍스트를 잘게 나누는 것입니다. 문장을 단어나 토큰 단위로 분해하고, 필요하면 소문자 통일, 불필요한 공백 제거, 특수문자 정리 같은 작업을 합니다. 전통적인 머신러닝에서는 이렇게 나눈 토큰을 단어 빈도나 TF-IDF 같은 수치 표현으로 바꾸는 경우가 많습니다.

하지만 텍스트 전처리에서 중요한 것은 "얼마나 많이 지웠는가"가 아니라 "의미를 얼마나 덜 훼손했는가"입니다. 예를 들어 리뷰 분석에서 느낌표, 반복 문자, 부정 표현은 감정 신호가 될 수 있습니다. 안 좋아요와 좋아요는 한 단어 차이인데 의미는 정반대입니다. 너무 공격적으로 정리하면 오히려 중요한 힌트를 제거할 수 있습니다.

최근에는 사전학습 임베딩이나 언어 모델을 활용하는 경우가 많아, 예전처럼 무조건 강한 정제를 하는 것이 항상 유리하지도 않습니다. 텍스트 전처리는 청소가 아니라, 의미를 보존하면서 모델이 읽을 수 있는 단위로 바꾸는 과정이라고 이해하는 편이 좋습니다.

전처리는 학습할 때와 예측할 때 완전히 같아야 한다

전처리에서 가장 실무적인 핵심은 따로 있습니다. 훈련 때 적용한 전처리를 예측 시점에도 똑같이 재현해야 한다는 점입니다. 이 원칙이 깨지면 학습-서빙 불일치가 생깁니다.

말은 어려워 보이지만 상황은 단순합니다. 학습할 때는 결측치를 중앙값으로 채우고, 범주형 열은 원-핫 인코딩하고, 숫자는 표준화했다고 합시다. 그런데 실제 서비스에 모델을 붙일 때는 결측치를 0으로 채우거나, 원-핫 인코딩 기준이 달라지거나, 표준화에 사용한 평균과 표준편차가 달라진다면 어떻게 될까요. 모델은 훈련 때 보던 입력과 다른 형태의 데이터를 받게 됩니다. 그러면 오프라인에서는 잘 되던 모델이 실제 운영에서는 엉뚱한 예측을 할 수 있습니다.

이 문제는 생각보다 자주 발생합니다. 노트북에서 급하게 실험할 때는 눈에 띄지 않지만, 제품에 붙이는 순간 문제가 드러납니다. 모델 자체가 틀린 것이 아니라, 모델에 들어가는 입력의 형식이 달라진 것입니다.

그래서 전처리는 "한 번 해보고 끝나는 작업"이 아니라 "같은 규칙을 반복 가능하게 만드는 작업"이어야 합니다.

전처리 규칙은 훈련 데이터에서 배우고, 나머지 데이터에는 그대로 적용한다

여기서 한 가지 더 중요한 원칙이 있습니다. 전처리 규칙은 훈련 데이터에서만 계산하고, 검증 데이터·테스트 데이터·실제 입력에는 그 규칙을 그대로 적용해야 합니다.

예를 들어 표준화를 한다면, 평균과 표준편차는 훈련 데이터에서 계산해야 합니다. 결측치를 중앙값으로 채운다면, 그 중앙값도 훈련 데이터에서 구해야 합니다. 범주형 인코딩의 기준 역시 훈련 데이터에서 정해야 합니다.

왜냐하면 검증 데이터나 테스트 데이터의 정보를 미리 써 버리면, 모델이 미래를 슬쩍 엿본 것과 비슷한 상황이 되기 때문입니다. 그러면 평가 성능은 좋아 보이지만 실제 운영 성능은 떨어질 수 있습니다. 아직 정식으로 평가 파트를 배우기 전이라도, 이 감각은 지금부터 익혀 두는 것이 좋습니다.

쉽게 말하면 이렇습니다. 시험 문제를 풀기 전에 정답지를 훔쳐보면 모의고사 점수는 높게 나올 수 있습니다. 하지만 실전에서는 무너집니다. 전처리도 똑같습니다.

파이프라인으로 묶어야 사람이 바뀌어도 같은 결과가 나온다

실무에서는 전처리 단계를 코드 파이프라인으로 묶는 습관이 중요합니다. 사람 머릿속 순서로만 기억하면 거의 반드시 어딘가에서 어긋납니다. 특히 여러 명이 함께 작업하거나, 실험 환경과 운영 환경이 분리되어 있을 때는 더 그렇습니다.

좋은 전처리 파이프라인은 다음 질문에 답할 수 있어야 합니다.

• 어떤 열에 어떤 처리를 했는가?

• 결측 대체 값은 무엇인가?

• 인코딩 기준은 무엇인가?

• 스케일링에 사용한 통계량은 무엇인가?

• 예측 시점에도 이 순서를 그대로 재현할 수 있는가?

이렇게 파이프라인으로 묶어 두면 모델을 다시 학습할 때도, 버전을 바꿀 때도, 서비스 환경으로 옮길 때도 같은 규칙을 유지하기 쉬워집니다. 결국 전처리의 품질은 단지 방법이 똑똑한가가 아니라, 재현 가능하냐로도 결정됩니다.

전처리에서 자주 하는 실수들

전처리는 겉보기보다 실수가 많은 영역입니다. 몇 가지 대표적인 함정을 미리 알고 있으면 시행착오를 크게 줄일 수 있습니다.

첫째, 전체 데이터를 한꺼번에 보고 평균이나 표준편차를 계산하는 실수입니다. 이렇게 하면 검증과 테스트에 대한 정보를 미리 사용하게 됩니다.

둘째, 훈련 때와 예측 때 결측 처리 방식이 달라지는 실수입니다. 노트북에서는 중앙값으로 채웠는데, 서비스 코드에서는 빈칸을 0으로 넣는 식입니다.

셋째, 범주형 인코딩 기준이 뒤틀리는 실수입니다. 학습 시점에는 없던 범주가 운영 환경에서 들어왔을 때 어떻게 처리할지 정해 두지 않으면 예측이 깨질 수 있습니다.

넷째, 전처리를 너무 많이 해서 오히려 의미를 지우는 실수입니다. 특히 텍스트 데이터에서 자주 벌어집니다.

다섯째, 모델에 맞지 않는 스케일링을 습관적으로 적용하는 실수입니다. 왜 필요한지 모른 채 넣으면, 전처리가 설명되지 않는 블랙박스가 됩니다.

좋은 전처리는 복잡한 전처리가 아닙니다. 문제와 데이터와 모델에 맞게, 필요한 만큼만, 일관되게 적용하는 전처리입니다.

전처리는 성능 향상 기술이기 전에 실패 방지 기술이다

전처리를 잘하면 성능이 좋아질 수 있습니다. 하지만 더 중요한 효과는 따로 있습니다. 모델이 엉뚱한 이유로 실패하지 않게 막아 준다는 점입니다.

결측치를 아무 생각 없이 처리하면 없는 패턴을 만들어 낼 수 있습니다. 범주형 값을 잘못 숫자로 바꾸면 가짜 순서를 주입할 수 있습니다. 스케일 차이를 무시하면 어떤 열이 모델을 독점할 수 있습니다. 훈련 때와 예측 때 다른 전처리를 쓰면, 잘 학습한 모델도 운영에서 망가질 수 있습니다.

이런 문제들은 화려하지 않지만 치명적입니다. 그리고 대부분 알고리즘 교체보다 전처리 점검으로 더 빨리 해결됩니다. 그래서 실무자들은 종종 "모델을 바꾸기 전에 입력부터 의심하라"고 말합니다.

전처리는 모델을 똑똑하게 만드는 마법이 아니라, 모델이 기본적인 실수를 하지 않게 만드는 안전장치입니다. 바로 그 점에서 전처리는 머신러닝의 주변부가 아니라 중심부에 있습니다.

이 장의 핵심

데이터 전처리는 데이터를 깨끗하게 정리하는 보조 작업이 아니라, 모델이 학습할 수 있는 표현으로 바꾸는 핵심 설계입니다. 결측치는 단순한 빈칸이 아니라 데이터 수집 과정의 흔적일 수 있으며, 평균 대체, 중앙값 대체, 별도 범주 처리 같은 방법은 각각 다른 가정을 담고 있습니다.

범주형 데이터는 문자열 그대로 넣기 어렵기 때문에 인코딩이 필요합니다. 원-핫 인코딩은 직관적이지만 범주가 많아지면 무거워지고, 빈도 인코딩은 고카디널리티 데이터에서 실용적이며, 해싱은 새로운 범주가 계속 등장하는 대규모 환경에서 강점을 가집니다. 어떤 방식을 쓸지는 범주 수, 해석 가능성, 운영 환경을 함께 보고 결정해야 합니다.

숫자형 데이터에서는 정규화와 표준화가 중요할 수 있습니다. 특히 거리 기반 모델과 경사 하강 기반 모델은 스케일 차이에 민감합니다. 반면 트리 계열 모델은 상대적으로 덜 민감하지만, 그렇다고 스케일링을 무조건 습관적으로 적용할 필요는 없습니다.

무엇보다 중요한 원칙은 훈련 때 한 전처리를 예측 시점에도 똑같이 재현해야 한다는 점입니다. 전처리 규칙은 훈련 데이터에서만 학습하고, 검증·테스트·서빙에서는 그대로 적용해야 합니다. 그래야 학습-서빙 불일치를 막고, 오프라인 성능과 실제 성능 사이의 간격을 줄일 수 있습니다.

다음 장에서는 이렇게 정리된 데이터를 바탕으로, 모델이 더 잘 배울 수 있도록 의미 있는 입력 신호를 만드는 방법, 즉 특성 엔지니어링을 살펴보겠습니다.