수안이의 컴퓨터 연구실

당신이 MSF/CD에 대해 고민해야 하는 이유

김상훈 (동명정보대학교 연구원)   2004/12/27 
    

연재순서?
1회. 이래서 안되는거군!
2회. PM 김씨의 좌충우돌기
3회. 더이상 꼼수는 없다
4회. 개발 방법론, 제대로 알고 쓰자

대부분의 PM은 자신이 맡은 프로젝트를 성공적으로 이끌기 위해서 개발 방법론을 도입한다. 다양한 개발 방법론 중 프로젝트의 규모와 크기, 형태, 그리고 조직 구성 등을 감안해 선택하고 따르게 되는데, 대부분의 닷넷 프로젝트는 MSF/CD 개발 방법론을 채택해 프로젝트를 진행하게 된다. 그렇지만 MSF/CD를 제대로 이해하고 있는 경우는 드물다. 이번 글에서는 MSF에 대해 이야기해보자.

처음에는 MSF(Microsoft Solution Framework)에 관련된 글을 쓰고자 했다. 사실 필자는 MSF라는 것이 신기하기만 하다. 최근 닷넷 개발 사례를 보면 개발 방법론으로 MSF/CD를 선택하는 프로젝트가 대부분인데, MSF라는 것이 정식적으로 국내에 소개된 것은 거의 없기 때문이다.

국내에서 발매된 MSF 관련 서적은 정보문화사에서 나온 책 한권이 전부라고 봐도 무방하고, 인터넷 컨텐츠 혹은 교육 등 여러 측면에서도 MSF는 다른 개발 방법론에 비해 자료가 턱없이 부족하다. 그럼에도 불구하고 MSF/CD 개발 방법론을 이용해 프로젝트를 진행한다는 프로젝트 제안서의 자랑스러운(?) 문구는 날이 갈수록 늘어가기만 한다.

“MSF/CD가 제대로 사용되는 것을 본 적이 없다”
세계적으로 볼 때 큰 활용 사례가 없는 MSF가 난데없이 닷넷 개발 방법론의 표준으로 자리잡으려 하는 것이 이상하기도 하려니와 객체지향 개발 플랫폼인 닷넷 환경에서 이벤트 지향적으로 분석하고 설계되는 MSF가 거의 붐인 것처럼 채택이 늘어나는 것이 의아하기도 하다. MSF에 대한 이해 없이 MSF/CD에서 작성하는 산출물 순서만 따라가는 개발 방법이 과연 성공할 수 있을지에 대한 의문도 크다.

프로젝트를 진행함에 있어서 어떤 개발 방법론을 선택하느냐가 중요한 것이 아니다. 그렇다고 아무 방법론이나 가져다 붙이면 된다는 것은 더더욱 아니다. 개발 방법론을 선택하는 작업은 신중에 또 신중을 기해야 한다.

어떤 개발 방법론을 채택했다가 중요한 것이 아니고 프로젝트에 도입될 플랫폼의 특성과 개발 기한, 개발 팀 구성, 개발 목표, 개발 범위 등이 모두 고려되어서 채택되어야 할 심각한 문제이다. 개발 제안서에 MSF/CD라고 이름만 거창하게 붙여놓는다고 해서 그 방법대로 진행되는 것은 아니기 때문이다. 필자가 참여한 몇 개의 프로젝트에서 MSF/CD가 제대로 사용되는 것을 본 적이 없다. 다음의 사례를 살펴보자.

MSF/CD를 도입한 사례
첫 번째, Object Interaction Diagram은 엑셀로 그리면 되나요?
닷넷 플랫폼으로 솔루션을 개발하게 된 한 업체는, MSF/CD를 도입하기로 결정했다. PM 김 씨를 제외한 내부 개발자들은 제대로 된 개발 방법론대로 프로젝트를 진행해 본 적이 없다. PM은 부랴부랴 개발자들에게 개발 방법론을 교육하기로 결정하고 MSF를 교육할 수 있는 기관이나 강사를 수소문했다.

