데이터 모델링22- 엔티티 모델링의 어려움을 극복할 방법론과 전략1

소프트웨어 개발에 대한 단상과 모델링 전략

1.엔티티 모델링이 어려운 이유는 경험재가 아니기 때문이다.

앞선 게시글 [데이터 모델링15-엔티티 모델링의 어려움]에서 엔티티 모델링이 어려운 이유 다섯가지를 살펴보았다. 여기에 덧붙여 데이터 모델의 특성에서 기인한 이유 하나를 더 추가하려 한다. 모델은 프로그램과 같은 경험재(experience goods)가 아니다. TV는 구매 후 바로 확인해서 작동이 안되면 즉시 반품할 수 있고, 프로그램은 컴파일 에러가 발생하면 즉시 확인 후 수정이 가능하며 실행 결과도 즉가 눈으로 확인된다.

 

그렇지만 방금 그린 ERD는 잘 동작하는지, 다른 문제는 없는지 즉시 확인해볼 수 없다. 모델은 아키텍처으 기저에 존재하여 구조적 문제가 당장 수면 위로 올라오지 않는다. 작성한 모델을 정량적으로 평가하는 것도 쉽지 않다. 이런 이유로 만들어진 데이터 모델은 검증이 쉽지않다.

 

2.업무 요건을 정확히 이해하고 정의한다느 것의 어려움

문제 영역을 정확히 파악하여 요구명세로 만들어낸다는 것은 굉장히 어려운일이다.

 

3. 소프트웨어의 역할은 문제영역을 시스템으로 옮기는 것이다.

 

소프트웨어의 역할은 인간이 지닌 문제를 컴퓨터로 해결하는 것이다. IT는 계층간의 통역이라고도 할 수 있다. 인간의 언어를 프로그래밍 언어로, 다시 기계어로 전환하고, 최종적으로는 전기적 신호로 번역한다. 사용자의 문제 영역은 인간의 영역이면 0과 1의 세계는 물리적인 영역이다. 소프트웨어는 이 두 영역 사이에 존재한다. 따라서 우리는 인간과 소프트웨어 그리고 물리라는 세 계층을 모두 이해해야 한다.

 

4. 문제 영역, 요구사항의 명확한 정의는 가능한 것일까

IT 소프트웨어를 만들때 당면하게 되는 문제중 하나는 문제 영격을 정확하게 정의하기 어렵다는 것이다. 정보시스템의 요구사항은 확정될 수 있을까? 요구사항은 프로젝크가 끝날때 으레 변경된다. 요구사항을 완벽히 통제하고 확정하는 것은 사실상 불가능하며, 요구사항은 항상 모호하다. 한 프로젝트에 요구사항이 확정되었다고 가정해보자 그런데 그 요구사항을 충족시키기 위한 하위 요구사항은 확정되지 않은 채로 남아이다면? 소프트웨어는 한 덩이에서 -> 작은 모듈로 거기서 -> 다시 복잡한 세부 로직으로 계층적으로 구성된니다. 요구사항도 마찬가지다. 어쨌든 문제 영역을 정확하게 이해하고 정의하는 것은 매우 어렵다.(모델링과는 조금 무관하지만 이런 문제의식에서 시작한 것이 최근 유행하는 애자일 방법론이다.)

 

5. 복잡도 문제를 해결하려면 무엇이 필요한가

지금까지의 장황한 이야기는 모두 복잡도를 말하기 위함이었다. 현실 세계의 업무는 복잡하다. 따라서 이를 시스템으로 옮겨놓은 소프트웨어도 복잡할 수 밖에 없다. 복잡한 업무가 복잡한 소프트웨어로 옮겨질 뿐이다. 이렇듯 소프트웨어는 태생적으로 복잡하다. 스리고 시스템 규모가 커지면 그 복잡성도 기하급수적으로 커진다. 업무 규모가 10이었을 때 오류가 10개였다면 업무 규모가 100일 때는 오류가 10¹⁰개로 증폭될 수 있다. 이러한 복잡도 문제를 해결할 수 있는 무언가가 필요하다.

 

분할 정복

