DATOR


DA의 활용 - 10. 데이터 아키텍처를 활용한 이종(異種) 시스템 통합 이화식컬럼


10.      데이터 아키텍처를 활용한 이종(異種) 시스템 통합 

 

산업이 발전함에 따라 시너지 효과를 노린 경쟁력 확보를 위해 인수 합병을 통한 기업통합이 매우 빈번하게 일어나고 있으며 갈수록 이런 현상은 더욱 거세질 전망이다. 기업이 통합된다는 것은 여러 가지의 많은 변화를 의미하지만 그 중에서 빼 놓을 수 없는 것은 기업의 핏줄이라고 할 수 있는 정보시스템의 통합이다. 사실 모든 면에서 기업이 통합되었더라도 정보시스템이 통합되어 있지 않았다면 그것은 진정한 하나의 기업이라고 할 수 없고, 당연히 본래 통합의 목적인 시너지 효과를 얻는 것도 거의 불가능 하다.

 

이처럼 정보시스템의 통합이 하루라도 빨리 이루어지는 것은 매우 중요하지만 그게 어디 말처럼 쉬운 일이 아니질 않는가? 마치 실핏줄까지 모두 정밀하게 연결해야 하는 접합 수술처럼 오랫동안 전혀 다른 구조로 관리되었던 시스템을 하나로 통합한다는 것이 결코 쉬울 수가 없다. 마치 처음부터 원래 하나였던 것처럼 두 개 시스템의 모든 과거 데이터까지 완벽하게 통합하여야 한다면 그건 정말 어려운 일이다. 

 

사실 많은 업체들이 엄청난 대형 시스템을 무사히 통합했노라고 자랑하고 있지만 그들에게 몇 가지 묻고 싶은 것이 있다. 첫 번째 질문은 피인수 기업의 데이터를 과연 얼마나 제대로 살려왔느냐는 것이다. 다시 말해서 고객 관련 데이터처럼 반드시 살려와야 할 데이터만 가져오지 않았느냐는 것을 묻고 있는 것이다. 이것은 엄밀히 말해서 시스템을 통합한 것이 아니라 고객을 통합한 것에 불과하다. 다른 의미로 보면 갑자기 엄청난 수의 고객이 다른 곳에서부터 이월되어 온 것을 처리한 것이나 별반 다를 것이 없다는 것이다.

 

두 번째로 묻고 싶은 질문은 통합을 하면서 기존 시스템의 문제를 얼마나 해결하였느냐에 대한 것이다. 옛말에 ‘떡 본 김에 제사 지낸다’는 말이 있다. 어차피 수술을 해야 한다면 지금껏 꼭 하고는 싶었지만 여러 가지 사유로 인해 차마 손댈 수 없었던 것을 이번 기회에 같이 해결해야만 하지 않겠느냐는 것이다. 물론 근본적으로 개선된 차세대 시스템을 구축하는 일은 통합 후에 본격적으로 논의될 수도 있겠지만 사실 그것이 언제가 될지도 확실하지 않고, 현재의 문제를 그대로 방치한다면 계속해서 문제가 발생될 것이라면 통합 프로젝트를 수행하면서 최대한의 조치를 하도록 해야 할 것이 아니겠는가?

 

세 번째 질문은 시스템 통합에서 데이터 아키텍처를 제대로 수립하였느냐에 대한질문이다. 시스템 통합이란 일반적으로 대부분이 데이터 통합이라 할 수 있기 때문에 통합을 잘하기 위해서도 그러하고, 앞으로의 유지·보수에도 큰 보탬이 되며, 향후 차세대 시스템을 구축할 때에도 중요한 참조자료가 될 수 있는 데이터 아키텍처를 제대로 수립하였느냐는 정말 의미가 있다. 천신만고 끝에 엄청난 데이터를 통합하였는데 어찌 당연히 남아 있어야 할 데이터 아키텍처가 없다는 것인가! 그렇다면 상호 보유한 데이터 집합을 정확히 모르면서 도대체 무슨 재주로 통합을 했다는 말인가? 그럼에도 불구하고 과연 그 결과를 믿어도 좋겠는가?

 

