디지털서비스 이슈리포트

01 플랫폼으로서의 정부 (3) - 성공을 위한 실행 전략

        │윤대균 아주대학교 교수

지난 두 차례의 칼럼에서 플랫폼으로서의 정부(GaaP: Government as a Platform) 개념과 이를 성공적으로 이끌기 위한 기본 요건들에 대해 정리해 보았다. 다시 한 번 환기하는 차원에서 간단히 정리해 보면 다음과 같다.

웹 2.0, Gov 2.0, GaaP

2000년대 말 개방과 공유, 그리고 참여를 기치로 내건 “웹 2.0”이 관심을 받기 시작한 이래 불과 수년 사이 “플랫폼”을 표방한 서비스가 인터넷 시장을 장악하게 되었다. 자연스럽게 “플랫폼 경제”는 현대의 경제 체제를 대표하는 한 형태로 자리 잡았다. 웹 2.0의 정신을 정부와 공공기관의 서비스에 투영한 것이 Gov 2.0이다. 이전 칼럼에서 소개했듯이 정부에서 제공하는 서비스의 개념이 이전에는 자판기 정부 개념, 즉, 국민이 세금을 낸 만큼 정부가 서비스를 제공하는 것이었다면1), Gov 2.0은 시민이 직접 참여하여 공공서비스를 만들고 발전시키도록 하는 것이다. 팀 오라일리(Tim O’Reilly)는 2005년 웹 2.0을 비즈니스 모델과 소프트웨어 디자인 패턴 관점에서 정의한 바 있다.2) 집단지성 활용의 중요성, 그리고 데이터 중심의 플랫폼을 강조하였는데 이는 오늘날 플랫폼 경제를 정의하는 핵심이기도 하다.

Gov 2.0을 정부에서 제공하는 플랫폼 서비스로 발전시킨 개념이 GaaP이다. 팀 오라일리는 자신이 쓴 글에서3) “Government as a Platform”이란 표현을 본격적으로 도입하며 GaaP이 갖추어야 할 요건들을 제시하고 있다. 이를 한 줄로 요약하면 다음과 같다.

“개방과 공유를 바탕으로 시민의 참여를 통한 혁신과 성장을 추구하는 것”

이와 함께 GaaP이 성공하기 위한 기본 지침도 제시하였는데 이를 다시 소환해 보면 다음과 같다.

• 개방과 공유를 위한 실행 지침을 먼저 만든다.

• 데이터를 기반으로 한 서비스 중심의 구조를 지향한다.

• 정부 데이터 개방의 기본 원칙을 숙지하고 반드시 따른다.

• 만일 정부가 주도하여 “무언가”를 개발해야 한다면, 이 역시 개방과 공유를 최우선 목표로 한다.

• 정부와 공공기관에서 사용하는 애플리케이션 생태계를 위한 앱스토어를 갖춘다.

• 각 부처/조직간 업무를 투명하게 공유하고, 자랑할 것은 자랑하며, 잘 모르는 것에 대해서는 물어보는 것을 주저하지 않는다.

특히 맨 마지막 항목이 매우 중요하다는 것을 재차 강조하고 싶다. GaaP이 제대로 동작하지 않는다면 아마도 가장 큰 원인은 부처 간 사일로 현상으로 인한 소통 단절일 것이다. 플랫폼이 성과를 내기 위해서는 범정부적인 개방과 공유의 노력이 수반되어야 하며, 이를 반드시 부처 성과 목표에 담아야 한다. 팀 오라일리가 GaaP에 대한 정의, 그리고 성공 기준이 되는 지침을 만들었다면, 이를 실제 가장 먼저 실행으로 옮기는 시도를 한 대표적인 사례는 영국 정부에서 찾을 수 있다. 영국 정부는 GDS(Government Digital Service)를 설립하여 정부 사이트인 GOV.UK를 기본 포털로 활용하는 GaaP을 구현하려고 노력했다. 이런 노력은 어느 정도 결실을 보아 이후 많은 다른 정부의 디지털 전략 수립의 모범적인 사례로 인용되고 있다.

GDS의 초기 설립 멤버이자 GOV.UK의 프로덕트 매니저로 활동한 리차드 포프(Richard Pope)는 자신의 경험에 바탕을 둔 GaaP 플레이북(Playbook)을 발표했다.4) “플레이북”이란 게임에서 승리하기 위한 전략, 규칙, 실행 방법 등을 명시한 것인데, 저자는 GDS에서 수행한 여러 프로젝트를 통해 터득한 GaaP로 성공하기 위한 “노하우”를 공유하고자 한 것이다. 이번 칼럼에서는 리차드 포프의 플레이북을 중심으로 GaaP이 성공하기 위한 실행 전략을 살펴보고자 한다. 그 출발점은 시민 경험에 초점을 맞춘 디지털 서비스 전략이다.

