[지디넷코리아]필자는 전문적으로 컨설팅을 하면서 특히 문제가 복잡하게 엉켜있어서 획기적인 해결사를 원하는 프로젝트를 주로 수행해 왔기 때문에 진행과정에서 방향을 잃고 표류하고 있는 프로젝트를 접할 기회가 아주 많았다.

물론 '슬로우 스타터(slow starter)'라는 말처럼 일정 시간이 지나야만 몸이 풀려 제기량을 발휘할 수 있는 경우도 있기 때문에 진행 초기에 발생하는 약간의 불협화음은 마치 신혼초기의 부부가 미묘한 헤게모니 쟁탈전을 벌리듯 얼마든지 있을 수 있는 일이다. 다만 그것이 일정기간을 넘지 않는 조정기간이어야 함에도 불구하고 계속해서 합의점을 찾지 못하고 있다면 프로젝트는 불협화음을 넘어 감정싸움으로 번질 것이며, 이 프로젝트의 미래는 불을 보듯이 분명해진다.

이런 상황에서 해결사로 투입돼 보면 이미 그들 간에는 같이 식사도 하러 가지 않는 서먹한 사이가 되어 있고, 서로 상대방 때문에 일이 꼬였다고 헐뜯고 있다. 필자는 최소한 '기술세계에서는 논쟁(argument)이란 없다'고 생각한다. 기술세계란 기분이나 감(feeling)으로 좌우되는 것이 아니라, 객관적이고 명백한 근거에 의해 좌우되기 때문에 동일한 '판단의 잣대'를 가지고 측정한다면 '결론'이라는 하나의 답이 있을 뿐이다.

바보가 아니라면 어느 누구도 아니라고 할 수 없는 지극히 상식적이고 분명한 판단의 잣대를 어떻게 공유할 것이냐가 문제다. 그것은 제각기 자기 주장만 하던 사람들이 '동일한 잣대'에 동의하는 순간부터 이제 같이 증거를 확인해 결론을 내는 일만 남아 있기 때문이다. 이러한 잣대는 그 누구도 거역할 수 없는 상식적인 논리를 근거로 해야만 공감을 얻을 수 있다. 상식을 부정하는 순간, 그 사람은 저절로 이미 바보가 된다.

만약 시스템 설계과정에서 불협화음이 계속되고 있다면 그것은 분명히 데이터 모델링이 원인이었을 가능성이 크다. 일반적으로 프로세스 모델링은 개발팀 별로 업무를 나누고, 개인별로 제각기 진행하면서 열심히 기록만 하고 있을 뿐이며 남들과 상호 연관성을 체계적으로 검증하지 않고 수행하기 때문에 설사 약간의 문제가 있다고 하더라도 표면으로 쉽게 드러나지 않는다.

만약 데이터 모델에 이상이 없고 프로세스에만 문제가 있다면 개발 단계에 가서도 해당 애플리케이션 개발자 자신에게 국한될 뿐이기 때문에 큰 문제로 부각되지는 않는다. 반면 데이터 모델은 특정 개발자 혼자만 사용하는 것이 아니라 여러 애플리케이션에서 같이 사용하는 것이며, 애플리케이션의 처리방법에 직접적인 영향을 주는 뼈대이기 때문에 이것이 명확하지 않고, 자꾸만 흔들린다면 문제는 금방 크게 불거진다.

이러한 문제는 한 차원 높은 기술력을 가진 모델링 리더의 지휘 하에 체계적이고 구체적인 모델링을 실시하지 않는 한 개발이 진행되어 감에 따라 계속적으로 증가한다. 아직도 개발해야 할 것은 첩첩 산중으로 남아 있는데 자꾸만 수정해야 할 것들이 발목을 잡고 있으니 어찌 프로젝트가 표류하지 않을 수 있겠는가!

이러한 현상은 시스템의 본질인 데이터를 대충 설계해 놓고 애플리케이션만 가지고 어떻게 해결해 보려고 하기 때문에 발생한다. 데이터는 여려 곳에서 같이 사용하는 공유물이기 때문에 어느 한쪽을 위해 근시안적으로 함부로 수정했다가는 경우에 따라 일파만파 문제가 발생할 수 있다. 만약에 이런 상황이 되었다면 이제라도 그 근본적인 원인인 데이터를 제대로 해결해야 함에도 불구하고 지금까지 억지로라도 고쳐 놓은 애플리케이션을 또 다시 고치기가 싫고, 어쩌면 전체를 내다보고 합리적인 데이터 모델링을 할 자신도 없기 때문에 계속해서 애플리케이션을 뜯어 고치는 악순환이 계속되어 프로젝트는 끝없는 혼란에 빠져들고, 개발은 지연되며, 온 몸은 만신창이가 되는 것이다.

이런 프로젝트의 해결책을 찾기 위해서 필자는 반드시 데이터 모델을 우선적으로 검증한다. 하지만 데이터 모델을 피상적으로 검증해서는 아무 것도 얻어 낼 수가 없다. 여러분들이 만약 셜록홈즈와 같이 예리한 눈을 가지고 있다면 조금만 분석해 보아도 그러한 문제가 발생한 원인을 바로 찾아낼 수가 있다. 물론 앞서 설명했던 데이터 아키텍처를 단계적으로 수립해 가면 저절로 문제점과 해결책이 모두 도출된다.

