한때는 C/S가 세상을 풍미하던 시절이 있었다.. 조금 지나니.. 3Tier 미들웨어 가
신기술로써 자리매김되더니 어느덧 객체 지향 CBD SOA등등의 키워드들이
SI시장을 주도하였었다. 물론 지금도 이러한 단어들이 전혀 무시되는 것은 아니지만
어느덧 일상에 묻히는 꼭... TCP/IP 같은 단어 들처럼.. 조금은 알건알고 한계도 알고..
뭐 그런 단어중에 하나가 되었다.
그중에서 우리가 90년대 후반 부터 SI 개발을 흔들었던 주요 단어를 찾아보면
디자인 패턴, 리팩토링, 프레임웍, CBD, S/W아키텍쳐라고 볼수 있다.
물론 누군가는 Web Application Server, JaveEE 라고 말할 수 있지만.. 약간은 이론적 관점에서..
보자면 그렇다는 것이다.
그런데.. S/W아키텍쳐가 과연 시장을 주도하거나 영향을 미쳤는가 엄밀하게 S/W아키텍쳐 이론이
유용하거나 아님 최소한 논란의 대상이라도 되었었는가..? 사실은 아니었다
그럼에도 이 글에서 S/W아키텍쳐에 대해서 이야기 하고자 하는 것은
실제로 유용하기 때문이다. 최소한 CBD보다, 디자인 패턴보다, 리팩토링보다
중요하고 고민해 봐야 하는 주제이기 때문에 본 글에서 S/W아키텍를 이야기 하고자 한다.
SI 개발이라함은 고객의 요구사항을 코드로 만들어 가는 일련의 과정으로 볼 수 있다.
요구사항과 코드 사이의 GAP이 바로 SI 개발에서의 문제이다.
어떻게 하면 요구사항이 코드화 될것인가??
나는 기적이 필요하다고 이야기 한다. 얼마나 많은 돈이 필요한지? 얼마나 많은 시간이 필요한지?
어떤 절차를 따라서 진행해야 할지? 기적이 아니고는 성공할 수 없는 것이 SI 개발 프로젝트이다.
이글을 읽는 분들은 꼭 앞으로 프로젝트를 시작하기 전에 신심을 가지고 교회나 절이나 아니면 고사를 지내기 바란다.^^
이러한 기적 혹은 운에 마껴지던 것은 어떻게 하면 좀더 예상가능하게 진행할 수 있을까 해서 만들어진 것들이 소위 말하는 방법론들이다. 한테는 지금도 그렇겠지만 개발 프로젝트를 수주하기 전에 반드시 사용할 방법론을 제시하고 고객으로 부터 OK를 받아야만 프로젝트를 진행할수 있게 되는 근원이 이것이다. 기적이아니라 좀더 예상 가능하게 하기 위해서다.
그런데 방법론은 주로 절차와 산출물의 집합으로 이루어져 있다. 문제는 HOW TO가 없거나 있어도 알려지지 않고 잇기 때문에..
방법론이 프로젝트의 성공을 담보한다고 누구도 생각하지 않는게 현실이다.
요구사항이 코드로 변화하기 위해서는 대단위의 구성요소(컴포넌트)의 정의, 시스템(상위레벨) 레벨의 추상화등이 적절하게
이루어 져야만 코드화 될 수 있다. S/W아키텍쳐는 바로 이러한 일련의 것들을 고민하는 것이라 볼 수있다.
아키텍쳐란 비즈니스와 기술적 결정의 산물이다. 시스템에 대한 업무요건, 조직 구성, 요소 기술을 정의하고 결정하는 것이다.
좀더 formal하게 말하면 "비즈니스 요구상을 처리하기 위한 기술적 솔류션의 시작점"이다.
말이 너무 어려운감이 있다 쉽게 풀어 서 우리가 프로젝트를 할때를 상상해 보자..
통상의 경우 킥오프 미팅을 한다. 고객전산담당자들고 개발 리더들과 PM등등이 모여서 간단하게 자기 소개하고
프로젝트 의의와 고객 경영진의 방향에 대해서 공유하게된다. 그리고 나면 고객 전산담당이
RFP의 큰 줄기에 대해서 이야기 하고는 프로젝트 수석 개발자가 어떨게 개발하겠습니다. 라고 간략하게 전달하게된다.
무슨 방법론을써서 무슨 프레임웍을 쓰구 등등을 이야기 하면서 잘해봅시다 하구
저녁에 소주한잔하게된다.
이때부터 그 프로젝트는 이미 아키텍쳐의 큰 줄기를 결정한 것이다.
자바웹, Struts 프레임웍, 톰켓, 오라클, 10명이 6개월간 뭐 등등..
뭐 이쯤하면 프로젝트 팀원 중에 한명은
친구를 만나서 자신이 참여하게될 프로젝트에 대해서 어런것들을 이야기 하게된다.
그럼 친구는 화면이 몇개나 되는데? 사용자가 몇몇이나 되는데? 테이블은 ? 등등.. 뭔과 볼륨을 알기 위한
질문들은 하고나면,,, 음! 고생좀 하겠네.. 아님 ,. 너무 널널하게 가는거 아냐?? --
이 대화 속에서 우리는 두사람이 이미 시스템에 대한 큰 그림을 그리고 있는 것을 알 수 있다.(틀렸나??)
다음날 프로젝트 팀원들은 기대반 불안반으로 회사에 출근하고 나면 PM은 사람들을 모아 놓구.. 향후 일정이 어떻고
역할이 어떻고.. 당장 뭘 해야 하고 등등을 이야기 하기 시작한다.
업무 파악하랴, 분위기 적응하랴, 어떨결에 2~3일, 1~2주 혹은 1~2개월 지나면 개발 리더는 개발자들을 모아 놓고
칠판에 그림을 그리고 일장 연설을 한다. 우리의 프레임웍구조는 어떻구 주저리 주저리 알듯말듯...
화면에 BOX하구 LINE 혹은 화살표 동그라미를 그리면서 몇시간을 이야기 한다.
그개발 리더는 아키텍쳐를 설명했을 것이다. (주로 소프트웨어에 중심을 두고)
