(영상) 풀스택 서비스디자인 - 사라 드러먼드

서비스의 사용자 경험은 화면이나 터치포인트만으로 결정되는 것이 아니라 정책·기술·업무 프로세스·조달·재정·조직구조·인력·비즈니스모델 등 수많은 결정이 누적되어 만들어진다.
사라 드러먼드는 이를 서비스·인프라·조직·의도·문화라는 다섯 층위의 ‘풀스택 서비스디자인’으로 설명한다.
서비스디자이너는 사용자 여정을 그리는 데 머물지 말고 서비스가 실제로 작동하게 만드는 수면 아래의 구조까지 진단해야 한다.
특히 기존 조직에서 이루어지는 대부분의 서비스디자인은 이미 만들어진 정책과 시스템 위에서 일하는 ‘브라운필드’이므로, 기존의 제약을 주어진 조건이 아니라 변화 가능한 디자인 대상으로 보아야 한다.
결국 좋은 서비스디자인은 사용자에게 보이는 경험을 개선하는 것을 넘어 그 경험을 만들어내는 조직과 시스템 자체를 변화시키는 일이다.

 

풀스택 서비스디자인

Sarah Drummond | 사라 드러먼드
출처 : Service Design Book Club
2024. 7. 12.
원본 영상 : https://www.youtube.com/watch?v=Un716sOtt8c
전체 번역 : 챗GPT로 번역했습니다. 생략, 오역이 있을 수 있으니 원본 영상을 봐주세요.

 

사라 드러먼드(Sarah Drummond)는 영국의 대표적인 서비스디자인 실무가이자 디자인 전략가이다.
2009년 로런 커리(Lauren Currie)와 함께 스코틀랜드에서 서비스디자인 컨설팅 기업 Snook을 공동창업해 공공서비스, 보건·사회복지, 시민참여와 디지털 전환 분야의 프로젝트를 이끌었다. 이후 2019~2021년 NEC UK 최고디지털책임자(CDO)를 지냈으며, 현재는 좋은 서비스를 디자인하고 운영하는 방법을 교육하는 School of Good Services와 영화·창작 스튜디오 Anthro Bricolage를 운영하고 있다. 
그의 관심은 서비스디자인 방법론 자체보다 조직이 실제로 좋은 서비스를 만들어낼 수 있는 조건에 가깝다. 정책, 조달, 기술, 조직구조, 재정, 권한, 조직문화까지 서비스의 구성요소로 바라보는 Full Stack Service Design 모델은 이러한 관점을 집약한 것이다. 사용자에게 보이는 경험 뒤에 숨어 있는 조직과 시스템을 서비스디자인의 대상으로 확장했다는 점에서 특히 공공서비스디자인과 정책디자인에 의미가 크다.
드러먼드는 MyPolice, CycleHack, Dearest Scotland, The Matter 등 사회혁신 프로젝트도 공동창립했으며, 기술과 민주주의 분야의 활동으로 Google Fellowship을 받았다. 2019년에는 디자인 분야에 대한 공헌을 인정받아 Glasgow School of Art 명예박사를 받았으며, 스코틀랜드 정부가 임명하는 Loch Lomond & The Trossachs National Park 이사회 멤버로도 활동하고 있다.

---

도입

사라 드러먼드

좋습니다. 여러분, 안녕하세요.
이 자리에 오게 되어 정말 기쁩니다.
저는 사실 토론토에 굉장한 친밀감을 느낍니다.
제 조부모님이 1951년에 스코틀랜드에서 토론토로 이주하셨고, 어머니도 그곳에서 태어나셨습니다.
그러다가 다시 돌아오셨죠.
그래서 토론토에는 미안한 일이지만, 토론토는 제가 세상에서 가장 좋아하는 도시 중 하나이고 특별한 유대감을 느끼는 곳입니다.
물론 오늘은 여러 지역에서 많은 분이 참여하고 있다는 것을 알고 있습니다.
제가 학교에서 진행했던 과정에 참여했던 분들도 몇 분 계신 것 같습니다.
그래서 오늘 이야기 중 일부가 반복된다면 미리 양해를 구하겠습니다.
그래도 북클럽이라는 공동체적인 느낌을 함께하기 위해 오셨으리라 생각합니다.
오늘은 비교적 빠르게 이야기하려고 합니다.
사실 제가 여러분에게 묻고 싶은 질문이 더 많기 때문입니다.
제가 던지는 질문을 바탕으로 여러분이 서로 이야기하는 것을 듣는 데 더 관심이 있습니다.
사실 이 자리에 있는 것이 조금 사기꾼 같은 기분도 듭니다.
이것은 책이 아닌데 행사의 이름은 북클럽이니까요.
언젠가는 책을 쓸 생각이 있습니다.
하지만 에런이 말했듯 지금은 영화감독 일을 병행하면서 영화감독이 되려고 하고 있어서 조금 바쁩니다.
오늘 말씀드릴 내용 중에는 앞으로 그 책에서 좀 더 깊이 다루고 싶은 이야기들도 포함되어 있습니다.
「Full Stack Service Design」은 상당히 긴 글입니다.
일종의 유용한 툴킷이 되기를 바라며 쓴 글입니다.

[왜 풀스택 서비스디자인인가]

