접근 방법 I (先 프로세스 모델링)

자료흐름도에 있는 데이터 저장소는 이러한 자료가 저장되어야 한다는 것을 의미하는 것일 뿐 반드시 이러한 모습으로 데이터 구조가 만들어져야 한다는 것을 나타낸 것은 아니다. 그러므로 이 데이터 저장소는 올바른 데이터 모델로 다시 태어나야만 한다.

이렇게 프로세스 모델링을 먼저 수행하는 방법은 현실적으로 가장 많이 적용하고 있다. 그 이유는 우리가 업무를 잘 모르는 상태에서 분석을 시작할 때 아무래도 상대적으로 익숙하고 지금까지 자주 사용해 온 자료흐름도 중심으로 시작하는 것이 보다 수월하기 때문일 것이다.

[img]

[그림1]

자료흐름도는 첫째, ‘추상적(abstractional)’으로 개념화 하기를 요구하고, 둘째 우리에게 익숙한 ‘흐름(flow)’을 가지고 있으며, 셋째, ‘단계적(leveling)’으로 서시히 접근하는 방법을 제시한다.

자료흐름도에서 단위 기능을 버블(bubble)로 그릴 때 구체적의 내용을 블랙박스에 넣어 버리고 크게 개념적으로으로 묶어 낸 추상화를 요구한다. 가령, ‘접수’라는 기능을 정의할 때 구체적으로 해야 할 내용은 생각할 필요없이 접수에 관련된 모든 행위를 모두 둘러싼 개념적 기능으로 정의하기를 바란다.

이처럼 아직 구체적인 내용을 파악하지 않은 우리에게 이러한 방법으로 접근하기를 요구하는 것은 확실히 부담이 적을 수밖에 없다. 이 방법은 앞으로 다음 단계에서 단계적으로 접근해 가면서 점차적인 상세화가 가능하므로 현 단계는 과감하게 개념적으로 접근하도록 허용하는 것이다.

두번째 특징인 ‘흐름’은 우리에게 매우 익숙해져 있는 사고 방법이다. 업무 지식이 부족한 상태에서는 역시 흐름을 알고 이해하는 것이 훨씬 쉽다. 모든 일에는 선후가 있고 앞뒤가 있는 법이다. 이 흐름을 따라가기 때문에 전문가가 아니더라도 보다 쉽게 접근할 수가 있다. 역으로 흐름을 제거한 상태에서 자신이 잘 알지 못하는 영역을 분석한다고 했을 때 과연 체계적으로 수행할 수 있는 사람이 얼마나 될 것인지 상상해 보라!

세번째 특징인 단계적으로 차례차례 접근해 간다는 것 또한 우리가 잘 모르는 업무를 매우 쉽게 접근해 갈 수 있도록 해 준다. 마치 단번에 암산으로 할 수 없는 복잡한 수학문제를 풀어 갈 때 이처럼 여러 단계에 걸쳐 점차적으로 진행해 감으로써 수월하게 결과에 도달할 수 있는 것과 같다.

이와 같은 장점이 있으므로 자료흐름도를 통해 업무를 분석하는 것은 확실한 전문가를 보유하고 있지 않더라도 충분히 가능하다. 자료흐름도가 완성되면 그 속에 있는 데이터 저장소를 가지고 데이터 모델링을 실시하면, 난이도의 입장에서 본다면 이 방법이 가장 좋은 방법이라고 할 수 있겠다.

아주 당연해 보이는 방법이지만, 필자는 이 방법을 쓰면 안 된다고 주장하는 사람이다. 왜냐 하면 바로 이 방법은 기능설계에 따라서 데이터모델링이 종속적이 된다는 데 문제가 있다. 기능이 데이터에 비해서 변화가 많이 발생한다는 것은 우리가 익히 알고 있는 사실이다. 현실의 업무란 마치 살아 움직이는 생명체와 같은 것이어서 시간이 지남에 따라 필연적으로 변화한다.

이처럼 변화할 수 밖에 없는 기능을 기반으로 데이터 구조가 결정된다면 마치 집을 지을 때 첫 입주자를 위해서 집을 지었다가 입주자를 바뀔 때마다 집을 다시 뜯어고쳐야 하는 것과 다르지 않다.

