▲ 김은생 IBM 공인 정보관리 아키텍트다. 한국디지털대학 외래교수로도 활동하고 있다.

프롤로그 - 360도 Customer Single View를 아십니까?

첫 화살을 무엇으로 보느냐에 따라 사람마다 달라지겠지만 IT(정보기술)의 역사도 반세기를 넘어섰다. 나름대로 많은 시간이 흐른 IT 부문에 있어서의 가장 큰 특징은 가속화되는 변화와 발전의 속도라고 볼 수 있다. 어제의 신기술이 오늘은 진부한 것이 되어버리는 바람에 IT업계에서 종사하게 된 것을 피곤하게 생각한 적도 있었다.

그러나 이 급변하고 날마다 새로운 용어와 개념이 쏟아져 나오는 IT 역사상 절대 불변의, 가장 달콤하고 솔깃한 말 중 하나는 ‘360도 전방위 정보’라는 것이다. 20년 전부터 우리가 줄곧 사용해 온 익숙한 표현을 사용하자면, ‘통합DB’, ‘데이터통합’, 등의 용어들이 그 맥을 같이 하며, CRM의 부각과 함께, 이 말은 이제 고객정보에 그 초점을 맞추어 ‘360도 Customer Single View’라는 표현으로 자주 사용되고 있다. 360도 Customer Single View란, 고객에 대한 360도의 모든 정보를 고객별로 단일한 통합 관점에서 볼 수 있게 해야 한다는 것이다.

수년간의 CRM에 대한 부풀린 기대의 부작용으로 CRM의 성과에 대한 실망이 커지면서 CRM이 살았다, 죽었다 하는 논쟁이 일어났을 때도, CRM 성과 미흡의 주요 원인으로 고객정보의 통합과 품질이 지목되었다. CRM의 다른 각 부문은 물론이고, Basel II 등 Compliance 이슈에 있어서도 문제가 발생하면 약방의 감초 격으로 언제나 거론되는 것은 고객정보의 통합과 품질이다.

기업들이 해마다 마케팅 시스템이나 캠페인 시스템을 구축하고 CRM 패키지를 구입하지만, 그 성과를 모니터링하고 분석한 feedback에는 항상 고객정보가 없어서, 또는 고객정보의 품질이 낮아서 성과에 한계가 있다고 보고된다. 때로는 CIO를 넘어서서 CEO가 직접 나서서 고객정보 통합 TFT를 구성하게 하고 그룹차원 또는 전사 차원에서의 사업계획을 세우게 함으로써 강력한 추진력을 받는 것으로 보이기도 하지만, 일정 시간이 지나면 다시 고객정보가 없거나 통합되어 있지 않다는 이슈가 제기되어 왔다.

또한 고객정보의 통합과 품질이 이야기될 때 항상 제기되는 근본적 이슈로 지목되는 문제점은 고객정보의 분산이다. 어느 금융기관은 고객정보가 20여 시스템에 분산되어 있다고 하고, 어느 기업은 고객정보가 얼마나 산재되어 있는 지 파악할 수조차 없다고 한다.

산재된 고객정보를 하나의 시스템으로 통합해야 한다는 고객정보 통합DB의 구축 필요성이 제기되고, 많은 예산과 노력을 쏟아 고객통합 DB의 구축을 추진해왔고 계획하고 있다. 그러면 우리는 이제 고객통합DB를 통해 ‘360도 Customer Single View’를 갖게 되었는가? 아니면 가까운 미래에 갖게 될 것인가? 생각해 볼 필요가 있다.

통합DB, 그 영원한 화두
먼저, 통합이란 말을 살펴보자. 누구나가 금방 공감하면서도 고객정보의 통합 이슈를 들으면, ‘또, 그 정보의 통합이 문제야?’라는 반응을 보이게 된다. 기업의 경영진에게 조차도 이미 지난 수년 동안 줄곧 들어온 매우 진부한 이야기인 것이다.

사실 정보의 ‘통합과 공유’라는 가치제언은 IT의 첫 무렵부터 반복적으로 사용되어 왔다. 우리가 FORTRAN, COBOL, BASIC 등을 이용해서 프로그래밍을 시작하던 그 때 그 시절에는 데이터는 개별 프로그램 내부의 ‘변수’들로 존재하였다. 프로그램 내부 변수의 값들이 파일(file)에 데이터로서 저장/관리되게 되면서, 각각의 다른 프로그램들이 그 데이터를 ‘공유’할 수 있게 되었다.

