(영상) 더블린의 미래 매핑하기: 아일랜드 최대 지자체의 서비스디자인 - 게리 스컬리온

게리 스컬리온은 아일랜드 최대 지방 자치 단체인 더블린 시의회에서 복잡한 공공 서비스를 개선하기 위해 서비스디자인을 도입한 여정을 소개한다. 부서 간 장벽과 불분명한 프로세스가 시민들에게 주는 좌절감을 지적하며, 이를 해결하기 위한 '서비스 아키텍처'를 제안한다. 특히 980개에 달하던 방대한 서비스 목록을 시민 중심의 '탑 태스크(Top Tasks)' 분석을 통해 67개의 핵심 서비스로 압축했다. 신뢰와 평판의 손실까지 고려한 '서비스 비용(Cost to Serve)' 모델을 통해 공공 서비스의 보이지 않는 가치를 조명한다. 외부 전문가의 도움 없이 조직 내부의 역량을 강화하는 '함께 하는(done with)' 디자인의 중요성을 강조한다. 이 발표는 인간의 상호작용이 중심이 되는 '관계적 경험'을 구축하여 더 인간적인 공공서비스를 만드는 방안을 제시한다.

더블린의 미래 매핑하기: 아일랜드 최대 지방자치단체의 서비스디자인 - 게리 스컬리온

채널: JourneyOps
날짜 및 장소: 2025년 12월 16일, 스톡홀름

게리 스컬리온(Gerry Scullion)은 Humana Design의 서비스디자인 디렉터이며 글로벌 디자인 커뮤니티인 'This is HCD' 팟캐스트를 창립한 인물이다. 그는 약 14년 동안 호주에 거주하며 뉴사우스웨일스 및 빅토리아 주 정부 등 대규모 공공 기관과 협력하여 인간 중심 디자인 전략을 수행해 온 경력이 있다. 아일랜드로 돌아온 후에는 6,000명 규모의 아일랜드 최대 지방 정부인 더블린 시의회의 서비스 개선 프로젝트를 주도하며 '서비스 아키텍처'라는 독자적인 접근 방식을 적용했다. 이 과정에서 그는 980개에 달하던 방대한 서비스 카탈로그를 '탑 태스크(Top Tasks)' 프레임워크를 통해 67개의 핵심 서비스로 재편하여 조직의 전략적 의사 결정을 지원했다. 그는 단순한 외부 컨설팅 방식에서 벗어나 조직 내부의 역량을 직접 강화하고 신뢰를 구축하는 '함께 하는(done with)' 디자인 실천을 강조한다.

(유튜브 영상 소개글 발췌)
게리 스컬리온(Gerry Scullion)이 아일랜드 최대 지방 자치 단체인 더블린 시의회(Dublin City Council)가 시민들을 위한 서비스를 개선할 수 있도록 어떻게 도왔는지 설명합니다. 게리는 불분명한 프로세스, 느린 시스템, 그리고 부서 간의 장벽(silo)이 어떻게 시민들에게 실망스러운 경험을 주는지 보여주며, '서비스 아키텍처(service architecture)' 접근 방식을 도입해 이러한 복잡성을 어떻게 해결했는지 들려줍니다. 그는 자신의 팀이 서비스를 매핑하고, 시민들에게 가장 중요한 것이 무엇인지 파악하며, 조직 내부의 역량을 강화하고, 현재 시스템에 숨겨진 비용을 어떻게 찾아냈는지에 대한 경험을 공유합니다. 이 강연은 서비스디자인이 어떻게 사람들을 하나로 모으고, 더 나은 의사 결정을 이끌어내며, 더 명확하고 인간 중심적인 공공 서비스를 만들 수 있는지에 대한 실질적인 사례를 제시합니다.

원본 영상 출처 : https://youtu.be/U_IucP7gc64?si=7pzJQFaE7LozaObf  
번역 : 제미나이 (요약, 생략된 부분이 있을 수 있습니다. 원본을 봐 주세요.)

 

---

 

마크의 뒤를 이어 발표하는 게 정말 싫네요, 아시죠? 마크가 저보다 훨씬 재미있기 때문인데, 그래도 최선을 다해서 이 지루할 수도 있는 이야기를 잘 이끌어보겠습니다. 하지만 Essa가 말했듯이 제 작업의 많은 부분은 지난 10년 동안 전 세계 정부들과 협력해 온 매우 흥미로운 것들입니다.

그래서 저는 이 프로젝트의 기원과, 6,000명이 근무하는 아일랜드 최대 지방 정부에 제가 '서비스 아키텍처'라고 부르는 개념을 도입할 수 있었던 기회를 어떻게 열었는지에 대해 말씀드리고자 합니다. 왜 제가 이것을 '저니 옵스(journey ops)'나 '여정 관리(journey management)'가 아닌 '서비스 아키텍처'라고 부르는지, 그 기회에 대해 말씀드리겠습니다. 그리고 방법론에 대한 아주 세부적인 내용까지 들어갈 예정입니다. 왜냐하면 여기 계신 분들과 이야기를 나누고 질문을 들어보니, 우리가 이런 환상적인 프레임워크를 가지고 여기서 관조하며 "정말 멋지다"라고 말하는 것도 좋지만, 그것이 어떻게 행동으로 옮겨져서 우리가 디자인하는 시민들에게 실질적인 변화를 만들어내는지 아는 것이 중요하기 때문입니다. 어떤 분들은 제 팟캐스트를 아실 수도 있는데, 사실 이 사업은 그 팟캐스트에서 시작되었습니다. 저는 꽤 오랫동안 디자인 리더십 분야에서 일해 왔습니다. 또한 변화를 만들고자 하는 분들을 위한 프라이빗 커뮤니티도 운영하고 있습니다.