MSF를 전문적으로 교육하는 기관은 찾지 못했고, 주위의 실력 있는 분석가들이나 설계자들의 말로는 설계 경험이 없는 개발자라면 UML에 대한 교육부터 실시하는 것이 좋을 것이라고 한다. PM 김 씨는 UML 교육을 실시하기로 하고 비싼 교육비를 투자해 UML을 교육하는 기관에 교육을 의뢰했다.

UML을 강의하러 온 강사는 래쇼날 로즈(Rational Rose)로 강의를 진행했고, 사흘간 교육에 참여한 개발자들은 UML을 사용한 설계 기법에 감동하는 것 같았다. 교육이 끝난 후 김 씨는 개발자들을 모아놓고 이번 프로젝트는 MSF/CD로 진행될 것이니 수료한 UML 교육에서 얻은 지식을 기반으로 MSF를 공부해보라고 지시했다.

개발자들은 인터넷을 뒤지고 책을 사보면서 열심히 공부했다. 김 씨는 꽤 만족했고, 개발 팀장에게 MSF/CD로 진행했을 때의 일정을 짜보라고 지시했다. 김 씨는 모든 산출물을 작성할 필요는 없으니 개발자 입장에서 빠르게 프로젝트를 진행할 수 있는 일정이 중요하다고 이야기했다. 며칠 뒤 김 씨가 받아본 일정은 다음과 같았다.

Business Context Diagram 7월 15일
Object Abstract Table 7월 20일
Class Diagram 7월 25일
… …

일정을 받아본 김 씨는 당황했다. “어떻게 Business Context를 설계하는 시간하고 객체를 설계하는 시간하고 같을 수가 있지? 그리고 Use Case가 왜 없는 거야? 데이터베이스 설계 방안은?” 김 씨는 일정을 작성한 개발 팀장을 불러서 의문점들에 대해 물어봤다. 개발 팀장의 답은 대강 다음과 같았다.

“다이어그램 그림 몇 장 그리는데 시간이 그리 오래 걸릴 리가 없잖아요?”
“Business Context Diagram의 도형이 뭘 뜻하는지 잘 몰라서, 일단 시작해놓고 보면 그 정도 걸릴 것 같아서요.”
“Class Diagram은 어차피 코드 작성해 나가면서 수정하는 거니까 대강 시간을 그 정도 잡았죠.”
“데이터베이스 설계 방안은… 나중에 페이지 설계가 나오면 그대로 해야죠.”

그리고 이어진 원망 같은 한 마디, “Object Interaction Diagram을 어떻게 그리죠? 엑셀로 그리면 되나요?” 이후 다른 대화는 계속됐다.

“Work Flow Diagram 작성은 누가 해?”
“전부 다 같이 하는 거죠”
“요구 분석에 따른 업무 분장은 안 하고?”
“몇 명 안 되는 개발팀에서 무슨 요구 분석에 따른 업무 분장을 해요?”

두 번째, “설계를 하지 않겠다는 뜻인가?”
필자는 모 대학 학사 행정 프로젝트의 기획 문서를 본 적이 있다. 이름만 대면 다들 알만한 큰 규모의 SI 업체에서 진행했는데, XXX-CBD라는 처음 보는 개발 방법론을 적용해 개발하겠다고 적혀 있었다.

교육 및 컨설팅으로 참여한 필자가 개발 방법론을 모른다는 것은 시쳇말로 ‘쪽팔리는’ 일이었고, 필자는 그 개발 방법론의 정체를 파악하기 위해 오만 서적과 인터넷 사이트들을 뒤져봤다. 하지만 그 미지의 개발 방법론의 정체를 파악하지 못했고, 결국은 업체의 과장님께 넌지시 물어봤다.

“XXX-CBD가 뭡니까?”
“아, 저희 회사에서 개발한 닷넷 개발 방법론입니다. XXX-CBD.NET이라고 부르는데 MSF/CD에 기반한 개발 방법론이죠”