그러나 각각의 프로그램들이 각각 파일을 열고 데이터를 쓰고 정합성을 유지하는 공통적인 일들을 반복하는 것이 이슈가 되면서, DBMS 즉, 데이터베이스 관리시스템이 등장하고 이 DB를 각각의 프로그램이 공유할 수 있게 하였다. 즉, DB의 등장 그 때도 강조된 것은 ‘통합과 공유’였다. 별도 DB에서 구축된 각각의 업무들간의 상호 연계성이 강조되면서 DB의 통합이 이야기되고, 분석 목적의 DW의 구축이나 운영(operation) 목적의 각종 통합DB의 구축이 추진되었다. 이때도 항상 강조된 것은 ‘통합과 공유’였다.

그러나, 이미 독자들이 짐작하였겠지만, 계속 진부하게 반복되어 온 것처럼 보이는 ‘통합과 공유’는 같은 이야기의 반복은 아니었다. 그 때 그 때 필요한 통합의 범위가 확장되면서, 지속적으로 정보의 통합과 공유의 중요성이 강조되어 온 것이다.

이는 고객정보에도 동일하게 적용된다. 약간 문학적 표현을 사용하자면, 강원도 산골 어느 작은 강가에서의 가을날 이른 아침, 가슴이 시리도록 너무나 진한 안개를 손에 한웅큼 쥐었다고 느꼈지만 손을 펴보면 어느새 아무 것도 남지 않은 것처럼, 고객정보의 통합도 수개월을 준비하고 또 다시 수개월에 걸쳐 요건정의, 모델링, 시스템 구축을 추진하였지만, 시스템 가동 후 얼마 지나지 않아 또 다시 고객정보의 통합의 필요성이 제기되는 경우가 종종 있다.

그러나 비록 고객정보의 통합 이슈가 일회성으로 끝내버릴 수 없는 영원한 화두라고 하더라도, 또 그 반복적으로 지속되는 이슈 제기가 통합범위의 확장이라는 유의미한 방향성을 가지고 있다고 하더라도, 고객정보의 통합을 추진함에 있어서는 스스로의 깊은 고민과 경험 많은 다른 사람의 도움을 통해, 모든 지혜를 동원해야만 한다.

이 글에서는, 360도 Customer Single View를 구현하기 위한 접근방법과, 기타 고객정보 통합을 추진함에 있어 고려해야 할 몇 가지 관점들을 살펴보려 한다.
　　
고객통합DB 구축이 360도 Customer Single View의 충분조건인가?
정확한 표현도 모르고 검증된 바도 없으나, 의학에 있어서 어느 환자가 어떤 병에 걸린 것이 확실하다는 진단 소견이 내려지면 그 병에는 기본적으로 어떤 치료법을 먼저 적용한다고 하는 것이 정해져 있다고 한다. 고객정보에 있어서도 마치 매뉴얼에 정해져 있는 것처럼, 각 기업들은 고객정보가 없다거나 산재되어 있는 것이 문제점으로 제기되면 고객통합DB의 구축을 추진한다.

그러나, 고객통합DB의 구축은 대개의 경우 약속한 바를 달성하지 못하고 또 다른 silo 또는 사용자들이 사용하지 않는 애물단지가 되어버린다. 고객통합DB는 구축하였으나, 거기에는 여전히 garbage성격의 데이터가 들어오거나 대부분의 field들에 데이터가 채워지지 않아서 사용자들은 불만을 갖게 되어, 시간이 갈수록 더욱 악순환이 반복되는 상황에 도달하게 된다. 

그러면 사업을 추진한 주체들은, 다른 부서의 일을 찾거나 문제의 원인을 외부 환경에서 찾으려 노력하게 된다. 대표적인 것이 각 채널의 업무담당자들이 고객정보를 입력하지 않는다거나 잘못된 데이터를 입력하기 때문이라고 이유를 대는 경우이고, 반면 각 채널에서는 시스템이 느리다든지 제대로 구축되지 않았다든지 하며 서로를 비난하게 된다.