기능에 종속적으로 데이터 구조가 설계된다는 것은 변화에 취약하다는 것 뿐만 아니라, 데이터의 중복성과 일관성에도 큰 문제를 일으키고 이로 인해 응용 프로그램이 증가하고 유지.보수 비용도 덩달아 증가할 수 밖에 없다. 더욱 참을 수 없는 것은 이러한 원죄(?)로 인해 수 많은 개발자가 쏟은 막대한 시간과 노력이 미래 지향적인 곳에 사용되지 못하고 과거의 문제 해결을 위해 사용됨으로써 인간 능력에 좌우되는 정보시스템 분야의 발전을 저해하고 있다는 것이다.

이와 같이 이 방법은 접근하기는 용이하지만 변화의 대응이 힘들고, 많은 추가 비용이 발생하므로 절대로 찬성할 수 없는 방법이라 생각한다.

접근 방법 Ⅱ (동시 진행)

두 번째 방법은 두 가지를 병렬로 동시에 진행해 나가는 방법이다. 이 방법은 주로 대형 프로젝트에서 다수의 개발자들을 보유하고 있을 때 동시에 진행해 가지 않으면 도저히 개발 일정을 준수하기 어려울 때 적용하고 있는 방법이다.

필자가 접해 본 많은 프로젝트가 이 방법을 적용하고 있었는데 분명히 문제가 있었다. 그 이유는 이 방법을 적용하기 위해서는 부문별로 반드시 전문가를 확보하고 있거나 전체를 리드하고 자문할 수 있는 전문가가 있을 때만 적용할 수 있는 방법이기 때문이다.

[그림2]

데이터 모델링과 프로세스 모델링을 병행해 가는 방법에는 세가지가 있다. 첫번째는 데이터 모델링과 프로세스 모델링을 전체적으로 분할하여 진행하는 방법이고, 두번째는 데이터 모델링은 통합해서 실시하고 프로세스 모델링은 업무팀별로 나누어 수행하는 방법이며, 세번째는 여러 개의 업무팀별로 나누어 각자 자기부분의 업무를 모델링하는 것이다.

첫번째 방법은 주로 아웃소싱을 통해 외부의 데이터 모델링 전문가나 전문업체에 데이터 모델링을 주관하게 하고, 프로세스 모델링도 마찬가지로 외부 컨설팅을 받거나 특정 방법론(methodology)을 적용하는 방식으로 프로젝트를 진행할 때 적용하는 방법이다. 이 방법은 비용이 많이 소요되는 단점이 있으나 전문가들에 의해 설계가 추진되므로 품질과 생산성 향상에 매우 유리하다. 이 방법은 매우 난이도가 높은 시스템 개발이나 대용량의 데이터를 처리하는 대형 시스템에 적용하는 것이 바람직하며, 성공의 핵심 조건은 얼마나 신뢰할 수 있는 전문가를 확보하느냐에 달려 있을 것이다.

두번째 방법은 첫번째 방법과 매우 유사하지만 현실성을 감안하면 차이가 있다. 일반적으로 대형 SI업체가 투입된 프로젝트에는 프로세스 모델링에는 어느 정도 숙련된 전문가 수준의 설계자 그룹이 존재한다. 그러나 데이터 모델링은 상대적으로 이러한 전문적 기술을 가진 사람이 매우 드물다.

더구나 프로세스는 상황에 따라 변경이 발생해도 상대적으로 충격이 적지만 데이터 모델링은 건물의 골조와 같은 것이어서 그 충격이 매우 크다. 이러한 현실적인 상황을 감안한다면, 대형 프로젝트에서는 이 방법을 사용하는 것이 가장 최소의 비용으로 최대의 효과를 얻을 수 있는 방법이 될 것이다.

위의 두가지 방법은 모델링을 주관하는 전문가가 정말 믿을 수 있는 수준이라면 말 그대로 전문가이기 때문에 모델링 간의 상호 조화와 업무간의 조정을 충분히 감안하여 진행했을 것이므로 문제는 발생하지 않을 것이다.

세번째 방법은 전문가가 없는 상태에서 업무의 크게에 따라 여러 개발팀으로 분할해서 독자적으로 진행하는 방법이다. 사실 이방법은 대부분의 대형 프로젝트에서 적용하고 있는 방법이다. 필자는 문제가 발생한 수 많은 대형 프로젝트의 해결을 위해 오랜기간 컨설팅을 해 왔기 때문에 이 방법이 가지는 문제점을 누구보다도 많이, 누구보다도 구체적으로 보아 왔다.

