참여와 공유를 강조하는 새로운 디지털 비즈니스 모델의 성공과 더 나은 서비스의 지속적 제공을 위해 IT는 ‘시스템 통합(System Integration)’이라는 소위 ‘물밑 작업’을 꾸준히 진행해 왔습니다.

이는 결국 전사적 공급망 차원에서 비즈니스 규칙과 데이터를 서로 공유하게 하여 자체 시스템 및 주변 환경에 대한 상호 가시성을 높이기 위한 작업들인데요. 그렇다면 과연 무엇을 어떻게 통합하려는 것이고, 이것은 왜 필요한 것일까요?

‘Data Supply Chain’ 하의 정보 통합 그리고 통치

우선 빅데이터 시대의 기업 정보 관리와 관련하여 ‘Master Data Management(MDM)’를 근간으로 한 정보 통합에 대한 이야기를 해볼까 합니다. 이는 아주 광범위한 내용이지만 IT 관점에 국한해서 보면 결국은 크게 두 가지 측면에서의 통합이 필요한데요. 그 내용은 아래과 같습니다.

● 정보 통합
정보 통합은 서로 다른 시스템 및 애플리케이션들 간에 공유되고 참조되는 데이터들을 그 원천에서부터 전사적으로 일관성 있고 완전하게 유지되도록 ‘관리’하는 작업으로 빅데이터(Big Data) 처리와 Master Data Management를 기반으로 한 Data Governance에 기반한 방법으로 구현할 수 있습니다.

● 시스템 통합
시스템 통합은 다양하고 상이한 컴퓨팅 플랫폼, 비즈니스(B2B) 및 소프트웨어 애플리케이션들(A2A)이 서로 협조된 전체 시스템의 일부로써 운영되게 하기 위해 논리적•물리적•기능적으로 서로 ‘연결’하는 작업이라고 할 수 있습니다. 애플리케이션들 간의 상호 운용성을 높이기 위한 Business Process와 Enterprise Application Integration(EAI) 아키텍처를 이용한 설계, 통신 플랫폼이나 별개의 인터페이스 도구, 공통의 데이터 형식 등을 활용하는 방법 등을 포함합니다.

현재 디지털 세계에서 다루는 정보의 양은 매년 거의 두 배씩 증가하고 있는데요. 2020년에는 40조 기가바이트에 육박할 것으로 예상하고 있습니다. 이 가공할만한 양의 정보는 모든 인구가 연간 약 5,200 기가바이트의 데이터를 사용한다고 했을 때 나타나는 수치이죠.1

또한 앞으로 개인이 사용하는 데이터보다 기업이나 조직에서 사용하는 데이터는 더욱 방대해질 것으로 예상하고 있는데요. 이는 기존의 정형화되고 축적된 데이터뿐만 아니라 새롭게 증가하는 비정형화된 데이터까지 포함하는 빅데이터의 영향을 받기 때문입니다.

향후 제조 기업뿐만 아니라 모든 기업들의 미래 생존 전략은 결국 ‘제품 공급망 관리’를 넘어서 데이터와 그 밖의 서비스로 이루어지는 무형의 ‘Data/Information Supply Chain’을 어떻게 효율적으로 관리하고 운영하느냐에 달려있다고 봅니다.

그렇다면 ‘Data/Information Supply Chain’의 흐름도를 한번 살펴볼까요? 위의 그림에서와 같이 다양한 데이터 소스들을 통해 획득한 정보(Source)는 그 종류와 질에 따라 ‘Hadoop’과 ‘Data Warehouse’ 등에 나뉘어 저장됩니다. 이후 분석 기법을 통해 유의미한 정보로 재생산하고(Make), 필요한 의사 결정 부분에 분배(Deliver)하는 식으로 제품 공급망의 가치 부여 활동 단계를 답습하는 것이죠.

정보화 시대의 데이터는 어떠한 디지털 기반 조직에서도 마치 인체의 혈액과도 같은 역할을 하게 될 텐데요. 데이터를 혈액에 비유해서 표현한다면 혈액에는 다른 혈액형 및 불순물 등과 같은 것들도 있을 것입니다. 그러나 결국 자신의 몸에 맞는 일치된 혈액 안에 산소와 영양분만 담아 신체 곳곳에 전달하는 적이 목적이 되겠죠.

이때 불순물을 걸러내는 ‘신장’과도 같은 역할을 하는 것이 바로 ‘Analytics’가 될 것이고, 혈액 순환과 공급을 담당하는 심장과도 같은 역할은 Master Data Management와 같은 ‘Data Governance’를 통해 이루어질 것으로 보입니다.

그러면 혈액을 신체의 각 부분으로 원활하게 전달하는 ‘혈관’의 기능을 담당하는 것은 무엇일까요? 바로 위 그림의 화살표에 해당되는 데이터를 사용할 ‘시스템과 애플리케이션의 연결과 통합’을 통해 이루어진다고 볼 수 있습니다.