여러 해 동안의 경험을 통해 갖게 된 결론은, 고객정보의 물리적 통합 즉, 고객통합DB의 구축은 360도 customer single view 구현에 유익한 것, 또는 필수조건이 될 수는 있으나 충분조건은 절대 아니라는 것이다.
그러면 360도 customer single view의 충분조건은 무엇인가? 우리는 답을 알지 못한다. 어쩌면 아예 답이 없을 수도 있다. 오히려 또 다른 필요조건들은 무엇이 있는지를 찾아보고, 그 필요조건들 간의 관계를 살펴보는 것이 훨씬 유익한 접근이 될 것이다.
　　
시스템이냐 비즈니스 혁신이냐?
고객통합DB의 구축은 360도 customer single view를 위한 시스템적 접근방법의 가장 대표격이다. 그러나 어느 기업이 단지 고객통합DB 구축에만 관심을 둔다면 매우 초보적 수준에 있다고 보는 것이 맞다. 시스템 차원에서도 고객정보의 통합과 개선을 위해서는 다른 많은 고려사항들이 있기 때문이다.

예를 들면, 각 고객정보 원천들로부터 통합DB로 데이터를 수집하기 위한 기술기반으로서 EAI 등의 방식을 사용할 것인가, Web Service방식으로 ESB(Enter-prise Service Bus) 개념과 연계시킬 것인가의 이슈가 있다. 또, 산재한 데이터들을 통합하기 위한 업무처리 및 데이터 변환을 통합DB에서 할 것인지도 결정해야 한다.

기존 고유의 고객DB를 사용하고 있는 application들을 모두 재개발 할 것인지, gateway application을 만들어서 단순한 wrapping 방식을 취할 것인지도 결정해야 한다. 어플리케이션을 구축하는 경우에는 SOA 등 새로운 아키텍처 사상과의 연계를 어떻게 할 것인지도 고민해야 한다. 또한 각각의 업무에서 필요로 하는 고객정보의 수준과 내용이 다를 때, 그것을 어떻게 하나의 통합된 형태로 구현/유지할 것인지도 결정하여야 한다.

이러한 시스템 차원에서의 다양한 고려도 매우 중요하고 기술적으로 복잡하지만, 여기에만 집착하는 것은 문제의 근본원인은 그대로 두고 계속 시스템만 반복 투자/개발하는 악순환 고리에 들어가게 되는 결과를 가져온다. 즉, 이기는 경기가 아닌, 질 수 밖에 없는 운명의 경기를 벌이는 어리석은 운동선수 격이 되고 마는 것이다.

오히려, 고객관리에 대한 전략이나 업무적 필요성을 재검토하여 필요한 고객정보가 무엇인지를 결정한 후, 어떤 채널에서의 어느 업무처리과정을 통해서 데이터를 습득/활용할 것인지, 그리고 이러한 과정들을 누가 어떻게 담당하게 하며, 그 성과를 어떻게 모니터링하고 평가/보상할 것인지를 검토하는 것이 먼저 선행되어야 한다. 이미 그 동안 여러 시행착오를 겪은 기업들은, 이러한 관점에서의 비즈니스 혁신을 추진하고 있으며, 그 첫 열매 (quick-win)들을 맛보고 있다.

그러나, 많은 경우 고객정보는 그 동안 IT 고유의 이슈로서 관리되어 왔고, 전사적 관점에서 고객정보를 담당하는 조직도 없으므로, 고객정보를 시스템 차원 이외의 비즈니스 혁신차원에서 접근해야 한다는 당위성을 느끼면서도 어떻게 추진해야 할 지 모르는 것이 일반적인 상황이다.

IBM의 Global Business Consulting & Service 부문은 이러한 고객의 pain에 대응하기 위해, 금융/통신/제조업계의 고객들의 고객정보 통합 및 활성화를 위해 해외에서의 practice들을 통해 CDI(Customer Data Integration) 추진을 위한 Business Framework을 정립했고, 국내에서의 독보적인 engagement들을 통해 이를 정제/보완하였다. 이를 CIIM(Customer Information Integration & Management)라는 이름으로 정리한 바, 그 중 일부 상위레벨의 고찰을 통해 비즈니스 혁신 부분의 접근 방법을 살펴본다.

IBM CIM 개요 - 고객정보 획득/관리/활용의 순환고리

	▲ <그림1> IBM CIIM Framework

