개념 데이터 모델의 활용_ BIS본부 오재철 이사

 개념 데이터 모델의 활용 

우리가 하는 모른 일에는 방법, 방법론이 있기 마련입니다.

규모를 막론하고 정보화 사업에도 당연히 방법론이 존재합니다.

방법론이란 개인의 역량과 경험에 프로젝트의 실행이 종속되지 않도록, 즉 누가 그 일을 하든지 일정한 수준의 질과 양을 보장할 수 있도록, 시스템 구축의 일반화된 절차 및 수행 과제들의 집합이라 할 수 있겠습니다. 이에 따라 모든 업무에 대해 일반화된 절차를 만들고, 단계별 활동을 세분화하고, 활동에 대한 산출물까지를 기술하게 됩니다.

물론 데이터 모델링에도 방법론이 존재합니다. 간단해서 그런지, 정보화 프로젝트에 일하는 많은 사람들이 데이터 모델링 방법론에 있어서의 모델링 절차를 알고 계신 분이 많습니다.

보통 주제 영역 정의로부터 시작해서 모델링 단계로 넘어가면 개념 데이터 모델링, 논리 데이터모델링, 물리 데이터설계.. 이런 식입니다.

일반적인 정보화 사업에서 많은 개발자와 커뮤니케이션하는 설계 수단으로 논리 데이터모델을 이용하는 경우가 많습니다. 또한 설계된 데이터 모델을 DBMS로 전환하기 위해서는 당연히 특정 DBMS에 최적화된 물리 설계가 수반되어야 할 것입니다. 한마디로 '쓸모 있는' 산출물이라는 말입니다.

하지만, 개념 데이터모델은 어떨까요? 어떤 이유로 모델링 절차에 개념 데이터 모델링이 빠지지 않고 등장할까요?

오늘은 개념 데이터모델의 활용에 대해 이야기해 보고자 합니다.

단, 개념 데이터 모델링을 어떻게 수행하는지는 오늘의 목적에서 벗어나므로 논외로 하겠습니다. 또한, 특정 notation이나 tool과 관계없음을 미리 말씀드립니다.

1. 상세한 데이터 모델링 단계의 INPUT

일반적으로 정보화 사업에서 가장 많이 사용되는 형태라고 볼 수 있겠습니다. 사실 개념 모델링 단계가 無用 하다고 말씀하시는 분들을 가끔 만나봅니다. 데이터 주제 영역 정의와 개념 모델이 지나치게 상위 수준이어서 정말 상세한 설계 단계에 INPUT을 제공할 수 있는지 의심스러워하는 경우입니다. 물론 Lagacy 시스템이 있는 경우, Business의 본질이 크게 변경되지 않는 경우에는 이론적으로는 개념 모델의 변경이 크지 않은 것은 사실이니, 이 경우에는 개념 모델링을 생략하거나 간소하게 진행할 수 있을 것입니다. 하지만, 대부분의 경우 개념 데이터모델이 없는 경우가 많고, 결정적으로 현행의 모델과 align을 맞춰서 현행화된 경우는 더더욱 찾아보기 힘든 것이 현실입니다. 따라서 다음에 설명하는 데이터모델의 개선 방향성 공유의 역할과 함께 상위 수준에서 Business 데이터를 식별하고 관리하는 노력이 필요할 것입니다.

 

사실 IN/OUT 관계보다도 이러한 시각에 가려져 있는 더 역할이 있습니다 바로 모델링이 결과보다는 수행 과정의 의사소통에 초점이 맞춰져 있는 행위라는 것입니다. 설계 완료된 ERD는 물론 소중하고 중요한 자산입니다만, 모델링 과정에서 수많은 이해관계자와 토론하고 협의한 내용이 엔티티 하나, 속성 하나로 표현된다는 사실. 그것이 데이터 모델러의 진정한 역할이라고 생각합니다. 

2. 데이터모델 개선안/방향성 공유

정보화 프로젝트의 모든 구성원은 프로젝트의 주요한 변화 테마에 대해 여러 가지 View을 통해 정확히 이해할 수 있어야 하고, 이를 위한 도구가 제공되어야 합니다. 개념 데이터 모델을 통하여 프로젝트의 주요 변화에 대한 데이터 측면의 개선안이나 방향성에 대한 이해와 공유를 돕는 도구를 제공할 수 있습니다. 

