[기고] 고객 데이터 모델 사례

고객 데이터 모델 이슈

고객 데이터는 거의 모든 조직에서 관리하고 있으며, 조직의 특성에 따라 대상과 범위가 다르고 관리하는 항목이 다를 수 있으나, 가장 중요하게 관리하는 데이터임은 분명하다.

국립국어원의 표준국어대사전은 고객을 "상점 따위에 물건을 사러 오는 손님"으로, 위키백과는 "고객(顧客)은 경제에서 창출된 재화와 용역을 구매하는 개인이나 가구를 일컫는다."로 정의했다. 어떤 기업에서는 상품/서비스 등을 직접 구입/계약한 고객뿐 아니라 구매 의사가 있는 고객도 대상으로 포함하는 등 고객의 개념과 대상을 기업마다 다르게 정의하고 있다. 조직에서 관리하는 고객 데이터는 고유/특성(나이,성별), 주소/연락처, 학력/경력, 재산/신용, 고객관계, 고객접촉 신용/마케팅정보활용 등 다양하다[그림1].

[그림1] 고객 주요 데이터

고객을 관리하는 방법은 다양하지만, 모델링을 하다 보면 가장 이슈가 되는 부분은 '고객을 어떻게 정의할 것이냐'이다. 회원, 개인, 법인, 사업자, 거래처, 대리점, 채널 등 고객과 관련된 용어들을 명확한 정의 없이 사용하는 경우가 많다. 흔히 고객의 특성(개인, 법인)과 역할/관계(회원, 거래처 등)을 혼용하여 사용하는 경우가 많다. 이러한 문제는 고객 식별번호(주민등록번호, 외국인등록번호, 법인등록번호 등)를 기준으로 고객을 정의하고, 한 고객이 회원이면서 거래처 등으로 여러 역할을 할 수 있다고 정의하면 쉽게 해결할 수도 있다.

[그림2] 고객 데이터 모델

(ERD는 정보공학(IE) 표기법을 기본으로 일부 바커(Barker) 표기법을 혼용하여 사용함.)

사업자 또는 사업장은 좀 더 고민스러울 수도 있다. 회사 내에서도 어떤 시스템은 법인 단위로 데이터를 관리하고, 어떤 시스템은 사업자 단위로 관리하는 경우를 종종 볼 수 있다. 법인 또는 사업자 기준으로 통일할 수도 있고, 법인과 사업자를 별도 고객으로 등록하고, 고객 간의 관계를 통해 해결할 수도 있다. 계약과 같은 업무처리 관점에서 본다면 법인이든 사업자든 별 문제가 아닐 수 있다. 하지만 통계자료를 제공하거나 데이터를 분석할 때 공통되고 일관된 기준을 적용할 수 있어야 한다. 데이터 측면에서는 개인, 법인, 사업자, 사업장 속성에서 공통된 것은 무엇이고, 개별로 관리하는 것은 무엇인지를 파악하여 어떻게 관리하는게 좋을지 판단할 필요가 있다. 위의 [그림2]에서 사업자를 개인/법인 고객의 부가정보로써 관리한다면 상관없겠지만, 그렇지 않고 계약 당사자나 상품이 위치하는 장소를 포함한다면 고객으로 통합하는 것도 좋은 방법일 것이다. 결국, 고객 데이터 관리는 데이터 관점도 중요하지만 고객에 대한 명확한 업무정의가 선행 되어야 한다.

고객 데이터 관리 사례 1

A사는 고객 데이터를 개인고객, 회원, 마케팅회원, 사업자, 업체 등으로 나누어 관리하고 있었다[그림3]. 동일한 사람이라 하더라도 월에 가입한 회원인지 회사의 상품이나 서비스를 이용하는 고객인지에 따라 여러 테이블에 중복하여 관리하고 있었고, 사업자의 경우 개인사업자냐 법인사업자냐에 따라 개인이나 거래처 데이터와 중복되기도 한다. 중복관리로 인해 데이터를 변경하거나 관리하는 데 많은 어려움이 있었고, 데이터 불일치 문제로 인해 마케팅 활동을 하는 데 많은 비용을 지불하기도 하였다. 아마 오랫동안 시스템을 운영하면서 데이터 통합에 대한 깊은 고민없이 필요할 때마다 테이블을 추가한 것으로 판단된다.