많은 경우 고객정보를 정태적인 것으로 인식하지만, 여러 프로젝트 경험을 통해 IBM의 CIIM은 고객정보를 고객 및 외부로부터의 정보 획득과 사내에서의 관리, 그리고 비즈니스에의 활용이라는 동태적 프로세스에서 접근하는 것이 그 특징이다.

먼저 고객정보의 획득 측면을 살펴보면, 대부분의 기업이 업무처리절차는 상세히 정의되어 있더라도, 고객정보의 획득과 관련된 지침(guideline)은 정리되어 있지 못하다. 따라서 고객과의 접점에서 고객정보를 수집하더라도 이를 어떻게 처리해야 할지를 모르기 때문에 사장되는 경우가 대부분이다. 또한 고객과의 접점에서 일하는 직원들이 고객정보 획득의 중요성을 인식하지 못하거나 유인(incentive)을 느끼지 못하는 경우도 많다. 어렵게 고객정보를 획득한 경우에도 시스템적으로 기능이 미비하여 입력되지 못하고 사장되는 경우도 왕왕 있다.

일단 고객정보가 획득된 후에도 내부적인 관리의 절차가 미흡하기 때문에 활용으로 연결되지 못하는 경우를 생각해야 한다. 첫째는 고객정보의 품질관리이다. 전사적으로 고객정보 관리활동들을 책임지고 관리/운용할 운영조직에 대한 정의가 없는 경우가 대부분이고, 고객정보의 품질 체계도 미흡하여 전사적 차원에서 일관되게 관리되지 못하기 때문에 획득된 정보의 활용도가 매우 낮아지게 된다.

고객정보의 활용 측면을 살펴보면, ‘구슬이 서 말이라도 꿰어야 보배’라는 말도 있듯이 고객정보가 분산되어 있어 고객응대시점에서 쉽게 활용할 수 없거나, 고객에 대한 분석을 진행하기 위한 데이터 수집이 너무 어려워 포기하게 된다. 또는 고객정보 보호 등의 이슈로 인해 고객정보에 대한 권한이 없어 고객 응대시에 필요한 정보마저도 조회할 수 없는 상황도 있다. 역으로 개인고객정보의 무분별한 사용으로 인해 민원 또는 고객불만이 발생할 소지도 높다. 고객정보의 활용도가 높은 경우는 어떻게든 수집/생성할 수 있는 방안을 강구해야 하므로, 고객정보의 프로세스는 다시 획득으로 돌아오게 된다.

고객정보 통합을 위한 비즈니스 혁신의 Dimension들
고객정보를 통합/관리하기 위한 비즈니스 혁신 접근방법은 대개 5개 정도의 dimension으로 구성된다. 먼저 고객정보의 관리전략이 수립되어야 한다. 전략이라 하면 매우 막연한 표현이 되기 쉽지만, 고객정보에 있어서는 필요한 고객정보가 무엇인지를 명확히 하고 각각의 구체적인 고객정보를 어떻게 획득/관리/활용할 것인지에 대한 큰 그림을 그려내는 일을 뜻한다.

고객정보의 획득/관리/활용의 전략적 큰 그림은 다시 상세한 업무프로세스로 정의되어야 한다. 이러한 프로세스들을 어느 조직이 담당하게 할 것이며 그 때의 역할과 책임을 어떻게 할 것이냐가 함께 정의된다. 조직적 측면에서는 데이터 오너쉽 또는 data steward의 정의 작업이 포함된다. 프로세스와 담당 조직이 정의되면, 그 지속적 운영을 위해 무엇을 measure로 모니터링할 것인지, 그것을 성과관리 체계에 포함시킬 것인지 아니면 별도의 보상을 통한 인센티브를 제공할 것인지 등에 대한 설계가 필요하다.

이러한 일들의 가장 기본은 고객정보의 통합 데이터 모델을 통해 구체화된다. 고객정보 관리전략이든, 획득/활용 프로세스이든 성과관리이든, 모든 것이 통합데이터모델을 통해 비로소 뜬구름 잡는 격이 아닌, 구체적 실행계획으로 거듭나게 된다. 이 때 데이터 모델에 있어서 가장 중요한 덕은 전사적 관점에서의 표준 역할을 할 수 있는가, 그리고 업무변화에 대해 유연성 및 확장성을 제공하느냐에 있다.

