데이터 인사이트

데이터 전문가 칼럼
데이터 전문가가 전하는 데이터 노하우

최상운의 사선(死線)에서 (6회) : 데이터 모델링에 들어가면서…데이터 모델이란?

작성자
관리자
작성일
2020-08-28 18:19
조회
73
 

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


데이터 모델링에 들어가면서…데이터 모델이란?

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

현장에서 전하는 데이터 모델링 이야기

필자는 수년간 시스템 통합(SI) 프로젝트에서 데이터 아키텍터, 데이터 모델러, PMO, 컨설턴트로서 역할을 했다. 그때마다 ‘왜 저렇게 데이터 모델링을 하지? 어떻게 하면 사람들이 데이터 모델 이론을 쉽게 익히고 베스트는 아니지만 모델에 업무를 표현하고 관련자에게 공유할 수 있도록 도와줄 수 있을까?’를 놓고 고민했다.

정답은 아니지만 데이터 모델링 과정을 이해하고 각 과정에서 해야 할 것과 점검할 것을 자료 형태로 정리하면 도움이 될 것 같아 조금씩 정리하고 있었다. 어렵고 복잡한 데이터 모델 이론은 배제하고 개발자 입장에서 접근 가능한 데이터 모델 이론을 소개하고, 실제 베스트와 워스트 데이터 모델 사례를 소개함으로써 '제대로 된 상당한 수준의 모델'보다는 '업무가 정확히 담겨 있고 모두가 이해할 수 있는 모델'을 작성할 수 있도록 하고 싶다는 생각에 감히 도전하게 되었다.

필자는 SI 프로젝트 현장에서 데이터 모델러로서 생사가 갈리는 전쟁터, 그 사선(死線)을 넘나들고 있다. 어떻게 하면 이 사선을 넘어 목표 지점에 도달할 수 있을까? 이 차원에서 다소 무겁지만 현장에서 겪는 문제점들을 먼저 알아보고, 나름대로 대책도 제시해 보고자 한다. 대책이 정답은 아니더라도, 모든 것을 해결할 수는 없더라도, 새롭고 획기적인 방법은 아니더라도 모델 다운 데이터 모델을 만들기 위한 방법을 생각했고 그것을 나누고자 이 글을 시작한다.
 

지금까지 현행모델분석을 어떻게 하는지 살펴보았다. 프로젝트가 시작되면 내가 만나야 할 사람, 나와 같이 일을 할 사람을 찾는다. WBS(Work Breakdown Structure)를 작성해 누가·언제·어떤 일을 해야 하는 지와 일의 선후관계를 계획한다.

• AS-IS 리버스 ERD로 현행 분석

현행 ERD와 테이블·컬럼 정보 등의 AS-IS 자료를 수집한다. ERD가 있다면 현행화 정도를 파악한 후 수집한 테이블·컬럼 정보와 비교한 후 추가·삭제·변경된 내용을 ERD에 반영한다. ERD가 존재하지 않거나 있더라도 현행화돼 있지 않다면 수집한 테이블·컬럼 정보로 AS-IS 리버스 ERD를 작성한다.

AS-IS 리버스 ERD에서 엔터티를 실체·주요·행위·목적 엔터티로 고객사 담당자와 함께 분류해, 80% 업무를 담당하고 있는 20% 엔터티에 해당하는 실체와 주요 엔터티를 파악한다. 우선 실체·주요 엔터티에 대한 정체를 정의(Definition)한다. 고객사 담당자와 함께 어떤 데이터를 관리하는지, 업무적 특성은 무엇인지, 사용 빈도는 어떻게 되는지, 관련된 엔터티는 어떤 것이 있는지, 당장 말해 줄 수 있는 중요한 속성은 무엇인지를 빠르게(Quick) 파악한다.

AS-IS 리버스 ERD로 현행 주 식별자가 유일성·최소성·안전성(불변성)·활용성·최소길이·고정길이·비암호화 원칙에 부합하는지를 분석한다. 식별자가 엔터티에서 관리하는 데이터를 대표하는지를 분석한다.

AS-IS 리버스 ERD에는 아직 관계선이 없는 상태다. 우선 실체·주요 엔터티를 대상으로 엔터티명 또는 테이블명에서 공통된 단어가 있으면 관련성이 있을 수 있다. 따라서 이런 엔터티들을 ERD에 모여 놓고 엔터티간 식별자↔식별자, 식별자↔일반속성 간을 비교해 임시로 관계를 도출한다. 정확한 관계비(Cardinality), 선택성(Optionality), 관계차수(Degree)는 향후 본격적인 데이터모델링 단계에서 파악한다.

