데이터 전처리 단계: 비즈니스 데이터를 정제하는 방법

완성된 것처럼 보이는 매출 데이터를 내려받았습니다. 시트에는 주문, 비용, 날짜가 빠짐없이 채워져 있습니다. 그런데 예측 결과가 재무 책임자의 책상에 올라가자 평균 주문 금액이 급등해 있습니다. 상품 카탈로그에는 아무 변화가 없는데도 말입니다.

이런 급등은 구매 행동이 달라져서가 아니라 전처리 오류 때문인 경우가 많습니다. 중복 송장이 아직 파일에 남아 있는 상태에서 빈 가격을 채우거나, 검증용 행을 따로 떼어 두기 전에 추출 데이터 전체의 스케일을 조정하면, 모델이 아직 알아서는 안 될 정보를 학습하게 됩니다. 대부분의 글은 데이터 전처리 단계를 순서에 상관없이 적용할 수 있는 개별 기법처럼 나열합니다. 하지만 결과를 부풀리는 것은 바로 그 순서입니다.

이 글에서는 분석가가 실제 운영 중인 비즈니스 파일을 맡았을 때 제가 권하는 순서를 소개합니다. 실행 순서, 절대 기준이 아닌 출발점으로 삼는 임계값, 그리고 각 단계에서 적합한 설정을 고정해 다음 데이터 적재 때도 같은 경로를 따르게 하는 방법을 다룹니다.

올바른 순서로 따르는 데이터 전처리 7단계

매출 데이터는 완성된 것처럼 보여도 중복된 송장 행, 비어 있는 단가, 두 가지 형식으로 저장된 날짜가 숨어 있을 수 있습니다. 이런 문제를 잘못된 순서로 정리하면 이후의 모든 평균값이 그 문제를 그대로 물려받습니다.

데이터에서 수치를 학습하는 모든 단계는 분할 이후에 실행해야 합니다. 전체 파일을 기준으로 계산한 평균, 중앙값, 스케일링 범위는 검증용 행이 학습에 영향을 주게 만듭니다. 그러면 점수는 높게 나오지만, 다음 달 주문에 대한 모델의 실제 성능은 그에 못 미칩니다.

한 소매업체에 주문 행이 12,000건 있고, 그중 900건이 중복된 송장 행이라고 해 봅시다. 중복을 제거하기 전에 누락된 가격을 대체하면 같은 송장을 두 번 계산하게 되고, 평균값이 가격표에서 벗어나게 됩니다.

실무 원칙: 다음 행에 필요한 값을 계산하기 전에, 지금 작업 중인 행을 먼저 끝내세요.

지금 열어 둔 파일을 이 일곱 개 행에 대입해 보세요. 아직 끝내지 못한 첫 번째 행만 오늘 손댈 가치가 있습니다.

원시 비즈니스 데이터 프로파일링과 정제

프로파일링은 누구든 모델을 열기 전에 담당 매니저가 한 시간 안에 끝낼 수 있는 작업입니다. 원본 파일은 그대로 두고, 모든 변경 사항을 정제 로그에 기록해 두세요. 그러면 재무 책임자가 합계가 왜 달라졌는지 확인할 수 있습니다.

1. 행과 열의 수를 세고, 각 열의 데이터 유형을 확인하세요. 텍스트로 저장된 비용은 합계에 포함되지 않으며, 오류도 눈에 띄게 나지 않습니다. 합계를 믿기 전에 먼저 변환하세요.
2. 모든 열의 결측률을 계산하세요. 비어 있는 비율이 30%를 넘는 열은 간단히 채우지 말고 결측값 처리 규칙에 따라 다루세요. 열 전체를 삭제하는 것은 결측이 50%를 넘고 해당 필드가 의사결정에 필수가 아닐 때만 고려하겠습니다.
3. 비슷해 보이는 행이 아니라, 완전히 동일한 중복만 제거하세요. 송장 번호, 날짜, 금액을 함께 기준으로 비교하세요. 행 ID가 다른 두 번째 주문은 실제 판매입니다. 고객과 날짜가 같다는 이유로 삭제하면 매출이 과소 집계되는 실수로 이어집니다.
4. 형식을 한 번에 통일하세요. 날짜 형식은 하나로, 열마다 통화는 하나로 맞추고, 코드에 섞인 불필요한 공백은 제거하세요. 형식이 섞여 있으면 하나의 제품이 두 개의 계열로 나뉘고, 이후 조인도 깨집니다.
5. 카테고리 레이블을 표준화하세요. UK, U.K., United Kingdom은 같은 시장입니다. 3년치 이커머스 내보내기 파일에서 한 제품군이 네 가지 표기로 적혀 있어도 같은 문제가 생깁니다. 레이블 하나를 정하고 나머지를 그것으로 매핑하세요.