필자는 얼마 전에 10테라바이트가 넘는 두 개의 통신회사 시스템을 통합하는 프로젝트에 직접 참여한 적이 있다. 한 쪽은 세계적으로 유명한 어떤 ERP패키지를 사용하고 있었고, 다른 한 쪽은 자체 개발한 시스템이었다. 물론 H/W, DBMS, 프로그래밍 언어까지 같은 것이라고는 하나도 없었으며, 단지 비슷한 상품을 취급한다는 것뿐이었다. 처음 양쪽 시스템을 파악해본 후 첫마디 소감은 “여기 두 대의 라디오가 있는데 하나는 트랜지스터 라디오이고, 다른 하나는 진공관 라디오였다. 둘 다 소리는 나지만 부품과 회로는 어디에도 닮은 곳이 전혀 없다”라고 표현했었다.

 

이 말은 마치 두 라디오에서 소리는 나는 것처럼 어쨌거나 각사의 업무는 처리되고 있었지만 각 시스템의 내부를 살펴보면 정말 닮은 곳을 전혀 찾아볼 수 없었다는 것이다. 어디나 똑 같은 모양으로 있어야 할 것으로 보이는 ‘고객’부터 전혀 달랐다. 한 쪽 시스템의 고객은 ‘가입의 주체’인 사람(법인 포함)만의 집합이었고, 다른 한 쪽은 분명히 명칭은 ‘CUSTOMER’로 되어 있지만 사람이나 법인과 같은 개체 집합이 아니라 청구계약을 맺을 때마다 개체가 생성되는 행위 집합이었던 것이다. 더욱 놀라운 것은 개발자들이 그 집합을 지금까지 행위의 주체가 되는 사람이나 법인의 집합으로 생각해 왔고, 그대로 CRM을 해 왔다는 것이다.

 

이 두 회사는 얼마 전까지는 서로 경쟁 관계에 있었기 때문에 각자 보유한 상품들에는 매우 독특한 것들이 많았다. 유사한 상품을 통합하려고 해도 아직 그 상품을 사용하고 있는 가입자들이 많이 남아 있기 때문에 설사 이제 더 이상 그 상품을 새롭게 판매는 하지 않더라도 무조건 버릴 수도 없었다. 통신회사의 상품이란 판매하면 그만인 것이 아니다. 기본료와 각종 서비스를 특별하게 묶은 것을 상품이라고 하므로 일단 판매하면 그 상품을 사용하는 가입자가 모두 탈퇴하거나 다른 상품으로 옮겨 가야만 없앨 수가 있다.

 

상품이 시스템에 완벽하게 반영되어야 한다는 것은 거기에 따르는 수 많은 관리들도 같이 감안되어야 한다는 것을 의미한다. 결국 이 말은 어느 한쪽을 무조건 다른 쪽에 맞추는 통합이 아니라 두 시스템을 혼합하여 제3의 시스템이 만들어져야 한다는 의미가 되는 매우 어려운 프로젝트였다. 물론 시스템의 전반적인 기반이나 기준은 인수를 하는 기업이 되었지만 두 시스템을 머지(merge)해야 한다는 것이 일을 매우 복잡하게 만들었다. 그것은 양쪽 모두를 명확히 알지 않으면 결코 머지를 할 수 없기 때문이었다.

 

집합적으로 본다면 ‘A’와 ‘B’의 합집합(union)을 구해야 한다는 것을 말한다. 합집합이란 단순히 집합이 결합된 것을 의미하는 것이 아니라 ‘최소공배수’ 집합을 의미한다. 즉, 단순 결합은 ‘UNION ALL’을 말하지만 이것을 다시 유일한(distinct) 개체 집합으로 만들어 낸 것이 바로 합집합이다. 이처럼 완전히 상이한 두 시스템의 데이터 집합으로 제3의 최소공배수 집합을 만들어야 한다는 것은 필연적으로 데이터 모델이 크게 영향을 받게 되었다는 것을 의미하며, 당연히 거기에 관련된 애플리케이션도 같이 영향을 받을 수 밖에 없었다는 것을 뜻한다.

 

