데이터 아키텍처/전사적 아키텍처와 데이터 아키텍처의 개념-2

제 2 장 데이터 아키텍처의 개념
데이터는 시스템의 본질이라고 했다. 본질이란 만물의 근원이므로 이를 통해 생겨나는 많은 파생적인 것들에게 원천적인 영향을 미친다.

즉, 본질이란 그만큼 중요한 것이므로 약간의 문제만 있더라도 그 파급효과는 실로 막대할 수 있다는 것이다. 본질이란 구성적으로 볼 때는 비록 가장 하위에 있는 미세한 것에 불과하지만 마치 수백만 권의 책이 단 수십 개의 철자로서 만들어지고, 세상의 모든 만물이 단지 수십 개의 원소들에 의해 만들어지듯이 본질은 엄청나게 많은 것에 매우 커다란 영향력을 미친다.

그럼에도 불구하고 이제껏 데이터는 단지 프로세스를 처리하다가 필요에 따라 잠시 저장해 두는 창고쯤으로 여긴 사람들이 너무나 많았다. 필자는 정보시스템은 반드시 데이터가 중심이 되어야 한다고 굳게 믿는 사람이다. 뿌리가 깊은 나무는 바람에 아니 흔들리듯이 시스템의 뿌리인 데이터가 든든하게 갖추어지게 되면 오랜 숙명처럼 여겨 오던 많은 문제들이 본질적으로 해결될 수 있는 길이 열리게 될 것이다.

무릇 모든 일이 그러하듯이 각각의 아무리 세밀한 부분들이 훌륭할지라도 그것이 일관되고 종합적인 전략도 없이 모래알처럼 개별적으로 존재한다면 그 가치는 격하될 수 밖에 없다. 항시 바로 눈앞에 있는 것만 바라보고 있으면 우리는 근시안이 될 수 밖에 없다. 아무리 혼신의 노력으로 내부 구성물을 만들었더라도 몸체가 필요없게 된다면 아깝지만 모두 버려질 수 밖에 없다. 이런 관점에서 본다면 기업의 업무를 데이터 입장에서 재조명해 볼 필요는 분명히 있다.

현재뿐만 아니라 먼 미래를 바라다 보는 시각을 가지고 업무의 근본인 데이터를 아키텍처적으로 접근해 가는 것은 정말 중요하다. 이 장에서는 전사적 아키텍처의 가장 중요한 부분으로써 데이터 아키텍처가 구성되고 추진되어 가는 절차, 활용 방향 및 효과를 알아보도록 하겠다.

2.1 데이터 아키텍처의 개념

앞서 전사적 아키텍처에서 대표적 아키텍처를 소개할 때 데이터 아키텍처에 대해 간략하게나마 소개를 했었기 때문에 어느 정도 개념적인 것은 이해를 했을 것으로 생각한다. 이 장에서는 데이터 아키텍처의 개념을 좀더 상세하게 알아보고, 각 구성 단계의 구체적인 개념 및 접근 방법에 대해서도 언급할 것이다.

데이터 아키텍처는 기업의 모든 비즈니스를 데이터 측면에서 처음부터 끝까지 조명해 보려는 것이다. 마치 어떤 건물을 다른 부수적인 것(가령, 인테리어)은 보지 않고 골조만 정밀하게 정의하려고 하는 것과 유사하다. 혹은, 사람의 몸을 뢴트겐(x-ray)이나 자기공명장치(MRI)로 찍어서 살은 보지 않고 뼈대나 뼈의 단층을 정밀하게 조사하자는 것과 유사하다고 하겠다.

데이터 아키텍처는 어쩌면 지금까지 없었던 완전히 새로운 개념이라고는 할 수 없다. 왜냐하면 정보시스템에서 '데이터'는 그 어떤 상황에서도 절대 없어질 수 없고, 앞으로도 영원히 없어질 수 없는 근본적인 것이며, 이를 제대로 설계하자는 것은 당연한 접근이라고 할 수 있기 때문에 마치 새삼스레 정립된 개념처럼 침소봉대할 필요는 없다.

하지만 지금까지는 너무나 당연히 그랬어야 했던 것을 제대로 지키지 못한 것은 엄연한 사실이다. 그간의 사정이야 어찌 되었던 간에 데이터를 과소평가하고 무시하여 이를 체계적이고 구체적으로 접근하지 않은 것은 엄연한 사실이기 때문에 지금이라도 이를 현실화시킬 수 있는 구체적인 접근방법이 필요한 것은 틀림없다.