[그림3] A사 현행 고객 데이터 구성

To-Be 시스템을 구축하면서 데이터 품질을 높이기 위해 고객을 정의하고 통합했다[그림4]. 고객은 서비스를 이용하는 개인(주민등록번호)과 서비스 이용 및 제공을 위해 거래하는 사업자(사업자등록번호)로 구분했으며 법인은 법인 단위가 아닌 사업자 단위로 관리하기로 했다. 개인 사업자인 경우 고객 테이블 내에서 개인과 사업자 간의 1:M 관계를 가지는 것으로 정의했다. 또한, 데이터 관리를 효율적으로 하기 위해 고객 데이터를 고객의 고유정보(주민등록번호, 고객명, 주소 등)와 고객의 역할정보(웹회원, 마케팅회원, 구매처, 판매처, 제조사 등)로 나누어 관리하였다. 추가로 개인정보보호를 위해 주민등록번호 등의 개인정보는 암호화를 통해 비식별화 하였다.

[그림4] To-Be A사 고객 통합 방안

고객 데이터 관리 사례 2

또 다른 사례로 B사는 고객을 업무적인 관점에서는 "우리 회사의 다양한 상품이나 서비스를 구매하거나 이용한 경험이 있는 고객이거나 마케팅 활동 등을 통해 접촉한 개인 중에서 구매 의향을 표시한 잠재 고객"으로 정의하였고, 정보수집 측면에서는 "개인(또는 법인)을 식별할 수 있는 주민(법인)등록번호 등의 식별자와 주소, 연락처 등의 접촉 가능한 정보가 있거나, 식별정보는 없으나 고객명과 접촉정보를 가지는 주체"로 관리하고 있었다. 이러한 두 가지 관점의 정의를 재해석하고 통합하여, 고객의 범주에 해당하는지를 판단하기 위해 아래와 같은 4가지 기준을 만들었다.

식별 가능한 :   주민번호, 여권번호, 사업자등록번호 등의 식별번호를 가짐

접촉 가능한 :   주소, 전화번호 등의 접촉 가능한 정보를 가짐

지속 가능한 :   일회성 거래가 아닌 지속적인 거래를 위해 정보관리 필요성이 있음

거래 주체　 :   실제 경제활동을 수행하는 단위이며, 
　　　　　　　 이름, 법인명, 단체명 등의 지칭할 수 있는 명칭을 가짐

그리고 업무를 하면서 계약, 판매, 거래 관계에 해당하는 이해당사자를 대상으로 고객 후보군을 도출하여, 위에서 정한 4가지 기분을 근거로 하여 고객관리 범위에 해당하는지 판단하였다.

[표1] 고객 판단을 위한 기준

글을 마치며

이 외에도 고객을 어디까지 볼지 다양한 이슈가 있을 수 있다. 직원을 고객에 포함할지, 개인과 개인사업자는 하나의 고객인지 별도 고객으로 관리할 것인지 판단하기 애매한 부분도 있다. 어떻게 모델링 해야 하는지 정답은 없지만, 어떻게 설계했는지 방향은 제시할 수 있어야 한다. 위에서 살펴본 것처럼 고객 후보를 도출하고 일정한 기준을 가지고 다시 후보군으로 분류하고 고객이 가져야 할 필수 조건을 정해서 고객을 정의한다면 현업도 수긍하지 않을까? 고객에 대한 이슈는 데이터 모델의 문제이기도 하지만 업무를 어떻게 정의하느냐의 문제이기도 하다. 모델러가 모든 것을 판단하기 보다는 현업이 판단할 수 있도록 근거 자료를 만들고 근거(기준)를 제공하는 것이 더 좋은 방법일지도 모른다.