데이터 인사이트
데이터 전문가 칼럼
데이터 전문가가 전하는 데이터 노하우
최상운의 사선(死線)에서 (1회) : 업무가 정확히 담긴 데이터 모델을 위한 시작
작성자
관리자
작성일
2020-08-28 18:12
조회
824
?
?
프로젝트 킥오프와 동시에 개인당 400개 이상의 AS-IS 테이블을 할당 받았다. ERD는 10년 전 프로젝트 때 작성하고는 현행화가 돼 있지 않다. ERD는 엔티티간 관계를 표시한 것인데, 관계선은 띄엄띄엄 있고 대부분 엔티티는 관계선이 그려져 있지 않다. 식별자가 없는 엔티티도 상당 수 존재한다. 그나마 주요 업무 이외 업무는 10년 전에 작성한 ERD조차 없다.
10년 전 작성된 ERD로는 현행 분석을 할 수 없으니 고객에게 요청해 운영 DB에서 스키마 정보를 제공받았다. 그런데 프로젝트 초기에 고객사에서 제공한 대상 테이블 수보다 많은 테이블이 존재한다. 초기 제공된 테이블 목록과 운영 DB에서 조회한 테이블 목록을 비교해 보았다. 고객사에게 추가된 테이블들 중에서 어느 업무 테이블을 사용중인지 식별을 요청했다. 돌아온 답변은 ‘잘 모르겠다’였다.
잘 모를 수밖에 없는 사유는 다음처럼 많았다. △해당 업무를 담당한 지 몇 년밖에 되지 않았는데 이전 담당자로부터 그런 테이블에 대해 설명을 들은 것이 없다. △소스를 찾아보았는데 해당 테이블 사용 소스를 발견하지는 못했지만, 데이터가 계속 증가하고 있어 미사용 테이블로 확정 짓기가 어렵다. △백업·임시성 테이블이 확실하지만 괜히 미사용 테이블로 분류했다가 나중에 누군가 사용하는 것으로 확인되면 책임을 물을 수 있으니 TO-BE에도 그냥 그대로 있어야 한다.
고객사로부터 제공받은 운영 DB 스키마 중 테이블 코멘트에 테이블에 대한 한글명이나 설명이 없는 것이 대부분이다. 테이블명은 로마자 알파벳과 숫자의 조합으로 구성돼 있다. 해당 고객사 담당자에게 문의해 보아도 본인들이 자주 사용하는 테이블 이외에는 어떤 정보를 담고 있고, 어떻게 사용되는지 알지 못 한다고 한다. 결국 데이터 모델러들에게 주어진 자료는 뜻 모를 알파벳과 숫자일 뿐이다.
운영 DB 스키마에서 FK(Foreign Key Constraint, 이하 FK로 통일)를 추출했는데 예상대로 FK 정보가 없다. 예상은 했지만 그나마 10년 전에 ERD에 표현했던 FK마저 실제 운영 DB에는 생성하지 않았다. 운영 중 데이터 삭제·변경 시 처리가 까다롭고 번거롭고, FK를 생성하면 쿼리 속도가 느려진다는 속설 때문에 대부분 DB에 FK를 생성하지 않는다. FK 정보마저 없으니 엔티티와 엔티티 간, 즉 데이터 간 관련성을 어떻게 분석해야 할지 막막 해진다.
이전 프로젝트를 하면서 메타 데이터 시스템(Meta Data System, 이하 메타)이 도입됐다. 운영 DB 스키마에서 추출한 컬럼명과 메타에 등록된 표준용어의 영문 약어를 비교해 컬럼명에 대한 표준용어 및 정의를 조회해 보았다. 그런데 표준용어에 대한 정의(Definition, 설명)의 용어명과 똑같다. 글자 하나 다르지 않고 똑같다. 엔티티를 구성하는 속성들의 용도와 정의를 파악하면 엔티티의 정체를 파악할 수 있다. 하지만 용어명과 똑같은 정의로 어떻게 엔티티 정체를 파악할 수 있겠는가? 다시 한번 막막해지는 순간이다.
속성을 분석하기 위해 메타에서 표준용어를 검색하다가 이음동의(異音同意, 음은 다르나 뜻의 같은 것)나 동음이의(同音異義, 음은 같으나 뜻이 다른 것)에 대한 구분이 돼 있지 않음을 발견했다. 심지어 동음이의 용어에 대한 영문명 오류가 있는 것도 상당수 존재한다. 예를 들어 ‘수신금액’ 표준용어에서 ‘수신’(受信)은 Deposit, 즉 ‘금융 기관이 거래 관계에 있는 다른 금융 기관이나 고객으로부터 받는 신용’을 의미한다. 하지만 ‘수신’ 단어에 대한 영어 단어가 ‘Receive’로 돼 있고 영문 약어는 ‘RCV’로 돼 있다. ‘수신금액’ 영문 컬럼명은 ‘RCV_AMT’로 원래의 의미와 전혀 다른 뜻으로 돼 있다.
위 이야기는 필자가 이름만 대면 알 수 있는 대형 은행·보험·증권·신용카드사 SI 프로젝트에서 데이터 모델링을 수행하면서 겪었던 일반적인 이야기다.
10년이면 강산이 변한다고 했는데, 그동안 SI 프로젝트 현장의 상황은 그리 많이 바뀌지 않았다. 어디서부터 무엇이 잘못된 것일까? 그 이유를 개인적으로 분석해 보면 아래와 같다.
?
1. 데이터에 대한 인식 및 투자의 제자리 걸음
2000년대 초반 국내 대형 SI사가 EA(Enterprise Architecture)를 SI 프로젝트에 적용하면서 BA(Business Architecture), TA(Technical Architecture), AA(Application architecture)와 더불어 DA(Data Architecture)가 많은 관심을 받게 됐다.
데이터를 기업의 핵심 자산으로 인식하고 데이터를 관리·통제하기 위한 관리체계(조직, 기능, 프로세스 등)가 제시됐다. 데이터 관리체계 구축은 많은 시간과 전사 차원의 노력이 필요하고, 구축 이후에도 지속적인 관리와 투자가 따라야 한다. 그러나 SI 프로젝트 종료 후 DA를 전담하는 기업 인력과 조직의 역량이 부족했고, 단기간의 성과를 중시하다 보니 어렵게 마련된?? 여전히 데이터를 기업의 핵심 자산이 아닌 비즈니스를 수행하면서 발생하는 것 또는 비즈니스를 지원하는 도구로 생각한다. 단기 이익과 경영진이 관심 있어 하는 ADW(Analytics Data Warehouse), RDW(Realtime Data Warehouse), OLAP 등 BI(Business Intelligence)에 대한 투자는 지속적으로 이뤄지는 모습이다. 하지만 원천 데이터를 관리하는 투자는 제자리걸음이다. 빅데이터로 대표되는 비정형 데이터를 활용한 마케팅에는 관심과 투자를 하지만 정작 비즈니스의 중심인 정형 데이터에 대한 관심과 투자는 제자리걸음이다.
기업은 늘어나는 데이터의 유일성, 정합성, 무결성을 유지하기 위한 데이터 저장 구조의 고도화 및 전문 인력에 대한 투자보다는 성능 좋은 하드웨어로 대체하는 방법을 택한다. 이는 근본적인 해결책이 아닌 임시방편일 수 있다.
?
그런데 몇 년 전부터는 대형 SI 프로젝트에 투입돼도 데이터 모델링을 직접 수행한 경우보다는 개발팀에서 개발자가 데이터 모델링을 수행하고 전문 데이터 모델러는 가이드(Guide)와 개발자가 작성한 데이터 모델을 점검(Inspection)만 하는 경우가 많았다.
이런 현상은 최근 몇 년간 SI 수행사들이 적정 금액보다 낮은 금액으로 프로젝트를 수주하는 데서 기인한다. SI 수행사는 적정 금액보다 낮은 금액으로 프로젝트를 수행해야 하기 때문에 기간과 투입 인력을 줄이고, 변경을 최소화해야 적자 없이 끝낼 수 있다.
하드웨어와 사무실 임대료 등의 비용을 줄이는 데는 한계가 있으므로 인건비를 줄일 수밖에 없다. 인건비를 줄이기 위해 전문 데이터 모델러 수십 명이 직접 데이터 모델링을 수행하기보다는 개발자가 데이터 모델링을 수행하고 소수 전문 데이터 모델러가 가이드와 모델 점검을 하는 방법으로 인건비를 줄이려 한다.
그러나 이는 데이터 모델링에 대한 무지에서 비롯된 잘못된 방법이다. 물론 개발자 중에는 데이터 모델링 실력을 갖춘 개발자도 있다. 하지만 전문 데이터 모델러의 데이터를 바라보는 관점과 개발자가 데이터를 바라보는 관점에 차이가 크다. 전문 데이터 모델러는 전사 관점에서 데이터를 바라보고 데이터의 유일성, 무결성, 정합성 및 유연성이 보장될 수 있도록 모델을 작성한다.
반면 개발자는 해당 업무에서 사용하는 데이터만 바라보기 때문에 업무 간 데이터가 중복되기도 한다. 중복된 데이터의 정합성과 무결성을 애플리케이션으로 맞추는 것이 어려워서 시간이 지나면 데이터의 정합성과 무결성이 깨지게 된다. 단지 인건비를 줄이기 위해 비전문 인력이 데이터 모델링을 수행하도록 하는 것은 기업의 핵심 자산으로서 데이터의 품질을 떨어뜨리는 결과를 낳게 된다.
?
일반적으로 DB 관리를 맡고 있던 사원이 DA팀에 배치돼 SI 프로젝트 기간에 외부 전문가로부터 데이터 관리 시스템과 데이터 관리 체계에 대해 교육받고 실습을 한다. 1~2년의 SI 프로젝트 기간에 소수 몇 사람이 다양한 분야의 지식을 완벽하게 습득할 수는 없다. 지속적인 교육을 받아야 하고 필요하다면 해당 분야 전문가를 새로 고용해 SI 프로젝트 기간 중에 구축된 시스템과 체계를 유지하고 관리해야 한다.
하지만 현실은 업무량에 비해 DA팀 인원이 부족하고, 필요 지식을 갖추지 못한 상태에서 업무를 진행하다 보니 잘못된 처리를 하는 경우가 많다. 또 정책을 마련하고 이를 통제하기 위해서는 조직 내에서 영향력이 있어야 하는데, 대부분 기업에서 DA팀은 영향력을 갖고 있지 못한 거 같다. 이러다 보니 어렵게 구축된 정책과 표준이 흔들리게 되고, 하나둘 예외를 인정하다 보니 너무 많은 예외로 인해 표준이 모호하게 돼 버린다.
절차와 통제를 무시하게 돼 데이터 관리 시스템이 무용지물이 되는 경우도 많다. 예를 들면, 데이터 모델링의 경우 아래와 같은 절차와 통제를 받게 된다.
① 개발팀에서 ERD에 신규 엔티티를 추가하거나 기존 엔티티를 수정한다.
② 신규 속성이 있다면 메타에 신규 용어를 신청한다.
③ 신규 용어를 표준 담당자에게 승인받는다.
④ 신규 또는 수정된 엔티티가 포함된 ERD를 모델 리포지터리(ERwin 모델마트 또는 DA# Repository 등)에 등록한다.
⑤ 메타에 신규 또는 수정된 엔티티를 모델 리포지터리에서 불러내어 신규 또는 수정 요청한다.
⑥ 신규 또는 수정 요청한 엔티티를 데이터 모델 담당자에게 승인받는다.
⑦ 메타에 승인받은 엔티티에 대한 테이블 생성을 요청한다.
⑧ DBA는 메타에서 테이블 생성 요청 건을 기준으로 물리적 오류가 없는지 확인하고 문제가 없으면 DB에 테이블을 생성·수정한다.
간략하게 적어 보았지만 테이블 하나를 신규 작성 또는 수정하더라도 여러 단계를 거쳐야 하고 단계마다 담당자의 승인을 받아야 한다.
개발 일정이 빠듯한데 단계별로 문제없이 통과돼도 최소 2일이 소요된다. 이때 한 단계에서 반려라도 되면 그 만큼 개발 일정이 지연된다. 개발이 내일 까진데 정상적인 절차를 밝으면 일정에 맞춰 개발을 할 수 없어 팀장님 ‘빽으로’ 나중에 정식 절차를 밝을 거라고 하고 우선 DB에 테이블을 생성해 개발을 마친다.
하지만 개발 요청이 계속 들어와 ERD 반영을 차일피일 미루다 보면 잊게 되고, 이런 일이 반복되면 ERD는 현행화가 안 되고, 메타는 테이블에 대한 상세정보가 없고 DB와 형상이 맞지 않아 메타로서의 기능을 하지 못 하게 된다. DB에는 단순히 스키마 정보만 있으므로 테이블이 어떤 정보를 관리하고, 업무적으로 어떻게 처리되는지에 대한 설명이 없어 담당자가 바뀌면 프로그램 소스를 분석해야만 알 수 있게 된다.
‘제대로 된 상당한 수준의 모델’을 만들려면 데이터 모델러는 상당 기간의 학습을 통해 이론적 지식을 갖추어야 하고, 실전에서 모델링 경력을 쌓아야 하고, 해당 업무에 대한 지식이 있어야 하며, 관련자들을 리딩 할 수 있는 커뮤니케이션 스킬을 갖추어야 한다.
하지만 우리가 일하고 있는 현장에서는 ‘제대로 된 상당한 수준의 모델’보다는 ‘업무가 정확히 담겨 있고 모두가 이해할 수 있는 모델’이 필요하다. 꼭 데이터 모델 전문가가 아니더라도, 전문 지식이 없더라도 프로젝트 단계(분석·설계·개발·통합 테스트·이행)와 각 단계에서 습득해야 하는 지식, 해야 할 일, 점검 사항을 알면 최소한 프로젝트를 해본 사람이라면 ‘업무가 정확히 담겨 있고 모두가 이해할 수 있는 모델’을 작성할 수 있다고 생각한다.
아래 그림은 프로젝트 기관 동안 데이터 모델링 단계와 각 단계에서 해야 할 것을 정리한 것이다.
그림. 데이터 모델링 단계와 해야 할 일
?
출처 : 한국데이터산업진흥원
제공 : 데이터 전문가 지식포털 데이터온에어(dataonair.or.kr)
최상운의 사선(死線)에서 (1회)
업무가 정확히 담긴 데이터 모델을 위한 시작
?| [필자 소개]?
최상운은 2000년 중반부터 데이터 관련 직무를 수행하고 있다. 은행·보험·증권·신용카드사 프로젝트에서 데이터 아키텍트, 데이터 모델러, PMO(Project Management Officer)를 수행했고, ISP 컨설팅에 참여했다. 한국데이터산업진흥원(KDATA)에서 주최하는 ‘DA 설계 공모대전’에서 2018년에 대상을, 2016년에는 금상을 각각 수상했다. 복잡하고 어려운 모델이 아닌 ‘업무가 정확히 담겨 있고 모두가 이해할 수 있는 모델’을 만들기 위해 현장에서 땀 흘리고 있다. |
|
현장에서 전하는 데이터 모델링 이야기 필자는 수년간 시스템 통합(SI) 프로젝트에서 데이터 아키텍터, 데이터 모델러, PMO, 컨설턴트로서 역할을 했다. 그때마다 ‘왜 저렇게 데이터 모델링을 하지? 어떻게 하면 사람들이 데이터 모델 이론을 쉽게 익히고 베스트는 아니지만 모델에 업무를 표현하고 관련자에게 공유할 수 있도록 도와줄 수 있을까?’를 놓고 고민했다.정답은 아니지만 데이터 모델링 과정을 이해하고 각 과정에서 해야 할 것과 점검할 것을 자료 형태로 정리하면 도움이 될 것 같아 조금씩 정리하고 있었다. 어렵고 복잡한 데이터 모델 이론은 배제하고 개발자 입장에서 접근 가능한 데이터 모델 이론을 소개하고, 실제 베스트와 워스트 데이터 모델 사례를 소개함으로써 '제대로 된 상당한 수준의 모델'보다는 '업무가 정확히 담겨 있고 모두가 이해할 수 있는 모델'을 작성할 수 있도록 하고 싶다는 생각에 감히 도전하게 되었다. 필자는 SI 프로젝트 현장에서 데이터 모델러로서 생사가 갈리는 전쟁터, 그 사선(死線)을 넘나들고 있다. 어떻게 하면 이 사선을 넘어 목표 지점에 도달할 수 있을까? 이 차원에서 다소 무겁지만 현장에서 겪는 문제점들을 먼저 알아보고, 나름대로 대책도 제시해 보고자 한다. 대책이 정답은 아니더라도, 모든 것을 해결할 수는 없더라도, 새롭고 획기적인 방법은 아니더라도 모델 다운 데이터 모델을 만들기 위한 방법을 생각했고 그것을 나누고자 이 글을 시작한다. |
? 야근에 주말 근무까지
벌써 몇 주째 야근하고 있는지 모르겠다. 야근뿐 아니라 두 달째 주말 근무도 하고 있다. 프로젝트는 4개월 전에 킥오프했다. 지난달까지 분석 단계였고, 지금은 설계 단계다. 앞으로 3개월 뒤에는 개발 단계에 들어간다. 주위 개발팀들은 분석·설계 단계에는 야근을 하지 않는데, 우리 데이터 모델러들은 왜 이리 야근과 주말 근무를 자주 하는지…프로젝트 킥오프와 동시에 개인당 400개 이상의 AS-IS 테이블을 할당 받았다. ERD는 10년 전 프로젝트 때 작성하고는 현행화가 돼 있지 않다. ERD는 엔티티간 관계를 표시한 것인데, 관계선은 띄엄띄엄 있고 대부분 엔티티는 관계선이 그려져 있지 않다. 식별자가 없는 엔티티도 상당 수 존재한다. 그나마 주요 업무 이외 업무는 10년 전에 작성한 ERD조차 없다.
10년 전 작성된 ERD로는 현행 분석을 할 수 없으니 고객에게 요청해 운영 DB에서 스키마 정보를 제공받았다. 그런데 프로젝트 초기에 고객사에서 제공한 대상 테이블 수보다 많은 테이블이 존재한다. 초기 제공된 테이블 목록과 운영 DB에서 조회한 테이블 목록을 비교해 보았다. 고객사에게 추가된 테이블들 중에서 어느 업무 테이블을 사용중인지 식별을 요청했다. 돌아온 답변은 ‘잘 모르겠다’였다.
잘 모를 수밖에 없는 사유는 다음처럼 많았다. △해당 업무를 담당한 지 몇 년밖에 되지 않았는데 이전 담당자로부터 그런 테이블에 대해 설명을 들은 것이 없다. △소스를 찾아보았는데 해당 테이블 사용 소스를 발견하지는 못했지만, 데이터가 계속 증가하고 있어 미사용 테이블로 확정 짓기가 어렵다. △백업·임시성 테이블이 확실하지만 괜히 미사용 테이블로 분류했다가 나중에 누군가 사용하는 것으로 확인되면 책임을 물을 수 있으니 TO-BE에도 그냥 그대로 있어야 한다.
고객사로부터 제공받은 운영 DB 스키마 중 테이블 코멘트에 테이블에 대한 한글명이나 설명이 없는 것이 대부분이다. 테이블명은 로마자 알파벳과 숫자의 조합으로 구성돼 있다. 해당 고객사 담당자에게 문의해 보아도 본인들이 자주 사용하는 테이블 이외에는 어떤 정보를 담고 있고, 어떻게 사용되는지 알지 못 한다고 한다. 결국 데이터 모델러들에게 주어진 자료는 뜻 모를 알파벳과 숫자일 뿐이다.
운영 DB 스키마에서 FK(Foreign Key Constraint, 이하 FK로 통일)를 추출했는데 예상대로 FK 정보가 없다. 예상은 했지만 그나마 10년 전에 ERD에 표현했던 FK마저 실제 운영 DB에는 생성하지 않았다. 운영 중 데이터 삭제·변경 시 처리가 까다롭고 번거롭고, FK를 생성하면 쿼리 속도가 느려진다는 속설 때문에 대부분 DB에 FK를 생성하지 않는다. FK 정보마저 없으니 엔티티와 엔티티 간, 즉 데이터 간 관련성을 어떻게 분석해야 할지 막막 해진다.
이전 프로젝트를 하면서 메타 데이터 시스템(Meta Data System, 이하 메타)이 도입됐다. 운영 DB 스키마에서 추출한 컬럼명과 메타에 등록된 표준용어의 영문 약어를 비교해 컬럼명에 대한 표준용어 및 정의를 조회해 보았다. 그런데 표준용어에 대한 정의(Definition, 설명)의 용어명과 똑같다. 글자 하나 다르지 않고 똑같다. 엔티티를 구성하는 속성들의 용도와 정의를 파악하면 엔티티의 정체를 파악할 수 있다. 하지만 용어명과 똑같은 정의로 어떻게 엔티티 정체를 파악할 수 있겠는가? 다시 한번 막막해지는 순간이다.
속성을 분석하기 위해 메타에서 표준용어를 검색하다가 이음동의(異音同意, 음은 다르나 뜻의 같은 것)나 동음이의(同音異義, 음은 같으나 뜻이 다른 것)에 대한 구분이 돼 있지 않음을 발견했다. 심지어 동음이의 용어에 대한 영문명 오류가 있는 것도 상당수 존재한다. 예를 들어 ‘수신금액’ 표준용어에서 ‘수신’(受信)은 Deposit, 즉 ‘금융 기관이 거래 관계에 있는 다른 금융 기관이나 고객으로부터 받는 신용’을 의미한다. 하지만 ‘수신’ 단어에 대한 영어 단어가 ‘Receive’로 돼 있고 영문 약어는 ‘RCV’로 돼 있다. ‘수신금액’ 영문 컬럼명은 ‘RCV_AMT’로 원래의 의미와 전혀 다른 뜻으로 돼 있다.
위 이야기는 필자가 이름만 대면 알 수 있는 대형 은행·보험·증권·신용카드사 SI 프로젝트에서 데이터 모델링을 수행하면서 겪었던 일반적인 이야기다.
10년이면 강산이 변한다고 했는데, 그동안 SI 프로젝트 현장의 상황은 그리 많이 바뀌지 않았다. 어디서부터 무엇이 잘못된 것일까? 그 이유를 개인적으로 분석해 보면 아래와 같다.
?
1. 데이터에 대한 인식 및 투자의 제자리 걸음
2000년대 초반 국내 대형 SI사가 EA(Enterprise Architecture)를 SI 프로젝트에 적용하면서 BA(Business Architecture), TA(Technical Architecture), AA(Application architecture)와 더불어 DA(Data Architecture)가 많은 관심을 받게 됐다.
데이터를 기업의 핵심 자산으로 인식하고 데이터를 관리·통제하기 위한 관리체계(조직, 기능, 프로세스 등)가 제시됐다. 데이터 관리체계 구축은 많은 시간과 전사 차원의 노력이 필요하고, 구축 이후에도 지속적인 관리와 투자가 따라야 한다. 그러나 SI 프로젝트 종료 후 DA를 전담하는 기업 인력과 조직의 역량이 부족했고, 단기간의 성과를 중시하다 보니 어렵게 마련된?? 여전히 데이터를 기업의 핵심 자산이 아닌 비즈니스를 수행하면서 발생하는 것 또는 비즈니스를 지원하는 도구로 생각한다. 단기 이익과 경영진이 관심 있어 하는 ADW(Analytics Data Warehouse), RDW(Realtime Data Warehouse), OLAP 등 BI(Business Intelligence)에 대한 투자는 지속적으로 이뤄지는 모습이다. 하지만 원천 데이터를 관리하는 투자는 제자리걸음이다. 빅데이터로 대표되는 비정형 데이터를 활용한 마케팅에는 관심과 투자를 하지만 정작 비즈니스의 중심인 정형 데이터에 대한 관심과 투자는 제자리걸음이다.
기업은 늘어나는 데이터의 유일성, 정합성, 무결성을 유지하기 위한 데이터 저장 구조의 고도화 및 전문 인력에 대한 투자보다는 성능 좋은 하드웨어로 대체하는 방법을 택한다. 이는 근본적인 해결책이 아닌 임시방편일 수 있다.
?
2. 전문 데이터 관리인력 부족
필자가 데이터 모델러로서 일을 시작한 2000년도 중반만 하더라도 대형 SI 프로젝트에서는 개발팀과는 별도로 데이터 모델링 팀이 구성됐다. 전문 데이터 모델러가 데이터 현황을 분석해 문제점과 개선점을 도출해 TO-BE 데이터 표준화, 데이터 모델 표준 및 데이터 아키텍처 방향성을 수립했다. 또한 업무 데이터 모델링을 전문 데이터 모델러가 직접 수행했다.그런데 몇 년 전부터는 대형 SI 프로젝트에 투입돼도 데이터 모델링을 직접 수행한 경우보다는 개발팀에서 개발자가 데이터 모델링을 수행하고 전문 데이터 모델러는 가이드(Guide)와 개발자가 작성한 데이터 모델을 점검(Inspection)만 하는 경우가 많았다.
이런 현상은 최근 몇 년간 SI 수행사들이 적정 금액보다 낮은 금액으로 프로젝트를 수주하는 데서 기인한다. SI 수행사는 적정 금액보다 낮은 금액으로 프로젝트를 수행해야 하기 때문에 기간과 투입 인력을 줄이고, 변경을 최소화해야 적자 없이 끝낼 수 있다.
하드웨어와 사무실 임대료 등의 비용을 줄이는 데는 한계가 있으므로 인건비를 줄일 수밖에 없다. 인건비를 줄이기 위해 전문 데이터 모델러 수십 명이 직접 데이터 모델링을 수행하기보다는 개발자가 데이터 모델링을 수행하고 소수 전문 데이터 모델러가 가이드와 모델 점검을 하는 방법으로 인건비를 줄이려 한다.
그러나 이는 데이터 모델링에 대한 무지에서 비롯된 잘못된 방법이다. 물론 개발자 중에는 데이터 모델링 실력을 갖춘 개발자도 있다. 하지만 전문 데이터 모델러의 데이터를 바라보는 관점과 개발자가 데이터를 바라보는 관점에 차이가 크다. 전문 데이터 모델러는 전사 관점에서 데이터를 바라보고 데이터의 유일성, 무결성, 정합성 및 유연성이 보장될 수 있도록 모델을 작성한다.
반면 개발자는 해당 업무에서 사용하는 데이터만 바라보기 때문에 업무 간 데이터가 중복되기도 한다. 중복된 데이터의 정합성과 무결성을 애플리케이션으로 맞추는 것이 어려워서 시간이 지나면 데이터의 정합성과 무결성이 깨지게 된다. 단지 인건비를 줄이기 위해 비전문 인력이 데이터 모델링을 수행하도록 하는 것은 기업의 핵심 자산으로서 데이터의 품질을 떨어뜨리는 결과를 낳게 된다.
?
3. 데이터 관리 시스템 및 체계 관리의 미흡
SI 프로젝트가 끝나면 기업 조직 내에 DA(Data Architecture)팀을 구성해 SI 프로젝트 과정에서 구축된 데이터 관리 시스템(메타 데이터 시스템, 데이터 모델 리포지터리, ETL 툴 등)를 관리하고 데이터 관리체계(데이터 표준, 데이터 모델, 데이터 흐름·배포, 데이터 거버넌스 등)를 통제하는 역할을 맡게 된다.일반적으로 DB 관리를 맡고 있던 사원이 DA팀에 배치돼 SI 프로젝트 기간에 외부 전문가로부터 데이터 관리 시스템과 데이터 관리 체계에 대해 교육받고 실습을 한다. 1~2년의 SI 프로젝트 기간에 소수 몇 사람이 다양한 분야의 지식을 완벽하게 습득할 수는 없다. 지속적인 교육을 받아야 하고 필요하다면 해당 분야 전문가를 새로 고용해 SI 프로젝트 기간 중에 구축된 시스템과 체계를 유지하고 관리해야 한다.
하지만 현실은 업무량에 비해 DA팀 인원이 부족하고, 필요 지식을 갖추지 못한 상태에서 업무를 진행하다 보니 잘못된 처리를 하는 경우가 많다. 또 정책을 마련하고 이를 통제하기 위해서는 조직 내에서 영향력이 있어야 하는데, 대부분 기업에서 DA팀은 영향력을 갖고 있지 못한 거 같다. 이러다 보니 어렵게 구축된 정책과 표준이 흔들리게 되고, 하나둘 예외를 인정하다 보니 너무 많은 예외로 인해 표준이 모호하게 돼 버린다.
절차와 통제를 무시하게 돼 데이터 관리 시스템이 무용지물이 되는 경우도 많다. 예를 들면, 데이터 모델링의 경우 아래와 같은 절차와 통제를 받게 된다.
① 개발팀에서 ERD에 신규 엔티티를 추가하거나 기존 엔티티를 수정한다.
② 신규 속성이 있다면 메타에 신규 용어를 신청한다.
③ 신규 용어를 표준 담당자에게 승인받는다.
④ 신규 또는 수정된 엔티티가 포함된 ERD를 모델 리포지터리(ERwin 모델마트 또는 DA# Repository 등)에 등록한다.
⑤ 메타에 신규 또는 수정된 엔티티를 모델 리포지터리에서 불러내어 신규 또는 수정 요청한다.
⑥ 신규 또는 수정 요청한 엔티티를 데이터 모델 담당자에게 승인받는다.
⑦ 메타에 승인받은 엔티티에 대한 테이블 생성을 요청한다.
⑧ DBA는 메타에서 테이블 생성 요청 건을 기준으로 물리적 오류가 없는지 확인하고 문제가 없으면 DB에 테이블을 생성·수정한다.
간략하게 적어 보았지만 테이블 하나를 신규 작성 또는 수정하더라도 여러 단계를 거쳐야 하고 단계마다 담당자의 승인을 받아야 한다.
개발 일정이 빠듯한데 단계별로 문제없이 통과돼도 최소 2일이 소요된다. 이때 한 단계에서 반려라도 되면 그 만큼 개발 일정이 지연된다. 개발이 내일 까진데 정상적인 절차를 밝으면 일정에 맞춰 개발을 할 수 없어 팀장님 ‘빽으로’ 나중에 정식 절차를 밝을 거라고 하고 우선 DB에 테이블을 생성해 개발을 마친다.
하지만 개발 요청이 계속 들어와 ERD 반영을 차일피일 미루다 보면 잊게 되고, 이런 일이 반복되면 ERD는 현행화가 안 되고, 메타는 테이블에 대한 상세정보가 없고 DB와 형상이 맞지 않아 메타로서의 기능을 하지 못 하게 된다. DB에는 단순히 스키마 정보만 있으므로 테이블이 어떤 정보를 관리하고, 업무적으로 어떻게 처리되는지에 대한 설명이 없어 담당자가 바뀌면 프로그램 소스를 분석해야만 알 수 있게 된다.
‘제대로 된 상당한 수준의 모델’을 만들려면 데이터 모델러는 상당 기간의 학습을 통해 이론적 지식을 갖추어야 하고, 실전에서 모델링 경력을 쌓아야 하고, 해당 업무에 대한 지식이 있어야 하며, 관련자들을 리딩 할 수 있는 커뮤니케이션 스킬을 갖추어야 한다.
하지만 우리가 일하고 있는 현장에서는 ‘제대로 된 상당한 수준의 모델’보다는 ‘업무가 정확히 담겨 있고 모두가 이해할 수 있는 모델’이 필요하다. 꼭 데이터 모델 전문가가 아니더라도, 전문 지식이 없더라도 프로젝트 단계(분석·설계·개발·통합 테스트·이행)와 각 단계에서 습득해야 하는 지식, 해야 할 일, 점검 사항을 알면 최소한 프로젝트를 해본 사람이라면 ‘업무가 정확히 담겨 있고 모두가 이해할 수 있는 모델’을 작성할 수 있다고 생각한다.
아래 그림은 프로젝트 기관 동안 데이터 모델링 단계와 각 단계에서 해야 할 것을 정리한 것이다.
그림. 데이터 모델링 단계와 해야 할 일
? ‘현행분석’부터 하나씩 풀어내기
다음 연재에서는 데이터 모델링 단계별로 무엇을 어떻게 해야 하며, 어떤 것을 점검해야 하며, 이를 위해 갖추어야 할 필요 지식이 무엇인지 하나씩 살펴보겠다. 먼저 ‘현행분석’을 주제로 찾아간다. 갓 프로젝트에 투입되면 수집해야 하는 자료와 어떻게 이 자료로 AS-IS 모델을 도출·분석해 문제점을 발견하고 TO-BE 방향성을 도출할 것인지, 이 과정에서 범하기 쉬운 실수를 알아보고, 도움이 될 만한 팁을 소개하고자 한다. (다음 회에 계속)?
출처 : 한국데이터산업진흥원
제공 : 데이터 전문가 지식포털 데이터온에어(dataonair.or.kr)