2.1.1 데이터 아키텍처와 데이터 모델링의 비교
먼저 데이터 아키텍처가 데이터 모델링과 근본적으로 다른 몇 가지 사항들을 나열해 보자.
?데이터 아키텍처는 전사적으로, 데이터 모델링은 프로젝트 단위로 접근한다.
?데이터 아키텍처는 시행사와 시공사, 관리업체의 역할을 모두 정의하지만 모델링은 시공사에서 하는 설계만을 의미한다.
?데이터 아키텍처는 과정을 관리하고자 하나 데이터 모델링은 결과 중심이다.
?데이터 아키텍처는 데이터 모델링을 포함한 보다 큰 개념이다.
?데이터 아키텍처는 속성집합을 개체집합과 독립적으로 구성할 수 있다.

데이터 아키텍처는 최상의 개괄적인 단계에서부터 출발하여 상세 정의 단계, 데이터 운용 단계까지 모두를 말한다. 방법론이 전체 영역을 구비하고 있다는 뜻일 뿐이지 항상 전사적(모든) 업무에 대해 아키텍처를 동시에 수립해야만 한다는 것을 의미하지는 않는다는 것이다.

사실 진정한 데이터 모델링이란 반드시 과정을 지원하는 방법론이어야 하겠지만 지금까지의 데이터 모델링은 복잡한 과정은 사람들이 알아서 하고 그 결과만 표현해 두는 정도로만 사용하였다. 바로 이것이 잘못되었다는 것이다. 앞으로 데이터 아키텍처에 구성될 새로운 데이터 모델링은 구체적이고 체계적인 결정을 해가는 모든 과정을 지원하게 될 것이다.

이를 위해서는 누구나 인정할 수 있는 매우 상식적인 수준의 '판단의 기준'이 제시되어야 하며, 어쩌면 인간에게 맡겨 두어야 할지도 모르는 '사고의 절차'까지도 구체적으로 제시하게 될 것이다. 데이터 아키텍처가 기존의 데이터 모델링과 다른 또 하나의 커다란 특징은 속성이나 속성집단이 개체 집합과는 독립적으로 정의될 수 있다는 것이다.

기존의 데이터 모델링에서는 먼저 엔터티가 탄생된 연후에라야 그 속에 속성들이 자리를 잡을 수가 있었다. 즉, 엔터티가 정의되지 않는 상태에서는 결코 속성을 논할 수 조차도 없었다. 단지 최종 결과를 기록하는 것에 그치지 않고 단계적으로 접근해 가는 과정 자체를 지원할 수 있어야 한다면, 마치 여러 가지 부품들을 적절히 조합하여 제품을 만드는 것처럼 미리 만들어진 속성(부품)들을 적절히 조합하여 엔터티에 채울 수도 있어야 한다는 것이다.

여기서 주장하는 속성, 혹은 속성그룹을 공용부품화 시키자는 것은 지식관리시스템(KMS, Knowledge Management System)에서 사용하고 있는 온톨로지(ontology, 존재론)의 개념을 활용한 것이다.
이 개념을 데이터 아키텍처에 도입하려는 것은 이 방법론에서 사상 처음으로 시도하려는 것이다. 이 개념을 도입한 이유는 진정으로 데이터 아키텍처를 수립해 가는 과정을 지원할 수 있는 방법론이라면 이와 같은 현실적인 도움을 줄 수 있어야 한다고 믿기 때문이다.

2.1.2 데이터 아키텍처의 계층별 기본개념
데이터 아키텍처는 전체적인 구조를 정의한 개괄적 모델에서부터 형체(골격)가 확정된 개념적 모델, 논리적으로 있어야 할 의미있는 모든 존재가 정의된 논리적 모델, 실제 데이터가 저장될 수 있는 물리적 모델, 부가적인 상세한 내용을 구체적으로 정의하는 부가적 단계로 구성된다.
마치 우리가 지도를 볼 때 나라 전체를 볼 수 있는 축척에서부터 소로(小路)가 상세하게 나타나 있는 축척에 이르기까지 여러 단계의 축척이 모두 필요한 것처럼 데이터 아키텍처 또한 확실한 목적과 존재의 의미를 가지고 있는 이러한 각각의 단계가 반드시 필요하다.

