데이터 인사이트

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

최상운의 사선(死線)에서 (2회) : 현행 모델 분석 1 : DB 스키마 기반의 리버스 ERD 작성

작성자
관리자
작성일
2020-08-28 18:12
조회
1835

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

?

현행 모델을 분석하자(상)

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

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

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

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

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

프로젝트 투입 첫날이다. 원래는 2주 전에 시작했어야 하는 프로젝트가 고객사와 수행사 간 기술 협상이 늦어 지면서 2주 늦게 시작했다. 2주 늦게 시작했지만 프로젝트 오픈 일자는 변동이 없다. 이 말은 기술협상으로 지연된 2주를 어떻게 하든 공정을 앞당겨 2주만큼의 시간을 보충해야 한다는 것이다.

?

? 함께 일할 사람이 누구인지 확인한다

첫날이라서 그런지 어수선하다. 자리는 배정됐지만 IP 할당이 아직 안 된 자리도 있어 기본적인 PC 세팅조차 하지 못 하는 사람들도 있다.

PC 세팅을 완료한 후 우선 프로젝트 조직도를 찾아보았다. 프로젝트 조직도에는 조직체계와 업무별 고객사와 수행사 담당자가 명시돼 있어, 내가 어떻 사람과 함께 일해야 하는지 확인할 수 있다. 파일서버 여기 저기를 뒤져 드디어 제안서에 포함된 조직도를 찾을 수 있었다. 그런데 조직체계는 어느정도 나와 있었지만 내가 맡은 데이터 모델링팀의 고객사 담당자가 아직 TBD(To Be Defined, 문서 작성 시점에는 확정할 수 없어 나중에 확정한다’는 의미) 상태다. 데이터 모델링팀뿐 아니라 각 업무팀의 고객사 및 수행사 TL(Team Leader) 상당 수도 TBD로 돼 있어서 내가 어떤 사람과 함께 일해야 할지도 알 수 없다. 프로젝트 사업관리팀에 문의해 보니 2주 후에나 완성된 조직도가 나온다고 한다. 그럼 2주 동안 그냥 앉아 있어야 할까?

프로젝트가 시작되면 기술지원 관련 팀(인프라팀, 아키텍처팀, 표준화팀, 데이터 모델링팀 등)은 바쁘다. 개발하기 위해서는 애플리케이션 서버, DB 서버, MCI(Multi Channel Interface) 서버, 프레임워크 서버 등이 준비돼 있어야 한다. 코딩하기 위한 소프트웨어 환경이 만들어져 있어야 하고, 각종 개발 표준이 개발 전에 마련돼 있어야 한다. 그래서 기술지원팀은 프로젝트 시작과 함께 야근과 주말 근무가 많다.

조직도가 완성되기를 기다릴 시간이 없다. 이때 정신을 차리지 않으면 금쪽같은 2주가 금방 흘러가게 될 판이다. 우선 수행사 프로젝트 매니저(PL)를 통해 업무별로 모델 담당자와 연락처를 조사해 달라고 회신을 돌렸다. 이번 주까지 고객사 모델 담당자를 확정해 달라고 고객사 PM을 통해 공식 요청했다.


[그림 1] 업무별 고객사·수행사 담당자 확인 양식
?

?

세상일이 다 그렇지만 나 혼자 할 수 있은 건 그리 많지 않다. 특히 최대 300~400명이 동시에 일을 하는 대형 SI 프로젝트에서 이해 당사자간의 협업이 필수적이다.

데이터 모델은 나 혼자 하루 종일 컴퓨터 앞에 있다고 해서 작성할 수 있는 것이 아니다. 프로젝트 초기에 업무(비즈니스)와 업무에서 다루는 데이터를 가장 많이 아는 사람은 고객사 담당자다. 그리고 내가 작성한 모델을 가장 많이 보고 활용하는 사람은 업무팀 개발자다. 모든 스트레스는 인간관계에서 비롯된다고 하여 웬만하면 새로운 인간관계를 맺기를 꺼리는 요즘이지만, 프로젝트 초반에 나와 함께 일할 사람을 파악하고 프로젝트 기간 동안 이들을 친구로 만들면 ‘베스트’다. 베스트에 이르지 못하더라도 최소한 원수 사이가 되지 않도록 서로 존중하며 협업할 수 있어야 한다.

