현대 기업의 원동력은 데이터다. 빨리 정보에 접근해, 이를 토대로 행동을 하는 능력이 핵심 경쟁력이 됐다. 그러나 비즈니스 데이터가 고립되고,
기업들이 데이터를 이용하는 과정은 통상 다음과 같다. 다양한 구조의 여러 데이터 소스에서 데이터를 획득하고 변환한 후, 운영 중인 데이터베이스로 불러온다. 그리고 데이터가 필요한 비즈니스 애플리케이션을 지원한다. 분석, BI(Business Intelligence), 보고 도구는 이질적인 데이터 웨어하우스나 데이터 레이크에 위치한 경우가 많은 데이터에 액세스해야 한다. 이 때 이런 계층 모두에 보안 프로토콜, 정보 거버넌스 기준, 기타 운영 요건을 적용해야 한다.
이런 복잡성 때문에 정보가 ‘사일로’화 되는 경우가 너무 많다. 단기적인 요구 사항을 처리할 시스템을 매번 구축하거나, 서비스에 새로운 기능성을 지원할 새로운 기술을 거듭 추가시키곤 한다. 인수와 합병으로 새로운 데이터 소스가 추가되어 누적된다. 결국 특정 비즈니스 부문의 정보(예, 고객 정보)가 10여 곳의 단절된 장소로 분산된다.
오픈소스 기반의 NoSQL 도큐먼트 지향형 데이터베이스인 몽고DB(MongoDB)의 제품 및 시장 분석 디렉터인 매트 키프는 “우리 모두 주변에 데이터가 많다는 사실을 안다. 매년 40-50%씩 증가하고 있다. 모바일, 웹, 센서 데이터, 소셜 네트워크 등 소스가 많다. 이런 데이터에 대한 ‘싱글뷰’를 구현해야 할 필요가 절실해지고 있다. 아주 복잡하고, 고립된 데이터가 많으며, 일관된 경우가 드물고, 활용하기가 힘들다. 기업들은 아주 오래 전부터 ‘싱글뷰’를 구축해야 할 필요성을 느껴 왔다”라고 말했다.
몽고DB는 고객에게 서비스를 제공하면서 힘들게 얻은 경험을 토대로 조직이 데이터 ‘싱글뷰’를 구현할 수 있는 10단계의 방법을 개발했다.
(클릭하면 이미지 커짐)
1단계: 프로젝트 범위와 스폰서십을 규정
키프는 고객사들이 아주 야심 찬 계획을 수립해 ‘싱글뷰’ 프로젝트를 추진하는 때가 많다고 말했다. 비전을 갖는 것은 좋지만, 처음부터 보유한 모든 시스템의 고객 데이터에 대해 ‘싱글뷰’를 마련하려 계획하는 시도는 대개 실수다.
그는 “프로젝트 첫 단계에서 모든 데이터에 ‘싱글뷰’를 계획하는 것은 지나치게 야심 찬 계획이다. 한 가지 비즈니스 문제에 초점을 맞춰야 가장 성공 확률이 높다는 사실을 발견했다”라고 말했다.
예를 들어, 콜센터의 MTTR(Mean Time To Resolution)을 줄인다는 목표를 세울 수 있다. 이렇게 프로젝트 범위를 특정 목표로 좁혀야 한다. 그래야 더 쉽게 성과를 일궈낼 수 있는 데이터를 찾을 수 있다.
(클릭하면 이미지 커짐)
키프는 “뛰기 전에 걷는 법부터 배워야 한다. 특정 비즈니스 문제를 출발점으로 삼아야 한다. 그래야 필요한 데이터, 성과를 측정할 수 있는 목표를 파악할 수 있다”라고 설명했다.
이는 또 이점을 누릴 핵심 이해당사자를 파악하는데 도움을 준다는 설명이다. 매일 프로젝트에 관여하지 않지만, 프로젝트가 성공할 수 있도록 필요한 리소스를 지원할 수 있는 사람들이 누군지 이해할 수 있게 해준다고 키프는 덧붙였다.
2단계: 데이터 소비자를 파악
해결하고 싶은 비즈니스 문제를 파악한 후, 구현할 데이터 ‘싱글뷰’를 소비할 사람들을 이해해야 한다. 이들이 누구인지, 어떤 식으로 일을 하는지, 어떻게 해야 업무를 능률화 할 수 있는지 파악해야 요구 사항을 올바르게 정립할 수 있다.
키프는 “이들에게 일정 시간을 투자해 관찰해야 한다. 어떤 식으로 데이터를 쿼리할까? 텍스트를 검색할까? 고객 ID로 검색할까? 필요 이상으로 복잡해지면 곤란하다. 충분한 데이터를 얻을 수 없다”라고 말했다.
몽고DB는 보험사인 메트라이프(MetLife)가 콜 센터 직원들을 위한 ‘싱글뷰’를 구현하는 프로젝트를 도왔었다. 관찰을 통해, 콜센터 직원들이 흔한 고객 질문에 대답을 하기 위해 많게는 15개의 화면을 탐색해야 한다는 사실을 발견했다. 메트라이프와 몽고DB는 콜센터 직원들이 고객의 질문에 답을 제공하는 과정을 정확히 관찰해 훨씬 더 단순한 시스템을 구축할 수 있었다.
(클릭하면 이미지 커짐)
3단계: 데이터 생산자를 파악
2단계와 연결된 3단계는 프로젝트에 필요한 데이터를 생산하는 데이터 소스를 파악하는 것이다.
키프는 “새 데이터 소스를 만들어야 할 수도 있지만, 이미 데이터가 있는 경우가 많다. 그 장소와 획득 방법을 파악해야 한다. 새로운 특성이 반영되도록 기존 애플리케이션을 바꾸거나, 수동인 부분을 디지털화하는 것이 여기에 포함된다. 2단계와 마찬가지로 필요한 요구 사항 파악에 도움을 준다”라고 말했다.
4단계: 데이터 스튜어드(관리인) 지정
앞서 단계들은 ‘싱글뷰’ 프로젝트의 ‘발견(시작)’ 단계에 해당된다. 모두 요구 사항의 틀을 만드는데 초점이 맞춰져 있다. 4단계는 소스 시스템 데이터를 책임질 데이터 스튜어드를 임명하는 것으로, 개발 단계의 출발점에 해당한다. 데이터 스튜어드는 ‘싱글뷰’ 프로젝트를 수립하고, 이후 지속적으로 관리하는 과정에 아주 중요한 역할을 한다.
키프는 “그는 통상 2-3단계에서 발견한 데이터 소스를 책임진다. 데이터가 위치한 테이블, 형식, 추출 방법을 알고 있다. 또 핵심 데이터 시스템에 방해를 초래하지 않으면서 데이터를 활용하는 방법이 있는지 안다”라고 설명했다.
-> 기고 | 애널리틱스 확산··· ‘데이터 스튜어드’가 필요하다
5단계: ‘싱글뷰’ 모델 개발
이후 모든 것에 영향을 끼치는 아주 중요한 단계이다. 키프는 앞서 발견 단계를 성공적으로 이행했다면 그리 어렵지 않게 마무리할 수 있는 단계라고 강조했다. 데이터의 종류, 위치한 장소, 쿼리 방법을 파악해야 한다.
키프는 “반드시 필요한 데이터 종류, 선택할 수 있는 데이터 종류를 조사하는 단계다. 예를 들어, 이메일 주소와 생년월일, 신용카드 번호가 반드시 필요한 애플리케이션이 존재할 수 있다. 그러나 소셜 미디어 계정 데이터는 선택 사항에 해당하는 데이터가 될 수 있다. 이후 인덱스로 분류해야 할 데이터 종류를 파악한다. 그러면 소비 애플리케이션에서 실행시키고 싶은 쿼리의 속도를 높일 수 있다. 유연한 데이터 모델이 큰 도움을 줄 것이다. 옵션 필드를 알 필요가 없다. 필요한 경우 추가할 수 있기 때문이다. 반드시 필요한 데이터만 선택하면 된다”라고 말했다.
6단계: 데이터 로딩(불러오기)과 표준화
‘싱글뷰’ 데이터 모델을 만든 후, 이 ‘싱글뷰’에서 데이터를 표시하는 방법을 규정해야 한다. 캡처한 속성 필드에 동일한 이름을 적용해야 한다. 생년월일이라는 동일한 속성이 데이터 소스 별로 ‘DoB’, ‘Date of Birth’, ‘Birthdate’ 같이 다양하게 표현될 수 있기 때문이다. 이런 필드명을 표준화 해야 한다.
(클릭하면 이미지 커짐)키프는 다음과 같이 설명했다. “6단계는 소스 시스템에서 가져온 데이터를 변환하고 표준화시키는 단계다. 이는 첫 데이터 로딩이 출발점이 된다. 처음 로딩을 했을 때 ‘싱글뷰’ 데이터베이스는 비어 있는 상태이다. 이후 소스 시스템의 데이터를 규정한 요구 사항에 맞춰야 한다.”
“그런 후, ‘싱글뷰’로 업데이트 한다. 배치로 처리할 수도 있지만, 최근에는 더 새로운 ‘보기’를 원하는 경향이 있다. 이런 이유로 아파치 카프카(Apache Kafka)가 인기를 끌고 있다. 실시간에 가까운 버전의 데이터를 제공한다. 우리는 이를 ‘델타 로딩’이라고 부르고 있다.”
7단계: 매칭(비교), 통합, 조정
앞서 단계에서 데이터를 표준화 했지만, 여전히 소스 시스템을 기준으로 데이터가 일치하는지 파악하는 알고리즘을 사용해야 한다. 예를 들어, ‘Mat Keep’, ‘Mr. Keep’, “Matthew Keep’라는 레코드를 이용하는 비즈니스 출장 애플리케이션이 있다고 가정하자. ‘싱글뷰’ 애플리케이션은 이들 레코드를 매칭, 통합, 조정해야 한다.
키프는 “가장 힘든 단계 중 하나다. ‘Mat Keep’, ‘Mr. Keep’, “Matthew Keep’를 동일인으로 인식해야 한다. 따라서 매칭과 통합이 필요하다. 신용카드 번호 등 고유 식별자를 사용할 수 있다. 이 필드를 검색해 동일인임을 확인하는 것이다. 특징적인 데이터가 없거나, 오식이 있다면 파일 속성을 포착해야 한다. 유사한 속성의 레코드를 묶어, 동일인인지 판단을 내리기 시작할 수 있다. 이 과정을 자동화 하는 도구를 사용할 수 있을 것이다”라고 말했다. 한편 머신 학습이 이와 관련해 중요한 역할을 할 수 있다.
8단계: 아키텍처 디자인
아키텍처 디자인은 ‘싱글뷰’ 프로젝트를 적용하기 시작하는 단계다. 키프는 “실제 적용(배포) 방법에 대한 단계다. 기반이 되는 시스템이 목표한 성능, 가용성, 보안을 충족하도록 만들어야 한다. 이 단계에서 개인 식별 정보(PII)를 적절히 보안 처리하고, 시스템이 실패나 중단으로부터 복원력을 갖도록 만든다”라고 설명했다.
조치 9: 소비 시스템을 수정
데이터를 소비하는 시스템을 확인하고, 애플리케이션에 ‘싱글뷰’를 도입하는 단계다. 애플리케이션이 데이터를 가져올 RESTful API를 구현하는 경우가 많다.
조치 10: 유지관리 프로세스
고정된 상태로 변화하지 않는 비즈니스 시스템은 없다. 새 프로세스가 추가되거나, 버그가 수정될 때마다 시스템이 변경된다. 완벽한 데이터 모델을 구축했지만, 소스 시스템이 바뀌거나 없어져 5일 정도 밖에 사용 못할 수도 있다. ‘싱글뷰’ 프로젝트에서 유연한 데이터 모델이 아주 중요한 이유가 여기에 있다. 빠르게 바뀌는 소스 시스템을 따라갈 수 있는 데이터 모델을 개발해야 한다.
키프는 “10단계는 ‘메타’ 단계이다. ‘싱글뷰’를 유지하기 위해서는 앞서 9단계를 되풀이하고, 지속적으로 데이터 모델을 업데이트해야 한다. 10단계는 앞서 프로세스가 계속 순환하는 단계이다. ‘싱글뷰’를 최신 상태로 유지하기 위해 관리 프로세스를 바꿔야 한다. 데이터 스튜어드는 소스 시스템의 보호자 역할을 한다. 새로운 애플리케이션 기능이 배포되면, ‘싱글뷰’ 팀과 변경 사항을 처리해야 한다. ‘온-디맨드’가 되어야 한다. ‘싱글뷰’ 팀은 변화(변경)를 즉시 수용할 준비를 해야 한다. 그리고 데이터 스튜어드는 개발 팀과 밀접히 협력해야 한다”라고 강조했다.
‘싱글뷰’ 성숙도 모델
몇몇 ‘싱글뷰’ 프로젝트를 진행해 익숙해졌다면, 다음으로 야심 찬 비전을 수립해 추진할 수 있다.
키프는 “큰 목표를 추구하기 쉽다. 이 때에도 여전히 규정된 문제를 출발점으로 삼는 것이 더 효과적이다”라고 설명했다.
그는 이어 “싱글뷰를 구현하면 효과가 있다는 것을 알게 된다. 고객들은 더 적극적으로 이를 활용할 방법을 추구한다. 더 새로운 데이터를 얻기 위해 ‘싱글뷰’에 쓰기(writing)를 시작한다. 우리 고객 중 인터내셔널 뱅킹 그룹(International Banking Group)과 같은 기업은 싱글뷰 우선 접근법을 취한다. 이들은 새 기능이 필요할 때, 처음부터 ‘싱글뷰’로 구현을 한다. 백엔드 소스 시스템을 변경한 경우, 로드를 소스 시스템으로 역류시킨다”라고 설명했다.
dl-ciokorea@foundryco.com