굳이 ‘와그너의 격리설’을 들먹이지 않더라도 상호 조정없이 설계가 진행된 후 이를 결합해 보면 당연히 [그림2]의 우측 그림과 같이 서로 맞지 않는 부분이 발생할 것이라는 데는 이견(異見)의 여지가 없을 것이다.

이렇게 발생한 오차는 설계 단계부터 뿌리를 흔들어서 지금까지 피땀흘려 구축한 많은 부분들을 수정하게 만들고, 또한 이러한 수정 작업이 한두번에 끝나는 것이 아니라 프로젝트가 종료할 때까지 끝임없이 그 대가의 지불을 요구하게 된다.

실전에서 발생하는 이러한 문제점은 대부분의 경우 프로젝트기 70%정도 진행되어야 나타난다. 이것은 마치 우리가 병이들었을 때 그 고통을 감지하는 순간 이미 병은 2!3기로 진행된 다음인 것과 유사하다.

‘아픔’이라는 것은 빨리 감지가 되어야만 달라질 수 있다. 여러분들은 자신이 어떤 상처를 입었을 때 “조물주가 왜 고통이라는 것을 만들어서 나를 이렇게 아프게 할까?”라는 생각을 한번쯤은 해 보았을 것이다. 그러나 절대 그렇지 않다. 고통이야말로 나를 지켜주는 유일한 보호장치라고 생각해야 한다.

만약, 내가 뜨거운 불에 뜨거운 불에 손이 타고 있는데도 아무런 고통을 느끼지 못한다면 내 육신은 만신창이가 되어 있을 것이 분명하다. 고통이야말로 자신을 지켜 주는 - 유일한 내 생명을 지켜 주는 - 귀중한 센서인데 그 아픔이 없으면 미지근한 물을 서서히 데우면 삶켜 죽더라도 빠져 나오지 못하는 개구리와 다를 것이 없을 것임을 명심하기 바란다.

문제를 예방하기 위해서는 더 늦기 전에 고통을 미리 느끼게 해야 한다. 그래야만 더 큰 고통에 빠지지 않을 수 있다. 자기 부문만 바라보는 개발 방법은 필연적으로 이러한 고통을 느낄 수 없게 한다. 대형 프로젝트는 소형과는 본질적으로 다르다. 문제 발생의 데미지 또한 비할 바가 아니다. 앞서 언급한 적이 있듯이 멍청한 소대장 때문에 불쌍한 사병들을 고생시켜서는 안된다. 프로젝트를 총괄하는 매니져들은 자신이 무엇을 해야 하는지 곰곰히 생각해 보아야 할 것이다.

접근 방법 Ⅲ(先 데이터 모델링)

세 번째 방법은 데이터 모델링을 먼저 한 다음 그 결과를 이용해 기능을 설계하는 방법이다. 필자는 될 수 있는 한 이 방법으로 가야 한다고 주장하는 사람이다. 왜냐 하면 바로 이 방법이야 말로 가장 합리적으로 목적을 달성하는 지름길이라 믿기 때문이다.

데이터모델링은 앞에서도 언급했고, 앞으로도 상세한 설명이 있겠지만, 객관적이고, 구체적인 판단을 요구한다. 객관적이라는 말은 누가 보더라도 이해가 되고, 똑같은 결과가 나와야 한다는 것이며, 구체적이라는 말은 이러한 객관적인 결과를 매우 상세하게 정의하여야 한다는 것을 의미한다.

이와 같이 우리가 객관적인 사실을 구체적으로 확정해 왔다면 당연히 모델링에 참여한 사람들이 그 회사의 업무를 가장 종합적이고, 가장 상세하게, 가장 체계적으로 알고 있는 사람이 된다. 이것을 기반으로 프로세스 설계를 하는 것이 가장 사용자에게 유용한 기능을 제공할 수 있도록 하는 것이라고 믿어 의심치 않는다.

또한 데이터 모델링은 업무의 흐름에 영향을 받지 않도록 수행해 왔으므로 기능에 독립적이 된다. 이 말의 진정한 의미는 데이터 모델링의 결과를 가지고 어떠한 기능이라도 만들어 줄 수 있음을 뜻한다.

[그림3]

이렇게 데이터 모데링을 먼저 수행하는 방법은 프로세스를 모델링할 때 자료흐름도를 그리지 않아도 무방하다. 이미 업무를 구체적으로 객관화 시켜 왔기 때문에 굳이 자료흐름도를 작성하는 긴 사간을 소비할 필요가 없다. 그 대신 기능계층도(FHD)를 작성하는 것으로 간략화 해도 좋다.

