[지디넷코리아]필자는 3년 전쯤 프란시스 포드 코폴라 감독의 ‘지옥의 묵시록 리덕스(Apocalypse Now Redux)’라는 영화를 본 적이 있다. 1979년에 만들어진 영화를 재편집해 3시간이 넘는 긴 영화로 만들어 재개봉한 이 영화는, 영화를 전공하지 않은 필자로서는 잘 모르겠지만, 볼 때는 지겨운 부분이 있긴 해도 보고나면 뭔가 남는 것이 있는(조금은 당황스럽지만) 좋은 영화였다.
필자는 객체지향 프로그래밍을 강의할 때 영화 대본의 예를 들어 객체지향 프로그래밍을 설명하곤 한다. 객체지향 프로그래밍을 하다 보면 객체(클래스가 아닌)를 정하는 일은 영화나 연극 작업에서 배역을 정하는 일과 거의 비슷하고, 지문, 소품, 대화 등을 객체의 상태, 메시지, 데이터로 생각하면 영화 시나리오를 쓰는 일과 프로그래밍을 위한 설계 작업이 거의 비슷하기 때문이다.
영화와 소프트웨어의 비슷한 점
객체지향적으로 문제를 분석하는 과정이 정형화되지 않은 사용자의 요구를 대본으로 옮겨 쓰면서 어떤 배역이 있는지를 분석하는 과정이고, 영화 대본이 배역(객체)끼리의 대화(메시지)이므로, 객체지향 프로그래밍을 위한 문제를 분석하는 과정(정규화하는 과정)은 소프트웨어의 개발 절차상 가장 시간이 오래 걸리는 작업이라고 볼 때, 정말 영화와 소프트웨어 사이에는 비슷한 점이 너무 많다.
 |
