[box type=”note”]
#. 플랫폼으로서의 정부
[/box]
[divide style=”2″]
플랫폼으로서의 정부(GaaP: Government as a Platform)가 국가 디지털 전략의 주요 화두가 되고 있다. 본 칼럼에서는 GaaP의 배경과 개념을 소개한 1편에 이어 성공적인 GaaP을 위한 기본적인 “가이드”를 소개하고자 한다.
이 얘기를 이어가기 전에 최근 발생한 사건을 우선 주목해 보자. 우리나라는 코로나 판데믹 한가운데에서 디지털 경쟁력을 바탕으로 위기를 극복해 나아가며 전 세계의 주목을 받았다. 이런 성과를 바탕으로 2021년 6월 영국에서 열린 G7 정상회담에도 초청되어 선진국으로서의 위상을 실감했다. 하지만 지난 7월, 50대 국민의 코로나 백신 예약 대란을 맞았다. 디지털 강국이니, 선진국이니 하는 수식어를 무색하게 하는 부끄러운 상황이 발생한 것이다. 도대체 무슨 일이 있었던 것인가?
시빅 해커: 백신 예약 대란의 시사점
백신 예약 사태를 해결하기 위해 긴급히 민간기업 및 관련 공기관이 참여하는 전담반(TF)이 구성되었다. 마침 나도 TF 책임자와 개선 과정에서 이야기를 나눌 기회가 주어져 문제점이 무엇인지 어느 정도 파악할 수 있었다. 여기서 자세한 과정을 얘기하려 하는 것은 아니다. 해결 과정에서의 핵심을 뽑자면 다음 두 가지다.
- 첫째, 민간 클라우드의 적극 활용
- 둘째, 서비스로서 사용자 경험에 관한 고민
부하가 몰리는 사용자 인증 서비스를 민간 클라우드 기업에 대부분 이양함으로써 이 과정에서의 병목현상을 제거했다. 그리고 실제 서비스를 사용하는 사용자 관점에서 어떻게 커뮤니케이션할 것인가, 즉 사용자 경험을 어떻게 개선할 것인가에 대한 많은 고민이 있었다. 그렇게 해서 나온 것이 인증 서비스 신호등이다. 최초 인증화면에 다양한 인증 서비스를 제공하고, 각 인증 서비스의 상태, 즉 부하를 신호등의 초록, 노랑, 빨강으로 구분하여 사용자가 선택하게 함으로써 자연스럽게 부하를 분산시킬 수 있도록 했다.
이 과정에서 민간기업이 담당하는 서비스 개발 전 과정이 공유되어 속도를 낼 수 있었다. 물론 중간중간 주요 마일스톤에서의 테스트도 적절히 이루어졌다. 서버 및 네트워크 증설도 이런 협업 기반하에 규모가 결정되어 짧은 시간에 서비스를 완성할 수 있었다.
민간기업의 적극적인 지원과 질병관리청 담당자들의 헌신적인 노력, 그리고 전체 TF 리더로서 거버넌스 체계를 잘 관리한 관계 기관의 노력으로 인해 전 국민 대상 백신 예약 서비스는 순조롭게 운영되고 있다. 사태 발단을 초래하게 된 배경, 그리고 해결 과정에서 드러난 이슈들은 한결같이 정부 서비스가 플랫폼으로서의 제 기능을 충분히 하지 못한 것으로 귀결된다.
왜 폭주하는 트래픽을 충분히 예상할 수 있었음에도 불구하고 이에 대한 사전 대응체계가 전혀 동작하지 않았을까? 아마도 질병관리청 내부에서는 당연히 트래픽 증가를 예측하고 나름 서버 증설 등 물리적인 준비는 했을 것으로 판단한다. 다만, 트래픽 증가를 포함하여 예측 가능한 최악의 시나리오에 대해 충분히 고려하지 못한 것이다.
한 예를 들면 정해진 예약 시간을 우회한 예약 시도로 인해 예약 대기열 시스템이 불능 상태에 빠진 것이다. 민간 서비스에서는 이런 예기치 못한 상황까지 고려하여 본격 서비스 전 알파·베타 서비스를 실시한다. 여기에 화이트 해커들을 활용하여 서비스(시스템) 취약점을 사전에 가능한 한 많이 발견하기 위한 과정이 서비스 출시 전 프로세스에 들어가 있다. 베타 서비스 운영은 차치하고라도, 시빅 화이트 해커들(참고-‘시빅 해킹’: 시민과의 협업으로 도시와 정부 시스템을 개선해 나가는 것. -편집자)을 동원한 취약점 분석만 있었어도 지난 최악의 대란은 막을 수 있었을 것이다.
질병관리청이 보관하고 있는 데이터가 매우 민감한 개인정보이고, 이를 안전하게 유지하는 것은 무엇보다 중요하다. 질병관리청 서비스는 ‘아마도’ 이러한 점을 고려하여 다중 보안 레벨이 적용된 아키텍처로 만들어져 있을 것이다. 이 구조를 개방하고, 더 나아가 소스 코드까지 공개하였다면 우리의 뛰어난 시빅 해커들이 집단지성의 힘을 발휘하여 더 많은 잠재된 문제점들을 발견하고 해결책까지 제시할 수 있었을 것이다.
소스 코드 공개를 마치 보안을 해제하는 것으로 착각하는 사람들이 있다. 소스 코드를 통해 취약점 분석을 할 수 있는 수준이라면, 진정한 해커들은 소스 코드가 없어도 얼마든지 보안에 위협을 가할 수 있다. 데이터 보안의 가장 기본인 암호화를 위해 흔히 사용하는 MD5나 SHA256 해싱 같은 것도 오픈소스를 가지고 얼마든지 분석할 수 있지만, 그렇다고 해싱 값으로 원 데이터를 유추하는 것은 여전히 불가능하다. 플랫폼으로서의 역할을 제대로 하기 위해 가장 중요한 덕목은 개방이다.
이번 개편된 백신 예약 서비스에서 눈에 뜨이는 것이 본인 인증 서비스이다. 네이버, 카카오, 이동통신사 등 대기업 인증서를 포함한 다양한 본인 인증 서비스를 사용자가 선택하게 한 것이다. 본인 인증에서부터 답답하게 막혀 있던 이전 예약 대란 때의 경험을 해결하고자 다양한 인증 방식이 도입되었다. 각각 인증 서비스 운영사에도 예상되는 트래픽을 충분히 감당할 수 있도록 대응을 요청했다고 한다. 이들 대기업은 이미 클라우드 기반으로 인증 플랫폼을 운영하고 있었기 때문에 그리 어려운 대응이 아니다.
이러한 인증 서비스는 이미 플랫폼 서비스로 일반에 제공되고 있다. 최근 시장에 출시되는 많은 서비스는 이러한 인증 플랫폼을 활용하고 있다. 본인 인증뿐만 아니라 ‘소셜 로그인’ 형태로 아예 사용자 계정관리의 핵심 기능을 대신하기도 한다. 만일, 질병관리청이 내부에서 관리하는 백신 접종 정보에 접근할 수 있는 안전한 통로를 API(Application Programming Interface) 형태로 제공했다면, 그리고 이를 개방하였다면 민간 개발자들이 이미 플랫폼으로 제공되는 다양한 인증 방식을 활용하여 훨씬 유연하고 사용성이 높은 백신 예약 서비스가 제공될 수 있었을 것이다. 상상하지 못하는 혁신적인 기능이 도입되었을 수도 있다.
공공서비스가 플랫폼으로서 역할을 제대로 한다면 백신 예약 대란이 발생하였다고 하더라도 시빅 해커들이 팔을 걷어붙이고 힘을 모아 문제를 더 빨리 해결했을 것이다. 작년 마스크 대란 때 시빅 해커들의 집단지성을 모아 해결한 것을 잊지 말아야 한다. 건강보험관리 공단의 시스템을 일부 개방하고 마스크 수급과 관련된 정보를 모아 공유할 수 있도록 한 정부의 플랫폼으로서의 역할이 빛을 발한 것이다.
공공문제 해결을 위해 집단지성의 힘을 활용한 2020년도의 마스크 앱 같은 훌륭한 예가 있음에도 불구하고 백신 예약 대란을 예방하지 못한 것은 무척 아쉬운 일이다.
팀 오라일리(Tim O’reilly)는 웹2.0에서 비롯된 Gov2.0(Government 2.0)에서는 도시·국가 문제 해결에 집단지성을 활용하는 것이 일상화되고 이를 위해서 정부는 ‘이네이블러’로서의 역할이 중요하다고 강조했다. 시민이 세금을 내면 정부는 서비스를 제공한다는 개념의 ‘자판기 정부’(Vending Machine Government)가 아닌, 플랫폼으로서의 정부(GaaP) 역할을 충실히 함으로써 정부가 직접 만들지 못할 혁신적인 서비스를 시민이 누리게 하고, 또한 백신 예약 대란 같은 예기치 못한 상황이 닥쳤을 때 정부가 제공하는 플랫폼을 활용하여 민간 개발자(또는 시빅 해커)가 직접 해결하도록 하는 것이 GaaP이 추구하는 비전이다.
성공적인 GaaP을 위한 가이드
팀 오라일리는 성공적인 “컴퓨터 플랫폼” 경험을 통해 얻은 교훈을 나열함으로써 GaaP이 지향해야 할 바를 간접적으로 제시하였다. 이는 필자의 지난 칼럼에서 소상히 소개한 바 있다. 팀 오라일리는 이러한 레슨에 기반한 GaaP 실행단계에 고려하여야 할 사항들 또한 제시하였다. 2010년 웹2.0 또는 Gov2.0이 주목을 받던 시기에 논의된 것이지만, 지금도 대부분 유효하다고 판단된다.
디지털 관련 정책을 수립하는 위치에 있다면 과연 우리 기관은 어떤 단계까지 와 있는지 비교하며 검토해 보는 것도 유의미하다. 팀 오라일리가 제시한 내용을 기초로 내 의견을 더하여 GaaP을 위한 실행 가이드를 다음과 같이 여섯 가지로 정리해 보았다.
1. 개방과 공유를 위한 실행 지침을 만든다
정부 기관이라면 당연히 “정부지침”이 될 것이다. 중앙정부가 될 수 있고 지방자치 정부도 될 수 있으며, 사실상 모든 공공업무를 수행하는 기관이 주체가 될 수 있다. 팀 오라일리는 2010년 당시 샌프란시코 시장이었던 개빈 뉴섬(Gavin Newsom: 2021년 현재 캘리포니아 주지사)이 만들었던 오픈 데이터 실행 지침(Open Data Executive Directive)을 모델로 예를 들었다. 이는 오바마 정부에서 정부 데이터는 기계가 해독할 수 있는 상태로 개방해야 한다는 실행 명령의 기초가 되었다.
우리나라는 공공데이터전략위원회라는 기구를 두어 관련 지침 및 시행령 등을 제정하고 있다. 이에 대해서는 추후 좀 더 자세히 살펴보도록 하겠다. 이러한 지침을 만드는 데에는 기본 원칙과 철학이 필요하다.
2. 데이터를 기반으로 한 서비스 중심의 구조를 지향한다
데이터를 개방함으로써 이를 기반으로 한 다양한 서비스를 활성화할 수 있도록 해야 한다. 즉, 데이터와 이를 활용하는 서비스를 분리함으로써 다양하고 혁신적인 서비스가 데이터 기반(data-driven)으로 나올 수 있다는 뜻이다. 로빈슨 등이 오바마 정부 출범 당시 발표한 논문에서는 인터넷 시대의 정부의 투명성을 강조하며 정부는 데이터를 투명하게 공개하고 일반 시민은 민간이 만드는 서비스를 통해 이 데이터에 접근할 수 있도록 하는 것이 바람직하다고 주장했다.
이를 기술적으로 풀어 표현하면 데이터와 이를 활용하는 상호작용(interaction)을 분리하는 것이다. 여기서 말하는 “상호작용”이란 매우 광범위한데, 단순히 데이터를 열람하는 것뿐만 아니라, 데이터를 소비하기 위한 모든 방식을 포함한다. 예를 들어 초기 야후 서비스처럼 디렉토리 기반으로 필요한 데이터를 찾을 수도 있고, 구글처럼 검색을 통해 직접 찾을 수도 있으며, 최근에는 인공지능의 발전으로 사용자가 필요한 데이터를 알아서 제시할 수도 있다.
이 밖에도 서비스 카테고리에 따라 다양한 방식의 데이터 접근이 가능한데, 이를 위해서는 데이터만 따로 “잘” 제공하는 것이 정부가 할 일이란 것이다. 이를 더욱 명확히 전달하기 위해 이 논문의 핵심 문장을 그대로 옮겨와 보았다.
“각 ‘엔드 유저'(시민, 이용자)의 필요를 충족하기 위해 현재처럼 분투하기보다는 기본 데이터를 “노출”(개방)하고, 이를 안정적이고 공개적으로 접근할 수 있는 인프라를 구축하는데 중점을 둬야 합니다. 영리나 비영리를 떠나 민간 행위자는 정부 정보를 시민에게 제공하고, 개인이 공공 정보를 찾고 활용하는 데 사용하는 도구를 지속적으로 만들고 재구성하는데 (정부보다) 더 적합합니다.”
“Rather than struggling as it currently does to design sites that meet each end-user need, it should focus on creating a simple, reliable and publicly accessible infrastructure that “exposes” the underlying data. Private actors, either nonprofit or commercial, are better suited to deliver government information to citizens and can constantly create and reshape the tools individuals use to find and leverage public data.”
데이터의 개방은 점진적으로 이루어지는 것이 자연스럽다. 개별 팀, 산하기관, 기초단체, 광역단체, 중앙부처 등 모두에서 기본 원칙을 반영한 지침에 따라 데이터 개방이 이루어져, 결국 정부 전체를 아우르는 데이터와 이를 활용할 수 있는 인프라가 갖춰진다. 우리나라나 미국의 공동데이터포털이 이런 방식으로 구축되어 운영되고 있다. 그러나 과연 기본 원칙이 제대로 지켜지고 있는지는 다시 한번 돌아볼 필요가 있다.
3. 정부 데이터 개방의 기본 원칙을 숙지한다
정부 데이터를 개방하면서 고려해야 할 기본 원칙이 매우 중요하다. 2007년 12월 캘리포니아의 작은 도시 세바스토폴(Sebastopol)에 정부 데이터 개방을 주장하는 30인이 모여 만들었다는 정부 데이터 개방의 8가지 원칙과 이후 추가된 원칙을 살펴보자.
우선 처음 제시되었던 8가지 원칙이다.
- 완전한(Completeness): 모든 공공데이터가 개방되어야 한다. 만일 디지털화 되어있지 않은 공공데이터라면 가능한 이를 디지털화하여 공개하여야 한다. 여기서 “공공데이터”라고 함은 프라이버시 침해, 또는 특별히 접근 제한이 필요한 보안데이터 등을 제외한 모든 데이터를 말한다.
- 원본의(Primary): 가능한 원 소스로부터 확보한 데이터이어야 하며 파편화되지도 않고 수정되지 않은 데이터이어야 한다.
- 즉시(Timely): 데이터의 가치가 극대화될 수 있도록 생성 즉시 공개되어야 한다.
- 접근 가능한(Accesible): 가능한 많은 사람이 다양한 용도로 활용할 수 있도록 인터넷을 통해 접근 가능해야 한다.
- 기계처리 가능한(Machine Processable): 일정 수준의 구조화된 데이터로 공개되어 자동으로 이를 처리할 수 있어야 한다.
- 차별적이지 않은(Non-discriminatory): 별도의 등록 과정을 거치지 않아도 누구나 데이터를 활용할 수 있어야 한다. 또한, 익명으로 데이터 접근이 가능해야 하며 찾을 수 없는 곳에 숨겨 놓아서는 안된다.
- 특정 포맷은 지양하는(Non-proprietary): 특정 그룹만 알 수 있는 포맷으로 구성되어 결과적으로 데이터를 제대로 활용할 수 없도록 하는 일은 없어야 한다. 만일 누군가 소유권을 주장할 수 있는 포맷이라면, 설사 이 포맷이 널리 알려져 다른 사용자들이 얼마든지 활용할 수 있다고 하더라도 이런 방식은 지양해야 한다는 뜻이다. 그런 의미에서 우리나라 정부에 만연해 있는 “hwp” 사용을 금지하기 위한 심각한 논의가 필요하다.
- 라이선스 없는(License-free): 저작권이나 특허 혹은 상표권, 영업 비밀 등 공공데이터로 공개되어서는 곤란한 것들은 최소한으로 잘 걸러내어야 한다. 데이터 생성 시점부터 공공 도메인임을 명시하여 안심하고 자유롭게 활용하는 것이 바람직하다.
발표 당시 논의에서 빠졌거나 혹은 좀 더 부연 설명이 필요한 것, 그리고 시대가 지나며 추가된 7가지의 정부 데이터 개방 원칙은 다음과 같다.
- 온라인에서 무료로 제공되는(Online & Free): 인터넷에서 무료로 제공되어야 한다. 만일 데이터를 재생산하는데 드는 어쩔 수 없는 비용이 있다면 최소화하여야 한다.
- 영속적인(Permanent): 인터넷상의 안정적인 사이트에서 가능한 한 오랫동안 제공되어야 한다.
- 신뢰할 수 있는(Trusted): 8가지 원칙 중 원본 또는 원본에 가까운 데이터를 보완하는 의미로, 공개된 데이터가 신뢰할 수 있어야 함을 의미한다. 디지털 서명 등을 활용하여 변조되지 않은 데이터임을 증명할 수 있어야 한다. 다만, 이는 원본 데이터에 해당하는 것이며, 이를 활용하는 경우 서비스에 맞게 수정은 가능하다. 다만, 이는 원본 데이터가 아님을 분명히 밝혀야 할 것이다.
- 개방을 기본으로(A Presumption of Openness): 공공데이터를 개방한다는데 개방을 또 기본으로 한다는 말이 다소 혼란스러울 수 있다. 이는 개방을 더욱 강조하기 위한 것으로, 모든 공공데이터가 기본적으로(by default) 개방되어야 함을 다시 한번 강조한 것이다. 이는 생성되는 데이터에 대해 공공데이터로 개방하지 못한다면 그 이유에 대해 매우 까다롭게 따져야 한다는 뜻이며, 또한 명확하게 이렇게 “따지는” 절차를 반영해야 한다는 의미이다.
- 문서화된(Documented): 데이터를 공개하며 이 데이터의 의미 포맷 등 데이터 활용을 위해 필요한 “충분한” 정보를 문서화 하여 제공해야 한다.
- 안전한(Safe to Open): 안전하게 문서를 오픈할 수 있어야 한다. 좀 더 구체적으로는, 이러한 문서에 “실행 가능한” 부분이 절대 없어야 한다는 뜻으로, 스크립트나 특정 플랫폼에서의 실행 파일 같은 것이 포함되어있지 않아야 한다. 이런 실행 가능한 데이터는 위/변조 시 매우 심각한 보안 위협을 초래할 수 있다.
- 일반 대중의 의견을 청취하는(Designed with Public Input): 공공데이터가 필요한 일반 대중이야말로 무엇이 필요한지 가장 잘 알고 있다. 따라서 늘 대중의 목소리에 기울이며 공공데이터를 설계하여야 한다.
4. 자체적으로 무언가를 개발할 경우 개방성과 공유를 우선해야 한다
정부에서 직접 개발하는 웹사이트 혹은 애플리케이션이 있다면, 이는 공개된 데이터와 마찬가지로 개방된 시스템을 활용하는 것을 우선 고려해야 한다. 정부는 데이터를 개방하고 이를 기반으로 한 애플리케이션은 민간이 주도한다는 것이 GaaP이 추구하는 궁극적인 목표이지만, 정부에서 직접 개발을 주도하여 공공데이터 및 정부 제공 서비스를 더 잘 활용할 수 있도록 할 필요도 있다. 이때 개발하는 시스템도 가능한 개방된 시스템을 활용해야 한다는 것인데, 오픈소스와 퍼블릭 클라우드 활용이 이에 해당한다. GaaP 관점에서는 공공 PaaS(Platform as a Service) 개발 시 특히 중점적으로 고려해야 할 부분이다.
오픈소스를 최대한 활용하여 개발하고, 무엇보다도 새로이 개발된 서비스 활용을 위한 인터페이스 즉 API(Application Programming Interface) 설계를 제대로 해야 한다. 공공데이터는 있는 그대로 개방하여 누구나 활용할 수 있도록 하는 것이 기본이지만, 공공데이터에 좀 더 쉽고 안전하게 접근할 수 있도록 API를 제공하는 것도 함께 고려하여야 한다. 이를 통해 개발자 커뮤니티가 활성화될 수 있으며 나아가 생태계 확산에 이를 수 있다.
웹사이트 구축에도 이러한 개방성이 적용되어야 한다. 웹 표준을 준수하여 기기에 따른 불편을 최소화하고, 가능한 많은 정보를 기기 내에서 소비할 수 있도록 설계해야 한다. 정부 문서 열람 시 스마트폰에서도 충분히 내용을 파악할 수 있도록 인쇄용 포맷의 문서뿐만 아니라 텍스트나 표준 웹 문서가 함께 제공될 수 있도록 하는 것을 예로 들 수 있다.
또한, 무엇보다 중요하며 정부 기관에서 가장 취약한 부분인 “라이프사이클” 운영이다. PaaS든 웹사이트 든 만들어 놓는 것보다 이를 안정적으로 운영하는 것이 더욱 중요하다. 구축보다는 더 많은 예산을 운영에 투입해야 한다. 만일 민간이 운영할 수 있다면 그렇게 하는 것이 더 바람직할 수 있다. 데이터도 변하고, 요구사항도 매우 빠르게 변화하는데 이에 대한 대응을 시의적절하게 하지 못한다면 죽은 서비스나 마찬가지이다. 기획, 구축, 운영 이 세 중요한 단계에 대해 구체적인 작업명세와 이에 따른 예산 및 인력 배정이 확실하게 이루어져야 한다.
5. 앱스토어를 중심으로 한 생태계를 구축해야 한다
정부에서 개발한 서비스 및 애플리케이션 스토어를 구축 운영해야 한다. 당연히 민간에서 개발한 서비스도 이 스토어에서 제공되어야 한다. 현재, 영국이나 우리나라에서도 디지털 서비스 마켓플레이스라는 것이 제공되고 있다. 문제는 공공기관에서 이를 적극적으로 활용해야 한다는 것이다. 우리나라의 클라우드컴퓨팅 발전 기본계획에도 디지털 서비스 마켓플레이스가 꽤 중요한 비중을 차지하고 있다. 이제 각 공공기관에서는 이를 어떻게 더욱 적극적으로 활용할 것인지 고민하여야 하며, 이 결과가 기관의 평가에도 반영되어야 할 것이다.
6. 알리고 자랑하고 물어봐야 한다
내가 속한 기관 혹은 지자체, 부처에서 하는 일에 대해서는 늘 공개하고, 특히 잘한 일들은 적극적으로 알려 자랑하는 것이 일하는 방식에 녹아 있어야 한다. 우선 연관 부서나 인접 지자체가 될 수도 있고, 더 작게는 부서 내 다른 동료일 수도 있다. 더 나아가서는 정부 기관이 아닌 민간까지 확대해야 한다. 여기서 “알린다”라는 것은 홍보를 말하는 것이 아니다. 가장 확실하게 알리고 공유하는 방식은 개발 결과를 오픈소스로 공개하는 것이다. 다른 기관과 공통 클라우드 플랫폼을 구축하여 활용하는 것도 한 방법이다.
한편, 도움이 필요한 경우는 항상 커뮤니티를 통해 답을 구하는 자세가 필요하다. 이를 위해서는 물론 내 일을 공유하는 것이 선제조건이다. 관련 부서나 지자체, 오픈소스 커뮤니티 등 적극적으로 문제 해결 방안을 찾는 것에 절대 주저하지 말자. 코드 포 코리아(Code for Korea)와 같은 시빅 해커 커뮤니티를 적극적으로 활용하는 것도 좋은 방법이다.
공공기관에서 일하는 사람들이 소셜미디어를 적극적으로 활용할 수 있는 환경이 필요하다. 각자 전문 분야에서의 커뮤니티 활동을 통해, 자연스럽게 민간에서 필요로 하는 요구사항을 파악할 수 있으며, 반대로 공공부문에서 풀어야 할 숙제를 함께 해결할 수도 있다. 온라인 커뮤니티 활동의 연장선으로 밋업, 해커톤, 부트캠프와 같은 활동들에 대한 지원을 강화할 필요가 있다.
공공기관에서 절대적으로 부족한 활동이 “데브렐(DevRel: 개발자를 대상으로 하는 소통과 홍보 활동)”이다. 대부분 민간기업이 DevRel(Developer Relation) 활동을 운영을 위해 전담 부서를 두고 있는 것에 비하면, 정부 기관은 이런 활동이 매우 취약하다. 성공적인 GaaP을 위해선 공격적인 DevRel 활동이 필요하다. 특히 공공데이터를 운영하는 기관이라면 반드시 갖추어야 할 기능이다.
정리하면
이런 가이드가 아무리 잘 갖추어져 있다고 하더라도 이를 구현할 수 있는 장치가 제대로 갖추어져 있지 않다면 아무 의미가 없다. 위와 같이 정리된 내용을 기반으로 각 기관의 관련 프로세스에 상세하게 녹여 넣는 것이 관건이다. 각각에 관해 구체화하여 실무에서 활용할 수 있는 명확한 명세서를 만드는 것도 한 방법이다. 명세서를 상황별로 분류하여 특정 상황에서는 반드시 참조하여 확인된 결과를 첨부하도록 하는 방식도 가능하다.
특히 위 3번 데이터 개방 원칙은 이런 식으로 정리하여 바로 실무에 적용할 수 있을 것으로 보인다. 그러나 너무 세부적인 요건에 치중하다 보면 GaaP이 지켜야 할 기본 원칙과 멀어질 가능성도 있다. 늘 두 질문을 끊임없이 반복함으로써 GaaP을 지향하는 원칙에 충실할 수 있도록 해야 한다.
[divide style=”2″]
데이터를 공개할 수 없는 이유가 무엇입니까?
왜 지금 개발해야 합니까?
[divide style=”2″]
이 글에서 소개한 기본 가이드만으로도 GaaP 구현을 위한 중요한 실행 방안이 도출될 수 있다고 생각한다. 하지만 더 성공적인 GaaP을 위해서는 세부적으로 고려하여야 할 사항들이 꽤 많다. 하버드 케네디 스쿨에서 2019년에 발간한 책자에서는 GaaP 구현을 위해 필요한 사항을 비교적 상세하게 제시하고 있다.
여기에는 사용자에 대한 이해부터 플랫폼 선택, 디자인, 부처 간 조율, 자본조달 및 운영, 거버넌스 등 공공기관 관점에서의 운영에 필요한 제반 사항들을 언급하고 있다. 이에 관해서는 다음에 사례와 함께 정리하여 소개해 보겠다.
[divide style=”2″]
[box type=”note”]
본 글은 한국지능정보사회진흥원의 지원을 받아 작성되었으며, 디지털서비스 이용지원시스템에 동시 게재합니다.
[/box]