필자는 그 개발 방법론에 대해서 알아보려고 그 회사의 홈페이지, 구글 등을 뒤져보고 개발 방법론을 정리한 문서를 찾아보려고 노력했으나 별 소득이 없었다. 결국은 HTML 한 페이지로 된 문서를 찾았는데 단지 개념적 설계·논리적 설계·물리적 설계라는 MSF/CD에서 이야기하는 3단계 스테이지밖에 없었고, 결론은 “특별한 개발 방법론이 아니고 MSF/CD를 그대로 사용하는구나”라고 생각할 수밖에 없었다.

MSF/CD가 그래도 괜찮은 개발 방법론이고, 회사 나름대로 개발 방법론도 정의하고 있으니 그 부분에 대해서는 그다지 걱정할 필요가 없지 않겠는가. 다른 회사의 경험 많은 분석가들이 정의해 놓은 개발 방법론에 대해 자세히 알 필요도 없을 뿐더러 왈가왈부하기도 어려운 입장이고 해서 2주로 예정된 교육만 잘 진행하면 별 어려움이 없을 거라고 생각했다.

교육을 하면서 느낀 것은 개발자들이 의외로 닷넷을 잘 모른다는 것이었고 MSF를 잘 모른다는 것이었다. MSF를 기반으로 하지 않은 MSF/CD는 이름을 그렇게 붙이는 것만으로도 이상한데, MSF/CD를 각 팀원에게 알아보라고 지시하고, 팀원들은 인터넷을 떠돌며 찾은 몇 개의 문서파일을 보고 산출물 리스트 작성 방법만 연구를 하는 것은 더욱 이상했다.

UML을 공부할 때 Use Case만 보더라도 제대로 표현하기 위해서는 몇 권의 서적을 읽고 많은 기간 연구를 해야 제대로 작성할 수 있는 법인데, 설계를 너무 가볍게 생각하는 것은 아닐까란 생각까지 들었다. 더욱 놀라운 것은 개발을 위해서 래쇼날 로즈를 구입한다는 것이었고, 개발을 위해서 래쇼날 로즈 전문 교육을 이수하도록 하겠다는 것이었다.

이상한데? MSF/CD 기반 개발 방법론인데 왜 래쇼날 로즈를 쓰지?

물론 Rose를 사용하면 절대 안 된다는 이야기는 아니지만, 당시에는 Rose의 C# 지원 도구가 발표되기 전이었고, Use Case라든가 Sequence, State 등의 다이어그램의 작성을 권하지 않는(아예 개발 방법이 틀리므로) MSF/CD에서는 가격에 비해서 그리 활용도가 높지 않을 것은 뻔한 일이므로, 엉뚱한 곳에 돈을 쓴다고 생각할 수 밖에 없었다. 나아가서 “설계를 하지 않겠다는 뜻인가?” 하는 생각까지 들었다.

얼마 후, 미국에서 객체지향을 전공한 설계 담당 프리랜서 직원이 고용됐다. 1개월 또는 2개월간 근무하면서 설계 산출물들을 작성할 것이라는데, 전체 학교의 모든 행정 시스템을 커버하는 시스템의 설계 산출물을 1명의 분석가가 한 달만에 다 작성하다니 말이 안 되는 일이었다.

필자와 프로젝트와의 인연은 거기까지였다. 그 후 어떻게 일이 진행됐는지는 자세히 알지 못하지만, 프로젝트가 막바지에 달했을 때 우연히 살펴본 프로젝트 산출물은 MSF/CD와는 거리가 멀었다. 그 산출물들이 XXX-CBD에 기반한 것이라고 말한다면, 필자는 그 방법론에 대한 문서를 열람한 적 없으므로 할 말 없지만, 더욱 기가 막힌 것은 설계 산출물의 내용과 작성된 프로그램은 완전히 다르다는 것이었다. 설계 따로 개발 따로의 전형적인 경우를 필자는 처음 봤다.

나중에 들은 개발 담당자들의 말은 더 기가 막히다.

“원래 그렇게 하는 거 아닙니까?”
“이론대로 다 하고 설계대로 다 하고자 하면 프로그램을 어떻게 짭니까?”

