필자 : 이 석 상무

지난 번 ‘#1. 차세대 프로젝트 준비 잘하기’에 이어서, 프로젝트를 성공적으로 진행할 수 있는 방안에 대해서 살펴본다.

차세대 프로젝트를 잘 할 수 있는 100점짜리 방법이 제시된다고 하면, 예상할 수 있는 결과는 국내외 모든 차세대 프로젝트의 프로젝트 관리 멘토로서 엄청난 성공을 거두던지, 아니면 수없이 많은 개발 방법론 및 프로젝트 관리 방법론과 같이 현실과 동떨어진 이상(충분한 예산과 기간, 인력이 확보된 상태에서 추진하는 FM절차)만을 언급한 경우가 될 것이다.

전자의 효과를 기대하기에는 너무 불충분하고, 후자는 이미 다양한 방법론 및 이론을 통해 소개되었으므로, 이번에는 큰 기대를 갖지 말고, 실제 현장에서 느꼈던, 다분히 주관적인 견해로서 차세대 프로젝트를 잘 할 수 있는 방안을 이슈별로 살펴보고자 한다(쉽게 얘기해서, 일단 꼬리를 내리고 시작하기로 한다).

# 1부 : 차세대 프로젝트 준비 잘 하기
# 2부 : 차세대 프로젝트 진행 잘 하기 (Part 1 : 프로젝트 관리)
# 3부 : 차세대 프로젝트 운영 잘 하기


전체적 관점 유지
차세대시스템은 전사적인 차원에서 출발한다. 따라서, 전체를 바라볼 수 있는 시야가 필요하다. 여기서 ‘전체’란 두 가지 관점으로 볼 수 있는데 첫째, 차세대 프로젝트와 관련된 전체 즉, 프로젝트 목표 및 전략, 일정, 조직, 공정, 위험, 예산, 투입인력/공수, 진도, 커뮤니케이션, 의사결정체 등 프로젝트 관리가 전체적인 관점에서 차질 없이 진행될 수 있는 계획이 수립되어야 한다(Multi Project/Team 관리).
둘째, 프로젝트와 연관된 전사차원의 전체적인 범위 관리이다. 업무 프로세스 및 조직간의 이해관계, 기존 Legacy 시스템을 포함한 모든 어플리케이션, 채널계-업무계-정보계-분석계-대외계에 걸친 데이터 현황, 하드웨어 및 소프트웨어 도입 및 설치 등을 전사 마스터플랜 아래 관리해야 한다(요구사항 정의 및 추적관리).

기획 능력
계획은 항상 변경된다. 여기서 중요한 것은 항상 새로운 단계가 시작되기에 앞서, 철저한 상세계획이 새로 수립되어야 한다는 점이다. 분석 단계에서는 시스템 설계 계획이, 설계단계에는 프로그램별 상세 개발계획이, 개발 단계에서는 다양한 테스트 계획이, 테스트 단계에는 오픈 후 운영계획이 미리 수립되어야 주어진 기간 안에 목표 품질 수준을 달성할 수 있다.
하지만 불행하게도 현실은 프로젝트 최초에 수립한 프로젝트 계획서의 버전이 여전히 1.0인 상태에서 시스템을 오픈하는 경우가 많다. 중요한 것은 각 마일스톤별로 진행상황을 점검하고 새로운 단계의 위험을 예측하여 기존 계획을 정련하는 지속적인 노력이 필요하다는 점이다(Plan-Do-See 관리체계).

삼각 관계
우리가 어렸을 때 처음 배운 자전거는 세발 자전거이다. 그 이유는 3개의 축이 가장 안정적인 힘의 균형을 이루기 때문이 아닌가 싶다. 프로젝트에서도 마찬가지로 3개의 축(고객-SI-PMO)이 서로의 책임과 역할을 제대로 수행해야 프로젝트가 원활히 진행할 수 있다.
‘고객’은 명확한 업무요건의 정의와 철저한 검토, ‘SI’는 정해진 개발 및 관리 절차에 따라 체계적인 작업 수행, ‘PMO 또는 Staff’ 조직은 고객과 SI업체의 균형을 이룰 수 있도록 공정과 아키텍처, 품질을 조정할 수 있는 능력이 있어야 한다.
어느 한 쪽의 힘이 세거나, 역량이 미흡하다면, 프로젝트는 항상 시끄러운 상황에서 진행될 것이다. 왜냐하면, 사람간의 관계에서 제일 골치 아픈 것이 삼각관계이기 때문에…(추진조직의 R&R 명확화 및 조정)