시민 경험 중심의 디지털 서비스

정부에서 제공하는 디지털 서비스의 핵심 가치는 향상된 “시민 경험(Citizen Experience)”에 있다. 그러나 최근까지 우리나라 정부의 디지털 정책은 시민 경험을 중시하는 것과 다소 거리가 있다. 우리나라의 정부 1.0에서 정부 2.0을 거쳐 정부 3.0으로 넘어오는 과정에서 각 단계가 추구하는 목표가 시민 경험의 향상과 일부 맥락을 같이 하고 있기는 하다. 정부 1.0은 행정 서비스의 효율화에 초점을 둔 공급자, 즉 행정부 중심의 전략이 주를 이루었다. 이는 정부 2.0까지 계속 이어졌으나 인터넷 활성화 특히 모바일 서비스 활성화를 통해 인터넷으로부터 소외된 계층이 대폭 줄어듦에 따라 정부 3.0에서 비로소 사용자 중심의 정부 서비스를 표방하게 된다. 과연 일반 시민들은 이런 변화에 대해 충분히 공감하고 있을까?

예전보다 훨씬 많은 시민이 정부의 디지털 서비스를 적극적으로 활용한다는 측면에서 분명 의미 있는 성과를 거두었다고 볼 수 있다. 그러나 우리 주위에서는 이런 성과를 무색하게 하는 정부 서비스를 쉽게 찾아볼 수 있다. 대한민국 성인이라면 인감도장은 하나 가지고 있어야 정상적인 경제생활을 할 수 있다는 사실, 취업이라도 하려면 직접 발급받아 제출해야 하는 수많은 증명서, 이젠 사라졌다고 하는 공인인증서도, “공동인증서”로 이름만 바꾸어 여러 곳에서 요구하는 등 아직 갈 길이 멀다.

시민 경험 관점에서 한 예를 들어보자. 디지털 서비스가 전혀 되어있지 않은 세상에서 차량 등록을 위한 과정은 상상을 초월한다는 표현이 가장 적절하다. 우리 대부분 이런 경험을 해 보지 않았기 때문이다. 우리는 최소한 어느 정도 “디지털화(전산화)” 되어있는 세상에서 자동차도 사고 이를 등록하는 경험을 해 보았을 것이다. 차량 등록소에 가서 줄을 서고 필요한 서류를 제출하고 마지막으로 차량 등록증을 발급받는 과정이 어느 정도 디지털화되어있기 때문에 그나마 당일 차량 등록을 마칠 수 있게 되었다. 차량 등록소는 제한된 인원으로 더 많은 민원서비스를 해결할 수 있다. 초기 “디지털화”는 이런 효율화에 초점이 맞추어져 있다. 만일 세무서에서 차량 등록 서류를 요구한다면 어떤 일이 벌어질까? 이를 해결하기 위해서 다음 세 가지 해결책을 생각해 볼 수 있다.

• 민원인이 차량 등록증을 가지고 세무서에 가서 원본을 확인시키거나, 혹은 사본을 제출한다.

• 민원인이 인증된 등록 정보를 차량 등록 서비스로부터 받아 저장한 후 이를 세무서 민원서비스를 통해 제출한다.

• 세무서는 차량 등록 서비스 플랫폼에서 제공하는 API를 이용해 해당 민원인의 차량 등록 정보를 가져온다. 단, 민원인이 사전에 정부 기관 간 데이터 공유에 대해 승인을 한 상태를 가정한다.

민원인 관점에서 가장 편리하다고 할 만한 서비스는 당연히 세 번째 방식이다. 이를 가능하게 하는 것은 우선 차량 등록 서비스와 세무서 서비스 간 데이터가 이 데이터 주권자의 동의하에 상호 공유된다는 사실이다. 특히 단순 공유가 아닌 안전한 API 호출을 통해 타 기관의 플랫폼 서비스를 활용할 수 있게 한 것이다. 각 기관의 서비스가 사일로(Silo)화 되어있어서는 절대 불가능한 일이다. 민원인, 즉 시민 관점에서 최선의 경험을 위해서는 각 기관의 서비스가 “플랫폼화” 되어있어야 함을 뜻한다. 시민 경험은 정부의 디지털 서비스 성숙도를 결정하는 가장 중요한 기준이기도 하다.