제가 왜 이 글을 썼는지 먼저 말씀드리고 싶습니다.
저는 제 회사인 Snook에서 일하면서, 또 업계 전반을 바라보고 여러 디자이너를 코칭하면서 몇 가지 현상을 발견했습니다.
많은 서비스디자이너가 자신의 작업이 실제로 실행되지 않는 데 상당한 좌절감을 느끼고 있었습니다.
또 서비스디자인을 조직 내부로 들여오기 위해 상당한 투자가 이루어지는 흐름도 보았습니다.
하지만 서비스디자이너들은 실패할 수밖에 없는 환경에 놓이는 경우가 많았습니다.
그들의 업무가 별도의 팀이나 부서 안에 고립되어 있거나, 정말 좋은 서비스를 디자인하기 위해 실제로 무엇이 필요한지 제대로 이해되지 않았기 때문입니다.
그래서 우리의 실무는 종종 아주 좋은 사용자 조사를 바탕으로 ‘서비스가 이렇게 되어야 한다’는 일종의 이상적인 미래상을 그려내는 작업 정도로 분류되곤 했습니다.
저는 이런 실패와 좌절이 상당히 많이 일어나는 것을 보았습니다.
그래서 사람들이 일종의 지도, 또는 새로운 관점을 가질 수 있도록 하는 글을 쓰고 싶었습니다.
디자인이 어디에서, 어떻게 일어나는지를 볼 수 있도록 시야를 열어주고 싶었습니다.
서비스를 더 낫게 변화시켜 사용자 필요를 더 잘 충족하고, 조직의 성과를 더 잘 달성하며, 지구를 위해서도 더 나은 일을 할 수 있는 지점이 어디인지 이해하도록 돕고 싶었습니다.
그리고 그런 변화가 어디에서, 어떻게 일어날 수 있는지를 이해하게 하고 싶었습니다.
이 글을 쓸 때 제가 무언가 획기적인 것을 쓰고 있다고 생각하지는 않았습니다.
지금도 전혀 그렇게 생각하지 않습니다.
하지만 다양한 관점에서 서비스를 어디에서 변화시킬 수 있는지를 볼 수 있도록 여러 방법을 하나로 모은 ‘지도’가 있다면 유용하겠다고 생각했습니다.

이 글은 결국 제가 지금까지 경험한 것들의 집약이기도 합니다.
저는 제 경력에서 정말 운이 좋았습니다.
Snook이라는 에이전시에 참여했고, 믿기 어려울 만큼 다양한 훌륭한 프로젝트를 수행할 수 있었습니다.
하지만 무엇보다 그 일을 하면서 여러 조직과 나누었던 대화가 중요했습니다.
조직이 서비스를 제공하면서 어떤 문제를 겪는지, 사용자에게 제대로 작동하면서 동시에 조직의 목표에도 부합하게 만들기 위해 어떤 어려움을 겪는지를 볼 수 있었습니다.
그 문제들이 어디에 존재하는지 듣게 되었습니다.
조달의 차원에 문제가 있는 것인지, 조직의 미션에 문제가 있는 것인지, 조직이 가진 역량의 문제인지 등을 볼 수 있었습니다.
그런 경험을 할 수 있었다는 것은 정말 큰 행운이었다고 생각합니다.
그리고 경력이 쌓인 뒤에는 몇몇 큰 자선단체의 이사회에도 참여했고, Settle 같은 작은 자선단체에도 참여했습니다.
보건 분야에서도 일했습니다.
또 NEC라는 매우 큰 기술기업에서 CDO, 즉 최고디지털책임자 역할을 맡기도 했습니다.
이사회 회의실에 앉아 서비스에 관한 의사결정이 실제로 어떻게 이루어지는지를 보는 것은 제게 정말 흥미로운 경험이었습니다.
그래서 풀스택 서비스디자인은 결국 제가 누릴 수 있었던 하나의 특권에서 나온 결과물이라고 생각합니다.
저는 조직의 최전선부터 이사회 수준에 이르기까지 정말 다양한 층위와 관점에서 일할 수 있었습니다.

그러면서 이런 생각을 했습니다.
‘내가 지금 다시 젊은 디자이너가 되어 이 업계에 처음 들어온다면 무엇을 갖고 싶을까?’
저라면 분명 「Full Stack Service Design」 같은 글을 읽고 싶었을 것입니다.
서비스가 어떻게 이루어져 있는지 아주 빠르게 이해하는 데 도움이 되었을 것이기 때문입니다.
글에서도 이야기했지만 자동차 정비사는 자동차를 아주 빠르게 읽어냅니다.
무엇이 작동하지 않는지, 무엇이 작동하는지 파악합니다.
엔진의 문제인지, 바퀴의 문제인지, 타이어 공기압의 문제인지 등을 빠르게 이해합니다.
서비스디자이너에게도 그와 비슷한 것이 필요하다고 생각했습니다.
이러한 지식을 빠르게 습득할 수 있도록 해주는 일종의 도구인 것입니다.

여기 보이는 이미지는 일부러 픽셀이 깨진 이미지를 사용했습니다.
제가 처음 제품디자인을 공부하던 시절에는 물건을 분해해서 시각화하고, 그것이 어떤 재료로 이루어져 있는지 이해하는 과제를 하곤 했습니다.
여기 있는 것은 제가 2002년쯤 만들었던 아주 초기 작업입니다.
자물쇠를 분해해 그린 도면과 CAD 버전입니다.
풀스택 서비스디자인에서 제가 하려고 했던 것도 서비스의 ‘분해도’를 만드는 것이었습니다.
서비스를 이루는 서로 다른 재료가 무엇인지 사람들이 이해할 수 있도록 하고 싶었습니다.