AS-IS 리버스 ERD를 이용해 속성을 분석한다. 80% 업무를 담당하는 20% 엔터티만 하더라도 엔터티 개수에 비하면 속성 개수는 엄청 많으므로 모든 속성을 다 분석할 수 없다. 확실히 식별되는 것만 분석한다. 고객사 담당자의 도움을 받아 속성을 기본·관계·추출·시스템 속성으로 분류한다. 또한 미사용 속성을 식별하되 ERD에서 삭제하지 말고 속성 뒤에 (x)로 표시해 둔다. 추출 속성은 뒤에 (d)를, 관계 속성 뒤에 (r)을, 시스템 속성은 뒤에 (s) 등을 붙여 ERD에 표시해 둔다.

AS-IS 리버스 ERD로 엔터티·식별자·관계·속성 분석을 통해 파악된 문제점으로부터 개선 방향을 도출하고 이로부터 TO-BE 데이터모델링 원칙을 수립한다. 이제부터 본론으로 들어가보자.


[그림 1] 데이터 모델링 단계와 해야 할 일
 

[그림 1]을 기억하는가? 1회 연재에서 보았던 그림이다. 연재를 이 그림을 토대로 진행하고 있다. 이 그림에서 다음 단계는 개념 모델링이다.

대부분의 데이터 모델링 책에서는 데이터 모델을 개념 데이터 모델(Conceptual Data Model), 논리 데이터 모델(Logical Data Model), 물리 데이터 모델(Physical Data Model)로 분류하고 있다.

이런 분류가 전적으로 옳다. 각 모델은 의미와 활용 분야가 있다.

• 개념·논리·물리 모델을 구분할 시간이 없는 현장

하지만 사선(死線)과 같은 프로젝트 현장에서 짧은 기간 동안 개념·논리·물리 모델을 구분하면서 작성할 시간적 여유가 없다. 최대 300~400명이 투입되는 차세대급 프로젝트에서도 분석·설계 단계는 6~7개월 정도다. 이 기간 동안 교과서적으로 개념 모델 따로, 논리 모델 따로, 물리 모델 따로 작성하자고 주장하는 사람은 연구소로 가야할 사람이거나 프로젝트호를 산으로 향하게 하는 스파이로 몰릴 수 있다(?).

PMP(Project Management Professor)로서 저자가 확언하는데 프로젝트란 유일무이한 것을 만드는 것이다. 우리가 IT 프로젝트를 한다는 것은 세상에 없던 전산 시스템을 구축하는 일이다. 구축된 전산 시스템과 똑 같은 것은 다시는 만들 수 없다. 만일 똑 같은 시스템을 계속 만드는 일을 한다면 그건 프로젝트를 하는 것이 아니라 솔루션 패키지를 개발하는 것이다.

저자가 참여한 몇몇 프로젝트에서 프로젝트로 만든 시스템을 다른 동종 업체에 서비스하겠다고 모든 엔터티 첫 번째 식별자 속성으로 ‘회사구분코드’를 포함시켰다. 하지만 결국 ‘회사구분코드’ 에는 같은 값만 입력되고 그 시스템을 이용하는 동종 업체는 없었다. 동종 업체라 하더라도 개괄적인 업무 프로세스와 데이터는 비슷하지만, 세부적인 업무 프로세스와 데이터가 다르기 때문이다. 다른 프로젝트에서는 기존에 모든 엔터티에 있던 ‘그룹회사코드’를 제거하기도 했다.

IT 프로젝트에서 구축하려는 시스템은 이미 그 목적과 용도가 확정돼 있다. 이 목적과 용도에 맞게 모든 하드웨어, 소프트웨어, 데이터베이스, 네트워크, 프로세스를 구축한다. 따라서 IT 프로제트에서 데이터 모델은 개념·논리·물전 과정을 통해 상세화하고 구체화하는 것이다. 단지 관리적인 측면에서 데이터 모델을 개념·논리·물리 단계로 구분한다.

 

• 전사적 개념모델이 필요한 이유

필자 개인적으로 전사적인 개념 모델은 반드시 있어야 한다고 본다. 업무별로 작성된 개념 모델을 통합하면 기업에서 다루는 데이터 지형도가 된다.

고객과 미팅하러 고객사를 방문한다. 첫 방문 때는 주소만 알고 있다. 스마트폰에서 지도 앱을 켜서 찾아간다. 건물 로비에 도착한다. 층별 입주 업체 현황을 보여주는 안내판을 보고 고객사가 몇 층에 있는지 확인한다. 엘리베이터를 타고 해당 층으로 올라간다. 해당 층에 내렸더니 친절하게도 엘리베이터 옆 벽면에 해당 층 안내도에는 현재 위치까지 표시돼 있다. 현 위치에서 오른쪽으로 네 번째가 고객사 사무실임을 확인하고 발길을 옮긴다.

