SW 개발 프로젝트에서 PM의 달라진 역할
- 그 많던 PM들은 다 어디로 갔을까요?

1 배경

디지털 트랜스포메이션을 중심으로 쏟아지는 비지니스 기회들을 잡기 위해서 대기업에서부터 스타트업까지 수 많은 소프트웨어 개발 프로젝트가 기획·수행되고 있습니다.

그런데 그 많은 프로젝트를 관리하기 위한 PM(Project Manager)이 눈에 잘 띄지 않습니다. 그들은 대체 어디로 갔을까요? 프로젝트를 시작하고 그 과정에서 발생하는 리스크를 제거하며 마지막까지 개발 결과물을 책임지는 역할은 어느 프로젝트에서건 꼭 필요합니다. 하지만 갈수록 고객들이 새로운 가치를 원하면서 그 가치를 만들어 내기 위한 서비스 모델이 바뀌었고 소프트웨어의 개발 방법도 진화했습니다. 그 동안 소프트웨어 개발 프로젝트에 어떤 변화의 바람이 불어왔으며 기존 PM들에게 어떤 영향을 미쳤는지 알아보겠습니다.

2 PM의 역할

프로젝트 매니지먼트에 대한 가장 공신력 있는 연구 기관인 PMI(Project Management Institute)는 프로젝트를 이렇게 정의했습니다.

PM은 정해진 납기 일정과 한정된 리소스를 활용하여 결과물을 만들어내는 것에 그 책임을 갖습니다. 그렇기 때문에 결과물을 만들어 내는 과정 전반에서 다양한 역할을 수행해야 합니다. PM이 관리해야 하는 영역을 PMBOK(Project Management Body of Knowledge) 6판 기준으로 요약해보면 다음과 같습니다.

  - 통합 관리: PM의 권한을 획득하고, 통합 관리 계획을 수행
  - 범위 관리: 요구사항을 수집하여 정의 하고 변경을 관리
  - 일정 관리: 활동을 정의하고 일정을 개발하여 모니터링
  - 비용 관리: 비용을 측정하고 예산을 책정하여 관리
  - 품질 관리: 품질 관리 계획에 따라 품질 관리 및 보증
  - 자원 관리: 자원을 확보하고, 팀을 개발하고 관리
  - 의사소통 관리: 의사소통 관리 계획에 따라 관리하고 모니터링
  - 리스크 관리: 리스크 식별 및 대응 계획을 수립 후 모니터링
  - 조달 관리: 고객에게 결과물 조달 계획을 수립하여 확보 후 조달
  - 이해관계자 관리: 이해관계자를 식별하고 관리 및 모니터링

1996년부터 ISO-21500 표준을 기반으로 정리된 내용이라 용어가 딱딱해 보일 수 있지만 PM이라면 당연히 해야 할 역할을 정의하고 시기와 영역에 따른 이론과 기술을 가이드 하고 있습니다.

3 SI 개발 프로젝트에 적합한 PM 역할

과거 소프트웨어 개발은 제조·금융·공공 등의 엔터프라이즈 SI(System Integration)를 중심으로 행해졌습니다. 기한 내 시스템 구축을 완료하기 위해 많은 개발자가 동원되었고 이들을 이끌면서 결과물까지 책임질 PM이 필요했습니다. 프로젝트 규모가 방대한 만큼 많은 요구 사항들과 각 영역들을 효과적으로 관리하기 위해 다수의 PM이 투입되었습니다. 그들은 PMO(Project Management Office)를 조직하여 프로세스를 표준화하고 하위 프로젝트 간 리소스를 공유하면서 전체 프로젝트의 결과물을 책임졌습니다.

그 당시 개발 방식은 폭포수(Waterfall) 방법론을 주로 활용했습니다. 큰 요구 사항이 정해져 있고 WBS(Work Breakdown Structure)로 목표를 개별 개발자에게 할당할 수 있을 정도까지 세분화합니다. 이 방법론은 요구 사항이 명확하며 변경이 최소화 되어야 합니다. 이를 위해 기획 과정에서 요구 사항을 명확히 파악하고자 제품 분석, 고객 인터뷰, 대안 개발, 심화 워크숍과 같은 활동이 필요하고 변경 통제를 위한 변경 관리 위원회(CCB, Change Control Board)도 운영해야 합니다. 하지만 고객의 요구 사항을 아무리 구체적으로 정의해도 외부 비즈니스 환경에 의해 변경 사항이 발생할 수 밖에 없었고 개발자는 이에 대응해야만 했습니다. 이러한 상황은 일정 지연과 함께 프로젝트 팀원의 피로도를 높여 리소스를 추가로 투입하게 만들었고 결국 사업 수익성에 좋지 않은 영향을 미치게 되었습니다.

