(영상) 서비스디자인과 비즈니스 목표 사이의 잃어버린 고리 - 마크 하웰 서비스디자인쇼 Ep: 241

서비스디자인과 비즈니스 목표 사이의 잃어버린 고리 / 마크 하웰 / 에피소드 #241
원본 영상 : https://www.youtube.com/watch?v=3dSs5a4RkNM
2025. 11. 20.
출처 : 서비스디자인쇼
번역 : 제미나이 (요약, 생략된 부분이 있을 수 있습니다. 원본을 봐 주세요.)

 

마크 하웰(Mark Howell, PhD)은 BP에서 Global Director of Service Design을 맡았던 영국 기반의 서비스디자인 및 전략디자인 리더이다. 20년 넘게 다양한 산업에서 서비스디자인과 사용자조사를 이끌며, 복잡한 대규모 조직에 디자인 역량을 구축하고 성숙도를 높여왔다. 그는 서비스디자인을 조직이 지속적으로 작동할 수 있는 조건을 만드는 전략적 능력으로 바라보며, 여러 제품팀과 부서를 연결하는 ‘스팬너(spanner)’ 역할을 서비스디자이너에게 요구한다. 또한 CX와 시스템적 사고를 결합해 서비스디자인과 비즈니스 목표의 간극을 메우는 실용적 접근법을 강조한다. LinkedIn과 SDN 커뮤니티를 통해 대규모 조직 경험 기반의 통찰을 공유하며, 디자인 리더십·심리적 안전·포용적 조직문화 구축의 중요성을 꾸준히 제기하고 있다.
https://www.linkedin.com/in/markhowell-phd/

(유튜브 소개글)

서비스디자인 개척자들과의 인터뷰

서비스디자인, 그래서 뭐 어쨌다는 겁니까... 이것은 여전히 우리 주변의 많은 사람들이 (당연하게도) 묻는 질문입니다. 그리고 솔직히 말해서, 그들은 당분간 계속 그렇게 물을 것입니다. 우리 분야가 누구나 아는 이름이 되기까지는 아주 오랜 시간이 걸릴 것이고, 저는 과연 그렇게 될지 의심스럽기도 합니다.

이런 상황에 좌절하고 누군가 우리 일의 가치에 의문을 제기할 때마다 눈을 흘기기는 쉽습니다. 하지만 그런 좌절감은 우리가 만들 수 있다고 알고 있는 영향력을 창출하는 데 조금도 도움이 되지 않습니다. 훨씬 더 생산적인 접근 방식은 이러한 질문에 대비하고, 그들이 묻기도 전에 우리의 답변을 준비해 두는 것입니다.

이것은 또한 우리가 무슨 말을 하거나 어떤 행동을 해도 서비스디자인에 대한 우리의 메시지가 공감을 얻을 가능성이 거의 없는 상황에 처했을 때, 그 상황을 더 잘 인식하도록 도와줍니다. 우리가 이것을 인정함으로써 모두에게 도움이 됩니다. 때로는 그곳이 적절한 장소가 아니거나 적절한 때가 아닐 수도 있습니다.

그렇다면 어떤 이야기를 언제 누구에게 해야 하고, 어떤 이야기를 피해야 하는지는 어디서 배울 수 있을까요? 이번 에피소드의 게스트인 마크 하웰로부터 몇 가지 단서를 얻을 수 있습니다.

마크는 제가 들어본 것 중 가장 큰 규모의 인하우스 서비스디자인 팀을 이끈 베테랑 전문가입니다. 인간 중심적 사고로 알려지지 않은 산업군에서 이런 성과를 냈다는 점을 고려하면 이 업적은 더욱 인상적입니다. 우리는 대화 속에서 마크가 이해관계자들과 올바른 대화를 나누기 위해 서비스디자인 품질 평가와 같은 도구를 어떻게 사용했는지 탐구합니다. 우리는 그가 다른 프로젝트를 찾아야 할 때를 알리는 적신호(red flags)를 식별하는 법을 어떻게 배웠는지 이야기하고, 성공적인 서비스디자인 실행을 구축하는 데 있어 커뮤니티가 수행하는 핵심적인 역할에 대해 깊이 파고듭니다.

저는 이번 에피소드가 정말 기대되는데, 왜냐하면 서비스디자인 팀을 이런 규모로 확장한 사례가 많지 않기 때문입니다. 그리고 그 여정에서 얻은 실제 교훈을 기꺼이 공유하려는 사람은 더더욱 드뭅니다. 따라서 서비스디자인을 성장시키려는 야망이 있다면, 이번 대화는 모범 사례를 얻고 피해야 할 함정에 대해 들을 수 있는 환상적인 대화가 될 것입니다.

이번 대화에서 제 기억에 남는 것은 때로는 앞으로 밀고 나가는 대신(그러다 지쳐서 나가떨어지는 대신) 한 걸음 뒤로 물러나야 할 때가 있다는 것을 인식하는 것입니다. 여러분의 의견도 듣고 싶습니다. 여러분에게 핵심적인 신호는 무엇인가요? 밀어붙이는 것을 멈추고 다른 전투를 찾아야 할 때라는 것을 알려주는 단서는 무엇입니까?

즐겁게 시청하시고 계속해서 긍정적인 영향을 만들어가시기 바랍니다! ~ 마크

 

---

마크 폰테인 (사회자) 에피소드 241에 오신 것을 환영합니다. 안녕하세요, 제 이름은 마크이고 여기는 서비스디자인쇼 에피소드 241입니다. 우리 서비스디자인 전문가들이 끊임없이 스스로에게 물어야 할 간단한 두 단어짜리 질문이 있습니다. "그래서 뭐요(So what)?"

우리는 블루프린트를 만듭니다. 우리는 여정을 매핑합니다. 워크숍을 운영합니다. 그래서 뭐 어쨌다는 겁니까? 그게 고객에게 실제로 어떤 의미가 있습니까? 그리고 더 중요하게는, 비즈니스에 어떤 의미가 있습니까?

그 질문과 설득력 있는 답을 찾는 여정이 오늘 우리가 풀려고 하는 중심 퍼즐입니다. 그것은 우리의 프로세스를 설명하는 것을 넘어 마침내 조직의 나머지 구성원들이 이해하는 언어로 우리의 가치를 심어주는 것에 관한 것입니다.

안녕하세요, 이곳이 처음이시라면 서비스디자인쇼에 오신 것을 환영합니다. 우리는 이 분야의 가장 뛰어난 지성들을 초대하여 사람들의 공감을 얻고, 비즈니스를 앞으로 나아가게 하며, 우리 지구를 존중하는 서비스를 디자인하는 데 진정으로 필요한 것이 무엇인지 탐구합니다.

오늘의 게스트인 마크 하웰은 2년 동안 경영 컨설팅 분야에서 일했을 때 경력의 전환점을 맞이했습니다. 그곳에서 그는 디자인을 비즈니스 케이스, 전략, 수익성이라는 냉혹한 현실과 연결하는 법을 배웠습니다. 본질적으로 그는 서비스디자인이라고 부를 줄도 모르는 상태에서 이미 서비스디자인을 하고 있었던 것입니다.

디자인과 비즈니스 가치에 뿌리를 둔 그 경험은 대규모 팀을 이끄는 것부터 만족스러운 퍼즐 같다고 묘사하는 통나무 쌓기라는 놀랍도록 치료적인 취미에 이르기까지 그의 전체적인 접근 방식을 형성했습니다. 프론트 스테이지에 집중하던 디자인 실무자에서 전체 시스템을 이해하는 디자인 리더로의 여정은, 우리 자신의 이해관계자들을 위해 "그래서 뭐요(So what)?"라는 질문에 마침내 대답할 수 있는 방법에 대한 비판적인 관점을 그에게 부여합니다.

그래서 오늘 대화에서 여러분은 성숙도가 낮은 환경에서도 영향력을 발휘할 수 있는 실행 가능한 전략에 대해 배우게 될 것입니다. 프로젝트가 실패할 수 있다는 신호인 적신호를 감지하는 방법. 우리의 가치를 설명하는 데 따르는 어려움이 왜 종종 여러분이 아니라 시스템에 있는지. 지속 가능한 업무를 수행하고 회복 탄력성을 기르는 데 커뮤니케이션이 하는 중요한 역할. 그리고 여러분의 업무를 비즈니스 성과와 일치시키기 위해 반드시 가져야 할 하나의 대화에 대해 배우게 될 것입니다.