<그림 1-2-1>을 한번 살펴보자. 그림의 좌측은 데이터 모델의 상세화 수준을 건물구축에 비유하여 표현한 것이며, 우측 그림은 데이터 집합들을 표현한 것이다. 개괄적 모델에는 마치 건물의 조감도에 중요한 건물들의 개략적인 형태가 나타나 있듯이 최상위의 집합이 도출되고 필요에 따라 보다 세부적인 부분집합이 표현되어 있다. 개념적 모델에 해당하는 건축물을 보면 각 단위 건물에 대한 골격이 세워져 있다. 이와 같이 개념적 데이터 모델에서는 주요 핵심 엔터티에 대해서 보다 구체적인 집합이 정의된다. 건축물의 논리적 모델에 건물의 내부가 입체적으로 나타나 있는 모습을 하고 있듯이 논리적 데이터 모델에서는 모든 엔터티에 구체적인 부분집합과 속성 및 릴레이션쉽이 모두 정의되어 있는 단계이다.

건축물의 물리적 단계는 실제로 물리적인 건물이 세워져 있는 단계이며, 데이터 모델에서 물리적 단계는 논리적 데이터 모델을 이용하여 물리적인 오브젝트(테이블, 뷰, 인덱스 등)를 설계하는 단계를 말한다. 앞의 그림에는 나타나 있지 않지만, 다섯 번째 단계인 부가적 모델에서는 보다 상세한 부가적인 사항들이 구체적으로 정의된다.

2.1.2.1 개괄적(contextual) 모델

개괄적 모델은 전사적 데이터 아키텍처의 최상위 모델이다. 이 단계에서 정의되는 집합의 형태는 독립적인 단위집합인 데이터 영역(data area)과 그 내부의 부분집합을 나타내는 데이터 클래스(data class)로 구성된다. 여기에 표현된 집합들을 합하면 데이터적으로 보았을 때 곧 '전사적을 의미하는 집합'이 되어야 한다. 이 말은 앞으로 생성되는 모든 엔터티들은 반드시 이들 집합에 소속될 수 있다는 것을 의미한다.

마치 건축물에서도 수많은 방이 있고, 복도, 엘리베이터 등이 있지만 이들은 결국 어떤 특정 건물에 반드시 소속되는 것과 같다. 만약, 주차장이나 도로처럼 어느 특정한 건물에 소속되지 않는다면, '부대시설'이라는 개념적인 집합에라도 소속되도록 해야 하듯이 '코드', 혹은 '기타'와 같은 포괄적인 개념의 데이터 영역을 지정해서라도 모든 엔터티를 포괄할 수 있도록 하는 것이 바람직하다.

<그림 1-2-2>는 여러분이 개괄적 모델이 무엇인지를 대략적으로 이해하는데 참고하는 정도로 보아주기 바란다. 무릇 집합 단위가 점차적으로 진화해 갈수 있다면 속성들도 거기에 보조를 맞추지 않을 수 없다. 앞서 잠시 소개했던 온톨로지의 개념을 활용하여 우리가 관리할 속성들을 처음에는 매우 추상적이고 집단적인 형태로 정의하였다가 점차 상세화할 수 있는 방법이 제시되어야 한다. 이해를 돕기 위해 간단한 예를 한 가지 들어보자. 가령, '고객'이라는 데이터 영역을 정의하는데 아직 관리할 항목을 속성단위까지는 결정할 수 없지만 '기본신상정보', '연락처정보', '주택정보', '차량정보' 등을 관리하겠다는 정도는 충분히 결정해 둘 수가 있을 것이다.

이처럼 비록 '시행사' 입장에서 작성하는 매우 전략적인 집합을 담고 있는 개괄적 데이터 모델에서도 최대한 집합을 상세화시켜야 하고, 속성 또한 최대로 세분화 시킬 수 있어야 한다. 또한 필요하다면 언제나 보다 하위의 단위로 상세화가 가능해야만 데이터 아키텍처라 할 수 있을 것이다. 이제 여러분들은 개괄적 모델이 단지 서술적인 문서 형태가 아니라 구체적인 설계도면 형태로 작성되어야 하는 것이 옳다는 것을 이해하였을 것이다.