4 스크럼 마스터와 프로덕트 오너

개인의 소프트웨어 사용이 보편화 됨에 따라 소프트웨어 시장은 엔터프라이즈 SI 개발 중심에서 개인화된 컴퓨터와 모바일 중심의 비즈니스 시장으로 빠르게 바뀌었습니다. 그러나 전통적인 폭포수 방식으로는 빠른 개발을 통한 신속한 시장 진입이 어려워졌습니다. 변화에 좀 더 민첩하게 대응할 수 있는 새로운 개발 방식이 요구되면서 애자일 방법론이 등장했습니다.

애자일의 기본 원칙은 가치 있는 소프트웨어를 지속적으로 전달하여 고객을 만족시키는 것이었습니다. 애자일 원칙을 따르는 여러 개발 방법론 중 스크럼 방법론은 2~3주간의 스프린트 결과물을 모든 이해관계자와 같이 확인하고 다음 스프린트를 계획합니다. 피드백을 수렵하고 목표를 조정한 후에 다시 스프린트를 진행함으로써 변경에 대한 유연성을 갖고 고객의 가치에 좀 더 가깝게 다가갈 수 있게 되었습니다.

스크럼 조직에서 PM의 역할은 SM(Scrum Master)과 PO(Product Owner)가 대신합니다. SM은 스크럼 팀이 효율적으로 운영될 수 있도록 프로세스에 대한 책임을 가집니다. 개발팀의 장애물을 제거하여 업무 효율을 높이고 스프린트가 원활히 진행 될 수 있도록 운영합니다. 팀 자원과 의사소통 그리고 리스크를 관리하는 역할에 더 집중하는 것입니다.

제품을 책임지고 고객의 가치를 고려하여 그에 따른 의사결정을 하는 역할은 PO가 가져 갔습니다. PO는 각 이해관계자와 꾸준히 커뮤니케이션 하면서 요구사항을 분명히 합니다. 중요한 결정 권한을 SM에게 주지 않는 대신 지속적으로 참여하고 이해관계자들과 의사소통하며 제품의 가치를 종합적으로 판단하며 빠른 결정을 내립니다. PM의 예산 관리에 대한 역할도 마찬가지입니다.

5 프로덕트 매니저, 프로그램 매니저

최근 소프트웨어 영역에서 등장한 큰 변화는 바로 SaaS(Software as a Service)입니다. 소프트웨어를 '설치'하는 시나리오는 점점 고려하지 않게 되었고 IaaS(Infra as a service)와 PaaS(Platform as a service) 등의 클라우드 기술이 급속도로 발전하면서 고객에게 가치를 빠르게 제공할 수 있는 SaaS 형태의 소프트웨어가 주를 이루는 시대로 전환되었습니다.

신규 고객을 지속적으로 유입해 성장하기 위해서는 새로운 기능이 빈번하게 업데이트 되어야 합니다. 즉 프로덕트의 규모는 점점 커지는 반면, 신규 기능 및 패치의 업데이트 주기는 더 짧아져야 하는 것입니다. MSA(마이크로 서비스 아키텍처)는 프로덕트를 작은 서비스 단위로 분리하여 의존성을 떼어내고 작은 서비스 단위로 업데이트가 가능하게 함으로써 성장하는 기업의 다운타임을 줄일 수 있게 되었습니다. 또한 서비스 단위로 데브옵스(DevOps)팀을 구성하여 개발, 배포, 운영 대응까지 모든 책임을 맡기는 특징을 가지고 있습니다.

프로덕트의 규모에 맞춰 과거에 PO가 없을 때 프로덕트를 담당했던 PdM(Product Manager)의 역할이 다시 중요해지기 시작했습니다. 프로덕트의 규모가 상대적으로 작을 때에는 PO가 그 역할을 충분히 수행했지만 방대해진 유관 부서와의 커뮤니케이션은 의사결정 속도를 늦췄습니다. PO가 제품의 비전, 유관 부서의 커뮤니케이션 관리를 맡으면서 PdM이 데브옵스팀과 스크럼을 수행하며 산출물을 만드는 역할에 더 집중할 수 있도록 했습니다.