물론 이러한 부분들은 여러분들이 사용하는 방법론에 따라 약간의 차이가 있을 것이며, 이 책은 전체 방법론을 다루는 것이 아니므로 프로세스 모델링에 관련한 구체적인 내용은 생략하기로 한다.

이 방법은 구축할 전체 시스템을 통일된 시각과 전략으로 접근하여 매우 구체적으로 객관화를 시켜왔으므로 다음에 바로 구축할 기능이나 앞으로 구축해야 할 기능까지 모두 만족한 이상적인 데이터 모델의 기반이 먼저 구축되도록 하였다. 기능이란 세워진 건물에 입주한 사람이 자신의 특성에 맞도록 집을 꾸미는 것과 유사하므로 얼마든지 상황에 맞춰 적절하게 진행시켜 갈 수 있다.

여러분은 어린 시절 초등학교 증축공사를 할 때 금년에 목표로 한 1층이 다 세워졌는 데도 옥상에 있는 철근들을 마무리 하지 않은 모습을 본 적이 있을 것이다. 그것은 예산 상의 이유로 금년에는 1층만 지었지만, 앞으로 학생이 늘어나거나, 예산이 확보되면 그 윗층도 지을 예정이기 때문이다. 금년에 1층 공사만 한다고 해서 이 건물의 설계도는 결코 단층용으로 설계되어 있지 않을 것이다. 앞으로 지을 층수를 감안해서 설계했을 것이 분명하며, 다음에 2층을 올리더라도 1층을 다시 세우는 일은 하지 않을 것이다.

이와 마찬가지로 데이터 모델이라는 설계도는 당장 기능을 개발하지 않는다고 해서 지금 개발할 것에만 국한된 설계를 하지는 않는다. [그림3]의 우측 그림과 같이 사정에 따라 금년에는 ‘기능1’만 개발하고, 내년에는 ‘기능2’,… 이렇게 개발해 가도 데이터 모델만 튼튼하게 되어 있다면 아무런 문제가 없을 것이다.

그러나 이 방법은 이상적인 모습을 하고 있지만 적용하는 것은 쉽지 않다. 그 이유는 반드시 전문 모델러를 확보해야만 가능한 방법이기 때문이다. 우리는 데이터 모델링에서 구체적인 객관화를 하라고 요구를 했다. 문제는 자신이 업무를 잘 알지 못하면서 과연 구체화, 객관화를 할 수 있겠느냐에 있다.

사실 업무를 파악하고 있을 때는 어느 정도 데이터 모델링을 할 수 있는 수준에 있는 사람은 일부 찾아 볼 수 있겠지만, 전혀 업무를 모르는 상태에서도 완벽한 모델링을 할 수 있는 사람은 결코 많이 있지 않다.

특히 우리나라 정보시스템 요원들의 대부분은 프로그래머 역할 위주로 경력을 쌓아 왔기 때문에 구조적으로 이미 모델링 전문가의 양산이 어려운 형태를 하고 있다. 그러나 이제는 정말 달라져야 한다. 더 이상 대형 건물을 초가삼간 짓듯이 자신이 설계하고 자신이 개발하는 자급자족(?)의 신석기 시대를 살아서는 안된다.

선진화 된 사회일수록 역할은 분담되어 전문화 되어 가는 것이며, 상위 수준의 일을 하는 사람들이 훨씬 융숭한 대접을 받게 된다. 멀지 않은 시일 내에 이런 세상은 반드시 올 것이다. 여러분들은 이제 그 준비를 하는 것이다. 인간만이 할 수 있는, 그리고 방법을 안다고 해서 할 수 있는 일이 아닌 그런 종합적이고 전략적인 사고 능력을 통해서만 할 수 있는 일을 해야 하지 않겠는가?

이 강좌가 여러분들이 그 길을 갈 수 있도록 도움을 줄 수 있을 것이라 확신한다. 그렇지만 지금까지 그래 왔듯이 단순히 이해를 하는데 만족해서는 아무 것도 얻을 수 없다. 서점에 나와 있는 바둑 책의 내용을 이해했다고 9단이 금방되는 것이 아니지 않는가? 자신의 것으로 완전히 소화하여 ‘자기의 수’를 둘 수 있는 수준까지 도달하는 각고의 노력이 있어야 비로소 가능한 것임을 명심하기 바란다.