저에게 정말 인상 깊었던 것은 환영받지 못한다고 느낀 프로젝트에서 배제되었던 마크의 솔직한 이야기였습니다. 우리 중 많은 사람들이 겪어본 상황이라고 생각합니다. 우리가 변화를 만들 수 있다는 것을 알지만 조건이 맞지 않는 상황 말이죠. 진짜 과제는 언제 계속 밀어붙여야 할지, 그리고 언제 다른 전투를 찾아야 할지를 아는 것입니다.

마크와의 이번 대화에는 힘들게 얻은 지혜가 많이 담겨 있으니, 바로 시작해 보겠습니다. 끝부분에서 저의 개인적인 요점 정리와 함께 다시 뵙겠습니다. 제 이름은 마크 폰테인이고 여러분은 서비스디자인쇼를 청취하고 계십니다. 쇼에 오신 것을 환영합니다, 마크.

마크 하웰 (게스트)
감사합니다, 마크. 이 자리에 오게 되어 정말 기쁩니다.

마크 폰테인 (사회자)
우리가 서로를 이름(First name)으로 부르기 시작하면 이번 에피소드는 가장 헷갈리는 에피소드 중 하나가 될 것 같네요. 네, 여기 실제 마크와 또 다른 마크가 있으니까요. 재미있겠네요.

마크, 본격적으로 시작하기 전에 오늘 대화 내내 우리가 함께 풀려고 노력할 퍼즐에 대해 무대를 간단히 설정하고 싶습니다. 청취하시는 많은 분들이 이해관계자들과 회의 중이거나, 네트워킹 행사, 생일 파티 같은 곳에 있는 상황을 인식하실 겁니다. 어떤 통찰력이 생기거나 기회가 보여서 그것을 전달하려고 노력하는데, 상대방은 멍한 눈빛으로 우리를 쳐다보며 "무슨 일을 하시는데요?"라고 묻는 상황 말이죠.

저는 그것이 서비스 공간에 있으면서 가장 실망스러운 요소 중 하나라고 생각합니다. 우리는 단순히 일을 하고 실제로 가치를 창출하는 대신 우리가 하는 일을 설명하려고 노력하는 데 너무 많은 시간을 소비합니다. 저는 거의 10년 가까이 서비스디자인 공간에 있었습니다. 그리고 이것은 우리가 여전히 나누고 있는 대화입니다. 우리가 단지 답을 찾는 것이 아니라, 이것을 극복하고 실제 업무로 나아가기 위한 전략을 찾을 수 있을지 단서를 찾아보려고 합니다. 마크 님의 서비스디자인 경험이 분명히 도움이 될 것이라고 생각합니다.

마크, 만약 이것이 우리의 퍼즐이라면, 초기에 문제 공간을 탐색하고 들여다볼 때, 2025년 늦은 화요일 아침인 지금 우리가 여전히 우리가 하는 일을 어떻게 설명하고 어떻게 포지셔닝해야 하는지에 대해 대화하고 있다는 사실에 대해 어떻게 생각하십니까? 우리는 왜 여전히 여기에 있는 걸까요?

마크 하웰  
네. 답답할 수 있습니다. 그리고 저는 그것이 서비스디자인이 가져올 수 있는 가치로부터 정말로 주의를 딴 데로 돌리게 할 수 있다고 생각합니다. 사고방식, 도구, 방법론이 가치 있다는 것을 우리는 알고 있고 조직에 적용할 수 있는 잠재력을 볼 수 있지만, 사람들이 우리가 누구인지, 우리가 무엇을 하는지, 우리가 해결하는 문제가 무엇인지 빨리 파악하지 못한다면 우리는 다소 불필요한 존재가 될 위험이 있다고 생각합니다.

그래서 아마도 처음에 혼란스러운 것 중 하나는 서비스에 대해 이야기하는 것 자체라고 생각합니다. 제 말은, 서비스란 무엇이고 서비스가 제품(Product)과 어떻게 다른가 하는 것입니다. 그리고 저는 그것이 결국 토끼굴로 빠져드는 일이 되거나 그렇게 될 수 있다고 생각합니다. 사실 그런 대화는 하고 싶지 않을 겁니다. 여러분은 여러분이 무엇을 할 수 있는지 알고 있습니다. 여러분이 가져올 수 있는 것의 가치를 알고 있습니다.

그런데 제품 디자이너는 이런 일을 하고, 서비스디자이너는 이런 일을 한다는 대화에 갇히게 됩니다. 약간의 겹치는 부분이 있습니다. 하지만 우리는 발견과 디자인이라는 디자인 프로세스 전반에 걸쳐 상호 보완적인 기술 세트를 가지고 있습니다. 그리고 조직에 들어오면 서비스디자인이 어디서 시작하고 끝나는지, 제품 디자인은 어디서 시작하고 끝나는지, 서비스디자이너는 ITIL 서비스디자이너와 어떻게 다른지에 대한 질문이 있습니다.

저는 서비스디자인이 전혀 없었지만 ITIL 서비스디자이너는 있었던 조직들에 있어 본 적이 있습니다. 그들은 기술적인 서비스디자이너에 더 가깝지만 서비스디자이너라고 불립니다. 그래서 조직에 들어가면 모두가 당신을 그런 사람 중 하나라고 생각합니다. 하지만 당신은 아닙니다. 당신은 휴먼 센터드(인간 중심) 서비스디자이너입니다. 그리고 다시 한번, 당신은 "좋아요, 이게 우리가 다른 점입니다"라고 말해야 합니다.

그리고 저는 최근 조직 중 한 곳에서 처음 일을 시작했을 때 휴먼 센터드 서비스디자이너로서 우리가 하는 일과 ITIL 서비스디자이너가 하는 일의 차이점을 나란히 매핑하는 사이드 프로젝트를 진행하기도 했습니다. 왜냐하면 유사점이 있기 때문입니다. 우리 둘 다 서비스를 개선하려고 노력하고, 때로는 기술 서비스를 개선하려고 하지만, 매우 다른 접근 방식을 취합니다.

그래서 직함에 갇히게 됩니다. 그리고 그렇게 되면, 그것은 단지 당신이 왜 거기에 있고 당신이 가져올 수 있는 가치가 무엇인지에 대한 주의를 산만하게 할 뿐이라고 생각합니다. 그래서 네, 아마도 이름에 문제가 있을 수도 있습니다. 그냥 이름 때문일 수도 있죠.

저는 요즘 그냥 고객 경험(Customer Experience)에 대해 이야기하는 편입니다. 서비스디자인은 도구와 방법의 집합이고 우리는 그것을 고객과 동료의 경험을 개선하기 위해 적용합니다. 그러면 바로 고객 경험에 대해 이야기하게 되고 그것은 사람들이 이해하는 것입니다.

마크 폰테인
방금 말씀하신 내용으로 잠시 돌아가 보겠습니다. 서비스와 제품의 차이를 이해하는 것, 서비스디자인 또는 휴먼 센터드 서비스디자인과 ITIL 서비스디자인의 차이를 이해하는 것 말이죠. 누군가는 이렇게 주장할 수 있습니다. "이봐요, 우리는 이걸 알아내기 위해 20년이 넘는 시간을 보냈어요. 우리는 이미 그 질문들에 대답하지 않았나요?" 만약 대답하지 못했다면, 지난 20년 동안 그 문제를 해결하지 못했는데 결국 해결할 수 있을 것이라고 확신하는 이유는 무엇입니까?

마크 하웰
저는 우리가 내부적으로는 그 문제를 해결했다고 생각합니다. 즉, 서비스디자이너들 사이에서는 말이죠. 그들은 이 질문에 대한 답을 알고 있습니다. 그래서 저는 ITIL 서비스디자이너와 휴먼 센터드 서비스디자이너의 차이를 알고 있습니다. 저는 서비스디자인과 제품 디자인, 사용자 리서치가 어디서 역할을 하는지에 대한 관점을 가지고 있습니다.

하지만 우리는 사람들이 디자이너와 한 번도 일해본 적이 없는 조직으로 들어가고 있습니다. 그리고 그들은 디자인의 세분화에 대해 신경 쓰지 않을 수도 있습니다. 그들은 콘텐츠 디자이너, 서비스디자이너, 제품 디자이너, 사용자 리서처가 왜 필요한지에 대해 너무 많이 알고 싶어 하지 않습니다. 그들은 단지 해결하고 싶은 문제가 있을 뿐입니다.