MSA 프로덕트 환경에서 또 많이 필요하게 된 역할로 PgM(프로그램 매니저)을 들 수 있습니다. MSA 기반 프로덕트에서 잘 만들어진 서비스들은 여러 다른 서비스 또는 다른 프로덕트에서도 쓰이는 경우가 많습니다.(검색, 채팅, 평점 등) 각 서비스들은 다른 프로덕트에 맞게 기능을 개선·수정해야 하는 프로젝트가 빈번히 발행합니다. 여러 연관성 있는 프로젝트의 모음을 프로그램이라 부르고 이 프로그램의 비지니스 영향도를 고려한 의사결정을 PgM(프로그램 매니저)이 맡습니다. 과거 PgM이 오랜 PM 경력을 기반으로 기업 및 조직의 대형 프로젝트를 종합적으로 관리하는 역할을 수행했다면 지금은 다양한 소규모 프로젝트의 PM까지 맡으면서 전방위적 역할을 담당합니다. 서비스를 담당하는 데브옵스팀과 긴밀한 커뮤니케이션이 필요하고 기술적 결정을 많이 해야 하기 때문에 테크니컬 프로그램 매니저라고도 불립니다.

6 제품에 적합한 조직, 조직에 적합한 역할

모든 소프트웨어가 MSA로 구성되는 것이 아니며 모든 기업들이 SaaS로 비지니스를 하고 있는 것은 아닙니다. 소프트웨어 제품의 특성과 사업 포트폴리오에 따라 적합한 형태로 프로젝트를 수행합니다. 비지니스 기회를 재빨리 잡아내고 고객 가치를 높일 수 있는 민첩한 대응을 위해 소프트웨어 개발 환경은 변화하고 있습니다. 그에 따라 기업은 PM이 했던 역할과 책임을 다시 정의하고 새롭게 부르며 변화에 대응해 가고 있습니다. 앞서 설명한 역할도 어떤 프로덕트를 추구하는지, 어떤 조직으로 이루어져 있는지에 맞춰 세부적인 역할을 변경하여 수행해야 합니다.

과거 프로젝트 중심의 PMO(Project Management Office) 조직도 변화하고 있습니다. PMO를 먼저 꾸리고 프로젝트 조직을 구성하던 방식에서 대형 스크럼 조직을 운영하기 위한 SoS(Scrum of Scrums), 프로덕트를 중심으로 한 PPO(Product and Portfolio Office), 고객 가치 중심의 VMO(Value Management Office) 조직이 등장하고 있습니다. 역할은 비슷하지만 어디에 더 무게 중심을 두는지에 따라 운영해야 할 팀과 그에 따른 역할이 달라집니다.

7 마치며

고객 가치에 더 가까이 다가가기 위한 PM의 역할은 진화해왔습니다. 앞으로도 변화에 적응하며 또 다른 역할이 필요할지 모릅니다. 그런데 이런 변화를 겪는 동안 프로젝트를 수행하는 개발팀원을 관리하는 노력도 같이 발전했을까요? 최일선에서 고객 가치를 구현해내는 개발자의 욕구 해소에 대한 역할을 누군가가 수행하고 있을까요?

PMBOK에서는 이론적으로나마 프로젝트 팀원을 관리하는 기술을 소개하고 있습니다. 팀 구성의 각 단계(형성기·혼돈기·규범기·성취기·해산기)에서 해야 할 역할과 동기 부여를 위한 팀원들의 욕구 이론, 팀원간의 갈등을 중재하는 기술 등 프로젝트 팀원을 관리하는 노력 또한 PM의 역할입니다.
아래 문장은 2021년 개정된 PMBOK 7판에서 팀에 대한 내용 일부를 발췌한 것입니다.

"It is impossible to deliver sustainable outcomes without a team that collaborates and works together towards the same objective."

소프트웨어 기술과 개발 방법론이 발전하면서 고객 가치에 더 가깝게, 더 빠르게 다가갈 수 있게 되었습니다. 그만큼 지속 가능한 결과를 위한, 지속 가능한 팀을 관리하는 방법 또한 함께 고민했으면 하는 바램을 가져봅니다.


  References
[1] PMBOK® Guide 6th Edition Project Management Institute. 2019
[2] PMBOK® Guide 7th Edition Project Management Institute. 2021
[3] Transforming The PMO Into A PPO To Become A Product-Driven Enterprise, fobes. 2020. 7. 22
[4] The Rise of Value Management Office . pwc 24 July 2019
[5] https://www.redhat.com/ko/topics/microservices/what-are-microservices
[6] https://www.romanpichler.com/blog/product-leadership-in-scrum/


▶ 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에게 저작권이 있습니다.
▶ 해당 콘텐츠는 사전 동의 없이 2차 가공 및 영리적인 이용을 금하고 있습니다.