그리고 제가 강조하고 싶었던 것은 서비스디자인에는 정말로 ‘그린필드(greenfield)’가 존재한다는 점입니다.
여러분의 경력에서 그런 기회를 얻게 된다면 꼭 붙잡으십시오.
예를 들어 정부나 공공부문을 생각해봅시다.
사용자의 필요를 충족하고 사람들이 풍요로운 삶을 살 수 있도록 정책을 만드는 데 참여할 기회를 얻었고, 그 아래에 여러분이 어쩔 수 없이 기반으로 삼아야 하는 낡고 형편없는 기술도 없다면 그 기회를 두 손으로 붙잡으십시오.
처음부터 시작할 수 있는 그린필드는 정말 놀라운 기회입니다.
하지만 대부분의 서비스디자인은 거의 언제나 ‘브라운필드(brownfield)’입니다.
이미 존재하는 수많은 것 위에서 일해야 합니다.
그 ‘것들’이 바로 제가 글에서 설명한 여러 구성요소입니다.
사용하기 어려운 기술 위에서 서비스를 만들어야 할 수도 있습니다.
조직이 이미 그 서비스에 적용해 놓은 측정기준 위에서 작업해야 할 수도 있습니다.
그런 것들 위에서 일하는 것은 상당히 어렵습니다.
하지만 서비스디자이너는 대부분 그런 상황에서 일해야 합니다.

여기서 잠깐 한 가지를 돌아보고 싶습니다.
제가 코칭했던 많은 사람은 언제나 위 어딘가에 있는 ‘나쁜 사람’을 지목하곤 했습니다.
그 사람이 형편없는 서비스를 만들었거나 잘못된 결정을 내렸다는 것입니다.
하지만 저는 어떤 한 사람이 아침에 일어나면서 ‘오늘은 사람들에게 정말 나쁜 서비스를 만들어야지. 제대로 작동하지 않게 해야지’라고 생각한다고 보지 않습니다.
저는 이 이야기를 할 때 자주 영화 「나, 다니엘 블레이크(I, Daniel Blake)」를 떠올립니다.
놀라운 감독 켄 로치(Ken Loach)가 만든 영화입니다.
그는 영국의 실제 삶을 바탕으로 훌륭한 영화를 만들면서 우리가 살아가는 현실을 거울처럼 보여주는 감독입니다.
영화는 여기 왼쪽에 보이는 다니엘 블레이크라는 남자의 이야기입니다.
그는 기술직 노동자였지만 심장질환이 생기면서 일을 그만두고 영국의 복지급여를 신청해야 하는 상황에 놓입니다.
영화에서 우리는 그가 복지급여 시스템과 상호작용하면서 엄청난 어려움을 겪는 모습을 보게 됩니다.
그런 일이 생기는 데에는 여러 이유가 있습니다.
상당히 가슴 아픈 이야기입니다.
이 영화를 풀스택 관점에서 보면 한 사람이 단 하나의 나쁜 결정을 내려 사람들이 이용하기 극도로 어려운 시스템이 만들어진 것이 아니라는 점을 알 수 있습니다.
정책, 기술, 성과 측정과 인센티브 등 수많은 서로 다른 결정이 누적된 결과가 바로 그 사용자가 경험하는 서비스입니다.
어느 한 사람의 잘못이 아닙니다.
여러 요소로 구성된 하나의 시스템인 것입니다.

[대문자 D의 디자인(Capital D Design)]

저는 이런 생각도 자주 합니다.
제가 ‘대문자 D의 디자인’이라고 부르는 공식적인 디자인 프로세스에서 디자이너가 제품이나 서비스를 처음 디자인하거나 기존 것을 개선하기 시작할 기회를 얻었을 때는 이미 그 이전에 엄청나게 많은 결정이 내려져 있습니다.
그중 일부는 유용한 제약일 수도 있습니다.
하지만 상당수는 다루기 어려운 제약이며, 우리가 그 위에서 작업해야 하는 브라운필드의 재료들입니다.
그리고 이미 내려진 수많은 결정이 서비스의 성과와 우리가 만들어내는 사용자 경험에 영향을 미칩니다.
이러한 결정은 우리가 워크숍을 하거나 컴퓨터 화면 앞에서 디자인하는 것과는 다른 장소에서 이루어지는 경우가 많습니다.
이사회 회의실에서 결정됩니다.
일선 현장에서 결정됩니다.
정책을 어떻게 디자인하느냐에 따라 결정됩니다.
기술을 어떻게 조달하느냐에 따라 결정됩니다.
이 모든 결정이 서비스와 사용자 경험에 영향을 미칩니다.