전사 개념 모델에는 우리 회사에서 어떤 데이터를 관리하고 있으며 데이터 간 관계가 있는지 표시돼 있다. 전사 개념 모델을 보면 내가 필요한 데이터가 있는지를 확인할 수 있고, 그 데이터를 획득하기 위해서는 어떤 업무(또는 주제영역)에서 확인해야 하는지 쉽게 알 수 있다. 좀더 자세하게 확인하려면 해당 업무(또는 주제영역) 논리 모델을 보면 된다.

이전 3·4회 연재 ‘리버스 ERD를 이용한 분석’에서는 모든 엔터티에 집중하지 않았다. 대신 80% 업무를 담당하고 있는 20% 엔터티에 집중했다. 이 20%에 해당하는 엔터티 에도 80대 20 법칙이 적용된다. 20%에서 다시 20%에 해당하는 엔터티와 식별자·관계·주요속성을 그려 놓은 게 개념모델이다.

은행을 예를 든다면 공통·고객·상품·여신·수신·외환·대행·회계 등의 업무가 있다. 800~900개 정도의 테이블이 있다. 전체 800개 테이블이 있다 하고, 이중 20%는 160개다. 160개 중 20%는 32개이다. 이 32개 엔터티에 대한 식별자·관계·주요속성만 그려져 있는 모델만 있어도 어떤 데이터를 관리하고 있으며 어떤 데이터를 어디서 찾아야 할지 한눈에 확인할 수 있다(관점에 따라서는 개괄모델이라도 할 수도 있다).

현장 프로젝트에서는 개념·논리·물리 모델을 정확히 구분하지는 않는다. 다만 프로젝트 관리적인 목적으로 분석 단계에는 논리 모델로 설계 단계에는 물리 모델로 호칭한다.

이론적으로 논리 모델과 물리 모델은 전혀 다른 모습이 될 수도 있다. 논리 모델은 논리적인 데이터와 관계를 표시하고, 물리 모델은 어떤 DBMS(Database Management System)를 사용하는지에 따라 달라진다. 예를 들어 파티션을 지원하지 않는 DBMS라면 논리 모델에서 1개 엔터티를 물리 모델에서는 파티션 키별로 여러 개 테이블로 분리해야 한다.

 

• 동시 다발적으로 진행되는 데이터 모델링

논리 모델에서는 두 개 엔터티로 분리했지만, 물리 모델에서는 두 테이블이 한꺼번에 조회되는 쿼리가 대다수라서 조회 성능 향상을 위해 한 개 테이블로 통합하기도 한다. 반대로 논리 모델에서는 한 개 엔터티인데, 물리 모델에서는 컬럼 수가 많고 자주 조회되는 컬럼과 자주 조회되지 않는 컬럼, 업데이트가 빈번한 컬럼과 그렇지 않는 컬럼 등을 분리해 각 테이블로 분리하기도 한다.

그런데 현장 프로젝트는 제안 단계부터 DBMS를 확정하고 프로젝트를 진행한다. 만일 프로젝트 중간에 DBMS를 교체하면 프로젝트 접어야 할 수도 있다. DBMS는 확정되었기 때문에 확정된 DBMS의 특성에 따라 논리 모델 단계부터 통합할지 분리할지를 결정한다. 또한 기존 데이터가 존재하므로 기존 데이터를 분석하면 논리 모델 단계부터 통합할지 분리할지 결정할 수 있다.

이렇듯 현장 프로젝트에서는 개념·논리·물리 모델 구분 없이 엔터티·식별자·관계·속성을 도출하고 표준화를 적용한다. 선정된 DBMS에 맞춰 엔터티를 분할/통합하며, 현재 데이터 양과 액세스 패턴을 고려해 상당한 역정규화를 동시에 진행한다.

[그림 1]의 개념모델링·논리모델링·물리모델링에서 해야 하는 것이 순차적이 아닌, 동시 다발적으로 진행된다. 이렇게 할 수밖에 없는 이유는 분석·설계 기간이 짧고, 전문 모델러가 투입되지 않기 때문이다.

개념·논리·물리 모델로 분리해 진행하기 위해서는 전문 모델러가 투입돼야 하는데 현장 프로젝트에서는 비용 문제로 전문 모델러 대신 개발팀의 설계자 중 경험이 많은 개발자가 데이터 모델링을 한다. 개발팀 입장에서는 빨리 개발해야 하기 때문에 모델링 원칙, 확장성, 유연성, 정규화와 표준화를 정확히 적용하지 않고 데이터 모델링을 진행한다. 그래서 속성이 200개가 넘는 엔터티, 식별자가 없는 엔터티, 식별자 수가 10개가 넘는 엔터티, 관계 없는 ERD가 만들어 진다.

