인사이트리포트

배경

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

PM의 역할

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

“고유한 제품, 서비스, 또는 결과물을 창출하기 위해서 한시적으로 투입하는 노력”

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

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

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

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

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

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

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

개인의 소프트웨어 사용이 보편화 됨에 따라 소프트웨어 시장은 엔터프라이즈 SI 개발 중심에서 개인화된 컴퓨터와 모바일 중심의 비즈니스 시장으로 빠르게 전환되었다. 그러나 전통적인 폭포수 방식으로는 빠른 개발을 통한 신속한 시장 진입이 어려워졌다. 변화에 좀 더 민첩하게 대응할 수 있는 새로운 개발 방식이 요구되면서 애자일 방법론이 등장했다.
애자일의 기본 원칙은 가치 있는 소프트웨어를 지속적으로 전달하여 고객을 만족시키는 것이었다. 애자일 원칙을 따르는 여러 개발 방법론 중 스크럼 방법론은 2~3주간의 스프린트 결과물을 모든 이해관계자와 같이 확인하고 다음 스프린트를 계획한다. 피드백을 수렵하고 목표를 조정한 후에 다시 스프린트를 진행함으로써 변경에 대한 유연성을 갖고 고객의 가치에 좀 더 가깝게 다가갈 수 있게 되었다.

스크럼 조직에서 PM의 역할은 SM(Scrum Master)과 PO(Product Owner)가 대신한다. SM은 스크럼 팀이 효율적으로 운영될 수 있도록 프로세스에 대한 책임을 가진다. 개발팀의 장애물을 제거하여 업무 효율을 높이고 스프린트가 원활히 진행 될 수 있도록 운영한다. 팀 자원과 의사소통 그리고 리스크를 관리하는 역할에 더 집중하는 것이다.
제품을 책임지고 고객의 가치를 고려하여 그에 따른 의사결정을 하는 역할은 PO가 가져 갔다. PO는 각 이해관계자와 꾸준히 커뮤니케이션 하면서 요구사항을 분명히 한다. 중요한 결정 권한을 SM에게 주지 않는 대신 지속적으로 참여하고 이해관계자들과 의사소통하며 제품의 가치를 종합적으로 판단하며 빠른 결정을 내린다. PM의 예산 관리에 대한 역할도 마찬가지이다.

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

최근 소프트웨어 영역에서 등장한 큰 변화는 바로 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까지 맡으면서 전방위적 역할을 담당한다. 서비스를 담당하는 데브옵스팀과 긴밀한 커뮤니케이션이 필요하고 기술적 결정을 많이 해야 하기 때문에 테크니컬 프로그램 매니저라고도 불린다.

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

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

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

마치며

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