Big and Master Data Governance를 통한 정보 그리고 시스템의 통합

제조 시스템의 IT 통합을 위해서는 우선 관리하는 정형 데이터(Structured Data)들을 동기화해야 합니다. 그리고 일관성 있는 참조 정보를 기업이 필요로 하는 여러 부분에 제공하는 것이 무척 중요하죠. 이는 소위 말하는 진실을 담은 단일 자료(Single Source of the Truth)를 통해 이루어집니다.

여러분도 집안 정리를 제때 하지 않아서 필요한 물건이 어디에 있는지 모르고, 같은 물건을 반복해서 구입했던 경험들이 다들 있으실 텐데요. 데이터 관리 역시 이와 조금 비슷할지도 모르겠습니다.

비즈니스 레벨의 ERP, CRM, PLM, Data Warehouse 등의 시스템들은 개별 데이터 베이스들을 운영하고 있는데요. 따라서 이처럼 방대한 크기의 여러가지 분산 데이터 베이스를 기반으로 하는 비즈니스 애플리케이션들을 운용하는 기업의 입장에서 ‘관리’란 집안 정리처럼 쉬운 문제만은 아닐 것 같습니다.

흩어져 있는 불일치한 데이터를 API 쿼리/ETL(Extract, Transform, Load)을 통해 서로 간에 이송한다고 해도 이 과정을 각각의 데이터 소스에서 수행하는 것은 무척 비효율적이고, 나아가 궁극적인 통합을 기대하기는 사실상 어렵습니다.

1. 문제는, 분산된 데이터 베이스(DB)의 주인이 너무 많은 것…

우선, 시스템 내외를 통틀어 가장 중요한 데이터인 ‘제품’, ‘고객’, ‘공급자’ 등과 관련한 데이터만이라도 그 정합성(Integrity)을 유지할 필요가 있을 것 같습니다.

그동안 이러한 데이터들은 각각의 시스템에서 ‘마스터 데이터 ’2라고 정의하고 관리해 왔는데요. 문제는 표준화의 경우처럼 마스터라고 주장하는 데이터들 또한 너무 많다는 사실입니다. 마치 따로 정리해 둔 집안 열쇠의 이가 안 맞는 복사본들이 집안에 돌아다니고 있는 셈인 것이죠.

대부분 기업들의 앞서 언급한 비즈니스 시스템들이 적어도 10~20% 이상의 중복된 데이터를 포함하고 있다고 추정합니다. 또한 보고에 따르면 위의 그림과 같이 분리된 저장소에 갇혀 있는 낮은 수준의 여러 가지 정보 소스들로 인해 80% 이상의 기업들이 곤란을 겪고 있는데요.

그것은 바로 부정확한 보고, 어떤 데이터를 기준으로 삼아야 하는지에 대한 혼란, 잘못된 데이터 정의에 대한 추가 작업 등의 실제적인 업무 비효율의 경험이라고 할 수 있습니다.3

그러면 그 중에서도 고객 데이터의 예를 지금부터 한 번 살펴보도록 하겠습니다.

위의 표와 같이 고객 한 사람의 정보는 다양한 비즈니스 시스템들에서 이용될 수 있습니다. 하지만 동일한 고객이 서로 다른 데이터 세트에 서로 다른 값으로 중복되어 있거나 누락 혹은 데이터 필드의 내용이 서로 상이하거나 형식 등이 서로 다른 상황이 빈번하게 발생하죠.

이는 분리된 데이터 베이스에서 각각의 입장대로, 또 다른 시간 대에서 데이터 세트를 저장/관리해 왔기 때문인데요. 고객 데이터가 핵심으로 작용하는 ‘CRM’과 같은 애플리케이션들에서는 이러한 문제가 가시적으로 드러날 수 있습니다.

그래서 최근 다시 Data Warehouse와 같은 중앙 집중식의 저장소를 기반으로 분산 데이터 베이스를 물리적으로 통합하기 시작했는데요. Master Data Management를 통해 보다 일원화된 관리를 수행하여 중복 데이터 제거 및 데이터들의 정합성을 유지하기 위해 노력 중입니다.

또한 기업은 제품 마케팅을 위해 고객들을 대상으로 종종 캠페인 등을 진행하기도 하는데요. 이를 위해 연간 수천만 통 이상의 이메일, 브로셔, 쿠폰, 광고 메일 등을 보냅니다. 그러나 대략 15% 정도의 메일이 고객들에게 전달되지 못하거나, 잘못 전달되거나, 한 집에 두서너 개가 전달되기도 하는데요. 그 이유는 굳이 설명하지 않아도 위의 그림을 통해 확인하실 수 있을 것 같습니다.

2. 마스터 데이터들을 통합 관리하자!

