DATOR


데이터 모델링은 어려운가? MODELING


벌써 오래전에 '데이터 모델링 왜 잘해야 하나요?' 라는 글을 쓴 적이 있는데 그 때 생각한 것이 데이터 모델링을 얼마나 공부하고 경험해야 하는가에 대한 생각도 정리해보자라는 것이었다. 너무 오래되었지만 그 때의 기억을 소환하여 데이터 모델링의 어려운 점에 대한 단상을 적어 본다.


무슨 일을 할 때 그 일이 어렵거나 쉬움을 판단한다는 것은 그 결과에 대한 기대치를 가지고 그 기대치 수준에 가까이 가기가 어렵거나 쉽거나를 판단한다는 것이다. 문제는 데이터 모델링에 대한 기대치의 개인차가 매우 크다는 점이다. 프로그램을 작성하는 작업은 프로그램 스펙에 명시된 기능을 오류없이 만족하면 되므로 개발자나 관리자, 기획자 심지어 사용자의 기대치가 모두 유사한 수준이다. 그런데 데이터 모델링에 대한 기대치는 다음의 예와 같이 매우 다르다.


일반 개발자의 기대치 : 대상 데이터가 어느 테이블에 있는지 쉽게 알 수 있었으면 좋겠습니다. 그리고 SQL 작성도 쉽고, 성능도 빨랐으면 좋겠습니다. (모델의 명확성, 성능 등)

운영 담당자의 기대치 : 업무의 변경을 쉽게 소화하여 데이터 모델과 관련 프로그램의 수정이 최소화되도록 모델링해 주세요. (유연성)

분석 담당자의 기대치 : 매출액이면 모든 테이블에서 동일한 값이 나와야 하는 거 아닌가요? (데이터 품질)

DBA의 기대치 : 데이터가 증가하더라도 SQL의 수행시간은 유지되어야 합니다 (성능)

고수 개발자의 기대치 : 데이터 값이 저장될 곳만 만들어줘. 나머지는 내가 알아서 할께! (신속하게 해치워죠!)


이렇게 다양한 기대치 중 목소리 큰 사람의 기대치만 반영해서 작성한다면 데이터 모델링은 쉬울 수 있다. 그러나 모두의 기대치를 만족시키려 노력하며 결론으로 인해 덜 고려된 요소는 부가적인 설명자료라도 만들어서 제공하는 것이 올바른 데이터 모델러의 자세라 할 것이다. 이렇게 모델링을 하는 것은 당연히 쉽지 않다.


'정말 이렇게 하는 것이 최선일까?' 라는 고민을 하면서 모델링을 수행해본 사람이라면 다음과 같은 면에서 어려움을 느낄 것이다.


1) 엔터티 정의를 얼마나 길게 기술해야 할까? 서브 타입은 꼭 그려야 하나?

2) 속성 정의, 관계명은 꼭 써야 하는가?

3) 이력 테이블을 만들어야 하나? 아니면 원 테이블과 통합한 테이블을 만들어야 하나?

4) 컬럼이 계속해서 추가되어야 하는 테이블인데 유연성을 위해서 meta 구조로 하는 건 어떨까?

5) 배타관계가 많이 나타나는데 통합을 고려해야 하는가?

6) 통합을 하게 되면 검색 성능이 떨어지지 않을까?

7) PK가 5개나 되는 테이블인데 인조식별자를 만들면 어떨까?


학교나 서적을 통해서 위에 나열되어 있는 용어의 의미에 대해 알 수 있지만 실제 업무에서는 위와 같이 지식과 경험이 동시에 필요한 판단을 해야 하는 요소가 정말 많기 떄문에 데이터 모델링은 어려운 것이다.

또한 아래와 같이 인터넷이나 서적 등에서 접하게 되는 선언적 표현들도 모델러에게 어려움을 준다. 


1) 서브타입세트는 하나만 표현해야 한다.

2) ERD에 관계로 표현한 것은 모두 DBMS의 FK 제약조건으로 만들어야 한다.

3) 이력테이블은 선분이력으로 만들어야 한다.

4) 반복되는 속성이 있으면 반드시 정규화해서 하위 테이블을 만들어야 한다.

5) ERP 패키지나 1등 업체의 모델을 따라하자.


위 내용을 살펴보면 '~이면 ~해야 한다' 라고 매우 명쾌한 결론을 제시하고 있어 모델링을 단순화하고 있지만 실제로 그 내용을 실전에 적용하기에는 문제가 있는 항목들이다. 각각에 대해서는 이미 다른 글에서 언급했거나 앞으로 정리할 내용으로 본 글에서는 간단한 커멘트만 적으면 다음과 같다.


1) 엔터티를 보다 자세히 설명하기 위해 논리모델에서 사용하는 것이 서브타입이므로 보다 다양한 시각으로 엔터티를 설명하기 위한 여러 서브타입세트의 활용은 충분히 의미있는 일이다. 물리 테이블을 만들기 위해 하나의 기준만 적용해야 한다는 것은 순서가 잘못된 접근이다. 