그 내보내기 파일에서 주문일이 한 해에는 2024-03-01, 다른 해에는 01/03/2024로 저장되어 있다고 해 봅시다. 두 형식을 하나로 통일하기 전까지 월별 차트는 3월을 이중으로 집계하거나 누락합니다.

로그와 개인정보 제거가 지켜 주는 것

정제 로그는 열, 규칙, 변경된 행 수, 담당자, 날짜로 구성된 간단한 표입니다. 재무팀이 지난 3월 수치가 왜 줄었는지 물으면, 파일을 기억에 의존해 다시 만들 필요 없이 중복 제거 규칙을 가리키면 됩니다.

파일을 분석 플랫폼에 넘기기 전에 고객 이름, 이메일, 결제 정보를 제거하세요. 수요를 예측하는 데는 필요하지 않으며, 추출 파일에 그대로 두면 모델로도 되돌릴 수 없는 개인정보 문제가 생깁니다.

영업 데이터 추출본에서 "좋은 상태"가 어떤 모습인지 다른 관점이 필요하다면, Pipecorn의 영업 데이터 품질 인사이트가 식별자, 완전성, 일관성을 점검하는 데 유용한 체크리스트가 됩니다. 이를 참고해 남길 열을 정한 다음, 앞서 설명한 결측률 기준으로 돌아오세요.

학습을 시작하기 전에 데이터를 분할하세요

분할은 울타리와 같습니다. 통계량을 추정하는 작업은 전체 파일에 적용해서는 안 됩니다.

지도 학습 기반 텍스트 분류에 대해 Google의 텍스트 분류 가이드는 데이터를 나누기 전에 먼저 섞으라고 권장합니다. 원래 순서를 유지하면 두 데이터셋 모두 편향될 수 있기 때문입니다. 섞은 뒤에는 보통 예제의 80%를 학습용, 20%를 검증용으로 나눕니다. 이후 두 데이터셋에 같은 변환을 적용하되, 변환 방식은 반드시 학습 데이터 행에서만 학습해야 합니다.

정렬된 판매 파일이 왜곡된 결과를 만드는 이유

내보낸 데이터는 날짜, 지역, 고객 기준으로 정렬되어 있는 경우가 많습니다. 이런 파일을 위에서 아래로 그대로 나누면 2023년 데이터로 학습하고 2024년 후반 데이터로 검증하게 됩니다. 그러면 점수는 달력, 프로모션 일정, 혹은 특정 지역의 구성비를 따라 움직입니다. 모델이 주문을 제대로 이해했는지는 알려주지 못합니다.

각 행이 독립된 사례일 때는 섞으세요. 완료된 주문, 이탈한 계정, 분류된 티켓이 그 예입니다. 질문이 예측(forecast)이라면 섞지 마세요.

예측에는 시간 순서를 유지하세요. 이전 달 데이터로 학습하고 이후 달 데이터로 테스트합니다. 섞으면 모델이 미래를 미리 보게 되고, 그것을 실력으로 착각하게 됩니다.

텍스트 필드에는 빈도 기준 필터링이 필요합니다

지원 티켓과 제품 설명은 수천 개의 토큰으로 늘어납니다. 같은 Google 워크플로에서는 등장 횟수가 2회 미만인 토큰을 버리고, 상위 20,000개 토큰 피처만 남긴 다음, 남은 토큰을 F-검정 기반 중요도 점수로 순위를 매깁니다. 한 번만 나타나는 토큰은 대개 오타나 일회성 SKU이며, 열(column)로 만들 만큼 의미 있는 패턴이 아닙니다.