| <그림 1> 영화 작업과 흡사한 OOP |
영화를 만드는 과정의 차이
한 편의 영화가 만들어져서 영화관에서 보게 되는 그 영화를 ‘프로그램’이라고 한다면, 영화를 만드는 과정, 즉 ‘영화 만들기’가 바로 ‘프로젝트’가 된다. 세계에서 영화를 가장 많이 제작하는 할리우드에는 바로 그 ‘영화 만들기’에 대한 엄청난 노하우가 있을 것이고 정형화된 과정도 있다. 필자의 개인적인 생각으로는 한국영화가 할리우드를 뛰어넘기 가장 어려운 부분이 바로 이런 부분이 아닐지 싶다. 얼마 전 ‘태극기 휘날리며’라는 영화를 보고 느낀 점은 “한국영화가 정말 많이 좋아졌구나”가 아니고 엉뚱하게도 “스티븐 스필버그가 영화를 과연 잘 만드는구나”였다.
필자의 그런 이야기를 들으면 사람들은 어쩔 수 없는 ‘제작비의 문제’라고 이야기를 하지만 그런 말에 동의할 수 없는 이유가 있다. 필자가 알기로 ‘태극기 휘날리며’의 제작비는 120억원이 넘었고(달러로 환산하면 1000만 달러가 넘는 큰 액수이다) 스필버그의 ‘라이언 일병 구하기’의 제작비는 6000만 달러라고 들었다. 주연 배우인 톰 행크스가 받은 출연료가 2000만 달러 남짓했었고, 국내 영화 스탭들의 인건비는 할리우드 스탭들의 수입과는 비교도 안 되는 수준이라면 할리우드 예산 6000만 달러와 한국 영화 예산 120억원은 거의 비슷한 수준으로 생각해도 되는 것 아닐까?
그렇다면 ‘태극기 휘날리며’를 만든 감독이 스필버그와 비교했을 때 그렇게 역량이 많이 떨어진다고는 생각할 수 없고, ‘태극기 휘날리며’에 출연한 배우들의 연기도 훌륭했고, 촬영기술도 ‘라이언 일병 구하기’의 초반 30분에 보여주는 카메라 흔들기와 개각도 촬영의 노하우를 아는 사람들이 비슷한 기법으로 촬영했다고 볼 때, 어떤 부분이 ‘라이언 일병 구하기’와 ‘태극기 휘날리며’의 차이를 만들 이유였는가를 생각해보면 ‘영화를 만드는 과정’이 어떠했느냐가 가장 큰 요소였다고 생각할 수밖에 없어진다.
‘태극기 휘날리며’라는 최종 산출물을 만들기 위한 프로젝트가 어떻게 진행되었는지 필자는 잘 알지 못하지만, 그 프로젝트가 잘 진행되었더라면 제작비를 조금 더 절감하면서 더 좋은 영화를 만들 수 있지 않았을까 하는 것이 필자의 견해이다. 영화를 좋아하고 영화에 대한 지식이 필자보다 월등한 독자들이 훨씬 많을 것이므로 영화에 대한 이야기는 여기까지만 하도록 한다(필자는 영화를 좋아하는 사람일 뿐, 영화 관계자가 아니고 IT 컨설턴트이므로 영화 지식의 무지에서 비롯된 여러 오류들은 널리 이해해 주리라 믿는다).
영화 이야기를 하는 이유
IT 프로젝트를 성공적으로 진행하는 방법에 관한 글에서 이렇게 영화 이야기를 장황하게 늘어놓는 이유는 필자가 10년쯤 전 서점에서 구입해 읽었던 한 영화 관련 서적에서 다음과 같은 글귀를 읽은 적이 있기 때문이다.
“감독은 영화를 완성하지 않는다. 적당한 시점에서 영화 만들기를 포기하는 것이다.”
이 말은 영화 ‘지옥의 묵시록’을 만들기 위해서 개인 재산을 모두 저당 잡히고 영화 만드는 과정에서 지게 된 빚을 갚기 위해 억지로 ‘대부 2’를 만들었던 프란시스 포드 코폴라 감독이 ‘지옥의 묵시록’을 만들면서 했던 말이다. 영화를 책임지는 사람은 바로 감독이고, IT 프로젝트를 책임지는 사람은 바로 PM이다. 영화 산업은 IT 산업과 비교해 훨씬 긴 역사를 가지고 있으므로 영화 만들기 내에서 세분화된 직책들로 구성되어 있다.
IT 프로젝트 역시 마찬가지다. 프로젝트를 성공적으로 이끌기 위해서는 세분화된 직책들이 구성되어 있어야 한다. 공들여 만든 영화가 비용과 상관없이 ‘벤허’가 되느냐 ‘조폭마누라’가 되느냐는 프로젝트의 진행에 달려 있다고 해도 과언이 아니다. 물론 영화계에는 오슨 웰즈나 쿠엔틴 타란티노와 같은 사람이 있어서 특별한 프로젝트의 관리 없이도 위대한 작품을 만들어내는 사람들이 있다.
IT 업계에도 찰스 시모나이나 빌 조이 같은 사람들이 있다. 하지만 ‘전함 포템킨’이나 ‘시민 케인’과 같은 영화보다는 ‘진주만’이나 ‘스파이더 맨’과 같은 영화들이 훨씬 많은 돈을 벌어들였다. IT에서도 그렇다. ‘불후의 걸작 프로그램’을 만들어 내는 것은 GNU나 Jakarta 같은 곳에 맡기는 것으로도 충분하다. SI 프로젝트에 투입되는 경우라면 독불장군이 되어 ‘시민 케인’을 만들기보다는 영화의 한 부분의 충실한 스텝이 되어 ‘스타워즈’를 만들어내는 것이 산업적인 측면에서 훨씬 더 올바른 경우임에 틀림없다.
왜 프로젝트 관리를 해야 하는가?
단순하게 조선소에서 배를 짓는 일에 대해서 생각해보자. 배는 인간이 만들어낼 수 있는 인공 건조물 중에 가장 큰 규모의 것이고 이런 어마어마한 규모와 예산이 투입되는 일을 프로젝트 단위의 계획 없이 진행하는 것은 불가능하다. 대우중공업이나 현대중공업 같은 대규모의 조선소에 가면 수만 명의 직원이 근무하고 있고, 수만 명의 직원이 수십 대의 배를 동시에 건조한다.
설계 부서에서 하루에 작도되는 도면의 양만 해도 어마어마하고, 건조 부서에서 하루에 생산되는 블럭의 무게만 해도 수만 톤을 넘는다. 조선소라는 공간이 제 아무리 넓다 하지만(실제로 대우중공업이나 현대중공업은 작은 시 규모의 면적을 가지고 있다) 제한된 공간을 가지고 있게 마련이고, 웬만한 아파트 한개 동 크기의 선박 블럭을 놓을 수 있는 장소에는 한계가 있다.
만약 설계 부서에서 도면을 제 시간에 작도해 건조 부서로 제 시간에 전달했지만, 건조 부서에서 지정한 시간 내에 도면대로 블럭을 완성하지 못했다면 다른 블럭을 건조하기 위한 장소의 확보가 어려워지고, 한 척의 배를 만드는 일정의 지연으로 인해 여러 척의 선박 건조 일정에 차질을 빚게 된다. 또한 설계 부서에서 며칠까지 도면 작업을 완료했다 하더라도 완료된 도면으로 블럭을 작업할 장소가 건조 부서의 인력이 없다면 설계와 건조가 탄력적으로 운영될 수 없게 된다.
이런 일정 조율은 설계 부서의 인원이나 건조 부서의 인원들이 전화 또는 회의로 정확하게 맞춰 진행될 수 있는 일이 아니다. 하물며 선박의 건조에는 설계 부서 또는 건조 부서뿐만 아닌 회계 부서, 자재 부서 등 수없이 많은 부서의 인원들이 동원되고, 동원되는 모든 인원과 자재 등의 자원(resource)이 유기적으로 결합되어 탄력적으로 운영되어야 한다. 투입되는 자원의 활용은 각 부서가 할 일이 아니고 각 부서를 유기적으로 결합해 탄력적으로 운영하는 관리 부서가 따로 필요하게 된다.
‘선택사항’이 아닌 ‘생존의 필수 요건’
Davidson Frame 박사는 그의 저서 “Managing Project in Organization”에서 다음과 같은 말을 했다.
“불확실성 시대의 생존 열쇠는 ‘탄력성’이며 어떤 변화에도 대처할 수 있는 프로젝트 마인드는 바로 ‘탄력성의 열쇠’이다. 이것은 이제 ‘선택사항’이 아닌 ‘생존의 필수 요건’이다.”
실제적으로도 조선소 또는 건설회사에서는 이러한 탄력적인 운영이 불가사의할 정도로 잘 운영되고 있다(필자는 조선소에서 근무해 본 적이 있다). 수만 톤의 배를 동시에 50대씩 건조하면서도 큰 불협화음이나 사고 없이 잘 진행된다. 역사가 오래된 조선이나 건설업 같은 경우에는 이러한 프로젝트의 관리 기법에 수백 년 전부터 도입되어 진행되고 있지만 역사가 얼마 되지 않은 IT의 경우에는 ‘프로젝트’라는 개념이 도입되기 시작하는 시점에 있다.
바로 프로젝트 개념의 관리와 가시성이 필요한 시점이 도래했다는 것이다(사실 배를 짓는 입장에서도 종이배를 짓거나 호수 위를 떠다니며 연인들의 사랑을 관리해 주는 나룻배 정도를 짓는 것이라면 프로젝트 관리가 별로 필요하지 않다. IT 프로젝트에서 프로젝트 관리의 중요성이 대두된 시점은 대 기업들이 회사의 관리에 IT를 도입하면서 시작되었는데, 이는 EJB나 닷넷과 같은 기업형 개발 시스템이 도입되는 시기와 일치한다). 프로젝트 관리에는 다음과 같은 개념들이 도입되어야 하고 이미 실천되고 있다.
[1] PMIS(Project Management Information System)
[2] EPM(EnterPrise management System)
[3] PPM(Project Portfolio System)
[4] EIS(Executive Management System)
프로젝트란 유일한 제품, 서비스, 프로세스, 결과, 계획을 생성하기 위해 수행되는 일시적인 행동이나 노력(A Project is a temporary endeavor undertaken to create a unique product, service, process, result, plan)을 말한다.
 |