이 프로젝트의 배경을 조금 설명해 드리겠습니다. 저는 호주에서 약 14년 동안 살았습니다. 억양을 오갈 수도 있죠. 하지만 저는 사실 아일랜드 사람이고, 아이들을 아일랜드 사람으로 키우고 싶어서 고향으로 돌아왔습니다. 제 뿌리로 돌아가는 것은 저에게 매우 중요한 일이었습니다. 제가 호주에 살 때 누군가 저에게 "아이들이 '워러(water)'라고 말하길 원해요, 아니면 '워터(wa-ter)'라고 말하길 원해요?"라고 묻더군요. 저는 "세상에, 당연히 '워터'지"라고 생각했습니다.

그래서 집으로 돌아가기로 결정했고, 호주의 거대한 지형을 가로지르는 대규모 정부 조직인 뉴사우스웨일스 정부와 빅토리아 정부에서 일하면서 컨설팅의 변화를 느끼기 시작했습니다. 저는 그곳에 영입된 독립적인 전문가였습니다. 제가 알아차린 것은 컨설팅 업체들이 아주 아주 오랫동안 그곳에 머물러 있다는 점이었습니다. 그래서 저는 운영 방식을 조금 더 바꾸고 싶었고, 신뢰를 제가 하는 모든 일의 중심에 두었습니다. 이것은 매우 중요한데, 컨설팅 업체에 대해 나쁜 말을 하려는 건 아니지만, 저는 그들이 독립적이기를 원하기 때문입니다. 저는 그들이 조직 내부에서 스스로 기능을 성장시킬 수 있기를 바랍니다.

이것은 큰 변화입니다. 신뢰를 전문성(credibility), 신뢰성(reliability), 친밀함(intimacy), 그리고 자기 지향성(self-orientation) 측면에서 볼 때, 신뢰 기반 관행에서 말하는 첫 번째는 전문성입니다. 당신은 당신이 말하는 것에 숙련되어 있습니까? 실제로 그것들을 전달할 수 있습니까? 다른 사람들이 당신의 판단에 정말로 의존할 수 있습니까? 두 번째는 신뢰성입니다. 끝까지 완수합니까? 당신이 말한 것을 의미하고, 의미하는 것을 말합니까? 그것은 정말 중요합니다. 사실을 전달하고 끝까지 이행하는 것 말입니다. 그다음은 친밀함입니다. 안전한 공간을 만드나요? 마크처럼, 어젯밤에 저희에게는 'Service Design in Gov'에서 기조연설을 했던 레이첼 디아커스라는 좋은 친구가 있습니다. 저와 마크는 지난주에 거기서 발표를 했죠. 이것은 단순히 "자 여러분, 이제 안전한 공간입니다. 무엇이든 편하게 말씀하세요. 제가 안전하다고 말했으니 안전한 겁니다"라고 말하는 게 아닙니다. 우리는 실제로 시범을 보이고 행동으로 옮겨야 합니다. 인간 중심 디자인을 실천할 때 '트라우마를 고려한다(trauma-informed)'는 것은 무엇을 의미할까요? 단순히 인간 중심 디자인 팀에 있다고 말하면서 사람들의 데이터를 추출해서 조직을 발전시키는 데 사용하는 것만으로는 부족합니다. 그리고 서비스디자인에서의 행동들이 정말로 당신을 위한 것인가요? 어떤 조직의 리더들은 팀의 성과를 가로채는 경우가 있는데, 여기 계신 분들 중에는 그런 분이 없을 거라 믿습니다. 이 모든 것을 합치면 신뢰 프레임워크를 향해 나아가기 시작하게 됩니다.

저는 제가 다운로드 링크를 드릴 수 있는 '서비스디자인 성숙도 조직 캔버스(service design maturity organization canvas)'에 대해 이야기합니다. 이것은 영국 뉴 카운슬(New Council)의 모델을 개선한 것입니다. 그것이 필요하시면 말씀해 주세요. 드롭박스 링크를 드릴게요. 이제 서비스디자인 성숙도에 대해 이야기해 봅시다. 제 고객사인 더블린 시의회의 경우, 서비스디자인 팀 내부의 성숙도는 꽤 높을 수 있습니다. 여정 관리나 다양한 리서치 방법에 대해 잘 아는 사람들이 있을 수 있는데, 그건 아주 좋은 일입니다. 하지만 여러분이 세계 최고의 서비스디자인 팀이라 할지라도, 그것을 제대로 이해하지 못하는 조직 내에서 일한다면 그것은 매우 어렵습니다. 그리고 그것은 아까 말씀하신 어떻게 그것을 발전시킬 것인가에 대한 문제로 이어집니다.