그리고 매우 기술 중심적이거나 제품 여정(journey)의 초기 단계에 있는 대규모 조직들이 있습니다. 어쩌면 그들은 최근에야 프로덕트 운영 모델을 도입했고, 서비스보다는 제품 관점에서 많이 생각하고 있을 수도 있습니다. 여정의 관점에서 생각하기 전 단계는 제품의 관점에서 생각하는 것과 거의 비슷합니다.

그래서 저는 우리가 그 문제를 해결하지 못한 데에는 시스템적인 이유가 많다고 생각합니다. 우리는 실무 커뮤니티로서 우리가 누구이고 무엇을 할 수 있는지 알고 있습니다. 그렇다고 해서 이해관계자와 조직이 우리의 강점을 발휘할 수 있도록 허용하는 방식으로 설정되어 있다는 뜻은 아닙니다.

그래서 답답합니다. 때로는 이름에 문제가 있기도 하지만 조직 구조에도 문제가 있습니다. 예를 들어, 사람들은 제품이나 서비스를 구축하는 데 필요한 5~6가지 다른 유형의 엔지니어에 대해서는 반드시 관심을 갖지 않습니다. 그렇다면 무언가를 앤드투앤드(End-to-End)로 출시하고 테스트하기 위해 데려와야 할 5~6가지 다른 유형의 디자이너에 대해 왜 그들이 관심을 가져야 할까요?

네, 그래서 아마도 그런 것들이 이유 중 일부일 것입니다. 답답할 수 있지만, 작게 시작해서 조직 내에 옹호자를 만드는 것이 매우 중요하다고 생각합니다. 그것을 이해하는 사람들이 아군이 되면, 거기서부터 점차 확장해 나갈 수 있습니다.

마크 폰테인
제가 제대로 이해했다면, 우리 분야는 실무 커뮤니티로서 우리가 조직에 가져올 수 있는 가치와 해결할 수 있는 문제에 대해 꽤 잘 이해하고 있습니다. 우리는 그것을 어떻게 수행하는지도 꽤 잘 이해하고 있습니다. 하지만 우리가 겪고 있는 어려움은, 말씀하신 대로 우리가 무엇을 하느냐나 어떻게 소통하느냐가 아니라, 우리가 관계를 맺기 시작하는 맥락이 수용적이지 않거나, 준비가 되어 있지 않거나, 우리가 가져오는 가치에 관심이 없다는 데 있습니다. 그리고 만약 제 요약이 맞다면, 우리는 정말 긴 여정을 앞두고 있는 셈입니다. 시스템은 그리 빨리 변하지 않으니까요.

마크 하웰
네, 맞습니다. 여전히 해야 할 일이 많을 것입니다. 저는 우리가 전도(evangelizing)하는 측면에서 벗어날 수 없다고 생각합니다. 그것은 필요할 것입니다.

저는 사람들이 직접 경험해 보는 것이 중요하다고 생각합니다. 서비스디자인은 직접 경험하면 이해하게 되고, 그 후에 동참하게 되는 그런 분야나 프로세스 중 하나라고 생각합니다. 이해관계자들도 마찬가지입니다. 만약 그들이 공동 디자인 프로세스, 서비스디자이너가 제공할 수 있는 퍼실리테이션, 공동 설계, 빠른 프로토타이핑, 여정에 대한 이해 등을 경험한다면, 대부분 그들은 그 프로세스에 정말로 매료됩니다.

하지만 그것을 사전에 설명해서 "그래, 이게 우리가 필요한 거고 우리가 기꺼이 돈을 지불할 거야"라고 깨닫게 하는 것은 어렵습니다.

조직이 구성되는 방식에 관해서, 제 지난 몇 가지 역할을 되돌아보겠습니다. 저는 영국의 한 대형 은행에 입사했는데, 그곳에서 서비스디자인은 정말 새로운 것이었습니다. 그곳에는 혁신 담당 임원(Director)이 있었는데, 그는 은행이 수십억 파운드 규모의 대규모 혁신을 진행하고 있었기 때문에 서비스디자인, 시스템 사고, 그리고 애자일(Agile)을 혁신을 주도할 세 가지 분야로 꼽았습니다.

 

일하는 방식의 관점에서는 워터폴(Waterfall)에서 애자일로 전환해야 했습니다. 조직적 관점에서는 시스템 사고의 렌즈를 통해 조직의 모든 움직이는 부분, 조직 간의 상호 작용, 행동을 유발하는 인센티브 시스템을 이해해야 했습니다. 인센티브는 행동을 유발하니까요. 따라서 모든 시스템 제약 조건을 이해하는 것이 정말 중요했습니다. 그것들이 여정에 영향을 줄 수 있기 때문입니다.

그리고 그 더 넓은 시스템 안에서 여정은 무엇인가, 바로 그 지점에서 서비스디자인이 들어왔습니다. 그래서 우리는 CEO에게 보고하는 누군가가 서비스디자인의 가치를 보고 "이봐, 서비스디자인 프랙티스를 만들어야 해. 그게 혁신을 주도할 거니까. 혁신하려면 먼저 여정을 이해해야 해"라고 말하는 상황이었습니다.

그리고 조직은 그것을 정말 잘 지원하도록 설정되었습니다. 조직 구조 측면에서 우리는 여정의 집합인 가치 흐름(Value streams)을 설정했습니다. 예를 들어 은행의 상업 부문이나 자산 관리 소매 부문에 가치 흐름이 있었고, 그 안에 여정에 초점을 맞춘 랩(Labs)이 있었으며, 그 랩 안에는 다학제적 팀이 있었습니다. 그리고 그곳에 서비스디자이너들이 있었습니다.

서비스디자인이 번성하기에 완벽한 조건이었습니다. 올바른 조직 구조가 있었고, 우리가 하는 일에 대한 고위층의 지원이 있었으며, 은행을 혁신하려면 여정을 이해해야 하고 서비스디자이너가 바로 그 일을 하는 사람이라는 이해가 있었기 때문입니다. 그들만 그 일을 하는 건 아니었지만, 여정을 매핑하고 개선하는 일의 대명사가 되었죠. 사람들이 더 많은 서비스디자이너를 요청하기 시작했고 팀은 성장했습니다.

모든 면에서 잘 작동했습니다. 물론 어려움이 없었다는 뜻은 아닙니다. 여전히 많은 저항에 부딪힙니다. 그 랩들에는 비즈니스 분석가(BA)들이 있었고, 그중 일부는 15~20년 동안 일한 분들이었습니다. 그들은 깊은 지식을 가지고 있었고, 현행(As-Is) 프로세스와 목표(To-Be) 프로세스를 매핑하는 데 능숙했습니다.

그래서 서비스디자이너로서 들어가서 "좋아요, 앉아서 목표 프로세스를 한번 봅시다"라고 하면, 저는 "음, 현재 상황이 어떤지 이해해 봅시다. 경험을 이해해 봅시다"라고 말하는데, 그들은 이미 목표가 무엇이어야 하는지에 대한 기능적인 버전으로 건너뛰어 버린 상태였습니다. 마치 기차가 이미 떠난 것 같은 느낌이었죠. 너무 늦게 들어간 겁니다.

"프로세스와 경험의 차이가 뭐죠? 정말 경험을 이해해야 하나요? 그냥 개선된 프로세스를 설계하면 안 되나요?" 그래서 서비스디자인과 비즈니스 분석 사이에 긴장이 많았습니다. 저는 꽤 많은 조직에서 그런 모습을 보았습니다.

어쩌면 사람들이 하고 있는 일에 위협이 될 수도 있기 때문일 겁니다. 서비스디자이너가 들어오면, "우리가 이걸 소유하고 있어요. 경험을 우리가 소유합니다"라고 말하기보다는 파트너가 되어 협력함으로써 가치를 보여줘야 합니다. 왜냐하면 경험을 누가 소유하느냐는 훨씬 더 큰 질문이기 때문입니다.

