컬럼/인터뷰
저자: 이춘식, 데이터베이스 설계와 구축 : 성능까지 고려한 데이터 모델링(개정판) 저자
개발자에서 모델러 & DBA역할로...
학부 전공이 컴퓨터 관련도 아니었고 학원수강 경험도 없는터라 입사하자마자 사수(신입사원 때 일을 가르쳐 주는 사람의 별칭)로부터 6개월 동안 끊임없이 들었던 잔소리이다. 이러한 사수의 한 마디 한마디가 너무 서러운지라 하루는 집 앞까지 따라가 서운한 감정을 토로하기도 하고, 정말 이 길이 나의 적성에 맞는 길인지를 반문해 보기도 했다.
90년 중반 필자는 메인프레임에서 작성된 COBOL2 프로그램을 유지 보수하는 업무를 담당했었다. 한참 메인프레임에서 오픈 시스템 환경으로 전환되는 시점에 IT업으로 진출한 것이다. 컴퓨터라고 하면 겨우 독수리 타법으로 하루 밤을 새우면서 보고서를 작성하는 수준이었고 그나마 기본적인 커멘트도 몰라 작업을 다시 해야 했던(이런 개인용 PC에 조차 무지했던) 사람이 기업의 인사와 급여에 해당하는 엔터프라이즈급 초대형 서버인 메인프레임의 프로그램을 맡아 운영을 해야 한다니... 하니 사수 입장에서 보면 한없이 답답한 부사수이었을 법도 하다.
사실 당시까지만 하더라도 필자는 프로그램에 대한 개념이 전혀 없었다. 온라인화면이 메인프레임 DO3270이라는 에뮬레이터 컴퓨터모니터에 나타나는 것을 보고, 뒤에 무한 Loop가 도는 프로그램이 계속 실행되고 있는 줄 알고 질문했다가, 무지한 질문에 면박당한 적도 있었으니 말이다.
이런 결심 후, 모르는 부분은 선배들을 붙잡고 물어가면서 본격적인 학습을 시작하였다. 메인프레임에서 기동되는 5개 정도의 보고서 프로그램 숙제를 밤을 새가며 원리를 이해하고 학습하며 실습해 보았다. 역시 프로그램은 실습이 중요하다고 느낀 때가 바로 이 때였다. 이렇게 6개월 정도 노력하다 보니까 자연스럽게 프로그램에 대한 개념뿐만 아니라 고객으로부터 접수되는 요구사항도 자연스럽게 처리할 수 있는 수준에 이르렀다. 한번은 이런 일도 있었다. 연말정산 프로그램 재작성때 하루 종일 프로그램 로직에 대해 고민하다가 결국 해결하지 못한채 집에 돌아가 잠을 잤는데, 밤새 꿈속에서까지 프로그램 로직 해결에 시달렸던 적도 있다. 잠도 설쳐가며, 꿈속에서, 화장실에서 프로그램 로직에 대한 이해 및 능력을 갖기 위해 노력하다보니 "나중에는 어떤 언어(LANGUAGE)가 되어도 프로그래밍을 할 수 있겠다" 라는 자신감이 들었다. 필자가 진정한 개발자로 거듭날 수 있었던 사고의 전환점이 된 시기였던 것 같다. 이후 코볼뿐만 아니라 C, 파워빌더, 델파이, Pro*C 등의 개발언어를 이용하여 개발하는 경우가 많았는데 어렵지 않게 프로그래밍 언어를 정복하며 개발에 참여 할 수 있었다.
그런데 어느 정도 프로그래밍에 대해 익숙해진 상태에서 시스템을 운영하다보니 계층형 데이터베이스에서 관계형 데이터베이스로 전환한 테이블 모양이 좀 이상하다는 생각이 들었다. 테이블간의 관계도 정확하게 판단하기 힘들었고, 또한 테이블의 모습을 알 수 없어서 테이블에 임시 컬럼을 많이 사용하게 되고 그 컬럼에 다른 값을 넣어 처리하게 되었다. 이러다 보니 응용프로그램에서는 임시 컬럼을 처리하기 위한 임시 로직이 증가하게 되고 임시 로직은 다시 변하고 바뀌고 추가되고 삭제되면서 이른바 "누더기(걸레)시스템"으로 관리되고 있었던 것이다.
한편에서는 당시 오픈시스템인 클라이언트 서버환경으로 새로운 프로젝트가 진행되고 있었다. 그 시스템은 분석하고 설계하는 사람이 이미 메인프레임 환경의 임시 컬럼에 익숙한 사람이라 유닉스 환경의 관계형 데이터베이스를 설계할 때도 한 테이블 당 3~7개 정도의 임시 컬럼을 설계했는데, 그걸 보고 과연 그렇게 해야만 하는지 의심이 들게 되었다.
국가적으로도 중요한 프로젝트였기 때문에 국내 유명 교수, 최고 전문가, 해외의 여러 컨설턴트가 투입되는 경우가 많았다. 나름대로 모델링에 대한 학습도 하면서, 이전에 문제로 생각했던 부분들을 적용하면서 접근하다보니까 여러 가지로 문제가 많음을 깨달을 수 있었다. 업무를 분석하여 모델링을 진행하는 사람은 대부분 개발에 익숙해져 있고 전문성을 가지고 있는 사람이 하는 경우가 많았다. 그러나 그렇다고 할지라도 실제로 모델링이 되어 있는 내용은 그렇게 수준이 높지 않고 개선의 여지가 너무 많이 발견이 되었다.
통합모델링을 진행하면서 "꼭 필요한 모델링은 어떻게 해야 하는가?", "다양한 사례는 어떠한 솔루션들을 가지고 해결할 수 있는가?"에 대해 심각하게 고민하고 해결점을 찾기 위해 노력하고, 국내 관련도서들도 조사해보았지만 막상 도움을 받을 수 있는 정보는 많이 없었다. 어떤 업무규칙에 대해서는 몇 주 동안 생각해보고 적절한 모델링 솔루션을 찾기 위해 고민한 적도 있었다. 프로그램을 처음 배울 때와 마찬가지로 잠도 설치며 출퇴근 하는 지하철에서 모델에 대한 솔루션을 생각해보았다. 이때 모델에 대한 개념도 정립하고 연구도 하면서, 특히 해외 컨설턴트와 같이 토론하며 모델링을 진행하면서 연구하였던 생각들이 다른 프로젝트 경험과 함께 “데이터베이스 설계와 구축”이라는 책으로 정리되었다. 개인적으로는 이 시기 동안 모델과 데이터베이스에 대한 사고에 전환을 가져오게 되었다.
이와 같은 사연으로 필자는 시스템을 운영할 때부터 가졌던 시스템 근본구조에 대한 고민과 개선의 필요성을 인식하고 실제 프로젝트에서 부딪히게 되는 핵심적인 이슈들에 대한 해결방법의 필요성을 느끼게 되어 개발자에서 모델러 & DBA 역할자로 직무를 바꾸게 되었다.
모델링의 중요성과 모델러 & DBA역할
IT 개발방법론은 건축의 방법론으로부터 응용하여 만들었다. 다시 말해 건축과 IT 구축은 서로 비슷하다고 할 수 있다. 건축방법론에서 가장 중요한 기초공사를 하는 부분이 바로 모델링으로 비유할 수 있다. 아무리 좋은 프로그램도 기반이 부실해서야 좋은 프로그램을 만들 수가 없다. 이는 마치 조선시대 마차가 지나가는 길로는 오늘날의 대형 버스나 수많은 자동차가 다닐 수 없는 것과 같은 이치이다. 많이 개선이 되었다고는 하지만 여전히 개발자들에게 프로젝트 일정은 촉박하게 잡힌다. 그래서 많은 개발자들이 개발에 대한 부담감으로 시스템근본인 모델링을 간과 하는 경우가 많다. 그러므로 모델링은 정보시스템을 구축하는 가장 핵심적인 프로세스인 것이다.
모델러 및 DBA로서 어떤 역할을 수행하는가?
모델러와 DBA는 같이 수행할 수도 있지만 별개로 구분되어 수행될 수도 있다.
일반적으로 모델링을 한다는 것은 크게 프로세스모델링과 데이터모델링영역으로 분류할 수 있다. 정보공학을 기반으로 할 때는 두 가지 모델링이 각각 진행되면서 보완하는 방법을 사용하고, 객체지향 기반으로 모델링을 할 때는 같이 진행하게 된다. 모델러는 개발에 참여한 모든 사람이 수행하는 역할이다. 거기에 모델만을 담당하는 사람(즉 모델러)은 전체적으로 모델링을 할 수 있도록 교육하고 가이드하며 통합모델링작업을 수행하는 등의 역할을 수행한다.
다음은 모델러로서 프로젝트에서 하는 역할이다
모델링을 하지 않고 구축된 데이터베이스만 다루는 사람은 자신이 어느 지점에 서있는지 잘 알지 못하는 길잃은 자와 같다. 또한 데이터베이스의 원리를 모르고 모델링만 하는 사람은 목적지가 없이 지도만 가지고 길을 가는 사람과 같다.
모델링을 전개할 때는 먼저, 업무로부터 비즈니스 모델을 만들어 낸 후, 이를 바탕으로 데이터베이스를 생성하기 위한 모델을 만들어 내야 한다. 그래야 데이터의 무결성도 지키면서 성능을 향상시킬 수 있는 모델링을 전개할 수 있게 된다.
반대로 데이터베이스 담당자는 모델이 어떤 비즈니스로 생성되었는지 비즈니스모델이 어떻게 데이터베이스 모델이 되었는지를 알고 있으면서 운영 및 관리를 해나가야 정확한 데이터스키마 관리 및 성능관리, 데이터의 무결성 관리가 가능해 진다.
왼쪽 그림과 같이 모델러가 데이터베이스를 모르고 모델링을 하거나 DBA가 업무를 전혀 모르고 데이터베이스만 관리하는 경우는 바람직한 모델이라 할 수 없다. 이는 가장 중요한 프로세스가 끊겨버리기 때문에 잘못된 물리모델이 생성되거나 구축이후 데이터베이스가 변경 될 때 이상한 모습으로 변형될 가능성이 많은 위험한 구조이다. 오른쪽 그림과 같이 모델러는 물리적인 데이터베이스의 모습을 이해한 상태에서 모델링을 진행해야 하며 DBA도 업무의 구조와 흐름을 이해한 상태에서 물리모델로 전환하는 작업을 수행하거나 이해해야 프로젝트가 효과적으로 진행될 수 있다.
어떤 사람이 모델러나 DBA가 될 수 있는가?
첫째! 누구나 모델러나 데이터베이스 관리자는 될 수 있다. IT분야 특히 소프트웨어 개발에 관심 있는 사람은 누구나 모델러와 DBA로서 역할을 수행할 잠재력이 있는 사람이 된다.
둘째! 어느 정도 개발경험을 가진 사람을 권유하고 싶다. 특히 학교나 학원에서 모델러나 DBA에 관심이 있는 사람이라면 개발과 같이 학습할 필요가 있다. 개발 공정을 이해하고 응용프로그램에서 어떻게 처리되는지에 대한 명확한 이해가 있을 때, 효율적인 모델링과 데이터베이스 구축과 관리가 이루어 질 수 있기 때문이다.
셋째! IT분야에 깊은 학문적 수준까지 학습 및 발전을 원한다면 모델러와 DBA를 권한다. 모델링분야와 데이터베이스분야는 점점 성숙해가고 발전하는 변화가 있지만 항상 그 이전의 이론을 배경으로 발전하기 때문에 IT분야에서 지속성이 유지되는 장점을 가지고 있다. 이른바 COBOL개발자, 파워빌더 개발자와 같이 기술 변화에 따라 수요가 줄어들고 사라지는 분야가 아니라 항상 존재하며 발전해나가는 분야라는 것이다.
전문적인 모델러와 DBA가 되기 위한 제언
정보기술에서 "다소 어려운 분야"로 인식되는 모델과 데이터베이스 영역에서 훌륭한 전문가가 되려면 바로 아래와 같은 사고의 전환 그래프 원리를 활용해야 한다.
그래프를 보면 일반적 노력에 의해 성장효과가 초기에는 명확하게 나타나지만 시간이 지남에 따라 성장속도가 둔화되고 더 이상 발전이 되지 않은 상태에 도달하게 된다. 그러다가 어떤 사고의 전환점을 만나는 순간 성장의 속도가 급격하게 빨라지게 되어 최고의 전문가로 성장한다는 그래프이다.
일반적인 모델러와 DBA로서 역할수행은 첫번째 노력에 의해 얼마든지 할 수 있다. 물론 이 과정에 드는 노력도 무척 중요하다. 그렇지만 그런 노력만 가지고는 전문적이고 훌륭한 모델러와 DBA가 될 수 없다. 바로 이 시점에서 사고의 전환점이 필요하다. 어떤 사람은 이 한계를 능력 최고점이라고 이야기하고 이 한계점을 넘은 사람에 대해서는 타고난 자질을 가지고 있다고 표현하기도 한다. 그러나 필자는 그렇게 생각하지 않는다. 사람은 누구나 능력이 있고, 그 상태에서 사고의 전환을 통해 누구나 무한히 성장할 수 있다.
그러므로 일단은 성장노력을 충분하게 하면서 사고의 전환점을 극복해내야 최고의 모델러와 DBA가 될 수 있다는 말이다. 사고의 전환점을 돌파하기 위해서는 자신을 규정했던 잘못된 자아관을 버려야 한다. "나는 여기까지가 한계야", "저 부분은 다른 전문가가 하는 영역이야", "내가 어떻게 저 영역까지..."라는 생각을 과감하게 버려야 한다. 우리가 알고 있는 소위 전문가라는 사람들은 이와 같은 부정적인 생각을 버리고 대신, 최고의 전문가가 될 수 있다는 자신감을 자신에게 불어넣어 최고가 된 사람들이다. 자신을 규정하는 부정적인 자아의 틀을 벗어버리고 자신감을 가지고 나아갈 때 최고의 전문가 영역에 도달 할 수 있다. 모델 및 DB분야가 어렵다는 생각은 벗어버리고 이 기사를 읽으며 최고의 전문가영역에 도달하기 위한 사고의 전환점을 꼭 가지시기를 희망한다.
글을 마치며
정보시스템의 영역은 다른 산업 분야와 다르게 그 추세나 기술영역이 가장 빠르게 변하는 영역이다. 그러나 이와 같이 빠르게 변하는 영역임에도 그 중심에는 항상 데이터가 있어 그 데이터가 안정정적이어야 빠르게 변화하는 기술이나 사상이 비로소 효과가 있게 된다. 서류에서 파일, 다시 데이터베이스로 이어지는 동안 한번도 업무를 처리하는 단위에서 데이터를 소홀히 한 적이 없음을 기억해야 할 것이다. 개발된 프로그래밍 소스나 개발되었던 장비(하드웨어), 그리고 사용하였던 소프트웨어는 시간이 지나면 사라져버린다. 하지만 누적된 데이터들은 지속적으로 릴레이 되고 추출되어 활용되며 다시 사용되는 경우가 많음을 기억해야 할 것이다. 필수적인 영역, 변화를 수용하지만 변화하지 않는 사상, 절대로 변치 않는 핵심 사상이 바로 데이터의 중요성과 그에 따른 시스템 구축 프로젝트에 그대로 적용이 된다.
그러므로 이미 IT분야에 진출해 있거나 앞으로 진출하기 원하는 사람은 데이터영역에 대한 새로운 시각을 가지고 모델링 분야와 데이터베이스 분야에 적극적으로 진출해 주기를 희망하는 바이다. 그리고 이미 진출하여 활동하는 분들은 자신의 전문영역을 한 층 더 전문화할 수 있도록 사고의 전환점을 바탕으로 최고의 전문가로 거듭나기를 기원하는 바이다.
학습에 참고할만한 책들
개발자에서 모델러 & DBA역할로...
"그냥 집어치우고 집에 가는 게 좋을 것 같아!"
"도대체 개념이 있어야 프로그래머가 되지?"
학부 전공이 컴퓨터 관련도 아니었고 학원수강 경험도 없는터라 입사하자마자 사수(신입사원 때 일을 가르쳐 주는 사람의 별칭)로부터 6개월 동안 끊임없이 들었던 잔소리이다. 이러한 사수의 한 마디 한마디가 너무 서러운지라 하루는 집 앞까지 따라가 서운한 감정을 토로하기도 하고, 정말 이 길이 나의 적성에 맞는 길인지를 반문해 보기도 했다.
90년 중반 필자는 메인프레임에서 작성된 COBOL2 프로그램을 유지 보수하는 업무를 담당했었다. 한참 메인프레임에서 오픈 시스템 환경으로 전환되는 시점에 IT업으로 진출한 것이다. 컴퓨터라고 하면 겨우 독수리 타법으로 하루 밤을 새우면서 보고서를 작성하는 수준이었고 그나마 기본적인 커멘트도 몰라 작업을 다시 해야 했던(이런 개인용 PC에 조차 무지했던) 사람이 기업의 인사와 급여에 해당하는 엔터프라이즈급 초대형 서버인 메인프레임의 프로그램을 맡아 운영을 해야 한다니... 하니 사수 입장에서 보면 한없이 답답한 부사수이었을 법도 하다.
사실 당시까지만 하더라도 필자는 프로그램에 대한 개념이 전혀 없었다. 온라인화면이 메인프레임 DO3270이라는 에뮬레이터 컴퓨터모니터에 나타나는 것을 보고, 뒤에 무한 Loop가 도는 프로그램이 계속 실행되고 있는 줄 알고 질문했다가, 무지한 질문에 면박당한 적도 있었으니 말이다.
다른 길을 선택할까?
아니면 그냥 이 길을 고집할까?
고민하다가 인정받을 수 없는 자신이 화가 나기도 하고 도전과 변화가 많은 이 일이 매력도 있게 보여 계속 가기로 결심하였다.
이런 결심 후, 모르는 부분은 선배들을 붙잡고 물어가면서 본격적인 학습을 시작하였다. 메인프레임에서 기동되는 5개 정도의 보고서 프로그램 숙제를 밤을 새가며 원리를 이해하고 학습하며 실습해 보았다. 역시 프로그램은 실습이 중요하다고 느낀 때가 바로 이 때였다. 이렇게 6개월 정도 노력하다 보니까 자연스럽게 프로그램에 대한 개념뿐만 아니라 고객으로부터 접수되는 요구사항도 자연스럽게 처리할 수 있는 수준에 이르렀다. 한번은 이런 일도 있었다. 연말정산 프로그램 재작성때 하루 종일 프로그램 로직에 대해 고민하다가 결국 해결하지 못한채 집에 돌아가 잠을 잤는데, 밤새 꿈속에서까지 프로그램 로직 해결에 시달렸던 적도 있다. 잠도 설쳐가며, 꿈속에서, 화장실에서 프로그램 로직에 대한 이해 및 능력을 갖기 위해 노력하다보니 "나중에는 어떤 언어(LANGUAGE)가 되어도 프로그래밍을 할 수 있겠다" 라는 자신감이 들었다. 필자가 진정한 개발자로 거듭날 수 있었던 사고의 전환점이 된 시기였던 것 같다. 이후 코볼뿐만 아니라 C, 파워빌더, 델파이, Pro*C 등의 개발언어를 이용하여 개발하는 경우가 많았는데 어렵지 않게 프로그래밍 언어를 정복하며 개발에 참여 할 수 있었다.
그런데 어느 정도 프로그래밍에 대해 익숙해진 상태에서 시스템을 운영하다보니 계층형 데이터베이스에서 관계형 데이터베이스로 전환한 테이블 모양이 좀 이상하다는 생각이 들었다. 테이블간의 관계도 정확하게 판단하기 힘들었고, 또한 테이블의 모습을 알 수 없어서 테이블에 임시 컬럼을 많이 사용하게 되고 그 컬럼에 다른 값을 넣어 처리하게 되었다. 이러다 보니 응용프로그램에서는 임시 컬럼을 처리하기 위한 임시 로직이 증가하게 되고 임시 로직은 다시 변하고 바뀌고 추가되고 삭제되면서 이른바 "누더기(걸레)시스템"으로 관리되고 있었던 것이다.
한편에서는 당시 오픈시스템인 클라이언트 서버환경으로 새로운 프로젝트가 진행되고 있었다. 그 시스템은 분석하고 설계하는 사람이 이미 메인프레임 환경의 임시 컬럼에 익숙한 사람이라 유닉스 환경의 관계형 데이터베이스를 설계할 때도 한 테이블 당 3~7개 정도의 임시 컬럼을 설계했는데, 그걸 보고 과연 그렇게 해야만 하는지 의심이 들게 되었다.
모델러와 DBA로서 길을 갈 수 있도록 나에게 가장 큰 도전을 준 프로젝트가 2년여 동안 수행한 H프로젝트였다. 나는 이곳에서 통합 모델러 역할과 함께 통합 DBA 역할을 동시에 수행하게 되었다. 통합 모델링도 업무가 큰 관계로 정보공학 기반의 모델링과 객체지향 기반의 모델링을 동시에 경험하게 되는 계기가 되었다.
국가적으로도 중요한 프로젝트였기 때문에 국내 유명 교수, 최고 전문가, 해외의 여러 컨설턴트가 투입되는 경우가 많았다. 나름대로 모델링에 대한 학습도 하면서, 이전에 문제로 생각했던 부분들을 적용하면서 접근하다보니까 여러 가지로 문제가 많음을 깨달을 수 있었다. 업무를 분석하여 모델링을 진행하는 사람은 대부분 개발에 익숙해져 있고 전문성을 가지고 있는 사람이 하는 경우가 많았다. 그러나 그렇다고 할지라도 실제로 모델링이 되어 있는 내용은 그렇게 수준이 높지 않고 개선의 여지가 너무 많이 발견이 되었다.
통합모델링을 진행하면서 "꼭 필요한 모델링은 어떻게 해야 하는가?", "다양한 사례는 어떠한 솔루션들을 가지고 해결할 수 있는가?"에 대해 심각하게 고민하고 해결점을 찾기 위해 노력하고, 국내 관련도서들도 조사해보았지만 막상 도움을 받을 수 있는 정보는 많이 없었다. 어떤 업무규칙에 대해서는 몇 주 동안 생각해보고 적절한 모델링 솔루션을 찾기 위해 고민한 적도 있었다. 프로그램을 처음 배울 때와 마찬가지로 잠도 설치며 출퇴근 하는 지하철에서 모델에 대한 솔루션을 생각해보았다. 이때 모델에 대한 개념도 정립하고 연구도 하면서, 특히 해외 컨설턴트와 같이 토론하며 모델링을 진행하면서 연구하였던 생각들이 다른 프로젝트 경험과 함께 “데이터베이스 설계와 구축”이라는 책으로 정리되었다. 개인적으로는 이 시기 동안 모델과 데이터베이스에 대한 사고에 전환을 가져오게 되었다.
이와 같은 사연으로 필자는 시스템을 운영할 때부터 가졌던 시스템 근본구조에 대한 고민과 개선의 필요성을 인식하고 실제 프로젝트에서 부딪히게 되는 핵심적인 이슈들에 대한 해결방법의 필요성을 느끼게 되어 개발자에서 모델러 & DBA 역할자로 직무를 바꾸게 되었다.
모델링의 중요성과 모델러 & DBA역할
IT 개발방법론은 건축의 방법론으로부터 응용하여 만들었다. 다시 말해 건축과 IT 구축은 서로 비슷하다고 할 수 있다. 건축방법론에서 가장 중요한 기초공사를 하는 부분이 바로 모델링으로 비유할 수 있다. 아무리 좋은 프로그램도 기반이 부실해서야 좋은 프로그램을 만들 수가 없다. 이는 마치 조선시대 마차가 지나가는 길로는 오늘날의 대형 버스나 수많은 자동차가 다닐 수 없는 것과 같은 이치이다. 많이 개선이 되었다고는 하지만 여전히 개발자들에게 프로젝트 일정은 촉박하게 잡힌다. 그래서 많은 개발자들이 개발에 대한 부담감으로 시스템근본인 모델링을 간과 하는 경우가 많다. 그러므로 모델링은 정보시스템을 구축하는 가장 핵심적인 프로세스인 것이다.
모델러 및 DBA로서 어떤 역할을 수행하는가?
모델러와 DBA는 같이 수행할 수도 있지만 별개로 구분되어 수행될 수도 있다.
일반적으로 모델링을 한다는 것은 크게 프로세스모델링과 데이터모델링영역으로 분류할 수 있다. 정보공학을 기반으로 할 때는 두 가지 모델링이 각각 진행되면서 보완하는 방법을 사용하고, 객체지향 기반으로 모델링을 할 때는 같이 진행하게 된다. 모델러는 개발에 참여한 모든 사람이 수행하는 역할이다. 거기에 모델만을 담당하는 사람(즉 모델러)은 전체적으로 모델링을 할 수 있도록 교육하고 가이드하며 통합모델링작업을 수행하는 등의 역할을 수행한다.
다음은 모델러로서 프로젝트에서 하는 역할이다
- 통합모델링을 수행한다
- 모델링을 한다는 것은 결국 어떤 업무 내용을 이해한 상태에서 그 내용을 정보시스템으로 구축하기 위해 모형으로 만드는 것을 의미한다. 세부 업무간의 정보의 흐름을 파악하여 모델에 표현하는 일은 각 개발자가 수행한다. 모델러는 전체 업무의 구조와 흐름을 분석하여 적절한 표기법으로 표현해 내는 역할을 수행한다. 또한 세부업무를 담당하는 사람이 효과적인 모델링을 진행할 수 있도록 교육하고 가이드 하는 역할을 수행한다.
- 모델에 대한 검증작업을 수행한다
- 업무를 분석하는 모든 사람들이 업무 각각의 모델링 작업을 한다면 모델검증은 좀 더 숙련되고 이해력이 높은 사람이 할 수 있어야 한다. 즉 모델러는 세부 업무에서 수행한 모델이 기술적이나 업무적으로 오류사항이 있는지를 확인하고 잘못을 지적하며, 새로운 대안점을 제시하는 역할을 수행한다.
- 커뮤니케이션 리더 역할을 한다
- 모델링은 혼자 하는 게 아니라 각 기업에 있는 여러 사람이 하는 경우에 해당하므로 커뮤니케이션이 많이 발생하는 업무가 된다. 특히 전체업무에 대한 통합모델링 작업을 진행할 때는 모델링 회의를 통해 세부업무를 담당하는 모델러들을 소집하여 통합 모델링 작업을 진행하게 된다. 특히 이때에는 모델링을 위한 커뮤니케이션이 질문, 조정, 중재 및 해결점 제시에 중요한 역할을 하게된다.
- 모델링을 했던 사람이 DBA를 겸임하면 더 효과적인 데이터베이스 관리를 할 수 있다. DBA는 업무를 모르는 상태에서 바로 데이터베이스를 구축하고 이를 관리하는 업무도 할 수 있지만 이와같은 업무는 제한적이고 좋지 않은 업무영역이 된다. 데이터베이스를 담당하는 사람도 모델부터 이어져 데이터베이스를 관리할 수 있도록 해야 한다.
- 논리모델을 물리모델로 전환한다
- 업무적인 관점에서 모델로 표기한 논리모델을 데이터베이스관점(특정 DBMS, 용량고려)에서 물리적인 모델로 전환하는 역할을 수행한다. 이 때 모델러가 있으면 같이 수행하고 자신이 두 가지를 수행한다면 논리모델에 대한 버전을 1.0으로 만들어 두고 물리모델을 생성하도록 해야 한다. 물리모델을 만들 때 중요하게 고려해야 하는 점이 바로 데이터무결성과 데이터베이스성능을 고려한 모델로 반정규와, 분산 모델이 같은 설계가 있을 수 있다.
- 데이터베이스 오브젝트를 설계한다
- 먼저 데이터베이스에 발생하는 트랜잭션의 수를 파악하고, 전환되는 데이터의 양과 데이터의 보관주기를 고려하여 용량산정을 하도록 한다. 그리고 트랜잭션과 데이터량에 따라 테이블스페이스, 데이터파일, 테이블, 인덱스, 뷰 등을 설계하도록 한다.
- 데이터베이스를 구축하고 관리한다
- 설계가 완료된 내용을 가지고 이용하여 DDL(Data Definition Language)스크립트를 이용하여 DBMS에 데이터베이스 인스턴스를 생성하고 거기에 설계된 오브젝트 들을 생성한다. 또한 한번 생성된 오브젝트들에 대해 개발하면서 변경되는 사항을 데이터모델과 데이터베이스에 정확하게 일치시켜가면서 변경하는 역할을 수행한다. 또한 데이터에 대한 백업 및 복구 역할을 수행하고 장애가 발생하지 않도록 세션 모니터링이나 로그모니터링을 지속적으로 수행하는 역할을 한다.
- 데이터베이스를 튜닝한다
- 구축된 데이터베이스는 데이터량이 증가할 수 있도록 SQL문장이 비효율적으로 작성 될 수록 데이터베이스 서버 파라미터가 잘못 지정되어 있거나, 파일시스템 설계를 잘못하는 경우 성능이 저하될 수 있다. 이때 DBA는 데이터베이스를 응용프로그램 관점에서 튜닝(SQL) 하거나 데이터베이스 서버(파라미터, 파일시스템 등)관점에서 튜닝하는 역할을 수행한다.
모델링을 하지 않고 구축된 데이터베이스만 다루는 사람은 자신이 어느 지점에 서있는지 잘 알지 못하는 길잃은 자와 같다. 또한 데이터베이스의 원리를 모르고 모델링만 하는 사람은 목적지가 없이 지도만 가지고 길을 가는 사람과 같다.
모델링을 전개할 때는 먼저, 업무로부터 비즈니스 모델을 만들어 낸 후, 이를 바탕으로 데이터베이스를 생성하기 위한 모델을 만들어 내야 한다. 그래야 데이터의 무결성도 지키면서 성능을 향상시킬 수 있는 모델링을 전개할 수 있게 된다.
반대로 데이터베이스 담당자는 모델이 어떤 비즈니스로 생성되었는지 비즈니스모델이 어떻게 데이터베이스 모델이 되었는지를 알고 있으면서 운영 및 관리를 해나가야 정확한 데이터스키마 관리 및 성능관리, 데이터의 무결성 관리가 가능해 진다.
왼쪽 그림과 같이 모델러가 데이터베이스를 모르고 모델링을 하거나 DBA가 업무를 전혀 모르고 데이터베이스만 관리하는 경우는 바람직한 모델이라 할 수 없다. 이는 가장 중요한 프로세스가 끊겨버리기 때문에 잘못된 물리모델이 생성되거나 구축이후 데이터베이스가 변경 될 때 이상한 모습으로 변형될 가능성이 많은 위험한 구조이다. 오른쪽 그림과 같이 모델러는 물리적인 데이터베이스의 모습을 이해한 상태에서 모델링을 진행해야 하며 DBA도 업무의 구조와 흐름을 이해한 상태에서 물리모델로 전환하는 작업을 수행하거나 이해해야 프로젝트가 효과적으로 진행될 수 있다.
어떤 사람이 모델러나 DBA가 될 수 있는가?
첫째! 누구나 모델러나 데이터베이스 관리자는 될 수 있다. IT분야 특히 소프트웨어 개발에 관심 있는 사람은 누구나 모델러와 DBA로서 역할을 수행할 잠재력이 있는 사람이 된다.
둘째! 어느 정도 개발경험을 가진 사람을 권유하고 싶다. 특히 학교나 학원에서 모델러나 DBA에 관심이 있는 사람이라면 개발과 같이 학습할 필요가 있다. 개발 공정을 이해하고 응용프로그램에서 어떻게 처리되는지에 대한 명확한 이해가 있을 때, 효율적인 모델링과 데이터베이스 구축과 관리가 이루어 질 수 있기 때문이다.
셋째! IT분야에 깊은 학문적 수준까지 학습 및 발전을 원한다면 모델러와 DBA를 권한다. 모델링분야와 데이터베이스분야는 점점 성숙해가고 발전하는 변화가 있지만 항상 그 이전의 이론을 배경으로 발전하기 때문에 IT분야에서 지속성이 유지되는 장점을 가지고 있다. 이른바 COBOL개발자, 파워빌더 개발자와 같이 기술 변화에 따라 수요가 줄어들고 사라지는 분야가 아니라 항상 존재하며 발전해나가는 분야라는 것이다.
전문적인 모델러와 DBA가 되기 위한 제언
정보기술에서 "다소 어려운 분야"로 인식되는 모델과 데이터베이스 영역에서 훌륭한 전문가가 되려면 바로 아래와 같은 사고의 전환 그래프 원리를 활용해야 한다.
그래프를 보면 일반적 노력에 의해 성장효과가 초기에는 명확하게 나타나지만 시간이 지남에 따라 성장속도가 둔화되고 더 이상 발전이 되지 않은 상태에 도달하게 된다. 그러다가 어떤 사고의 전환점을 만나는 순간 성장의 속도가 급격하게 빨라지게 되어 최고의 전문가로 성장한다는 그래프이다.
일반적인 모델러와 DBA로서 역할수행은 첫번째 노력에 의해 얼마든지 할 수 있다. 물론 이 과정에 드는 노력도 무척 중요하다. 그렇지만 그런 노력만 가지고는 전문적이고 훌륭한 모델러와 DBA가 될 수 없다. 바로 이 시점에서 사고의 전환점이 필요하다. 어떤 사람은 이 한계를 능력 최고점이라고 이야기하고 이 한계점을 넘은 사람에 대해서는 타고난 자질을 가지고 있다고 표현하기도 한다. 그러나 필자는 그렇게 생각하지 않는다. 사람은 누구나 능력이 있고, 그 상태에서 사고의 전환을 통해 누구나 무한히 성장할 수 있다.
그러므로 일단은 성장노력을 충분하게 하면서 사고의 전환점을 극복해내야 최고의 모델러와 DBA가 될 수 있다는 말이다. 사고의 전환점을 돌파하기 위해서는 자신을 규정했던 잘못된 자아관을 버려야 한다. "나는 여기까지가 한계야", "저 부분은 다른 전문가가 하는 영역이야", "내가 어떻게 저 영역까지..."라는 생각을 과감하게 버려야 한다. 우리가 알고 있는 소위 전문가라는 사람들은 이와 같은 부정적인 생각을 버리고 대신, 최고의 전문가가 될 수 있다는 자신감을 자신에게 불어넣어 최고가 된 사람들이다. 자신을 규정하는 부정적인 자아의 틀을 벗어버리고 자신감을 가지고 나아갈 때 최고의 전문가 영역에 도달 할 수 있다. 모델 및 DB분야가 어렵다는 생각은 벗어버리고 이 기사를 읽으며 최고의 전문가영역에 도달하기 위한 사고의 전환점을 꼭 가지시기를 희망한다.
글을 마치며
정보시스템의 영역은 다른 산업 분야와 다르게 그 추세나 기술영역이 가장 빠르게 변하는 영역이다. 그러나 이와 같이 빠르게 변하는 영역임에도 그 중심에는 항상 데이터가 있어 그 데이터가 안정정적이어야 빠르게 변화하는 기술이나 사상이 비로소 효과가 있게 된다. 서류에서 파일, 다시 데이터베이스로 이어지는 동안 한번도 업무를 처리하는 단위에서 데이터를 소홀히 한 적이 없음을 기억해야 할 것이다. 개발된 프로그래밍 소스나 개발되었던 장비(하드웨어), 그리고 사용하였던 소프트웨어는 시간이 지나면 사라져버린다. 하지만 누적된 데이터들은 지속적으로 릴레이 되고 추출되어 활용되며 다시 사용되는 경우가 많음을 기억해야 할 것이다. 필수적인 영역, 변화를 수용하지만 변화하지 않는 사상, 절대로 변치 않는 핵심 사상이 바로 데이터의 중요성과 그에 따른 시스템 구축 프로젝트에 그대로 적용이 된다.
그러므로 이미 IT분야에 진출해 있거나 앞으로 진출하기 원하는 사람은 데이터영역에 대한 새로운 시각을 가지고 모델링 분야와 데이터베이스 분야에 적극적으로 진출해 주기를 희망하는 바이다. 그리고 이미 진출하여 활동하는 분들은 자신의 전문영역을 한 층 더 전문화할 수 있도록 사고의 전환점을 바탕으로 최고의 전문가로 거듭나기를 기원하는 바이다.
학습에 참고할만한 책들
- 데이터베이스 설계와 구축
- 업무영역별 데이터베이스 설계와 구축
- 오라클 SQL 튜닝 : 쿼리의 본질과 성능 튜닝에 대한 37가지 이슈
- 30가지 장애 유형별 오라클 백업과 복구
- IT Expert 데이터베이스 모델링, 구축, 연동 실무
- An Introduction to Database System (Addison-Wesley, C.J. Date, 1999)
- Modern Database Management (Prentice Hall, 2001, Jeffrey A.Hoffer 외 2명)
- 대용량 데이터베이스 솔루션 I, II (엔코아, 1997, 이화식)
- 대용량 데이터베이스 솔루션 I, II (엔코아, 2000, 이화식, 조광원)
- 오라클 SQL 튜닝 실무 사례 (대청, 2000, 김광열 외 3명)
TAG :
이전 글 : 피보나치에 대한 이야기
다음 글 : Simple is Beautiful!
최신 콘텐츠