MSF는 개발 방법론이 아니다
MSF를 기반으로 하는 MSF/CD, MSF/EA 등을 공부할 때 명심해야 하는 것은, MSF는 개발 방법론이 아니라는 것이다. MSF는 이름 그대로 프레임워크이다. MSF는 솔루션을 작성하기 위한 모든 방법을 포함하는 개발 프레임워크를 지칭한다. MSF에는 프로젝트에 알맞은 팀을 구성하는 방법, 프로젝트의 라이프 사이클, 마일스톤 버전을 지정하고 버전 관리하는 방법, 프로젝트를 스타트하고 종료하고 리스크를 관리하는 방법 등이 포함되어 있다.

MSF는 마이크로소프트 내부에서 팀 단위로 개발을 관리하기 위해 쓰이던 기법이다. MSF는 개발을 관리하기 위한 교육, 검토, 팀 구성 모델 등을 모두 포함한다. MSF는 두 가지 모델과 다섯 가지의 훈련 사항들을 포함하고 있다.

◆ MSF Team Model : MSF에는 프로젝트를 진행하기 위한 팀 결성 모델이 들어 있다. 팀 모델은 메이저 프로젝트와의 연결을 위한 다른 팀과의 연결 고리와 프로젝트의 목표를 명확하게 할 수 있도록 팀을 구성할 것을 명시한다.

◆ MSF Process Model : MSF Process Model은 지정한 시간에 프로젝트를 완수하고 전달(deliver)하기 위해 프로세스를 조직하는 방법을 명시한다. 마일스톤 버전을 통해 위험 요소를 제거한 후 프로세스를 진행하도록 하고 있다.

◆ MSF Project Management Discipline : MSF에는 팀 단위 개발에서 프로젝트를 성공적으로 진행하기 위한 간소화되고 합리화된 프로젝트 관리 기법이 포함된다.

◆ MSF Risk Management Discipline : MSF에는 비용이 많이 소모되는 액티비티를 최소화하고 프로젝트의 진행 중 위험요소를 최소화하기 위한 위험요소 관리 기법이 포함된다.

◆ MSF Readiness Management Discipline : MSF에는 프로젝트를 성공적으로 수행하기 위해서 팀원들이 공통적으로 숙지해야 할 사항과 성공적인 수행을 위해 반드시 갖춰야 할 스킬을 관리할 수 있는 기법이 포함된다.

MSF를 다 설명한다는 것은 지면 관계상 불가능한 일이므로 MSF Team Model만 잠시 살펴보도록 하자. MSF Team Model은 계층 구조(Hierarchical Model)로 구성되지 않고 원형 구조(Circular Structure)로 구성된다. 각 구성 요소들은 같은 중요도를 갖고 프로젝트에 참여해야 하며, 여러 요소들이 동적으로 커뮤니케이션하며 프로젝트를 진행하는 구조를 지향한다.

MSF Team Model의 핵심은 커뮤니케이션에 있다. MSF Team Model은 프로젝트의 ‘보스’를 지정하지 않을 것을 권고한다. 프로젝트의 보스가 정해지게 되면 모든 팀들의 의사소통 창구가 하나로 통일되고 어떤 의사소통의 결과에 보스의 생각이 개입되며 자유로운 의사소통을 방해하는 요소가 될 수 있다. 보스가 의사소통 수단이 되면 팀원들간의 의사소통은 그만큼 줄어들게 된다.

프로젝트의 목표를 정확하게 파악하고 범위를 명확하게 하기 위해서는 팀원들간의 의사소통이 그만큼 중요함을 강조하는 모델이다. MSF Team Model은 각 팀이 대화를 하면서 각자의 책임을 규정하는 등의 프로젝트 진행이 자연스럽게 이뤄지게 된다는 것이 목적이다.

<그림 2>에서 보는 바와 같이 팀 모델이 조직됐다면 역할을 할당한다. 역할은 각 팀들의 기능적인 구획에서 반드시 수행해야 하는 일들을 팀별로 할당하는 것이다. 프로젝트에 ‘보스’가 없는 상황에서 할당한다는 것이 우리나라의 관습에는 그다지 어울리지 않는 형태일지 모르지만, MSF는 <그림 3>에서 조직된 팀들이 해야 할 일들을 명시한다.