이상의 내용들이 효율적으로 추진되기 위해서는 시스템 인프라의 구축이 불가결의 필수요소가 된다. IBM의 CIIM은 최상위 전략으로부터 베이스가 되는 시스템 인프라에 이르기까지 고객정보의 통합/관리를 위한 제반사항의 고려와 설계를 추진하기 위한 Framework으로서 활용된다.
　　
화타와 돌팔이 - 제대로 된 첫 매듭을 위하여
화타(華陀)는 중국 한나라 때의 명의로서 못 고친 병이 없는 명의이다. 반면에 우리는 전혀 자격증이나 검증된 내용 없이 만병통치를 자랑하는 약장사와 돌팔이 의사도 보곤 한다. 많은 미숙한 컨설턴트나 기업들이 고객정보 통합을 추진하는 프로젝트에서 가장 먼저 진행하는 Task는 ‘고객정보의 현황 파악’이다.

대개 DW를 구축하면서 데이터에 대한 이해를 키워 왔으나, 고객정보의 통합/관리에 대해 혁신적 사고를 추진해보지 못한 경우가 대표적인데, 이들은 너무나 당당하게, 사내 각 시스템에 있어서의 현행 고객정보 DB 및 테이블의 구조를 수집하고, 현행 시스템 담당자로부터 여러 이슈를 들으며 프로젝트 초기의 상당 기간을 보내게 된다.

그러나 시스템의 복잡도에 따라 다르지만, 2~3개월이 지난 후 이들이 손에 쥐게 되는 것은, 여러 시스템의 데이터 구조를 담은 수백 페이지의 엑셀시트와 잡다하고 사소한 부정적 이슈들로 가득 찬 회의록이 있을 뿐이다. 이 이슈들은 경영진 누구의 관심도 끌지 못하며, 기존에 여러 번 시도했으나 안 되었던 이유들만이 풍성한 회의록 내용은 향후의 개선 방향을 오도해나가게 된다. 결국은 채워지지 않는 고객통합DB, 활용되지 않는 또 다른 시스템의 구축으로 넘어가게 된다.

고객정보에 있어서 경험과 역량이 있는 컨설턴트와 열심은 있을 수 있으나 클라이언트에게 도움은 주지 못하는 컨설턴트를 구별하는 간단한 방법이 여기에 있으며, 애초부터 실패할 수밖에 없는 프로젝트에 참여하느냐 아니면 고질병을 고칠 수 있는 혁신적 성공 프로젝트를 이끌어 나가느냐를 갈라놓는 시금석이 여기에 있다. 명의 화타와 시장의 돌팔이는 구별되어야 한다.
　　
필요 고객정보의 정의 - 지혜로운 접근을 위해

	▲ <그림2> 필요고객 정보의 정의 관점

고객정보의 통합을 추진하기 위해 가장 우선적으로 이루어져야 할 것은, 고객응대와 고객이해를 위해 업무적으로 또는 전략적으로 필요한 고객정보가 무엇인지를 명확하게 정의하는 것이다. 여기에도 세밀한 방법론적 고려가 필요하다. 각 사업부서나 일선 채널의 직원들을 만나서 필요한 고객정보가 무엇인지를 물으면, 무엇이 필요한 지 이야기 할 것이라고 생각하면 큰 오산이다. 개인적 성향에 의해 워크샵이나 인터뷰에 잘 적응하는 사람들은 많은 이야기를 하기도 하지만, 역시 유의미한 내용은 아닌 경우가 많다.

IBM의 CIIM은 이를 위해 산업별로 고객접점에서 어떤 업무 이벤트들이 발생하는 지를 체계적으로 정리하고, 이를 기반으로 필요한 고객정보가 무엇이며 그 활용도가 무엇인지를 인터뷰를 통해 정리해나간다. 또한 필요한 고객정보란 절대불변의 것이 아니며, 고객의 유형에 따라 (즉, 개인인지, 기업인지) 또 어느 채널을 통해 고객을 응대하고 있는 지에 따라 (대면채널인지, 비대면 전화채널인지, 인터넷 사이트인지), 그리고 어느 상품과 관련되는가에 따라 필요한 고객정보는 달라진다.