그림 1 디지털 성숙도 기준 및 단계별 특징(출처: 딜로이트)

디지털 전환이 한창 화두로 대두되던 시기 딜로이트에서 발간한 한 리포트에서5) 가장 성숙한 정부 디지털 서비스는 사용자를 중심에 두고 있음을 구체적으로 언급하고 있다(그림 1). 여기서 추가로 눈여겨볼 부분은 “문화(Culture)” 항목이다. 이는 정부 디지털 서비스를 관장하는 기관에서의 조직 문화와도 직결되는 부분으로, 디지털 전환이 성숙해지기 위해서는 위험을 회피하거나 견디려고 하는 것보다는 오히려 이를 받아들이고 오히려 혁신의 발판으로 삼아야 한다는 것이다. 이는 GaaP의 개념에서 언급한 “실패를 당연한 것으로 여기는” 요건과도 부합한다. 그리고 시민 경험의 혁신을 위해 정부가 나서기보다는 일반 시민이 직접 문제를 해결하고 혁신을 이끌어야 한다는 것과도 일맥상통한다.

리차드 포프는 이러한 플랫폼 중심 변화의 예로 미국 베테랑(참전용사) 서비스를 들었다. 미국에서의 베테랑의 위상은 매우 높아서 다양한 혜택과 보상이 여러 정부 기관에서 제공된다. 베테랑들에게 이런 서비스를 원활하게 제공하기 위해 베테랑 운영 당국은 베테랑과 관련된 서비스 API를 개발해 다른 정부 기관 및 민간에서도 활용할 수 있도록 했다고 한다. 베테랑 경험 중심 즉 시민 경험 중심의 서비스를 위한 플랫폼의 중요성을 인식한 것이다. 이 외에도 인도, 에스토니아, 영국 등의 디지털 전환 사례를 언급하며 시민 경험을 중시하는 정부 플랫폼 예를 들고 있다.

성공적인 GaaP 구현을 위한 실행 전략

리차드 포프는 열 가지가 넘는 항목을 실행 전략으로 제시하고 있다. 이 중 일부는 합치고, 굳이 언급이 필요하지 않은 것은 제외하였으며 여기에 필자가 판단하기에 추가로 살펴봐야 할 내용을 섞어 다음과 같이 GaaP 구현 시 고려해야 할 주요 실행 전략을 정리해 보았다.

• 1.GaaP 사용자에 대한 명확한 이해

앞서 시민 경험 중심의 디지털 서비스를 언급한 이유는 GaaP에서 추구하는 가장 중요한 가치가 사용자 경험, 즉 시민 경험이기 때문이다. 이의 첫 단추는 사용자를 이해하는 것이다. 디지털 서비스는 사용자의 수요(needs)를 중심에 두고 설계되어야 한다. 그런데 성공적인 GaaP의 목표는 개방과 공유, 그리고 시민 참여를 바탕으로 한 성장과 혁신이다. 플랫폼은 그 자체가 최종 사용자 즉 일반 시민을 위한 서비스가 아니다. 이를 다양한 형태로 조합 활용하여 최종 시민이 사용하는 서비스가 완성된다. 즉, GaaP의 관점에서 사용자는 이를 활용하여 혁신적이며 사용자 친화적인 서비스를 만들어 내는 개발자 커뮤니티라 볼 수 있다. 플랫폼은 다른 많은 서비스에서 활용할 수 있는 일종의 부품과 같은 것이란 사실을 분명히 인식해야 한다. 공공 혹은 민간에 걸쳐 이런 플랫폼을 활용하여 다양한 서비스를 만들어 낼 사용자들이 분포되어 있다.

본격적인 플랫폼 설계 전에 이런 커뮤니티와 함께 만들고자 하는 플랫폼이 어떻게 서비스에 활용될 수 있을지 충분한 사전 연구가 필요하다. 주요 사용자, 즉 함께 연구하고 설계하여야 할 대상은 개발자와 디자이너 외에도 정부의 관련 업무를 수행하는 사람들도 포함한다. 예를 들어 정부 조달업무를 담당하는 사람, 행정 관료들, 그리고 정치인이나 고위 관료들이다. 필요에 따라 관계 입법 및 법령 제정 등도 GaaP 실행 전략에 매우 중요한 부분이다. 물론 플랫폼을 기반으로 만들어진 최종 서비스 사용자들의 참여도 성공적인 GaaP 설계를 위해 필요하다. 결국, 이들이 필요로 하는 서비스를 충분히 만들어 낼 수 있는 소위 “빌딩 블록”들을 제공할 수 있어야 하기 때문이다.

