엄청난 노력을 들였고 많은 고생을 했지만 개발은 자꾸만 지연되고, 새로운 문제들은 부도난 회사에 어음이 돌아오듯 막아도 막아도 끝없이 나타난다.
천신만고 끝에 문제점들이 봉합된 시스템은 그야말로 상처투성이가 되어 있고 이러한 시스템은 당연히유연성을 가지지 못하기 때문에 차후 유지보수에 많은 시간과 비용을 수반한다.
이러한 문제들을 미연에 방지하기 위한 프로젝트 성공요소를 든다면 다음 세 가지로 요약할 수 있겠다.
단순명료한 설계데이터 모델링은 모든 개발 과정에 지대한 영향을 미친다.
데이터 모델은 건축물의 설계도면과 같다. 전체적인 구조에서부터 아주작은 부분에 이르기까지 매우구체적이고 정확해야 한다.
데이터 모델은 평면도가 아닌 모든 부분이 구체적이고 정확하게 표시된 '청사진'이 되어야 한다.
그대로 따르면 모든 것이 조화를 이룰 수 있는 그런 모습의 ERD(Entity Relationship Diagram)가 그려져야 한다.
"ERD를 그릴 수 있는 사람은 많이 있지만 데이터를 모델링할수 있는 사람은 많지 않다"는 말이 있다.
데이터 모델링은 그림을 그려내는 '작도법'이 아니라 무에서 유를 찾아내는 '수사법'을 말한다.
복잡한 것을 복잡하게 만드는 것은 실력이 아니다. 복잡하게 엉켜져 있는 것을 단순하고 명료하게 만들 수 있는 것이 바로 실력이다. 이렇게 할 수 있는 것이 전문가이고, 프로젝트 성공의 1차 비결이다. 올바른 데이터 모델링을 하기 위해서는
첫째, "무엇을 어떻게 활용할 것인가?"를 명확히 하는 것이다. 데이터 모델링은 있는 그대로를 그려내는 '사실화'가 아니다.
장차 시스템이 구축되었을 때 우리가 원하는 본래의 목적이 달성될 수 있도록 하기 위해서 구체적인 목적과 전략을 명확히 해야 한다.
둘째 "정보의 단절을 어떻게 막을 것인가?"하는 문제를 해결해야 한다.
독립적으로 고유한 특성을 가지는실체(Entity)는 다른 실체들과 다양한 관계(Relationship)를 가진다. 물론 그 관계가 직접 관계가 아니라 다른 실체를 중간에 둔 간접관계일수도 있다.
전선이 끊어지면서 전류가 흐르지 않듯이 정보의 관계또한 그러하다.
관계의 선이 끊어지지 않도록 하려면 자식(Child)은 부모(Parent)에 필수적(Mandatory) 관계를 가지도록 하고 부모는 자식을 가지지 않을 수도 있는 선택적(Optional) 관계가 되도록 해야 한다. 그렇게 하기 위해 서는 가장 우선적으로 자기를 탄생시킨 주체, 개체의 의미상의 주어, 즉 친부모가 누구인지를 명확히 해야 한다.
즉, 새로운 개체는 누구에 의해서 무엇이 달라질 때 탄생하는 지에 대한 출생비밀을 풀어헤칠 수가 있어야 한다. 그래야 실체 집합이 명확해진다.
자신의 집합이 모호하면 자신이 탄생시킨 자식 실체들 또한 모호한 집합이 된다. 필자는 컨설팅한 대부분의 데이터 모델에는 얼굴마담에 불과한 인조키(Artificial Primary key)가 마치 자신이 주인인양 행세하고 있으면서 정작 진짜 주인이 누구인지 명확하지 않다.
생성된 데이터를 분석해 보면 군정시절 낙하산 인사 처럼 근원도 알 수 없이 일련번호만 증가하면서 마두 데이터는 탄생된다.
이러한 모호한 집합은 프로그램 에서 곡예를 하듯이 예외처리를 하여야 겨우 의미있는 정보로서 재생된다. 이러한 문제가 바로 정보를 단절시키는 가장 큰 이유라 하겠다.
셋째 "융통성과 통합성을 어떻게 유지할 것인가?"에 대한 해답을 찾아야 한다.
설계단계에서 아무리 우수한 설계자가 아무리 우수한 전문지식을 가지고 있는 사용자들과 협의하고 향후의 발전방향을 감안하여 데이터 모델을 확정했다 하더라도 머지 않아 업무규칙은 다시 변경될 수가 있다.
이러한 필연적인 변화에 유연하게 대처할 수 있는 데이터 모델은 개발단계보다 유지보수 비용을 훨씬 많이 투자해야 하는 우리의 현실을 감안해 보면 더욱 그 중요성이 강조된다.
유연한 데이터 모델을 만들기 위해 우리가 해야 할 가장 중요한 것은 실체의 집합을 어떻게 정의하느냐 에 있다. 우리가 매우 명확하다고 하는 집합도 한 단계 더 구체적으로 들어가 보면 매우 추상적으로 정의되어 있다. 가령 우리가 너무나 잘 알고 있고, 정확히 정
의되었다고 생각하는 '고객' 실체(Entity)에 대해 다음 물음에 답을 해보자. "우리의 고객은 사람마다 반드시 하나의 개체만을 가지는 집합인가?
아니면 한 사람이 경우에 따라 여러 개체가 될 수 있는 집합인가?", "우리의 고객은 사람만의 집합인가?
법인 혹은 기타 단체까지 포함된 집합인가?", "우리의 고객은 우리와 계약을 가진 개체들의 집합인가?
잠재고객까지 합친 개념인가?", "나는 사원인가? 고객인가?" 이외에도 아직 구체화되지 않은 정의는 훨씬 더 많이 있다. 과연 여러분들이 정의한 '고객' 집합은 명확한 집합이 라고 자신할 수 있는가?
넷째 "데이터베이스의 특성을 어떻게 반영할 것인가?"에 자신있는 답을할 수 있어야 한다.논리적 모델링만으로 프로젝트의 성공을 바랄 수는 없다.
특히 관계형 데이터베이스가 진정한 프로그래머 역할을 한다.
그러므로 데이터베이스의 특징에 순응할 수 있어야 많은 도움을 요구할수가 있다.
여기서 데이터베이스의 특징을 반영하라는 것은 많은 집계 테이블을 생성하거나 컬럼의 중복화를 해야 한다는 것은 결코 아니다. 요소기술 리더의 역할 관계형 데이터베이스는 우리가 어떤 테이블을 분리하느냐 통합하느냐, 혹은 어떤 컬럼을 하나로 하느냐 분리하느
냐와 같은 미묘한 문제에도 매우 큰 차이를 보일 수 있다. 데이터베이스의 깊은 곳을 알지 못한 채 시스템을 설계한다는 것은 축구공을 한번도 차보지 않은 사람이 감독을 하는 것과 다를 바 없다.
데이터베이스의 전문적인 기술은 블랙박스에 숨겨져 있기 때문에 오랜개발 경험을 가진 전문가들도 예상외로 깊은 지식을 가지기가 쉽지 않다는 것이 우리가 풀어야 할 숙제라 하겠다.
다섯째 "단순명료하면서도 수행속도를 보장받을 수 있는가"에 대한 문제 해결할 수 있어야 한다.
과거에 개발자가 직접 처리과정을 일일이 기술하던 방식에서는 일단 프로그램이 작성되면 대부분의 경우 어느 정도 수행속도는 보장받을 수가 있었다.
그러나 관계형 데이터베이스에서는 처리과정을 옵티마이져(Optimizer)가 생성해 주기 때문에 실행계획의 양호도에 따라 엄청난 수행속도의 차이를 가져오게 된다.
수행속도에 영향을 주는 요소는 매우 다양하고 복잡하며 겉으로 잘 나타나 있지 않으므로 대부분의 개발자는 이에 관한한 거의 문외한에 가깝다.
한정된 자원을 효율적으로 사용하지 못하면 애써 개발한 시스템에 과부하가 걸려 모든 것이 물거품이 될 수 있다.
이런 이유로 인해 대다수의 개발자들에게는 수행속도에 대한 과민반응이 일어난다. 그 결과 문제의 핵심에 접근하지 못하고 지나치게 많은 테이블을 생성하거나 컬럼의 중복화, 무수한 인덱스의 생성 등을 통하여 또 다른 문제를 야기시킨다.
정확한 원리와 적절한 활용방법을 알고 있다면 단순 명료하면서도 수행 속도를 낼 수 있는 방법은 얼마든지 있다.
바로 이것이 기술의 차이이며 성공의 비결이다. 모든 일에 있어서 복잡 다난해질수록 조직을 이끌어 가는 사람의 역할은 무엇보다 중요해진다.
특히 정보시스템은 100명이 1명의 일을 할 수 없는 일이 허다하게 있다.
정말 복잡하기 그지 없는 정보시스템에서는 특히 이러한 요소기술을 가진 리더의 역할이 무엇보다도 중요하다.
그러나 현실은 어떠한가? 경력이 오래된 사람은 많은데 전문가를 찾아보기도 정말 어렵다. 관리직에는 대리, 과장, 부장, 이사들이 피라미드 구조로 되어 있다.
그런데 기술직에는 이러한 피라미드 구조가 없다는 사실이 왜 놀라지 않는가? 사실 피라미드 구조는 있으나 그 모양이 거꾸로 되어 있다. DBA는 시스템 자원을 관리·통제하는 정도의 역할만을 하는 사람이 아니다.
개발자의 어떤 문제라도 해결해 줄 수 있고 전체 구성원을 한 차원 높은 세계로 인도할 수 있는 기술을 보유 한 사람이어야 하며, 새롭게 변화되는 신기술을 부단히 노력하여 솔루션을 제공할 수 있는 사람이어야 한다.
그러나 현실은 어떠한가. 대부분의 DBA는 마치 과거의 SP(System Programmer)와 같이 저장공간이나 관리하고 백업, 시스템 업그레이드 등의 역할만 한다.
그들은 현업의 업무도 모르고 프로그램 개발 경험이나 설계 능력도 없다.
개발을 하면서 부딪히는 문제들의 근본적인 원인을 규명하고 해결책을 찾고 관련된 공부를 하기에는 당장 내일까지 해야 할 일이 시급하다.
그러다 보니 전에 했던 방법을 그대로 답습하게 되고 잘못된 길인 줄을 알면서 버젓이 그 길을 간다.
경력은 자꾸 쌓여 가지만 잔기술만 늘었지 체계는 제대로 잡혀 있지 못하니 또 다시 많은 시행착오를 겪게 된다.
당연히 항상 바쁘게 일하지만 일은 줄어들지 않는다.
그러니 항상 발등엔 불이 떨어지고 제대로 된 기술을 쌓을 시간이 없다.
이러한 악순환은 계속되고 점차 몸과 마음은 같이 지쳐만 간다. 이제 우리는 이 악순환의 고리를 끊어야만 도약을 할 수 있다. 자신도 편하고 미래의 전문가의 길도 보장된다.
우리가 전환해야 할 인식의 첫 번째는 하루 빨리 절차형 사고에서 벗어나 집합적이고 비절차형 사고로 전환하는 것이다.
이것은 결코 생각처럼 쉽지가 않다. 정보시스템을 시작하는 날부터 지금까지 항상 생각의 바탕이 되었던 절차형 사고를 하루 아침에 바꾼다는 것은 참으로 어렵다. 개발자의 인식전환 다음으로 우리가 바꾸어야 할 생각은 '설계는 대충해도 프로그램에서 어떻게 처리하면 된다'는 것과 '모름지기 처리 과정은 내가 직접 기술할 수밖에 없다'는 생각이다.
앞서도 언급했지만 이제 더 이상 프로그래머는 우리가 아니다.
진짜 프로그래머는 데이터베이스이며,우리는 그들에게 사용자로 처리를 부탁하는것이다.
이제 더 이상 복잡한 로직을 잘 구현하는 사람이 우수했던 시대는 지나갔다.
데이터베이스가 좋은 일을 하도록 전략적인 요소를 잘 정의해 주는 사람이 진정으로 우수한 사람이다. 또한 데이터는 한건씩 처리하는 것이 아니라 여러 건을 동시에 처리할 수 있다는 생각을 해야 프로그램의 형태가 달라진다. 지금까지 우리가 처리한 모든 프로그램에서는 일단 한 건을 읽어 마치 곡예를 하듯이 필요한 처리를 하고, 끝나면 다시 처음으로 돌아가는 처리를 반복한다. 이것은 어쩌면 절대로 바뀔 수 없는 프로그램의 기본 골격으로 생각하고 있다.
그러나 이러한 생각을 버려야 집합이 보이고 비절차형으로 갈 수 있고 수 행속도가 보장된다.
아직도 많은 개발자들은 데이터는 출력해서 보는 것이라는 생각을 버리지 못하고 있다.
가능한 모든 프로그램은 온라인으로 검색할 수 있어야 한다.
온라인 화면은 그대신 정보 검색이 매우 자유롭고 유기적으로 연결되어 있어야만 한다.
이를 위해서는 무엇보다도 기능 모델링이 제대로 되어야 한다.
더 이상 단편적인 프로그램들을 메뉴에 엮어서 들락거리게 해서는 안된다.
어느 정보에서 출발했더라도 자신이 원하는 정보로 쉽게 옮겨 다닐 수 있어야 그게 바로 시스템이다. 마지막으로 우리가 버려야 할 생각은 '경력이 많아지면 관리자가 되어야 한다'는 생각이다.