2.1.2.2 개념적(conceptual) 모델

개념적 데이터 모델이란 건물로 말하면 철제빔으로 건물의 골격을 세워 놓은 형태와 유사하다고 했었다. 이 말은 아직은 비록 앙상한 골조만 나타나 있을 뿐이지만 앞으로 아무리 구체적으로 상세화된다고 하더라도 절대로 이 골격을 벗어나지는 못한다는 의미라고 하였다. 이와 같이 데이터 모델에서도 앞으로 아무리 상세한 모델링이 진행되더라도 전체적인 골격은 결코 개념적 모델을 벗어나지 못할 것이다. 건물의 골격이 주요 골조 자재로 구성되어 있듯이 개념적 데이터 모델도 주요 핵심 엔터티들로 구성되어진다.

개념적 모델은 단지 대상을 주요 핵심 엔터티로 한정한다는 것일 뿐이지 모델링 기법은 논리적 모델링과 특별히 다를 것이 없다. 만약 우리가 하향식으로 데이터 아키텍처를 수립해 간다면 개념적 모델은 개괄적 모델을 좀더 상세화된 형태로 진화시켜 가거나 중요 엔터티만 선정하여 모델링을 함으로써 탄생된다. 물론 이후에도 모델링의 상세화는 계속되어 갈 것이며, 필연적으로 개념적 모델도 따라서 약간씩의 변화가 일어날 수 밖에 없다.

2.1.2.3 논리적(logical) 모델

논리적 모델은 데이터 모델링이 최종적으로 완료된 상태를 말한다. 즉, 물리적인 스키마 설계를 하기 전 단계의 '데이터 모델' 상태를 일컫는 말이다.

혹시 '논리적'이란 말 때문에 현실적 요건들이 배제되어 있는 것처럼 생각할 수도 있으나 결코 그렇지는 않다. 엄격히 말하면 데이터 모델링 단계에도 논리적 데이터 모델링과 물리적 데이터 모델링이 있다. 여기서 말하는 '물리적 데이터 모델링'이란 데이터베이스 설계를 말하는 것이 아니다. 말 그대로 데이터 모델링인 것은 분명하지만 논리적 데이터 모델링 단계에서 논리적인 접근을 위해 잠시 배제해 두었던 물리적(현실적) 요건을 감안시키는 모델링 단계를 말하는 것이다.

데이터 모델링이란 모델링 과정이 아닌 별도의 과정을 통해서 조사하고 결정한 사실을 단지 ERD라는 그림으로 그려내는 과정을 말하는 것이 아니다.
시스템 구축을 위해서 가장 먼저 시작할 기초적인 업무조사를 하는 초기단계에서부터 인간이 결정해야 할 대부분의 사항을 모두 정의하는 시스템 설계의 전 과정을 지원하는 '과정의 도구'라고 해야 할 것이다. 그렇기 때문에 이 책에서는 단순히 결정된 데이터 모델을 어떻게 작도할 것인가를 설명하는데 그치지 않고, 수많은 결정사항들을 어떻게 하면 확신을 가지고 올바르게 정의해 갈 수 있느냐에 대한 구체적이고 실질적인 솔루션을 제시하게 될 것이다.

2.1.2.4 물리적(physical) 모델
물리적 모델이란 논리적 모델을 특정 데이터베이스로 설계함으로써 생성된, 데이터를 저장할 수 있는 물리적인 스키마를 말한다.

2.1.2.5 부가적(out-of-context) 단계
데이터 아키텍처에서 부가적 단계란 일명 상세기술(detailed representations) 단계라고도 할 수 있다. 쟈크만이 분류한 다섯 번째 단계인 'OUT-OF-CONTEXT'란 말을 음미해 보면, 이 말은 원래의 의미인 '문맥외'라는 뜻이 아니라 의역을 하여 '부연'적, 혹은 '부가'적인 상세기술을 의미하고 있다는 것을 알 수 있다. 부연적인 기술이란 원론적인 내용만으로는 내용이 충분하지 않을 때 이를 좀더 상세하게 보충하기 위해서 추가하는 설명이나 세부적인 정의를 말한다.