이를 위한 framework을 상세히 정의하고 현장과의 인터뷰를 진행할 때 비로소 생생하면서도 의미 있는 현장의 목소리를 담을 수 있게 된다. 때로는 채널에서의 고객응대에 필요한 정보뿐만 아니라, 고객을 분석하는 데 있어서 반드시 필요한 정보도 있을 수 있다. 이 경우에도 IBM CIIM은 사전 정의된 고객정보 분석 framework을 기반으로 필요한 고객정보를 정의한다.
　　
고객정보 획득 방안 수립 - 그들이 온다?
‘꿈의 구장’(Field of Dreams)이라는 1989년 미국 영화가 있었다. 1987년 미국 아이오와 주에서 36세의 평범한 농부인 레이(케빈 코스트너 분)는 아내와 딸과 함께 옥수수 밭을 일구며 평범하게 살고 있다. 어느 날 밭에서 일하던 그는 훗날 그의 인생을 변화시키는 소리를 듣게 된다. 자신의 옥수수 밭에 야구장을 만들면 그가 온다는 계시에 따라, 레이는 야구장을 짓지만 주위의 시선은 냉담할 뿐이다. 그러나 돌아가신 아버지의 우상이었던 맨발의 조(Shoeless Joe Jackson)와 1919 시카고 블랙 독스의 선수들이 그의 야구장으로 나타나고 레이의 꿈은 점차 현실화 되어 가면서 영화가 전개된다. 필자는 아직도 옥수수 밭의 바람결에 들려오는 ‘If you build it, he will come.’이라는 속삭이는 소리를 잊을 수가 없다.

그러나, 이것은 영화이다. 많은 사람들이 고객통합DB를 구축하면 고객정보는 축적되게 될 것이라고, 아무 근거도 없이 낙관적으로 생각한다. 그러나 그 결과는 또 하나의 사용되지 않는 시스템이 구축될 뿐이다. 고객통합DB를 구축하더라도 데이터가 저절로 채워지는 것은 아니다. 고객정보의 수집을 위한 철저한 준비가 필요하다.

고객정보의 획득을 위해서는 각 정보항목별로 세밀하게 전사 차원에서 획득 방법을 다양화하고 이 방법들을 체계화해야 한다. 특히, 일상적인 업무처리과정에서의 고객정보 수집이 효과적이므로, 이 경우는 고객과의 접점 채널 및 업무 특성을 고려하여 어느 업무 이벤트 단계에서 어떤 정보를 어떤 시나리오로 수집할 것인지를 섬세하게 정의하여야 한다.

특정의 고객정보는 별도의 캠페인이 필요한 경우도 있다. 또 Inbound 고객뿐만 아니라 Outbound로 적극적인 정보수집 활동을 벌여야 하기도 한다. 있는 정보를 수집하는 경우도 있지만, 없는 정보이더라도 기존의 정보들의 가공/조합을 통해 생성해내기도 하며, 외부기관과의 제휴를 고려하기도 한다.

특히, 필요고객정보의 수집 작업은 고객의 민원이 발생하거나 접점 채널의 반발을 불러올 수 있는 소지가 많으므로, 매우 조심스럽게 접근하여야 한다. 모든 사람의 비즈니스는 그 누구의 비즈니스도 아니라는 말이 있듯이, 모든 고객정보를 수집하라 하는 것은 아무 것도 획득하지 못하는 결과를 가져온다. 따라서 우리는 필요고객정보에 가중치를 두어야 하며, 이러한 작업이 핵심고객정보항목의 정의 작업으로 연결된다. 이 작업도 섬세한 작업방법이 중요하며, IBM의 CIIM은 이를 정의해 놓고 있다.
　　
고객정보 활용 방안 수립 - 측정할 수 없는 것은 관리할 수도 없다
다양한 채널을 통해 수집된 고객정보는 각각 다른 모습을 갖는다. 다듬어지지 않은 광석에 지나지 않는 것이다. 활용할 수 있는 고객정보가 되기 위해서는 전사적으로 동일한 기준에 의해 표준화되고, 메타데이터 관리 및 품질평가 체계를 통해 그 품질이 측정되고 관리되어야 한다. 고객정보의 전사적 표준이라 함은 용어/항목/코드/도메인 등을 표준화하는 것이고, 고객정보에 있어서의 메타데이터는 일반적인 경우보다 훨씬 확장되어 오너쉽/중요도/접근권한 등의 다양한 측면들이 메타데이터로서 관리되어야 한다. 고객정보의 품질도 단순한 양적 가치뿐만 아니라 논리적 오류도 체크할 수 있어야 하며, 비즈니스에의 활용도도 중요한 품질의 결정변수가 된다.
　　
고객정보 활용 방안 수립 - 고인 물은 부패한다
한 번 수집/축적된 고객정보는 지속적으로 비즈니스에 활용되며 갱신되지 않으면 금방 쓸모  없게 된다. 다양한 원천으로부터 획득된 고객정보는 각 조직 및 채널에서 필요한 시점에 적절히 활용될 수 있어야 하며 가급적 많이 공유/활용되도록 장려되어야 한다. 고인 물은 썩기 마련이다.
하지만, 이때도 반드시 고객의 프라이버시를 침해하지 않아야 하며, 조직의 영업적 기밀이 누출되어서도 안 된다. 이를 위해서 관련 법규 및 업무특성을 반영한 조직별 채널별 정보 활용 지침을 마련해야 하며, 이는 전사적으로 반드시 준수되도록 해야 한다. 이를 위해 사용자 관리를 강화하고 관련 규칙을 정비해야 한다.
　　
고객정보 통합모델링 - 고객의 식별과 관계 관리

	▲ <그림3> 고객정보 통합 모델의 추상적 예시