비즈니스 레벨 시스템들의 목표는 업무 자동화뿐만 아니라 서로 다른 부서와 팀 간의 협업을 원활하게 하는 것이었습니다. 조직이 커지면서 일일이 다 모여서 상의하는 것은 비효율적이기 때문에 가상 공간에서 서로의 업무를 조직화하여 관리함으로써 업무의 효율성을 높이기 위한 것이었죠. 그러나 각기 다른 시스템에서 활용하는 데이터가 일관적이지 않으면 그때마다 모여서 상의해야 하는 일종의 패러독스 같은 상황이 발생합니다.

그래서 Master Data Management는 고객, 계정, 제품 자체, 설비, 메타 데이터 및 참조 값들과 같이 거래 데이터나 분석 데이터와는 다르게 잘 변하지 않는 속성 정보를 담고 있는 데이터들을 지속적으로 정의하고 관리하는 데 필요한 여러 프로세스와 도구를 포함하고 있습니다. 즉 Product Management, 데이터 품질 관리, 고객 데이터의 일원화, 구매 데이터들의 합병을 통해 정형화된 데이터 세트가 여러 애플리케이션들에게 일관적으로 참조 정보를 공급하는 것을 목표로 합니다.

또한 서로 간의 불일치한 데이터들이 여러 데이터 베이스에 쌓여 가는 것을 막고 데이터들의 다이어트를 유도하는 식의 데이터 통치를 함께 수행하기도 하는데요. 이것은 위의 그림을 통해 일반적인 중앙 집중식 Master Data Management의 계층적인 구조와 거시적인 데이터 흐름을 확인하실 수 있습니다.

그리고 Master Data Management는 아래 제시한 표의 내용과 같이 구축 수준에 따라 기본적으로 다음과 같은 역할을 합니다.

뿐만 아니라 DBMS를 개발•운영하는 IT 기업들(IBM InfoSphere, Oracle, SAP, Informatica, Tibco, SAS 등)이 고객용 및 제품용 Master Data Management 솔루션을 함께 제공하기도 하는데요. 대체로 아래와 같은 과정을 통해, 분산되어 있는 데이터 베이스의 마스터 데이터들에 대한 통합을 수행해 나가고 있습니다.

3. 제품 BOM(Bill of Material) 마스터 데이터들의 대한 논쟁

제조 업체 입장에서 더 중요한 것은 앞서 소개한 고객 데이터뿐만 아니라 그들이 제조하는 제품 데이터에 대한 일관성일 것입니다.

제품이 만들어지는 과정에서 디자인과 개발 부서, 생산 부서, 마케팅과 서비스 부서 등은 하나의 제품에 대해 여러 가지 다른 가치 부여 활동들을 수행하는데요. 그런데 문제는 이러한 활동들을 거치며 상대하게 되는 제품 데이터들이 오류를 동반하고, 때로는 서로 원활하게 동기화되지 않는 상황이 발생한다는 것입니다.

그 이유는 단계들을 거치면서 부정확한 데이터가 입력되거나, 상이한 애플리케이션들 사이에서 데이터가 잘못 옮겨 가는 경우가 있기 때문이죠. 또한 중복한 데이터들도 문제의 원인이 됩니다.

최근 PDM을 발전시켜 ‘PLM’이란 비즈니스 애플리케이션이 등장했습니다. 이것의 원래 취지는 이 시스템을 통해 비즈니스 레벨의 다양한 시스템들(궁극적으로는 CAD/PDM 대 ERP의 구도)의 데이터들을 통합해서 보다 제품 중심의 일원화된 기록을 제공해 보자는 것이었습니다. 그리고 이는 긍정적인 측면을 갖고 있기도 하지만 결과적으로는 기존 거래 중심의 ERP의 아성에 굴복하면서 여전히 상충되는 면을 보여 주고 있습니다.

예를 들어, 제품 마스터 데이터 중에는 가장 핵심이 되는 BOM(Bill of Material, 자재 명세서) 데이터가 있습니다. 제품을 만들기 위해서는 제품 구조를 트리 형태로 만들어 가장 윗 단의 완제품에서 시작해 그것을 조립하기 위한 세부 부품들, 재료들의 구성 및 수량을 명시하며 DB에 저장합니다. 그리고 그 정보를 내부 부서의 시스템들과 공급자, 계약 업체 등에 제공하죠.

그런데 이 BOM에도 여러 종류가 있습니다. 왜냐하면 여러 부서들에서 이 BOM을 작성하고 사용하는 자기들만의 방식이 있기 때문인데요. 여기서 또 어김없이 관점의 문제가 발생합니다.