상세 수준의 설계가 진행되지 않은 시점에 데이터의 범위와 구성 집합을 시각적으로 확인하고 구성원에게 공유할 수 있다는 점이 매력적이기는 합니다만, 사실 개념 데이터모델이라기보다는 '개념 모델을 이용한 방향성'이라고 정의하는 것이 명확할 것 같습니다. 이 경우 As-Is와 To-Be의 개념 데이터모델을 비교하고, Business 변화에 따른 데이터의 변화를 명확히 문서화하는 작업이 필요하기 때문에 데이터 모델링을 '설계의 범주'로 넣는 것보다는 'Business를 표현하기 위한 방법'으로 분류하는 것이 보다 타당하다 하겠습니다.

유사한 유형으로 복수의 개별 시스템을 통합해야 하는 업무에서는 개념 데이터 모델링 단계에서 통합 대상 시스템을 대상으로 한 상위 수준의 Fit/Gap 분석과 시각화가 가능하여, 프로젝트 초기의 의사결정에 많은 도움이 될 수 있습니다.

3. Integration의 기준

대규모 정보시스템은 다수의 모델러가 parallel 하게 진행되어야 하기 때문에 전체 시스템 차원의 Integration이 매우 중요합니다. 이 경우, 전사 혹은 전체 시스템 차원의 개념 데이터모델이 마련되어 있다면 많은 도움이 될 수 있습니다. 모델링 단계에서는 개별 단위 업무 모델러는 개념 데이터 모델을 참고하여 타 업무와의 연관 관계를 파악하고,  Integration을 담당한 모델러는 개념 데이터모델을 기준으로 단위 업무 모델 간의 관계를 검증하게 됩니다. 사례에서 보는 바와 같이 개별 단위 데이터 주제 영역의 핵심 엔티티를 도출하여 기술된 개념 데이터모델은 전체 시스템의 뼈대 역할을 하는, 일종의 skeleton diagram의 역할을 하게 됩니다.

하나 더.

과거 모 회사의 차세대 프로젝트에서 프로젝트의 Steering을 담당하고 있는 고객사 프로젝트 리더와 각 업무 현업(비 IT) 팀장님들께, 대형 용지에 컬러로 인쇄해서 코팅까지 한 

개념 데이터 모델을 드린 적이 있습니다. 

과도한 찬란함의 오류를 여실히 보여주는 색상과, Key 레벨도 표시되지 않은 '초'상위의 개념 데이터모델이었고, 특별한 산출물도 아니고, 공을 많이 들인 설명자료도 아니었지만, 지금까지 데이터 모델러로 살면서 어떤 문서를 제출하고 받아들었던 고객의 반응 중에 가장 뜨거웠다고 생각합니다. 팀장님들께서 주요한 회의 때마다 개념 모델을 꺼내오셔서 (코팅한) 모델 위에 마킹하고, 메모하면서 당신들만의 방식으로 이슈를 이해하고, 문제 해결을 위한 방안을 찾는 것은 정말 신선한 장면이었습니다. 단점이라면 팀장님들의 IT 이해 수준이 과도하게 높아져서 개발 팀원들의 원성을 샀던 점이.. 

위 사례에서 보는 바와 같이 상위 수준의 데이터 모델링 시각화 도구로 개념 데이터모델의 활용방법은 매우 다양하다고 할 수 있습니다. 또한, 학술적인 접근이 아니라면 개념 데이터모델을 표현하는 수준도 다양할 수 있음을 확인할 수 있습니다. 모델을 이용하는 조직 구성원의 눈높이에 맞게 제공하고, 이해하는 것이 무엇보다 중요하기 때문입니다.

이와 같이 개념 데이터모델을 활용하여 프로젝트 이해관계자에게 보다 매력적으로 데이터를 표현할 수 있는 방법에 대해서 고민하는 것이 데이터 모델링의 세계를 보다 풍성하게 할 수 있는 작업이 될 수 있을 것이라 의심치 않습니다. 

  여러분은 데이터모델을 얼마나 활용하고 계신가요?