아직 「나, 다니엘 블레이크」를 보지 않았다면 꼭 한번 보시기 바랍니다.
켄 로치는 제가 가장 좋아하는 감독이고 정말 훌륭한 영화입니다.
영화에는 다니엘 블레이크가 구직수당을 신청하기 위해 화면에서 GOV.UK 디자인 시스템의 일부와 상호작용하면서 어려움을 겪는 장면이 나옵니다.
그가 마우스를 화면 아래로 끌려고 하고, 상자가 제대로 작동하지 않으면서 이상한 소리가 나는 장면이 있는데 상당히 보기 괴롭습니다.
저는 그 영화를 실제로 그 디자인을 만들었던 사람들과 함께 본 적이 있습니다.
그들은 제가 이 업계에서 만난 사람 중 가장 뛰어나고 경험 많고 유능한 디자이너들입니다.
그 서비스의 해당 터치포인트 자체는 접근성이 매우 뛰어납니다.
콘텐츠디자인도 훌륭합니다.
사용 흐름도 정말 잘 만들어져 있습니다.
하지만 그 터치포인트가 디자인되기까지 앞서 내려진 수많은 결정과 제약 때문에 결국 사용자가 원하는 결과에 도달하기가 매우 어렵습니다.
바로 그렇기 때문에 저는 풀스택 서비스디자인을 생각하기 시작했습니다.

여기 이 그림은 별로 좋은 다이어그램은 아닙니다.
하지만 제가 글을 쓰기 훨씬 전부터 풀스택 서비스디자인을 설명할 때 사용하던 방식입니다.
우리 업계와 전문영역은 지금까지 빙산의 수면 위에 보이는 부분에 주로 집중해 왔습니다.
사용자 여정을 생각합니다.
사용자 경험을 생각합니다.
터치포인트가 잘 작동하도록 합니다.
서비스 흐름이 작동하도록 합니다.
사용자가 원하는 결과에 도달하도록 만듭니다.
이 모든 작업은 반드시 필요하고 매우 중요합니다.
그러나 우리가 흔히 작업하지 못하거나 볼 수조차 없는 수면 아래의 요소들과 분리해서 존재할 수는 없습니다.
물론 우리가 그런 요소들을 전혀 다루지 않는다는 뜻은 아닙니다.
많은 서비스디자인 프로젝트가 실제로 풀스택 수준에서 작업하고 있습니다.
하지만 업계 전체를 보면 상당한 양의 작업이 여전히 빙산의 위쪽에 집중되어 있습니다.
그래서 저는 「Full Stack Service Design」을 빙산 전체를 둘러볼 수 있는 일종의 지도이자, 서로 떨어져 있는 것들을 연결해주는 방법으로 쓰고 싶었습니다.

[핵심 질문]

아마 여러분 대부분이 이미 글을 읽으셨을 테니 여기서는 빠르게 넘어가겠습니다.
저는 이와 관련한 대화를 나누는 데 훨씬 관심이 있습니다.
서비스 자체를 장황하게 설명할 필요는 없겠습니다.
하지만 이 글을 쓰면서, 그리고 언젠가 책을 쓰게 된다면 특히 중요하게 다루고 싶은 것이 하나 있습니다.
각각의 층위에서 제가 던지는 핵심 질문입니다.
각 층위에서 어떤 결정이 내려졌고, 그 결정이 최종 서비스나 최종 사용자 경험에 어떤 영향을 미치는지를 이해하기 위해 사용하는 질문입니다.
여기 있는 질문들은 매우 단순하지만 가장 많은 것을 드러내는 질문들이기도 합니다.

저는 서비스의 리더이거나 서비스에 대해 어느 정도 의사결정 권한을 가진 사람들에게 이런 질문을 자주 합니다.
그런데 대부분의 경우 이사회나 경영진은 서비스가 실제로 달성하려는 결과가 무엇인지 명확하게 답하지 못합니다.
서로 다른 사용자의 필요가 무엇인지도 답하지 못합니다.
사용자가 실제로 누구인지도 정확하게 답하지 못합니다.
자신들의 서비스가 정확히 무엇인지조차 명확하지 않은 경우도 있습니다.
그래서 저는 서비스디자인이나 사용자 경험디자인으로 들어가기 전에 상당히 높은 수준에서 우리가 실제로 무엇을 제공하고 있는지를 이해하는 작업부터 하는 경우가 많습니다.
그 서비스가 조직이 무엇을 이루도록 돕는 것인지, 그리고 사용자가 무엇을 할 수 있도록 돕는 것인지에 대해 명확한 개념을 갖도록 합니다.

좋은 서비스를 만들어 사람들에게 제대로 작동하게 하는 것이 어려운 이유 중 하나는 서비스가 정말 눈에 보이지 않기 때문이라고 생각합니다.
서비스가 보이지 않는다면 풀스택 수준에서 작업하기가 매우 어렵습니다.
조달 방식, 측정 방식, 조직이 가진 역량 등에 관한 결정이 서비스에 어떤 영향을 미치는지를 사람들에게 이해시키기도 어렵습니다.
애초에 서비스 자체를 볼 수 없고 그것이 무엇을 하는 것인지 명확하지 않다면, 수면 아래에서 이루어지는 여러 결정과 서비스를 연결하기가 매우 어렵습니다.
그래서 저는 서비스가 실제로 무엇을 하려고 하는지, 어떤 결과를 만들어내려고 하는지를 명확하게 하는 일을 매우 중요하게 생각합니다.
이 부분을 길게 설명하지는 않겠습니다.
이 자리에 계신 대부분이 서비스디자인 경험이 상당히 있다는 것을 알고 있습니다.
중요한 것은 결과가 무엇인지 명확히 하는 것입니다.
사용자가 그 결과에 도달하도록 돕는 데 누가 관여하는지 명확히 합니다.
그리고 사람들이 그 결과에 어떻게 도달하는지를 구체적으로 파악합니다.
또 조직으로서 우리가 사용자가 궁극적인 결과에 도달하는 모든 단계와 과정을 소유하고 있는지, 아니면 그 과정 중 일부만 담당하고 있는지도 명확하게 구분해야 합니다.
그래서 풀스택의 서비스 층위에서는 우선 ‘이 서비스가 실제로 무엇인가’를 명확하게 하는 데 집중합니다.