데이터를 나눈 뒤에는 모든 매핑을 학습 데이터로만 맞춘(fit) 다음, 고정된 그 매핑을 검증 데이터에 적용하세요. 어휘 목록이나 카테고리 목록을 검증용 행에서 다시 계산하면, 정답이 데이터 준비 단계로 새어 들어가는 또 다른 경로가 됩니다.

결과를 왜곡하지 않고 결측값 채우기

필드가 얼마나 자주 비어 있는지, 그리고 의사결정에 그 필드가 필요한지에 따라 처리 방법이 정해집니다. 아래 구간은 법칙이 아니라 실무에서 쓰는 경험칙입니다. 규제를 받는 리스크 모델에서는 소매 수요 예측이라면 버려도 되는 행을 함부로 제외할 수 없을 수 있습니다.

완결된 주문 파일에서 비용이 비어 있는 행이 몇 개뿐이라면, 그것이 첫 번째 사례입니다. 가격을 지어내는 것보다 그 행을 삭제하는 편이 손실이 적습니다. 중간 구간에 있는 거의 쓰이지 않는 설문 항목은 추측으로 채울 가치가 없으므로 해당 열을 제거합니다. 이탈 분석에 쓰는 가입 기간(tenure)은 그대로 두고 값을 추정합니다.

데이터 준비에 관한 Google의 클러스터링 가이드는 현실적인 선택지를 세 가지로 제시합니다. 결측값이 있는 예시를 제거하거나, 해당 피처를 제거하거나, 다른 데이터로 결측값을 예측하는 것입니다. 결측이 드물다면 행 삭제도 타당할 수 있습니다. 결측이 잦다면 보통 피처를 버리거나 대체(imputation)합니다.

상수를 붙여 넣지 말고 빈 값을 예측하세요

숫자형 필드는 값이 있는 행으로 회귀 모델을 학습시킨 뒤 빈 값을 추정합니다. 예를 들어 고객 나이가 비어 있다면 회사 전체 평균 하나로 바꾸는 대신 소득과 가입 기간으로 추정할 수 있습니다. 이미 신뢰하고 있는 변수 간 관계를 활용하는 방법입니다.

주문 금액은 분포가 한쪽으로 치우쳐 있습니다. 대형 도매 주문 몇 건이 평균을 끌어올리기 때문에, 평균으로 채우면 일반적인 장바구니가 실제보다 커 보입니다. 중앙값은 일반적인 주문 수준에 위치하며, 대량 청구서 한 건이 들어와도 덜 움직입니다. 채우기 전과 후의 요약 통계를 비교하세요. 큰 차이가 난다면 그 방법은 구멍을 메우는 것이 아니라 비즈니스 현실을 바꾸고 있는 것입니다.

범주형 필드는 빈 값을 Unknown으로 표시합니다. 빈 값 자체가 신호인 경우가 많습니다. 결제 과정에서 지역이 수집되지 않았거나, 제품에 공급업체 코드가 없는 경우가 그렇습니다. 이를 하나의 실제 수준으로 만들면 행을 유지하면서, 해당 필드가 의도적으로 비어 있었다는 점을 모델에 알려 줄 수 있습니다.

운영 데이터에서 잦은 결측은 드문 일이 아닙니다. 2025년의 한 불완전한 물 사용량 데이터 연구는 2019년 2월부터 2023년 12월까지의 시간별 기록 33,888건으로 구성된 건물 데이터셋을 소개하는데, 이 중 20%의 시간대에 결측값이 있습니다. 이 정도면 행을 일괄 삭제할 경우 너무 많은 이력이 사라지는 수준입니다(해당 연구).

대체 모델(imputer)은 학습 행에서만 학습시키세요. 순서가 아니라 방법을 한 번 더 검토하고 싶다면, 결측 데이터에 관한 ELECTE 가이드에서 대체 방식 선택지를 더 자세히 다룹니다.

범주 인코딩과 유용한 피처 설계

여기에는 두 가지 작업이 있습니다. 레이블을 모델이 쓸 수 있는 숫자로 바꾸는 일, 그리고 원본 필드로는 답할 수 없는 비즈니스 질문에 답하는 열을 만드는 일입니다.

가짜 순위를 만들지 않는 인코딩