어차피 제3의 데이터 모델이 만들어져야 한다면 기준이 되는 인수 기업이 가지고 있던 심각한 문제들을 도출하여 이번 기회에 같이 해결해야 하는 것이 옳다. 필자는 오히려 이 문제 때문에 ‘갑’과 충돌을 겪었다. ‘을’인 우리가 힘이 들더라도 이 시스템의 중대한 결함을 이번 기회에는 반드시 같이 고쳐야 한다고 의욕을 보이고 있는데, 오히려 ‘갑’이라는 사람들이 통합 프로젝트에 부담이 될 수 있으니 그냥 가자고 하는, 어쩌면 앞뒤가 뒤바뀐 설전을 벌렸다. 그러나 필자가 누구인가? 옳다고 생각하면 절대 양보를 하지 않는 사람이다. 후일담이지만 1년이 채 지나지도 않아 그렇게 수정하지 않았다면 큰 사단이 벌어질 수 있는 모종의 일을 겪고 난 그들은 자신들의 반대를 무릅쓰고서도 회사를 위해 정말 귀중한 역할을 해 주었다는 것에 깊은 감사를 보냈다.

 

데이터 모델은 시스템의 골격이기 때문에 함부로 수정될 수 없는 것이다. 새롭게 시스템을 구축하거나 이처럼 통합 프로젝트를 통해 대수술을 하는 경우에만 할 수 있는 – 즉, 쉽게 기회가 오지 않는 – 귀중한 기회이므로 이것을 그대로 날려 보낸다는 것은 결코 옳은 일이 아니다. 결국 통합 프로젝트의 최대의 관건은 데이터의 통합일 수 밖에 없으므로 이를 위해서 우리가 할 수 있는 가장 바람직한 일은 바로 두 시스템의 현행 데이터 모델을 정확히 분석하는 일이었다. 우리는 이를 위해서 매우 정밀한 현행 데이터 아키텍처를 수립하였다. 매우 방대한 시스템을 리버스해야 했기 때문에 가장 어려운 것은 기존의 자료가 지극히 부실하다는 것과 어느 정도 깊이 파고들었을 때 구체적인 대답을 해 줄 사람이 거의 존재하지 않았다는 것이었다.

 

우리는 이러한 현실적인 문제점들을 해결하기 위해 다양한 모델링 기법을 활용하였다. 여기서 사용한 ‘수사력을 극대할 시킬 수 있는 방법’은 앞으로 설명할 데이터 모델링 단계에서 아주 상세하게 언급하게 될 것이다. 특히 자료를 조사하거나 사람들과의 인터뷰에서는 도저히 확인할 수 없는 많은 것들은 데이터를 직접 분석해 봄으로써 많은 진실(?)을 캐 낼 수가 있었다. 물론 마치 모국어를 자유롭게 사용하는 ‘NATIVE SPEAKER’처럼 수백 라인의 애플리케이션으로 작성해야 할 처리를 단 십여 라인의 SQL로 데이터와 자유로운 대화(?)를 할 수 있는 능력을 가진 사람들이 있어 데이터 속을 헤집고 다녀보면 정말 우리에게 유익한 다양하고 많은 정보들을 얻을 수가 있다.

 

어쨌든 앞서 설명했던 현행 시스템을 리버스해서 두 시스템의 물리적 모델까지 만들어 보았더니, 두 시스템의 데이터 모델의 구조가 다른 것은 차치하고라도 각 엔터티의 집합적인 의미와 구성까지도 너무나 상이하다는 것을 알 수 있었다. 그러나 이렇게 다른 것을 그저 조사만 해 두는 것은 큰 의미가 없다. 이들을 이상적인 목표 데이터 모델이 되기 위해서는 어디를 어떻게 보완하고, 어떤 변화를 주어야 하는지 같이 평가해 두는 작업이 반드시 필요하다. 우리는 이 작업이 바로 앞서 여러 차례 소개했던 물리적 데이터 모델을 ‘논리화’하여 논리적 모델로 작성해 가는 과정이라는 것을 잘 알고 있다.

 

논리적 모델에는 ‘가상’의 엔터티, 릴레이션쉽, 속성을 만들 수 있기 때문에 얼마든지 현재의 물리적 형태와 이를 보완시킨 논리적 모델을 같이 표현할 수 있다. 우리는 논리화를 통해 의미를 재해석한 두 시스템의 논리적 모델을 작성함으로써 두 시스템의 진정한 내용 상의 차이를 분명히 규명하였다. 각각의 데이터 모델이 구체화 되었기 때문에 이들을 머지한 제3의 집합을 결정할 만반의 준비가 이루어졌다. 가장 먼저 실시한 작업은 기본이 될 인수기업 시스템의 논리적 모델을 대상으로 지금까지 밝혀지지 않았던 여러 가지 특징과 심각한 문제점, 보다 바람직한 구조에 대한 개념 전달하기 위한 특별 워크이었다.

 