?

? 언제 어떤 일을 해야 할지를 계획한다

WBS(Work Breakdown Structure)는 말 그대로 일을 쪼개 놓은 구조로서 일종의 해야 할 일의 리스트다. WBS에는 어떤 일(Activity와 Task)을 언제부터 언제까지 누가 할 것이며 이때 필요한 자원(장비, 사무실 등)이 무엇인지 기술돼 있다. 각 일(Task)간 선후행 관계가 나와 있다. 또 각 일(Task)이 종료되면 어떤 결과물이 나와야 하는지 기술돼 있다.

프로젝트 관리(Project Management) 관점에 측정할 수 없는 것은 관리할 수 없으므로 프로젝트의 모든 일은 측정 가능해야 한다. 일의 시작이 있으면 끝이 있어야 한다. 그 기간이 길면 관리와 측정이 어려워지므로 최대 2주를 넘지 않도록 일정을 계획한다. 짧게는 1년 길게는 2~3년이 걸리는 SI 프로젝트에서 계획을 세우는 것은 매우 중요 하다.


[그림 2] WBS의 예
?


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

데이터 모델링의 경우 일반적으로 [그림 3]과 같이 주요 태스크들이 있으므로 각 태스크의 일정을 잡으면 된다. 하지만 WBS에서 개발팀의 분석·설계·개발 일정과 다르면 문제가 되므로 개발팀의 일정 확인은 필수적이다. 업무별로 분석·설계·개발 일정이 동일한 프로젝트가 있고, 업무별로 일정이 제각각인 프로젝트가 있다. 여기서 점검할 포인트는 내가 맡은 업무의 데이터 모델링 일음주??직 현행 분석중이거나, 나는 야근과 주말 작업을 해서 논리모델까지 끝냈는데 개발팀은 아직 인력조차 투입되지 않았다면 그 간격으로 인한 손실이 크다. 따라서 내가 맡은 업무 개발팀의 WBS를 확인해 개발팀 일정에 맞춰 데이터 모델링 일정을 수립해야 한다.

?

? AS-IS 자료를 수집한다

우여곡절 끝에 고객사 담당자와 개발팀 담당자 명단을 확보했다. 오전에 첫 미팅을 진행 했다. 우선 고객사 담당자에게 ERD가 있어서 현행화 수준에 대해 문의했다. 돌아온 답변은 ‘ERD는 10년 전 프로젝트 때 작성된 것뿐이고 이를 현행화하지 않았다’였다. 다소 실망스러웠지만 대부분 프로젝트에서 겪었던 바라 차근차근 AS-IS 자료를 수집하기로 했다.

데이터 모델링 이론서들을 보면, 현업에서 사용하는 각종 양식 및 보고서, 시스템 관리 문서(운영 매뉴얼 등), 현업 사용자와의 인터뷰, 관련 서적, 데이터 흐름도(DFD, Data Flow Diagram), 전산 화면 등으로부터 엔티티와 속성을 도출할 수 있다고 나와 있다. 맞는 말이다. 하지만 SI 프로젝트에서 이런 자료들을 수집하고 분석할 시간이 넉넉하지 않고 효율적이지도 않다. 신규 사업 프로젝트를 진행하지 않는 이상, 대부분은 현재 운영하고 있는 전산시스템이 존재한다. 모델이 잘되고 안 되고를 떠나 현재 운영중인 전산 시스템만큼 확실한 AS-IS 자료는 없다. 고객사 담당자에게 현재 운영 DB에서 스키마 정보를 추출해 달라고 요청했다.