정보 기술이 찾은 복잡한 문제 풀이의 방법은 분할 정복(divide and conquer)이다. 여기에는 현실세계의 특정 부분의 무시하여 문제를 간단하게 만드는 추상화 기법이 적용된다. 기능 관점으로 추상화한 UML의 유스케이스, 데이터 과점으로 정규화된 엔티티가 모두 분할 정복의 산물이다. 

 

다만 분할 정복이 시스템의 복잡도를 덜어주는 것은 아님에 주의해야 한다. 앞서 언급한 것처럼 프로그램을 작성하면 복잡한 업무가 복잡한 소프트웨어로 옮겨질 뿐이다. 소프트웨의 복잡성을 분할 정복으로 해결할 수 없는 이유는 소프트웨어를 모듈화한다고 해서 모듈화되는 것은 아니기 때문이다. 결국 분할은 소프트웨어의 복잡도를 제거하는것이 아니라 복잡도의 숲에서 길을 잃지 않고, 업무 영역을 시스템으로 옯기는데 지치거나 압도되지 않도록 도와 줄 뿐이다.

 

결론, 분류가 필요하다.

분할 정복은 필연적으로 분류 문제를 발생시킨다. 하지만 업무 도메인에서 절대적인 분류 기준을 찾을 수는 없다. 분류란 내가 생각하는 대상을 어디에 두고 어떻게 묶는냐는 것인데, 그 기준이 항상 애매하다. 이러한 분류 문제는 소프트웨어 공학의 모든 곳에서 나타난다. 해결하려는 문제가 너무 복잡하기 때문에 위는 문제를 쪼갤 수밖에 없다.

 

데이터 모델링에서는 정규화가 바로 분류의 핵심 기준이다. 데이터 영역을 멀리서 보면 정규화가 보이고 현미경으로 보면 부분집합이 보인다. 업무 도메인이 변경되는게 두렵다면 그 중에서도 변경되지 않을 법한 것을 앞에 내세워야한다. 그럴러면 업무 도메인을 유지해주는 근본적인 것이 무엇인지 생각해야한다. 업무 도메인도 변하는 것과 변하지 않는 것으로 나뉜다. 우리는 가급적 변하지 않는 것에 집중해야 한다. 

 

이런 변하지 않는 부분을 찾아내기란 쉽지 않다. 은행은 각양각색의 예금 상품을 만들어 팔고 있다. 그러나 대부분의 은행 예금에는 정해진 만기일이 있고, 이자를 지급해야 한다는 사실은 변하지 않는다. 그리고 어떤 분류 체계든지 그 체계에 부합하지 못하는 대상이 있으므로, 결국 억지로 끼워 넣거나 다수의 분류에 애매하게 걸치는 경우도 적잖이 확인할 수 있다. 이는 모델링을 위해 당시에 채택한 분류가 얼마만큼의 보편성을 획들할 수 있는냐의 문제로 귀결된다.

 

엔티티 모델링의 어려움 극복 방법

어려움과 복잡도를 극복할 전략은 1)정규화 이론에 근거한 분류, 2)마스터 데이터를 중심으로 한 업무 행위의 주체와 대상 식별, 3)Account 중심의 접근법 , 4)명확한 분류하기등이다. 결국 데이터 모델링이란 분류와 묶음이다.

 

-> 분류의 결과물은 서브타입(부분집합)이다.

 

분류와 서브타입

앞서 말한 분할 정복과 분류의 개념을 데이터 아키텍쳐의 영역으로 가져와서, 업무 복잡도에 압도되지 않고 좋은 모델을 만들수 있는 실전적 방법과 원리로서의 서브타입(subtype)에 대해 알아보기로 하자.

 

서브타입은 분류의 결과로 나뉜(sub) 유형(type)이다. 즉, 전체와 부분을 명시적으로 구분하여 표현하는 방식이다. 어떤 것을 분류하는 이유는 대상의 본질을 여러 성질 별로 분류하여 그 본연의 모습을 쉽게 이해하기 위해서이다. 기준과 규칙을 가지고 대상을 분류함으로써 그 대상을 구성하는 각 요소를 실체를 파악할 수 있고 또 요소 사이의 동질성이나 차이점에 대해서도 이해할 수 있게된다.

 

