고객 데이터는 예제 데이터처럼 생기지 않았다

한 줄 요약

데이터 정제에서 진짜 결정은 어떤 도구를 쓰느냐가 아니라 무엇을 버릴지의 기준을 누가 정하느냐다.

왜 이게 필요했나

튜토리얼의 CSV 는 열 개수가 일정하고, 빈 칸이 없고, 숫자 칸에는 숫자만 들어 있습니다. 고객이 주는 CSV 는 그렇지 않습니다.

실제로 만나는 것들을 나열하면 이렇습니다. 필드가 하나 모자란 행. 고객명이 비어 있는 행. 금액 칸에 N/A 나 - 가 들어간 행. 음수 금액. 앞뒤에 공백이 붙은 이름. 같은 회사가 MOONSHOP 과 moonshop 두 가지로 들어온 것. 같은 주문 번호가 두 번 나오는데 한쪽은 날짜 형식만 다른 것. 그리고 2026-08-20, 2026/08/20, 08/20/2026 이 한 파일에 섞여 있는 것.

여기서 초보자가 하는 실수는 곧바로 정제 스크립트를 짜기 시작하는 것입니다. 그러면 반드시 두 가지가 벌어집니다. 첫째, 스크립트가 조용히 데이터를 지웁니다. 둘째, 고객이 나중에 "왜 우리 매출이 이것밖에 안 되죠" 라고 묻습니다.

어떻게 동작하나

순서는 세기 → 분류 → 합의 → 정제 입니다.

먼저 셉니다. 전체 몇 행 중 몇 행이 규칙을 어기는지. 이 숫자가 없으면 정제 결과가 맞는지 판정할 수 없습니다. 226 행 중 5 행이 깨진 것과 226 행 중 180 행이 깨진 것은 완전히 다른 상황이고, 후자라면 정제가 아니라 데이터 추출 자체를 다시 해야 합니다.

다음에 분류합니다. 깨진 이유를 종류별로 나눕니다. 구조 문제(필드 수), 결측(빈 값), 타입 문제(숫자 자리에 문자), 범위 문제(음수·비현실적 값), 중복. 이 분류가 중요한 이유는 종류마다 처리 방침이 다르기 때문입니다. 필드 수가 안 맞는 행은 대개 버려야 하지만, 고객명이 비어 있는 행은 버릴 수도 있고 미상 으로 채울 수도 있습니다. 그 결정은 엔지니어가 아니라 업무 담당자가 합니다.

그다음이 합의입니다. 여기가 FDE 의 일입니다. "금액이 음수인 행 4건은 환불로 보이는데 이번 집계에서 제외할까요, 별도로 셀까요" 라는 질문을 던지는 것. 이 질문을 하지 않으면 나중에 숫자가 안 맞을 때 설명할 근거가 없습니다.

마지막이 정제입니다. 그리고 정제 스크립트는 반드시 버린 행의 수를 출력해야 합니다. 조용히 지우는 스크립트는 시한폭탄입니다.

현장에서 만나는 모습

중복 제거에서 가장 자주 나는 사고를 하나 소개합니다.

"이메일이 같으면 중복이니 하나만 남긴다" 는 규칙으로 그룹화해서 정리하는 코드가 있습니다. 대부분의 경우 잘 동작합니다. 그런데 이메일이 비어 있는 행들이 있으면, 그것들이 전부 하나의 그룹으로 묶여서 서로 다른 고객이 한 명만 남고 전부 삭제됩니다.

같은 함정이 이름 정규화에도 있습니다. 앞뒤 공백을 없애고 소문자로 바꾸는 것은 좋은 습관이지만, 그러고 나면 kimcoffee 와 kimcoffee31 처럼 원래 다른 두 고객이 비슷해 보이기 시작합니다. 정규화는 비교를 위한 것이지 병합의 근거가 아닙니다.

그래서 실무 규칙 하나. 중복 판정 키에 결측이 들어갈 수 있으면, 결측 행은 중복 판정에서 아예 빼고 따로 셉니다.

다음 실습에서 할 것

25 행짜리 주문 CSV 에서 깨진 행을 규칙대로 걸러 내고, 버린 행의 수를 세고, 정제 결과의 합계와 일자별 집계까지 만들어 냅니다. 규모는 작지만 종류는 현장 그대로입니다.