쿼리만 돌리면 간단히 얻을 수 있어 오후에 스키마 정보를 받았다. 메타 시스템에 등록된 테이블과 컬럼 정보와 비교해 최대한 테이블 한글명과 속성명을 엑셀 파일에 채워 넣었다. 그러지만 메타 시스템에 등록돼 있지 않는 테이블도 있고, 컬럼도 표준 용어를 사용하지 않는 것들도 있다. 메타 시스템에 등록된 테이블 정의는 테이블 한글명에 조사만 붙인 수준이었다. 해당 테이블이 어떤 데이터를 관리하고 어떻게 사용하는지 분석하기 힘들다. 사용하는 것인지 아닌지도 알 수 없는 테이블도 있다.


[그림 4] AS-IS 테이블 조사 양식
[그림 4]와 같이 AS-IS 테이블에 대한 테이블 한글명, 테이블 설명, 사용 여부, 고객사 담당자, 개발팀 담당자 항목을 채워 달라고 고객사에게 요청했다.

이 자료는 데이터 모델링 대상이 되는 AS-IS 테이블 목록으로 활용할 것이며, TO-BE 테이블과 매핑해 AS-IS 테이블이 TO-BE 데이터 모델에서 누락됐는지 여부와 정량적인 데이터 모델링 진척율을 측정하는 데 활용된다.

?

? AS-IS 리버스 ERD를 작성한다

?

AS-IS 테이블 조사를 통해 데이터 모델링 대상 테이블이 식별됐다. 엑셀 파일은 대량 작업을 하는 데는 유용하지만 어떤 테이블이 있고, 테이블에는 어떤 컬럼이 있고, 컬럼의 데이터 타입 길이와 널(Null) 옵션 등을 한눈에 파악하기에는 불편하다. 특히 테이블 간에 관계를 전혀 파악할 수 없는 자료 형식이다. 데이터 모델러에게는 ERD(Entity Relationship Diagram)가 테이블이 관리하는 정보와 테이블 간 참조 관계 등을 파악하는 데 가장 친숙한 자료 형식이다.

데이터 모델링 프로그램 자체적으로 엑셀 자료를 ERD로 전환해 주는 기능을 이용하거나, 제3자가 플러그인 방식으로 별도 프로그램으로 ERD로 전환해 주는 기능을 이용해 AS-IS 리버스 ERD를 작성한다.

[그림 5] ERwin Add-In으로 ERD 리버스
?


[그림 6] DA#으로 ERD 리버스
?

AS-IS 리버스 ERD를 작성함에 있어 팁은 AS-IS 테이블 정보와 AS-IS 컬럼 정보를 ERD 안에 포함하는 것이다.

일반적으로 SI 프로젝트에서 중요한 20% 테이블이 1:N, N:1 또는 N:N으로 통합·분리·수정 등이 발생해 복잡한 매핑이 필요하다. 하지만 나머지 80% 테이블은 단순 컬럼 추가/삭제만 발생해 단순 1:1로 매핑된다. 따라서 AS-IS 테이블 정보와 컬럼 정보를 포함해 ERD를 작성하고, 이 ERD를 기반으로 TO-BE 모델링을 한다면 데이터 표준 적용으로 인한 엔티티·테이블명 변경이나 속성·컬럼명이 변경되더라도 AS-IS 정보 추적이 가능하다. 따라서 향후 데이터 이관(이행)을 위한 테이블 및 컬럼 매핑 정의서 산출물 작성 시 80% 테이블은 데이터 모델링 프로그램에서 제공하는 엑셀 포맷으로 변환기능을 이용해 쉽고 간편하고 빠르게 산출물을 작성할 수 있다.

AS-IS 정보는 엔티티 및 속성 UDP(User Defined Property)를 만들고 이 곳에 AS-IS 정보를 입력 하도록 한다. 또한 데이터 모델링 프로그램에 따라서는 엑셀 문서 양식을 이용해 일괄 입력할 수 있는 기능을 제공하기도 한다.


[그림 7] AS-IS 테이블 및 컬럼정보 포맷을 데이터 모델링 프로그램에 삽입한 예

? 리버스 ERD 분석

현행 DB 스키마 정보로부터 리버스 ERD를 작성했다. 다음 연재에서는 이번회의 하편으로서 무엇을 어떻게 분석할 것인지 설명하겠다. (끝)

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

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