그림 11-1 분류되지 않은 엔티티(왼쪽)와 서브 타입으로 분류한 엔티티(오른쪽)

따라서 서브타입을 보면 대상이 가지는 요소 간의 차이점을 알기 쉽다. [그림 11-1]은 <이해관계자>를 분류하여 <온라인회원>과 <공급자>라는 서브타입을 도출한 예다.  왼쪽보다 오른쪽의 엔티티가 <이해관계자>라는 집합이 어떻게 구성되어 있는지 이해하기 쉽다.

 

서브타입을 업무와 데이터 집합을 이해하는 도구로 활용하기에 유용하다. 데이터 모델링을 업무를 100%이해한 상태에서 모델링을 시작하는 경우는 거의 없다. 업무를 분석하면서 데이터 집합을 다양한 관점에서 조망하면서 데이터를 어떤 종류로 분류할 수있는 알아가는 과정에서 서브타입은 중요하다. 좋은 데이터 모델링을 하려면 데이터를 보고 전체집합과 부분집합을 잘 도출할 수 있어야한다.

 

그림 11-2 서브타입을 포함한 엔티티와 주변 엔티티

[그림 11-2]는 서브타입이 잘 도출되어서 서브타입 주면의 관계도 명확히 표현된 좋은 논리 모델이다. 이 모델을 보면 <이해관계자>가 <온라인회원>과 <공급자>로 구성되어 있음을 알 수 있다. 그리고 슈퍼타입(전체집합)에 그어진 관계선을 통해 <온라인회원>과<공급자>모두는 <등급이력>으로 관리되고 있음도 알 수 있다. 동시에 포인트는 <온라인회원>에게 만 발급되며 <공급자>는 별도의 신용 정보와 평가 내역을 관리하는 것도 쉽게 파악할 수 있다. 물론 서브타입들의 공통 속성과 고융 속성도 명확하다.

 

데이터 모델이 상세화 되어 있다는 것은 바로 위 그림과 같은 것이다. 이 모델은 오프라인 회원은 이해관계자로 관리하지 않는다는 업무 규칙을 명시적으로 담고 있다. 이렇게 모델에서 서브타입이 명확하게 보여 업무를 입체적으로 조망할 수 있는 것, 이것이 바로 논리 데이터 모델이다.

 

어차피 테이블로 만들때는 서브 타입을 가지며  통합(RollUp)된 형태가 아니라 서브 타입벼로 쪼개서 개별 테이블로 생성(RollDown)할 건데 굳이 통합(RollUp)된 형태의 서브 타입을 만들어야 하느냐고 반문할 수도 있다. 앞서 논리 데이터 모델은 테이블 수준이 아닌 인간이 이해하기 적헙한 수준으로 데이터를 관리하는 뷰라고 했다. 이러한 이해를 바탕으로 다음 모델들을 살펴보자 

 

그림 11-3 슈퍼타입 없이 독립적으로 존재하는 경우

[그림 11-3]은 업무 행위의 주체가 <온라인회원>과<공급자>라는 두 형태가 있음을 추측할 수 있게 해준다. 하지만 확신할 수는 없다. 데이터의 동질성을 확신하게 해주는 묶음(슈퍼타입)이 없기 때문이다. 그에 반해 [그림 11-2]에서는 <온라인회원>과 <공급자>가 명확하게 <이해관계자>의 부분집합으로 존재하므로, 업무 행위의 주체가 명확히 두 종류임을 확신할 수 있는 것이다. 게다가 이해관계자 역할의 엔티티가 다른 주제 영역(subject area)에도 존재한다면 그 엔티티의 존재를 인지하기가 더 어려울것이다. 이것은 단순히 쉽다・어렵다의 논점처럼 보일 수도 있으나, 사실 굉장히 중요한 문제다 그림 한장으로 전체와 부분을 식별할 수 있고, 거버넌스에 꼭 필요한 영향도를 분석할 수 있느냐 그렇지 못하느냐는 천지차이다.

 

[출처 - 프로젝트의 성패를 결정짓는 데이터 모델링 이야기 , 김상래 저]