위험관리 능력
프로젝트는 기본적으로 리스크를 내재하고 있다. 정해진 기간 내에, 정해진 예산에 맞추어, 불확실한 요건을, 검증되지 않은 새로운 기술요소를 활용하여, 생면부지의 수 백 명의 사람들이 일사불란하게 진행하는 것 자체가 Mission Impossible에 가깝다.
리스크 없는 프로젝트는 있을 수 없으므로 이와 같은 리스크를 사전에 파악할 수 있는 능력(현실은, 감추기에 급급함), 리스크를 끝까지 추적 관리할 수 있는 관리체계(현실은, 모두 “불이야 !”라고 외치지만 정작 소화기를 사용하는 사람은 아무도 없음), 문제를 신속하게 해결할 수 있는 강력한 리더쉽(현실은, 누가 고양이 목에 방울을 달 것인가?) 등이 모두 뒷받침되어야 한다(철저한 리스크 관리).

리더쉽
리더쉽을 가장 필요로 하는 직업으로 오케스트라 지휘자, 프로야구 감독, 군함의 함장 그리고 프로젝트 PM을 들 수 있다(앞의 3개는 유명인이 한 얘기, 뒤의 것은 사견 *^^* ). <베토벤 바이러스>의 강마에가 외치는 것처럼, 오케스트라 연주의 성공(단순히 악기연주가 아닌, 인간의 감성을 자극하는 음악)을 좌우하는 것은 지휘자의 역량이고, 이를 위해서는 모든 연주자가 지휘자에 복종해야 한다.
프로젝트도 마찬가지일 것이다. 전체의 하모니를 위해 개성 강한 악기들을 조율할 수 있는 역량 및 리더쉽을 갖춘 리더, PM이 필요하다. 단, PM이 반드시 勇將일 필요는 없다. 智將도 좋고, 德將도 좋고, 暴君도 좋다. 강력한 리더쉽만 있다면…

방법론
모든 개발업체는 시스템 개발 및 프로젝트 관리 방법론을 ‘보유’하고 있다. 그러나, 개발에 참여한 모든 사람들이 방법론을 적용하여 체계적으로 프로젝트를 수행해왔다고 생각하면 오산이다.
모든 사람들은 자기만의 방식, 노하우로 일하기를 원하며, 문서화와 같은 관리행위를 무지 싫어한다. 하지만 소프트웨어 개발은 Art가 아닌 Engineering이기 때문에 요구사항 정의부터 시스템 오픈까지의 전체 개발공정에 대한 명확한 정의 및 각 산출물간의 연관관계 파악이 무엇보다 중요하다. 각 프로젝트의 특성을 살려, 관리를 위한 산출물이 아닌, 진정으로 필요한 산출물과 작업공정을 설계할 수 있는 방법론 커스터마이징 역량이 필요하다. 실제 프로젝트에서 이 작업이, 이 산출물이, 어떤 의미가 있는지도 모르고 작업하는 경우를 종종 만나게 된다.

품질보증
품질보증의 주체는 각 작업자 당사자이어야 한다. 별도의 QA조직이 존재하더라도, 품질에 대한 일차적인, 그리고 최종적인 책임은 실제 작업을 수행하는 사람이 담당해야 한다. 따라서, 품질보증 활동은 사전, 사후 활동으로 구분해서 추진해야 하며, QA조직은 이와 같은 절차를 명확히 정립해야 한다.
사전 품질활동으로는 각 작업 및 산출물 작성 양식, 샘플, 베스트 프랙티스, 표준, 리뷰 시 체크포인트 등을 작업에 착수하기 이전에 정확하게 공지해야 하며, 실제 작업 시에는 워크스루(Walkthrough) 및 동료, 고객 검토를 통해 품질을 확인해야 한다.
사후 품질은 단계 말 또는 작업 종료 시 별도의 인스펙션 기준에 따라 수행해야 한다(단계별 감리활동 포함). 이와 같이 추진하기 위해서는 실제 프로젝트 공정을 기획할 때에는, 작업에 대한 공수뿐만 아니라, 품질보증을 위한 제반 검토 활동(수 많은 리뷰회의 일정)도 모두 고려하여 일정계획에 반영해야 한다(사전-사후 품질관리 기준 및 체계 정립).



커뮤니케이션
프로젝트의 성공요소 중에서 가장 중요한 것이 무엇이냐고 묻는다면, 주저하지 않고 ‘커뮤니케이션’을 꼽을 수 있다. 커뮤니케이션이란 프로젝트에 참여한 모든 이해당사자들 간의 컨센서스를 의미한다.
현업과 IT 부서, 고객과 SI업체, 개발팀과 Staff 조직, 개발팀과 공통/표준화팀, 개발팀간, 개발팀 내부, 팀장과 팀원, 사업자와 협력업체 등 모든 당사자들간의 이해와 협조가 무엇보다도 중요하다.
차세대시스템은, 전사 차원의 빅뱅식 접근, 새로운 정보기술의 도입, 업무 프로세스의 통폐합, 전사 시스템의 통합 등 수많은 불협화음을 발생시킬 수 있는 소지를 안고 추진된다. 따라서, 각 역할을 맡고 있는 당사자들이 차세대시스템이라는 큰 틀 안에서, 타인을 배려하면서 자신의 목소리를 주장할 수 있는 원활한 커뮤니케이션 채널 확보 및 회의체 운영이 중요하다.
공식, 비공식적인 회의체 및 온라인, 오프라인을 망라하는 다양한 채널을 통해 상하좌우의 원활한 의사소통 흐름체계를 확보해야 한다(다양한 회의체 및 커뮤니케이션 채널 운영).