정부 플랫폼 사용자는 디지털 서비스를 사용하는 일반 시민이 아니라 플랫폼을 이용해 서비스를 만드는 개발자와 디자이너, 그리고 플랫폼 개발에 필요한 지원을 제공할 정부 관계자들이다.

리차드 포프는 자신이 영국 GDS에 참여하여 활동했을 때의 경험을 얘기하며 자신들도 처음에는 일반 시민들을 상대로 다양한 조사를 벌이기 시작했으나, 추후 이런 대상이 자연스럽게 정부 관계자들로 전환되는 과정이 있었다고 한다. 플랫폼으로서의 기능에 대해 고민을 할수록 각 정부 기관에서 대민 서비스를 제공하는 사람들과의 소통, 특히 이런 서비스를 개발하는 팀들과의 긴밀한 협업이 필요했다는 것이다. 실제로 정부 전반에 걸쳐 있는 팀들과 150회의 인터뷰를 진행했다고 한다. 주로 질문했던 내용은 이런 것이다.

• “당신의 사용자들에 대해 말해주세요.”
  “사용자들의 요구를 잘 충족시키고 있는 것들은 무엇입니까?”
  “사용자들이 필요로 하고 있는데 아직 만족시키지 못하고 있는 것은 무엇입니까?”

2. 플랫폼에 대한 정확한 이해, 그리고 이에 기반한 설계

플랫폼은 앞서 언급한 것처럼 “빌딩 블록”이다. 즉, 사용자들의 공통된 요구사항에 대한 해결책을 제공한다. 예를 들어 정부에서 제공하는 다양한 서비스에 필요한 공무원 사용자 인증 플랫폼 같은 것이 있다면 이는 공무원 인증이 필요한 모든 서비스에서 공통으로 사용될 수 있다. 민간 개발자들은 이런 기능을 활용하여 공공을 대상으로 한 다양한 서비스를 만들 수 있다. 중복적으로 발현되는 수요를 찾는 것이 플랫폼으로 가는 첫 번째 과업이다. 만일 플랫폼을 만들어야 하겠다는 고민을 지금 하고 있다면, 이는 이미 여러 서비스에서 중복적으로 발현되는 수요를 알고 있다는 뜻이다. 사용자 인증 서비스 같은 것이 거의 모든 서비스에 늘 사용되는, 즉 “중복적으로” 수요가 있는 대표적인 예이며, 미국이나 우리나라에서 적극적으로 추진 중인 공공데이터 허브도 다양한 서비스에서 반복적으로 활용될 수 있는 데이터 플랫폼이다.

이렇게 “플랫폼”화 되어야 할 기능을 찾아내는 것은 그리 단순한 일이 아니다. 다양한 서비스를 제공하는 민간 기업에서의 오랜 경험을 돌이켜 보면, 각 서비스가 진화하며 설사 이들 사이에 많은 공통부분이 눈에 뜨인다고 하더라도 각각 다른 조직에서 운영되는 서비스를 분석하고 여기서 플랫폼으로 제공되어야 할 요소를 찾아내는 것이 절대 “자연스럽게” 이루어지지 않는다. 별도의 팀을 만들어 각 서비스 팀들과 깊은 소통이 필요한 것은 기본이고, 플랫폼 사양이 정해진 이후에도, 플랫폼 개발, 기존 서비스 리모델링 등 넘어야 할 일들이 많다. 정부 플랫폼 관점에서는 우선 동일 기관 내에서의 중복 서비스부터 찾는 것이 필요할 것이고, 이후 기관 간 공통 요소를 찾아 나아가는 과정이 필요하다. 한 기업 내에서도 쉽지 않은 일을 정부에서 어떻게 할 수 있는가라고 반문할 수 있다. 하지만, 정부는 개방된 플랫폼으로서 오히려 이를 이용한 민간이 개발할 서비스를 유도하는 것이기 때문에 기존 서비스에 발목을 잡힐 필요가 없다. 정부 플랫폼을 기반으로 한 새롭고 혁신적인 서비스를 통해 시민 경험을 높이는 것이 목적이기 때문이다.