통합될 시스템에 대해서도 유사한 워크샾을 가졌는데 주로 인수기업 시스템의 구조와 차이점을 비교하고 여기에 있는 데이터가 어떤 형태로 머지되고 전환되어야 하는지에 대해 설명하는 방향으로 전개되었다. 마치 자식을 가진 중년남녀가 재혼을 할 때 여자쪽 가족들이 대가족을 거느린 시가로 들어가야 할 때 자식들이 해야 할 처신을 설명하는 것과 비슷한 상황이었다고 이해할 수도 있겠다. 

 

두 시스템의 현행 데이터 아키텍처를 수립하는 일이 완료되고, 이제 전체적인 통합 컨셉이 잡혔기 때문에 이제 본격적으로 목표 데이터 아키텍처를 수립하기 시작하였다. 두 시스템의 최소공배수 – 물론 인수기업을 보다 비중있게 처리한 형태이기는 하지만 – 를 만드는 작업은 단지 통합된 데이터 모델을 만든다는 것보다 보다 발전적인 형태의 데이터 모델을 만들어야 한다는 방향으로 진행되었다. 특히 이 회사는 현재의 시스템에 상당히 만족하고 있는 상태였기 때문에 앞으로 당분간은 새로운 차세대 시스템에 투자할 생각이 없었다. 이 말은 이번 기회에 최대한 숙원사업들을 해결해야 한다는 당위성을 의미하고 있기도 하다.

 

3의 목표 데이터 모델을 결정해 갈 때의 가장 큰 어려움은 거의 대부분의 데이터 모델에 영향을 미치는, 마치 등뼈와 같은 위치에 있던 핵심 엔터티를 근본적으로 개념부터 바꾸어야 한다는 것을 관철시키는 것이었다. 사람에게도 중심이 되는 등뼈를 바꾸는 수술은 엄청난 대수술이라고 겁을 먹듯이 데이터 모델의 등뼈에 해당하는 엔터티부터 근본적으로 바꾸어야 한다고 했을 때 많은 사람들이 두려워하는 것은 어쩌면 당연한 일이었다. 특히 이 시스템의 모체는 유명 패키지였기 때문에 그 두려움은 더욱 컸다. 그러나 상식적으로 보아도 그 모델이 가지고 있는 엄청난 문제는 반드시 해결되어야 했기 때문에 설득은 가능했고, 이제 와서 그 판단이 옳았음에 행복해 하고 있다.

 

필자가 이 사례를 자세하게 설명하는 것은 시스템 통합을 위한 목표 데이터 아키텍처의 수립에서도 정말 필요한 교정이라면 그게 아무리 힘이 들고 어렵다고 하더라도 반드시 결행해야만 한다는 것을 강조하고자 함이다. 비록 참으로 어려운 과정을 거쳤지만 시스템의 근본인 데이터를 이렇게 구체화 함으로써 거의 모든 데이터를 과거의 이력까지 통합할 수 있었고, 그 와중에서 엄청난 오류 데이터를 정제하는 작업도 같이 병행하여 진정한 데이터 기반을 수립할 수 있었던 것이다.

 

과거에 발생한 거의 모든 데이터를 소급해서 모두 이행하기로 했기 때문에 이루 말로 형언할 수 없을 만큼의 어려움도 있었다. 두 시스템에는 고객에게 청구를 하고 납입이 되면, 어떤 청구 건들이 어떤 납입 건에 의해 수납되었는지를 나타내는 ‘수납내역’이 있었는데 그 관리방법에서 큰 차이가 있었다. 더구나 그 데이터는 6개월 분이 약5억 건을 상회하는 대용량의 테이블이기도 했다. 청구에는 매월 청구한 합계가 있고, 수십 가지로 나누어져 관리되는 청구항목별 금액이 있다. 패키지로 되어 있는 인수기업의 시스템은 수납내역을 청구항목별로 관리하고 있지만 합병된 기업에서는 월합계 별로 내역을 관리하고 있었다.

 

