최상운의 사선(死線)에서 (7회)

데이터 모델 요소: 주제영역

?

[필자 소개]? 최상운은 2000년 중반부터 데이터 관련 직무를 수행하고 있다. 은행·보험·증권·신용카드사 프로젝트에서 데이터 아키텍트, 데이터 모델러, PMO(Project Management Officer)를 수행했고, ISP 컨설팅에 참여했다. 한국데이터산업진흥원(KDATA)에서 주최하는 ‘DA 설계 공모대전’에서 2018년에 대상을, 2016년에는 금상을 각각 수상했다. 복잡하고 어려운 모델이 아닌 ‘업무가 정확히 담겨 있고 모두가 이해할 수 있는 모델’을 만들기 위해 현장에서 땀 흘리고 있다.

?

현장에서 전하는 데이터 모델링 이야기 필자는 수년간 시스템 통합(SI) 프로젝트에서 데이터 아키텍터, 데이터 모델러, PMO, 컨설턴트로서 역할을 했다. 그때마다 ‘왜 저렇게 데이터 모델링을 하지? 어떻게 하면 사람들이 데이터 모델 이론을 쉽게 익히고 베스트는 아니지만 모델에 업무를 표현하고 관련자에게 공유할 수 있도록 도와줄 수 있을까?’를 놓고 고민했다. 정답은 아니지만 데이터 모델링 과정을 이해하고 각 과정에서 해야 할 것과 점검할 것을 자료 형태로 정리하면 도움이 될 것 같아 조금씩 정리하고 있었다. 어렵고 복잡한 데이터 모델 이론은 배제하고 개발자 입장에서 접근 가능한 데이터 모델 이론을 소개하고, 실제 베스트와 워스트 데이터 모델 사례를 소개함으로써 '제대로 된 상당한 수준의 모델'보다는 '업무가 정확히 담겨 있고 모두가 이해할 수 있는 모델'을 작성할 수 있도록 하고 싶다는 생각에 감히 도전하게 되었다. 필자는 SI 프로젝트 현장에서 데이터 모델러로서 생사가 갈리는 전쟁터, 그 사선(死線)을 넘나들고 있다. 어떻게 하면 이 사선을 넘어 목표 지점에 도달할 수 있을까? 이 차원에서 다소 무겁지만 현장에서 겪는 문제점들을 먼저 알아보고, 나름대로 대책도 제시해 보고자 한다. 대책이 정답은 아니더라도, 모든 것을 해결할 수는 없더라도, 새롭고 획기적인 방법은 아니더라도 모델 다운 데이터 모델을 만들기 위한 방법을 생각했고 그것을 나누고자 이 글을 시작한다.

?

주제영역은 데이터간 상호 관계가 높은 엔터티들을 모아 놓은 논리적 구분 단위다.

1000개의 엔터티가 있는 모델을 A3 용지 한 장에 다 표현할 수 있을까? 혹 가능하더라도 너무 작아서 잘 보이지 않거나, 엔터티 간 관계 표현이 복잡해서 가독성이 떨어질 것이다. 대신에 A3 용지 여러 장에 20~40개 정도로 엔터티를 그룹핑해 보면, 적당한 크기의 관계도를 읽기에 편할 만큼 표현할 수 있을 것이다.

이렇듯 전체 엔터티를 관리하기 쉽게 그룹핑해 놓은 것이 주제영역이다. 그럼 어떻게 엔터티를 그룹핑하면 좋을까? 엔터티명을 가나다 순으로 배치한 다음, 20개씩 그룹핑하면 될까? 물론 아니다. 데이터 성격이 유사한 엔터티끼리 그룹핑하는 것이 효과적이다. 다시 말하면?데이터 간 상호관계가 밀접하고 다른 주제영역과는 독립적인 엔터티를 그룹핑하는 것이 주제영역이다.

주제영역을 정의하는 가장 큰 목적은 데이터의 계층적 구조를 파악해 관리할 수 있기 때문이다. 수많은 데이터를 사전 정의된 기준에 따라 분류해 놓음으로써 데이터에 대한 접근성을 높이고, 신규 데이터 발생 시 분류와 관리를 용이하게 할 수 있다.

?

주제영역 정의 - 데이터 간 상호관계가 밀접하고 다른 주제영역과는 독립적인 엔터티를 그룹핑하는 것이 주제영역(Subject Area)이다. - 주제영역은 데이터간 상호 관계가 높은 엔터티들을 모아 놓은 논리적 구분 단위다. - 주제영역은 데이터로 관리하고자 하는 관심 영역으로, 데이터의 상위 집합이다. - 하나의 주제영역으로 정의되는 데이터 간의 관계는 밀접하고, 다른 주제영역에 포함되는 데이터 간의 상호작용은 최소화할 수 있도록 정의한다(높은 응집성, 낮은 결합성).

?