제가 말하는 프레임워크에서는 이들을 '새싹(sprouts)'과 '씨앗(seeds)'이라고 부릅니다. 서비스디자인 팀에는 새싹들이 있습니다. 그들은 서비스디자인 팀이라고 불리지 않을 수도 있지만 놀라운 전문가들입니다. 그들은 서비스디자인에 더 많이 참여하고 싶어 하지만, 조직의 나머지 부분은 여전히 씨앗 수준에 머물러 있습니다. 제가 이 고객과 7년 동안 간헐적으로 일하면서 알게 된 것은 제가 많은 프로젝트에 노출되고 있었다는 점입니다. 그것을 통해 저는 일종의 신뢰 네트워크를 구축할 수 있었습니다. 다시 말씀드리지만, 저는 제가 가진 비전과 가치라는 모토를 실천하며 삽니다. 그리고 그것은 마치 요트를 타러 가는 것처럼 조건을 설정해 주었습니다. 조건과 요트 타기, 연결되는 거 보이시죠? 저는 디자인을 그렇게 생각합니다. 이런 일을 하기에 조건이 적절한가? 서비스 아키텍처로 첫발을 내디딜 만큼 충분한 신뢰를 쌓았는가? 그렇게 기회가 찾아왔습니다.

저는 불법 쓰레기 투기에 관한 프로젝트를 진행하고 있었습니다. 이곳 스톡홀름처럼 깨끗한 도시에서는 일어나지 않을 수도 있지만, 런던이나 더블린 같은 대도시에서 쓰레기가 많이 쌓여 쓰레기통이 가득 차면, 사람들은 그냥 집 앞마당에 쓰레기를 두고 가버려도 괜찮다고 생각하곤 합니다. 그런 일이 발생하면 더블린 시의회는 가서 그것을 수거해야 합니다. 이는 설치류 문제를 일으키고 계속 연쇄 반응을 일으킵니다. 그 프로젝트를 전달한 후, 저는 잠시 후에 말씀드릴 '그 사건의 비용'에 대해 실질적인 관심이 생기는 것을 발견했습니다. 금전적 가치 측면의 비용, 신뢰의 비용, 조직에 대한 인식의 비용 말입니다.

그것이 저를 'CS 리뷰(CS review)'라는 프로젝트로 이끌었습니다. CS 리뷰는 고객 서비스 팀(customer service team)입니다. 제가 그곳에 가서 가장 먼저 한 말은 "그 누구도 검토(review) 대상이 아닙니다"라는 것이었습니다. 저는 "잘한다, 못한다"를 따지러 온 컨설턴트가 아닙니다. 결코 그런 식으로 틀을 짜지 않았지만, 그것이 프로젝트의 이름이었습니다. 저는 고객 서비스 팀을 '입, 심장, 그리고 뇌'라고 부릅니다. 그들은 매일 시민들과 소통하며, 어떻게 도울지에 대한 인지적 결정을 내리고, 인간답다는 것이 무엇인지 보여주는 심장을 가지고 있습니다. 그들은 실제로 매일 수백 명의 사람들과 대화합니다. 저는 이 프로젝트가 무엇에 관한 것인지 확인하기 위해 그 프레임워크에 정말 많이 의존했습니다.

특히 이 프로젝트는 세 가지 주요 사항을 다루었습니다. 현재 서비스에 어떻게 접근하는지, 실제 경험(lived experience)을 전략적 대화로 가져오는 것, 그리고 실행 가능한 권장 사항 세트를 제공하는 것이었습니다. 그리고 나서 우리는 앞으로 나아가기 시작했습니다. 그 브리핑 어디에도 "게리, 네가 '저니 옵스'나 '여정 관리' 같은 걸 해주면 참 좋을 것 같아"라는 말은 없었습니다. 저는 "조건이 딱 맞네"라고 생각했고, 마크에게 전화를 걸어 "예산에 이 내용을 슬쩍 짜 넣기 시작할 거야"라고 말했습니다. 하지만 대놓고 말하지는 않았습니다. 조금 조심스럽게(koi) 접근했죠. 서비스디자인이 꽃을 피울 수 있는 비계(scaffolding)가 전혀 없다는 것을 깨달았기 때문입니다. 모든 것이 매우 단편적인 방식으로 이루어지고 있었습니다. 그래서 이 작업을 이끄는 활동들 속에서 프로젝트가 시작되었고, 저는 중간쯤에 '서비스 아키텍처'라고 불릴 이 지도들을 만들기 시작할 것임을 알고 있었습니다.

여기서 왜 저는 이것을 '서비스 아키텍처'라고 부르고, 마크는 '저니 옵스'나 '여정 관리'라고 부를까요? 정부 부문에서 '아키텍처'는 매우 잘 확립된 관행인 경우가 많습니다. 그들은 건물을 짓는 아키텍처 팀을 가지고 있죠. 저는 이 모든 생태계를 감싸는 서비스들이 여기에 있다고 생각했습니다. 그래서 그것을 서비스 아키텍처라고 부르는 것이 이치에 맞았습니다. 딱 들어맞았죠. 하지만 만약 다음 고객이 나타나서 그것을 여정 관리라고 부른다면, 저도 여정 관리라고 부를 것입니다. 저는 그런 명칭에 크게 신경 쓰지 않습니다. 하지만 그 고객에게는 서비스 아키텍처라는 말이 이해가 되었습니다.

작년 10월에 시작되었으니 생각해보면 거의 1년 전이네요. 시간이 벌써 그렇게 됐다니 믿기지 않지만, 어쨌든 우리는 제가 직접 참여한 내부 인터뷰로 시작했습니다. 저는 더블린 시민들이 전화를 걸어 불만을 제기하거나 요청하는 것을 들었습니다. 그리고 이런 것들이 아주 많다는 것을 알 수 있었습니다. 어느 게 포인터인지 잘 모르겠네요. 한번 해볼까요? 이 버튼을 눌러보겠습니다. 자, 보십시오. 맞는 버튼을 선택한 것에 대해 박수 한번 주세요, 여러분. 감사합니다. 아주 관대한 청중이시네요.