여러분도 잘 알고 있겠지만 상세한 소스 데이터를 이용해 집계를 하는 것은 어려울 것이 없지만, 집계된 소스 데이터를 가지고 거꾸로 세부내역을 만든다는 것은 매우 어려운 일이다. 마치 회계에서 원가를 배부하듯이 세부내역을 강제로 배부해서 만들어야 하는데 어떤 기준으로 배부할 것인가도 문제이고, 소수점 처리 때문에 가로를 맞추면 세로가 틀리게 된다는 것도 보통 문제가 아니었다. 더구나 이미 회계에 모두 반영되어 함부로 수정할 수도 없는 과거 데이터를 있지도 않은 세부내역을 역으로 다시 만들어낸다는 것은 참으로 어려운 일이 아닐 수 없다. 그러나 이런 데이터에 대해서 단1원까지도 틀리지 않게 과거의 모든 데이터를 통합하였다는 것은 매우 의미있는 일을 하였다고 믿는다.

 

이런 일은 오로지 데이터를 진정으로 사랑하는 사람들만이 할 수 있는 것이다. 필자는 ‘대용량 데이터베이스 솔루션’에서 가곡을 하는 사람들이 술자석에서 노래를 시키면 대중가요를 부르는 이유를 아느냐고 질문한 적이 있다. 그것은 바로 자신이 모든 것을 바치고 있는 가곡을 진정으로 사랑하기 때문이라고 하였다. 여러분이 진정 정보시스템에 평생을 바치고자 하는 사람이라면 진심으로 데이터를 사랑해야 한다. 사랑이 없으면서 혼을 넣어 매진할 수 없다. 정말 진정으로 데이터를 사랑할 자신이 없는 사람이라면 이 책을 더 이상 읽을 필요도 없을 것이라 생각한다.

 

 

 

전사적 아키텍처는 일관성이 없는 시스템 설계를 방지하고, 개발에 대한 근시안적인 결정과 성능이 최적화가 되지 않은 결과와 관련 비용의 낭비를 막을 수 있는 체계적인 방법이 될 것이다. 전사적 아키텍처가 미치는 영향은 조직간에 완전하고 일관된 정보를 공유하고, 변화에 효과적으로 대응할 수 있게 하는 능력이다. 

 

특히 시스템의 근간이랄 수 있는 데이터를 제대로 설계하는 전사적 데이터 아키텍처가 없다면 시스템은 골격이 부실한 선천성 불구의 모습이 될 수 밖에 없을 것이다. 더구나 대부분의 경우 이런 문제의 해결을 위해서 자꾸만 복잡한 애플리케이션을 동원해서 막으려고 하기 때문에 갈수록 더욱 심각한 양상으로 나타나게 되리라는 것은 자명하다. 조직은 불완전한 정보로 인하여 본질적으로 잘못되고, 부적합하고, 값비싼 결정을 하게 되는 위험에 계속해서 직면하게 된다. 이로 인하여 조직은 언제나 완전한 만족을 얻지 못하게 되고, 부족한 품질과 불완전한 데이터에 익숙하게 길들여 진다. 결국 아키텍처가 없다면 조직은 변화에 대한 자극에 담당자가 국부적으로만 반응하는 형태로 나타나게 되고, 전체적으로는 계속해서 느리고 일관성이 없는 형태로 진행될 것이다.

 

혹 전사적 아키텍처는 허황된 생각이고, 시간과 노력을 낭비하는 것이라고 사람들이 생각할지도 모른다. 그러나 축적되고 자발적인 노력이 설명하듯이 조직의 정보화담당관(CIO)은 전사적 아키텍처를 생성하기 위해 사실적이고 재사용 가능한 접근 방법인 전사적 아키텍처 프레임워크를 정의해야 한다. 특히 기업의 정보시스템 구성에 직접적인 설계의 근간을 이룰 데이터 아키텍처를 전문적으로 수립, 관리할 조직부터 만들어 가는 것이 우선적으로 필요하다. 결국 이 모든 것들이 인간에 의해 좌우되고, 인간이 중심이 되어야만 가능한 일이기 때문이다. 만약 시기를 놓쳐 버린다면 그만큼 뒤로 미루어 지는 것이 아니라 만회하기 힘든 커다란 기회손실로 돌아 온다는 사실을 명심해야 할 것이다.

 

Tag :

Leave Comments

댓글 쓰기 권한이 없습니다. 회원 가입후에 사용 가능합니다