데이터이야기
DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.
대형 SI 프로젝트의 데이터 모델링 문제점을 재고해 보기! - 첫 번째 회사를 새로 설립하고, 새로운 프로젝트를 시작하느라 정신이 없는 몇 개월을 보낸 후, 이 가을에 다시 한번 조용히 대형 SI 프로젝트의 DA(Data Architecture) 분야에서 발견할 수 있는 문제점을 재고해 본다. 이러한 감리의 보고에 필자가 고객 관리자에게 문제가 없다고 소명하는데 들어간 시간은 무려 3 ~ 4일이나 되었다. 왜냐하면 이 보고를 받은 최고 관리자에게 까지 소명을 해야 했으므로!대형 SI 프로젝트의 데이터 모델링 문제점을 재고해 보기! - 첫 번째
현업의 불참 또는 부분 참여
수많은 대형 SI 프로젝트가 최종 오픈 일자에 제대로 시스템을 가동하는 것을 보는 것이 매우 드문 현상이라는 것을 알만한 사람들은 다 알 것이다. 물론 이렇게 된 이유는 수많은 원인이 있겠지만 본 장에서는 데이터 모델링 관점에 한정해서 논리를 전개해 보기로 하겠다.
고품질 데이터 모델의 일반적 특징을 보면 첫 번째는 업무 계획, 정책 및 전략의 형상화이고, 두 번째는 업무 영역 전문가의 참여, 세 번째는 프로젝트 요원의 확보를 얘기하고 있다. 이러한 얘기는 무엇을 의미하는 것일까
논리 데이터 모델링이란 데이터베이스 설계를 위한 입력물로 업무에서 발생하는 정보의 구조와 규칙을 명확하게 표현하기 위한 기법이다. (Logical data modeling is a technique for clearly representing business information structures and rules as input to the database design process.)
Handbook of Relational Database Design - 1989
Candace C. Fleming & Barbara von halle
필자는 논리 데이터 모델링에서의 가장 중요한 점은 현업의 업무를 이해하고 어떻게 업무에서 발생하는 업무 규칙을 논리 데이터 모델에 반영하여 프로젝트와 관련된 사람들과 함께 공유하느냐가 중요한지를 끊임없이 얘기하는 사람이다. 하지만 대형 SI 업체들이 진행하는 프로젝트에서는 극단적인 경우에 있어서 논리 데이터 모델링을 진행하는 과정에 업무 전문가를 아예 참여시키지 않는 다거나 참여하더라도 매우 미온적인 태도로 참여하는 경우가 다반사인 것이 현실이다.
대부분의 대형 프로젝트에서 본 프로젝트를 진행하기 전에 대부분 ISP(Information Strategic Planning: 정보 전략 계획), BPR(Business Process Re-engineering) 또는 PI(Process Innovation)라는 이름으로 사전 프로젝트를 진행한다.
이러한 프로젝트에서 BA(Business Architecture) 컨설턴트와 현업의 업무 전문가들이 프로세스와 업무 목표, 전략, 업무 이슈 및 개선 사항 등을 파악하여 업무를 정리한다. 업무 영역별로 꽤 많은(10 ~ 20명) 컨설턴트와 현업 업무 전문가가 투입되어 업무를 정리한다.
그리고 나서 본 프로젝트가 진행될 때는 대형 SI 업체들이 개발 논리에 맞춰 AA(Application Architecture)의 전문가들에게 화면 및 응용 프로그램 설계를 위하여 현업 업무 전문가를 프로그램 분석, 설계자들과 팀을 이뤄 프로젝트를 진행하게 구성하는 것이 일반적이다. 이번에는 더 많은 AA 담당자와 현업 담당자가 세밀하게 분석, 설계를 진행한다.
이러한 경우에 데이터 모델러에게 업무를 파악할 팀(업무 전문가 + 운영 담당자)과 시간은 할애되지 않는 경우가 다반사인 것이다.
대부분의 프로젝트에서 데이터 및 정보가 중요하고 데이터 모델이 중요하다는 것을 인식은 하고 있다. 하지만 고품질의 데이터 모델을 만들어 나가는 과정을 이해하고 있는 현업의 관리자나 SI 업체의 관리자는 매우 드물다. 이러다 보니 어떤 프로젝트에서는 DA 컨설턴트가 아예 TA(Technical Architecture) 밑에서 일하는 경우도 발생한다. 데이터 모델러는 업무를 파악하는 사람들인데 DBMS(Database Management System)를 관리하는 DBA(Database Administrator)와 동일 선상에서 DA 컨설턴트를 바라본다.
또한 DA 컨설턴트에게는 자기들이 사전 프로젝트와 AA 컨설턴트들이 업무를 다 파악했으니 문서를 보거나 AA 컨설턴트에게 업무를 듣고 모델링을 진행하라고 하며, 한 사람의 DA 컨설턴트에게 과도한 양(테이블 500개 이상)의 업무를 맡기는 것이 일상적이다. 여기에 더하여 DA 컨설팅 업체도 이러한 논리에 편승하여 맡겨만 주면 다 할 수 있다고 주장을 한다.
이렇게 프로젝트가 진행 되는 경우 다음에 일어나는 현상은 너무도 명확하다. 분석, 설계 단계에 어쩔 수 없이 업무 파악을 제대로 못하고, 개발 과정에서 데이터 모델을 형상관리란 이름으로 끊임없이 고치면서 데이터 모델이 바뀌니 프로그램 또한 끊임없이 바꾸면서 매일 매일을 보낸다.
SI 업체는 이런 와중에 데이터 모델이 무슨 문제가 있나를 고민하면서 대책을 세운다는 것이 감리 업체를 불러서 데이터 모델을 검증 받고, 모델에 문제가 있다는 것을 현업 관리자에게 보고하여 문제를 해결하려고 한다. 문제는 DA 컨설턴트들이 업무를 제대로 파악할 수 없는 시스템적인 문제인데도 불구하고, DA 컨설턴트 개인 또는 그 업체가 문제가 많다는 식으로 프로젝트의 문제를 해결하려고 한다.
업무를 잘 알지 못하는 감리 회사의 감리사들은 뭔가 지적해서 문제가 있다는 것을 보고해야 하므로 업무 파악은 제대로 하려고 하지 않고, 왜냐하면 그만한 시간과 돈을 지불하지 않으니, 교과서적인 지적만 하고 문제가 많은 것처럼 보고서를 작성한다.
예전에 손해보험회사 프로젝트에서 데이터 모델링을 진행한 적이 있는데 대형 SI업체에서 자사 직원을 구성하여 데이터 모델에 대한 감리를 진행한 적이 있었다. 보상 업무를 담당하고 있었는데 자동차 보험 보상과 장기, 일반 보험 보상은 합쳐서 두 가지 영역으로 모델을 생성하였다. 이 중 일반 보험 보상에는 외화가 있기 때문에 속성의 자릿수를 소수점 이하까지 선언하였고, 자동차 보험 보상에서는 원화만을 다루므로 소수점 이하가 필요 없었다. 그럼에도 불구하고 감리회사는 속성의 자릿수가 표준을 어기고 있다고 지적을 한 것이다. 화면에서도 자동차 보상은 원화만을 다루게 구성하였음에도 불구하고, 프로젝트 진행하는 사람들과 같은 회사에서 파견 나온 감리를 담당하는 사람간에도 업무에 대한 이해가 다르니 다른 얘기를 하고 있는 것이다.
우리는 학교를 다닐 때 누구나 다 영어를 배웠다. 그럼에도 불구하고 누구는 영어 문장을 해석하지도 못하고, 누구는 해석은 하는데 작문을 하지는 못하고, 누구는 해석과 작문은 하는데 말하기는 못하며, 누구는 이 세가지를 모두 한다.
필자는 항상 논리 데이터 모델이 업무 전문가와 응용 프로그램 분석, 설계, 개발자와 데이터 모델러가 현업의 업무에서 발생하는 정보의 구조와 규칙을 이해하기 위한 의사 소통 수단이라고 얘기한다.
비록 업무 전문가와 응용 프로그램 담당자가 논리 데이터 모델을 만들어 낼 수는 없더라도 논리 데이터 모델을 보고 업무를 이해할 정도는 되야 하는데 아예 논리 데이터 모델링 과정에 참여를 안 하면서 논리 데이터 모델이 고품질 이기를 바라는 것은 어불성설인 것이다. 마지막으로 Michael J. Hernandez 다음의 문장을 인용하면서 글을 마치기로 한다.
처음부터 명확하게 하고 싶은 것 한 가지는 설계 절차 완료의 중요성이다. 필자는 전체 설계 절차를 완전히 거치는 것이 꼭 필요한지에 대해서 종종 스스로에게 질문을 던지고는 한다. 그러나 대답은 항상 “예”이다. 또, 누군가가 단지 ‘단순한’ 데이터베이스를 만들고자 할 때도 자문을 해 본다.
(‘단순한’ 이란 것은 데이터베이스 개발자에게 알려진 것 중 가장 위험한 단어 중 하나다. 아무것도 ‘단순한’ 것은 없다). 필자의 대답은 여전히 “예, 그것은 역시 필요합니다”이다. 데이터베이스의 종류, 크기 또는 목적은 완전히 개발된 설계 작업의 가치와는 아주 독립적이다. 데이터베이스 설계 절차를 처음부터 끝까지 구현하고 따라야만 한다.
완전한 데이터베이스 설계 절차를 수행하지 않고 데이터베이스의 설계를 시도하는 것은 나쁜 생각이라는 것은 잘 알려지고 증명된 사실이다. 많은 데이터베이스 문제는 잘못된 데이터베이스 설계에 기인하며 설계 절차를 부분적으로 따르는 것은 그것을 전혀 따르지 않는 것만큼이나 나쁘다. 불완전한 설계는 잘못된 설계다. 완전하고 생략되지 않은 설계 절차를 따르는 것만이 정상적인 구조와 데이터 무결성을 보장한다.
자신의 데이터베이스의 구조적 무결성과 데이터 무결성의 수준은 얼마나 완전하게 설계 절차를 따랐느냐에 정비례한다는 것은 마음에 새겨두어야 할 중요한 사실이다. 설계 절차에 소비한 시간이 적을수록 데이터베이스에서 문제를 만날 위험은 커진다. 데이터베이스 설계 절차를 완전히 따르는 것이 비록 데이터베이스를 설계할 때 만날 수 있는 문제를 완전히 제거해 주지는 못하지만 그것을 최소화해 주는 데는 큰 도움이 된다. 자신의 RDBMS 프로그램으로 작업할 때 잘 설계된 데이터베이스는 잘못 설계 된 것보다 구현하기 쉽다는 것을 깨닫게 될 것이다.
데이터베이스는 설계하기 어렵지 않다. 단지 그것을 적절하게 설계하는데 시간이 좀 걸릴 뿐이다. 설계 절차에 너무 많은 시간이 걸리는 것처럼 보일 때에도, 지름길로 가지 말고, 인내심을 가지고, 오래 전 현인이 다음과 같이 말한 것을 기억하기 바란다.
‘There’s never time to do it right, but there’s always time to do it over!"
- Database Design for Mere Mortals - Michael J. Hernandez