마크 폰테인
이 예시를 공유해 주셔서 감사합니다. 여기서 풀어낼 이야기가 많네요. 한 가지 제 머릿속에 깊이 박힌 것은 "우리는 여정이 필요했다"는 말씀입니다. 여정의 관점에서 생각하기 시작해야 했습니다. 의사 결정 권한이 있는 높은 위치의 누군가가 그것이 전제 조건이라는 것을 이해했고, 그다음 "누가 여정을 이해하고 여정으로 생각하는가?"라는 질문이 나왔을 때, 이 경우 서비스디자인이 논리적인 대답이었습니다.

이것은 우리가 처음에 이야기했던 '우리가 실제로 무엇을 소통하고 어떻게 포지셔닝하는가'라는 점을 상기시켜 줍니다. 서비스디자인의 가치에 대한 이 대화는 지난 20년 동안 제 머릿속을 맴돌았습니다.

제가 차를 운전하다가 지나가는 비즈니스 밴(Van)들을 보는데, 그 밴에 적힌 이름들을 봅니다. 예를 들어 'B2B 물류 파트너'라고 적혀 있으면 저는 도대체 이 회사가 무슨 일을 하는지 전혀 모르겠습니다. 하지만 그들이 저에게 소통하는 것에 신경이나 쓸까요? 만약 그렇지 않다면, 왜 우리 서비스 전문가들은 이것에 대해 그렇게 많이 신경 쓰는 걸까요?

여기서의 메시지는, 만약 제 문제가 내 소포가 제시간에 도착하게 하고 온라인 스토어에서 구매한 사람들에게 한 약속을 지키는 것이라면, 그리고 밴에 그런 메시지가 적혀 있다면 그 맥락에서 훨씬 더 말이 된다는 것입니다.

다시 마크 님의 여정 예시로 돌아가면, 이 경우에는 명확한 요점이 있었습니다. "우리는 여정이 필요하고 누가 그걸 해결할 것인가." 서비스디자인이 서비스디자인이라고 불린다는 사실조차 알 필요가 없을 수도 있습니다. 단지 그 일을 하는 사람이 필요할 뿐이죠.

여기서 한 가지 짚고 넘어가고 싶은 점이 있는데, 마크 님의 관점이 궁금합니다. 저는 많은 서비스디자인 전문가들과 이야기를 나누는데, 그들이 겪는 문제는 한 가지 특정 업무에만 국한(pigeon holed)된다는 것입니다. 종종 "워크숍을 진행해야 하니 당신은 워크숍 담당자야"라거나 "여정 지도가 필요하니 여정 지도를 만들어"라는 식입니다. 그래서 실제로 서비스디자인을 하는 대신 여정 지도를 만들거나 워크숍을 진행하고 있습니다. 이에 대해 어떻게 생각하시나요?

마크 하웰
네, 우리는 틀에 갇힐 수 있고, 실제로 '서비스 블루프린트 만드는 사람들'로 틀에 갇히기도 합니다.

제가 말씀드린 대형 은행의 예에서, 서비스디자이너로 나타나면 기대되는 것은 블루프린트를 만드는 것이었습니다. 때로는 블루프린트를 만들 필요가 없을 때도 있습니다. 불필요할 수도 있죠. 그래서 우리가 가져올 수 있는 것이 훨씬 더 많지만, 무언가를 이해하고 구획화하는 방법은 때때로 그것을 하나의 방법론(method)으로 축소하는 것입니다. 그러면 "좋아요, 그들은 저걸 하러 왔군요"라고 생각할 수 있습니다.

거버넌스나 체크포인트 관점에서는 "네, 현행(As-Is) 블루프린트가 나왔으니 정의 단계로, 디자인 단계로, 컨셉 단계로 넘어갈 수 있겠군요"라고 말할 수 있습니다. 어떤 디자인 거버넌스 프로세스들은 결과물과 산출물에 대한 긴 체크리스트를 가지고 있습니다. "네, 고객과 대화했고, 블루프린트가 있고, 기존 리서치를 다 검토했습니다." 이것은 체크박스 채우기 활동이 되지만, 저는 이것이 포지셔닝과도 관련이 있다고 생각합니다. 포지셔닝과 '위상(elevation)'의 문제입니다.

만약 당신이 제품 스쿼드(squad)에 고정적으로 배정된 서비스디자이너라면, 아마도 프로덕트 매니지먼트가 당신의 비용을 지불하고 있을 것이고, 매핑 작업이나 여정 작업이 필요하기 때문에 당신을 원할 것입니다. 그래서 들어가 보면 때로는 너무 늦게 도착해서 당신이 왜 거기에 있는지 알기 어려울 때가 있습니다. 저에게도 그런 일이 있었습니다.

저는 배제된 적이 있습니다. 환영받지 못하거나 너무 늦게 도착해서 열외 된 느낌을 받은 환경에 들어간 적이 있습니다. 저는 끊임없이 가치를 가져올 수 있는 각도나 관점, 기회를 찾고 있었습니다. 그런 상황에서 서비스 블루프린트를 만들 수 없다면, 당신은 무엇을 위해 그곳에 있습니까? 사람들은 "실제로 당신이 필요한가요, 아니면 유저 스토리(User stories)를 작성할 비즈니스 분석가만 있으면 되나요?"라고 생각할 때까지 그곳에 머물게 됩니다.

그래서 그것은 포지셔닝과 위상의 문제입니다. 하지만 많은 회사가 디자인 역할을 펀딩하는 방식은 제품 단위로 펀딩하고 스쿼드에 속하게 하는 것입니다. 이것은 여러 여정을 가로질러 볼 수 있는 능력을 정말로 제약할 수 있습니다. 왜냐하면 다른 여정들은 다른 제품 랩이나 스쿼드에서 일어나고 있기 때문입니다.

당신이 "이봐요, 이 제품들을 연결해서 생태계를 구축할 수 있어요"라거나 "이 제품이 이 여정과 교차해요"라고 기회를 볼 수 있더라도, 그것을 하는 것은 당신의 권한이 아닙니다. 당신은 그 일을 하도록 돈을 받는 게 아니니까요. 그래서 스탠드업 미팅에 참석하고, 필요하면 블루프린트를 만들고, 만약 그게 아니라면 당신은 무엇을 위해 거기에 있습니까? 물론 사용자 옹호자가 될 수 있지만요.

그래서 당신이 어디에 포지셔닝되어 있는가? 조직 내에서 어떤 수준의 위상을 가지고 있는가? 사람들이 당신이 왜 거기에 있는지 얼마나 이해하고 있는가? 3개월 혹은 6개월치 비용을 지불받았는가?

제가 말씀드린 것처럼 제품 예산으로 고용된 상황에 처한 적이 있었습니다. 제가 있기에 적절한 곳은 아니었습니다. 여정을 매핑하려고 했고, 워크숍을 진행하려고 했고, 퍼실리테이션과 조율이라는 서비스디자이너로서의 모든 슈퍼파워를 쏟아부으려 했습니다. 하지만 결국에는 배제되었고 기분이 전혀 좋지 않았습니다. 제가 무엇을 할 수 있는지 알고 있었고 기회도 보였지만, 말 그대로 가치를 가져올 수 없었기 때문입니다.

저는 당시 매니저에게 가서 말했습니다. "여기서는 제가 효과적이지 않아요. 다른 기회를 찾아야겠어요. 제가 정말로 영향을 미칠 수 있다고 확신하는 조직 내 다른 곳으로 이동해야 합니다." 한동안은 실패한 것처럼 느끼지만, 이동해서 성공하게 되면 "와, 거기는 내가 영향을 미치기에 조건이 맞지 않았구나"라고 생각하게 됩니다.

마크 폰테인
궁금한 점이 있습니다. 환영받지 못하거나 활용되지 못하는 곳에 있다가, 약속을 이행할 수 있는 맥락으로 이동한 그 경험에서 무엇을 배우셨나요?

마크 하웰
전투를 잘 선택해야(pick your battles) 한다는 것을 배웠습니다. 계속 밀어붙이기만 해서는 안 됩니다. 우리 서비스디자이너들은 광범위한 툴킷을 가지고 있어서 시도해 볼 수 있는 것이 많습니다. 하지만 궁극적으로 관심을 끌기 위해 모든 것을 시도했는데도 효과가 없다면, 조직 내 다른 곳으로 이동해야 할 수도 있습니다. 그러면 모든 것이 바뀔 수 있습니다. 조건이 완전히 다르니까요.

모든 전투에서 이길 수는 없다는 것을 깨달아야 합니다. 때로는 성공할 수 있도록 설정되어 있지 않을 때가 있습니다. 에너지를 어디에 집중할지 아는 것이 중요합니다.