이미 상술한 바와 같이, 고객정보와 관련된 모든 비즈니스 혁신적 접근은 고객정보 통합모델에 의해 검증되고 정리되어야 비로소 제 역할을 할 수 있게 된다. 고객정보가 채널간/시스템간에 불일치가 발생하고 이로 인한 비효율이 발생하는 것을 방지하기 위해서는 전사적으로 동의되고 이해되는 표준 고객정보 모델이 정의되고, 이를 기반으로 모든 일이 추진되어야 하는 것이다.

고객정보 통합모델의 중심은 고객이다. 고객을 중심으로 모든 접촉 및 거래정보가 통합되어 고객현황을 한 눈에 파악할 수 있게 해야 한다. 이 중심이 되는 고객에 있어서는 고객을 어떻게 식별할 것이냐가 가장 중요한 이슈가 되며, 이는 개인/개인간의 관계, 개인/기업간의 관계, 기업/기업간의 관계를 어떻게 관리하며, 그 관리 단위별로 어떻게 식별할 것이냐가 중요한 이슈가 된다. IBM의 CIIM은 이를 위한 다양한 방안들이 정리할 수 있는 프레임웍을 제공한다.

기존 고객정보 시스템을 개발했던 경험이 있는 사람이 고객정보 통합시스템을 구축하는 경우에, 오히려 성공적인 구현을 가로막는 경우가 있다. 기존의 고객정보 시스템은 단지 정보를 읽고 쓰는 단순한 작업이 대부분이었으나, 고객통합DB의 경우는 고객정보의 분할, 다양한 고객관계의 관리, 그리고 그에 따른 부속정보들의 분할과 통합 등 다양한 기능적 장치를 필요로 하게 된다. 이를 위해, IBM은 WCC라는 CDI(Customer Data Integration) 솔루션을 제공하고 있으며, 이는 고객정보의 혁신적 변환을 심도 있게 추진하는 사람은 절실하게 느낄 수 있는 가치를 제공한다.
　　
구조화된 데이터와 비구조화 데이터 - 데이터를 넘어서 컨텐츠로
IBM의 CIM을 활용한 고객정보 통합의 접근방법과 고려사항들을 상위레벨에서 고찰하였다. 보다 상세한 이슈들은 지면보다는 직접적인 세션을 통해 전달할 수 있을 것으로 생각한다. 그러나, 마지막으로 고려해야 하는 것은 고객정보란 무엇인가 하는 점이다. 많은 사람들이 이미 관리하고 있는 정형적 수치 데이터를 생각한다. 생일이 언제인지, 전화번호가 무엇인지, 구매한 상품이 무엇인지, 주소가 어디인지 등등의 정보는 기존 데이터베이스에서 잘 관리되고 있고 분석이 용이하다.