그런데 서비스 우회(service workarounds)가 많다는 것을 알아차렸습니다. 이런 것들을 많이 보게 되는데, 많은 사람이 수첩에 메모를 하고 하루가 끝날 때 수첩을 파쇄하더군요. 정말 놀랐습니다. 제가 그 시점에서 발견한 것 중 하나는 전화가 오면 전화를 받고, 잠시 기다리게 한 다음 다른 라인으로 연결해 다른 부서에 전화를 거는 식이었습니다. 그 담당자가 스스로 결정을 내릴 권한이 없었기 때문입니다. 그 시점에서 문제를 해결할 권한이 없었고, 서비스디자인 관점에서 그것은 놓친 기회라는 것을 우리는 알고 있습니다.

아무튼 그것은 많은 맥락을 제공했고, 저는 시민 인터뷰에 꽤 오랜 시간을 보냈습니다. 시민 인터뷰는 로비에 앉아 상호작용이 일어나는 시점에 사람들을 붙잡고 이야기하는 것이었습니다. 재미있는 일화는 제가 고객들에게 제가 비밀리에 조사(covert stuff)를 할 거라고 알리지 않았고, 결국 건물 밖으로 쫓겨났다는 것입니다. 저는 그게 매우 자랑스럽습니다. 보안 요원이 개입했고, 저는 경찰을 부를 필요는 없다는 전화를 해야 했습니다. 저는 진심으로 연구를 하고 있었던 거니까요. 하지만 그 시점에서 정말 좋은 증거를 얻었습니다.

혹시 '탑 태스크(Top Tasks)'에 대해 들어보신 분 계신가요? 와, 좋습니다. 쉽네요. 모르시는 분들을 위해 말씀드리면, 탑 태스크는 저와 같은 지역 출신이자 CX 전문가인 제리 맥거번(Gerry McGovern)이 만든 것입니다. 가끔 제가 그의 이메일을 받기도 하죠. 아무튼 탑 태스크는 사람들이 당신의 생태계와 상호작용하는 이유 중 상위 20%를 식별할 수 있게 해주는 환상적인 프레임워크입니다. 이것이 왜 중요한가 하면, 조직들이 하위 80%의 아주 사소한 작업들에 계속해서 시간을 투자하는 것을 보게 되기 때문입니다. 높은 직급의 사람들이 "내 프로젝트가 더 중요해"라고 말하며 예산의 많은 부분을 가져가 버리죠. 탑 태스크가 있고 시민들, 고객들과 함께 리서치를 하면 정말 엄밀하고 전략적인 대화를 나눌 수 있습니다. 탑 태스크에 대해 들어본 적이 없으시다면 제리가 쓴 책을 보세요. 기본적으로 어떻게 하는지 다 나와 있습니다. 제리는 반퇴직 상태였는데, 제가 이 프로젝트를 위해 그를 은퇴 생활에서 끌어냈습니다. "제리, 아직 안 죽었잖아요. 와서 나 좀 도와줘요"라고 말했죠. 그는 "고마워요 게리, 스페인에서 정말 즐겁게 지내고 있었는데"라고 하더군요. 저는 "제발 도와주세요 제발"이라고 했고 그는 와서 저를 도와주었습니다. 정말 대단했죠.

그래서 우리는 이 시점에서 탑 태스크도 시작했습니다. 그리고 그것을 통해 현재 더블린 시 내에서 작동하고 있는 모든 서비스에 대한 거대한 생태계적 이해를 시작했습니다. 더블린 시 옆에 LGMA라는 조직이 있는데, 그들은 약 980개의 서비스 카탈로그를 가지고 있습니다. 이 이야기를 왜 하냐고요? 그것이 조직이 가지고 있던 인지였기 때문입니다. 980개의 서비스가 있다는 것 말이죠. 탑 태스크를 통해 저는 그것을 재평가할 수 있었고, 67개로 줄였습니다. 이 67개의 핵심 서비스는 매우 중요합니다. 왜냐하면 그것을 통해 팀 워크숍을 선정하고 우리가 집중하고 싶은 핵심 서비스를 선택할 수 있었기 때문입니다. 이를 통해 경영진에게 "보세요, 980개를 다 볼 필요가 없습니다. 이제 우리는 67개를 보고 있습니다. 남은 프로젝트 기간 동안 제가 어떤 것에 집중하길 원하는지 결정해 주세요"라고 말할 수 있는 데이터를 얻었습니다. 그들은 세 가지 핵심 분야를 선택했습니다.

이와 병행하여 저는 팀을 교육하기 시작했습니다. 저와 마크는 교육을 제공하고 역량을 구축하기 시작했습니다. 다시 말하지만 신뢰가 제가 하는 일의 중심입니다. 저는 팀원들을 알게 되고, 그들은 "전 자격 있는 서비스디자이너가 아니에요, 게리, 여정 지도를 한 번도 그려본 적이 없는데 어떻게 하나요?"와 같은 가면 증후군(imposter syndrome)을 느낄 수도 있다는 것을 알게 됩니다. 그러면 저는 "괜찮아요"라고 말하며 제 영상 강의를 듣게 하고 그들이 직접 해보면서 배우게 합니다. 그리고 저는 그들을 코칭합니다. 우리는 제가 언급한 안전한 공간을 만들고, 그들은 진행하면서 역량을 키울 수 있습니다.