2.1.2.6 운용적(operational) 단계
운용적 단계란 원래 쟈크만이 주장한 단계는 아니다. 필자는 데이터 아키텍처의 마지막 단계로써 지금까지 정의된 집합에 실제 데이터들이 들어와서 운용되고 관리되는 것 또한 우리가 무시해서는 안 될 중요한 단계라고 생각하고 있다.

우리가 앞 단계까지 정의한 것은 어떤 모양과 특징을 가진 상자(스키마의 정의 사항)일 뿐이지 그 안에 들어 있는 내용물(데이터, 로우)을 말하는 것은 아니었다.

데이터의 다양한 관련 정보가 리파지토리에 저장되어 있고, 또한 애플리케이션 아키텍처가 체계적으로 리파지토리에 저장되어 있다는 것은 시스템의 설계 정보가 고스란히 데이터화되어 있다는 것을 의미한다.
시스템은 결국 데이터와 애플리케이션으로 구성된 것일진대 이들 정보가 모두 리파지토리에 구체적인 데이터로 관리되어 있다면 이를 이용해서 우리가 얻을 수 있는 혜택은 참으로 다양하다. 가령, 어떤 데이터의 구조가 변경되었을 때 얼마나 많은 애플리케이션이 영향을 받는지를 정확히 분석할 수 있다면 이것은 참으로 매력적인 일이 아닐 수 없다.

만약 튜닝을 위해 설계 변경을 하고 싶은데 얼마만큼의 투자에 어느 정도의 효율을 얻을 수 있을 것인지를 미리 예상하는데도 활용할 수 있을 것이다. 뿐만 아니라 애플리케이션에 적용된 처리방식이 개발자의 능력에 따라 어떻게 차등적으로 적용되었는지도 분석할 수 있어 품질이 낮은 애플리케이션을 집중적으로 보강하는 것도 가능해진다.

어쩌면 이것이 참으로 꿈 같은 일로 생각될지도 모르겠지만 이미 데이터 아키텍처와 애플리케이션 아키텍처를 연결하여 이러한 정보를 활용하는 업체가 이미 상당 수 존재하고 있다. 그러나 혹시나 여러분들 중에서 시중에 나와 있는 메타데이터 관리(일명 MDR) 툴이 모든 것을 저절로 해 줄 것이라고 믿고 있다면 그런 망상에서 하루 빨리 빠져나와야 한다.

만약 분석의 기준이 되는 데이터에 대해 데이터 아키텍처를 수립하지 않고 적용했다면 그것은 단지 물리적 모델, 즉 테이블과 컬럼이 어떤 프로그램에서 적용되었는지를 자동화해 둔 것 그 이상은 아무것도 아니라는 것이다. 물리적 모델은 순수한 업무적 집합인 논리적 모델에 현실의 요건을 반영한 모습일 뿐이므로 물리적 모델이 데이터의 진정한 대표 집합이 아니라 논리적 모델이 진정한 데이터의 대표 집합이기 때문이다.

2.1.3 계층간 얼라인먼트(alignment) 정립

데이터 아키텍처에서 가장 중요한 요소 중에 한 가지는 각 계층간을 구체적인 고리로 연결하여야 한다는, 즉 얼라인먼트 가 명확해야 한다는 것이다.

이 말은 곧 하위 계층은 상위 계층에 대한 상세화이므로 결국 상세화된 하위 계층이 상세화시킨 상위 계층의 대상과 분명한 연결고리를 가지고 있어야 한다는 것을 의미한다. 이것은 하향식으로 접근해 갈 때나 상향식으로 접근해 갈 때 모두에게 동일하게 적용되는 개념이다. <그림 1-2-3>은 데이터 아키텍처 계층간의 명확한 얼라인먼트를 보여주고 있다.

2.2 데이터 아키텍처의 접근 방법

데이터 아키텍처를 수립해 가는 접근방법은 여러 가지를 생각해 볼 수가 있겠으나 여기서는 크게 두 가지로 나누도록 하겠다. 한 가지는 이미 기존의 시스템이 존재하는 상태에서 데이터 아키텍처를 수립하는 것이고, 또 다른 한 가지는 아무 것도 없는 상태에서, 혹은 기존의 시스템을 전혀 감안할 필요가 없는 상태에서 적용하는 경우일 것이다. 물론 첫 번째 경우라 하더라도 단지 기존의 아키텍처를 수립해 둔다는 단순한 목적일 수도 있겠지만 새로운 시스템의 구축을 위해 차세대 목표 시스템의 데이터 아키텍처를 수립하고자 하는 경우도 있을 것이다. 사실 지금까지의 데이터 구조 설계는 새로운 시스템을 구축할 때나 하는 것이지 운용 중인 시스템의 데이터 구조를 재조명해 보려는 시도는 거의 하지 않았다고 해도 과언이 아니다.