플랫폼에서 제공되어야 할 아이템들이 결정되면 이를 “어떻게” 제공할 것인가 하는 다음 단계를 넘어야 한다. 다양한 정부 플랫폼 서비스에 대한 포털(관문)이 우선 그 첫 번째이다. 플랫폼 포털은 일반 기업 서비스 관점에서 보면 개발자 포털과 같은 것이다. 국내외 주요 인터넷 서비스 기업들은 대부분 개발자 포털 서비스 운영에 엄청난 노력을 기울이고 있다. 각자 자신의 플랫폼을 중심으로 한 생태계를 확대함으로써 시장에서의 영향력을 강화하기 위함이다. 단순히 개발자 포털 운영뿐만 아니라 이를 기반으로 한 커뮤니티 관리에도 많은 자원을 투입한다. 데브렐(DevRel)이라 불리는 개발자 커뮤니티 운영만을 전담하는 직군도 있으며 회사의 브랜드 제고를 위해 중요한 역할을 담당한다. 우리나라 정부에서 가장 취약한 것이 바로 이 부분이다. 현재 운영되고 있는 포털들도 전담 운영자가 전문적으로 관리하기보다는 제3의 업체에 위탁 운영을 맡기는 것이 일반적이다. 수시로 위탁 운영업체가 바뀌기 때문에, 서비스의 개선은 차치하고 일관성을 유지하는 것조차 힘든 상황이다.

플랫폼에서 제공되는 서비스는 API(Application Programming Interface) 방식으로 주로 제공된다. 플랫폼을 제공하는 주체(주관기관) 별로 플랫폼 포털 운영과 함께 API의 라이프사이클 관리를 해 주어야 한다. 데이터 포털의 경우에도 이런 라이프사이클 관리는 매우 중요하다. 특히 시의성이 있는 데이터에 대해 라이프사이클 관리가 제대로 이루어지지 않을 경우, 플랫폼으로서의 효력은 사라지게 된다. API를 설계하고 이를 수요에 따라 수정/개선하는 것은 기술에 대한 상당한 이해가 필요하다. 특히 소프트웨어 아키텍처에 대한 경험이 중요하다. 서로 다른 도메인을 다루는 정부 부처 각 기관에서 이런 전문성을 가진 리더가 필요하며, 또한 이 리더들 간의 소통을 주도하고 정부 플랫폼으로서의 전반적인 로드맵을 만들어 갈 리더와 지원 조직이 필수다. 민간 서비스 기업과의 협력도 빠뜨릴 수 없는 부분이다. 안정적인 플랫폼 서비스를 제공하고, 최신 기술을 적시에 반영하기 위해서는 민간 퍼블릭 클라우드 서비스 활용이 불가피하다. 따라서 정부 플랫폼 서비스를 담당하는 리더는 민간 기업의 서비스 및 기술에 대한 이해를 바탕으로 이들 기업과의 시너지를 낼 수 있어야 한다.

플랫폼을 제대로 이해하고 설계하는 것은 “전문 기술” 영역이다. 특히 플랫폼 사용자들과 같은 언어로 소통하고, 민간 플랫폼 서비스와의 긴밀한 연계를 위해서도 “전문가”가 정부의 플랫폼 리더가 되어야 한다. 아무리 훌륭한 전략이 있다고 하더라도 이를 실행에 옮길 수 있는 전문가가 이끌지 않으면 결코 성공적인 플랫폼 서비스가 만들어질 수 없다.

3. 효율적인 데이터 인프라 설계

데이터 인프라는 정부 제공 플랫폼에서 매우 중요한 부분이다. 따라서 바로 앞서 언급한 “플랫폼에 대한 이해”에서 다룰 수도 있지만, 데이터 플랫폼의 특성상 특별히 따로 강조해야 할 것도 있다. 데이터 개방과 공유 가이드에 대해서는 이전 칼럼에서 상세히 다루었기 때문에 여기서 데이터 플랫폼으로서 갖추어야 할 요건은 따로 언급하지 않겠다.