개인적으로 받아들이지 마세요. 어떤 환경은 매우 정치적일 수 있습니다. 당신의 존재를 자신들이 힘들게 얻은 지식에 대한 위협으로 보는 사람들이 있을 수 있습니다. 그래서 저항이 있을 수 있고 에고(ego)가 있을 수 있습니다. 하지만 동시에 자랑스러워할 만한 빠른 승리(quick wins)를 거둘 수도 있습니다. 원하는 큰 전략적 변화는 얻지 못하더라도, 작은 승리에 집중하는 것만으로도 앞으로 나아가고 있다는 느낌을 받을 수 있습니다.

어떤 시스템 사상가의 말인지 기억은 안 나지만, 성과의 90%는 실제로 시스템 조건과 제약에 달려 있고, 10%만이 당신의 성과라는 말이 있습니다. 당신이 최고의 서비스디자이너라 할지라도 시스템 조건이 당신에게 불리하게 작용하고 성공할 수 있도록 설정되어 있지 않다면, 할 수 있는 일이 별로 없다는 말은 아니지만, 한발 물러서서 생각해야 합니다. "관계를 맺었고 여러 접근 방식을 시도했지만 뭔가 움직이지 않아. 타이밍이 안 맞을 수도 있고, 6개월 뒤에 다시 오거나 다른 사람이 개입해야 할 수도 있어."

마크 폰테인
공유해 주신 경험을 지금 되돌아보면 조건이 갖춰지지 않았다는 것을 식별하기 쉽습니다. 하지만 그 업무를 처음 시작했을 때는 희망적이고 긍정적이며 그들이 당신을 초대한 것에 대해 흥분했을 것이라고 가정할 수 있습니다.

새로운 직책으로 이동하거나 팀을 운영할 때, "좋아, 지금은 다른 전투를 선택해야 할 때야"라고 알리는 적신호(red flags)는 무엇인가요? 언제 계속 가야 하고, 언제 물러서서 다른 것을 찾아야 하는지 어떻게 아나요? 멈추는 것이 포기하는 것처럼 느껴지기 때문에 어렵습니다. 그런 적신호는 무엇입니까?

마크 하웰 
몇 가지 적신호 중 하나는 주의 깊게 듣는 것입니다. 때로는 제 팀의 이야기를 주의 깊게 듣고 이해하는 것입니다. 만약 그들이 어떤 제품이나 포트폴리오에 속해 있는데 힘든 시간을 보내고 있고, 일대일 면담을 할 때마다 여전히 힘들다고 한다면, 그 힘든 시간이란 무엇을 의미할까요?

여러 가지가 있습니다. 공격적인 이해관계자가 있거나, 이전의 일하는 방식으로 여전히 일하는 이해관계자가 있는 경우입니다.

예를 들어 조직은 다양한 운영 모델을 도입합니다. 새로운 프로덕트 운영 모델을 도입할 수도 있고, 여정 기반 운영 모델로 이동할 수도 있습니다. 조직이 그렇게 할 때마다 변화해야 합니다. 그리고 사고방식과 일하는 방식을 바꿔야 하는 것은 조직 내 사람들입니다.

때때로 이해관계자들은 말로만(lip service) 동의합니다. "오, 그래요, 좋아요. 새로운 프로덕트 운영 모델에 완전히 동의해요. 고객 인사이트를 충분히 얻고 리스크를 줄여야죠." 기본적으로 옳은 말만 하지만, 문을 닫고 나면 여전히 옛날 사고방식에 머물러 있습니다. 때로는 그들이 조직의 리더이기도 합니다.

저에게 이것은 진짜 적신호입니다. 변화에 동의하지 않고 새로운 일하는 방식을 시도할 의향이 없는 리더들이 있는 경우입니다. 서비스디자이너들은 보통 일하는 방식과 사고방식을 바꾸고, 사일로(silos)를 통합하며 협업을 개선하기 위해 들어옵니다. 하지만 변화에 저항하는 리더가 있다면 그것은 아래로 흘러내려갑니다.

그래서 그것이 하나의 적신호입니다. 그런 유형의 리더가 있는 조직의 일부로 들어간다면, 그곳은 있기 힘든 곳이 될 수 있습니다. 그들은 옳은 말은 하겠지만 실제로는 변화를 지원하지 않기 때문입니다.

마크 폰테인
그것을 사전에 발견할 수 있나요?

마크 하웰
어느 정도는 알 수 있다고 생각합니다. 때로는 회의를 통해 듣기도 하고, 뒷소문을 통해 듣기도 합니다. 하지만 때로는 팀원들과의 일대일 면담을 통해 그들이 묘사하는 행동과 사람들의 태도를 들으면서 그들이 변화에 저항하고 있다는 것이 분명해지기도 합니다.

마크 폰테인
하지만 그건 나중에 깨닫는 것(hindsight)이잖아요? 승산이 너무 희박해서 이길 방법이 없는 상황에는 애초에 들어가지 않기를 바랄 텐데요.

마크 하웰
네, 이것은 언제 누군가를 빼내야 하는가에 대한 질문이라고 생각합니다. 누군가 그 안에서 최선을 다하고 있지만 진전이 없다면, 어느 시점에 "좋아, 그들을 빼내서 다른 곳에 투입하자"라고 말할까요? 제 팀원 중에는 번아웃을 겪는 사람들도 있었습니다. 매우 도전적인 조건과 이해관계자, 그리고 앞에서는 동의하지만 뒤에서는 딴소리를 하는 수동적인 공격성에 장기간 노출되었기 때문입니다.

예측 변수(predictor)에 대해 이야기하자면, 들어가기 전에 어떻게 보이는지와, 서비스디자이너가 두세 달 있었는데도 여전히 힘들어할 때 어느 시점에 그들이 빠져나올 수 있는가 하는 두 가지가 있습니다.

정말 도움이 되는 또 다른 것은 제품의 성숙도, 그 영역의 성숙도를 파악하는 것입니다. 여기서 잠깐 옆길로 새서 제가 팀과 함께 디자인한 '품질 평가(Quality Assessment)'에 대해 이야기해 보겠습니다.

저는 대규모 서비스디자인 팀을 가지고 있었고 품질에 대한 책임이 있었지만, 저는 한 명뿐이었고 제가 품질의 병목(bottleneck)이 되고 싶지 않았습니다. 40~50명의 서비스디자이너가 하는 작업의 품질을 어떻게 파악할 수 있을까요?

그래서 저는 팀과 함께 품질을 정말로 파악할 수 있는 프로세스를 디자인했습니다. 품질의 4가지 핵심 지표가 있었습니다.

마크 폰테인
방해해서 죄송합니다만, 품질이라뇨?

마크 하웰
네, 이것은 크래프트(기능) 수준의 평가에 가깝습니다. 서비스디자인 품질에 대해 이야기할 때 비즈니스 성과나 고객 성과와 얼마나 잘 일치하는지 이야기할 수 있지만, 이것은 사람들이 수행하는 서비스디자인 작업의 기술(craft)에 대한 평가였습니다. 특정 요인과 기준에 대해 올바른 수준의 품질로 작업을 수행하고 있는가? 그리고 그것은 수행되는 작업의 품질과 그들이 실제로 OKR(목표 및 핵심 결과)에 기여하는 정도를 예측하는 변수가 되었습니다.

우리는 몇 가지 지표를 만들었습니다. 방법론(methodology) - 올바른 방법을 따르고 있는가? 방법이 건전한가? 성과(outcomes) - 올바른 성과를 지원하고 있는가? 올바른 이해관계자 관계를 구축했는가? 그리고 개인적 성찰(personal reflections) - 수행 중인 작업과 환경에 대한 개인적 성찰은 무엇인가?

제가 이것을 언급하는 이유는 이 품질 평가 프로세스가 서비스디자이너들이 자신이 하는 일, 따르는 방법, 구축한 관계, 그리고 수행 중인 작업이 해결해야 할 문제와 얼마나 잘 일치하는지에 대해 이야기할 수 있는 매우 열린 대화가 되도록 의도되었기 때문입니다.