? 데이터 위치를 쉽게 찾고 신규 데이터를 분류하는 기준

책을 빌리기 위해 도서관 도서 검색대에서 원하는 책을 대출할 수 있는지를 조회한다. 다행히 대출가능하면 ‘331.5412-ㅂ986ㅂ’라고 표기된 청구기호를 종이에 적거나 인쇄한다.


[그림 1] 청구기호와 도서관 책장책마다 배정된 청구기호는 자료의 위치를 알려주고, 다른 자료와 구분해 주는 역할을 한다. 따라서 청구기호는 책들의 주소라고 할 수 있다.

청구기호 앞 3자리를 보고 어느 책장에 있는지 먼저 찾는다. 그리고 해당 책장에 저자기호 순으로 책이 비치돼 있으므로 저자기호를 보고 순차적으로 오른쪽에서 왼쪽으로, 위에서 아래로 훑어보며 책을 찾을 수 있다.

청구기호 중 앞 3자리를 분류기호라고 한다. 한국십진분류법을 토대로 000부터 999번까지 책이?주제별로 구분돼 있다. 청구기호를 토대로, 분류기호가 찾고자 하는 책의 위치를 알려주므로 책을 쉽게 찾을 수 있다. 또한 신규 도서의 주제에 맞게 분류기호를 부여함으로써 신규 도서 분류를 쉽게 해 준다.

분류기호로 책의 위치를 쉽게 찾듯이, 데이터 주제영역은 찾고자하는 데이터의 위치를 쉽게 찾을 수 있도록 한다. 또한 신규 데이터를 신속하게 분류하는 기준도 제공한다.

? 데이터 성경 중심과 업무조직 중심 주제영역

원칙적으로는 데이터 성격을 기준으로 엔터티를 그룹핑해 주제영역을 정의해야 한다. 하지만 실무 프로젝트에서는 기업의 업무조직으로 주제영역을 정의하는 것이 일반적이다. 데이터의 유사성도 중요하지만, 해당 주제영역에 대한 오너십(데이터에 대한 권한과 책임) 문제가 기업 조직 구조와 맞물려 있어 데이터 성격을 기준으로 주제영역을 정의하기에는 괴리가 있다.

예를 들어 은행에서 데이터 성격을 기준으로 주제영역을 정의한다고 하자. 여신·수신·외환·대외 업무조직에서 고객과 체결한 계약 데이터를 묶어 ‘계약’이라는 주제영역을 정의했다. 하지만 여신·수신·외환·대외 업무조직은 있지만 ‘계약’이라는 업무조직은 없다. 각 업무조직에서 발생한 계약 건은 각 업무조직에서 체결과 실행에서 종료까지 관리하는 것이 일반적이다. 전사에서 발생한 계약 건을 총괄 관리하는 업무조직을 별도로 만들지 않는다면 ‘계약’ 주제영역의 데이터를 누가 관리하고, 누가 권한과 책임질 것인지가 명확하지 않게 된다. 즉 ‘계약’ 주제영역에 있는 ‘계약기본’ 엔터티에는 여신·수신·외환·대외에서 발생한 데이터가 들어 있다. 그럼 어느 업무에서 ‘계약기본’ 엔터티를 관리할 것인가?


[그림 2] 업무조직 중심 주제영역 정의 vs. 데이터 성격 중심 주제영역 정의[그림 2]는 업무조직 중심의 주제영역과 데이터 성격 중심의 주제영역을 표현한 것이다.

2000년도 초?로 일반화한 참조 모델을 소개하면서 데이터 주제영역을 업무관계자(Party), 계약(Agreement), 상품(Product), 경영방침(Business Direction), 자원(Resource), 이벤트(Event), 장소(Location), 조건(Condition), 분류(Classification) 등으로 분류하는 방법을 소개했다. 국내 SI 업체들에서 이것을 그대로 받아들여 프로젝트를 진행한 적이 있었다. 처음에는 데이터 성격 중심의 주제영역이 주는 이점을 부각시키면서 진행했다. 하지만 프로젝트가 진행되면서 데이터에 대한 오너십이 기존 업무조직과 배치(背馳)됐다. 업무조직을 바꾸지 않는 이상 데이터에 대한 오너십 문제를 해결할 수 없었다. 이 때문에 다시 업무조직 중심의 주제영역으로 회귀한 적이 있다.

데이터를 의미적으로 일반화해 그룹핑하면, 유연한 데이터 구조와 데이터 통합 및 공유 측면에서 효과적이다. 하지만 기업의 업무적 가시성 확보가 어렵고 업무간 오너십 문제가 발생할 수 있으므로 실무 프로젝트에서는?데이터 성격 중심과 업무조직 중심을 적절히 적용해 주제영역을 정의해야 한다.


[그림 3] 데이터 성격 중심과 업무조직 중심을 적절히 반영한 주제영역 정의[그림 3]은 데이터 성격 중심과 업무조직 중심 주제영역을 적절히 반영한 주제영역 정의 예시다.

