전사적 ITA 구축과 DA의 10가지 활용법

기업 혁신의 새 이름 ‘데이터 아키텍처’

전사적 ITA 구축과 DA의 10가지 활용법

데이터는 모든 정보의 본질이자 시스템의 골격이다. 그런데 데이터를 다룰 줄 아는 사람은 많아도 데이터 구조를 이해하거나 설계할 수 있는 전문가는 찾아보기 어렵다. 데이터의 세계는 애플리케이션의 세계보다 훨씬 차원이 높고, 어렵기 때문이다. 여기에 DBA들의 바이블이라고 할 수 있는 ‘대용량 데이터베이스 Ⅰ, Ⅱ’의 저자이자 명 DB 컨설턴트인 이화식 엔코아정보컨설팅 사장이 새로운 정보기술 아키텍처(ITA)와 차세대 데이터 관리의 핵심이라고 할 수 있는 데이터 아키텍처(DA)의 세계를 3회에 걸쳐 소개한다. <편집자주>

 

아키텍처를 해야 하는 가장 큰 이유는 구체적이고 합리적인 설계 과정을 더욱 체계적이고, 구조적으로 접근하자는 것이다. 물론 이러한 접근은 비록 처음에는 그 과정이 다소 어렵게 느껴지더라도 당연히 우리에게 많은 장점을 제공해 줄 것이다.

전사적 아키텍처 수립 기반
전사적 아키텍처의 수립에서 데이터 아키텍처는 무엇(What)을 할 것인가를 정의하는 가장 근본적인 구성 요소이므로 다른 어떤 아키텍처보다 논리적이고 구체적이어야 하며, 전문가의 도움을 받으면서 체계적인 아키텍처를 수립해 가는 것이 바람직하다.
전사적 아키텍처의 수립을 위해 데이터 아키텍처는 조직에 있는 수많은 정보들 중에서 데이터가 될 수 있는 집합들을 정의하고 그들 간에 맺고 있는 다양한 관계 및 애플리케이션과의 적용 관계, 그리고 데이터의 유지보수, 접근, 사용 방법을 구분하여 모든 것을 객체화된 단위 집합으로 정의하게 된다. 머지 않아 아키텍처를 기반으로 시스템이 구축되고 운영되는 세상은 분명히 올 것이다. 비록 어려운 작업이기는 하지만 그 근간이 되는 데이터 아키텍처를 단단히 수립해 두면 굳건한 반석이 될 것이다.

 

데이터 아키텍처를 이용한 정보전략계획
전사적인 관점에서 경영 환경을 분석하고 도출하는 과정이 정보전략 계획이며, 여기서 전사적으로 모델링 해야 할 객체는 ‘비즈니스, 조직, 데이터, 프로세스’라 할 수 있다.
‘예비정보구조 정의’ 단계에서는 전사적 프로세스 모델링과 전사적 데이터 모델링을 정의하게 되며, 데이터 아키텍처의 전 단계가 아니라 개괄적 모델과 개념적 모델까지만 실시해야 한다. 그러나 현행 시스템을 정확히 분석하려면 데이터 모델을 최대한으로 리버스 하는 것이 가장 좋기 때문에 만약 현행 시스템의 데이터 아키텍처를 수립하여 운용해 오고 있었다면 매우 유리할 것이다.
‘정보구조 정의’ 단계에서 작성하는 ‘데이터 정의’는 목표 데이터 아키텍처를 수립하는 것을 의미한다. 정보전략 계획에서는 목표 데이터 아키텍처의 작성 수준을 개괄적 모델과 개념적 모델 정도로만 작성하는 것이 일반적이지만 필요에 따라 개념적 모델의 수준을 조정할 수는 있다.

 

암초에 부딪친 개발 프로젝트
만약 시스템 설계 과정에서 불협화음이 계속되고 있거나, 개발 단계에서 애플리케이션의 지나친 수정이 반복되고 있다면 그것은 분명히 데이터 모델이 원인이었을 가능성이 크다. 이는 시스템의 본질인 데이터를 대충 설계해 두고 애플리케이션만 가지고 해결하려고 하기 때문에 발생하는 응분의 대가라고 보아야 할 것이다.
이런 상황에서는 이제라도 근본적인 원인인 데이터를 제대로 해결해야 함에도 불구하고 계속해서 애플리케이션만을 수정하는 빈곤의 악순환이 계속되어 프로젝트는 끝없는 혼란에 빠져들고, 개발은 끝없이 지연되는 일이 자주 발생하게 된다.
이러한 프로젝트를 해결하기 위해서는 반드시 데이터 모델을 우선적으로 검증해야 하지만 피상적으로 검증해서는 아무 것도 얻어 낼 수가 없기 때문에 체계적인 데이터 아키텍처를 단계적으로 수립해 간다면 저절로 문제점과 해결책을 모두 도출할 수 있을 것이다.

 