MSF에서 각 역할은 드롭다운 형식으로 세분화된다. 여섯 개의 각 역할은 여러 개의 기능적인 분할로 나눠지며 각 기능 분할은 여러 책임 단위(responsibility)로 구성되고, 각 책임 단위는 여러 개의 작업(task)로 이뤄진다. 팀원의 구성에 따라 다르겠지만 하나의 책임 단위에 두 명 또는 그 이상의 개발자들이 투입되는 것이 정석이다.

MSF는 <그림 4>과 같이 역할 배정의 구조를 정하고 각 역할에서 어떠한 책임 단위를 구성해야 하는지를 명시한다. 또한 MSF에는 팀을 조직할 때 각 팀의 크기를 어떻게 결정할 것인지에 대한 명세를 포함하고 있다. MSF가 <그림 3> 또는 <그림 4>와 같이 팀 모델을 제시하고 있지만 각 조직들은 주어진 역할에 따라 복잡도, 크기, 위험 부담, 그리고 각 참여자들이 익히고 있어야 할 기술의 숙련도가 달라져야만 한다. 이를 위해서 MSF는 다음과 같은 방법을 제안한다.

◆ 각 구현 단위와 의사소통 단위, 낮은 등급의 프로세스 단위 등의 조직을 이용해 큰 팀을 작은 팀으로 분할한다.

◆ 다른 팀들을 이끌 수 있는 한 팀을 지정한다.

◆ 핵심이 되는 한 팀이 전체 프로젝트를 관리하도록 한다.

이렇듯이 MSF의 팀 모델은 프로젝트를 수행하기 위한 조직 구성의 모든 해법을 갖고 있다. 프로젝트 관리 경험이 있거나 CMM을 접해본 독자라면 이러한 조직 구성이 프로젝트를 성공적으로 이끄는 데 결정적인 역할을 한다는 것을 실감하고 있을 것이다. MSF의 팀 모델은 이 외의 팀 조직을 위한 다른 많은 요소들을 포함한다.

산출물 리스트만 따른다고 개발 방법론을 준수하는 건 아니다
앞서 살펴봤던 내용은 MSF의 Team Model의 20% 정도에 지나지 않는다. MSF는 팀 모델 이외에도 위험 관리, 프로젝트 라이프 사이클의 결정, 프로젝트를 시작하는 데 있어서 지켜야 할 사항, 프로젝트를 기획하는 방법, 솔루션을 개발하는 방법 등에 대한 모든 명세들을 총망라한다. MSF는 CMM에 못지 않을 정도의 규모와 상세를 갖고 있다.

MSF는 이러한 규약을 100% 준수하지는 못하더라도 비슷한 조직을 구성할 수 있는 능력이 있는 프로젝트팀에 적용될 수 있다. 사람들 모아놓고 MSF/CD라고 말한다고 무조건 MSF/CD대로 프로젝트를 진행할 수 있는 것은 아니라는 뜻이다.

MSF는 프로젝트의 진행에 필요한 모든 조건을 명시한다. MSF가 개발 방법론이 아니라 개발 프레임워크라고 불리는 이유가 여기에 있다. 개발 프레임워크는 개발 방법론을 적용할 때 그 기반이 되는 개발의 기본 방법들의 정의라고 할 수 있다. MSF를 파악하고 그 내용대로 조직을 정비하고 모델을 따를 수 없는 조직이라면 당연히 MSF 기반으로 만들어진 MSF/CD, MSF/AD 등을 개발 방법론으로 채택하는 것이 어려워지기 마련이다.

필자도 예전에 래쇼날 로즈 교육을 수강한 적이 있었는데, 객체지향 프로그래밍 교육이라기보다는 도구 사용법에 대한 교육이었다는 느낌이었다. 강사는 노트북에 준비해온 입력 산출물을 입력하고 산출물이 자동으로 작성되며 코드를 생성하는 시뮬레이션을 시연해줬다. 수강하는 학생들이 모두 감동했음은 자명하다.

