CSV 중복 행을 지운 뒤 꼭 확인할 4가지, 원본·인코딩·실패 기록

CSV에서 중복 행을 지운 뒤 파일이 열리기만 하면 끝났다고 보기 쉽습니다. 하지만 정리 작업에서 더 무서운 문제는 오류 창이 아니라 조용한 누락입니다. 원본이 덮어써졌거나, 문자 인코딩을 잘못 읽었거나, 여러 파일 중 일부만 실패했는데도 결과 폴더만 보고 넘어갈 수 있습니다.

2026년 7월 30일 Windows용 CSV Audit Cleaner로 4행 표본을 실제 처리했습니다. 결과는 2행이었고, HTML 감사 보고서에는 빈 행 1개·중복 1개·실패 0건으로 기록됐습니다. 이 표본을 기준으로 CSV 정리 뒤 확인할 순서를 네 가지로 나눠보겠습니다.

첫째, 정리 파일보다 원본이 그대로 남았는지 먼저 봅니다

원본과 결과를 같은 파일에 덮어쓰면 문제가 발견돼도 돌아갈 곳이 없습니다. 이 도구는 원본과 다른 새 실행 폴더에 cleaned 결과를 만들고, 원본의 SHA-256을 보고서에 기록합니다. 사용자는 원본 폴더와 결과 폴더를 나란히 두고 확인할 수 있습니다.

실행 전에 따로 복사본을 만드는 습관도 좋지만, 프로그램 자체가 원본을 덮어쓰지 않는지 확인하는 것이 먼저입니다. ‘저장’ 버튼을 누르는 순간 원본에 반영되는 편집기라면 자동화 속도보다 백업 계획이 우선입니다.

둘째, 입력 4행→출력 2행의 이유가 숫자로 맞아야 합니다

결과 행 수만 보면 두 행이 사라졌다는 사실밖에 알 수 없습니다. 실제 표본에서는 완전히 빈 행 1개와 order_id가 같은 중복 행 1개가 빠졌습니다. 입력 4에서 두 항목을 빼면 출력 2가 됩니다. 보고서의 입력·출력·빈 행·중복 행 숫자가 이 관계와 맞는지 확인해야 합니다.

중복 기준 열을 지정했을 때는 한 단계 더 봐야 합니다. 예를 들어 order_id를 기준으로 잡으면 다른 열이 달라도 같은 주문번호 행은 중복으로 처리될 수 있습니다. 기준 열을 비워 두면 전체 행의 값이 모두 같은 경우만 중복으로 제거합니다. 여러 CSV를 한꺼번에 처리할 때는 지정한 열 이름이 모든 파일의 헤더에 정확히 있어야 합니다.

셋째, 한글이 보인다고 인코딩 확인을 건너뛰지 않습니다

입력 범위는 UTF-8, UTF-8 BOM, CP949 CSV입니다. 결과 CSV는 UTF-8 BOM으로 저장해 Windows의 일반적인 스프레드시트 환경에서 열기 쉽게 했습니다. 여기서 지원 범위 밖의 형식을 억지로 읽거나, 확장자만 CSV로 바꾼 XLSX 파일을 넣으면 안 됩니다.

파일이 열렸다는 사실과 모든 글자가 제대로 읽혔다는 사실은 다릅니다. 고객명이나 주소처럼 한글이 있는 표본 한두 행을 결과에서 직접 확인하고, 열 개수와 헤더가 원본과 같은지 보는 편이 안전합니다. 이 도구는 값의 의미를 추측해 고쳐주지 않으므로 깨진 원문을 정상 값으로 만들어 주는 기능도 없습니다.

넷째, 성공 파일만 보지 말고 실패 목록을 따로 확인합니다

여러 파일을 한 번에 처리할 때 한 파일이 실패했다고 전부 멈추면 정상 파일까지 결과를 얻지 못합니다. 반대로 실패를 숨기고 정상 파일만 보여주면 누락을 알아채기 어렵습니다. CSV Audit Cleaner는 정상 파일은 계속 처리하고, 실패한 파일과 오류 종류를 report.html과 run_log.jsonl에 남깁니다.

