앞선 글에서 고객사 중복은 청소 문제가 아니라 입구 문제라고 했다.
이미 만들어진 중복을 반복해서 정리하는 것보다, 새로운 고객사 정보가 들어오는 순간 같은 회사인지 먼저 확인하는 편이 낫다는 이야기였다.
그렇다면 실제로 그 입구에는 무엇을 두어야 할까.
이번 글에서는 Linkspace가 고객사 이름을 어떻게 비교하고, 어디까지 자동으로 판단하며, 어느 순간 사람에게 결정을 넘기는지 이야기해 보려고 한다.
먼저, 입구가 하나가 아니었다
고객사 이름은 한 곳으로만 들어오지 않는다.
명함을 촬영해서 등록할 때 들어온다.
마케팅 캠페인의 참가자 엑셀을 올릴 때도 들어온다.
교육 신청자 명단을 등록할 때도 들어오고,
파이프라인에서 새로운 영업기회를 만들 때도 고객사를 찾아야 한다.
문제는 여기서 시작한다.
각 화면마다 고객사를 찾는 방식이 다르면 어떻게 될까.
명함에서는 같은 회사라고 판단했는데, 교육 신청자 등록 화면에서는 새로운 회사라고 판단할 수 있다.
한 화면에서 중복을 막아도 다른 화면에서 다시 만들어진다.
즉,
입구마다 판정 기준이 다르면, 입구 수만큼 중복이 만들어질 경로도 생긴다.
그래서 고객사 판정 로직을 각 화면에 따로 두지 않았다.
하나의 공통 엔진으로 분리했다.
어느 화면에서 고객사 이름이 들어오더라도 같은 순서와 같은 기준으로 판정한다.
그리고 뒤에서 설명할 별칭 학습 결과도 모든 입구가 함께 사용한다.
① 먼저 표기의 차이를 지운다 — 정규화
첫 번째 단계는 이름에서 회사를 구분하는 데 의미가 없는 차이를 제거하는 것이다.
예를 들어 법인격 표기가 있다.
㈜, (주), (유), (재), (사), (합), (학), (의)
그리고 이를 문자로 풀어 쓴 표현도 있다.
주식회사, 유한회사, 유한책임회사, 합자회사, 합명회사, 재단법인, 사단법인, 학교법인, 의료법인
영문 회사명에도 비슷한 표현이 붙는다.
Co., Ltd., Inc., Corp., Corporation, Company, LLC, Limited, GmbH
공백과 구두점도 이름을 갈라놓는다.
띄어쓰기, 마침표, 쉼표, 하이픈, 밑줄, 슬래시, 앰퍼샌드, 가운뎃점, 따옴표, 괄호 같은 표현이다.
여기에 영문의 대소문자 차이까지 통일한다.
그러면 앞선 글에서 봤던 이름들은 하나로 모인다.
㈜가나다정밀 가나다정밀(주) 가나다 정밀 가나다정밀
사람에게는 처음부터 같은 회사였지만 시스템에는 서로 다른 문자열이었다.
정규화를 거치면 모두 가나다정밀이라는 동일한 기준으로 비교할 수 있다.
영문명은 별도로 다룬다.
GANADA Precision Co., Ltd.를 정규화한다고 해서 한글명인 가나다정밀과 같은 문자열이 되는 것은 아니기 때문이다.
그래서 고객사마다 영문명 필드를 별도로 두고, 고객사를 찾을 때 한글명뿐 아니라 영문명도 함께 비교한다.
② 자동 판정에도 순서가 있다
하지만 정규화만 해놓는다고 끝나는 것은 아니다.
새로운 고객사 이름이 들어오면 Linkspace는 정해진 순서대로 확인한다.
1단계 — 사람이 직접 지정한 연결
담당자가 이전에
“이 표기는 이 고객사다.”
라고 직접 지정해 둔 관계가 있다면 그 판단을 가장 먼저 사용한다.
2단계 — 원문 그대로 일치
입력된 고객사명이 이미 등록되어 있는 고객사명과 완전히 같다면 해당 고객사를 사용한다.
3단계 — 정규화한 이름으로 비교
원문이 정확히 같지 않더라도 정규화한 결과가 같다면 같은 고객사 후보로 본다.
이때 비교하는 대상은 고객사명 하나만이 아니다.
고객사명, 영문명, 그리고 지금까지 학습된 별칭을 함께 본다.
여기서 중요한 것은 판정의 순서다.
특히 첫 번째 단계가 중요하다.
자동 판정이 사람의 명시적인 결정을 덮어쓰면 안 된다.
담당자가 이미
“이 이름은 저 고객사를 의미한다.”
라고 확인했다면,
그다음부터는 알고리즘이 다른 후보를 찾더라도 사람이 내린 판단을 우선한다.
자동화가 사람을 대신하려면 모든 것을 자동으로 판단해야 할 것 같지만, 실제로는 그 반대인 경우도 있다.
사람이 확실하게 알려준 것은 시스템이 다시 판단하지 않는 것.
그것도 자동화의 한 부분이다.
③ 정규화로 해결되지 않는 이름은 한 번만 가르친다
정규화가 잘 작동하는 것은 어디까지나 표현 방식만 다른 경우다.
하지만 실제 고객사 이름에는 문자열 규칙만으로 해결할 수 없는 경우가 많다.
브랜드명과 법인명이 다른 경우.
회사의 사명이 변경된 경우.
예전에 사용했던 이름이 그대로 남아 있는 경우.
가나다정밀 창원공장처럼 사업장 이름이 붙어 있는 경우.
이런 이름은 문자가 애초에 다르기 때문에 아무리 정규화를 해도 같은 문자열이 되지 않는다.
그래서 Linkspace에서는 사람이 한 번 연결하도록 했다.
담당자가 제시된 후보 중 실제 고객사를 선택하면,
처음 입력했던 원래 표기를 해당 고객사의 별칭으로 저장한다.
그리고 다음부터는 그 별칭도 고객사 검색에 함께 사용된다.
즉,
처음 한 번만 알려주면 된다.
같은 표기가 다시 들어왔을 때 시스템이 다시 묻지 않는다.
입구가 많을수록 오히려 빨리 학습한다
여기서 중요한 것은 별칭이 특정 화면에만 저장되지 않는다는 점이다.
모든 고객사 입력 경로가 같은 별칭 정보를 공유한다.
예를 들어 교육 신청자 엑셀을 업로드하면서
가나다정밀 창원공장
이라는 표기가 가나다정밀이라고 한번 알려줬다고 해보자.
다음 주 명함에서 같은 이름이 들어와도 이미 알고 있다.
파이프라인에서 연결한 별칭을 마케팅 캠페인 등록에서도 사용할 수 있다.
처음에는 여러 개의 입구가 문제였다.
입구마다 따로 판단하면 그만큼 중복 경로가 늘어났기 때문이다.
하지만 판정과 학습을 하나로 묶고 나면 상황이 달라진다.
입구가 많을수록 오히려 시스템이 같은 표기를 더 빨리 학습한다.
한 곳에서 배운 것을 다른 곳에서도 바로 사용할 수 있기 때문이다.
④ 애매하면 자동으로 잇지 않는다
그래도 남는 경우가 있다.
원문이 완전히 일치하지 않고,
정규화해도 같지 않으며,
아직 학습된 별칭에도 없는 이름이다.
이 경우에는 입력된 이름과 비슷한 고객사를 찾아 후보로 보여준다.
유사도를 판단하는 방식은 하나만 사용하지 않는다.
한 방식은 이름을 일정한 단위로 나눠 얼마나 많은 부분이 겹치는지를 본다.
다른 방식은 두 이름이 같아지려면 문자를 얼마나 수정해야 하는지를 본다.
두 방식은 장점이 다르다.
앞의 방식은 단어의 일부가 섞이거나 순서가 조금 달라진 이름을 찾는 데 유리하고,
뒤의 방식은 오탈자나 몇 글자 차이를 찾는 데 유리하다.
두 결과 가운데 높은 값을 기준으로 일정 점수를 넘은 고객사를 찾아 최대 세 건까지 후보로 제시한다.
하지만 여기에는 중요한 원칙이 있다.
후보를 찾았다고 해서 자동으로 연결하지 않는다.
이름이 비슷하다고 같은 회사는 아니다
자동으로 연결하지 않는 이유는 명확하다.
이름이 비슷하다는 것과 같은 회사라는 것은 전혀 다른 문제이기 때문이다.
계열사는 이름이 거의 같을 수 있다.
본사와 사업장도 같은 이름을 공유한다.
업종에 따라서는 서로 관계없는 회사가 비슷한 이름을 사용하는 경우도 있다.
이 상황에서 유사도 점수만 보고 자동으로 고객사를 합치면 더 큰 문제가 생긴다.
예를 들어,
가나다정밀
과
가나다정밀기술
이라는 서로 다른 회사가 있다고 해보자.
문자열은 매우 비슷하다.
하지만 고객도 다르고, 거래도 다르고, 매출도 다르다.
이 두 회사를 시스템이 임의로 하나로 연결하면 서로 다른 회사의 영업이력과 고객 정보가 섞인다.
그리고 두 가지 오류는 무게가 다르다.
같은 회사를 중복 등록했다면 나중에 확인해서 바로잡을 수 있다.
반면 서로 다른 회사를 하나로 잘못 연결하면,
어느 기록이 원래 어느 회사의 것이었는지 다시 구분하기 어려워질 수 있다.
그래서 Linkspace는 여기서 보수적으로 동작한다.
확실한 것은 자동으로 연결하지만,
애매한 것은 후보와 근거만 보여준다.
최종 판단은 사람이 한다.
되돌릴 수 있는 실수와 되돌리기 어려운 실수 중에서, 되돌릴 수 있는 쪽을 택한 것이다.
⑤ 찾아낸다고 끝나는 것도 아니었다
여기까지 만들고 나서 실제 운영 과정에서 예상하지 못했던 문제가 하나 더 나타났다.
시스템은 제대로 찾았는데, 사람에게는 보이지 않는 경우였다.
고객사 검색 결과에는 화면마다 표시할 수 있는 개수에 제한이 있다.
파이프라인에서는 50건,
고객사 등록 화면에서는 8건이다.
그런데 검색 결과를 단순히 이름순으로 나열하면 정확한 고객사가 뒤로 밀릴 수 있다.
실제로 라마를 검색했을 때 이런 일이 있었다.
가라마 라마테크시스템 …
이름 안에 라마가 포함된 회사들이 가나다순으로 먼저 표시됐다.
그리고 정작 찾던 (주)라마는 표시 개수 제한에 걸려 화면에 나타나지 않았다.
검색 자체는 실패하지 않았다.
시스템 내부에서는 해당 회사를 찾아냈다.
하지만 담당자에게는 보이지 않았다.
담당자 입장에서는 결국 이렇게 판단한다.
“등록된 회사가 없네.”
그리고 새로운 고객사를 만든다.
검색 알고리즘은 맞았지만 결과적으로 중복 고객사가 생긴 것이다.
찾아내는 것과 보여주는 것은 다른 문제였다
그래서 지금은 검색 결과를 단순 가나다순으로 보여주지 않는다.
먼저 검색어와의 관련도를 네 단계로 나눈다.
원문 그대로 일치 → 표기 차이만 있는 일치 → 해당 이름으로 시작 → 이름 안에 포함
그리고 같은 단계 안에서는 이름이 짧은 고객사를 먼저 보여준다.
예를 들어 라마라고 검색했다면,
이름 어딘가에 라마가 들어 있다는 이유만으로 긴 회사들이 먼저 나오지 않는다.
사용자가 실제로 찾고 있을 가능성이 높은 고객사를 먼저 보여준다.
아무리 검색 엔진이 정확한 결과를 찾고 있어도,
그 결과가 화면 밖으로 밀려나면 사용자에게는 찾지 못한 것과 같다.
그리고 사용자는 새로운 고객사를 등록한다.
결국 중복을 막으려면 검색 정확도뿐 아니라 검색 결과를 어떤 순서로 보여주는가까지 함께 설계해야 했다.
중복을 막기 위해 필요했던 네 가지
정리하면 Linkspace의 고객사 매칭은 네 가지 방식이 함께 작동한다.
첫째, 정규화한다.
법인격, 공백, 구두점처럼 회사 자체를 구분하지 않는 표기 차이를 제거한다.
둘째, 사람이 한번 알려준 관계를 기억한다.
문자열 규칙으로 해결하기 어려운 브랜드명, 옛 사명, 사업장 표기 등은 별칭으로 저장한다.
셋째, 애매한 경우에는 자동으로 판단하지 않는다.
비슷한 고객사를 후보로 보여주되, 서로 다른 회사를 잘못 연결하지 않도록 최종 판단은 사람에게 남겨둔다.
넷째, 찾아낸 고객사가 실제로 보이게 한다.
정확한 후보가 검색 결과의 뒤로 밀리지 않도록 관련도 순으로 정렬한다.
이 네 가지 가운데 하나만 있어서는 부족했다.
정규화만으로는 브랜드명이나 옛 사명을 연결할 수 없다.
별칭 학습만으로는 처음 등장한 표기의 중복을 막을 수 없다.
유사도 검색만 믿고 자동으로 연결하면 서로 다른 고객사를 잘못 합칠 수 있다.
정확한 후보를 찾아도 검색 결과 뒤에 숨어버리면 사용자는 존재하지 않는 고객사라고 생각한다.
결국 다시 처음의 결론으로 돌아온다.
중복 고객사는 정리하는 문제가 아니라, 만들어지는 순간을 막는 문제다.
그리고 그 순간은 한 화면에만 존재하지 않는다.
명함에도 있고,
마케팅 캠페인에도 있고,
교육 신청에도 있고,
영업 파이프라인에도 있다.
그래서 한 곳만 잘 만들어서는 해결되지 않았다.
모든 입구가 같은 기준으로 고객사를 바라봐야 했다.
다음은 날짜에 관한 이야기다
다음 글에서는 두 번째 문제로 넘어간다.
계약과 라이선스의 만료일에 관한 이야기다.
흥미로운 점은 만료일이라는 정보가 처음부터 없었던 것이 아니라는 것이다.
대부분 이미 계약서나 라이선스 증서 안에 정확하게 적혀 있다.
그런데도 갱신 시점을 놓치는 일은 반복된다.
왜 그럴까.
문서 안에 존재하는 것과,
영업 시스템이 사용할 수 있는 데이터로 존재하는 것은 다르기 때문이다.
다음 글에서는 이 질문에서 시작한다.
문서 안에 있는 날짜는 왜 관리되는 데이터가 아닌가.
키워드: 고객사 매칭, 거래처 자동 매칭, 중복 고객사 방지, 상호명 정규화, 법인명 정규화, 유사도 매칭, 문자열 유사도, 별칭 학습, 데이터 클렌징 자동화, 엑셀 업로드 매칭, 고객 데이터 통합, B2B CRM, 영업관리 프로그램, Linkspace