하지만 문제는 툴의 성능이 아니다. 한 카피가 웬만한 고급 승용차 값을 호가하는 소프트웨어가 그 정도의 성능을 갖고 있는 것은 당연하다. 아무리 훌륭한 자동차를 가졌다 하더라도 운전을 못한다면 비용만 낭비한 셈이 된다. 훌륭한 도구를 갖고 있다면 그 도구를 훌륭하게 사용할 수 있는 능력이 있어야 한다.

그렇다면 MSF/CD는?
MSF/CD는 CBD가 솔루션 개발의 대세가 되는 무렵 마이크로소프트가 MSF에 따라 구성된 팀 모델과 프로세스 모델을 사용하며, 여러 MSF가 제시하는 방법들을 따라 컴포넌트 기반 솔루션을 구축하고자 할 때 사용하는 방법이다. 국내에 출간된 MSF/CD 서적을 봐도 MSF/CD의 장점은 프로토타이핑을 통한 빠른 개발 진척도 지원이라고 한다.

또한 MSF/CD는 다른 개발 방법론(예를 들면 RUP)들이 놓치고 있는 물리적인 설계를 잘 지원하도록 구성되어 있으므로 빠르고 정확한 개발을 진행할 수 있는 닷넷 기반 솔루션 개발에 가장 알맞은 방법이라고 MSF/CD를 소개한다.

하지만 그 한권의 책을 읽었다고 MSF/CD대로 프로젝트를 진행할 수 있는 것은 결단코 아니다. MSF/CD는 MSF를 소화할 수 있는 조직이 되어야 제대로 진행할 수 있다. MSF/CD의 산출물 리스트를 봐도 RUP에서 권장하는 산출물 리스트들과는 거리가 멀다. Use Case Diagram은 작성하지도 않도록 되어 있다.

조직의 구성이 트리 구조로 되어 있는(트리 형태의 계층 구조로 조직된) 프로젝트 팀에서는 팀원들간의 의사소통이 원활하지 않다. 또한 한 사람의 PM이 프로젝트를 책임지고 있는 경우라면 MSF/CD를 적용해 개발하는 것은 오히려 개발을 지연시키는 결과를 초래할 수 있다. MSF에는 4가지의 방법론이 포함되어 있다.

[1] MSF/AD(Application Development)
[2] MSF/CD(Component Design)
[3] MSF/ID(Infrastructure Deployment)
[4] MSF/EA(Enterprise Architecture)

4가지 설계 방법론과 개발 방법론은 모두 MSF를 기반으로 한다는 것을 잊어서는 안 된다. MSF는 2～3명의 소규모 개발팀부터 몇 백명의 대규모 개발팀까지를 커버할 수 있는 프레임워크라고 하는 것은 MSF를 잘 이해하고 이행하는 데서 비롯되는 것이다. 산출물 리스트만을 외우고 있다고 MSF가 되는 것은 아니다.

<그림 5>에서 볼 수 있는 MSF Process Model 또한 MSF/CD를 기반으로 개발할 때 프로세스 진행의 기반이 된다. MSF를 제대로 파악하지 못하고서는 MSF/CD를 제대로 사용할 수 없음은 당연하다. MSF의 여러 모델을 파악하지 못한 조직은 MSF/CD를 사용하는 것이 오히려 프로젝트가 실패하는 원인이 될 수 있다는 것이다.

MSF/CD가 영원할 것인가?
한 마디로 말하자면 “결코 그렇지 않다”라는 것이다. MSF/CD의 설계 원칙은 Event Driven이다. Workflow Process Model도 이벤트에 따라 작성되고 객체 상호 작용 또한 UP의 Sequence Diagram에서 익숙하던 시간의 흐름이나 객체의 상태 변화를 통해 나타내는 것이 아닌 이벤트의 발생에 따라 기술된다. MSF/CD는 컴포넌트의 작성과 상호작용에 너무 치중됐으므로 유연한 객체 구조를 작성하는 것은 오로지 개발자의 능력에 의존하는 결과를 낳기 쉽다.