그래서 저는 팀이 데이터를 다루고 함께 일할 수 있도록 교육합니다. "게리는 모든 걸 다 알아, 그를 절대 보내면 안 돼"라는 식은 아닙니다. 그런 컨설팅 모델은 끝났습니다. 지방 정부와 전 세계 정부에서는 정말로 그런 역량을 내부에서 구축해야 합니다. 그래서 저는 제가 하는 일을 공개하고 누구든 참여하고 싶은 사람을 환영합니다. 그것이 우리가 일한 방식입니다.

우리는 세 개의 핵심 스트림(stream)을 선택했고 그 스트림들은 필수적이었습니다. 이 단계에서 이해관계자들은 완전히 설득되었습니다. 더블린 역사상 처음으로 다른 부서들과 신뢰와 역량을 구축할 수 있었고, 그들은 "좋아요, 우리는 이 일에 정말 관심이 있습니다. 당신이 어디로 가려는지 알겠고 이해가 됩니다"라고 말했습니다. "옳은 일을 하는 것"과 같은 핵심 키워드들이 들리기 시작할 때 알 수 있죠.

저는 각 스트림에 대해 매주 코칭 세션을 가졌습니다. 제가 맨 아래 스트림에 있는 것을 보실 수 있을 겁니다. 저는 실제로 도구를 사용하고 리서치를 하고 있습니다. 다른 스트림에 있는 사람들로부터 동료 검토(peer reviews)도 받습니다. 저는 팀원들 속에 섞여 있습니다. 그리고 2월부터 진행 중인 작업물(work in progress)을 만들기 시작했습니다.

저와 마크는 서비스 아키텍처를 한다는 것이 무엇인지 교육하기 시작했습니다. 거버넌스, 즉 의사 결정 프로세스와 코디네이터 측면에서 의례(rituals)와 루틴(routines)은 무엇인가요? 무엇이 일어나야 할까요? 그리고 저는 그것을 다시 다듬었습니다. 하지만 탑 태스크 부분이 훨씬 더 중요해지기 시작했는데, 라이프 사이클 관점에서 이를 바라보면 67개의 서비스를 아키텍처에 짜 넣기 시작하기 때문입니다. 그리고 바로 그 시점에서 저는 이것을 '비계(scaffolding)'라고 부르기 시작합니다. 마크가 아까 지표에 대해 말한 것들을 다룹니다. 그 지표들은 시간이 지남에 따라 변합니다. 예를 들어 지속 가능성 쿼터에 관한 정부의 새로운 정책이 만들어질 수 있고, 그것을 어딘가에 짜 넣어야 합니다. 그것이 고립되어 있는 것을 원치 않을 것이며, 아키텍처로 통합되기를 원할 것입니다. 그것이 제자리를 찾아 의미가 통하게 되기를 원할 것입니다. 저는 이것을 나침반 없이 항해하는 것에 비유합니다. 나침반도 없고 방향도 모른 채 여기서 노르웨이까지 배를 타고 가지는 않을 것입니다. 그것이 오늘 우리가 여기서 이야기하려는 것입니다. 우리는 이 서사를 바꿔야 합니다. 그 변화를 알리기 위한 비계를 만들어야 합니다.

리서치를 좀 해보시면 여기서 나온 핵심 요소 중 하나가 '서비스 난해화(service obfuscation)'였습니다. 사람들이 프로세스가 무엇인지 정말로 모르는 경우입니다. 마크가 비행기를 타러 갈 때, 그는 어느 시점에는 비행기에 타야 한다는 것을 압니다. 비행기는 마크의 경우 다행히도 맞는 목적지에 착륙할 것입니다. 사실 100% 보장할 수는 없지만요. 하지만 특히 정부 서비스에서는 사람들이 정말로 이해하지 못합니다. 그냥 시키는 대로 하면서도 "내가 맞게 하고 있는 건가?"라고 생각합니다. 그것을 이해하기가 정말 어렵습니다. 무언가를 해내기 위해 필요한 노력이 너무 과도합니다. 서비스의 높은 가치에 비해 그렇습니다. 늘어난 노력, 줄어든 신뢰, 비효율성은 모두 핵심 요소입니다. 서비스디자이너로서 우리는 가드레일이 쳐진 멋지고 명확한 길을 만들고 싶어 하지만, 실상 그렇게 빨리 도달하지는 못합니다. 우리는 투명한 서비스를 원합니다. 탐색하기 쉽고 예측 가능한 서비스를 원합니다. 그것들이 우리가 정부 서비스에 요구하는 핵심 사항들이지만, 현실은 이렇습니다. 산을 오르라고 요구하는 것과 같죠. 우리는 그런 서비스를 만들고 싶지 않습니다.