즉 개발•디자인 파트에 있는 사람들의 방식에 맞춰 개발된 시스템이 ‘CAD•PDM•PLM’이라면, 생산 현장•서비스 파트에 있는 사람들의 방식에 맞춘 것이 ‘ERP 시스템’입니다. 그러다 보니 같은 제품이라도 BOM에 대해 생성•관리•사용의 주체가 다르게 되는 것이죠.

PLM 시스템이 CAD를 바탕으로 ‘Configuration BOM(cBOM)’과 ‘Engineering BOM(eBOM)’을 생성하면 그것을 바탕으로 ERP에서 ‘Manufacturing BOM(mBOM)’, ‘Service BOM(sBOM)’ 등을 변형하여 작성하는 식으로 말입니다. 아직도 많은 기업에서는 이런 데이터들과 관련해 스프레드 시트를 이메일에 첨부하는 식으로 서로 상호 작용을 하고 있다고 합니다.

이런 분위기라면, 당연히 MDM 솔루션을 통해 BOM을 오른쪽 그림과 같은 ‘Master Enterprise BOM’ 등으로 일원화하거나 동기화하여 관리하는 것이 당연한 수순일 듯 합니다. 특히 요즘 들어 보다 개인화된 제품의 다양한 구성이 요구되는 시점에서 부서별로 개별 BOM 마스터 데이터를 사용한다는 것은 전사적으로 볼 때 무척 비효율적인 것 같습니다. 또한 새로운 제품을 개발하고 테스트할 때도 그 추적이 어려워서 원활하게 진행될 것 같지 않습니다.

그러나 여기서 발생하는 것이 ‘데이터 소유권 문제(Data Ownership)’입니다. 웬만한 PLM, ERP 솔루션 벤더들은 MDM 솔루션도 같이 가지고 있는 경우가 많은데요. 그렇지 않고 제3자 MDM 솔루션을 이용해 통합을 진행하려 해도, 어떤 데이터를 기준으로 통합할 것이냐가 문제가 될 수 있습니다.

고객 데이터와 같은 경우는 어차피 외부 정보이기 때문에 상식적인 룰에 의해 처리하면 됩니다. 하지만 서로의 ‘입장’과 ‘소유권’이란 것이 존재하는 제품 데이터는 단순히 기술적, 의미론적으로의 통합 진행이 어렵다는 것이 바로 그 이유입니다.

한 예로 유럽의 항공기 제조업체 ‘Airbus’를 통해 극단적인 예를 찾아볼 수 있습니다. 우선 이 업체는 ‘CATIA CAD’ 애플리케이션을 사용하여 도면을 작성합니다. 그리고 도면을 작성할 때 사용되는 제품 데이터는 Dassault System社의 ‘Enovia’를 통해 가져오죠. 그런 다음 도면을 바탕으로 PTC社의 ‘Windchill’이란 PLM 애플리케이션을 이용하여 eBOM을 만듭니다. 이후 SAP ERP가 실제 생산을 위한 mBOM을 발행하는 것이죠.

뭔가 복잡하긴 하지만 여기까지는 별 문제가 없습니다. 그러나 역방향의 데이터 수정과 같은 변화가 발생하면 문제가 커집니다.

그래서 Siemens, Dassault, PTC/GE Intelligent Platform 같이 제품 중심 관점을 가지는 PLM-MES 솔루션들을 개발해 온 업체들은 mBOM의 소유권을 PLM으로 가져와서 함께 운영하는 Master Data Management를 통해 기존 eBOM과 완벽하게 동기화되는 mBOM을 ERP와 같은 다른 시스템에 공유하는 식으로 진행하고자 합니다.

그러나 기존에 그 데이터를 사용하고 있는 부서를 대변하는 SAP, Oracle과 같은 ERP 측에서는 절대 안 된다는 식으로 ERP 중심의 MDM을 내세우면서 첨예한 갈등을 빚고 있는데요. 한 예로 Tibco 시스템의 제품 관련 Master Data Management인 ‘Global Data Synchronization Network(GDSN)’ 등으로 맞불을 놓는 양상으로 흘러가고 있습니다.

국내에서는 위와 같은 정치적 양상과는 별개로, LG CNS에서 자체 개발한 MDM을 MES, Supply Chain Management System 등과 함께 ‘LG Display 7 Mega Process’에 적용한 바 있습니다. 그 밖에도 ‘데이터 스트림즈’라는 국내 데이터 관리 솔루션 회사 또한 이러한 MDM 솔루션을 국내 시장에 활발히 공급하고 있습니다.

지금까지 더 나은 제조 시스템을 위해 분산되고 분리된 데이터 베이스들과 개별 마스터 데이터들의 통합을 위한 ‘Master Data Management(MDM)’의 중요성을 함께 살펴보았는데요. 이어서 다음 시간에는 빅데이터 시대에서의 MDM의 한계 및 빅데이터와 MDM을 이어주는 새로운 형태의 MDM 방법 등에 대해 알아보겠습니다.

글 l 이승엽 연구원