2025. 8. 17. 20:04ㆍ서비스디자인/정책디자인
이 영상은 국제 공공부문디자인 커뮤니티(International Design in Government community)가 주최한 헬싱키 컨퍼런스 2024에서 소개된 발표이다. 카탈루냐 정부는 지난 20여 년간 행정절차를 온라인화했지만, 사용자 중심성이 부족해 시민들이 불편을 겪었다. 2018년부터 서비스디자인과 디자인씽킹을 도입해 시범사업을 거쳐 현재는 주요 절차를 재디자인하는 대규모 전환을 진행 중이다. 궁극적으로 2026년까지 핵심 절차 대부분을 재디자인하여 시민들이 정부 서비스를 더 쉽게 이용하도록 하고, 공무원의 업무방식 자체를 변화시키는 것을 목표로 한다.
정부 서비스의 체계적 전환: 카탈루냐 사례 연구
연사 : 호셉 마리아 플로레스 후안페레 Josep Maria Flores Juanpere 카탈루냐 정부 디지털행정국 혁신 책임자
2024.12.18.
영상 출처 : https://youtu.be/zc000_vh4Mo?si=tOVAHVIML7G9VB2x
번역 : 챗GPT (요약, 생략된 부분이 있을 수 있습니다. 원본을 확인해주세요.)
호셉 마리아 플로레스 후안페레 Josep Maria Flores Juanpere
안녕하세요. 오늘 이 자리에 함께해 주셔서 정말 감사합니다. 짧게 저희의 맥락을 먼저 소개해드리겠습니다.
우주가 있고, 지구가 있습니다. 지구 안에 유럽이 있고, 남유럽에 빨간 삼각형 모양으로 표시된 곳이 있습니다. 바로 카탈루냐입니다. 카탈루냐에는 바르셀로나라는 주요 도시가 있습니다. 이 지역에는 약 800만 명의 카탈루냐 주민, 즉 800만 명의 인구가 살고 있으며, 이들을 담당하는 정부가 있습니다. 바로 카탈루냐 정부입니다. 카탈루냐 정부에는 약 20만 명의 공무원이 있으며, 이들은 16개 부처에 나뉘어 있습니다. 이 16개 부처 중 하나가 대통령부입니다. 대통령부는 전체 부처를 조정하는 임무를 가지고 있습니다.
이 대통령부 안에는 전자정부, 디지털 정부를 담당하는 중앙 단위가 있습니다. 제가 근무하는 곳이며, 이 자리에 있는 제 동료 카르마도 같은 부서에서 일합니다. 저희 부서의 역할은 모든 부처 내 단위들이 디지털 정부와 관련된 일을 할 수 있도록 디지털 플랫폼, 도구, 지원, 가이드를 제공하는 것입니다.
오늘 저는 저희 정부에서 사용자 중심 디자인의 역사를 어떻게 만들어왔는지를 말씀드리고자 합니다. 하지만 모든 역사에는 선사(前史)가 있듯, 저희의 경우에도 그러했습니다.
과거에는 시민이 정부에 요구하는 모든 행정 절차가 종이 기반으로 이루어졌습니다. 정부 사무소, 혹은 ‘정부의 동굴’이라고 부를 만한 곳에 가서 어떤 서류를 어떻게 작성해야 하는지조차 알 수 없었지만, 공무원이 “여기에 이름을 쓰세요, 여기에 서명하세요”라고 알려주며 도움을 주었습니다.
그러다 약 20년 혹은 15년 전쯤 카탈루냐와 스페인 전역에서는 ‘대규모 디지털화 정책’이 추진되었습니다. 이 정책은 모든 행정 절차를 온라인으로 전환하여, 시민이 집에서도 할 수 있도록 하자는 것이었습니다.
그래서 지난 15~20년 동안 저희는 행정 절차를 온라인으로 옮기는 작업을 해왔습니다. 그 결과 현재 약 2,000개의 절차가 디지털화되었습니다. 하지만 이것은 ‘사용자 중심적’이지 않았습니다.
왜냐하면 저희가 한 일은 단순히 번거로운 종이 양식을 온라인에 옮겨놓은 것에 불과했기 때문입니다. 시민은 집에서 이 온라인 절차를 접했지만, 도대체 이 관료적 용어가 무슨 뜻인지, 이 칸이 나에게 해당되는지 아닌지 알 수 없었고, 컴퓨터 문제도 많았습니다. 결과적으로 이러한 디지털 절차들은 이용률이 낮았습니다. 일부 경우에는 사람들이 여전히 정부 사무소를 직접 찾아야 했습니다.
은행 업무나 쇼핑과 같은 다른 생활 영역에서는 온라인 서비스가 잘 작동했지만, 정부 절차만큼은 그렇지 않았습니다. 더 나아가 기업의 경우에는 온라인 절차가 의무화되어 있어서, 결국 대리인에게 돈을 주고 대신 처리하도록 맡겨야 하는 상황도 있었습니다.
이러한 상황 속에서 저희 부처는 ‘사용자 중심 디자인’으로의 전환을 시작하게 되었습니다. 마치 ‘쉽고 편리한 서비스의 천국으로 가는 길’을 걷기 시작한 것입니다.
2018년에 저희는 ‘디자인씽킹’을 발견했습니다. 사실 디자인씽킹은 이미 다른 나라에서 오래전부터 쓰이고 있던 방법론이었습니다. 이를 미국 대륙 발견에 비유하자면, 아메리카 대륙은 원래부터 존재했고, 이미 아메리카 원주민과 바이킹이 알고 있었지만, 1492년에 ‘발견되었다’고 표현한 것과 비슷합니다. 카탈루냐 정부 안에서 디자인씽킹을 ‘발견한’ 것은 바로 저희 부서였습니다. 그리고 저희 부서는 규모를 확대할 수 있는 특별한 위치에 있었기 때문에 이것을 확산시킬 수 있었습니다.
2018년에 ‘아메리카 대륙’을 발견한 후, 저희는 본격적으로 체계를 마련하기 시작했습니다. 2020년에는 두 개의 시범사업을 운영했고, 성공적으로 작동했습니다. 2021년부터 올해까지는 약 25개의 프로젝트를 수요에 따라 운영했습니다. 그리고 현재는 또 다른 단계로 나아가고 있습니다. 전 부처의 200여 개 서비스와 절차를 대규모로 전환하고 있는 것입니다. 그리고 2027년에 이르면, 그 결과가 어떻게 될지는 아직 모르겠지만, 이후의 일이 될 것입니다.
따라서 오늘 발표의 내용은 크게 네 가지 단계로 나눌 수 있습니다.
첫째, 서비스를 어떻게 리디자인할 수 있는지, 즉 저희의 서비스 리디자인 방식.
둘째, 몇몇 서비스를 어떻게 리디자인했는지 사례.
셋째, 지금처럼 수많은 서비스를 어떻게 리디자인하고 있는지.
마지막으로, 모든 서비스를 다 리디자인한다면 어떻게 할 것인가입니다. 다만 이 마지막 단계는 저희의 범위를 넘어서는 것이고, 저희도 방법을 모릅니다. 하지만 이번 컨퍼런스 다음 세션에서 호주 국세청이 ‘디자인 성숙도’에 대해 발표할 예정인데, 그들은 이미 그 단계에 도달했으니 참고하시면 좋을 것 같습니다.
그럼 시작하겠습니다.
이제 ‘서비스를 어떻게 리디자인할 수 있는가’에 대해 말씀드리겠습니다. 저희의 경우, 서비스를 리디자인하고자 했던 이유는 디자인씽킹이라는 빛을 보았기 때문입니다. 그러나 서비스를 리디자인하려고 할 때 가장 먼저 필요한 것이 있습니다.
바로 ‘아이디어’, ‘사람’, 그리고 또 하나가 필요합니다. 바로 ‘서비스 자체’입니다. 리디자인되기를 원하는 서비스가 있어야 합니다.
그런데 이것이 문제였습니다. 왜냐하면, 어떤 부서나 절차 담당 단위가 굳이 자신들의 서비스를, 그것도 전혀 경험 없는 사람들이 낯선 방법론을 들고 와서 리디자인하자고 했을 때, 왜 기꺼이 동의하겠습니까? 여기에는 ‘신뢰’라는 문제가 있었습니다. 또한 누가 그 일을 하느냐는 문제도 있었습니다. 저희 스스로도 디자인씽킹을 실제로 적용해본 적이 없었기 때문에, 왜 자신들의 서비스를 저희에게 맡겨야 하느냐는 의문이 있었던 것입니다. 또 다른 장애 요인은, 이미 말씀드렸듯이, 각 부처가 자신의 서비스를 운영하느라 너무 바빠서 리디자인할 시간을 내기 어렵다는 점이었습니다. 그래서 이러한 장애 요인을 해결해야 했습니다.
첫 번째로, 신뢰의 부족 문제를 해결할 필요가 있었습니다. 다행히도 저희 부서는 부처들 입장에서 ‘낯선 존재’가 아니었습니다. 저희는 장기적인 파트너로서 각 부처와 늘 협력해왔습니다. 부처들은 디지털 플랫폼과 관련된 지원을 요청할 때마다 저희에게 와서 도움을 받았기 때문에, 저희 조직을 신뢰했고, 심지어 저희 팀원 개인을 신뢰했습니다. 그래서 저희가 새로운 방법론을 들고 갔을 때, 방법론 자체는 믿지 않았지만, 저희를 믿고 시도해볼 수 있었습니다. 이것이 제가 앞서 말씀드린 ‘확산할 수 있는 위치’라는 점입니다.
두 번째로, 자원의 문제였습니다. 설령 저희를 신뢰한다 하더라도, 부처는 자신들이 잘 알지도 못하는 방법론에 예산을 지불하지는 않았을 것입니다. 그래서 저희는 자원을 직접 투입해야 했습니다. 팀은 저희가 구성했고, 시간도 저희가 투입했습니다. 이것은 마치 슈퍼마켓에서 신제품을 시식해보는 것과 같습니다. 먼저 ‘무료 샘플’을 제공해야 사람들이 관심을 가지고 이후에는 구매를 결정합니다. 저희도 마찬가지로, 먼저 무료 샘플처럼 파일럿 프로젝트를 제공해야 부처들이 방법론의 가치를 체감하고 이후 더 큰 프로젝트를 원하게 될 것이라 생각했습니다.
세 번째로, 개발 약속을 제시했습니다. 저희가 정부 차원의 공통 플랫폼을 관리하고 있었기 때문에, 리디자인 과정에서 해당 플랫폼에 새로운 기능이 필요하다면 저희가 직접 그 개발을 책임지고 실행하겠다고 약속했습니다. 이 약속 덕분에 부처들은 더욱 적극적으로 협력하게 되었습니다.
다음은 ‘사람’의 문제입니다. 디자인을 하려면 디자이너가 필요합니다. 하지만 저희 부서는 그전까지 디자인씽킹을 해본 적이 없었습니다. 따라서 가장 쉬운 선택지는 외부 전문가, 즉 컨설팅 회사에 의뢰하는 것이었습니다. 이들은 경험도 있고 숙련된 인력도 있었기 때문에 즉시 투입할 수 있었습니다.
그러나 외부 디자이너만으로는 위험이 있었습니다. 그들은 부처 내부의 언어, 즉 관료적 용어를 이해하지 못했고, 누가 실질적인 권한을 가진 사람인지 알지 못했습니다. 또한 외부 디자이너는 복도에서 우연히 마주쳐 대화하거나 비공식적으로 상황을 파악하는 등 내부자만이 할 수 있는 활동을 할 수 없었습니다. 결국 외부 디자이너만으로 프로젝트를 진행하면 부처는 “내가 설명해도 저 사람들은 이해하지 못한다”는 생각을 하게 되고, 속도는 더 느려졌을 것입니다.
그래서 저희의 해결책은 혼합 디자이너 팀을 구성하는 것이었습니다. 여기 사진을 보시면, 이 작은 사람이 저이고, 옆의 큰 사람이 제 동료 카르마입니다. 실제로 그녀가 저보다 훨씬 큽니다. 그리고 여기 있는 사람들이 내부 팀, 즉 공무원 디자이너이고, 여기에 있는 사람들이 외부 컨설팅 회사 디자이너들입니다.
2020년에는 한 컨설팅 회사, 2021년에는 또 다른 컨설팅 회사와 함께했습니다. 하지만 저희의 목표는 단순히 외부 인력에 의존하는 것이 아니라, 그들의 지식을 내부화하는 것이었습니다. 첫해에는 외부 전문가 3명에게서 많은 것을 배웠고, 두 번째 해에도 또 다른 전문가들로부터 배웠습니다. 덕분에 이후 2년 동안은 외부 도움 없이도 스스로 프로젝트를 수행할 수 있었습니다.
올해에는 다시 외부와 큰 계약을 맺었습니다. 지금은 대규모 확산 단계에 있기 때문에 더 많은 인력과 전문 지식이 필요하기 때문입니다. 하지만 기본 구조는 그대로입니다. 내부와 외부가 함께 일하는 혼합팀입니다.
마지막 장애 요인은 ‘시간’ 문제였습니다. 부처는 서비스 운영만으로도 너무 바빠서 1년을 통째로 내어줄 수 없었습니다. 게다가 저희 접근법이 효과가 있다는 보장도 없었기 때문에, “1년 동안 당신들과 일하겠습니다”라고 약속할 수도 없었습니다.
그래서 저희가 찾은 해법이 바로 디자인 스프린트입니다.
혹시 여기 계신 분들 중에 ‘디자인 스프린트’를 알고 계신 분 계십니까? (청중에게 손을 들어보라고 묻는 듯) 네, 잘 아시네요. 구글 벤처스에서 만든 초기 버전은 1주일 일정으로 전체 디자인 과정을 압축해 진행하는 방식이었습니다. 이후 구글은 또 다른 접근법을 제시했는데, 이번에는 전 과정을 3일로 줄였습니다.
저희는 이 방식을 참고했지만, 저희 상황에서는 부처 직원들이 일주일을 통째로 낼 수 없다는 것을 알고 있었습니다. 그래서 저희는 변형된 방식을 만들었습니다.
보통 약 10명 정도의 팀을 구성합니다. 그 안에는 해당 절차를 담당하는 부서 책임자, IT 담당자, 법률 담당자, 디자이너, 그리고 필요에 따라 다른 전문가들이 포함됩니다. 이들은 다섯 번의 세션을 거칩니다. 각 세션은 4시간 정도 진행됩니다.
첫 번째 세션에서는 이해하고 정의하는 과정을 진행합니다. 이후 프로토타입을 만들고, 마지막에는 테스트를 합니다. 이렇게 다섯 번의 세션을 거치면, 약 두 달 안에 프로젝트가 완료됩니다. 만약 새로운 서비스라면 서비스 디자인을 하고, 기존 서비스라면 리디자인을 완료합니다.
이 방식은 저희에게 매우 잘 맞았습니다. 지금까지 약 30개의 프로젝트를 이런 식으로 진행했고, 모두 효과가 있었습니다. 가장 큰 장점은 예측 가능성입니다. “어떻게 될지는 모르지만, 두 달 안에는 반드시 결과물이 나온다”라는 확신을 줄 수 있었기 때문입니다. 이것은 부처를 설득하는 데 큰 힘이 되었습니다.
하지만 문제는 ‘원 사이즈(one size)’ 접근이 모든 프로젝트에 맞을까? 였습니다. 당연히 그렇지 않습니다. 당연히 모든 프로젝트에 이 틀이 딱 들어맞는 것은 아닙니다.
어떤 프로젝트는 이 두 달짜리 스프린트에 아주 잘 맞습니다. 하지만 어떤 프로젝트는 훨씬 더 복잡하고, 더 많은 시간이 필요합니다. 이런 경우 저희는 두 번째 세션(재정의 단계)에서 우선순위를 정합니다. 예를 들어, 문제점이 10개라면, 이번 두 달 동안은 가장 중요한 5개만 해결합니다. 그리고 부처가 결과에 만족한다면 이후에 또 다른 스프린트를 열어 나머지 문제를 해결합니다.
또 다른 경우에는 단순히 문제의 수가 많은 것이 아니라, 서비스 자체가 매우 복잡한 경우도 있었습니다. 이럴 때는 첫 번째 스프린트에서 고수준 분석과 로드맵, 블록 다이어그램을 만들고, 특정 부분만 디자인합니다. 이후 추가 스프린트에서 이 로드맵의 각 부분을 차례로 깊이 다루는 방식으로 진행했습니다.
현재까지는 이런 방식이 잘 작동했습니다. 그러나 언젠가는 실패할 수도 있을 것이라 생각합니다. 그래서 오늘 이 자리를 빌려 여러분께 묻고 싶습니다.
저희가 사용하는 이 두 달짜리 프레임워크는 모든 프로젝트에 맞지 않을 것입니다. 그렇다면 어떤 프로젝트에서는 이 방식이 실패할까요? 어떤 유형의 프로젝트에서는 이 방법이 통하지 않을 것이라 생각하십니까? (청중을 향해 질문)
참석자 A (Service Design Lead, Cyprus)
네, 저도 이런 문제를 경험한 적이 있습니다. 제가 담당했던 한 서비스는 조사만 반년이 걸렸습니다. 그 이유는 단순했습니다. 따를 수 있는 법적 근거가 없었기 때문입니다. 그래서 규칙을 새로 만들어야 했습니다.
이 서비스에는 이해관계자가 너무 많았고, 각자 의견이 달랐습니다. 데이터를 수집해야 했고, 여러 부서와 통합해야 했습니다. 그런데 백엔드 시스템은 준비가 안 되어 있었고, 협력할 인력도 부족했습니다.
그래서 매번 범위를 다시 정의해야 했습니다. “이건 범위 안에 포함된다, 이건 아니다.” 다른 부서 시스템과 통합해야 할 때는 기다릴 수밖에 없었습니다. 대신 사용자에게 직접 업로드하도록 요구하기도 했습니다.
결국 여기서 중요한 것은 ‘사용자 중심’과 ‘부서 간 협력’ 사이에서 균형을 찾는 일이었습니다. 정부 내 여러 부서와 협력하는 것이 가장 큰 문제였습니다. 그래서 어떤 서비스는 2개월 안에 끝났지만, 다른 서비스는 설계와 개발에 1년 이상이 걸리기도 했습니다.
Josep Maria Flores Juanpere
네, 말씀하신 것이 정확합니다. 사실 저희의 방식은 일종의 ‘광란의 달리기(crazy run)’와 같습니다. 우리는 반드시 두 달 안에 프로젝트를 끝내야 한다는 압박 속에서 가장 쉬운 길을 택합니다. 만약 법을 바꿔야 하는 문제가 있다면, 그것은 피해갑니다. 다만 프로젝트가 “미래를 상상해보자”라는 성격이라면, 두 달 안에 미래를 상상하는 것까지는 가능합니다. 하지만 근본적으로는 쉬운 길을 택하게 됩니다. 이것은 장단점이 있습니다. 말씀 감사합니다.
참석자 B (Andre, Municipality of Oslo)
저는 이 스프린트 방식이 모든 프로젝트에 맞지 않을 수 있다고 생각합니다. 특히 사용자 여정(user journey)이 여러 서비스 경계를 가로지르는 경우에는 잘 작동하지 않을 수 있습니다.
예를 들어, 특정한 하나의 요구에 대응하는 단일 서비스라면 두 달짜리 스프린트가 충분할 수 있습니다. 하지만 그 요구가 “나는 이 나라로 이사 왔다”라든가, “가족이 세상을 떠났다, 장례 절차를 진행해야 한다” 같은 것이라면, 이는 단일 서비스가 아니라 매우 큰 서비스 시스템과 연결됩니다. 이런 경우 사용자 여정은 여러 조직의 경계를 넘나들게 됩니다.
이럴 때는 단순히 한 부서와만 협업해서는 안 되고, 다양한 서비스 시스템을 함께 고려해야 합니다. 따라서 두 달짜리 스프린트만으로는 충분하지 않을 수 있습니다. 반면, 특정 업무만 담당하는 단일 서비스라면 이 방식이 매우 효과적입니다. 일정 조율도 쉽고, 신속하게 결과를 낼 수 있습니다. 그러나 여러 조직과 협력해야 한다면, 각 부서마다 다른 일정이 있어 맞추기가 어렵습니다.
Josep Maria Flores Juanpere
네, 맞습니다. 저희도 그런 대형 프로젝트를 몇 차례 경험했습니다. 그중 하나는 전 부처가 모두 참여해야 하는 ‘협회 설립 및 운영 시스템’을 만드는 일이었습니다. 저희도 처음에는 “과연 이 방식이 통할까?”라는 의문을 가졌습니다. 그래서 저희는 프로젝트를 분할하여, 여러 번의 2개월 스프린트를 반복하는 방식으로 진행했습니다.
결국 다섯 번 정도의 스프린트를 거쳤습니다. 각 스프린트가 끝날 때마다 새로운 프로토타입을 만들고, 모든 부처가 합의하는지를 확인했습니다. “네, 여기까지는 모두 동의합니다”라는 합의가 이뤄지면, 그다음 단계로 넘어갔습니다. 물론 단일 서비스를 리디자인할 때처럼 쉽지는 않았습니다. 하지만 이런 식으로 반복적인 합의 과정을 거쳐서 진행할 수 있었습니다.
참석자 C (Gabri, Poano)
저는 또 다른 요인이 있다고 생각합니다. 이해관계자 수와 복잡성도 중요하지만, 우리가 어떤 종류의 혁신을 추구하는지에 따라 달라집니다. 그리고 이해관계자와 어떤 관계를 맺고, 그들의 필요와 요구를 얼마나 깊이 이해하는지가 핵심이라고 생각합니다.
작은 프로젝트나 단순한 절차라면 두 달 안에 충분히 결과를 낼 수 있습니다. 하지만 진정한 공감(empathy)을 쌓고, 사용자와 이해관계자의 필요를 깊이 파악해야 하는 경우에는 더 많은 시간이 필요할 수 있습니다.
Josep Maria Flores Juanpere
네, 아주 중요한 지적입니다. 말씀하신 대로, 저희가 지금까지 성공할 수 있었던 이유 중 하나는 저희가 모든 부처의 ‘오랜 파트너’였기 때문입니다. 이미 각 부처 안에 친구 같은 네트워크가 있었고, 덕분에 신뢰가 있었습니다. 그런데 새로운 이해관계자가 끼어들면 상황은 달라집니다. 그들은 저희를 잘 알지 못하고, 저희 방법론도 이해하지 못합니다. 이런 경우에는 모든 것이 갑자기 멈추게 됩니다.
그래서 단순히 “5번의 세션, 두 달”이라는 제한만으로는 충분하지 않습니다. 회의에 적절한 사람이 참석하지 않거나, 의사결정 권한이 없는 사람들이 모이면, 다섯 번의 세션을 다 마쳐도 아무런 성과가 나오지 않을 수 있습니다.
저희가 시간을 압축해 두 달 안에 끝낼 수 있었던 이유는 몇 가지 다른 요소 덕분이기도 합니다.
우선, 저희는 내부 퍼실리테이터(내부 디자이너)를 사용합니다. 내부 디자이너는 부처의 언어와 필요를 이미 알고 있어서, 빠르게 맥락을 이해할 수 있습니다.
또한 저희는 도구들을 미리 준비해둡니다. 예를 들어, 온라인 협업 툴 Miro 보드를 활용할 때, 그냥 빈 칸에서 시작하지 않습니다. 이미 알려진 정보, 기존 문서, 당연한 사실들은 미리 채워 넣고 시작합니다. 그렇게 하면 세션에서 모두가 제로에서 출발하는 대신, 이미 쌓인 기반 위에서 빠르게 새로운 아이디어를 발전시킬 수 있습니다.
프로토타입을 만들 때도 마찬가지입니다. 완전히 빈 화면에서 시작하지 않고, 늘 ‘버전 0’을 준비해갑니다. 그러면 참여자들은 비판하고 개선하는 데 집중할 수 있고, 시간은 훨씬 절약됩니다.
또한, 다학제적 팀을 꾸립니다. 여기에는 서비스에 대한 세부 지식을 가진 사람과, 동시에 어느 정도 권한이 있는 사람이 함께 들어옵니다. 그래야 실제로 결정을 내릴 수 있습니다. 저희는 보통 조직도에서 중간 관리자급, 즉 실무도 알고 일정 부분 권한도 가진 사람을 팀에 넣습니다. 저희는 시각화 기법을 사용합니다. 여러분도 아시다시피, 이는 일을 훨씬 빠르게 만듭니다.
그리고 회의가 단순한 논의가 아니라 몰입(flow) 상태에 들어가도록 만듭니다. 헝가리 심리학자가 정의한 ‘몰입 상태’처럼, 방해받지 않고 생산적으로 일하는 분위기를 조성하는 것입니다.
즉, 일이 막힘없이 흘러가고, 방해물이 없으며, 생산성이 극대화되는 상태를 말합니다.
그런데 이 몰입 상태를 깨는 요인이 있습니다.
예컨대, 긴장감, 불신, 혹은 “잠깐 멈춰야겠다. 상사에게 물어봐야 하는데 상사가 지금 여기에 없다” 같은 상황이 그것입니다.
그래서 저희는 이런 상황을 피하기 위해 여러 방법을 씁니다.
예를 들어 농담을 던지기도 하고, 스스로 광대(clown) 같은 역할을 하기도 합니다.
또한 저희는 프로젝트에 굉장히 열정을 쏟습니다. 그렇게 해야 해당 부처 사람들이 “아, 이 사람들은 진심으로 우리의 서비스를 개선하려고 하는구나”라고 느낄 수 있기 때문입니다.
그리고 저희는 비공식적인 자리에서도 많은 노력을 합니다.
예컨대, 복도에서 만나 대화하며 ‘이 프로젝트 잘 되고 있나요?’라고 묻거나, 사람들의 생각을 미리 들어보고, 세션 전에 모두가 같은 방향을 바라보도록 조율합니다.
이렇게 해서 저희는 한두 개의 프로젝트를 성공적으로 진행할 수 있었습니다.
그러고 나서 생각했습니다.
“이제 이 방식을 전 부처 차원에서 확산시켜야 한다.”
그래서 저희가 제일 먼저 한 일은 “성경(Bible)”을 작성하는 것이었습니다.
여기 보시는 것이 저희의 ‘디자인 성경’입니다. 특별한 내용이 들어 있는 것은 아닙니다. 표준적인 디자인씽킹 방법론을 저희 조직의 관료적 언어로 번역하고, 저희 맥락에 맞게 조정한 문서입니다.
하지만 중요한 차이가 있습니다. 이 문서가 법으로 강제되었다는 것입니다.
카탈루냐 법에 “서비스는 이 성경에 따라 디자인되어야 한다”라는 조항이 포함되어 있습니다.
여기 계신 여러분께 이 성경을 팔려는 게 아닙니다. 영어로도 번역되어 있고 다운로드할 수도 있습니다.
다만 제가 말씀드리고 싶은 것은, 여러분도 자신들만의 성경을 작성해보라는 것입니다. 실제로 몇 명이나 이 성경을 읽었는지는 저도 잘 모릅니다. 하지만 저희가 부처에 가서 이야기할 때, “이건 우리 성경에 나온 방법론이고, 법으로도 규정된 방식입니다”라고 말하면, 그 자체가 문을 여는 열쇠가 됩니다.
그 다음 저희가 세운 야심찬 계획은 이랬습니다.
우선, 모든 부처의 조직 단위(organization unit) 직원들을 훈련시키자는 것이었습니다.
이 조직 단위는 일종의 내부 컨설팅팀으로서, 해당 부처 내에서 디지털정부 업무를 관리하는 역할을 합니다.
저희의 아이디어는 이 사람들을 디자인씽킹으로 훈련시키는 것이었습니다.
그리고 나서 부처별로 한 개의 프로젝트를 진행하는 것이었죠.
즉, 16개 부처에서 동시에 16개의 프로젝트를 실행하는 방식입니다.
이렇게 하면 그들이 실제로 방법론을 직접 경험하게 되고, 배우게 되며, 그 다음부터는 저와 제 동료가 물러나도 괜찮아질 것이라고 생각했습니다.
그들이 이후의 모든 프로젝트를 스스로 디자인할 수 있을 것이라고 기대했기 때문입니다.
그러나 안타깝게도, 이 계획은 제대로 작동하지 않았습니다.
물론 몇몇 성공 사례도 있었습니다.
예를 들어 사법부(Justice Department)에서는, 교육을 받고 프로젝트에 참여한 뒤 이 방법론을 사랑하게 되었고, 스스로 적극적으로 적용하기 시작했습니다.
심지어는 저희보다 더 잘 활용하기도 했습니다.
하지만 대부분의 부처는 그렇지 않았습니다.
교육을 받고, 프로젝트에 참여하기는 했지만, 결국 또다시 저희가 뭔가 해주기를 기다렸습니다.
또 어떤 부처들은 스스로 방법론을 적용해보려 했습니다.
하지만 그것이 문제였습니다.
저희가 그것을 ‘좀비 딸(Zombie daughter)’ 현상이라고 부릅니다.
이 비유는 이렇습니다.
여러분의 딸은 사랑스럽고, 잘 교육받았고, 귀엽습니다.
그런데 잠깐 한눈을 팔았다가 다시 보니, 무언가 괴물 같은 존재로 변해 있습니다. 딸이긴 하지만, 더 이상 예전의 딸은 아닌 것이죠.
저희 방법론도 비슷했습니다.
경험과 훈련이 충분하지 않은 사람들이 저희 방법론을 가져다 쓰자, 그것이 왜곡되었습니다.
정의(Definition)는 무엇인지, 프로토타입은 무엇을 위한 것인지조차 제대로 이해하지 못했습니다.
결국 모든 것이 엉망으로 무너졌습니다.
그리고 그것은 “우리 방법론”의 이름 아래 일어났습니다.
그래서 그것은 그들(부처)에도 문제를 일으켰고, 저희의 전체 계획에도 문제가 되었습니다.
왜냐하면, 마치 “이 방법론은 잘 작동하지 않는다”라는 이미지를 남겼기 때문입니다.
그래서 저희는 깨달았습니다. 이 접근 방식은 통하지 않는다는 것을요.
그래서 저희는 여러분께도 묻고 싶습니다. 여러분의 현장에서는 이런 괴물을 본 적이 있습니까? 저희에게는 ‘좀비 딸’이 있었고, 또 다른 괴물은 ‘프랑켄슈타인’이었습니다.
‘프랑켄슈타인’은 방법론을 자기 멋대로 변형하는 경우입니다.
저희 방법론을 가져와서 “이번 프로젝트에서는 세션을 3번만 해보자, 혹은 뭔가 조금 다르게 바꿔보자” 하고 변형해 쓰는 겁니다. 하지만 결과적으로 절대 제대로 작동하지 않았습니다.
저희는 여전히 그런 실수를 반복하고 있습니다.
혹시 여러분도 디자인 프로젝트에서 이런 종류의 괴물을 발견한 적이 있습니까?
참석자 (영국, 정책 디자이너)
네, 저희가 경험한 사례를 말씀드리겠습니다. 정책팀과 함께 프로그램을 개발한 적이 있었습니다.
그 아이디어는 디자이너와 연구자들을 정책 담당자들과 함께 모아 사법 시스템 전반의 문제를 다루자는 것이었습니다.
저는 그것이 아주 훌륭하다고 생각했습니다.
“이제 정말 흥미롭고 창의적인 일들을 많이 해낼 수 있겠구나”라고 기대했죠.
하지만 문제는, 이 프로그램의 자금을 확보하기 위해 모든 작업에 대해 임팩트 평가(impact evaluation)를 하겠다고 약속해야 했다는 점입니다.
제 아이디어는 아니었고, 다른 누군가가 “수백만 파운드의 자금을 확보하자”는 밝은(?) 아이디어를 냈습니다.
결국 그 프로젝트는 막대한 자금을 확보하게 되었고, 우리는 그 돈을 반드시 소진해야 했습니다.
문제는 그 순간부터 모든 노력이 돈을 쓰는 것과, 임팩트 평가가 가능한 방식으로 프로젝트를 수행하는 쪽으로 전환되었다는 것입니다.
그 말은 곧, 어떠한 반복(iteration)도 할 수 없게 되었다는 것을 뜻했습니다.
개입(intervention)을 한 번 정의하고, 그것을 멈추고 고정시켜야 했습니다.
사람들이 그 개입을 경험하고 나서야 평가할 수 있었기 때문입니다.
사업계획서를 쓰고 자금을 따내는 단계에서는 다 좋아 보였습니다.
하지만 실제로 자금을 확보하기 위해 우리가 서명한 조건들 때문에, 결국 프로젝트의 끝에서는 더 이상 디자인씽킹을 할 수 없게 된 것입니다.
Josep Maria Flores Juanpere
네, 결국 돈 때문에 ‘익사(drowned by money)’하신 거군요?
참석자 A
맞습니다.
다시 한다면 저는 돈을 받지 않았을 겁니다.
그리고 요즘 유행이라고 해도, 임팩트 평가 조건에는 서명하지 않았을 겁니다.
임팩트 평가를 한다는 건, 곧 반복(iteration)을 할 수 없다는 뜻이니까요.
Josep Maria Flores Juanpere
좋습니다. 혹시 또 다른 괴물 사례가 있습니까?
청중
없습니다.
Josep Maria Flores Juanpere
좋습니다. 그러면 괴물이 아니라, 광대(clowns)는요? 괴물은 아니지만, 광대 같은 경우는요?
청중
네, 괴물은 아니고, 저에게 또 다른 사례가 있습니다.
저는 이런 경험을 했습니다.
디자인, 디자인씽킹, 이런 방법론에 대해 한 번도 들어보지 못한 부처에 들어간 경우였습니다.
그곳에 가서 이 방법론을 소개하면, 처음에는 모두들 그것이 환상적으로 멋지다고 느끼고, 이해하고, 당장 적용해보고 싶어 합니다.
그런데 갑자기, 이상하게도 모두가 더 관심을 가지는 것은 보고서(report)가 되어버립니다.
보고서 자체가 힘의 지렛대(leverage)가 되는 것이죠.
정작 우리가 찾으려던 해결책, 문제 탐구, 혹은 이 방법론이 요구하는 호기심(curiosity)에는 관심이 없어집니다.
그저 “리더에게 제출할 보고서에 무엇을 쓸 수 있느냐”에만 집중하게 되어버립니다.
이런 보고서 중심 사고 때문에 초점이 완전히 다른 데로 흐르는 경우를 저는 여러 번 경험했습니다.
Josep Maria Flores Juanpere
네, 아주 공감됩니다. 저희도 비슷한 상황을 겪었습니다.
저희의 밝은 계획은 결국 완전히 실패했습니다. 하지만 그렇다고 해서 전혀 효과가 없었던 것은 아닙니다. 몇 가지 긍정적인 결과도 있었습니다.
첫째, 조직 전반의 인식 제고가 있었습니다. 모든 부처가 최소한 한 번은 프로젝트를 경험했고, 교육도 받았습니다. 그 덕분에 이제는 조직 전체가 “디자인씽킹이 무엇인지”를 알게 되었습니다.
둘째, 신뢰가 생겼습니다. 예전에는 부처들이 저희는 신뢰했지만, 방법론 자체는 믿지 않았습니다. 그러나 교육과 프로젝트를 경험한 후에는 방법론 자체도 신뢰하게 되었습니다.
셋째, 저희 팀에게도 큰 학습 효과가 있었습니다. 디자인씽킹은 뛰어난 도구이지만, 프로젝트마다 다른 장애물이 있었습니다. 프로젝트를 반복하면서 저희는 이러한 장애물을 극복하는 경험을 쌓았습니다.
마지막으로, 예상치 못했던 효과가 있었습니다. 그것은 바로 중앙 디자인 서비스(central design service)가 된 것입니다. 저희는 이제 ‘수요에 따라 부처가 요청하면 지원하는 중앙 디자인 팀’으로 자리 잡았습니다. 이제는 보조금, 허가, 계획, 지원 서비스 등 다양한 프로젝트가 저희에게 들어옵니다.
보통 이런 프로젝트의 전형적인 흐름은 이렇습니다.
처음 절차가 시스템 안으로 들어올 때에는, 많은 사람들이 그 절차를 수행하려 하지만,
현실적으로는 여러 장애물이 가로막습니다.
- 서비스를 알지 못한다.
- 컴퓨터가 없다.
- 가지고 있는 컴퓨터에서 서비스가 작동하지 않는다.
- 사용 언어를 이해하지 못한다.
- 기타 등등…
이런 이유들 때문에, 최종적으로는 아주 소수의 사람들만이 온라인으로 절차를 완료하게 됩니다. 저희가 기대하는 것은, 서비스디자인을 통해 재디자인을 거친 이후에는, 절차를 시도하는 모든 사람이 성공적으로 절차를 완료할 수 있게 되는 것입니다.
예를 들어, 2020년에는 한 서비스의 온라인 이용률이 25%에 불과했습니다. 매년 약 88건만 온라인으로 처리되었습니다. 하지만 저희가 2021년에 리디자인한 후, 2022년에는 온라인 이용률이 두 배로 증가했습니다. 동시에 오프라인 이용 건수는 줄었습니다.
하지만 이런 결과가 나오려면, 해당 절차가 제대로 정의되어 있어야 합니다.
여기서 중요한 개념 차이를 말씀드리고 싶습니다. 그것은 ‘절차(procedure)’와 ‘삶의 사건(life event)’의 차이입니다.
절차가 명확하게 정의되어 있고, 시민의 필요를 충족시킬 수 있다면, 그 절차는 단순히 리디자인하면 됩니다. 그러나 절차의 범위가 제대로 정의되지 않았다면 문제가 됩니다.
시민은 보통 하나의 절차가 아니라, 삶의 사건을 경험합니다. 예를 들어, 대학에 입학했을 때, 또는 지갑을 잃어버렸을 때, 시민이 필요한 것은 ‘증명서 한 장’이 아닙니다. 그런데 정부가 제공하는 것은 ‘증명서를 발급하는 절차’입니다.
문제는 시민은 증명서를 필요로 하지 않는다는 것입니다. 증명서는 단지 수단일 뿐, 실제 필요는 그것을 통해 달성되는 결과입니다.
이런 경우 저희는 단일 절차만을 리디자인하지 않습니다. 대신, 절차의 범위를 다시 정의합니다.
예를 들어, 한 ‘삶의 사건’을 해결하기 위해 여러 절차가 얽혀 있다면, 저희는 그 절차들을 묶어서 다시 디자인합니다. 이를 위해 여러 부처가 모여 부처 간 통합 리디자인(cross-department redesign)을 진행합니다.
저희는 대통령부이기 때문에, 여러 부처를 조정할 권한이 있습니다. 그래서 이러한 부처 간 프로젝트를 추진할 수 있었습니다.
예를 들어, 협회 등록 절차가 있습니다. 과거에는 협회를 설립하려면 법무부에 등록해야 했습니다. 하지만 만약 그 협회가 문화 활동을 한다면 문화부에도 등록해야 했고, 환경과 관련이 있다면 환경부에도 등록해야 했습니다. 이렇게 여러 부처에 각각 등록해야 했습니다.
저희는 이것을 하나의 통합 등록 절차로 리디자인하려고 했습니다. 단일한 절차를 통해 여러 부처의 요구사항을 한 번에 충족시키는 방식입니다.
또 다른 사례는 드론 비행 허가입니다. 만약 드론을 A도시에서 B도시로 날리고 싶다면, 경찰에 허가를 받아야 하고, 병원이 있는 경우에는 병원 헬리포트와 충돌 위험 때문에 병원에도 허가를 받아야 했습니다. 보호구역을 지나면 환경 당국에도 허가를 받아야 했습니다. 이렇게 많게는 10개의 허가를 각각 신청하고 승인받아야 했습니다.
저희는 이러한 절차들을 하나로 묶어, 통합 허가 양식 (unified permission form)을 만들고자 했습니다. 시민이 한 번의 신청만으로 필요한 모든 허가를 받을 수 있도록 하는 것입니다.
이와 같이 저희는 중앙 디자인 서비스(central design service)로 자리 잡았습니다. 지금은 부처들이 필요할 때 저희에게 찾아와 “이 절차를 리디자인하고 싶다”라고 요청합니다. 그러면 저희가 지원합니다.
이 과정에서 저희는 팀 다이내믹스를 발전시켰습니다. 모든 디자이너는 개별 프로젝트를 맡지만, 서로 배울 수 있도록 매주 프로젝트를 공유하고 비판합니다. 예를 들어, 제가 책임자로 있지만 동시에 프로젝트의 디자이너이기도 합니다. 제가 맡은 프로젝트를 팀 앞에서 보여주면, 다른 디자이너들이 “여기서 당신은 잘못했다”라고 비판합니다. 그렇게 서로 배우고 개선합니다.
저희는 개방적(open)이고 학습 지향적인 문화를 갖추게 되었습니다.
그리고 이제 저희는 또 다른 단계로 나아가고 있습니다. 바로 수많은 서비스들을 동시에 리디자인하는 것입니다. 지금까지는 약 25~30개의 프로젝트를 해왔습니다. 하지만 이제는 카탈루냐 정부가 제공하는 약 2,000개의 디지털 절차 전체를 다루어야 합니다.
저희의 목표는 가능한 한 짧은 시간 안에 이 모든 절차를 사용자 친화적으로 만드는 것입니다.
그래서 저희는 올해부터 2026년까지, 약 200개의 프로젝트를 진행할 예정입니다. 이는 연간 이용자가 1,000명 이상인 절차를 모두 포함합니다. 이 작업이 끝나면, 정부와 시민 간 디지털 상호작용의 약 **95%**를 다루게 됩니다.
즉, 시민들이 정부와 관계 맺는 대부분의 영역에서 체감할 수 있는 개선을 이루는 것이 목표입니다. 이것은 더 많은 자원이 필요합니다.
이 작업은 유럽연합 기금을 통해 가능해졌습니다. 덕분에 더 많은 디자인 팀을 고용할 수 있었습니다. 저희는 이전에 말씀드린 것과 같은 혼합팀(mixed teams) 방식을 그대로 적용하고 있습니다.
외부팀이 아니라 내부팀처럼 작동하도록 구성했습니다.
또한 전체 프로그램을 관리할 별도의 팀도 두었습니다.
확대(scale-up)에는 자원뿐 아니라 신뢰(trust)가 필요합니다.
저희는 처음에, 이를 실현하려면 모든 부처가 절차를 저희에게 의무적으로 넘기도록 법령이나 규정을 제정해야 한다고 생각했습니다.
그러나 실제로는 필요하지 않았습니다.
부처들은 이미 저희와 함께 했던 프로젝트에서 효과를 경험했고, 그 경험으로 인해 자발적으로 주요 절차들을 저희와 함께 재디자인하는 것에 동의했습니다.
확대 과정에서 또 다른 강점은 저희가 디지털 플랫폼을 직접 책임지고 있다는 점입니다.
새로운 서비스를 매번 처음부터 개발하는 것은 불가능합니다.
따라서 저희는 재사용 가능한 플랫폼과 디자인 시스템을 적극 활용합니다.
서비스의 고충점 중 일부는 플랫폼에서 비롯됩니다.
하지만 저희가 플랫폼을 직접 관리하기 때문에, 플랫폼이 만들어내는 장애물도 함께 제거할 수 있습니다.
또한 디자인 시스템(design system)과 통제된 어휘집(controlled vocabulary)도 도입했습니다.
서비스마다 매번 UI 요소를 새로 만드는 것이 아니라, 재사용할 수 있도록 표준화했습니다.
또한 언어를 이해하기 쉽게 바꾸는 작업을 담당하는 전담 유닛을 두었습니다.
그들은 “사용할 단어 목록”과 “사용하지 않을 단어 목록”을 만들어, 모든 서비스에서 같은 의미를 같은 방식으로 전달하도록 하고 있습니다.
마지막으로, 저희는 평가(evaluation)를 도입하고 있습니다.
그동안은 체계적인 평가를 하지 않았지만, 이제 이 규모에서는 반드시 필요합니다.
그리고 이것은 문화적 변화(cultural change)를 요구합니다.
2026년 6월까지 모든 부처는 주요 절차를 재디자인하게 될 것입니다.
즉, 모든 유닛이 최소한 한 번은 서비스디자인 프로젝트를 경험하게 됩니다.
이를 통해 저희는 공무원들의 일하는 방식을 바꾸고자 합니다.
즉, 생산에 투입하기 전에 반드시 테스트(test)를 거치는 습관을 들이는 것입니다.
이 변화가 실제로 일어나기를 기대하고 있지만, 200개 프로젝트를 마친 후에 정확히 어떤 변화가 일어날지는 아직 알 수 없습니다.
그래서 마지막으로 여러분께 묻고 싶습니다.
혹시 여러분도 디자인을 스케일업(scale-up)해 본 경험이 있습니까?
저희보다 더 멀리 나아간 곳이 있다면, 그다음 단계가 무엇일지 알려주시면 감사하겠습니다.
저희는 아직 모릅니다. 200개 프로젝트 이후에 무엇이 기다리고 있을지 말입니다.
어쩌면 이 자리의 누군가가 그 답을 알고 있을지도 모릅니다.
시간 관계상 지금은 더 논의할 수 없지만, 나중에 여기서 계속 이야기를 나눌 수 있기를 바랍니다.
이제 저희 발표를 마치겠습니다.
다음 세션에서는 호주 국세청(Australian Taxation Office)이 조직이 성숙 단계에 도달했을 때 어떤 일이 일어나는지를 발표할 예정입니다.
저희가 도달하려고 하는 바로 그 수준입니다.
경청해 주셔서 감사합니다.
'서비스디자인 > 정책디자인' 카테고리의 다른 글
| (영상) 영국 정책랩과 함께하는 실험적 정책디자인 방법 탐색 - 폴리시랩 공동대표 스티븐 베넷 등 (0) | 2025.08.21 |
|---|---|
| (영상) 정부, 디자인으로 재구성하라 - 마르코 스타인버그 (1) | 2025.08.19 |
| (영상) 정부를 위한 디자인: 과거를 돌아보고 미래를 내다보다 - 누리아 솔소나, 마르코 슈타인베르크, 이승호. 2024.10.2. (0) | 2025.08.17 |
| (영상) 공동체의 힘, 정부 전환의 긴 여정을 함께 헤쳐 나가기 - 카라 케인, 마르틴 요르단. 2024.10.4. (3) | 2025.08.17 |
| (논문) 정책과 디자인은 어떻게 교차하는가? 세 가지 관계 - 리즈 리처드슨, 캐서린 듀로즈, 루시 킴벨, 라미아 마제. 2025.6. (6) | 2025.08.16 |
| (보고서) 디자인과 정책: 영국의 현재 쟁점과 향후 연구 방향 - 2023 (0) | 2025.08.16 |