ERP 도입 시 데이터 아키텍처의 활용
ERP를 도입하는 기업은 그것이 가진 기능의 존재 유무만 확인하여 일정 부분을 수정하면 프로젝트를 성공할 수 있다고 생각하는 경향이 있다. 다행스럽게도 일부 애플리케이션의 수정으로 해결된다면 문제가 없겠지만, 만약 데이터 모델의 구조가 변경되어야 한다면 매우 심각한 상황이 올 수도 있다.
따라서 양쪽의 데이터 구조를 검토해 위험 요소를 최소화하고, 데이터 기준으로 커스터마이징 범위와 고려사항을 확인해야만 실패하지 않을 것이다. 이미 현행 시스템의 데이터 아키텍처가 수립되어 있다면 ERP 패키지의 핵심 데이터 모델을 리버스한 것과 비교하여 더욱 객관적이고 구체적인 검토를 할 수 있다. 일반적으로 패키지는 여러 업무에 적용할 수 있도록 매우 포괄적으로 정의되어 있으므로 여러 가지 형태로 매핑이 가능하다.
이 말은 곧 매핑의 적절성에 따라 매우 큰 차이가 있다는 것을 의미한다. 패키지 도입은 얼마나 많은 사람이, 얼마나 많은 애플리케이션을 수정하느냐에 있는 것이 아니라 무엇을, 어디에, 어떻게 대응시킬지를 찾아내는 것이 바로 성공의 지름길이라 할 수 있다. 이를 위해 우리가 선택해야 할 올바른 길은 패키지 데이터 모델의 데이터 아키텍처를 수립하여 구체적 의미를 명확히 알고, 우리 업무의 데이터 아키텍처를 명확히 하여 ‘지피지기(知彼知己)’를 하는 것이다.

데이터 아키텍처를 이용한 EDW 구축
EDW는 장기적인 비전과 전략을 반영한 IT의 궁극적인 가치를 높이는 시스템이지만 구축실태를 살펴보면 다른 서버로 데이터를 옮겨 두는 정도에 불과한 경우가 많아서 무용지물이 되거나 착시현상만 유발하고 있는 실정이다.
EDW에서 반드시 준수해야 할 기본 원칙은 바로 ‘통합, 단순, 장기(long term)’의 3가지라 할 수 있다. 정보의 원천인 OLTP는 자신들만이 가져야 하는 복잡한 사연이 있기 때문에 다른 목적들까지 모두 감안해 줄 여력이 없으므로 이들이 자신을 위해 변해 주기를 기다릴 수는 없다. 정보의 분석을 위한 원천 데이터는 너무나 다양하고, 대용량이며, 넓게 흩어져 있고, 그들간의 관련정보는 깊숙이 숨어 있기 때문에 이를 명확하게 재조명한다는 것은 결코 쉬운 일이 아닐 것이다.
그럼에도 불구하고 ‘장기간’의 대용량 데이터를 처리해야 하고, 툴이나 DBMS에게 많은 것을 맡겨야 하는 특수성 때문에 최대한 ‘단순 명료’해야 하며, 정보의 일관성과 투명성 확보를 위해 최대한 ‘통합’을 하기 위해서는 데이터 원천을 명확히 알아야만 한다.
만약 원천 데이터에 대한 현행(AS-IS) 데이터 아키텍처가 수립되어 있다면 이를 이용해 EDW를 위한 목표(TO-BE) 데이터 아키텍처를 수립함으로써 매우 쉽고, 빠르게 완벽한 EDW 데이터 모델을 얻을 수 있을 것이다.

이종의 시스템 통합
기업이 통합된다는 것은 여러 가지의 많은 변화를 의미하지만 그 중에서 빼 놓을 수 없는 것은 기업의 핏줄이라고 할 수 있는 정보시스템의 통합이다. 만약 모든 면에서 기업이 통합되었더라도 정보시스템이 통합되어 있지 않았다면 그것은 진정한 하나의 기업이라고 할 수 없고, 통합의 목적인 시너지 효과를 얻는 것도 불가능할 것이다.
마치 이종의 생명체를 정밀하게 연결해야 하는 접합 수술처럼 전혀 다른 구조의 시스템을 마치 처음부터 원래 하나였던 것처럼 과거의 모든 데이터까지 완벽하게 통합해야 한다면 정말 어려운 일이 아닐 수 없을 것이다.
이를 위해서 우리가 할 수 있는 가장 바람직한 일은 바로 두 시스템의 현행 데이터 모델을 정확히 분석하기 위해 매우 정밀한 현행 데이터 아키텍처를 수립해야 한다는 것이다. 이러한 방법의 이종 시스템의 통합은 이전 데이터를 최대한 보전하고, 기존문제를 해결할 수 있으며, 통합된 구조의 완성도를 높여서 통합된 차원의 시스템으로 거듭나게 할 것이다.

 