[업무 프로세스]

업무 프로세스에 관해서도 저는 상당히 흥미를 느낍니다.
아마 여러분 중 많은 분도 서비스를 이용하면서 지나치게 복잡한 언어를 헤쳐나가야 했던 경험이 있을 것입니다.
업무 프로세스는 사용자에게 아주 직접적으로 드러날 수 있습니다.
저는 이 작은 프로젝트를 즐겨 사용하는 사례로 소개합니다.
현장 직원 한 명이 자신이 지원하는 사용자들을 위해 복잡한 업무 프로세스를 조금이라도 풀어내려고 시간을 들인 사례입니다.
그 사용자들은 다니엘 블레이크처럼 복지급여를 받아야 하는 사람들입니다.
지금 보여드리는 것은 뒤쪽에서 보라색 셔츠를 입고 있는 존이라는 사람이 만든 것입니다.
이것은 제가 영국에서 운영을 도왔던 ‘Systems Changers’라는 프로그램의 일부였습니다.
이 프로그램에서는 여기 보이는 것처럼 여러 현장 직원들을 모아 시스템디자인, 시스템 변화, 서비스디자인에 대해 약간씩 가르쳤습니다.
그리고 자신들이 일하는 시스템 안에서 직접 변화를 만들어보도록 했습니다.
존은 복합적이고 복잡한 지원 필요를 가진 사람들을 일선에서 돕는 사람입니다.
그가 이 프로그램 안에서 진행했던 디자인 프로젝트는 여러 종류의 복지급여를 신청할 때 거쳐야 하는 업무 프로세스의 복잡성을 풀어내는 것이었습니다.
저는 이 작업을 정말 좋아합니다.
한 사람이 복지급여를 받을 수 있도록 돕는 현장 직원의 관점에서 보면, 그 과정이 얼마나 복잡하고 얼마나 많은 서로 다른 언어로 이루어져 있는지를 잘 풀어 보여주기 때문입니다.
그는 여러 가지 매핑 도구를 이용해 그 과정이 어떻게 이루어지는지를 설명했습니다.
그리고 직접 작은 종이 안내물도 만들었습니다.
Microsoft Word에서 종이를 가로 방향으로 설정한 뒤 인쇄해서 접어 만들었습니다.
정말 훌륭한 작업입니다.
그는 전문 디자이너가 아닙니다.
하지만 사람들이 업무 프로세스를 더 쉽게 이해하도록 만드는 방법을 고민했습니다.
그래서 저는 서비스를 디자인할 때, 서비스 층위와 풀스택 관점에서도 조직이 가진 업무 프로세스를 살펴보고 이런 종류의 작업을 하는 데 관심이 있습니다.

시간을 조심해야겠네요.
이 부분들은 글에서 이미 보셨을 테니 빠르게 넘어가겠습니다.
저는 풀스택을 다섯 가지 층위로 나눕니다.
첫 번째가 서비스이고, 두 번째는 인프라입니다.
인프라에는 시스템, 기술, 데이터 등의 구성요소가 포함됩니다.
서비스 아래에서 작동하는 시스템과 기술은 서비스가 실제로 어떤 모습이 되고 어떻게 운영되는지를 크게 좌우합니다.
동시에 서비스의 심각한 장애지점이나 취약성을 만들어내기도 합니다.
필요할 때 서비스를 얼마나 신속하게 변화시킬 수 있는지에도 영향을 줍니다.

책에 넣고 싶은 사례가 정말 많습니다.
제가 자주 떠올리는 사례가 하나 있는데, 좋아하는 사례라고 하기는 어렵습니다.
좋은 이야기는 아니기 때문입니다.
영국에서 Excel 스프레드시트 때문에 한 대형 보건기관의 코로나바이러스 확진자 약 1만6천 건이 누락됐다고 알려진 사건이 있었습니다.
제가 이해한 바로는 정보를 계속 기록하던 스프레드시트가 기본적으로 셀 한계에 도달하면서 더 이상 데이터를 담지 못했던 것입니다.
그 기반 기술의 문제 때문에 서비스의 해당 부분 전체가 작동하지 않게 되었습니다.
그래서 서비스를 디자인할 때 저는 서비스가 실제로 무엇 위에서 작동하고 있는지를 여기저기 찔러보고 탐색하는 데 관심이 많습니다.
일종의 고고학자가 되어야 한다고 생각합니다.
서비스가 실제로 어떤 기반 위에서 운영되고 있는지 살펴봅니다.
그리고 그 지점에서 변화를 만들고, 시스템이 안전하고 보안성이 있으며 올바르게 작동하도록 해야 합니다.