개발 중인 시스템의 데이터 아키텍처를 수립하기 위해서는 기존의 설계자료를 최대한 활용함으로써 시간을 절약해야 한다. 체계적인 방법론을 가지고 구체적으로 접근하면 비로소 현재의 문제점이 보이기 시작한다. 이것을 어떻게 개선하여야 할 것인지를 결정하는 방법은 앞서 설명했던 데이터 모델의 '논리화' 기법이다. 논리화를 표현하는 기법을 활용하면 물리적 모델(현재 설계되어 있는 데이터 모델)과 개선하고자 하는 논리적 형태(가상의 집합으로 표현되어 있는 모델)를 같이 그려 넣을 수가 있다. 이 두 가지 형태를 같이 표현했다는 것은 이미 기존의 데이터 모델과 애플리케이션들이 어떻게 수정되어야 하는지 보다 분명하게 나타냈다는 것을 의미한다.

표류하고 있는 프로젝트를 이러한 방법으로 해결하는 실사례가 있다. 몇 년 전 금융권의 어떤 업체에서 대형 차세대 시스템을 구축하고 있었다. 초기에는 패키지 도입 검토를 위해 거의 1년여를 허송 세월을 보냈고, 뒤늦게 자체 개발로 가닥을 잡아 설계부터 시작했으나 불협화음이 끊이지 않았다. 이미 시간을 많이 소비했기 때문에 마음은 조급했고, 조금이라도 빨리 하기 위해 서두르다 보니 서브시스템 별로 잘게 나누어 각자 자기 일에만 열심이었다.

모름지기 세상에 있는 모든 것은 각자 독립적으로만 존재하는 것이 아니라 서로 간에 미묘한 역학관계를 가지고 있으며, 물리적 혹은 논리적 종속 관계를 가지고 있기도 하다. 다시 말해서 같이 먼저 결정해 두어야 할 것이 있고, 이를 바탕으로 각자가 알아서 할 일이 있음에도 불구하고 무조건 나누어서 제각기 설계를 했다면 제대로 진행될 수 없는 것은 지극히 당연한 일이다. 이 와중에서 프로젝트 매니저는 책임을 지고 경질됐고 관리자들은 무조건 일정만 가지고 아우성을 하고 있었다. 물론 일정을 가지고 사람을 못살게 하니 시간이 되면 무언가 산출물이 나오기는 했다. 그러나 그 내용물의 품질은 장담할 수 없었다.

새로 부임한 프로젝트 매니저는 필자와 오랜 교분을 가지고 있던 사람이었다. 부탁을 받아 잠시 프로젝트의 진행 상태와 산출물을 분석해 보고 크게 놀라지 않을 수 없었다. 사실 이 프로젝트에는 이미 개발업체 외에도 프로젝트 관리를 위해서 세계적인 대형 컨설팅 업체와 전문 프로젝트 관리조직(PMO, Project Management Officer)을 운영하고 있었다는 것이 더욱 놀라웠다. 방법론적으로는 체계적인 관리를 하고 있는 것이 분명했지만 그 내부의 설계 내용은 기본조차 되어 있지 않았다. 관리자들이 밖으로 드러나는 겉모양만 관리했을 뿐이지 내용에 대해서는 모두 개발자들에게 맡겨 버렸기 때문이었다.

필자는 프로젝트 매니저에게 현재의 문제점은 데이터 모델에서부터 근본적으로 잘못되었기 때문이며, 지금까지 수행한 데이터 모델은 '이럴 수도 있다'는 정도의 추상적인 모습에 불과하다고 하였다. 만약 제대로 다시 모델링을 한다면 기존까지 애플리케이션으로 처리하던 수많은 규칙들까지 데이터로 도출할 수 있어 엔터티 수를 1/10로 줄일 수 있을 것이라고 충고했다. 그리고 급한 마음에 지금 이 데이터 모델로 프로세스를 설계하고, 개발까지 진행한다면 정말 큰 문제가 발생할 것이라고 경고했다.

결국 프로젝트 매니저는 필자의 의견을 받아들여 전면적으로 새롭게 데이터 모델링을 시작했다. 모델링의 상위 영역을 결정하기 위해 초기에는 대부분의 설계 관련자들을 모두 참석시켜 모델링을 진행했다. 개발자에 대한 모델링 교육을 병행하면서 학습 효과를 높이기 위해 시험도 치렀다. 처음에는 불만을 가진 사람도 있었지만 모델링이 진행되면서 그 동안 결정하지 못하고 방치됐던 많은 사항들이 우선순위에 따라 결정되고, 이 결정이 다시 다음 결정의 '상수값'의 역할을 하게됐다. 수없이 난무했던 '미지수'가 점차 사라지면서 많은 것이 가시화되기 시작했다.

4개월 만에 모든 데이터 설계가 완료됐다. 필자는 공식석상에서 프로젝트 매니저가 "어려웠던 시절에 혜성같이 나타나 우리를 구해 준 것에 정말 감사한다"고 했던 말을 잊을 수 없다. 얼핏 필자의 무용담을 이야기한 것 같아 쑥스럽기도 하지만 독자들이 필자의 경험담을 통해 실전 프로젝트에서 참고할 사항이 무엇인지 알았으면 한다. 문제가 복잡하게 엉켜 있는 상태를 그대로 두고 일정에 쫓겨 무조건 불도저처럼 밀고 나가는 것은 매우 위험하고 무서운 일이라는 것이다. @