시스템 유지보수 생산성 향상
소프트웨어의 생명주기는 유한하지만 데이터의 생명주기는 무한하며, 데이터는 영원히 관리해야 하는 기업 자산이기도 하다. 비즈니스 변화는 단지 How-To의 변화일 뿐이므로 데이터 아키텍처를 이용해 What-To를 정확히 인지함으로써 How-To 변화에 효과적으로 대응할 수 있을 것이다.
이는 곧 데이터 구조가 투명하고 구체적으로 관리되고 있어야 한다는 것과 프로그래머가 함부로 애플리케이션만 수정하려는 미봉책을 쓰지 않도록 적극적인 통제 조직의 역할이 필요하다는 것을 분명히 하고 있다.
그러나 아무리 완벽한 데이터 아키텍처가 수립되어 있더라도 제대로 통제할 조직이 없다면 유명무실해질 것이며, 아무리 우수한 조직이 있더라도 정확한 정보를 제공할 데이터 아키텍처가 없다면 결코 그 소임을 다할 수는 없을 것이다.
아직은 완벽한 데이터 아키텍처가 수립되어 있지도, 이를 적극 활용할 조직이 제대로 준비되어 있지도 않지만 세상은 ‘발전하는 방향으로 진화’해 갈 것이 분명하므로 머지 않아 반드시 이러한 세상이 올 것이라 확신한다.

 

차세대 시스템 구축 교두보
공자가 말한 ‘온고지신(溫故知新)’이란 ‘과거를 바로 알지 못하고서는 결코 올바른 미래를 만들 수 없다’는 것을 경계하는 말이다. 비록 현행 시스템은 문제가 많아 더 이상의 존재가치가 없어졌지만 그 속에는 온갖 업무 규칙이 녹아 있다. 만약 이것을 무시하고 현업 사용자에게서 직접 도출하려고 한다면 훨씬 많은 시간이 필요할 것이며, 아무리 우수한 분석가에 의해 수행되었더라도 필시 많은 정보가 누락되고 결과에 오류가 나타날 수밖에 없을 것이다.
여러분들이 전문가의 능력을 가져서 ‘봐야 할 것과 보지 말아야 할 것’을 확실히 구분할 수 있고, ‘먼저 보아야 할 것과 나중에 볼 것을’ 정확히 가려 낼 수만 있다면, 현행 시스템을 구체적으로 분석하고 이를 바탕으로 차세대 시스템을 구축해 가는 방법은 가장 많은 시간과 비용을 절약할 수 있는 유일무이한 방법이라는 것을 이해하게 될 것이다.
그러나 현행 시스템을 분석한 자료가 단순히 ‘수집된 정보’ 수준이어서는 아무런 의미가 없으므로 전문가의 눈으로 분명한 의미와 본질을 찾아내어 독립적인 객체로 정의하고, 더욱 합리적인 잣대로 문제를 평가할 수 있어야 한다. 그렇지 않은 상태에서 분석하는 것은 마치 글자의 뜻도 모르면서 아무리 책을 읽더라도 결코 그 의미를 알 수 없는 것과 같다.

 

데이터 아키텍처를 이용한 데이터 이행
데이터 이행(Migration) 규칙이란 결국 데이터 집합간의 변환, 이동을 의미하는 것이므로 소스 집합을 알고, 결과 집합을 안다면 그리 어렵지 않게 데이터를 이행을 할 수 있다. 데이터 이행은 수많은 예외 경우를 처리하는 것이 아니라 데이터와 데이터간의 집합적인 매핑에 불과한 것이다.
이를 위해서는 현행 시스템과 목표 시스템의 데이터 아키텍처를 명확하게 수립하는 것 말고는 절대 더 좋은 대안이 없을 것이다. 그러나 실전에서 수행되는 대부분의 데이터 이행은 유형별 사례를 무수히 도출한 후에 애플리케이션에서 ‘CASE-BY-CASE’로 알고리즘을 작성하여 해결하고 있다.
이처럼 애플리케이션에서 수많은 예외처리를 일일이 지정하려 애쓰지 말고, 규칙을 벗어나는 데이터를 정제하여 규칙을 준수하도록 교정하고, 애플리케이션에서는 단지 규칙을 준수한 집합만을 처리하도록 하는 것이 가장 바람직한 처리 방법일 것이다.

 

리모델링을 위한 데이터 아키텍처
건축물의 리모델링이 거의 재건축을 하는 것과 다름없는 효과를 보이는 것처럼 시스템 리모델링이란 시스템을 단지 수리하는 정도가 아니라 개선요구 사항들을 더욱 확실하게 반영하고, 앞으로 나타날 다양한 요구사항에 좀더 쉽게 대응할 수 있도록 현재의 시스템을 ‘근본적으로 개조’하는 작업이다.
여기에서 ‘개조’란 단지 일부 애플리케이션을 통합하거나 기능을 개선하는 정도가 아니라 데이터 모델부터 근본적인 수술을 단행하는 것을 말한다. 현행 데이터 아키텍처 수립을 통해 수집된 분석정보는 전문가의 차원 높은 정밀 진단을 통해 획기적인 개선 대책과 개선의 부위, 개선 후의 효과, 투입할 일량 등이 구체적으로 제시될 수 있다.
즉, 현행 시스템에 있는 불필요한 내용들을 제거해 버리거나, 더 좋은 것으로 대체, 혹은 과감한 통합을 통해 단순화를 시키며, 필요하다면 일정 부분을 아예 다시 작성하는 방법을 통해 훨씬 저렴한 비용으로 획기적인 개선을 할 수 있다는 것이다.

[출처] 전사적 ITA 구축과 DA의 10가지 활용법|작성자 정신차렷