최근에 접한 또 다른 사례도 하나 말씀드리고 싶습니다.
정확한 메모를 잠깐 확인하겠습니다.
포뮬러 원(F1)의 한 팀에 새로운 책임자가 들어왔을 때의 이야기입니다.
자동차의 여러 부품과 수리를 관리하던 팀이 Excel 스프레드시트를 사용하고 있었는데, 여러 차고에 흩어져 있는 부품을 관리하는 행이 7만7천 줄 이상이었다고 합니다.
이 때문에 신속하게 차량을 수리하고, 필요한 재고를 갖추고, 모든 레이스를 준비하는 것이 매우 어려웠습니다.
조직 전체가 이렇게 취약하면서도 지나치게 세부적인 도구 위에서 운영되고 있다고 생각하면 별로 합리적이지 않습니다.
그래서 저는 서비스디자이너가 어떻게 표면 아래로 내려가 ‘사실 이 문제는 시스템이나 데이터 수준에서 해결할 수 있는 것 아닐까?’라고 질문할 수 있을지 관심이 있습니다.
저는 기술과 관련해서 이런 시스템과 데이터의 층위에 관심이 있습니다.
시간을 충분히 확보하기 위해 이 부분은 넘어가겠습니다.

[조직 차원]

조직 차원의 층위도 있습니다.
이 층위는 아직 상당히 크게 느껴집니다.
풀스택에 관한 책을 쓰게 된다면 이 부분을 바꿀지도 모르겠습니다.
우리가 의사결정을 하기 위해 조직을 구성하는 방식은 서비스에 엄청난 영향을 준다고 생각합니다.
거버넌스도 포함됩니다.
언제, 어떻게 만나 의사결정을 하는지도 포함됩니다.

이것도 조금 우스운 사례입니다.
Ryanair가 고객들의 엄청난 수의 항공편을 취소해야 했던 일이 있었습니다.
조종사들의 휴가를 배정하는 적절한 프로세스가 없었기 때문입니다.
결국 서비스 전체가 무너졌습니다.
이것 역시 거버넌스 수준이나 내부 업무 프로세스 수준에서 무언가를 제대로 갖추지 못하면 서비스가 중단될 수 있다는 사례입니다.
직원들의 휴가가 지속적으로 제대로 운영되도록 만드는 것도 우리가 작업할 수 있는 영역입니다.
저는 이런 것들도 모두 서비스디자인의 일부라고 봅니다.

오늘 하나하나 모두 들어가지는 않겠습니다.
서비스에 자금을 조달하는 방식도 제가 특히 문제의식을 갖고 있는 부분입니다.
우리는 서비스의 연구개발을 시작하기 위해 흔히 자본적 지출(capital expenditure)을 투입합니다.
그런데 서비스가 디자인되거나 실제로 구축된 이후 지속적으로 개선하는 데 필요한 운영비용(operational expenditure)을 확보하는 경우는 매우 드뭅니다.
조직 차원에서 서비스를 어떤 방식으로 재정 지원할 것인지에 관한 결정은 서비스 자체와 지속적으로 개선할 수 있는 능력에 엄청난 영향을 미칩니다.
무엇을 조달하는지도 마찬가지입니다.
공급업체와 적절한 계약이 맺어져 있지 않거나 지속적인 개선이 가능하도록 계약을 구성하지 않는다면 그것 역시 장기적으로 서비스에 영향을 줍니다.
조직의 구조가 어떠한지, 어떻게 의사결정을 하는지, 누가 권력과 권한을 가지고 있는지도 각각 다른 방식으로 서비스에 영향을 미칩니다.

제가 정말 좋아하는 마지막 사례 중 하나는 네덜란드의 보건·돌봄 조직인 Buurtzorg입니다.
이 조직은 요스 더 블록(Jos de Blok)이라는 사람이 만들었습니다.
그는 원래 네덜란드에서 직접 돌봄 서비스를 제공하던 사람이었습니다.
몇 년 전 당시 그 분야의 상황은 사상 최악 수준이었습니다.
여러 조직에서 환자가 평가한 서비스 성과점수가 매우 낮았습니다.
병원에서 퇴원한 뒤의 회복 관련 성과도 좋지 않았습니다.
요스는 자신의 현장 경험을 바탕으로 먼저 서비스 내부를 새롭게 디자인하는 조직을 만들기로 했습니다.
저에게는 이 사례가 풀스택이라는 개념을 아주 생생하게 보여줍니다.

요스가 한 일은 일선의 간호사와 여러 돌봄 종사자에게 더 많은 교육을 제공하고 더 큰 의사결정 권한을 부여한 것입니다.
그 결과 의사가 여러 의사결정을 승인할 때까지 기다리지 않고 현장에서 스스로 판단할 수 있게 되었습니다.
이를 위해 직원들에게 더 많은 교육을 제공했습니다.
동시에 필요한 경우 의사와 이야기해 자신들의 결정과 제공할 돌봄을 승인받을 수 있는 체계도 마련했습니다.
이들이 제공하는 돌봄은 매우 다양합니다.
승인된 여러 종류의 약물을 제공하기도 합니다.
사람들이 샤워하는 것을 돕습니다.
병원에서 퇴원해 일상으로 돌아가는 것을 지원합니다.
음식을 만들기도 합니다.
정말 많은 일을 합니다.
하지만 때로는 의학적 판단이 필요한 상황도 있습니다.
그래서 일선 인력의 역량을 높이자 환자에게 필요한 처치를 훨씬 더 신속하고 효과적으로 제공할 수 있게 되었습니다.
조직도 대폭 분권화했습니다.
재정 투자의 더 많은 부분을 일선 인력에 투입하고 중앙 조직을 축소했습니다.
이것은 서비스디자인을 단지 사용자 경험 수준에서 바라보지 않고 수행한 사례입니다.
그 결과 Buurtzorg는 최근 몇 년간 네덜란드에서 가장 높은 평가를 받는 돌봄 조직이 되었습니다.
이 모델은 세계 여러 곳으로 확산되어 적용되고 있습니다.
지금 정확한 메모가 없는데, 제 기억으로는 이 방식이 환자가 지원을 필요로 하는 기간을 무려 3개월가량 줄였던 것으로 알고 있습니다.
병원에서 퇴원한 뒤 회복하는 과정을 빠르게 만들었기 때문입니다.
그 밖에도 잘 측정되고 근거가 확인된 여러 개선효과가 있었습니다.
이것은 서비스의 ‘역량’ 측면을 변화시킨 사례입니다.
다시 말하면 풀스택은 이런 요소들을 어떻게 바라보고 다루어야 할지 사람들이 이해하도록 돕기 위한 것입니다.