하지만 대화는 그들이 속한 제품의 성숙도 수준에 따라 정말 달라졌습니다. 일부 제품 영역은 성숙도가 매우, 매우 낮았습니다. 말 그대로 고객 인사이트 작업을 한 번도 해본 적이 없었습니다. 고객이 누구인지조차 몰랐고 디자이너와 일해본 적도 없었습니다. 그런 제품 영역에서 서비스디자이너들이 하는 이야기는 성숙도가 훨씬 높고 확립된 곳에 있는 사람들이 하는 이야기와 매우 달랐습니다.

성숙도가 낮은(예를 들어 2점 정도) 곳에 있다면, 그들은 관계를 구축하는 데 어려움을 겪고 있었습니다. 자신의 강점을 발휘하지 못하는 작업을 하고 있었고 성과와 일치하지 않았습니다.

그래서 서비스디자인 성공의 예측 변수로서, 해당 조직 영역의 디자인 성숙도를 평가하는 것이 어느 정도 서비스디자이너의 효과성을 예측하는 변수라고 말할 수 있습니다.

디자인 성숙도는 운영 설정, 사람, 파트너십, 실무 및 역량, 가치 및 영향 측정 등을 통해 생각할 수 있습니다. 이것들이 실제로 갖춰져 있는가? 대화가 시작되기 전에 그들이 성숙도 2인 곳에 있는지 7인 곳에 있는지 알 수 있었고, 그것은 매우 명확했습니다. 디자인 성숙도 수준에 따라 대화가 매우 달랐습니다.

질문으로 돌아가서 적신호에 대해 말하자면, 낮은 디자인 성숙도입니다. 물론 그곳에 들어가지 말아야 한다는 뜻은 아닙니다. 누군가는 들어가서 상황을 바꾸려 노력해야 하니까요. 하지만 성숙도가 7인 곳처럼 쉽지는 않을 것입니다.

마크 폰테인
이 평가에 대해 듣는 것이 정말 흥미롭습니다. 제 생각에는, 우리가 아는 한 이해관계자들과 솔직한 대화를 나누기 위해 사용할 수 있는 업계 표준의 품질 벤치마크 평가가 없는 것 같습니다. "이것이 우리 서비스디자인 업계가 효과적인 업무 수행에 대해 알고 있는 것입니다. 이 질문들을 채워보면 이런 상황이 나옵니다. 이런 결과로 이어질 것이라는 점을 인지하세요."

업계 전체에서 사용할 수 있는 도구를 본 적이 없습니다. 그 결과 많은 전문가가 효과적이기 위해 자신의 맥락에서 무엇이 필요한지조차 잘 설명하지 못하는 것 같습니다. 마치 식당을 운영하면서 재료를 얼마나 자주 사야 하는지, 의자가 몇 개나 필요한지 감이 없는 것과 같습니다. 식당이 어떤 모습인지 대충은 알지만, 메커니즘에 대한 깊은 이해가 없는 거죠. 이 경우 좋은 여정 지도를 만드는 기술의 메커니즘이 아니라, 그런 결과를 얻기 위해 갖춰져야 할 조건들을 말하는 것입니다. 말이 되나요?

마크 하웰
네, 그렇습니다. 이것이 제가 초기에 팀을 모은 실제 이유입니다. 우리는 분기별로 모임을 가졌는데, 전체 팀이 직접 만나 오후 시간을 보내며 새로운 것을 배우고 성공을 축하하거나 우리 실무에 중요한 이니셔티브와 기초 작업을 했습니다.

초기에 저는 정말 간단한 질문을 던졌습니다. "서비스디자이너로서 우리가 하는 작업의 일관성과 품질을 어떻게 향상할 수 있을까요?" 프로덕트 매니저들이 품질 책임자인 저에게 와서 "서비스디자이너 비용을 지불하고 있는데, 작업이 올바른 품질 수준으로 수행되고 있는지 어떻게 알 수 있나요?"라고 물었기 때문입니다. 다른 컨설팅 회사, 다른 배경을 가진 사람들이 너무 많았고, 저는 그들에게 그리고 저 자신에게 작업이 일관된 기준에 따라 올바른 품질 수준으로 수행되고 있다는 확신을 줄 필요가 있었습니다.

우리는 그날 오후 워크숍을 했고 서비스디자인 품질에 기여하는 요소는 너무 많았습니다. 조직에 얼마나 잘 온보딩되었는지, 공유된 템플릿과 산출물이 어디에 있는지 아는지 등일 수 있습니다. 서비스디자인 비평(critique)이 언제 열리는지 알고 참석해서 동료들에게 피드백을 받는지 등도 품질에 중요한 기여 요인입니다.

하지만 제가 정말 집중하고 싶었던 것은 서비스디자인의 정말 중요한 요소들에 대해 대화할 수 있는 프레임워크를 어떻게 디자인하느냐는 것이었습니다. 말씀드린 대로 4가지 지표와 6가지 토론 항목을 만들었습니다. 토론 항목은 문제 정렬, 지속 가능한 디자인, 포용적 디자인, 타이밍 및 역량(사람이 충분한가?), 커뮤니티 협업(커뮤니티 피드백 기회를 활용하고 있는가?), 그리고 지난 체크인이나 품질 평가의 조치 사항을 팔로업했는지 등이었습니다.

이것의 장점은 이것이 게이트(gated) 거버넌스 프로세스가 아니라 품질의 예측 변수가 되었다는 것입니다. "공감 단계가 끝났으니 서비스 블루프린트 체크박스, 사용자 리서치 체크박스, 그러니 정의 단계로 이동"하는 식이 아니었습니다. 이것은 고품질 작업의 예측 변수가 되었고, 실제로 프로덕트 매니저의 90%가 서비스디자이너의 참여를 그들의 OKR 달성에 '필수적(critical)'이라고 평가하게 만들었습니다.

이 프레임워크는 제가 품질 평가를 저 이상으로 확장할 수 있게 해주었습니다. 병목 현상을 없애고, 일관된 기준을 제공하여 좋은 대화를 나누고 작업의 이면을 들여다보며, 동료 피드백을 통해 다르게 접근할 방법을 찾게 해주었습니다.

처음에 말씀하신 포인트와 관련해서, 이 프로세스에 대해 여러 번의 회고(retro)를 거쳤기 때문에 피드백이 많았습니다. 처음에는 좋지 않은 점도 많았습니다. 서비스디자이너가 완전히 새로운 도메인에 뛰어들어 도메인을 이해하고 다른 사람의 작업을 이해한 뒤 비판적인 피드백을 주는 것은 인지적으로 매우 어려운 일이었습니다.

하지만 피드백 중 하나는 "좋은 것(Good)이 어떤 모습인가요?"였습니다. "제가 이 다른 서비스디자이너의 작업을 평가하고 있는데, 서비스디자인에서 '좋음'의 북극성(North Star)은 무엇인가요?" 이것은 정의하기 더 어려운 것입니다. 우리는 가봤기 때문에 알고, 해봤기 때문에 압니다. 어쩌면 고객 만족도를 크게 높이고 효율성을 개선한 영향력 있는 사례 연구를 제시하는 것이 정의하는 방법일 수 있습니다. 하지만 훌륭한 UI를 가리키는 것보다는 어렵습니다.

마크 폰테인
좋은 것이 어떤 모습인지에 대해 힌트를 주신 것 같습니다. 대리 지표(proxy)가 있고 저는 마크 님이 소개한 KPI를 정말 좋아합니다. "당신의 시간 비용을 지불하는 사람이 다음번에도 당신을 고용하겠는가?" 프로덕트 매니저가 그 과정에서 당신의 참여가 필수적이라고 생각하는가? 특정 프로젝트의 결과가 무엇이든 간에 말이죠. 그들이 다시 당신을 고용할까요? 저는 그것이 당신이 얼마나 효과적인지를 보여주는 정말 좋은 대리 지표라고 생각합니다.

마크 하웰
네, 우리는 이에 대한 데이터를 실제로 어떻게 얻을 수 있을지 알아내기 위해 많이 논의했습니다. 결국 "프로덕트 매니저에게 물어보자"로 귀결되었습니다.

저는 3개월마다 프로덕트 매니저들과 회의를 가졌습니다. 그리고 3개월마다 아주 간단한 질문을 했습니다. 5분도 안 걸리고 1분이면 되는 질문입니다. "프로덕트 성과를 달성하는 데 있어 서비스디자이너의 기여도를 어떻게 평가하시겠습니까?" 가장 높은 점수는 '필수적(critical)'이었고 가장 낮은 점수는 '관련 없음' 정도였습니다.