공유 데이터에 접근하는 방법은 매우 다양하다. 가장 기초적인 방법은 공유 자원을 설정하고 여기에 공유 권한을 부여함으로써 데이터가 필요한 사람들이 직접 접근할 수 있도록 하는 것이다. 작은 조직에서는 매우 효과적인 방법이지만, 정부 차원에서 제공되는 데이터 플랫폼으로 적합한 방식은 아니다. 그래서 가장 많이 쓰이는 방식이 일반적인 “마이크로서비스” 방식의 서비스 제공 방식인 API를 통한 데이터 제공이다. 주요 데이터에 접근할 수 있는 API를 제공함으로써 이를 필요로 하는 사용자는 해당 API 호출을 통해 필요한 데이터를 받을 수 있도록 하는 것이다. 이 방식은 사용자 관점에서 매우 편리하면서도 플랫폼 서비스 제공자 관점에서는 API 사용 승인 권한을 통한 유연한 접근 제어가 가능하다는 것이 강점이다. 또한, API 호출 기록을 통해 데이터 입/반출 모니터링이 가능하다.

한편, API 호출에 의한 특정 데이터 접근 외에 “벌크(bulk)” 데이터 수요에 대한 대응도 필요하다. 파일 시스템 내에서 데이터 셋을 복사하거나 내려받을 수 있도록 하는 것이 이를 해결할 수 있는 유용한 방법이다. 개방된 표준 기술이나 서비스를 활용하는 것도 매우 효과적이다. 예를 들면 깃헙(Github)이나 깃랩(GitLab)과 같은 협업 도구를 사용하는 것이다. 만일 데이터를 생성하는 측과 소비하는 측 양측이 불특정 다수로 존재한다면, 이와 같은 표준 협업 도구를 활용하는 데이터 플랫폼 설계도 고려해볼 필요가 있다.

API를 활용하여 데이터에 접근할 수 있도록 하는 것이 일반적이나, 벌크(bulk) 다운로드도 고려한 데이터 인프라 설계가 필요하다. 이 경우 깃헙/깃랩과 같은 개방된 표준 기술을 활용하는 것이 바람직하다.

4. 정부 서비스 언번들링(Unbundling)

정부에서 제공되는 서비스는 매우 복잡하고 그 규모가 큰 경우가 많다. 이런 서비스도 자세히 분석해 보면 다양한 분야에서 공통으로 사용될 수 있는 기능들이 얼마든지 있을 수 있다. 정부 플랫폼이 더 많은 영역에서 활용되고 더 많은 시민이 참여하여 공공의 문제를 혁신적으로 해결하기 위해서는 가능한 많은 공통 기능들이 플랫폼 서비스로 제공되어야 한다. 앞서 플랫폼에 대한 이해 부분에서 공통 기능을 발견하는 것에 대해 언급했는데, 이를 위해 필요한 선제 조건이 서비스 언번들링이다.

언번들링은 단일 서비스에서 제공되는 다양한 기능을 해체하여 각기 다른 서비스 형태로 제공하는 것을 의미한다. 단일 서비스 내에서도 일부 기능의 특성상 서비스 요구사항이나 특성이 다를 경우 이를 각각 다른 더 작은 서비스로 나누어 서로 다른 환경에서 제공함으로 전반적인 성능 또는 서비스 효율을 높일 수 있다. 또한, 각각의 세부적인 기능을 전문적으로 다루는 기업이 서비스를 제공할 경우 더 나은 서비스로의 발전이 용이하다는 점도 서비스 언번들링이 주목을 받는 이유다. 마이크로서비스 아키텍처와도 물론 궁합이 잘 맞는다. 이러한 언번들링을 통해 세분화된 각 기능은 또 다른 서비스에서도 활용될 가능성이 크다. 즉 플랫폼 서비스가 될 주요 후보군이다. 정부 서비스 언번들링을 통해 플랫폼에서 제공되는 서비스를 확대해 나갈 수 있다.

5. 사일로 현상의 극복

각 정부 기관의 전문 업무 영역에 따라 제공할 수 있는 플랫폼 서비스도 각각 다르다. 업무 도메인에 부합하는 전문성을 갖춘 기관이 해당 분야의 서비스를 플랫폼으로 제공하는 것은 매우 타당하다. 하지만 여기서 절대 간과해서는 안 되는 것이 플랫폼 호환성 및 표준 준수이다. 서비스가 오래 지속되어 이 분야에서의 에코시스템이 점차 두터워 지면 질수록 각각 플랫폼이 독자 노선을 걷게 될 가능성이 높다. 이는 플랫폼으로서 정부가 지속 발전하는데 가장 큰 위협 요소이다.