만약 새로운 차세대 시스템으로 시스템 전체를 개편하려는 프로젝트를 하고자 한다면 반드시 전사적 아키텍처를 수립할 필요가 있다. 물론 전사적으로 모든 부문의 아키텍처를 수립한다는 것은 그리 쉬운 일이 아니다. 만약 여러분이 본격적으로 차세대 시스템을 구축할 계획을 하고 있다면 미리 현행 시스템에 대해 전사적 아키텍처, 최소한 전사적 데이터 아키텍처라도 수립해 두는 것은 정말 중요한 일이라고 하겠다.

데이터 아키텍처를 수립하려는 대부분의 경우에는 이미 현행 시스템이 존재하고 있다. 손자병법에 '지피지기면 백전불태'라고 하였듯이 현행 시스템을 정확히 알아야 목표 시스템을 제대로 구축할 수가 있다. <그림 1-2-4>는 현행 시스템을 리버스하여 현행 데이터 아키텍처를 수립하고, 여기에 새로운 요구사항을 감안하여 목표 데이터 아키텍처를 수립해 가는 절차를 보여 주고 있다.

2.2.1 현행 데이터 아키텍처 수립 절차

정보시스템을 구축할 때 가장 먼저 우리가 해야 할 일은 바로 현행 시스템을 정확히 아는 것이라 할 수 있겠다. 설혹 현행 시스템이 누더기처럼 되어 있어 거의 빈사지경에 이르렀다고 하더라도 단지 그 모습이 체계적이지 못하다는 것일 뿐 원래 하고자 하는 업무내용은 어디엔가는 반드시 구현되어 있다는 점을 무시할 수는 없다. 만약 우리가 여러 가지 기법과 도구, 분석력을 이용하여 보다 쉽게 다량의 현행 정보를 정확하게 도출할 수만 있다면, 목표 시스템 구축의 일정과 품질에 매우 많은 도움이 될 수 있으리라는 것은 틀림없다.
이런 의미에서 데이터를 기반으로 한 리버스를 시도하는 것이 매우 바람직한 방법이라 하겠다. 다만 업무의 내용을 완벽히 알지 못하는 상태에서 구체적인 데이터 모델을 리버스하기 위해서는 어느 정도 전문가의 도움이 필요하다는 단점이 있지만 조직마다 이러한 능력을 가진 사람들이 지속적으로 배양된다면 그리 어려운 접근방법은 아닐 것이라 믿는다.

2.2.1.1 현행 개괄적 모델의 생성

앞에서 제시한 <그림 1-2-4>에서 볼 수 있듯이 비록 거꾸로 올라가야 하는 리버스 모델링이지만 그렇다고 해서 가장 먼저 '현행 물리적 모델'부터 바로 작성하는 것은 아니다. 물론 현행 물리적 모델이란 현재 존재하고 있는 데이터 모델을 있는 그대로 그려두는 것을 말한다. 그러나 단지 그냥 있는 그대로를 그려만 두는 것은 아무런 의미가 없으며, 또한 본래의 의미를 정확하게 찾아낼 수도, 표현할 수도 없다. 아무런 사전 단계도 없이 바로 현행 물리적 모델을 그려서는 안 되는 이유가 여기에 있다.

일반적으로 현행 물리적 모델은 대상 오브젝트 수가 매우 많이 존재하기 때문에 체계적으로 접근하지 않으면 엄청난 일량과 혼란에 빠질 수가 있다. 개수가 적다면 눈에 보이는 대로 접근하더라도 어떻게든 제자리를 찾아 갈 수가 있겠지만, 개수가 많은 경우에는 본질적으로 달라진다.

마치 그림 맞추기 퍼즐을 풀 때 조각 수가 몇 개 되지 않을 때는 어떤 것을 먼저 시도해도 큰 문제가 생기지 않지만 조각 수가 수백 개가 된다면 이미 그렇게 접근해서는 필시 엄청난 시행착오를 겪게 되는 것과 유사하다.