그 질문에 대해 정말 많은 피드백을 받았고, 팀이 전반적으로 어떻게 하고 있는지 등급을 매길 수 있었습니다. 그리고 해당 영역의 디자인 성숙도를 알면, 프로덕트 매니저가 낮은 점수를 줬을 때 추가적인 맥락을 제공해 줍니다. "평균적인 기여도라고 평가하셨지만, 저는 그 환경과 어려움을 알고 있습니다. 디자인 성숙도가 2~3점이라는 것은 이런 방식으로 일하는 것에 대한 개방성이나 서비스디자인이 할 수 있는 올바른 종류의 작업이 갖춰져 있지 않을 수 있다는 것을 의미합니다."

그래서 "프로덕트 매니저가 평균만 줬으니 일을 잘 못하고 있군"이 아니라, "왜 평균인지 이해합니다. 그들의 여정을 돕기 위해 우리가 무엇을 더 할 수 있을지 봅시다"라고 말할 수 있는 맥락을 제공했습니다.

마크 폰테인
이미 몇 번 언급하신 주제로 빠르게 넘어가고 싶습니다. 현재 상당한 규모의 서비스디자인 팀을 이끌고 계시고, 분기별 체크인과 '커뮤니티'라는 단어를 언급하셨습니다. 효과적인 서비스디자인 업무를 수행하는 데 있어 커뮤니티가 얼마나 중요한지 마크 님의 관점을 좀 더 말씀해 주시겠습니까?

마크 하웰
네, 커뮤니티는 우리가 이야기해 온 것과 아주 잘 연결되는 질문이라고 생각합니다. 우리는 품질에 대해 이야기했고, 일부 제품 그룹에서 서비스디자이너로 일하는 것이 얼마나 어려울 수 있는지 이야기했습니다.

저에게 있어 제가 커뮤니티를 매우 강조하는 이유는, 디자이너들이 돌아와서 자신들이 쓰는 언어로 말하고, 소속감을 느끼며, 같은 생각을 가진 사람들과 함께 있다고 느낄 수 있는 안전한 공간(safe space)을 갖고 싶기 때문입니다. 항상 같은 생각을 가진 사람들과 있다고 느끼지는 못하니까요.

그래서 저에게 커뮤니티는 매우 중요합니다. 커뮤니티를 구축하는 방법은 종종 리추얼(의식)을 중심으로 이루어집니다. 그리고 프랙티스를 발전시키면서 그것들을 변화시켜야 한다고 생각합니다.

실무 커뮤니티(Communities of Practice)에 대해 생각할 때 저는 사람(People), 목적(Purpose), 실천(Practice)에 대해 생각합니다. 누구를 위해 이 프랙티스를 디자인하는가? 왜 사람들의 삶에 이것이 필요한가? 사람들은 바쁩니다. 현업에서 할 일이 많습니다. 그들에게 '왜(Why)'라는 요소를 제공해야 합니다. 왜 내가 이 실무 커뮤니티에 참여해야 하는가?

그리고 종종 그 이유는 "우리는 왜 여기에 있는가? 목적은 무엇인가? 우리의 가치 제안을 어떻게 정의하는가?"입니다. 그리고 프랙티스를 구축하면 정보, 방법, 도구를 공유하고 공유 저장소에 접근할 수 있게 해주므로 서비스디자이너에게 유용합니다.

하지만 무엇보다도 커뮤니티를 주도한 것은 우리가 도입한 리추얼들이었습니다. 일대일 면담부터 분기별 모임, 그리고 '토킹 서클(talking circle)'까지 다양합니다.

저는 팀 내에서 새로운 모임을 시작했는데, 사실 누군가 저에게 제안한 것이었습니다. 저는 서비스 아키텍처부터 AI, 측정에 이르기까지 기초를 다지기 위해 팀과 함께 13가지 이니셔티브를 진행하고 있었습니다. 그중 하나는 웰빙에 관한 것이었는데, 그룹의 누군가가 '토킹 서클'이라는 모임이 있다고 말했습니다.

북미 원주민의 전통에 기원을 둔 것인데, 그룹으로 모여 누군가 물건(토킹 스틱 같은)을 잡고 주제나 중요한 문제에 대해 이야기하기 시작합니다. 예를 들어 변화 관리 같은 주제로 5~10분간 이야기합니다. 아무도 방해하지 않고, 물건을 다른 사람에게 넘기면 그 사람이 이야기하고 사람들은 깊이 경청합니다.

저는 참석하지 않았습니다. 제 팀이 실제로 토킹 서클을 시작했고 피드백이 정말 좋았습니다. 사람들이 중요한 문제에 대해 이야기하는 데 정말 도움이 되었습니다.

그것은 스펙트럼의 한쪽 끝에 있는, 팀이 주도한 리추얼이었습니다. 다른 끝에는 분기별 모임이 있었습니다. 제가 가장 최근 조직에 왔을 때 거대한 서비스디자이너 그룹은 있었지만 커뮤니티는 없었습니다. 계약직 중 한 분이 한 달에 한 번 서비스디자인 밋업을 운영하고 있었지만, 누군가 "무엇을 하시나요? 가치 제안이 뭐죠?"라고 물으면 50가지 다른 대답이 나왔을 겁니다. 그게 문제였습니다.

그래서 저는 이런 기초를 다지기 위해 분기별 모임을 시작했습니다. 하지만 무엇보다도 코로나 기간이었기 때문에 물리적인 연결, 함께 배우는 것, 성공을 축하하는 것이 중요했습니다.

분기별 모임을 앞두고 저는 전체 팀에게 "기대 이상을 해냈거나 정말로 인정을 받아야 한다고 생각하는 사람을 추천해 주세요"라고 요청했습니다. 그리고 그들의 이름, 추천인, 추천 내용을 담은 슬라이드를 만들었습니다. 종이로 나눠주기도 했고, 처음에는 코팅(laminate)도 했지만 지속 가능하지 않아서 그만뒀습니다. 하지만 코팅된 슬라이드는 마치 상장처럼 느껴졌죠.

시간을 내어 성공을 인정하고 축하하는 것만으로도 정말 좋았고 사람들은 박수를 보내고 환호했습니다. 그런 리추얼을 갖는 것이 정말 도움이 되었고, 어느 순간 티핑 포인트가 와서 갑자기 내가 무언가의 일부, 즉 커뮤니티의 일부라고 느끼게 되었습니다. 제가 직접 주도하지 않았는데, 실무 커뮤니티는 반드시 한 사람이 이끌 필요는 없고 어느 정도 구성원들에 의해 주도되어야 한다는 것이 제 정의의 일부였기 때문입니다.

마크 폰테인
커뮤니티가 어떻게 도움이 되는지 예시를 들어주셔서 감사합니다. 저도 그 생각에 동의합니다. 대화 초반에 말씀하셨듯이, 서비스디자인을 한다는 것은 변화를 가져오는 것입니다. 그것이 우리가 항상 테이블에 가져오는 것입니다. 그리고 변화를 가져온다는 것은 저항에 부딪힌다는 뜻입니다. 변화는 저항을 해결하는 것입니다.

따라서 다시 튀어 오르고 정신적으로 온전함을 유지하려면 많은 회복 탄력성(resilience)이 필요합니다. 혼자서 하기는 정말 어렵습니다. 같은 여정을 겪고 있고 같은 투쟁을 하고 있는 사람들이 있다면 큰 도움이 됩니다. 저는 커뮤니티가 전문가로서 장기적으로 지속 가능한 서비스디자인을 하는 데 필수적이라는 것을 배웠습니다. 변화를 가져오는 모든 사람에게 해당하겠지만 우리는 특히 그렇습니다.

이제 대화를 시작할 때 했던 이야기로 돌아가 보겠습니다. 우리가 하는 일을 설명하려고 애쓰는 대화에서 벗어나 실제로 일을 하고, 정의에 집착하거나 프로세스에 대해 이야기하는 것을 멈추고 우리가 가져오는 성과에 대해 더 이야기하자는 것이었죠. 마크 님은 맥락이 이미 갖춰져 있고 처음부터 성공할 수 있는 운 좋은 위치에 있기도 했습니다. 하지만 대부분의 청취자는 아직 그렇지 않다고 가정해 봅시다.

