그럼에도 불구하고 실제 프로젝트에서 설계되어 있는 데이터 모델을 보면 그 수준과 문제점으로 인해 많은 실망을 하게 된다. 이름이 설계도일 뿐이지 대부분 주먹구구식이다. 필자가 그 동안 컨설팅을 하기 위해서 접해 본 프로젝트가 100개가 넘는다. 불행히도 거의 한 곳에서도 제대로 된 데이터 모델을 찾아볼 수가 없었다. 심한 말이라고 할지 모르겠지만 다른 어느 곳을 가더라도 유사한 상황이 발생되어 있을 것이라고 감히 확신한다.
데이터 모델링은 정밀하게 작성되어야 한다. 설계단계에서 인간이 조사하고, 판단하고, 결정해야 할 모든 것들이 구체적으로 명시되어 있어야 한다. 대부분의 시스템에서 나타나는 현상은 - 그것이 비록 유명 ERP 패키지라고 하더라도 - 개념적인 설계, 그 이상은 아니었다. 커다란 엔터티 박스에 다량의 속성들만 표시되어 있다. 이러한 데이터 모델은 단지 엔터티 종류와 속성들이 나열된 것, 그 이상도 이하도 아니다. 앞으로 우리는 데이터 모델링에서 얼마나 많은 내용들이 구체화 되고 체계적으로도 정리되어야 하는 지를 보여 주게 될 것이다.
이런 의미에서 데이터 모델링을 상세하게 설명하기 이전에 현실에서 자행(?)되고 있는 데이터 모델링의 문제들을 짚어보고, 우리가 추구하고자 하는 모델링을 하기 위해서 유의해야 할 일들부터 먼저 살펴보기로 하겠다.
데이터 모델링 실태
실전에서 일어나는 데이터 모델링의 잘못된 유형과 잘못된 접근 행태를 먼저 살펴보기로 하자. 여러분들이 지금까지 해 온 모델링의 접근 방법들이 대부분 이러한 형태에 속할지도 모른다. 필자가 지금까지 수 많은 데이터 모델들을 보아 왔는데 거의 대부분은 다음의 몇가지 형태로 구분되어 지고 있었다.
모델링에 대한 구체적인 접근 방법을 설명하기 전에 지금까지 우리가 실시해 왔던 접근 방법의 심각한 문제점을 살펴보고 더 이상 이러한 잘못된 접근을 하지 않기 위해 앞으로 우리는 어떻게 해야 할 것인가를 차례로 살펴보기로 하겠다.
1) 데이터 모델링의 잘못된 유형
필자가 여러 프로젝트를 컨설팅하면서 접했던 데이터 모델들의 형태를 몇가지로 분류해 보면 다음과 같은 세가지의 유형으로 나눌 수 있겠다. 그 첫 번째 유형은 '형제형'이 라고 부르고, 두번째 유형은 '족보형'이 라고 부르기로 하며, 마지막으로 세번째 유형은 '네트워크(network)형'이라고 이름을 붙이겠다.
'형제형'은 말 그대로 관계의 상하에 상관없이 누구나 동격(同格)이 되는 형제로 나타나는 형태를 말한다. 조금 더 자세하게 알아보기로 하자.
데이터 모델링이 한창 진행 중인 어떤 프로젝트에 가서 작성된 ERD를 보면 엔터티(entity)에 속성(attribute)은 가득 차 있는데 어디에도 관계(relationship)는 찾아 볼 수가 없는 경우가 많이 있다. "관계는 언제 맺어지느냐?"고 물어보면 조금만 더 있으면 맺어질 것이라면서 얼굴을 붉히곤 한다. 자식을 낳을 부모 엔터티는 아직 태어나지도 않았는데 자식 엔터티는 이미 태어나 속(속성)까지 채워져 있다. 기업에서 발생할 행위 데이터들을 저장할 집합들은 지금까지 항상 가까이에서 사용해왔기 때문에 눈에 잘 보이지만 이미 오래 전에 돌아가신 조상님(부모 엔터티)들은 눈에 보이지 않아 쉽게 찾아낼 수가 없기 때문이다.
그러다 보니 자식들부터 탄생하는 기현상이 발생한다. 자신이 어떻게 해서 태어났는지 출생의 비밀도 모르면서 속성들부터 마구 집어 넣는다. 더구나 그 속성이 정말 자기 것인지 아니면 조상 것인지, 그것도 아니면 주변에서 빌려 온 것이지도 확인하지 않은 채 우리가 관리해야 할 것처럼 보이니까 그냥 채워두는 것이다.
이렇게 눈 앞에 보이는 것들을 열심히 수집해서 채워 넣고 보니 관계는 없고 독립된 엔터티 박스에 깨알 같은 속성만 까맣게 채워져 있는 ERD가 만들어 진다. 그러다가 그림에 선(관계)을 안 그려 넣으면 그림이 이상하고 창피하니까 한참이 지난 다음에 결국 관계는 그려 진다. 문제는 모델링에서는 1촌 관계만을 찾아 관계를 맺어 주어야 함에도 불구하고 어디나 있어야 할 '구분코드', 가령 '거래구분'과 같은 자신의 출생과 별로 관련이 없는 엔터티와 관계를 맺어 준다.
그러다 보니 '거래구분'과 이것과도 1:M, 저것과도 1:M이 된다. 마치 '할아버지', '아버지', '나'가 있는데 할아버지도 단군할아버지의 자손이고, 아버지도 단군할아버지의 자손이며, 나도 단군할아버지의 자손이므로 결국 이들과 단군할아버지는 모두 동일한 1:M관계가 된다. 이 말은 곧 할아버지와 아버지, 나는 동일한 위치, 즉 '형제'가 된다는 있을 수 없는 일이 벌어지게 된다는 것을 의미한다. 물론 제일 위에 위치하고 있는 단군할아버지가 보면 다 똑같은 자손임에는 틀림이 없다고 하더라도 이와 같이 이들간의 관계가 형제라고 해야 한다는 것은 지극히 상식밖의 일이 아닐 수 없다.
이러한 일이 발생하는 이유는 모델링에서는 반드시 1촌 관계만을 표현한다는 원칙을 모르고 있었기 때문이다. 나와 아버지와의 1촌 관계를 정의하고, 아버지와 할아버지의 관계를 1촌으로 정의해 두면, 굳이 할아버지와 내가 2촌이라고 정의하지 않더라도 이들 간의 관계는 이미 2촌으로 정의되어 있는 것이다. 마찬가지로 삼촌과 할아버지는 1촌이므로 나와 굳이 3촌이라는 관계를 맺지 않더라도 저절로 삼촌이 되는 것이다. 물론 물리적 모델링 단계에 가서 다양한 물리적 요소들 때문에 접근경로를 단축하기 위해 1촌 이상의 관계들을 정의하는 경우도 있지만 이것은 아주 나중에 일어날 수 있는 것일 뿐이지 논리적 모델링에서는 그렇게 해서는 안된다.
두 번째 유형은 '족보형'이라고 표현을 하는 유형으로써 마치 대대로 물려 오는 족보처럼 부계(父系)중심으로 작성된 데이터 모델을 말한다. 사실 우리가 편의상 어느 조상의 몇대 손이라고 말하지만 어떻게 우리 몸속에는 부계쪽 피만 흐르고 있겠는가? 필자의 성이 '이'씨라고 해도 절대로 내 피에 이씨의 피만 흐르는 것이 아니다. 족보상 이씨의 혈통을 순수하게 받아온 것처럼 보인다. 그러나 우리 아버지의 성은 '이'씨겠지만 우리 어머니의 성은 '금'씨였다. 우리 어머니의 어머니, 즉 외할머니의 성은 역시 '금'씨가 아니다. 그렇다면 온갖 혈통이 섞여 있는 것이지 어떻게 내 몸 속에 이씨 피만 흐를 수 있겠는가? 전통에 따라 아버지 입장에서만 족보를 쓰다보니까 부계혈통만 이어받은 것처럼 보이지만 실제로는 나 자신이 태어나기 위해서는 반드시 아버지와 어머니가 있어야 하고 부계쪽 혈통만으로 탄생될 수는 없는 것이다.
자신의 출생의 비밀을 밝히기 위해서는 반드시 양쪽 부모 모두가 밝혀져야 하는 것이지 어느 한쪽만으로는 불가능 하다. 이와 같이 모델링은 - 특히 논리적 모델링에서는 - 자신에게 피를 준 부모(의미상의 주어; 뒤에 상세하게 설명할 것임)를 명확히 규명해야 한다. 그렇게 해야 자신의 집합이 무엇인지 그 본질을 분명하게 밝혀 낼 수가 있는 것이다.
그러나 대부분의 모델링은 마치 족보처럼 아버지만 나타나 있고 나머지는 대부분 '일련번호'로 표시되어 진다. 마치 낳아준 어머니가 누구였든 간에 어느 아버지의 몇번째 아들로 표현되는 것과 마찬가지라 하겠다.
가령, 어떤 가족들의 자식들을 구체적으로 조사해 보니 사실은 서로 이복형제들이 섞여 있을 수도 있다. 또한 다른 부모가 낳은 자식을 양자로 들여 왔을 수도 있다. 데이터 모델은 필요에 따라 상위 부모 엔터티의 정보를 참조할 필요가 있으므로 반드시 이러한 구체적인 관계가 밝혀져야 하고 그것이 데이터 모델에 구체적으로 나타나야 한다. 대부분의 경우 이러한 관계는 숨어 있어서 잘 모이지 않으며, 대부분의 경우 애플리케이션 로직(logic) 속에 숨어 있는 경우가 많이 있다.
세 번째 유형은 '네트워크형'이라고 표현할 수 있는데 이러한 유형은 마치 네트워크 도면에서 나타나는 것 처럼 길게 선이 하나 늘어져 있고, 중간 중간에 하나씩 라인을 빼서 단말기를 붙이는 것과 유사한 형태를 말한다.
중요한 역할을 하는 엔터티가 군데 군데 위치해 있고 거기에서 길게 선분을 그은 다음 중간 중간에 선을 하나씩 끄집어 내어 엔터티를 달고 있는 모습은 네트워크 도면과 너무도 흡사하다. 실제로 어떤 시스템에서라도 이런 유형의 데이터 모델은 절대로 나타날 수가 없다. 아무리 많은 역할을 하는 중요한 엔터티가 있다고 하더라도 옛날 왕(王)이 그랬듯이 수십명의 1촌 자식들을 거느릴 수는 없을 것이다. 만약 실제로 이러한 모습이 나타난다면 그것은 필시 하나의 엔터티를 물리적으로 수직분할 하여 여러 개로 잘라놓은 것이 틀림없을 것이다.
실전에서 나타나는 데이터 모델에는 1:1이 많이 발생하고 있는데 대부분의 경우 물리적 설계 단계에서 수행속도를 두려워하여 지나치게 수직분할을 했거나, 프로세스의 진행에 따라 단계마다 엔터티를 만든 경우로 보아야 한다.
데이터 모델에는 순서와 시간, 흐름의 개념이 들어가지 않는다. 이러한 개념을 넣어서 마치 DFD(Data Flow Diagram)처럼 업무의 흐름에 따라 엔터티가 발생하는 경우를 많이 발견하게 되는데 필자는 이를 가르켜 EFD(Entity Flow Diagram)라는 신조어를 사용하여 잘못을 호되게 질책하기도 한다.
이상과 같은 잘못된 유형의 데이터 모델이 나타나는 원인은 데이터 모델링 접근방식의 근본적인 잘못에서 비롯 되었다고 할 수 있다. 데이터 모델링은 현실에 흩어져 있는 수많은 요소들을 마치 방정식을 풀듯이 하나 하나 단계적으로 구체적이고 명확하게 정의를 해 가는 것이다.
방정식이 그러하듯이 미지수가 있는 채로는 방적식의 해를 구할 수 없다. 우리가 학교 다닐 때 풀어보았던 방적식은 먼저 풀어야 할 미지수를 찾아 그것을 상수화(常數化) 시키고, 그 결과를 다음에 풀 미지수에 대입하는 방식으로 미지수를 줄여나가야 한다. 이와 같이 모델링에서도 현실에 있는 무수한 불확실성을 해결하기 위해 먼저 해결해야 할 것과 그 결과를 이용하여 해결해야 할 필연적인 종속성(dependency)이 존재한다.
다시 말해서 먼저 정의되어야 할 것과 그것이 정의되어야 이것이 정의될 수 있다는 식의 결정 순서가 분명히 있다는 것이다. 이것을 무시하고 눈에 보인다고 무턱대고 가까이 있는 것부터 정의해 가면 반드시 모순이 따르게 되고 결국에 가서는 서로 엉키어 버린다는 것을 명심해야 할 것이다.
내 자신이 누구인 지를 정확히 알지 못하는데 내 자식이 누구인 지를 어떻게 알 수 있겠는가? 어쩌면 아직도 우리는 설계는 대충 해 두고 특이한 상황이 발생하면 프로그램에서 어떻게 처리하면 될 것이라는 생각을 하고 있고, 또 지금까지 그렇게 해 왔는 지도 모른다. 프로그램을 하나하나 작성해 나갈 때는 상세한 내용이 일일이 드러나지만 설계 단계에서 모든 내용을 상세화 하기란 정말 어렵고 짜증나는 일일 것이다.
이런 이유로 설계 단계에서는 대충 윤곽만 잡아 두고 프로그램 작성 단계에서 고쳐 가는 것이 오히려 마음이 편했는 지도 모른다. 그러나 이제는 그렇게 해서는 안된다. 초가삼간을 지을 때는 간략한 도면만 있어도 가능할 지 모르겠지만 대형 건물을 지으면서 복덕방에서 볼 수 있는 평면도 수준의 도면으로 접근해서는 안된다.
다음 시간엔 데이터 모델링 실태 중 "데이터 모델링의 잘못된 행태"에 대해 살펴보도록 하겠다.
이 글은 (주)엔코아정보컨설팅의 저작물로서 자료의 일부 또는 전부를 (주)엔코아정보컨설팅의 허락 없이 복제 재생하여 사용할 수 없음을 밝힙니다.
[출처] 데이터 모델링 강좌(1) |작성자 김연준