원-핫 인코딩은 영업 지역 다섯 곳처럼 값이 적은 범주에 적합합니다. 각 지역이 별도의 예/아니오 열이 되므로 어느 지역도 다른 지역보다 "크지" 않습니다.

순서형 인코딩은 S, M, L 같은 사이즈처럼 실제 순서가 있는 경우에 적합합니다. 숫자가 비즈니스에서 이미 쓰는 순위와 일치합니다.

채널이나 도시처럼 순서가 없는 이름에 1, 2, 3을 부여하지 마세요. 모델은 코드가 높을수록 더 큰 값이라고 받아들입니다. 이 잘못된 순위는 나중에 확신에 찬 잘못된 계수로 나타납니다. 필드의 수준이 수백 개라면 원-핫 인코딩은 매우 넓은 테이블을 만듭니다. 인코딩하기 전에 드문 수준을 Other로 묶고, 이 묶는 기준은 학습 행에서만 학습하세요.

비즈니스 질문에 답하는 열

만들 수 있는 모든 비율을 쏟아내지 말고, 하나의 의사결정과 연결된 짧은 목록을 만드세요.

• 마진율: (price − cost) / price는 프로모션이 원가를 넘어서는지 알려 줍니다. 매출만으로는 알 수 없는 정보입니다.
• 마지막 구매 후 경과일: 이탈 분석에는 고객 ID를 한 번 더 복사한 열이 아니라 최근 구매 시점이 필요합니다.
• 요일과 월: 수요 계획에서는 전체 타임스탬프 안에 숨어 있는 금요일 급증과 계절별 월 패턴이 중요합니다.
• 7일 이동 평균: 일별 판매량은 들쭉날쭉합니다. 주간 평균을 보면 수요가 늘고 있는지 알 수 있습니다.
• 재고 대비 판매 비율: 재고 관리자는 단순 보유 재고 수량보다 더 일찍 재고 부족의 조짐을 확인할 수 있습니다.

저라면 하나의 의사결정과 연결된 10~15개 피처로 시작하겠습니다. 두 열의 상관관계가 0.95를 넘으면 하나는 제거하세요. 두 번째 열이 첫 번째 열을 그대로 반복하기 때문입니다. 데이터 사전에는 열 이름 옆에 비즈니스상의 의미를 적어 두세요. 인코딩 맵이나 이동 평균을 따로 떼어 둔 행까지 포함한 전체 파일로 학습하면, 분할 단계에서 막아 둔 누수가 그대로 되풀이됩니다.

숫자 스케일 조정과 이상치 관리

극단값이 곧바로 오류인 것은 아닙니다. B2B 고객사의 40개 단위 주문은 실제 판매입니다. 평균을 좌우하지 않도록 플래그만 달고 이력에는 그대로 두세요. 1,000이어야 할 단가가 100,000으로 입력되었다면 입력 오류입니다. 자릿수를 바로잡아야 하며, 수요로 "처리"해서는 안 됩니다.

삭제하기 전에 극단값부터 확인하세요

두 가지 점검을 함께 쓰면 효과적입니다. 1.5 × 사분위 범위 규칙은 열의 중앙에서 멀리 떨어진 값을 표시합니다. 도메인 점검은 그 값이 존재할 수 있는지 묻습니다. 예를 들어 음수 재고, 10년 뒤 날짜, 판매가보다 큰 할인액이 여기에 해당합니다. 먼저 확인하세요. 그다음 1·99번째 백분위수로 상한과 하한을 두거나, 치우친 매출에 로그 변환을 적용하거나, 플래그를 추가하고 보고용 원본 값은 그대로 유지하세요.

삭제한 대량 주문은 다시는 예측할 수 없는 매출입니다. 그대로 둔 오타는 고객이 지불할 것이라고 모델이 믿는 가격이 됩니다.

상한·하한을 적용한 뒤에는 요약 통계를 다시 확인하세요. 열의 중심값은 거의 변하지 않아야 합니다. 중앙값이 크게 달라졌다면 그 제한이 과하게 작용한 것이므로 원본 행을 다시 살펴봐야 합니다.

데이터 특성에 맞는 스케일러