이 대화를 듣고 난 다음 날 아침 사무실에 걸어 들어갑니다. 상황을 개선하기 위해 그들이 취해야 할 첫 번째 단계는 무엇이라고 생각하십니까?

마크 하웰
가장 좋은 첫 단계는 사무실로 바로 걸어 들어가서 프로덕트 매니저나 스쿼드의 리더와 시간을 갖고 "당신의 지표는 무엇입니까? 무엇에 신경 쓰고 있습니까? 무엇을 하려고 합니까?"라고 이해하는 것입니다.

OK(Objectives and Key Results)에 대해 이해하는 순간, 즉 목표와 핵심 결과를 이해하는 순간 정말 깨닫게 되는 것이 많습니다.

당신이 거기서 추진해야 할 결과가 무엇인지 이해하고, 당신이 그것에 어떻게 기여할 수 있는지 이해한다면, 다른 것을 추진하다가 배제되는 대신 같은 방향으로 밀고 나갈 수 있습니다.

그래서 "당신이 왜 거기에 있는지, 무엇을 할 수 있는지"에 대한 대화를 나누고, 그러한 OKR에 가장 잘 기여하기 위해 무엇을 할지 결정하는 것이 중요합니다. 피할 수 없습니다. 당신은 이유가 있어서 거기에 있습니다. 그들은 당신의 시간 비용을 지불하고 있고, 당신이 어떻게 영향을 미치는지 확신하지 못한 채 느끼는 것보다 같은 목표를 향해 협력하고 파트너십을 맺는 것이 낫습니다.

제 팀들과의 일대일 면담에서 저는 그냥 "OKR이 뭐예요? 주요 OKR 3가지만 말해줘요"라고 묻곤 했습니다. 대부분은 알지만 때로는 모릅니다. 모를 때는 좀 놀랍죠.

저는 팀과 함께 월간 OKR 세션을 운영하기 시작했습니다. 모든 제품, 모든 디자이너, 그리고 OKR을 놓고 봅니다. 처음에는 정말 건조한 연습처럼 느껴졌습니다. 거대한 엑셀 스프레드시트를 보며 아무도 말을 안 했죠. 첫 세션을 즐긴 사람은 없었을 겁니다.

하지만 디자이너들이 OKR을 움직이는 데 어떻게 돕고 있는지 살펴보기 시작하고 성공을 축하할 수 있게 되자, "그래, 모멘텀을 얻고 있어"라고 느끼게 되었고 팀 전체가 자신들이 무엇을 하고 있는지 볼 수 있었습니다.

단지 제품 OKR에 관한 것만이 아니었습니다. 더 넓게는 조직의 OKR과 조직 전략으로 연결(laddering up)되는 것이었습니다. "디자인 성숙도를 1점 높인다", "자본 지출(Capex)을 4억 줄인다" 같은 높은 수준의 목표라 하더라도, 당신이 하는 일이 아주 작은 방식이라도 그곳에 어떻게 기여하는지 볼 수 있다면 올바른 방향으로 움직이고 있는 것입니다.

그것이 제가 말하고 싶은 가장 중요한 것입니다. 그리고 그것을 알면 생일 파티에서 이야기하기도 훨씬 쉬워지죠. 서비스디자인에 대해 이야기하는 대신 "저는 자본 지출 400을 절약하는 데 기여하고 있습니다"라고 말하면 더 흥미로운 대화로 이어질 것입니다.

마크 폰테인
네, 좋습니다. 마지막으로 드릴 질문이 있습니다, 마크. 우리는 보통 에피소드를 답변이 아니라 질문으로 끝내는 것을 좋아합니다. 올바른 질문이 있으면 답은 종종 꽤 분명해지기 때문입니다. 이 방송을 다 듣고 나서 우리가 곰곰이 생각해 볼 만한 가치가 있는 질문은 무엇이라고 생각하십니까?

마크 하웰
생각해 볼 만한 질문이라... "어떻게 하면 서비스디자인을 비즈니스에 더 연결되고 더 성과(outcome) 중심적인 것으로 재정의(reframe)할 수 있을까?"입니다.

저는 그것이 우리가 생각해야 할 핵심적인 변화라고 생각합니다. 우리는 방법론을 앞세우고 싶지 않습니다. 우리는 소위 '포스트잇 연극(post-it note theater)'을 한다는 비난을 받고 싶지 않습니다. 우리는 비즈니스 임팩트를 주기 위해 존재합니다.

언어도 매우 중요합니다. 사용하는 언어는 사람들을 즉시 돌아서게 하거나 소외시킬 수도 있고, 반대로 "잠깐, 이 사람은 자신이 무슨 말을 하는지 알고 있고 우리가 여기서 하려는 일에 관심이 있구나"라고 생각하게 만들 수도 있습니다.

그래서 방법론 중심의 접근 방식에서 성과 중심의 접근 방식으로 재정의하려면 어떻게 해야 할까요? 그리고 그렇게 하기 위해 어떤 언어를 사용하는 것이 올바를까요? 우리가 불리는 이름에 대한 언어일 수도 있고, 업무에 대해 이야기하는 방식일 수도 있습니다.

그리고 우리 머릿속에는 항상 "그래서 뭐요(So what)?"를 생각해야 합니다. "그래서 뭐요? 우리가 이 모든 걸 했는데, 그래서 뭐요? 고객에게 무슨 의미가 있고, 비즈니스에 무슨 의미가 있는가?" 항상 '그래서 뭐요'를 생각하지 않으면 프로세스에 갇힐 수 있습니다.

마크 폰테인
생각해 보기에 이미 좋은 질문이네요. "그래서 뭐요?" 저도 거기에 한 표 던지겠습니다. 제 추가 질문은 "당신의 밴(Van)에 적힐 부제(subtext)는 무엇인가?"입니다. 만약 밴에 '마크 폰테인 서비스디자인'이라고 적혀 있다면, 그 아래 들어갈 부제는 무엇일까요?

지금 당장 대답할 필요는 없지만, 저는 그것에 대해 생각해 보겠습니다. "중요한 것을 디자인하라(Design what matters)." 또는 "비즈니스를 더 수익성 있게 만들기." 아마 그런 것 중 하나를 남길 것 같네요.

댓글을 남겨주세요, 여러분. 여러분의 밴에는 무슨 일이 일어나고 있는지 알고 싶습니다. 마크, 경험과 이야기를 공유해 주셔서 정말 감사합니다. 우리에게 필요한 것은 이론이나 프레임워크가 아니라 실제로 시도하고, 해보고, 본 것입니다. 오늘 그것을 많이 가져다주셨습니다. 나와주셔서 감사합니다.

마크 하웰
초대해 주셔서 감사합니다, 마크. 오늘 대화 정말 즐거웠습니다.

마크 폰테인
저에게 있어 우리 퍼즐의 해답은 세 단계로 정리되었습니다. 이해관계자가 측정받는 비즈니스 목표를 진정으로 이해함으로써 정렬(alignment)을 찾는 것으로 시작합니다. 그것은 우리에게 임팩트를 중심으로 업무를 재정의할 명확성을 주어, 그들의 눈에 '좋은 것'이 어떤 모습인지 알게 해줍니다.

그리고 그 길은 결코 쉽지 않기에, 우리는 혼자 갈 수 없다는 것을 상기하게 됩니다. 우리의 커뮤니티는 회복 탄력성의 가장 큰 원천입니다. 그 여정으로 우리를 안내해 준 마크에게 다시 한번 감사드립니다.

오늘 대화가 즐거우셨다면 큰 부탁 하나 드리겠습니다. 이 영상의 좋아요 버튼을 눌러주시고, 아직 안 하셨다면 짧은 댓글을 남겨주세요. 알고리즘을 위해서가 아니라, 저에게 영양분을 주고 우리가 이런 주제를 다룸으로써 올바른 궤도에 있는지 알려주기 위해서입니다.

마지막으로 헤어지기 전에, 잠시 시간을 내어 오늘 우리와 함께함으로써 전문가로서 배우고 성장하는 데 주의를 기울였다는 사실을 축하해 주시기 바랍니다. 여러분의 업무를 통해 영향을 받게 될 모든 사람을 대신하여, 시간을 내어 헌신해 주셔서 감사합니다. 제 이름은 마크 폰테인이고 서비스디자인쇼의 새로운 대화에서 여러분을 다시 뵙기를 고대합니다. 건강하시고 또 만나요.