앞에서 잠깐 말씀드렸지만, 저는 또 다른 역할로 스코틀랜드의 Loch Lomond & The Trossachs National Park 이사회 멤버로 활동하고 있습니다.
저는 이 일을 정말 좋아합니다.
현재 우리가 하려고 하는 일 중 하나는 사람들이 국립공원 안에서 이동하는 방식을 새롭게 디자인하는 것입니다.
현재 기록상 국립공원 방문자의 95%가 아니라, 정확히 말씀드리면 92%가 자동차로 국립공원에 옵니다.
자동차 이용은 엄청난 양의 탄소배출을 만듭니다.
우리는 넷제로를 향해 가려고 하고 있습니다.
따라서 사람들이 국립공원을 이동하는 방식이 우리의 가장 큰 탄소배출원 중 하나입니다.
이를 줄이기 위해 지속가능한 교통시스템을 디자인하려고 하고 있습니다.
이를 위해 셔틀버스를 도입하는 것과 같은 여러 방법을 시도하고 있습니다.
머릿속으로 생각했을 때는 상당히 쉬운 해결책처럼 보였습니다.
적어도 처음에는 그렇게 생각했습니다.
그런데 지난 3년 동안 우리는 실제로 그 서비스를 도입하는 데 실패했습니다.
시스템 안에 이용 가능한 운전자가 부족했기 때문입니다.
실제로 지역에서 구할 수 있고 버스를 운전할 수 있는 자격까지 모두 갖춘 운전자 중 가장 젊은 사람이 62세였다는 이야기가 있었습니다.
따라서 서비스를 실제로 운영할 수 있는 역량과 인력이 시장에 존재하는지를 살펴보는 것이 정말 중요했습니다.
여름철 서비스를 조달하기 위해 필요한 리드타임 같은 것도 자세히 살펴봐야 했습니다.
이런 프로젝트에서는 사용자 경험 수준의 작업보다 훨씬 더 깊은 스택의 아래쪽에서 일하고 있는 것입니다.

기쁘게도 결국 사람을 구했습니다.
여기 사진에 있는 사람들이 운전자는 아닙니다.
이들은 우리의 청년위원회와 CEO입니다.
결국 셔틀버스를 확보했고 올해 실제 운행을 시작합니다.
하지만 새로운 서비스를 제공할 수 있는 상황을 만들기 위해 조달이라는 까다로운 문제와 시장에 필요한 역량이 존재하는지를 해결하는 데 3년이 걸렸습니다.
블로그 글에는 없는 작은 사례들을 몇 가지 보여드렸습니다.
책을 쓰게 된다면 이런 사례를 많이 넣고 싶습니다.
서비스가 실제로 이루어지도록 만들기 위해 우리가 어떤 질문을 해야 하는지를 사례를 통해 보여주고 싶습니다.
아주 짧게 한두 가지를 더 말씀드리고 마무리하겠습니다.

[의도(Intent)]

스택의 또 다른 층위는 ‘의도’입니다.
저는 이 부분을 굉장히 좋아합니다.
의도는 우리가 무엇을 디자인하고 있는지에 대한 방향을 결정하기 때문입니다.
예를 들어 우리가 디자인해야 하는 정책이 있다면, 정책은 사실상 서비스의 브리프와도 같습니다.
조직 안에 존재하는 가치와 윤리도 있습니다.
명시적으로 문서에 적혀 있을 수도 있고, 조직문화의 일종의 ‘암흑물질’ 속에 그냥 존재할 수도 있습니다.
하지만 제가 보기에는 서비스를 어떻게 디자인할 것인지에 가장 강력한 영향을 주는 것은 비즈니스모델입니다.
여러분에게 새로운 이야기는 아닐 것입니다.
하지만 서비스를 디자인할 때 우리가 더 적극적으로 들여다봐야 할 영역이라고 생각합니다.
서비스의 일부를 혁신할 수 있는 여지를 만들 때도 비즈니스모델의 관점에서 살펴봐야 합니다.