스케일링은 연간 매출처럼 단위가 큰 열이 주문당 수량처럼 단위가 작은 열을 압도하지 못하게 합니다. Scikit-learn 전처리 문서에 따르면 StandardScaler는 각 피처를 학습 세트의 평균을 기준으로 중심화하고 분산에 맞춰 스케일을 조정하므로, 이상치가 많을 때는 성능이 떨어질 수 있습니다. RobustScaler는 이상치에 더 강한 중심값과 범위 추정치를 사용하는 대체 도구입니다.

스케일러는 학습 데이터에만 맞춰(fit) 학습한 다음, 그 결과를 그대로 검증 데이터에 적용하세요. 홀드아웃 세트에서 다시 fit하면 검증 데이터의 극단값이 스케일 기준을 좌우하게 됩니다. 처리 방법을 정하기 전에 극단값을 찾아내는 방법을 자세히 알아보려면 ELECTE의 이상치 가이드를 참고하세요.

파이프라인을 자동화하고 출력 결과를 점검하세요

노트북 한 곳에 저장된 정제 파일은 실행할 때마다 달라질 수 있습니다. 새 파일에 다른 대체값, 범주 인코딩, 스케일이 적용되면 실제 비즈니스에는 변화가 없어도 대시보드 수치가 바뀔 수 있습니다.

파이프라인은 학습된 대체기(imputer), 인코더, 스케일러를 함께 보관하고 새 파일에도 동일한 변환을 적용합니다. 이 단계들은 학습 파티션만으로 fit하세요. 검증 및 테스트 데이터에는 다시 계산하지 말고 fit된 설정을 그대로 적용하세요. 학습 데이터와 테스트 데이터 전체에 걸쳐 전처리 단계를 fit하면 평가에 정보가 유출될 수 있는 이유는 IBM's note on data leakage에서 확인할 수 있습니다.

실행할 때마다 확인할 사항

작업이 성공으로 표시됐다는 것은 프로세스가 실행되었다는 의미일 뿐입니다. 결과물이 원본 및 설정한 규칙과 여전히 일치하는지 확인하세요.

• 행 수: 로그에 기록된 중복을 감안해 적재된 파일과 내보내기 파일의 행 수를 대조합니다.
• 열별 null 비율: 갑자기 증가했다면 원본 필드가 더 이상 들어오지 않는다는 신호일 수 있으니 원인을 조사하세요.
• 값 범위: 가격, 수량, 날짜가 허용 범위 안에 있는지 확인합니다.
• 새로운 범주: 처음 보는 지역이나 SKU는 알림 없이 버리지 말고 지정된 구분 항목으로 보내세요.

데이터 검증의 실무 사례에서 이러한 검사가 업무용 파일에 어떻게 적용되는지 살펴보세요. 자동화된 결과는 추정치로 취급하고, 알림을 발생시키는 기준으로 사용하기 전에 처음 몇 주기는 직접 검토하세요.

성장 중인 기업을 위한 AI 기반 데이터 분석 플랫폼 ELECTE는 회계 소프트웨어 또는 업로드한 파일에 연결해 분석가 없이도 데이터 분석과 예측을 실행합니다. 고객은 재무 분석을 자동화해 매주 10시간 이상을 절약합니다. 이러한 도움은 업로드할 때마다 다시 계산하는 대신, 검토 과정에서 근거를 설명할 수 있는 학습된(fitted) 단계를 사용하는 데 달려 있습니다.

이번 주에 데이터셋 하나를 7행짜리 표에 따라 처리해 보고, 아직 수동으로 하는 단계를 표시하세요. 반복되는 단계는 자동화하되, 중복과 실제 재주문의 구분, 오타와 대량 주문의 구분처럼 판단이 필요한 사안은 규칙이 안정될 때까지 검토 대상으로 유지하세요.

ELECTE는 회계 데이터 또는 업로드한 파일을 연결해 정리하고, 팀과 함께 검토할 수 있는 예측과 보고서로 만들어 줍니다. 이러한 데이터 전처리 단계를 매번 같은 방식으로 적용하고 싶다면 ELECTE를 방문해 플랫폼이 여러분의 실제 수치로 해당 과정을 어떻게 실행하는지 확인해 보세요.