MSF/CD는 MSF에 따라 마일스톤 소프트웨어의 작성이 우선되어야만 프로젝트 진행 과정에서 발생할 수 있는 위험 부담을 줄이고 일정을 지킬 수 있는 구조로 되어 있다. MSF/CD의 산출물 리스트대로 그림만 그리다가는 제대로 된 소프트웨어의 작성이 거의 불가능해지는 방법이 바로 MSF/CD이다.

여러 가지 이유로 MSF는 그리 오래 버틸 수는 없을 것 같아 보인다. CMM이 거의 표준이 되다시피 했고, MSF의 팀 모델이나 프로세스 모델이 CMM/CMI의 그것과 닮아 있지만 수정되어야만 할 것이다. 또한 닷넷은 전형적인 객체지향 개발 모델이므로 이벤트 지향적인 방법으로 설계하는 MSF/CD는 닷넷 개발에 어울리지 않는다는 것이 필자의 생각이다.

필자 역시 MSF/CD를 따라 프로젝트를 진행해 본 경험이 있지만, MSF/CD에서는 OOAD를 제대로 수행할 수 없고, 필자가 몸담은 조직을 MSF대로 재구성할 수도 없는 형편이라 객체지향 디자인시에는 개발자 개개인의 능력에 크게 의존할 수밖에 없었다. 다행이라면 마일스톤 작성을 통해 위험요소를 제거하며 프로젝트를 진행할 수 있었다는 것이 100% 성공적이지는 못하지만 그럭저럭 실패하지는 않을 수 있었던 이유였던 것 같다.

마이크로소프트가 다른 개발 방법론을 준비하고 있다는 소식이 여기저기서 들려오기 시작한다. 공식적인 채널을 통해서는 듣지 못했지만 마이크로소프트가 MSF를 포기한다는 것이 개발자들 사이에서 널리 퍼지고 있다. MSF/CD를 잘 알고 프로젝트 관리 이론과 UML 등을 잘 아는 개발자라면 누구나가 예측했을 법한 이야기일 것이다. 비주얼 스튜디오 2005를 셋업해보고 예제 프로그램을 몇 개 작성하다 보면 누구나가 신선한 충격을 느끼게 될 것이다.

프로젝트 관리에도 기본이 있다
필자는 C#을 교육할 때 교육 시간이 100시간이라면 추상화를 교육하는 데 60시간 이상을 할애한다. C#이라는 언어는 어떻게 변할지 모르지만 객체지향 이론과 추상화 이론, 타입 이론 등을 잘 알고 있다면 언어가 어떻게 변하든지 잘 적응할 수 있기 때문이다.

필자의 경우 C#이라는 프로그래밍 언어는 프로그램을 작성하기 위한 도구일 뿐, 프로그램을 작성하는 데는 추상화라는 도구가 가장 강력하고, 튼튼한 이론적 뒷받침이 좋은 프로그램을 작성할 수 있는 가장 바른 방법이라고 믿어 의심하지 않는다.

CMI와 SPICE를 공부해보면 프로젝트를 관리하는 기법에 있어서 MSF와 동일한 이론이 뒷받침되어 작성됐다는 것을 알 수 있다. 훌륭한 개발자가 되기 위해서는 튼튼한 이론적인 뒷받침이 되어야 함이 틀림없듯이 훌륭한 프로젝트 관리자가 되기 위해서는 프로젝트 관리 기법에 대한 튼튼한 이론적인 뒷받침이 있어야 한다.

전문 개발자나 프로젝트 관리 전문가가 되기보다는 Visio나 로즈, 파워포인트의 활용 전문가가 되고 싶다면 같은 개발 방법론(아마도 필자가 좋아하는 Nogada Technology 개발 방법론일 것이다)으로 산출물의 형태만 바꾸며 프로젝트를 진행해도 별 상관없다. 하지만 정말 성공적인 프로젝트를 진행하고 싶으면 프로젝트 진행 방법론을 잘 이해해야 한다.

또한 진행하는 프로젝트가 조선이나 건축 프로젝트가 아닌 IT 솔루션 프로젝트라면 프로젝트 관리 능력에 필적할 만한 IT 기술도 갖고 있어야 한다. 프로젝트 관리라는 산은 멀고도 험하기만 하다. @

* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다.