이를 해결하는 데 가장 중요한 것은 정부 전체 플랫폼에 대한 거버넌스 체계를 유지하는 것이다. 앞서 전문성을 가진 리더십의 중요성을 언급한 바가 있다. 사일로 현상을 극복하기 위해서는 정부 플랫폼 전체를 관장하는 리더십 하에 각 기관의 플랫폼 거버넌스 체계가 들어와 있어야 한다. 이를 단순 조직 체계로 운영하는 것만으로는 부족하다. 거버넌스 체계를 지원하는 적극적인 도구 활용이 필요하다. 실시간 모니터링 도구, 대시보드 시스템, 협업 시스템, 성과지표 관리, 조달 현황 등이 하나의 시스템 아래에서 관리 운영될 수 있어야 한다. GaaP 구현 초기에 조직 설계와 함께 반드시 갖추어져야 할 도구다. 이런 도구를 효과적으로 활용할 수 있는 리더십이 필요하기에 “전문성”에 대한 중요성이 더욱 강조되는 것이다.

6. 플랫폼 확산

정부 주도 서비스에서 가장 취약한 부분이 서비스 운영과 확산이다. 일반 서비스와 마찬가지로 플랫폼 서비스도 출시된 다음부터 본격적인 게임이 시작된다. 정부 플랫폼 서비스 사용자는 이를 활용하여 일반 사용자 서비스를 만드는 사람들이다. 이들 커뮤니티를 최대한 활용하는 마케팅이 매우 중요함에도 불구하고 이를 위한 예산이나 자원 지원에 대해서는 소극적인 것이 정부 주도 프로젝트의 현실이다. 이런 고정관념부터 타파해야 한다. 예산 수립 시 개발 비용의 최소 서너 배 이상 향후 1년간의 마케팅 및 운영에 할당되어야 한다. 이는 서비스 운영에 수반되는 인프라 사용 및 관리 비용은 제외한 것이다. 사용자 커뮤니티 활동과 플랫폼 디버깅 및 개선을 위한 비용이 플랫폼 자체 개발 비용보다 훨씬 더 많이 필요하단 뜻이다.

플랫폼 확산을 위해 필요한 기술적 마중물도 소홀하게 생각하면 안 된다. 이는 사용자 커뮤니티 활동과도 직결되는 부분으로 플랫폼을 기반으로 한 초기 파일럿 프로젝트 지원도 여기 포함된다. 우리나라 정부에서는 이와 유사한 형태로 소위 “실증사업”이란 것을 하는데, 외부에 사업을 맡기기 전에 좀 더 주도적으로 플랫폼을 활용한 서비스를 직접 설계하여 이를 예시로 제공하는 것이 바람직하다. 이를 기술적 마중물이라 표현한 것이다.

위험에 대한 충분한 사전 대응도 플랫폼 확산을 위해 필요하다. 불특정 다수의 사용자가 더 많이 참여하면 할수록 예측 불가능한 위험요소가 늘어난다. 따라서 플랫폼이 안정화 되기 전 가능한 많은 위험요소를 찾아내고 이를 해결하기 위해서는 사용자들이 부담 없이 마음껏 다양한 서비스를 시도할 수 있는 “완충지대”가 필요할 수도 있다. 민간 서비스에서는 클로즈드 베타 또는 오픈 베타 서비스를 통해 이런 과정을 거친다. 마찬가지로 정부의 플랫폼 서비스에서도 이러한 “완충” 단계에 대한 계획이 수립되어 실행되어야 한다. 

7. 그 밖에 실행 전략 수립 시 고려해야 할 점

정부가 플랫폼을 제공하고 민간이 이를 기반으로 한 서비스를 완성한다는 것이 GaaP의 기본 정신이라고 해서 플랫폼 제품 책임자들이 서비스에 대한 고민을 접으라는 것은 절대 아니다. 플랫폼 제품 책임자는 각 부처의 플랫폼 담당자들이라고 볼 수도 있는데, 이들 역시 이 플랫폼을 활용한 서비스에 대한 고민을 항상 하고 있어야 한다. 그래야 플랫폼이 성장할 수 있다. 성장이 멈춘 플랫폼은 일반 서비스와 마찬가지로 죽은 플랫폼이다. 각 부처 일선의 플랫폼 담당자들은 플랫폼을 가지고 노는 커뮤니티와의 긴밀한 관계를 통해 플랫폼의 성장을 도모하여야 한다.

플랫폼의 성과를 측정하고 모니터링하는 계획을 플랫폼 설계 초기에 수립하여야 한다. 그래야 플랫폼이 의도하는 목적대로 개발되고 운영되는지를 확인할 수 있다. 만일 의도와 다르다면 서비스 초기 바로 폐기하는 것도 좋은 전략 중의 하나다.