저는 두 가지 다른 것에 대해 언급했습니다. 아까 질문 중 하나가 '참여(buy-in)'를 이끌어내는 것에 관한 것이었죠. 사람들은 "AI가 모든 것을 장악할 거야"라고 말하고, 그런 일은 어디서나 일어나고 있습니다. 우리 모두 같은 처지라는 것을 압니다. 이런 의미에서 서비스에는 두 가지 유형이 있습니다. 여권을 갱신하거나, 지방 재산세를 내거나, 자동차세를 내는 것과 같은 '거래적(transactional)' 서비스들이 있습니다. 그건 괜찮습니다. 이런 것들은 기술이 수시로 개입할 수 있는 거래적인 부분입니다. 하지만 '관계적(relational)'인 것들은 인간적인 측면입니다. 본질적인 공공 주택(social housing) 같은 것 말입니다. 사업을 잃었을 수도 있고, 가족이 노숙자가 될 위기에 처했을 수도 있습니다. 이것들은 관계적인 경험입니다. 이것이 바로 인간 중심 디자인이 독보적인 영역입니다. 사회 복지 같은 것들요. 이런 많은 것들에 기술을 사용할 수 있겠지만, 그것은 매우 관계적인 경험입니다. 자, 서비스를 조금 더 분석해 봅시다.

'요람에서 무덤까지(cradle to the grave)'. 이것이 제가 정부 내에서 사용해 온 프레임워크입니다. 그 사이에는 아주 많은 서비스가 있습니다. 하지만 조금 더 자세히 살펴보겠습니다. 마크가 언급했듯이 한 부서나 한 서비스로 깊이 들어가 보면 많은 파편이 있고, 3단계 아키텍처 수준의 핵심 하위 서비스들이 있다는 것을 알게 될 것입니다. 각 팀 간에 많은 상관관계가 있음을 알 수 있고, 이는 경영진에게 "보세요, 여기에 일종의 교차점이 있습니다"라고 말할 수 있는 전략적 엄밀함을 제공합니다. 만약 여러분이 한 부서 수준의 프로젝트에 자금을 지원한다면, 우리가 확인한 것과 비슷한 부분이 여기에도 있으니 이 두 프로젝트를 합치는 것이 더 나은 비즈니스적 판단입니다. 그러면 갑자기 그들이 돋보이게 됩니다. 방금 제가 제 멜빵을 당기는 시늉을 했는데, 제가 잘났다고 하는 게 아닙니다. 저는 시니어급의 면모를 보여주고 있는 것이고 그게 제가 일하는 방식입니다. 저는 많은 고위 임원들과 부서 책임자들을 위한 전략적 조언자로 일합니다. 우리는 그들이 돋보이게 하고 그들이 올바른 결정을 내릴 수 있도록 정보를 제공하고 싶습니다.

강력한 인간의 지원이 동반되는 관계적 경험에 대해 이야기해 봅시다. 대부분의 정부 조직이나 민간 조직은 "인간의 상호작용은 비용이 더 많이 드니까"라며 아주 잠깐만 인간의 손길을 닿게 하고 싶어 할 것입니다. 조직들은 사람들을 기술로 밀어내려 합니다. 기술로 유도하죠. 인간의 개입은 아주 조금이고 나머지는 모두 기술입니다. 하지만 인간이 정말로 원하는 것은 과정 전반에 걸친 지원입니다. 우리는 기술을 그 프레임워크를 제공하는 데 사용하고 싶습니다. 모든 것을 오로지 기술에만 의존하고 싶지는 않습니다. AI는 여러분이 항상 나누게 될 대화가 될 것입니다. "AI가 이걸 할 수 없나요?" 하지만 이 사실에 대해 굳건히 서는 것은 실무자인 우리에게 달려 있습니다. 관계적인 것은 거래적인 것과 다릅니다.

'서비스 비용(cost to serve)'에 대해 말씀드리기 시작하겠지만, 이것이 서비스 비용 모델의 기원입니다. 예전에 호주에서 아주 많은 불만과 아주 많은 데이터를 받고 있던 관행에 대해 작업하고 있었습니다. 그런 자료들이 의사 결정을 위해 고위 임원들에게 전달되고 있었지만, 아무런 변화가 없었습니다. 그래서 저는 '고통의 벽(wall of pain)'이라는 프레임워크를 만들었습니다. 각 문제들을 조직에 미치는 비용, 즉 '방치의 비용(cost of inaction)' 관점에서 시각화하는 것입니다. 거기에 도달하기까지는 약간의 노력이 필요했지만, "이런 문제들은 시간이 지나도 정체되어 있습니다"라고 차트 상단에 보여줄 수 있습니다. 그리고 "사실 저것 때문에 방치의 비용 측면에서 한 달에 25만 유로가 낭비되고 있습니다"라고 말할 수 있습니다. 또한 그것은 당신의 신뢰에도 영향을 미치고 있습니다. 거기서부터 저는 숨겨진 비용들을 실제로 파헤치기 시작했습니다. 비즈니스들은 원하는 비즈니스 경험을 만드는 데 많은 돈을 쓰기 때문입니다. "이것이 우리 고객들이 하길 원하는 것입니다." 하지만 저 밖의 빨간 선들에는 숨겨진 비용이 있습니다. 그 이탈의 비용, 인간 경험의 방황(meandering)에 대한 비용이 존재합니다. 제가 이것을 어떻게 하는지 조금 더 말씀드리고 싶습니다. 서비스를 진정으로 구성하는 요소들이 무엇인지 아는 것은 실무자인 우리에게 달려 있습니다. 서비스 비용 모델은 제품 관리 관점에서 존재해 왔지만, 일반적으로는 이렇게 틀이 짜입니다. 서비스 비용은 1년 동안의 총 서비스 비용을 상호작용 횟수나 고객 수로 나눈 것입니다. 그래서 서비스를 운영하는 데 50만 유로가 들고 백만 명의 고객이 상호작용한다면, 상호작용당 약 50센트입니다. 끝났죠, 그렇죠? 저는 이에 대해 끝까지 논쟁할 것입니다. 왜냐하면 비용은 보통 돈으로만 한정되기 때문입니다. 하지만 우리가 정말로 생각해야 할 비용에는 다른 많은 측면이 있습니다. 신뢰의 침식은 엄청난 것입니다. 현재 전 세계에서 그것을 볼 수 있죠. 평판의 비용이 있고, 기회비용이 있고, 문화적 비용이 있습니다. 직원들과 함께 일하면서 그들이 "아무도 보지 않고, 아무도 듣지 않아"라고 느끼는 것을 보게 될 때 말입니다. 우리는 그런 요소들도 반드시 고려해야 합니다.