저는 늘 이 사례를 사용합니다.
제 강의에 참여하셨던 분이 있다면 죄송합니다.
이미 많이 들으셨을 것입니다.
Netflix와 수많은 주문형 영상 서비스가 등장하기 전에는 Blockbuster가 거리마다 있었습니다.
기억하신다면 매장에 가서 비디오카세트나 게임을 빌렸습니다.
그리고 늦게 반납하면 연체료를 냈습니다.
당시 Blockbuster의 연간 매출 중 연체료가 차지하는 비중은 16%였습니다.
그렇다면 회사가 서비스의 특정 요소에서 상당한 돈을 벌고 있는 상황에서 그 서비스를 제공하는 방식을 혁신할 유인이 크지 않습니다.

마지막으로 한 가지 이야기를 하고 싶습니다.
아까 보셨던 자물쇠의 분해도처럼 저는 세상의 모든 서비스를 보면서 계속 같은 방식으로 생각합니다.
항상 그렇게 세상을 호기심 있게 바라보는 것은 사실 꽤 피곤하고 성가신 일이기도 합니다.
하지만 어떤 서비스를 볼 때마다 저는 이렇게 생각합니다.
‘이것은 무엇으로 이루어져 있지?’
‘이 서비스의 스택은 무엇이지?’
언젠가 책을 쓰게 된다면, 그리고 누군가 그 책을 출판해준다면, 사람들이 이런 것에 흥미와 호기심을 갖도록 만들고 싶습니다.
여러분도 세상을 돌아다니다가 어떤 서비스를 만나면 한번 살펴보십시오.
‘저것은 어떻게 저기에 존재할 수 있게 된 것일까?’
‘저 서비스 뒤에 있는 비즈니스모델은 무엇일까?’
‘저것을 운영하려면 어떤 역량을 갖춘 사람들이 필요할까?’

저도 얼마 전에 읽고 처음 알게 된 사실인데 Costco를 한번 생각해봅시다.
제 메모를 확인하겠습니다.
제가 인터넷에서 본 내용이기 때문에 틀렸다면, 지금 녹화되고 있는 만큼 미리 사과하겠습니다.
인터넷에 있으니 일단 사실이라고 믿겠습니다.
Costco 수익의 80%가 매장에 들어가기 위해 내는 약 100달러의 회원비에서 나온다고 합니다.
말도 안 될 만큼 놀랍지 않습니까?
Costco가 판매하는 상품에서 얻는 이익이 주된 수익일 것 같지만 실제로는 회원비라는 것입니다.
굉장한 비즈니스모델입니다.
McDonald's를 보더라도 비슷합니다.
햄버거를 뒤집어 파는 것은 사실상 부동산 사업을 하고 있다는 사실을 가리는 외피에 불과하다는 이야기도 있습니다.
저는 이런 것들에 정말 큰 호기심을 느낍니다.
왜냐하면 이런 요소들이 서비스디자인 작업의 브리프를 결정하기 때문입니다.
우리가 처한 제약조건도 이런 요소들이 결정합니다.

풀스택에서 제가 특히 관심을 갖는 것은 이런 것들을 ‘주어진 제약’으로 보는 데서 벗어나 ‘디자인하고 영향을 미칠 수 있는 것’으로 바라보는 것입니다.
그리고 모든 사람이 어떤 방식으로든 디자인하고 있다는 사실을 인식하는 것입니다.
때로는 자신이 디자인하고 있다는 사실을 의식하지 못하고 있을 뿐입니다.
서비스디자이너로서 우리의 역할은 때때로 스택의 안쪽으로 더 깊이 들어가는 것일 수도 있습니다.
조달 담당자들과 함께 일하면서 이렇게 물을 수 있습니다.
‘이 파트너를 조달하는 방식을 바꿀 수 없을까요?’
‘현재 조달 방식이 서비스에 이런 영향을 주고 있습니다.’
또는 이렇게 말할 수도 있습니다.
‘이 서비스를 제대로 제공하려면 이 시장에 조금 더 많은 역량 개발이 필요합니다.’

여기에서 일단 멈추겠습니다.
사실 이 주제에 대해서는 제 안에 한 권의 책 정도 분량이 들어 있는 것 같습니다.
그래서 여러분에게 정말 묻고 싶습니다.
이것을 책으로 만든다면 흥미로울까요?
사람들이 이 프레임워크를 실제로 좀 더 쉽게 사용할 수 있도록 하는 몇 가지 도구에 대한 아이디어도 있습니다.
하지만 저는 오히려 여러분에게 묻는 것에 더 관심이 있습니다.
이 글을 읽고 무엇을 얻으셨습니까?
물론 철자 오류 몇 개를 발견했다는 것 말고요.
저도 몇 개 발견했습니다.
이 개념을 어디에서, 어떻게 적용해보셨습니까?
실제로 몇몇 분이 연락해서 ‘이것을 이런 방식으로 사용해봤다’고 이야기해주셨습니다.
그런 사례들을 정말 듣고 싶습니다.
그리고 이것이 책으로 나온다면 도움이 될까요?
에런이 이야기했듯 마지막에 약 25분 정도밖에 남지 않았습니다.
그래서 여러분의 이야기를 듣고 싶습니다.
질문에도 기꺼이 답하겠습니다.
다른 아이디어가 있다면 화면에 제 이메일 주소가 있으니 메일을 보내셔도 되고, 트위터나 LinkedIn으로 연락하셔도 됩니다.
아무래도 정말 책이 되어야 할 것 같네요.
벌써 20분이나 이야기했으니까요.
여기에서 멈추겠습니다.