이런 문제에 빠지지 않기 위해서 우리가 선택할 수 있는 유일한 접근방법은 먼저 골격이 되는 엔터티들을 확정해 둔 다음 나머지를 차례차례 단계별로 정의해 가는 것이다. 예를 들어 현행 테이블이 3,000개가 있다고 하더라도 이 중에서 개체들의 집합은 그리 많지 않을 것(많아야 100개 이내)이므로 현행 물리적 모델을 이용해 데이터 영역을 찾아내는 것은 그리 어려울 것이 없다.

개체형 데이터 영역을 찾았으면 이들을 좀더 상세한 집합인 데이터 클래스로 세분화 시켜야 한다. 예를 들어 '사람' 데이터 영역을 '사원', '고객' 등으로 세분화할 수 있으며, 사원은 다시 '정규직, 임시직, 협력사직원' 등으로 분리해 둘 수가 있다. 개체형 데이터 영역을 모두 정의했다면 이제 행위형 엔터티를 찾아야 한다. 개체집합들이 존재하면 반드시 그들 간에는 모종의 행위가 발생하게 된다. 가령, '사람'과 '상품' 사이에는 '계약'이라는 행위가 존재할 수 있다. 물론 이 '계약'을 좀더 상세화 시키면, '가입계약, 청구계약, 임대계약' 등으로 분류될 수 있으며, 가입계약은 다시 '유선, 무선' 등으로 나눌 수 있다고 했다.

나뭇가지를 가지고 생각해 보자. 내용물의 대부분을 차지하는 잔가지와 잎사귀는 결국 줄기와 굵은 가지 중의 어느 하나에 매달려 있게 되는 것처럼 수많은 엔터티는 결국 특정 데이터 영역이나 데이터 클래스에 달려 있게 된다. 이처럼 수천 개에 달하는 테이블을 당장 리버스하는 것보다 먼저 수십 개의 데이터 영역을 찾아내는 것이 훨씬 쉬울 것이다. 뿐만 아니라 아직 현행 시스템의 내용이 모두 밝혀지지 않은 상태에서도 충분히 명확한 정의를 할 수 있다는 것 또한 매력적이라 하지 않을 수 없다.

2.2.1.2 현행 개념적 모델의 생성
우리는 이미 앞서 모든 테이블들을 개괄적 모델에 연결해 두었기 때문에 개념적 모델링의 대상을 추출하는 것은 매우 쉬워졌다. 가령, 물리적 모델에 3,000개의 테이블이 있다고 가정해 보자. 이것을 이용하여 개괄적 모델링에서 100개의 데이터 영역을 도출하였다고 하자. 가령, 각각의 데이터 영역마다 중요하다고 생각되는 테이블을 평균 3개씩 선정했다면, 300개의 테이블이 대상으로 도출될 것이다. 물론 무조건 3개씩으로 하라는 뜻은 결코 아니다. 시스템의 크기나 유형에 따라 다르겠으나 대략 3~5개 정도가 적당하리라 생각되지만 경우에 따라서는 없을 수도, 그 이상일 수도 있으므로 여러분의 적절한 판단이 필요하다.

현행 개념적 모델을 먼저 생성하자는 것은 우리가 매우 다양한 미지수를 가지는 작업에서 결론을 도출해 낼 때 '봐야 할 것과 보지 말아야 할 것을 가려낼 수 있어야 하고, 먼저 봐야 할 것과 나중에 봐야 할 것을 구별할 수 있는 지혜'를 이용하는 방법이다. 먼저 골격부터 세워야 한다는 것에 더 이상의 이의를 제기할 사람은 아마 없을 것이다. 그러나 이 골격에는 단지 먼저 해야 한다는 것 이상으로 중요한 것이 한 가지 있다. 그것은 바로 골격은 분명하고 단단해야 한다는 것이다. 나중에 다양한 잔가지들이 결국 이 골격에 붙게 될 것인데 만약 이것이 부실하다면 그 결과는 사상누각일 수 밖에 없기 때문이다.

2.2.1.3 현행 물리적 모델의 생성