플랫폼은 그 자체의 정체성(Identity)을 가지고 있다. 제공되는 서비스 도메인 관점에서의 정체성도 있지만 이를 구현하는 기술 관점에서의 정체성도 있다. 예를 들면 플랫폼 개발 시 어떤 기술 스택을 활용하였는가에 따른 정체성이다. 어떤 오픈 소스를 활용하였는가에 따라 그 계보가 정해지기도 한다. 이와 같은 기술 정체성이 중요한 이유는 새로운 서비스를 개발할 경우 여기서 활용하는 플랫폼에 따라 유용하게 활용될 수 있는 툴체인(Tool Chain)이 달라질 수도 있기 때문이다. 즉, 이 플랫폼을 활용하는 커뮤니티의 특성까지 영향을 줄 수 있는 부분이므로 설계 단계 혹은 개발 초기 단계에 관련 기술 스택에 대한 검토 과정을 포함시켜야 한다.

이 외에도 투명성 및 책임소재, 조직간 신뢰와 동의 등과 같은 문제도 중요하게 거론될 수 있다.

실행 전략을 구체화하는 KPI의 필요성

실행 전략을 구체적이면서 또한 효율적으로 정의하는 방법은 실행 성과를 정확하게 조망할 수 있는 KPI(Key Performance Indicator) 설정이다. 정량적 정성적 KPI 모두 실행 성과 분석에 쓰일 수 있다. 모든 실행 전략에 최소한 하나 이상의 KPI를 설정하는 것이 바람직하다. 플랫폼 서비스의 경우 목표 KPI는 비교적 단순하게 정의될 수 있다. 플랫폼을 사용하는 사용자가 이를 활용하여 서비스를 만들게 되는 것이므로 플랫폼을 활용하여 개발된 서비스 수 같은 것이 최종 목표에 부합하는 KPI라 할 수 있다. 좀 더 나아가 이렇게 개발된 서비스를 사용하는 최종 사용자 수가 될 수도 있고, 생태계 강화에 주안점을 둔다면 서비스를 통해 개발자들이 얻는 수익까지 KPI를 확대할 수 있다.

기술적인 관점에서는 개발된 플랫폼 성능에 대한 목표를 주요 KPI로 삼을 수도 있다. 지난 7월 백신 예약 대란을 해결하기 위해 민간 인증 플랫폼 서비스를 도입하면서, 각 인증 서비스 기업에는 단위 시간 처리할 수 있는 인증 횟수가 KPI로 주어졌다. 실행 전략을 점검하는 관점에서는 플랫폼 활용 횟수와 같은 최종적인 목표 KPI 외에 관리 KPI 수립이 필요하다. 예를 들면 플랫폼 서비스 포털의 등록 사용자 수 같은 것들이다. 이들이 궁극적으로 잠재적 플랫폼 사용자이므로 커뮤니티 강화를 위한 마케팅 활동 성과를 측정하는 지표로 등록 사용자 수는 매우 합리적이다. 마케팅 세부 계획도 여기에 맞게 진행될 것이다.

전체 정부 플랫폼을 아우르는 성과지표는 기관 간 사일로 현상을 줄이고 표준에 기반한 개방성 강화에도 도움이 될 수 있다. 예를 들어 정부 플랫폼 서비스 전체를 관장하는 GPO(Government Platform Officer)가 있고, 기관별 DPO(Department Platform Officer)가 있다고 가정해 보자. 이들의 KPI가 일관성 있게 유지된다면 각 기관의 목표가 정부 플랫폼 목표와 제대로 맞춰져(align) 있다는 뜻이다. 즉, 각 기관 사일로 현상도 최소화될 수 있음을 의미한다. 이런 상황에서 GPO는 효과적으로 범정부 플랫폼 로드맵을 가져갈 수 있다. 결과적으로, 성공적인 GaaP 실현에 더욱 가까이 다가갈 수 있다.

01) Donald Kettl, “The Next Government”, 2008 
  https://transition2008.wordpress.com/2008/11/25/the-next-government-donald-kettl/

02) O’reilly, “What Is Web 2.0 - Design Patterns and Business Models for the Next Generation of  Software”, Sep 30, 2005

03) Tim O’Reilly, “Government as a Platform,” Innovations, 6, no. 1, 2011

04) Harvard Kennedy School, “Playbook: Government as a Platform”, Nov 2019

05) Deloitte Uinversity Press, “The journey to government’s digital transformation”, 2015