정부의 디지털 정책으로 PM의 도입은 시사점이 매우 명확하다.
이 글은 제가 KISA [한국 인터넷진흥원]의 < KISA Report > 2021년 4월호에 기고한 글입니다. 원본 글 '캐나다 정부의 프로덕트 매니지먼트 정책 시도의 의미' 을 이곳 브런치에도 공유합니다.
많은 나라의 정부가 추진하는 정보기술 정책에는 유사성이 있다. 기술에 대한 만성적인 과소 투자, 품질 기반 성능 평가시스템보다는 비용 중심적 평가, 사회 변화에 따른 데이터 및 디지털 역할의 확산 요구는 많으나 종종 디지털 리더십이 부족하고, 임기 내 위험 부담을 회피하는 환경을 갖고 있다. 많은 정부에서 정부 CIO 조직을 마련하고 컨트롤타워로의 역할을 추진하려 하고 있지만 CIO의 비전과 목표만으로는 기존의 업무 관행을 바꾸는 것은 거의 불가능하다.
캐나다 정부는 2009년 연방 공무원을 위한 새로운 급여시스템을 완전히 갱신하는 프로젝트 를 야심 차게 시작한다. ‘피닉스 급여 시스템’ 이라 이름 붙여진 이 거대한 프로젝트는 2년 동안 기술 파트너를 찾는데 시간을 보내고 2011년 IBM과 3천만 달러 계약을 맺는다. 그 후에 수많은 잡음과 충돌이 나고, 예산은 한정 없이 늘어나고, 2016년에 1월에 30만 명의 직원 신상정보가 유출이 된다. 그 후 2월에서야 첫 번째 출시가 된다. 품질 문제가 곧 나타나기 시작했고, 2017년 6월 말까지 누적 급여 오류가 5억 달러를 넘게 되었다. 엄청난 실패를 가져다준 프로젝트였다. 프로젝트가 실패한 원인은 다음과 같이 정리된다.
엔드 투 엔드 프로세스 변환에 대한 전반적인 관리가 제대로 이루어지지 않았다.
비즈니스 프로세스, 인력/기술, 조직 문화, 서비스 및 기능, 인사 데이터 및 관련 인사 시스템의 품질 및 적시 제공에 대한 포괄적인 계획이 개발되거나 구현되지 않았다.
정부 전체의 일관성을 위한 공통 비즈니스 프로세스가 충분히 상세한 수준으로 구현되지 않았다.
역할과 책임에 관해 설계, 문서화 또는 전체적인 프레임워크의 일부로 구현되지 않았다.
전반적인 거버넌스 기구는 없었다.
위험에 대해 오픈하는 문화가 없었고, 진실에 대해 말하는 것을 허락하지도 않았다.
충분히 테스트되지 않았다. 테스트 볼륨과 적용 범위는 시간 및 예산 압박으로 인해 최종 단계에서 축소되었다.
이렇게 어마어마한 예산을 들여 추진했던 프로젝트가 완전한 실패로 끝난 뼈아픈 경험을 가진 캐나다 정부가 최근 정보기술 부분에서 꽤 인상적인 변화를 만들고 있다. 소위 소프트웨어 기업에서 활용하고 있는 프로덕트 매니지먼트 관리기법을 사용하고 디자인 씽킹(Design Thinking), 린스타트업(Lean Startup), 애자일(Agile), 데브옵스(DevOps)까지 도입하며 빠르게 변화를 시도하고 있다.
그림 2는 캐나다 정부의 공공 디지털 서비스를 제공하는 캐나다 디지털 서비스(CDS)가 프로덕트 매니지먼트 그룹장을 채용 하는 공고이다. 정부가 사용하는 프로덕트/서비스를 기획하는 프로덕트 매니저를 관리하고, 정부와의 파트너 관계를 유지하면서 요청하는 디지털 서비스에 대한 비전과 솔루션을 제공하는 역할이다. 공고 내용을 살펴보면 실리콘 밸리에서 채용하는 프로덕트 매니지먼트 그룹장의 기준, 경험이나 역할과 다르지 않다. 단지 업무 파트너로서 정부 부서를 상대할 뿐이다.
매우 놀라운 변화가 아닐 수 없다. 많은 나라의 정부가 디지털 트랜스포메이션을 표방하고 변화를 시도했지만, 실제 프로덕트 매니지먼트를 도입하여 실행하고 있다는 것은 생각보다 훨씬 더 많은 변화를 의미하기 때문이다. 그중에서도 가장 큰 변화는 정부 디지털 서비스의 기준이 ‘프로젝트’에서 ‘프로덕트’로 패러다임이 넘어왔다는 것을 의미한다.
캐나다 정부뿐만 아니라 많은 정부의 정보기술 업무 추진 방법은 전통적인 ‘워터폴(waterfall)’ 접근법이다. 워터폴 방법론은 그동안 오랜 기간 동안 정부의 예산시스템과 함께 다음과 같이 동작한다.
① 몇 년 후에 실제 효과가 발생하고 완료 상태로 끝나게 될 프로젝트를 계획한다.
② 소프트웨어를 구입하고 용역 업체 또는 컨설팅 회사를 고용하여 비즈니스 프로세스를 재설계하고 시스템을 구축한다.
③ 진행되면서 계획하지 않은 수정 사항이 많이 발생한다.
④ 용역 업체와의 계약 변경 수시로 발생한다.
⑤ 결과적으로 비용과 시간이 초과되기 쉽다.
⑥ 프로젝트는 무언가를 만들고 난 후 끝난다.
⑦ 프로젝트가 종료된 후에도 IT 조직은 이를 유지해야 한다.
⑧ 수정과 업그레이드는 어렵고, 비용이 많이 든다.
디지털 세계에서 프로덕트라는 의미는 제품 수명 주기 관리 (PLM: Product Lifecycle Management)를 하는 대상을 뜻한다. 아래 그림과 같이 버전을 높여가면서 지속 가능한 가치를 제공하는 것을 프로덕트라고 한다.
프로덕트 매니지먼트를 한다는 것은 위에서 이야기한 워터폴 프로젝트의 개념과 상충될 수밖에 없다. 워터폴이 끝나는 시기를 정해두고 시작하는 데 반해 PLM은 끝나는 시기가 정해져 있지 않다. 한 번의 딜리버리로 모든 기능과 피드백이 포함되는 워터폴 접근법과는 달리 프로덕트의 관점에선 지속적인 발전과 개선이 이루어진다. 즉 디지털 세계에서 특히 공공서비스 영역에서 프로덕트는 다음과 같이 정의할 수 있다.
외부 (일반 시민)또는 내부(타 공공 부서, 공공서비스 요원) 고객에게 반복적인 서비스를 제공한다.
고객에게 가치 있는 기능을 제공한다.
이름이 있으며 명확하게 정의할 수 있다.
플랫폼일 수 있다.
구매, 판매 또는 구독 모델로 가입 가능하다
경쟁자가 있을 수 있다.
프로젝트 주도형 관점과 프로덕트 주도형 관점의 가장 큰 차이점은 이 결과물이 어떻게 생산되느냐에 초점(프로젝트 주도형)을 맞추는 것이 아니라, 어떻게 소비되는지(프로덕트 주도형)에 맞추는 것이다.
아래의 그림은 가트너가 조사한 공공서비스에서 프로덕트 주도형 딜리버리 모델의 이점을 방사형 차트로 정리한 것이다.
10가지 거론된 지점에서 모두 이점이 있지만 특히 강조되는 점이 바로 ‘정보기술과 비즈니스와의 긴밀한 연합’을 들 수 있다. 지금까지 시간에 맞추어 기술 중심의 밀어내기식 딜리버리 모델에서 실제 사용자가 만족하는 비즈니스 기능이 정보기술과 연합하여 제공되는 것에 가장 큰 장점이 있는 것이다.
그 외에 혁신적이고 새로운 기능의 신속한 제공, 고품질 확보, 고객 요청을 용이하게 핸들링하고, 공공서비스 영역에서 조달 규정 및 정책을 보다 쉽게 준수할 수 있었다는 점은 매우 중요한 시사점이라고 볼 수 있다.
프로덕트 중심의 딜리버리 모델의 이점을 이해했다면 이젠 조직에 프로덕트 매니지먼트 구조를 도입해야 한다. 이것은 어떤 의미이고 어떤 곳에 어떤 프로세스를 만들어야 하는지 밑의 그림을 보면서 이해를 해 보자. 가장 중심에 일하는 방식을 이제는 더 이상 프로젝트 중심의 워터폴 접근법을 쓰지 않는다는데 있다. 프로덕트 중심의 애자일 접근법으로 변환이 일어나야 하는 것이 맨 처음 생각해야 하는 부분이다.
그 외에 비즈니스 모델, 전략, 조직의 문화와 지금까지 이루어진 기업 내 업무 진행방식이 모두 영향을 받을 수 있다.
캐나다 정부가 프로덕트 매니지먼트를 도입할 때 가장 힘들었던 부분은 기존의 조직에 ‘프로덕트 매니저’라는 역할을 만들어 내는 것이라고 했다. 기존 정부의 직무 분류에 이런 역할은 없었기 때문이었다. 결과적으로는 성과물을 만드는 책임 역할을 하는 프로덕트 매니저를 둘러싼 운영방식을 구현해 냈다. 프로덕트의 총 생사 책임을 지는 프로덕트 보드(리더십) 팀을 꾸리고, 그들의 구성은 공공비즈니스를 알고, 각 관계부서의 대표성을 가진 이들로 구성한다. 프로덕트 보드팀은 입법기관이나 재정을 관리하는 부서로부터 프로덕트를 개발, 관리하기 위한 재정지원을 받는다. 입법기관, 재정 관리 행정기관에서는 그 프로덕트의 사용자나 이용자가 될 시민, 시민단체, 공공기관들에게 제공될 프로덕트를 홍보하고 프로모션 하며, 그들로부터 요구된 프로덕트 제안이나 개선점은 프로덕트 보드를 통하여 프로덕트 매니저와 실제 개발팀에 전달되도록 하는 구조를 갖는다.
이런 하나의 모델은 하나의 프로덕트를 가졌을 때 매우 단순한 구조로 보일 수 있다. 하지만 이런 프로덕트들이 하나씩 늘어나면서 숫자의 늘어남 뿐만이 아니라, 각각의 프로덕트끼리도 연결성을 갖는 경우가 생긴다. 마이크로소프트의 오피스 제품군을 예로 이해하면 좀 더 쉬울 것 같다. 워드, 엑셀과 같은 각각의 제품을 책임지는 프로덕트 매니저 위에 그 통합된 오피스 프로덕트 스위트를 책임지는 라인 매니저가 위치하게 되고, 프로덕트 라인을 다 묶어서 전사적 자원관리(ERP)와 같은 통합 복합 프로덕트 전체 군을 책임지는 ‘프로덕트 헤드’가 운영하는 조직 구조를 갖게 된다. 예를 들어 호주의 퀸즈랜드 주 정부에서는 운전면허증이나 낚시 면허증을 디지털로 관리하는 정부 디지털지갑 프로덕트 를 단독으로 기획하게 되었는데 이 반응이 좋아지면서, 실제 패스포트나 주민등록증도 함께 관리하게 되는 범 정부 프로덕트로 확대되어 실행된 좋은 사례가 있다.
프로덕트의 로드맵을 작성하기 위해서는 맨 처음 어떤 관점을 갖고 그 관점에 맞게 기능을 배치시키느냐가 우선되어야 한다. 즉 우선순위를 만드는 작업을 하고 그 후에 그 기능을 구현하기 위한 비용 (시간, 노력, 난이도, 재정비용)을 모두 계산하여 모든 것을 한 번에 완성하는 것이 아닌 지속적 개발과 가치 투여를 하는 과정을 거친다. 이것을 가장 보편적으로 접근하는 방법이 GE-매킨지 아홉 상자 매트릭스(GE-McKinsey Nine Box Matrix) 모델인데, 두 개의 관점 축을 따라서 상중하의 기준을 세우고 그곳에 기능을 배치시킨다.
캐나다 정부가 시도한 대민행정서비스 프로덕트를 예로 들어보면, 품질을 측정하게 될 두 개의 축은 고객 경험을 개선하는 방향과, 실제 행정서비스의 업무 생산성이 지표가 될 수 있다.
고객 경험의 상세 목표지표는 의사결정 주기를 단축한다거나, 보다 인식하기 쉬운 UI를 도입하여 솔루션을 빨리 찾는다던가, 정보의 정확성, 옵션의 명확성 등으로 규정할 수 있다. 다른 목표지표의 축은 이 프로덕트를 사용했을 때 생기는 내부의 행정서비스 생산성을 예로 들 수 있다. 공무원의 노동시간 단축에 도움을 줬다던지, 업무 연결성을 높이고 오류를 감소시켰다는 상세 목표 지표를 둘 수 있다. 또한 이런 목표지표를 만족한다고 할 때 해당 기능의 투자 대비 수익률(ROI)이 얼마나 될까를 생각해야 한다. 투자라고 해서 비용을 이야기 생각하면 안 되고, 투자는 고객의 경험 개선과 생산성 개선 같은 무형의 투자가치도 생각하여 결정한다.
이 과정이 지나고 나서는 대민 행정서비스에 필요한 모든 기술 기능을 검증하고 두 축에 해당하는 지표에 따라서 그 기능을 위의 9개 상자에 배치시켜본다. 위와 같은 실험을 통해서 다음과 같은 매트릭을 만들 수 있다. 즉 필요하다고 판단하는 모든 기능을 열거하고 배치시키면서 난이도 세팅을 통해서 프로덕트 로드맵에 필요한 보다 명확한 가치 판단 기준을 만나게 된다.
이곳에 기술한 기능들은 모두 잠재적인 프로덕트이지만 모두 다 프로덕트화 할 필요는 없다. 맨 오른쪽 상단에 있는 적격성 심사(Eligibility Determination)는 부가가치는 굉장히 높지만, 그 기능을 구현하는 것은 쉽지 않은 것으로 분류가 되었다. 이런 기능일수록 전문가 팀을 동원하고, 중앙정부뿐만 아니고 지방정부에서도 필요한 요구사항을 취합하여 공통적으로 사용할 수 있는 프로덕트로 설계해야 한다. 제품의 개발뿐만이 아니라 나중에 발생하게 될 딜리버리 비용, 유지보수 비용을 모두 단순하고 일원화시키는 작업이 필요한 것이다. 얼마나 수많은 공공서비스가 많은 기능을 중복으로 개발하고, 관리하고, 일관성 없이 운영을 하는지 우리는 수많은 경험이 있다. 캐나다 정부가 이런 프로덕트 중심 접근법 시도를 통해 업무 생산성 향상과 시민들의 공공서비스 경험이 개선되었다는 것은 다른 나라의 정부에도 큰 모범사례가 된다.
프로젝트 중심의 접근법에서 프로덕트로 그 중심이 이동한다는 것은 마인스 셋만의 변화가 아닌 일하는 방법과 조직이 함께 변화해야 얻을 수 있다. 즉 해결해야 할 어려움과 이점을 모두 가지고 있다. 더 빠른 딜리버리와 높은 품질, 위험 감소, 다수의 수혜자와 같은 이점은 전통적인 업무 문화, 과정, 변화에 대한 거부감과 같은 어려움을 충분히 능가한다. 캐나다 정부의 사례가 말하는 여러 정부조직에서 사용할 수 있는 유사한 기능을 파악하고 그것에 맞는 제품을 딜리버리 하는 것은 대단한 성과이다. 그렇다고 지금까지 수행했던 모든 프로젝트 중심의 딜리버리 방법을 한 번에 바꿀 수는 없다. 충분한 가치판단 평가가 있은 후에 작은 프로덕트부터 시작하기를 바란다. 아무리 작은 프로덕트라고 해도, 위에서 설명한 프로덕트 보드/리더십팀과 입법기관이나 재정을 관리하는 부서에게서 재정 지원을 받는 과정을 함께 시작해야 한다. 정해진 시간 내에 완성형을 딜러버리 하는 프로젝트와 동일한 방법으로 제품에 자금을 지원하지 않기 때문이다. 선진국 정부라면 모두 디지털 트랜스포메이션을 외치고 있다. 그 속 내용을 살펴보면, 모두 프로젝트로 진행하기 보다는 솔루션 형식의 프로덕트를 개발하고 지속적인 품질 개선을 통해서만 이루어질 수 있는 과제들로 이루어져 있다. 이런 시점에 캐나다 정부의 프로덕트 매니지먼트 도입 사례는 좋은 참고가 될 것이다.