현행 물리적 모델은 비록 있는 그대로를 표현하는 것이기는 하지만 결코 생각처럼 쉽다고는 할 수 없다. 물론 겉으로 보이는 것을 리버스하는 것은 매우 쉬운 일이다. 그렇지만 내부에 숨어 있는 것들을 찾아서 정확하게 표현한다는 것은 말처럼 결코 쉬운 일이 아니다. 마치 건물을 리버스할 때 겉에 보이는 기둥이나, 외벽, 창문 등은 자로 재고, 재질을 조사해 적어 넣음으로써 얼마든지 리버스가 가능하지만 벽 속에 숨어 있는 철골, 배관, 공조시설 등은 전문가와 전문장비가 없이는 찾아내기가 쉽지 않는 것과 같다.

현행 물리적 모델을 일차로 조사하는 작업은 어떤 수준으로 실시되느냐에 따라 다음에 연결될 작업에 많은 영향을 미친다. 만약 1차 조사자들이 단순히 컬럼의 명칭이나 설명만 기입하는 정도에 그친다면 나머지 모든 일들은 모델러의 몫이 될 수 밖에 없다.

엔터티의 집합에 대한 정의가 매우 구체적이어야 한다. 집합에 대한 정의라 함은 그 속에 들어 있는 개체들의 형태(유형)가 분명하게 나타나 있어야 한다는 것을 말한다. 개체의 유형을 분명하게 하는 방법은 크게 두 가지가 있다. 첫번째는 의미상의 주어(본질적인 식별자)를 분명히 하는 것이다. 의미상의 주어란 자신을 태어나게 한 부모에 해당하는 속성이나 릴레이션쉽들을 말한다.

현행 물리적 모델에 있는 기본키(primary key)가 인조 식별자(artificial unique identifier)로 되어 있다면, 이것은 원래의 식별자가 아니라 단지 개체가 탄생한 다음에 임의로 붙여진 얼굴마담에 해당할 뿐이다. 사람도 자신의 출생의 비밀이 밝혀져야 자기가 누구인지를 정확히 알 수 있는 것처럼 엔터티 또한 자신이 어떻게 해서 태어나게 되었는지를 밝히는 것이 매우 중요하다.

2.2.1.4 현행 논리적 모델의 생성

우리는 앞서 논리적 모델을 '현실적인 제한이나 고려할 사항들을 무시하고 오로지 본질적인 내용 중심으로만 접근하는 단계'라고 정의하였다.

논리적이거나 이론적인 것은 다양한 현실요소를 반영해 놓은 물리적인 것에 비해 의미가 매우 분명하고, 모습이 단순·명확하다. 리버스 모델링에서 현행 논리적 모델을 생성한다는 것은 이미 현실 상황이 다양하게 가미되어 만들어져 있는 현행 물리적 모델에서 거꾸로 본질적인 것들만 도출하여 원래부터 그랬어야 할 본래의 모습을 찾아나가는 과정을 의미한다.

생각해 보라. 원래 내용의 10배에 달하는 물리적 모델을 아무런 의미의 분석도 없이 그냥 나열해 둔 것은 '수집' 그 자체에 지나지 않는다. 마치 병원에서 종합검진을 할 때 간호사가 수집한 검진정보를 그냥 기록만 해두고 의사가 전혀 참조하지 않는다면 그 수집내용들은 아무런 가치도 갖지 못한다.

리버스 모델링에서도 이와 별반 다를 것이 없다. 조사자에 불과한 사람들이 일차적으로 수집만 해 둔 물리적 모델 정보는 마치 전문의가 의학적 분석과 평가, 조치를 취하는 것처럼 전문 모델러가 물리적 요소를 걷어내고 원래의 본질적인 의미를 해석해 내는 단계를 거쳐야 한다. 이렇게 의사의 판단을 거치는 작업을 바로 논리화 단계라고 한다.

특히, 논리화된 모델은 아직 새로운 요건(Requirement)이 반영되지 않았을 뿐이지 현재의 요구사항에 대해서만큼은 이미 차세대 시스템이나 전사적 데이터웨어하우스 모델의 이상적인 구조에 상당부분 반영되어 있는 형태라 할 수 있다.

다시 말해서 완벽한 현행 논리적 모델은 목표 데이터 모델의 60~70% 이상이 이미 완성되어 있는 형태라는 것이며, 이것은 참으로 큰 의미가 있다고 하겠다.

저작권자 © 아이티데일리 무단전재 및 재배포 금지