그래서 서비스 비용 모델은 여정 지도 프레임워크를 사용합니다. 모든 핵심 주체, 각 상호작용에 드는 시간과 비용을 식별하고, 단일 수치에 도달합니다. 불법 쓰레기 투기 사건의 경우에는 50센트가 아니라 482유로에 가까웠습니다. 이 구글 시트가 필요하시면 나중에 저에게 오세요. 링크를 드릴 테니 접속하실 수 있습니다. 다시 돌아가서, 저는 그 서비스 비용을 많은 여정 지도에 집중하고 있는 정부의 서비스 아키텍처에 짜 넣습니다. 마크가 언급했던 신호등 시스템(traffic light system)을 제가 어떻게 식별할 수 있는지 보이실 겁니다. 저는 'Smapley'를 사용합니다. Smapley는 제가 선택한 도구입니다. 2013년부터 전 세계 정부에서 사용해 왔습니다. 제가 이를 강력하게 믿는 이유가 있습니다. 제 역량을 10배로 키워주는 최고의 도구 중 하나라고 생각하기 때문입니다.

이것이 제가 말하는 '요람에서 무덤까지' 아키텍처입니다. 이것은 아키텍처에서 가장 멀리 줌 아웃한 레벨이고, 여기 위에 있는 것들이 경영진이 선택한 핵심 서비스들입니다. 이를 조금 더 자세히 들여다보고 싶습니다. 줌 인해서 보면 여기에 약간의 교차점(crossover)이 있는 것을 보실 수 있습니다. 이 서비스와 저 서비스 사이에 교차가 있습니다. 여기서 우리가 본 것은 공공 주택 신청이었습니다. 공공 주택을 신청하러 가서 열쇠를 받게 되면 행복한 날이죠. 꽤 오랫동안 호텔 숙박 시설에서 살았을 수도 있는데, 가서 서류에 서명하면 그들은 "이제 임대료 설정을 위해 저쪽 다른 건물로 가셔야 합니다"라고 말합니다. 그러면 신청자는 "알겠습니다"라고 하고 밖으로 나가서 길을 잃고 다른 팀으로 걸어갑니다. 그러면 그들은 "그 서류 가져오셨나요?"라고 묻죠. "아니요, 다른 팀에 있는데요"라고 하면 신청자는 다시 건물을 가로질러 걸어가야 합니다. 저는 "이것은 기술 문제가 아닙니다. 이것은 업무 방식의 문제입니다"라고 생각했습니다. 우리가 여기서 식별할 수 있었던 것은 앞차 뒷차 같은 경험(bumper-to-bumper experience)이었는데, 사실은 교차 경험이 되어야 했습니다. 겹치는 경험이 있어야 했죠. 일종의 협업이 있어야 했습니다. 아키텍처는 때때로 이처럼 간단할 수 있습니다. "이봐요, 당신들 소통이 부족해요. 협업이 부족해요. 무슨 일이죠?"라고 말하며 전략적인 대화를 이끌어낼 수 있습니다. 그리고 그들을 협상 테이블로 불러냅니다. 우리는 너무 자주 기술이 구원자라고 말하지만, 때로는 그저 루틴을 설정하고 캘린더 초대를 보내는 것만큼 간단할 때가 있습니다. 다시 말하지만, 우리는 이것을 들여다봅니다. 방금 제가 말씀드린 내용이죠. 감사합니다. 그리고 우리는 그 모든 기회와 페인 포인트(pain points)에 대해 이야기하기 시작합니다. 시간이 얼마나 남았죠? Essa, 5분 정도 남았나요. 좋습니다. 자, 이제 혁신 포트폴리오에 대해 이야기해 봅시다.

이걸 보시죠. 우리는 모든 리서치를 마쳤고, 모든 여정을 살펴보았습니다. 이 시점에서 우리가 할 수 있는 일은 페인 포인트를 식별하고 기회를 식별하는 것입니다. 언어는 조직에서 잘못되는 핵심 사항 중 하나입니다. 서비스 아키텍처가 아주 좋은 예죠. 그래서 우리는 고객과 협력하여 언어와 그들이 측정하는 바가 이 작업에 반영되도록 합니다. Strategizer가 모든 템플릿에서 사용한다고 해서 제가 "이득(gains)과 고통(pains)이라는 용어를 씁시다"라고 말하는 건 제 역할이 아닙니다. 그런 말은 정부 조직에는 맞지 않습니다. 그래서 우리는 여기서 언어를 바꿨고, 이를 2x2 매트릭스로 정량화할 수 있었습니다. 빨간색은 많은 고통을, 파란색은 기회를 나타냅니다. 우리는 이것의 크기를 측정하고 의사 결정 프로세스에 엄밀한 대화를 제공할 수 있었습니다. 아직 완벽하지는 않습니다. 하지만 작년 이맘때 프로젝트를 시작했을 때와 지금을 비교하면 어떨까요? 더 나아졌을까요, 나빠졌을까요? 저는 우리가 12개월 전보다 훨씬 더 좋은 위치에 있다고 주장하고 싶습니다. 그래서 우리는 이것을 세분화하여 단기, 중기, 장기의 지평(horizons)으로 매핑할 수 있었습니다. 그리고 그것은 리뷰 내의 실행 가능한 성과들로 통합되었습니다. 저는 저 이미지를 만드는 데 AI를 사용했습니다. 보고서 자체가 아니라 이미지만요. 확실히 해두죠.