그러나, 데이터 관리의 다른 영역과는 달리, 고객정보 관리에 있어서는, Text 성격의 데이터를 어떻게 관리하느냐가 중요한 포인트가 된다. 고객이 전화를 했던 내용, 고객의 불만 내용, 고객의 문의 사항 등은 고객과의 접촉이 끝나면 사라지거나, 녹취록에 남거나, 기껏해야 Text 정보로 저장되게 된다. 그러나, 이러한 Text 정보는 다양한 분석은 물론 불가능하고, 여러 정보를 한 눈에 살펴보기도 어려워진다. 즉, 우리가 늘 해오는 데이터 관리 및 분석의 기능들이 적용되지 않는다.

이를 극복하기 위해서 여러 가지 방법들을 사용한다. 각각의 분류코드를 정의하여 어떤 상품에 대한 문의인지, 커뮤니케이션의 목적이 불만이었는지 정보 문의였는지의 각 경우들을 코드화하여 분류시킨다. 그러나 이 방법은 채널 직원들의 불만을 크게 사는 원인이 되고, 제대로 유효하게 입력되지 않는다. 또, 관점의 변화에 따라 변경시키는 것도 그 적용이 어려워진다.

어떤 경우는 각 채널에서의 텍스트 정보를 하나의 통합DB에 합하는 경우에, 그 포맷이 달라서 또는 그 길이가 달라서 어려움을 겪기도 한다. 보통의 시스템은 400KB 이내에서 관리가 되는데, 어느 인터넷 시스템은 1MB를 넘어서기도 한다. 이 경우에는 어떻게 할 것인가? 앞에서 400K까지만 잘라서 보관할 것인가? 핵심 어휘가 있는 부분을 중심으로 400KB를 자를 것인지 등등의 고려를 해야 한다.

또한 텍스트 성격의 커뮤니케이션 정보들은 그 중요성에 의한 차별화도 필요하다. 어떤 커뮤니케이션은 관리하는 것이 오히려 부담이요 노이즈가 되고 만다. 어느 경우는, 그 커뮤니케이션 내용을 어느 고객과 연결해야 할 지 망설여지는 경우도 있다. 연결해야 할 고객이 식별되지 않거나 여러 고객이 관련되는 경우이다. 이와 같이 고객정보의 통합은 지금까지 우리가 익숙하게 다루어오던 데이터와 매우 다른 고려와 접근을 필요로 한다. 여기에 경험 있는 컨설턴트와 잘 정비된 프레임웍의 존재가치가 있는 것이다.
　　
에필로그 - 고객정보 통합으로 가는 마지막 비상구
‘브룩클린으로 가는 마지막 비상구’라는 제목의 영화가 있었다. 영어 원제는 ‘Last Exit to Brooklyn’인데, 이 영화의 원래 포스터를 보면 우리말 번역이 영어 제목의 어감과 좀 다르다는 것을 느끼게 된다. 원래는 고속도로를 타고 가다 나오는 지역별 출구의 안내 표시인 것이다. 즉, ‘브룩클린으로 나가려면 여기가 마지막 출구입니다’라는 표시인 것이다. 그러나  원래의 영화 분위기를 고려하면, 우리말 제목이 필자 개인에게는 더 다가와 닿는다.

우리는 오랫동안 360도 Customer Single View 또는 고객정보의 통합을 추진해 왔으나, 그 결과는 기대에 크게 미치지 못했다. 360도 Customer Single View는 영원히 끝나지 않는 Never-ending challenge로서 우리에게 남아 있을 수 있다. 그러나 단순한 시스템적인 접근에서 시각을 확대해서, 전략적 측면, 조직적 측면, 프로세스 및 성과 관리 등으로 살펴보면 보다 real world에 적절히 대응할 수 있는 여지들이 아직 우리에게 많이 있음을 알 수 있다.

경험 있는 인력의 도움을 받으며, 잘 정비된 지적 산출물을 참조하며, 우리에게 있는 아픔과 이슈들을 체계적으로 깊이 고민하면, 우리에게 새로운 돌파구는 분명히 있는 것이다. 이미 그 열매를 따 맛보고 있는 Innovator들이 있으며, 우리도 그 단계에 이를 수 있다. 물론, Innovator’s Innovator의 도움을 받는다면, 그 확률은 훨씬 높아질 것이고.

필자 ; 김은생
IBM 공인 정보관리 아키텍트다. 한국디지털대학 외래교수로도 활동하고 있다.