개발 조정
부분의 최적화가 전체의 최적화를 의미하지는 않는다. 상위 수준의 아키텍처는 전사 차원에서 정의하고 검토하는 것이 비교적 용이하지만, 실제 설계 및 개발 단계에서는 전사 차원의 정합성 및 일관성을 유지하는 것이 매우 어렵다.
개발팀들은 자체 영역 내 작업물량을 소화하기에도 상당히 바쁘고, 공통 오브젝트를 도출하여 다른 팀과 공유하여 추진하기보다는 중복이 되더라도 자체적으로 해결하는 것이 훨씬 용이하다. 간혹 여러 업무영역에서 오너쉽이 모호한 업무가 발견되면 과감히 내가 하겠다고 나서는 경우도 거의 없다.
이와 같이 전사 차원에서 어플리케이션간의 연관관계를 조정하고 공통 오브젝트를 ‘제대로’ 관리하기 위해서는 각 업무영역 간 개발내역을 조정하는 개발조정(Development Coordination) 기능이 필요하다.
단계 말이나 오픈을 앞둔 시점에서 다른 팀과 협조하며 일하기를 기대하는 것은 현실적으로 어렵기 때문에, 강력한 파워를 가진, 그리고 전사 업무를 전체적인 시각에서 파악하고 있는, 별도의 개발조정 조직이 역할을 수행해야 한다. Chief Architect가 이 같은 역할을 수행해야, 전사 아키텍처 관점의 정합성을 구현한, 진정한 의미의 통합 시스템을 구축할 수 있다.

선도개발팀 & 파일롯 프로젝트팀 가령 프로야구에서 각 포지션별 골든글러브 수상자만으로 팀을 구성한다는 것은 현실적으로는 불가능에 가깝다. 사람들의 능력이 모두 같을 수는 없기에 잘하는 사람, 보통인 사람, 미흡한 사람도 함께 어울려서 팀웍으로 플레이를 한다.
차세대 프로젝트도 모두 베테랑 엔지니어만으로 팀을 구성할 수는 없다. 프로그램을 귀신같이 짜는 사람부터 지난 달에 입사한 신입사원까지 다양한 능력의 소유자들이 참여한다. 하지만 프로젝트 전체 입장에서는 동등한 품질 수준을 요구한다. 물론 모든 프로그램의 기대수치가 100점이 될 수는 없고, 80점 또는 90점을 목표로 품질의 균등화에 초점을 맞추게 되며, 목표치를 조금이라도 높이려고 많은 노력을 기울이게 된다.
그 중의 하나가 선도개발팀(Path Finder)의 역할이다. 목표 아키텍처를 남보다 먼저 앞서서 진행해나가는 전문가 집단으로서, 파일롯 또는 선도 개발 과정에서 프로젝트 적용 방법론, 산출물, 샘플, 베스트 프랙티스, 표준 등을 점검하고 보완하여 전체 참여자가 실제 개발할 때 바이블처럼 활용될 수 있도록 해야 한다. 현재의 프로젝트 체계에서는 소수의 천재(S/W 아키텍트)들이 전체를 이끌 수 있어야 한다.

Fun 경영 / 회식
월화수목금금금… 불행하게도 이 말은 차세대 프로젝트를 추진하는 책임자들이 마지막 보루로서 믿는, 프로젝트 위험관리 해결책이다. 물론 처음부터 적용되는 경우도 있지만…
차세대 프로젝트는 마라톤에 비유할 수 있다. 처음부터 전력 질주해서는 결코 완주할 수 없으며, 프로젝트 진행의 완급조절, 집중력 향상 방안 등이 필요하다. 그리고 간과해서는 안 되는 것이 프로젝트 참여자들에 대한 배려이다. 결국 사람이 하는 일이기에, 목표만 부과한다고 좋은 결과가 나오는 것이 아니라, 참여자들이 진실로 가치를 느낄 수 있는 동기 부여와 함께 프로젝트 자체에 재미를 느낄 수 있어야 한다.
작업자들이 매일 철야 작업을 하면 뿌듯해할 관리자들도 있겠지만, 품질 측면에서는 완전 마이너스이다. 집중할 때 집중해야 하고, 항상 참여자들의 세세한 일상까지도 챙겨줄 수 있는 즉, 재미있는 프로젝트 진행이 반드시 필요하다. 시야가 확 트인 북한산 정상에서, 흙먼지로 뒤범벅된 한강고수부지 축구장에서, 돈 주고는 절대 살 수 없는 끈끈한 동료애를 얻을 수 있다. 온갖 난관을 헤쳐나갈 수 있는…