[그림 3]에서 데이터 성격 중심 주제영역은 업무를 수행하는 주체·대상·자원 등과 관련된 데이터로 고객·상품·조직 같은 주제 영역이 이에 해당한다. 엔터티 분류에서 실체 엔터티에 해당되는 엔터티가 주로 포함돼 있다. 정의(Definition)에 의한 데이터가 관리된다.

[그림 3]에서 업무조직 중심 주제영역은 여러 가지 업무 활동에 의해 발생하는 계약·거래·주문·결제 등과 같은 데이터를 업무조직별 분류로 이뤄졌다. 같은 계약 데이터라도 그 데이터의 오너십이 어느 업무에 있는지에 따라 여신·수신·대외 등으로 분류된다.

?

? 실무 프로젝트에서 목표 주제영역 설계

데이터 주제영역을 설계하기 위해서는 먼저 모든 엔터티를 파악해야 한다. 모든 엔터티를 정의하면서 유사한 엔터티를 분류·그룹핑하는 과정을 거치면서 주제영역을 설계한다. [그림 3]은 일반적인 데이터 주제영역 설계 절차다.


[그림 4] 일반적인 데이터 주제영역 설계 절차(출처: dbguide.net)수행 프로젝트에서 분석 단계 초반에 주제영역을 설계해야 한다. [그림 4]와 같은 절차로 주제영역을 설 하기에는 기간이 너무 짧다. 분석 단계(3~4개월)를 온전히 주제영역 설계에만 할애한다면 가능할 수도 있지만, 분석단계에서 제출해야 여러 산출물을 고려할 때 일반적이 방법으로 주제영역을 설계하기란 쉽지 않다.

? EA·ISP 컨설팅 산출물 참고

어느 정도 규모가 되는 프로젝트는 개발 프로젝트 전에 EA(Enterprise Architecture) 컨설팅이나, ISP(Information Strategy Plan) 컨설팅을 한다. 컨설팅 업체에서 AA(Application Architecture), TA(Technical Architecture), DA(Data Architecture), BA(Business Architecture) 분야별로 TO-BE에 대한 큰 그림을 제시한 산출물을 만든다.

필자도 EA·ISP 컨설팅에 참여했지만 개발 프로젝트 조직에서 받아서 바로 쓸 수 있을 만한 수준으로 산출물을 만들기에는 기간과 인력이 턱없이 부족했다. 어찌 보면 너무 원칙 수준이기도 하고, 수박 겉 핥기식이기도 하지만, 해당 기업의 고민과 문제점, 나아갈 방향(TO-BE)을 컨설턴트들과 기업 핵심 인력이 머리를 맞대고 고민한 흔적은 엿볼 수는 있다.

따라서 EA·ISP 컨설팅 자료에서 AS-IS의 문제점과 TO-BE 방향성을 참고하도록 한다.

? TO-BE AA 기능 구조 참고

위에서 살펴봤지만, 실무 프로젝트에서는 데이터 주제영역을 데이터 성격 중심과 업무조직 중심을 적절히 조정해 주제영역을 정의한다. 일반적으로 애플리케이션 기능 구조는 업무조직에 맞춰 설계하므로 ‘업무조직’은 TO-BE AA(Application Architecture) 기능 구조를 참조한다.

? 동종업종 타사의 주제영역 참조

같은 업종에서 다루는 데이터는 유사하다. 마이너 데이터는 다소 다를 수 있지만, 데이터 주제영역을 분류에 사용되는 메인 데이터는 유사하다. 따라서 동종 업종의 타사 주제영역을 참조한다.

? 현행 데이터 구조 분석

현행 데이터에 대한 구조 분석은 TO-BE 데이터 주제영역을 설계하는 데 가장 중요한 활동이다.

‘백문이 불여일견’이라고 남의 자료를 참고하더라도 내가 보고, 분석하고, 문제점을 파악하여 TO-BE 개선점을 도출한 것만큼 데이터 주제영역을 설계하는 데 중요한 인풋은 없다.


[그림 5] 실무 프로젝트에서 목표 주제영역 설계[그림 5]는 실무 프로젝트에서 목표 주제영역 설계 방법을 도식화한 것이다.

EA·ISP 자료, TO-BE 목표 AA 기능 구성, 타사 모델을 참고하고 현행 데이터 구조를 분석해 문제점과 개선방향을 확인한다. 이어서 해당 기업의 특성과 일반적인 주제영역 분류 원칙, 구성 방법을 적용해 TO-BE 목표 주제영역을 설계한다.

다음 연재에는 데이터 모델 요소 중 엔터티에 대해 알아보겠다. (다음 회에 계속)

?

?

출처 : 한국데이터산업진흥원

제공 : 데이터 전문가 지식포털 데이터온에어(dataonair.or.kr)