Customer Data Does Not Look Like Sample Data

한 줄 요약

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

왜 이게 필요했나

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

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

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

어떻게 동작하나

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

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

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

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

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

현장에서 만나는 모습

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

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

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

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

정제 결과를 어떻게 증명하나

정제가 끝났다는 것을 무엇으로 보이느냐가 실제 업무의 절반이다. "돌렸습니다" 로는 아무도 그 숫자를 쓰지 못한다. 그래서 정제 스크립트는 결과 데이터와 함께 무슨 일이 있었는지를 적은 보고를 내야 한다.

최소한 이 다섯 줄은 있어야 한다.

• 입력 행 수와 출력 행 수, 그리고 그 차이
• 버린 행을 이유별로 나눈 건수
• 값을 고친 행의 건수(공백 제거, 대소문자 통일, 날짜 형식 통일)
• 중복으로 합친 건수와 그때 무엇을 남겼는지
• 합계처럼 업무가 실제로 쓰는 숫자의 정제 전후 값

마지막 줄이 특히 중요하다. 행 수가 2% 줄었는데 매출 합계가 30% 줄었다면 그것은 정제가 아니라 사고다. 큰 거래 몇 건이 걸러졌다는 뜻이고, 그런 행일수록 형식이 특이할 가능성이 높다. 행 수만 보고 있으면 이것을 놓친다.

되돌릴 수 있게 만드는 것도 중요하다. 원본을 덮어쓰지 않고, 버린 행은 지우는 대신 별도 파일로 남긴다. 그러면 나중에 "이 주문이 왜 집계에 없죠" 라는 질문에 몇 초 만에 답할 수 있다. 버린 행 파일에는 원본 줄 번호를 함께 적어 두는 편이 좋다. 고객이 자기 파일에서 그 줄을 직접 열어 볼 수 있어야 대화가 빨라진다.

마지막으로, 규칙은 코드가 아니라 문서와 코드 양쪽에 같은 말로 적혀 있어야 한다. 정제 규칙이 코드에만 있으면 몇 달 뒤에 아무도 그것을 모르고, 새 담당자가 다른 규칙으로 다시 만든다. 그때부터 같은 원본에서 두 개의 다른 숫자가 나오기 시작하고, 그 둘 중 무엇이 맞는지 판정할 근거가 사라집니다.

문서에는 규칙마다 그것을 정한 사람과 날짜를 함께 적어 둔다. 나중에 규칙을 바꿔도 되는지 물을 상대가 그 줄에 적혀 있어야, 새로 온 사람이 혼자 판단하고 넘어가는 일이 생기지 않는다.

다음 실습에서 할 것

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