현재 상황에 대해, 소위 '종군 기자 리포트(war story)' 같은 이야기를 들려드리겠습니다. 첼시 몰든(Chelsea Molden)을 아시나요? 뉴욕 공공 정책 연구소(public policy lab)의 디렉터입니다. 제가 팟캐스트를 한다고 말씀드렸죠? 스포티파이와 애플에서 구독해 주세요. 이 대화는 아마 2~3주 후에 공개될 텐데, 저는 첼시와 큰 대화를 나누었습니다. 제가 팟캐스트를 해서 정말 다행이라고 생각합니다. 저라고 모든 답을 다 아는 건 아니니까요. 제가 앉아서 "첼시, 제가 지금 이런 프로젝트를 하고 있는데요, 당신이라면 그걸 어떻게 처리하겠어요?"라고 물으면 그녀는 저에게 조언을 해주고, 저는 그 조언을 제 팟캐스트 커뮤니티에 공유합니다. 제가 발견한 핵심 사항 중 하나는 고객과의 상호작용과 지원을 유지하고 싶지만 예산이 말라버렸다는 것이었습니다. 그래서 프로젝트의 50%는 실행(doing)에, 나머지 50%는 구현(implementation)에 할당해야 한다는 것을 배웠습니다. "다시 회의를 해서 이건 서비스 아키텍처고 우리가 이걸 왜 하는지 설명해야 합니다"라고 말해야 하는 그런 험난한 과정들이 있는데, 계약이 끝났기 때문에 제가 그 회의에 들어갈 수가 없습니다. 이것은 큰 부분이며 제가 앞으로 제 업무에 다시 반영할 부분입니다.

이번 프로젝트에서 무엇이 잘 되었을까요? '대신 해주는 것(done for)'이 아니라 '함께 하는 것(done with)'은 지방 정부와 정부 일반에 정말 환상적인 방식입니다. 교육을 병행하는 것은 정말 강력합니다. 제가 떠날 때 프로젝트가 성공할 가능성이 더 커진다는 것을 알기 때문입니다. 통합된 온디맨드 학습도 마찬가지입니다. 단순히 하루짜리 교육 이벤트를 열고 떠나면서 그들이 다 알기를 기대하는 것으로는 부족합니다. 제가 모든 참가자에게 영상 강의를 제공하는 이유입니다. 매주 코칭 세션을 갖는 것도 매우 효과적입니다. 어떤 때는 참석하고 어떤 때는 안 하지만, 선택 사항입니다. 집중 분야를 넘어선 리서치는 항상 보상을 줍니다. 작은 영역 안에만 머무는 것은 탑 태스크가 제공하는 엄밀함을 가지고 밖으로 나가는 것만큼 보람차지 않습니다.

하지만 여러분이 듣고 싶어 하시는 부분, 무엇이 잘 안 되었는지에 대해서도 말씀드리겠습니다. 휴가 시즌의 리듬이 항상 저를 힘들게 하더군요. "그 프로젝트는 2주 안에 못 해요"라고 하면 그들은 돌아와서 "네, 6월입니다. 다음 워크숍은 10월이에요"라고 말하죠. 전 "아, 그건 좋지 않네요"라고 생각합니다. 그것이 문제입니다. 그리고 저는 여전히 그것을 해결하려고 노력 중입니다. 추가 예산에 대해 더 일찍 깃발을 올렸어야 했습니다. 우리는 여전히 이 프로젝트를 계속하기 위해 기다리고 있습니다. 아직도 결과물을 걸어둘 벽이 없습니다. 분산된 도구를 쓰면 된다, 'Mural'을 써라, 'Smapley'를 써서 여정 지도를 어디든 걸어라 하는 논쟁은 이제 끝났습니다. 우리는 사무실로 돌아왔습니다. 일주일에 2~3일이라도 우리는 우리가 작업 중인 것을 보여주어야 합니다. 여전히 거기서 회의를 해야 하는데 현재 그들에게는 벽면 공간이 없습니다. 말할 때는 너무 사소해 보이지만 정말 정말 중요합니다. 리더십의 변화도 있었습니다. 마지막으로, 탑 태스크는 조직 전체를 아우르는 일이기 때문에 '골치 아픈 문제(can of worms)'를 일으켰습니다. '좋은 의미의' 골치 아픈 문제이기도 합니다. 갑자기 리서치에 대한 대화를 나누게 되었으니까요. "우리가 이걸 알아내면 어떻게 될까요? 어떻게 대응할까요?" 이는 마크가 이야기했던 것과 아주 잘 연결됩니다. 이게 어떤 모습일지 미리 짐작하기보다는 전략적인 대화를 나눌 수 있게 해줍니다.
그게 전부입니다. 들어주셔서 정말 감사합니다.