이 글은 전문 모델러가 아닌 일반 개발자가 '업무가 정확히 담겨 있고 모두가 이해할 수 있는 모델'을 만들 수 있게 하기 위함이다. 따라서 편의상 개념·논리·물리를 하나로 묶어 엔터티·식별자·관계·속성에 대한 꼭 알아야하는 모델링 이론과 팁을 설명한다.

또 데이터 모델링을 하면서 반드시 알아야 하는 데이터 표준화(단어, 용어, 도메인)와 공통 데이터 모델링을 하기 위한 모델링 표준에 대해 설명한다. 더불어 작성한 데이터 모델에 대한 품질을 점검하는 방법에 대해 설명한다.

 

• 데이터 모델이란?

데이터 모델의 사전적 정의는 다음과 같다.
데이터 모델링은 기업 등의 조직에서 관리할 데이터 집합을 찾아 정의하고, 정의된 데이터 집합 간에 존재하는 업무 규칙과 데이터를 구성하는 세부 항목을 정해진 표기법(Notation)을 이용해 모형으로 시각화하는 과정이며, 이 과정의 산출물이 데이터 모델(Data Model)이다.
‘데이터 집합’은 엔터티이며, ‘업무 규칙’은 관계이며, ‘세부 항목’은 속성이며, ‘시각화하는 과정’은 개념·논리·물리 모델링이다.


[그림 2] 데이터 모델 요소
 

일상에서 모델(Model)이라면 패션 모델 또는 모델 하우스, 자동차 모터 쇼를 연상하게 된다. 패션 모델은 디자이너가 옷과 모자, 핸드백, 액세서리를 생산에 앞서 전문 훈련을 받은 패션 모델을 통해 선보임으로써 일반인이 ‘내가 저 옷, 모자, 핸드백, 액세서리를 착용하면 저렇게 되겠구나’ 하는 생각을 불러일으킨다.


[그림 3] 아파트 모델 하우스 조감도와 평면도
 

모델 하우스는 아직 아파트가 실재하지는 않지만, 어떤 모습과 환경으로 시공사가 아파트를 건설할 것인가에 대한 정보를 제공한다.

자동차 모터 쇼에서도 자동차 제조사가 콘셉트카를 선보여 미래의 자동차에 적용되는 기술과 디자인을 예측하도록 한다.

이와 같이 모델이란 어떤 대상에 대한 쉽게 이해하고 파악할 수 있는 정보를 제공한다. 특히 데이터 모델은 현실세계에 대해 우리가 관심있어 하는 대상을 데이터베이스화하기 위한 개념적 도구다.

 

• 개념·논리·물리 모델과 추상화

현장 프로젝트에서는 개념·논리·물리 모델의 명확한 구??도 구분 없이 설명하기로는 했다. 하지만 각 모델에 대한 정의와 활용 방안은 알고 넘어가도록 하자.


[표 1] 개념 논리 물리 모델 설명
 

데이터 모델링에서 추상화라는 말이 자주 나온다. 추상화의 사전적 정의는 아래와 같다.
추상화는 컴퓨터 과학 분야에서 주어진 문제나 시스템의 복잡도를 단순화해 인식하기 쉽게 만드는 개념화 작업. 핵심 요소를 잘 파악해 필요 이상으로 상세, 복잡한 요소들을 결합하거나 단순화하고, 속성의 일부분만으로 주어진 대상을 간결하고 명확하게 표현한다. 복잡도를 관리하는 핵심 기술이라고 할 수 있다. (출처: IT용어사전)
알 듯 모를 듯한 정의다. 간단하게 설명하자면 추상화란 군더더기는 모두 빼고 대상이 갖고 있는 핵심만 표현함으로써 대상을 빠르고 직관적으로 인식하도록 하는 것이다.

[그림 5] 여러 가지 표지판
 


[그림 6] 추상화한 수도권 지하철 노선도
 

[그림 5]와 [그림 6]에서 보듯이 대상의 핵심만을 표현함으로써 대상을 더 명확히 이해하도록 한다. 데이터 모델에서 추상화란 현실 세계에서 다루는 데이터를 관련자들이 이해할 수 있도록 도식화하는 것이다.

데이터 모델이란 현실 세계에 존재하는 있는 유무형의 고객, 사원, 상품, 서비스, 계약, 계좌, 카드, 거래, 조치 등의 데이터를 모델, 주제영역, 엔터티, 식별자, 속성, 관계라는 데이터 모델 요소로 추상화해 관련자들이 이해할 수 있도록 도식화한 것이고, 그 과정이 데이터 모델링이다.

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

 

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

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