따라서 마지막 확인 순서는 간단합니다. 보고서의 실패 수가 0인지 보고, 0이 아니라면 파일명과 오류를 먼저 읽습니다. 그다음 헤더에 중복 기준 열이 있는지, 지원 인코딩인지, 실제 CSV인지 확인해 해당 파일만 고칩니다.

결과 폴더는 정리 파일보다 보고서부터 여는 편이 빠릅니다

실행 폴더에는 정리된 CSV만 있는 것이 아닙니다. 먼저 report.html을 열어 입력·출력·빈 행·중복·실패 수를 한 화면에서 확인하고, 숫자가 예상과 맞을 때 cleaned 폴더의 CSV를 엽니다. 자동화 결과를 곧바로 원래 업무에 넣기 전에 변화의 크기를 먼저 보는 순서입니다.

summary.json은 같은 실행의 전체 성공·실패 수를 다른 프로그램에서 읽기 좋게 모아 둔 파일이고, run_log.jsonl은 파일별 처리 기록을 한 줄씩 남깁니다. 평소에는 HTML 보고서만으로 충분하지만, 파일 수가 많거나 실패 원인을 다시 추적할 때 두 기록을 함께 보면 어떤 파일에서 흐름이 갈렸는지 찾기 쉽습니다.

실제 프로그램의 4행→2행 흐름을 51초로 확인했습니다

판매용 Windows 실행 파일을 새 프로세스로 열어 준비됐습니다. 상태부터 녹화했습니다. 동봉 표본 선택, order_id 입력, 정리 실행, 성공 1개·실패 0개 확인, HTML 보고서 열기까지 한 흐름으로 이어집니다.

영상 속 수치는 이 고정 로컬 표본에만 해당합니다. 같은 입력 파일명과 빈 행 1개·중복 1개·실패 0건은 실제 HTML 샘플 보고서에서 따로 대조할 수 있습니다.

큰 원본을 넣기 전에 네 행짜리 표본으로 기준 열을 시험합니다

중복 기준이 모호한 파일은 원본 전체를 바로 처리하지 않는 편이 안전합니다. 헤더와 정상 행 두 개, 의도한 중복 한 개, 빈 행 한 개만 복사한 작은 CSV를 먼저 만듭니다. 전체 행 중복을 쓸지 order_id 같은 기준 열을 쓸지 정한 뒤, 기대한 두 행만 남는지 확인하면 기준 선택 실수를 빨리 발견할 수 있습니다.

표본이 통과해도 큰 파일에서는 입력 행 수와 출력 행 수를 다시 대조해야 합니다. 제거된 빈 행 수와 중복 행 수를 입력 수에서 빼면 출력 수와 맞아야 하고, 실패 수가 0이 아니라면 결과를 사용하기 전에 해당 파일부터 분리합니다. 이 네 숫자의 관계가 맞아야 ‘파일이 열렸다’보다 강한 완료 근거가 됩니다.

100행 무료 Lite로 자기 파일을 먼저 시험할 수 있습니다

CSV Audit Cleaner Lite 공개 릴리스는 CSV당 데이터 행 100개까지 처리합니다. ZIP을 새 폴더에 전부 푼 뒤 CSV_Audit_Cleaner_Lite.exe를 실행하고, 브라우저에 열린 로컬 화면에서 CSV를 고르면 됩니다. 별도 Python 설치나 클라우드 계정은 필요하지 않습니다.

더 큰 파일이 필요할 때만 행 제한 없는 정식판과 실제 보고서 화면을 확인하면 됩니다. 정식판은 일회성 $15이며, 무료판과 정식판 모두 맞춤 작업을 맡기는 서비스가 아니라 사용자가 직접 실행하는 완성된 Windows 도구입니다.

확인한 기준

2026년 7월 31일 기준으로 UTF-8 표본을 정식판으로 실행해 입력 4행·출력 2행·빈 행 1개·중복 1개·실패 0건을 대조했습니다. 제품 문서에서 UTF-8, UTF-8 BOM, CP949 입력 지원과 UTF-8 BOM 결과 저장, 원본 비파괴, 실패 격리 조건을 다시 확인했습니다. 공개 Lite ZIP의 크기와 SHA-256도 로컬 원본과 일치했습니다. 51초 영상과 공개 샘플 보고서는 같은 고정 로컬 표본을 사용합니다.