거래처별 매출을 집계하려는데 ‘한빛상사’, ‘한빛 상사’, ‘ 한빛상사 ’가 서로 다른 항목으로 나온다. 이름을 통일하면 집계표는 짧아지지만, 비슷한 이름의 다른 회사를 합치면 정산 자체가 틀어진다.

OpenRefine은 비슷한 표기를 모아 검토할 때 유용하다. 다만 같은 회사인지는 거래처 코드나 사업자번호로 따로 확인해야 한다. 비교용 거래명세 24행을 정리했을 때도 자동 제안 중에는 합치면 안 되는 묶음이 있었다. 최종 결과가 맞았던 이유는 도구의 추천을 그대로 받아서가 아니라, 코드가 다른 항목을 제외했기 때문이다.

거래처 코드가 있다면 이름보다 코드를 먼저 쓴다

월별 파일을 합쳐 담당자에게 거래처별 합계를 넘기는 상황을 생각해보자. 정산 기준은 거래처 이름의 모양이 아니라 거래처 식별자다. 코드가 이미 정확하다면 엑셀에서 코드 기준 피벗 테이블을 만들고, 기준표의 정식 이름을 조회하는 방법으로 충분할 수 있다.

자료 상태	먼저 할 일
코드와 기준 거래처명이 모두 있다	코드로 집계하고 기준표의 이름을 조회한다.
코드는 있지만 표기 종류를 검토해야 한다	코드를 대조하며 OpenRefine의 병합 후보를 확인한다.
코드가 없고 이름만 비슷하다	사업자번호·주소 등 추가 근거를 찾고, 확인 전에는 합치지 않는다.

이번 비교 파일에는 invoice_id(명세 번호), vendor_id(거래처 코드), vendor_name(이름), amount(금액)를 넣었다. 24행에 거래처 코드는 10종, 표기는 24종이고 금액 합계는 390,000원이다. 아래는 입력 일부다.

invoice_id,vendor_id,vendor_name,amount
INV001,V001,한빛상사,1300
INV002,V001, 한빛상사  ,2600
INV003,V001,한빛 상사,3900
INV004,V002,ABC Tech,5200
INV005,V002,abc tech,6500
INV006,V002,ABC-Tech,7800
INV007,V003,Tech ABC,9100

원본 사본을 열고 거래처명 열에서 병합 후보를 찾는다

Windows에서는 공식 다운로드의 Java 포함 ZIP을 받아 압축을 푼 뒤 openrefine.exe를 실행한다. 브라우저에 열리지만 기본 작업은 로컬 프로그램에서 한다. 이번에 사용한 버전은 3.10.0이다. 확장 기능이나 외부 대조 서비스를 추가하면 자료 전송 조건이 달라질 수 있으므로, 회사 자료를 다룬다면 외부 연결 여부부터 확인한다. 공식 실행 안내에서 로컬 실행 방식을 확인할 수 있다.

1. 원본을 복사한다. CSV라면 한글이 깨지지 않는 UTF-8 사본으로 준비한다. 원본 명세 번호와 거래처 코드 열을 삭제하지 않는다.
2. Create Project → This Computer에서 파일을 선택한다. 미리보기에서 열이 제대로 나뉘는지, 코드 앞자리 0과 한글이 유지되는지 확인한 뒤 프로젝트를 만든다.
3. vendor_name 열 메뉴 → Edit cells → Cluster and edit를 연다. 먼저 key collision / fingerprint로 후보를 확인한다.
4. 묶음별 거래처 코드를 대조한다. 판단이 안 되면 병합 창을 닫고 해당 이름을 Text facet으로 좁혀 vendor_id를 확인한다. 코드가 다른 묶음은 선택하지 않는다.
5. New Cell Value에 기준표의 정식 이름을 적고 확인한 묶음만 Merge Selected로 적용한다. 결과를 확인할 때까지 전체 후보를 일괄 선택하지 않는다.

ABC Tech와 Tech ABC가 같은 묶음으로 제안됐다

첫 fingerprint 결과에서 ABC Tech, abc tech, Tech ABC, TECH ABC가 한 후보로 모였다. 그러나 입력에서 ABC Tech는 V002, Tech ABC는 V003이다. 이름이 비슷해도 다른 거래처로 유지해야 한다.

이 동작은 공식 클러스터링 설명과도 연결된다. fingerprint는 단어를 정렬해 비교하므로 단어 순서가 다른 이름도 같은 후보가 될 수 있다. 후보가 나왔다는 사실만으로 동일 거래처가 확인된 것은 아니다.

안전한 세 묶음만 반영한 다음에는 n-gram fingerprint를 size 2로 바꿔 띄어쓰기·붙여쓰기 후보를 확인했다. 그래도 남은 Seol Data와 Seoul Data는 nearest neighbor / Levenshtein에서 확인했다. 이때도 Seoul Date라는 별도 거래처가 비슷하게 잡혀, 코드가 같은 두 표기만 골랐다. 설정을 바꿀 때마다 후보를 다시 검토해야 한다.

마지막으로 가온물류(주)는 V007의 다른 표기와 코드가 같다는 것을 확인하고 셀 하나를 수정했다. 괄호 안의 ‘주’나 지점명을 일괄 삭제하는 규칙은 쓰지 않았다. 한빛상사 강남점처럼 별도 코드로 관리하는 항목까지 지워질 수 있기 때문이다.

이름만 바뀌었는지 명세별로 다시 대조한다

정리된 파일을 내보낸 뒤 명세 번호별로 원본과 비교했다. 총액만 같으면 된다고 보면 안 된다. 두 행의 금액이 서로 바뀌어도 전체 합계는 같을 수 있다.

확인 항목	정리 결과
행 수 / 명세 번호	24행 유지, 명세 번호 누락·중복 없음
거래처 코드 / 행별 금액	각 명세의 원래 값 유지
거래처명 표기	24종 → 10종
금액 합계	390,000원 유지
다른 코드의 거래처가 합쳐졌는지	없음

같은 코드 기준으로 만든 AI 보조 치환표도 최종 이름은 같았다. 이번 입력에서는 OpenRefine이 정답을 더 잘 찾았다고 볼 수 없다. 차이는 표기 후보와 변경 이력을 화면에서 검토할 수 있었다는 점이다. 코드 기준 치환표가 이미 잘 관리된다면 굳이 도구를 추가할 이유가 작다.

반대로 여러 부서가 보낸 파일에서 표기가 계속 늘고, 담당자가 무엇을 합쳤는지 함께 확인해야 한다면 OpenRefine을 검토할 만하다. 정리한 결과는 바로 정산 원장에 덮어쓰지 말고, 원본·정리본·확인한 코드 기준표를 함께 보관한다. 다음 달 파일에 같은 변경을 자동 적용하는 작업은 별도 검증이 필요하다.

금액 자료까지 옮기는 업무라면 업무 도구 배포 전 확인할 항목도 함께 확인해두자. 실행이 끝났다는 표시와 원본 값이 보존됐다는 확인은 서로 다르다.

확인일 2026-10-08 · OpenRefine 3.10.0 / Windows · 비교용 거래명세 24행의 입력·출력과 변경 이력을 대조했다.