| <그림 2> 프로젝트 |
프로젝트라는 것이 앞에서 이야기한 것이라면 프로젝트 관리라는 것은 다음과 같이 설명된다.
“프로젝트 요구사항 (Requirement)을 만족시키기 위하여 프로젝트 활동에 관련된 지식(Knowledge), 기술(Skill), 도구(Tools) 및 기법(Technology) 등을 적용하여 수행하는 제반 관리 활동”
프로젝트 관리를 위해서는 무엇이 필요한가?
프로젝트 관리를 위해서는 무엇이 필요할까? 한마디로 이야기하면 프로젝트 관리 조직(PMO: Project Management Office/PSO: Project Support Office)이 필요하다. PM이 제 아무리 능력이 뛰어난 사람이라도 유기적으로 다른 조직과 융합되어야 하는 프로젝트의 모든 부분을 감당할 수는 없다.
최근의 프로젝트들은 예전의 목표 지향적 관리보다는 미래 지향적 관리 기법이 필요하다. 예전의 목표 지향적 관리 기법이었다면 PM이 원가와 일정, 품질 관리를 통합하는 업무만으로 충분히 이룰 수 있었지만, 프로젝트의 규모가 커지고 탄력적으로 운영되어야 하는 현 시점에서는 목표 지향적 관리 기법이 그렇게 올바른 방법이 아님이 증명되었다.
 |