2) ERD의 관계를 기반으로 실제 데이터를 검증하는 것은 올바르지만 그 방법이 반드시 DBMS의 제약조건일 필요는 없다. 다양한 요소를 고려해서 트리거를 사용하거나 배치작업을 통해서 체크할 수도 있는 것이다.

3) 이력테이블의 용도를 보아 점이력으로도 충분한 경우가 많다. 특정시점의 신속한 재현이 자주 발생한다면 보다 선분이력의 필요성이 커질 뿐이다.

4) '반복되는 속성'이라는 정의를 먼저 해야 한다. 유사성을 너무 크게 잡으면 잃는 것도 생긴다.

5) ERP 패키지는 어쩔 수 없이 유연성을 매우 중요하게 고려한 모델로 현실에 적합하지 않을 가능성도 크다. 1등 업체라도 모두 데이터 모델이 최선은 당연히 아니다.


위의 5가지 이외에도 모델링에 대해서 너무 쉽게 규정하는 설명과 방법론이 많이 존재한다.


우연한 기회에 어떤 개발 방법론에서 데이터 모델을 설계하는 과정을 본 적이 있는데 무척 쉽게 설명하고 있었다. 간단히 설명하면 사용자 화면과 출력물을 기준으로 속성을 도출하고 그 속성들을 유사성을 기준으로 그룹을 만들어 엔터티를 도출하고 정규화와 반정규화를 적용하여 데이터 모델을 완성하는 순서였다. 이렇게 하면 데이터 모델링이 거의 끝난 것으로 데이터 모델링이 어렵지 않다고 설명하고 있었다. 그 과정의 수강생들은 모두 그 단순 명쾌함을 좋아하는 눈치였는데 좀 안타까운 느낌이 들었었다. 모델링 시에 고려해야 하는 것들을 직접 고민하지 않고, 유사성 기준의 그룹화, 화면(기능) 기준의 속성 도출과 정규화 등을 통하여 모든 것이 제대로 될 것이라고 생각하는 것은 너무 단순한 접근이다. 이렇게 완성된 데이터 모델은 아마도 위의 여러 담당자의 기대치 중 고수 개발자의 기대치만 만족시키는 수준이 될 것이다. 일반 개발자 및 운영자에게는 숨어 있는 여러 배타 관계로 인해 SQL의 작성이 어려워 질 수 있고, 화면 기준의 테이블은 화면의 개편과 함께 적지 않은 운영 상의 복잡도 증가가 일어날 수 있으며, 유사한 테이블이 여러 시스템에 걸쳐 존재하는 전사적인 측면에서의 데이터 중복 및 불일치 가능성이 커질 것이다. 


최선의 데이터 모델을 설계하기 위해서는 모델링 시에 고려해야 하는 여러 항목 - 유연성, 데이터 품질, 성능, 관리용이성 등 - 을 모두 고려하여 종합적으로 판단해야 하며 (http://www.dator.co.kr/encore/textyle/620387),  데이터 모델링 관련 서적 중 700페이지가 넘는 서적도 많이 존재하고, party role, service account, meta구조 등 쉽지 않은 개념도 많음을 감안하면 결코 데이터 모델링을 쉽게 접근해서는 안된다.


결론을 내려보면

'기업 수준'에서의 데이터 모델링을 '제대로 하려면' 며칠 간의 교육 수강만으로는 어렵다!

는 것이다. 앞으로 더 설명하겠지만 데이터 모델링에 대한 상황과 기대 수준이 워낙 다양하므로 약간 다르게 표현하면 다음과 같다.


 '기업 수준'에서의 데이터 모델링을 '신속하게 해치우려면' 며칠 간의 교육 수강만으로도 가능하다. 

 '상당히 간단한 수준'에서의 데이터 모델링을 '제대로 하려면' 며칠 간의 교육 수강만으로도 가능하다.


약간 말장난 같은 느낌이지만 어떻게 하면 공감할 수 있을까를 고민하여 표현한 것으로 대상 업무의 복잡도를 '기업 수준'과 '상당한 간단한 수준'으로, 모델링 시 얼마나 다양한 항목을 고려했느냐를 '제대로 하려면'과 '신속하게 해치우려면'으로 구분하여 직설적으로 정리한 것이다. 대부분의 전산 시스템 담당자들은 자신의 업무가 '기업 수준'에 해당한다고 알고 있을 것이고 그것이 적절한 판단이다. 오히려 업무가 너무 복잡해서 일반 기업 수준이라 표현하면 좀 섭섭한 담당자들도 많을 것이다. 

한편, 기업의 데이터 모델을 설계하는 담당자에게 다양한 고려 사항 사항을 검토하고 종합적으로 판단하느라고 물어보면 그렇게 까지 고민하지는 않았다라고 대답한다. 그 원인에는 데이터 모델링의 다양한 고려 사항을 모두 감안하여 모델링을 진행하면 시간이 너무 많이 걸릴 것 같다는 생각이 자리잡고 있는데, 사실 데이터 모델링에 투입되는 시간은 데이터 모델링에 대한 올바른 지식과 경험으로 상당히 줄일 수 있는 부분으로 앞으로 '데이터 모델링을 잘하는 방법'을 설명하면서 정리하도록 하겠다.


TAG

Leave Comments