| <그림 3> 목표 지향적 관리와 미래 지향적 관리 |
<그림 3>에는 PMBOK(Project Management Body of Knowledge)라는 용어가 등장한다. 이는 미국 프로젝트 관리 협회인 PMI(Project Management Institute)에서 정의한 프로젝트 관리 분야의 범용적인 표준 체계를 말한다. PMBOK에 대한 내용은 책 여러 권의 분량으로도 부족하므로 관심 있는 독자는 PMBOK에 관련된 책을 구해서 읽어보기를 권한다.
전사적 입장에서 보는 프로젝트 관리를 위하여 CMMI를 도입하고자 한다면 한 사람의 PM이 감당할 수 없는 여러 일들을 해야 한다. 프로젝트 관리에서 이야기하는 프로그램이라는 것이 흔히 개발자들이 이야기하는 소프트웨어 프로그램이 아닌 서로 관련 있는 프로젝트들이 유기적으로 관리되는 프로젝트들의 그룹을 이야기하므로, 기업의 프로젝트(KFP나 ERP 같은 큰)를 탄력적이고 유기적으로 이끌어 가기 위한 다른 조직이 필요하게 된다. 그 조직이 바로 직접적으로 수익을 창출하는 조직이 아닌 조직들의 프로젝트를 관리하고 기업의 표준화를 이끌어나가는 조직인 PMO가 된다. 어떻게 보면 필요 없는 PMO 조직을 다른 부서에서 먹여 살리는 것 같은 느낌이 들지만 50인 이상의 조직에서는 반드시 필요한 조직이 된다.
PM 김씨의 고민 이야기
PM 김씨는 ERP 프로젝트를 2004년 9월에 시작해야 한다. 김씨는 얼마 전 마이크로소프트에서 개최한 세미나에 참석했었고, 마이크로소프트가 진행하고 있는 엄청나게 많은 제품에 기가 질려 돌아왔다. 특히 김씨를 힘들게 하는 것은 닷넷 프레임워크 2.0과 비주얼 스튜디오 2005에 관련된 새로운 정보였다. 김씨는 세미나에 참석해서 받은 비주얼 스튜디오 닷넷 2005를 컴퓨터에 셋업하고는 기가 질렸다. 이전 버전과의 호환성을 유지할 수 없는 것은 아니지만 새로운 개체가 엄청나게 많이 등장했다.
MDAC 9.0이 과거 2.7에서 이렇게 한 방에 버전업이 될 수 있는 건지 아니면 오타인지에 대한 구분도 가지 않는 상태이고, C#에는 Generic이 들어가서 이전 버전의 C#보다 훨씬 많은 프로그래밍 지식을 요구하고, 웹 프로젝트의 Code-Behind 방식은 사라졌다(김씨는 개발자가 아닌 PM이라 다른 업무도 많은 상태에서 사라진 것인지 숨은 것인지 알아내는 시간 투자가 부담스럽다).
닷넷은 자바처럼 여러 업체가 주도하는 기술이 아닌 마이크로소프트라는 한 기업이 주도하는 기술이고, 그런 이유로 기술의 변화가 급격하다. 자바는 이미 산업에서 많이 쓰이고 있으므로 자바 5가 발표되었다고 그 즉시 자바 5를 사용해야 되는 경우는 드물지만, 이제 도입하는 업체가 늘어나는 상황인 닷넷의 경우 새로 시작하는 프로젝트는 최신 버전을 사용해야 함이 당연하다(김씨의 경험으로는 기술의 설명 같은 것은 클라이언트들이 들어주지도 않는다. 클라이언트들은 최신 기술이 무조건 좋은 기술인 줄로만 안다. 전산을 조금 안다는 클라이언트일수록 이 현상은 더욱 심각하다).
어떤 버전으로 진행해야 할까?
팀원이 그렇게 많지 않은 조직에 근무하는 김씨는 고민에 싸이게 되었다. 기존의 1.1 버전으로 프로젝트를 시작할 것인지, 내년 3월이면 발표된다는 2.0 버전으로 프로젝트를 시작해야 할 것인지에 대한 고민이 우선 클 뿐더러, 2.0으로 결정했다 해도 2.0에 포함된 기술들에 익숙하지 않은 팀원들의 교육 문제는 어떻게 해결할 것이며, 산출물의 형태는 어떤 식으로 변경되어야 하고, 회사의 기존 프로젝트 산출물들을 어떻게 새 버전에 맞추어 개량해야 할 것인지의 문제에 직면했다.
기업에 PMO 조직이 있다면 김씨의 이런 고민은 말끔히 해결된다. PMO 조직이 김씨의 고민거리를 몽땅 맡아주기 때문이다. CMM에 따라 정비된 조직이라면 다음과 같은 프로젝트 오피스 조직들을 운영하고 있을 것이다.
[1] PSO(Project Support Office)
[2] PMO(Project Management Office)
[3] PMO(Program Management Office)
이와 같은 프로젝트 오피스 조직들은 다음과 같은 업무들을 맡아서 진행한다.
[1] 훈련/교육, 소프트웨어 도입 및 표준 템플리트 등의 형식으로 프로젝트 매니저에게 지원 기능을 제공한다.
[2] 일부 실제적인 프로젝트 결과를 책임진다.
[3] 표준 템플리트는 절차서, 범위 명세서, WBS, 액티비티에 대한 전반적인 일정 내용을 지칭한다.
[4] 프로젝트 관리 지침 및 프로젝트 헌장 등의 각종 절차서를 개발하고 제공한다.
[5] 회사의 PMIS를 구축한다.
PMO 조직은 예상 문제점을 사전에 파악해 분석하고, 이에 대한 대응조치를 제공해 프로젝트가 실패할 확률을 줄여줄 뿐만 아니라 팀원들의 프로젝트 목표의식을 분명히 해줌으로써 CMP(Communication Management Plan)를 명확하게 하고 이해 관계자간의 간섭 사항을 고려해 업무 수행을 원활하게 해준다. 절차를 명확하게 명시해 줌으로써 논리적이고 체계적인 업무 처리를 할 수 있게 해줌은 물론이다.
완벽하지 않다고 해서 실패한 프로젝트는 아니다. 하지만 실제 상황을 이야기해 보자. CMM, 물론 좋은 이야기다. CMMI, SPICE 모두 다 좋은 이야기이긴 하지만 하청의 하청인 영세 업체에서는 꿈꾸기조차 어려운 이야기이다. CMMI 레벨을 획득하기 위한 비용이 만만치 않을 뿐더러 PMP를 두 명 이상 유지하는 것은 현재 회사의 규모로 볼 때 만만한 일이 아니다. 영세 업체의 입장에서 볼 때 PMO 조직을 운영하는 것 자체가 무리이고, 비용 관리에서 일정 관리, 팀원의 교육까지 모두 PM이 책임져야 하는 상황이라면 모든 일을 PM이 다 하는 것은 불가능한 일이 된다. 이런 경우 적당한 시점에서 타협해야 한다.
[1] 프로젝트의 전반적인 방향에 대해 파악하는 데 있어 기존의 자료를 최대한 활용한다.
1차 또는 2차 하청 업체이거나 또는 전체 프로젝트의 특정 모듈만을 작성해야 하는 경우라도 프로젝트의 전반적인 방향이나 목적에 대한 파악 없이는 불가능하다. 의욕적인 PM이나 개발자의 경우 모든 파악을 능동적으로 구성하려 하지만 시간적이거나 인력적인 여건에서 불가능한 경우가 대부분이다. 이런 경우 최대한 클라이언트 또는 원청 업체를 졸라서 최대한 많은 리소스를 확보하고 참조하는 것이 좋다.
[2] 프로젝트 헌장을 정확하게 파악한다.
프로젝트 헌장이라는 것은 프로젝트의 존재를 알리는 공식적인 문서를 의미한다. 이 문서에는 사업의 요구사항, 제품 기술서, PM이 자원을 사용할 수 있는 권한에 이르기까지의 사항들이 기술된다. 프로젝트 헌장이 작성되기 전에 PM으로 임명됐다면 다른 이야기가 될 테지만, 그렇지 않다면 헌장을 정확하게 파악해 자신이 해야 할 일과 해서는 안 되는 일에 대한 파악이 무엇보다 중요하다.
[3] WBS 리스트를 작성하고 시작한다.
개발이 끝나고 나면 실제 동작하는 프로그램보다 산출물이 훨씬 더 중요시되는 경우가 대부분이다. 특정 개발방법론을 선택하고 개발에 착수했을 경우 작성되는 WBS의 분량은 실로 엄청나다. 투입되는 개발자의 대부분이 프로그램을 작성하는 것보다 산출물을 작성하는 것이 더 어렵고 시간이 많이 소요된다고 이야기한다. 프로젝트를 관리하는 사람의 입장에서는 팀원들의 요구를 잘 파악하는 것이 중요하고 필요 없는 산출물을 작성하고 있는 것은 오히려 프로젝트 진행의 발목을 잡는 일이 된다. WBS 리스트는 클라이언트 또는 원청 업체와 상의해 필요 없을 것 같은 산출물은 아예 작성하지 않는 것이 좋다.
[4] 일정을 작성할 때는 비 프로젝트 휴가를 반드시 포함한다.
일정을 작성할 때 휴일을 고려하는 것은 당연하다. 비 프로젝트 휴가를 포함하라는 말은 예상치 않은 곳에서 발생할 수 있는 결원 가능성에 대해서 반드시 고려하라는 말이다. 어떤 모듈이 내일까지 완성되는 줄로 알고 있었다가 담당 개발자가 예비군 훈련 등의 일로 인해서 2～3일씩 지연되는 경우가 많다. 기업간의 프로젝트는 일정으로 이야기되는 경우가 대부분이어서 예기치 못한 일정 지연으로 낭패를 당하는 경우가 허다하다. 일정에 플러스마이너스 15 정도의 여유를 두는 것이 오히려 진행 속도를 빠르게 하는 결과를 가져온다.
실패하지 않은 포기를 위한 몇 가지 충고
프로젝트를 처음 시작할 때는 누구나가 야심찬 계획을 세우게 된다. 산출물도 바로 작성하고 포트폴리오도 정리하고 코드도 예술 같은 코드를 써서 인쇄해 벽에 걸어놓고 싶은 마음이 들게끔 하고 싶은 것이 당연하다. 하지만 그런 야심찬 계획들은 대부분 진행 도중에 난관을 만나게 된다.
난관에 부닥치면 결정의 기로에 서게 되는데, 난관을 타개하고 애초 생각한 모습대로 진행하느냐 또는 적절한 시점에서 타협해 몇 가지를 포기하느냐 하는 결정을 내려야 한다. 대부분의 경우 적절한 시점에서 타협하게 된다. 그리고 그 타협이 돌아가는 프로그램을 만들게 되고 프로그래머를 과로사의 위협에서 구해낸다.
한마디 덧붙여 이야기하면, 프란시스 포드 코폴라는 악몽과도 같았던 프로젝트 ‘지옥의 묵시록’으로 칸 영화제 황금 종려상을 수행했고, 1979년 아카데미 시상식 8개 부분에 노미네이트되어 두 개 부분을 수상했다. 완벽하지 않지만 실패하지 않은 포기를 위한 몇 가지 충고를 하면 다음과 같다.
[1] 팀원들을 ‘No Man’으로 만들라.
클라이언트와 팀원들 사이의 대화 통로를 아예 봉쇄하는 것이 가장 바람직한 길이라고 극단적으로 말하고 싶다. 하지만 그렇다면 PM이 할 일이 너무 많아지게 되므로 적당한 대화 수단을 제공하되, 클라이언트의 요구사항을 팀원이 절대로 “해드리겠습니다”라고 말하지 않게 훈련시키는 것이 중요하다. 프로젝트 요구사항에 포함되지 않은 어떤 요구를 구두로라도 승락하게 되면 구두 계약이 되어 프로젝트의 분량이 엄청나게 늘어나는 경우를 종종 봐왔다. 다음 버전업에서 해야 할 작업을 팀원의 “예” 한마디 때문에 모듈을 모두 수정하는 경우도 가끔은 있다.
[2] 프로젝트 매니저는 프로젝트에 직접 참여하지 말라.
프로젝트 매니저가 의욕이 넘치는 사람이고, 개발 기술을 잘 아는 사람이라면 직접 프로젝트에 참여하여 개발 일부분을 담당하는 경우가 있다. 개발을 담당한다는 것은 프로젝트 관리 업무를 포기하겠다는 말과도 같다. 프로그램 코드를 작성하는 업무와 프로젝트를 관리하는 업무는 본질적으로 틀려서 얽힌 코드를 푸는 작업을 하다가 일정 관리 작업으로 다시 돌아오는 데는 시간이 제법 걸리게 된다. 프로젝트 매니저가 일정을 작성하지 않으면 개발자들이 적당히 알아서 다음 프로그램을 작성할 것이라는 생각은 버리는 것이 좋다. 일정이 비게 되면 개발자들은 100% 논다.
[3] 제대로 알지 못하는 기술을 사용하는 프로젝트에는 참여하지 말라.
통계에 의하면 1시간을 강의하기 위해서는 3시간을 공부해야 한다고 한다(재판 판례에 따른 이야기다). 물론 강의와 개발은 엄연히 다른 이야기이지만 새로운 기술을 익혀서 개발에 직접 이용한다는 것은 많은 노력과 시간을 요구한다. 프로젝트의 성패 여부는 일정 관리와 시간을 어떻게 사용하느냐에 있다고 봐도 과언이 아니므로 팀원의 교육과 훈련 등을 맡아서 관리해주는 조직 또는 사람이 따로 있지 않은 프로젝트 관리자의 입장에서는 프로젝트를 맡지 않는 것이 경력에도 도움이 되고 회사의 입장에서도 이익이 되는 경우가 훨씬 더 많다. ‘따고 보자’의 시대는 지나갔다.
[4] 두 마리 토끼는 두 마리 호랑이가 쫓아야 한다.
두 마리 토끼를 쫓다가 저녁을 굶는 호랑이 이야기를 많이 듣고 살지만, IT 일처럼 이런 경우가 딱 들어맞는 경우가 드물다. “이것도 하고 저것도 한다”는 것은 관리자 또는 개발자의 업무를 두 배로 늘이겠다는 이야기 밖에는 되지 않는다. 특히 한국 개발자들의 특성이 하루 만에 할 수 있는 일이라면 밤샘하면 할 수 있는 일을 생각한다는 것은 큰 병폐 중의 하나가 아닐 수 없다. 물론 일정이 빡빡하면 사흘쯤 밤샘하는 것은 당연한 일(?)이라고 생각하는 것도 좋지만 과중한 업무를 감당하는 기간이 길어지게 되면 업무에 대한 집중도가 떨어지고 실수를 많이 하게 된다. 특히 디버깅 기간 중에 실수를 저지른다면 감당할 수 없는 일이 발생할 수도 있다. 한 마리 토끼를 착실히 쫒아서 반드시 잡는 것이 프로젝트를 성공하는 가장 큰 방법이 된다.
지극히 상식적인 프로젝트의 수행
결혼정보회사에 근무하는 친구의 말을 들으니 3년 전쯤에는 프로그래머라는 직업의 선호도가 아주 높았는데, 날이 갈수록 떨어지고 있다고 한다. 이유인 즉 급여 수준에 비해서 하는 일이 너무 많아 가정적이지 않고 전체적으로 성격들이 완벽주의자라 피곤한 성격의 소유자들이 많고, 또한 꼼꼼하고 나쁘게 말하면 째째하게까지 보이는 사람들이 많아서라고 한다.
프로젝트를 시작했으면 완벽하게 마무리하고 싶은 것이 개발자들과 관리자들의 본성이지만 당연히 완벽하게 마무리되는 경우는 드물다. 특히 자존심 강한 엔지니어들의 세계에서는 누구나가 완벽하게 프로젝트를 마무리짓고 싶어 하지만 적당한 시점에서 욕심을 다스리는 것이 프로젝트를 성공적으로 이끄는 요인이 될 수도 있다.
이번 연재에서는 프로젝트를 수행하는 데 있어 책임을 회피하거나 작업량을 줄일 수 있는 방법, 즉 ‘꼼수(?)를 권장하는 듯한 냄새가 풍기는 듯하다. 하지만 이번 연재는 어디까지나 100점 만점에 95점을 기준으로 했을 때라는 것을 알아주었으면 하다. 일정을 지키기 위해 산출물의 내용과 프로그램의 내용이 따로 노는 프로젝트라도 성공한 프로젝트라고 말하는 것은 아니기 때문이다. 모 CF의 내용처럼 ‘상식에서’ 이야기했을 때의 적당한 시점을 이야기 하는 것이기 때문이다.
하지만 이런 ‘꼼수’가 통하지 않는 시대가 가까운 미래에 오게 될 것 같다. 미국에서는 2006년부터 CMMI 레벨 3을 획득하지 못한 기업은 국책 프로젝트에 참여할 수 없다는 법률이 정해졌고 국내에서도 그런 움직임이 활발하다. 하지만 우리나라 사람이 항상 그렇듯이 언제나 빠져나갈 구멍은 있게 마련이고 그 빠져나갈 구멍의 한도에서 병폐도 생길 것이 확실하다. 프로젝트를 성공적으로 이끄는 방법은 ‘지극히 상식적인 프로젝트의 수행’에서 리소스를 잘 파악해 적당한 시점에 적정 리소스를 투입하는 데 있다. @
* 이 기사는 ZDNet Korea의 자매지인 마이크로소프트웨어에 게재된 내용입니다. 
로그인 |
회원가입 (뉴스레터신청) |
SITEMAP
독자의견 남기기 (로그인 후 독자 의견을 남기실 수 있습니다.) 
