(영상) 애자일 딜리버리를 위한 서비스디자인 가이드: 7가지 실용 도구 - 크리스틴 브라운, 루이즈 머셋

이 영상은 서비스디자이너가 애자일 딜리버리 과정 전반에서 어떻게 효과적으로 기여할 수 있는지를 보여준다. 발표자는 웨일스 정부의 디지털 신청 포털과 중앙정부 데이터 분석 대시보드 프로젝트 경험을 바탕으로, 디스커버리 이후에도 서비스디자인이 왜 필수적인지, 그리고 알파·베타·라이브 단계에서 활용할 수 있는 7가지 실용 도구(가정 기록과 가설 설정, 사용자 스토리 매핑, 빠른 프로토타이핑, 서비스 비전 정립, 서비스 블루프린트 구체화, 성과 측정 체계 수립, 사용자 니즈를 기술 요구사항으로 번역하기)를 소개한다. 

* 애자일이나 디지털 서비스 표준(특히 영국 GDS)에서 정해진 공식 단계는 보통 디스커버리 → 알파 → 베타 → 라이브이다.
알파(Alpha)
– 소규모 실험, 프로토타입, 가설 검증.
– “이 접근이 가능할까?”를 보는 초기 테스트.
베타(Beta)
– 제한적 또는 공개적 시험 운영.
– MVP를 실제 환경에서 검증.
– “실제로 잘 작동할까?” 확인.
라이브(Live)
– 정식 운영.
– 지속적 개선(Continuous Improvement).

애자일 딜리버리를 위한 서비스디자인 가이드: 7가지 실용 도구
A Service Design Guide to Agile Delivery: 7 Practical Tools
2025년 9월 25일
크리스틴 브라운 (Christine R. Browne), 루이즈 머셋 (Louise Mushet)
원본 영상 : https://youtu.be/VJXKDGMftPA?si=NgvixsN9DbW3PGge
출처 : Agile on the Beach
번역 : 챗GPT (요약, 생략된 부분, 발언자 표기 오류가 있을 수 있습니다. 원본을 확인해주세요.)  

 

유튜브 소개글: 
서비스디자이너들은 종종 딜리버리 과정에서 디스커버리 단계에만 보이거나 인정받는 경우가 많다. 서비스디자이너들은 이 단계에서 단순히 즐길 뿐 아니라, 가장 역량을 발휘하며 활약한다. 현재(as-is) 환경의 문제와 어려움을 이해하고 이를 바탕으로 미래(to-be)를 설계하는 것은 딜리버리에서 핵심적인 부분이다. 그러나 우리가 배운 것은 실제로 적용되어야 하며, 그래야만 디자인이 눈에 보이는 실질적 라이브 서비스로 이어질 수 있다. 우리가 디자인한 것은 반드시 구현되어야 한다. 기술적 환경에 적응하면서 서비스디자인 방법을 적용할 수 있는 능력은 서비스디자이너들이 성장해야 할 필수 역량이다.
이 세션은 애자일 딜리버리 과정에서 서비스디자이너가 맡는 중요한 역할을 깊이 탐구하고, 그 가치가 입증될 수 있도록 돕는다. 발표자는 공공 부문에서 고위험 디지털 전환 프로젝트를 라이브 단계까지 이끈 경험을 토대로, 다학제 팀 안에서 서비스디자이너가 어떻게 자신의 전문성을 가장 잘 활용할 수 있는지에 대한 실질적 통찰을 제공한다.
우리는 이 세션에서 서비스디자인 기법이 MVP를 정교화하고 검증하며, 이해관계자의 기대를 관리하고, 라이브 서비스로의 원활한 전환을 보장하는 데 어떻게 효과적으로 활용될 수 있는지를 살펴본다. 익명화된 실제 사례를 통해, 빡빡한 일정과 복잡한 요구 조건 속에서도 서비스디자이너가 의미 있는 개선을 어떻게 이끌어낼 수 있는지 보여줄 것이다.
이 세션은 특히 다음과 같은 사람들에게 유익하다.

• 디스커버리를 넘어 더 큰 영향력을 발휘하고자 하는 서비스디자이너
• 이후 단계에서 서비스디자인을 더 잘 활용하고자 하는 프로덕트 매니저
• 서비스디자인을 애자일 딜리버리에 통합하고자 하는 딜리버리 매니저
• 베타 단계에서 서비스디자인의 실질적 적용에 관심 있는 모든 사람

크리스틴 브라운 (Christine R. Browne)
크리스틴 브라운은 TPXimpact의 시니어 서비스디자이너이다. 도서관학과 정보과학을 전공한 배경을 가지고 있으며, 사서로 일한 경험이 있다. 이후 디지털 전환과 공공부문 서비스 혁신 영역으로 경력을 확장하였다. 특히 데이터 기반 의사결정과 실용적 낙관주의를 바탕으로, 복잡한 공공 프로젝트 속에서 서비스디자인이 기술 및 시스템 구축과 결합될 수 있도록 이끄는 역할을 한다.
https://www.linkedin.com/in/christine-r-browne

루이즈 머셋 (Louise Mushet)
루이즈 머셋은 10년 이상의 경력을 가진 서비스디자이너로, 현재 TPXimpact에서 시니어 서비스디자이너로 활동한다. 공공 및 제3섹터 프로젝트 경험이 풍부하며, 포용적 디자인을 핵심 주제로 삼고 있다. 디스커버리 이후 단계에서 서비스디자인의 역할을 확장하는 데 관심을 두고 있으며, 조직 내에서 서비스디자이너가 어떻게 더 오래, 깊이 참여할 수 있는지를 탐구한다. 또한 디자인 커뮤니티와 동료 디자이너를 멘토링하며 지식과 경험을 공유하는 활동도 적극적으로 하고 있다.
https://www.linkedin.com/in/louise-mushet-61156731

---

사회자:
오늘의 시작을 열어줄 TPX 임팩트의 다이내믹 듀오입니다. 시니어 서비스디자이너 크리스틴 브라운과 루이즈 머셋입니다. 크리스틴은 컴퓨터·정보과학 박사 학위와 사서 자격을 바탕으로 한 전략형 전문가로, 트랜스포메이션을 이끄는 데 탁월합니다. 루이즈는 10년 경력의 디자이너로서 모두에게 접근 가능한 제품과 서비스를 만드는 데 사명을 두고 있습니다.
포용적 디자인의 열정적 옹호자인 두 사람이 디스커버리를 넘어 애자일 딜리버리로 나아가는 서비스디자이너의 길을 이야기할 것입니다. 큰 박수로 루이즈와 크리스틴을 맞이해 주기 바랍니다.

크리스틴:
안녕하세요. 모두 반갑습니다. 오늘 아침 이 세션을 선택해 주셔서 감사합니다. 우리는 TPX 임팩트의 시니어 서비스디자이너 크리스틴과 루이즈이며, 디스커버리가 끝난 이후에도 서비스디자이너가 어떻게 계속 관여하고 가치를 더할 수 있는지 공유하려 합니다.
먼저 자기소개부터 하겠습니다. 방금 소개만큼 그럴듯하지 않을 수도 있습니다만, 시작하겠습니다. 저는 크리스틴 브라운입니다. 주로 영국 중앙정부에서 일합니다. 실용적 낙관주의자이자 약간의 데이터 덕후로 알려져 있습니다.

루이즈:
저는 루이즈 머셋입니다. 공공 및 제3섹터 조직과 함께 일하는 것을 좋아합니다. 스스로를 디스커버리, 줄여서 ‘디스코’ 디바라고 부릅니다.
우리가 몸담고 있는 회사 TPX 임팩트는 어떤 곳인지 소개하겠습니다. 과거 디자인 업계에서 익숙하실 FutureGov나 Different 같은 여러 회사가 합쳐져 탄생한 조직입니다. 사람 중심 디지털 트랜스포메이션에 대한 공통의 열정을 바탕으로 모였습니다. 화면에 보이는 공공 및 제3섹터의 다양한 파트너들과 함께 일하고 있으며, 오늘 발표에서 이들과의 협업 경험을 예시로 소개할 예정입니다.우리 조직은 네 가지 축에서 일합니다. 디자인은 우리가 주로 활동하는 영역으로, 문제를 이해하고 과제를 정의하며 해결책과 기회를 도출합니다. 데이터 영역에서는 사람들이 데이터를 쉽게 찾고 접근하고 활용할 수 있도록 돕습니다. 경험 영역에서는 디지털 채널 전반에서 대상자와의 효과적인 소통을 설계합니다. 기술 영역에서는 고품질의 확장 가능한 시스템과 서비스를 구축합니다.

크리스틴:
그렇다면 디스커버리 바깥에서는 무엇을 하고 있을까요? 디스커버리는 훌륭한 리서치와 명확한 사용자 니즈로 끝나는 경우가 많습니다. 그러나 알파와 베타로 넘어가면 사용자가 어떻게 행동할지에 대해 다양한 가정을 세우기 시작합니다. 어떤 가정은 맞지만, 어떤 가정은 그렇지 않습니다. 질문을 하나 드리겠습니다. 마지막으로 디스커버리를 마치고 산출물을 딜리버리 팀에 넘긴 뒤, 그다음에는 어디로 갔고 무엇을 했습니까? 많은 분들이 새로운 클라이언트와 또 다른 디스커버리를 시작했을 가능성이 큽니다. 혹은 가장자리에서 “어떻게 돼가나요?”라고 물었고 “좋습니다, 감사합니다”라는 예의 바른 짧은 답을 들었을 수도 있습니다.

루이즈:
디스커버리는 서비스디자이너의 궁극의 안락지대이기 때문입니다. 우리는 해결책으로 뛰어들기 전에 문제를 깊이 이해하고, 어떻게보다 왜에 몰입하는 데 강점이 있습니다. 그래서 마치 마법처럼 정의된 ‘To-Be’ 상태에 이르면 우리 없이도 순조롭게 항해할 것이라고 믿는 경우가 많습니다. 그러나 항상 그렇게 되지는 않습니다. 우리가 곁에 없으면 사용자 여정, 블루프린트, 니즈 맵 같은 훌륭한 디스커버리 산출물이 잊히거나 단절되거나 이어지지 않을 수 있습니다. 따라서 전체 과정에서 어떻게 다시 우리 자신을 자리매김할 것인지가 중요합니다.

크리스틴:
또 하나 깨닫고 있는 점이 있습니다. 많은 팀이 서비스디자인을 ‘완료하는 단계’로 취급합니다. 그러나 복잡성이 커질수록 서비스디자인은 더 가치 있는 ‘사고의 렌즈’가 됩니다. 뛰어난 탐정들을 막상 진짜 사건이 시작되는 순간 집으로 돌려보내는 격과 같습니다.

루이즈:
애자일의 단계(디스커버리·알파·베타·라이브)는 서비스디자이너의 절친인 더블 다이아몬드와 잘 맞물립니다. 문제를 이해하고, 해결을 구축한다는 점에서 타당합니다. 그럼에도 왜 실제 일이 본격화되는 후반부에서 우리는 종종 배제되는 것일까요?

크리스틴:
글쎄요. 우리가 프로젝트 전 생애주기에 관여하며 배운 바는 이렇습니다. 디스커버리에서 만든 사용자 여정은 빌드가 진행될수록 계속 새로운 것을 드러냅니다. 식별했던 페인포인트는 실제 기능이 형태를 갖출 때 예상치 못한 방식으로 나타납니다. 결국 우리가 디자인한 것은 반드시 빌드되어야 합니다. 서비스디자인은 완료하는 단계가 아니라, 복잡성이 커질수록 더 유용해지는 관점입니다. 베타는 예측하지 못했던 뉘앙스를, 라이브는 실제 사용 맥락에서 무슨 일이 일어나는지를 보여줍니다. 그러므로 후속 단계에서도 서비스디자인을 계속 이어가야 합니다.
서비스디자인이 완료하는 단계가 아니라, 복잡성이 커질수록 더 유용해지는 렌즈라면 어떻겠습니까? 알파 단계에서는 사용자 행동에 대한 새로운 질문이 생깁니다. 베타 단계에서는 예측하지 못했던 뉘앙스가 드러납니다. 라이브 단계에서는 실제 사람들이 우리의 서비스를 사용할 때 어떤 일이 일어나는지를 보여줍니다. 오늘 오전 기조연설에서 언급된 감자 예시를 떠올려 보면, 우리는 회의를 더 만들거나 속도를 늦추지 않고도 딜리버리 전 과정에서 계속 관여하며 진짜로 유용할 수 있습니다. 실제로 빌드하는 순간에 디자인 사고의 가치가 더 커진다는 것을 증명함으로써 그렇습니다. 딜리버리 매니저 여러분, 알파와 베타에서 사용자가 어떻게 반응할지에 대한 더 명확한 인사이트가 필요하다고 느낀 적이 있지 않습니까? 개발자 여러분, “사용자는 쉽게 결제하길 원한다” 대신 “사용자는 복잡한 삶과 산만한 환경 속에서 모바일을 사용하므로 3초 이내 결제 확인을 받아야 한다”라는 문장을 받는다면 더 도움이 되지 않겠습니까? 스크럼 마스터 여러분, 스프린트 리뷰에 “실제 사용자가 우리가 만든 것을 어떻게 경험했는지”에 대한 관찰이 포함된다면 어떻겠습니까? 딜리버리 전 과정에서 사용자 중심 사고를 살아 있게 유지하면 속도가 느려지지 않습니다. 더 나은 정보를 바탕으로 더 빠르고 더 나은 결정을 내릴 수 있습니다. 절차를 더하는 것이 아니라 더 좋은 정보를 다루기 때문입니다.
즉, 서비스디자인 사고를 계속 유지하는 일은 애자일 딜리버리를 복잡하게 만들지 않습니다. 오히려 더 민첩하게 만듭니다.

루이즈:
그렇다고 해서 쉽다는 뜻은 아닙니다. 우리가 겪었고 아마 많은 분들이 공감할 만한 공통 과제가 있습니다.
첫째, 서비스디자인은 흔히 인간·지구 중심으로 인식되고, 애자일은 제품 중심 프로세스이기 때문에 제품 중심 팀 안에 우리가 던져지는 경우가 많습니다. 그 안에서 우리의 자리를 어떻게 찾을지가 문제입니다.

크리스틴:
둘째, 프로토타이핑 이후의 일은 UX의 일로 여겨지는 경향이 있어, 중요한 논의와 개발에서 우리가 배제되기 쉽습니다. 그러면 설계 대상은 사일로화되고 서비스가 어떻게 작동해야 하는지에 대한 큰 그림 연결이 끊깁니다.

루이즈:
셋째, 서비스디자인 작업은 무형적이고 상위 수준의 일로 보여 Jira 티켓에 표현하기 어렵습니다. 그 결과 즉각적인 가치를 입증하기도 쉽지 않습니다.

크리스틴:
넷째, 제품팀이 서비스디자이너를 어떻게 활용해야 할지 모르는 경우가 많고, 결국 우리가 스스로 역할을 정의해야 합니다. 여기에 알파 이후는 우리 서비스디자이너에게도 낯선 공간이라, 스스로를 어떻게 가장 잘 활용할지 모호해지는 문제가 겹칩니다.

이제 제가 더 깊은 예시를 하나 소개하겠습니다. 퍼블릭 베타 공개 3주 전에 합류한 프로젝트입니다. 웨일스 정부의 디지털 신청 포털로, 시민이 정부 프로그램에 신청하도록 돕는 서비스였습니다. 팀에는 훌륭한 디스커버리 산출물, 사용자 리서치, 서비스 맵, 페인포인트가 정리되어 있었습니다. 그러나 빌드 단계로 들어가자 프로젝트의 원래 서비스디자이너가 애자일 팀 내 더 큰 책임의 역할로 이동했고(이 환경에서 흔히 일어나는 일입니다), 서비스디자인 자체에 집중하는 사람이 아무도 없었습니다. 많은 분들께 익숙한 상황일 것입니다.
제가 베타 3주 전 도착했을 때의 인수인계 상태는 이러했습니다. 수용 기준이 없는 사용자 스토리 62개, 서로 다른 버그 트래킹 시스템 3개, 사용자 니즈를 기술 요구사항으로 번역하는 명확한 프로세스 부재, 그리고 문서화되지 않고 사람들 머릿속에만 있는 비즈니스 프로세스들. 동시에 개발해야 하는 복잡한 사용자 여정의 백로그는 가득했습니다.
이것이 나쁜 디자인이라는 뜻은 아닙니다. 현실의 복잡성입니다. 그러나 런칭이 3주 남았고, 개발자들이 “정확히 무엇을 빌드해야 합니까?”라고 묻는 상황에서는 아름다운 디스커버리 산출물만으로는 도움이 되지 않았습니다. 문제는 복잡성 그 자체가 아니라, 그 복잡성이 ‘번역 불가능’했다는 점이었습니다.

루이즈:
그리고 저의 경우에는 디스커버리에 참여하지 않은 채 알파 프로젝트로 들어가 디스커버리 산출물을 파일럿과 테스트가 가능하도록 ‘번역’하는 역할을 맡았습니다. 18개월짜리 프로젝트였고, 제가 경험한 프로젝트 중 가장 길었습니다. 긴 호흡의 로드맵 안에서 제 작업이 어떻게 구현될지를 장기적 전략으로 유지하며, 모멘텀과 체력을 끝까지 관리해야 했습니다. 제품매니저, 서비스오너, 딜리버리 매니저, 디자인 리드, 다른 분야 디자이너 등 매우 큰 팀 한가운데에서 혼자 있는 서비스디자이너로서 “좋다, 팀의 일을 보완하면서도 대비점을 만들 수 있도록 내 역량을 어떻게 가장 잘 투입할 것인가”를 스스로 설계해야 했습니다.

크리스틴:
이제 애자일 딜리버리를 위한 우리의 서비스디자인 가이드를 소개하겠습니다.
다음 주 바로 사용할 수 있는 일곱 가지 실전 도구입니다. 마감과 예산 제약 속에서 검증된 실제 기법입니다. 하지만 먼저, 여러분이 이 도구들을 보면서 머릿속에 하나 생각해 주셨으면 합니다. 서비스디자이너가 애자일 딜리버리 과정 전체에서 ‘처음에만 유용한 존재’가 아니라 ‘전 과정에서 필수적인 존재’라고 여겨진다면, 여러분의 조직에는 어떤 변화가 일어날 수 있을까요? 그것이 우리가 도와드리고자 하는 목표입니다.

루이즈:
하지만 어디서부터 시작해야 할지 막막할 수 있습니다. 새로운 프로젝트 단계에 들어간다면 아주 기본적이고 당연해 보이는 것부터 시작하는 것이 좋습니다. 가끔은 스스로에게 다시 돌아가 기본을 허락하는 것이 필요합니다.
첫째, 프로젝트 브리프를 읽으십시오. 작업 지시서, 입찰 제안서, 계약서 무엇이든 좋습니다. 꼼꼼히 읽어 어떤 약속이 이해관계자에게 되었는지 확인하고, 자신의 역할에 따라 그것을 어떻게 실현할 수 있을지 찾아야 합니다.

크리스틴: 
둘째, 프로젝트 팀에서 압도당하는 기분이 들 때는 자신의 직무기술서를 다시 읽으십시오. 자신의 역량과 책임이 어디까지인지 확인하고, 어떤 부분을 더 가져올 수 있을지 생각해야 합니다.

루이즈:
셋째, 디스커버리 자료를 소화하십시오.
앞서 말씀드린 것처럼 저는 디스커버리에 직접 참여하지 않은 채 그 산출물을 인수했습니다. 그래서 저는 항상 이렇게 돌아가 확인합니다. 마스터 덱은 있는가? 리서치는 어디에 있는가? 산출물, 사용자 니즈, 에픽, Jira 보드 같은 것들은 어디에 있는가? 이런 것들을 다시 훑어보면서 내가 어떤 것을 물려받았고 어떤 기반 위에서 일하는지를 파악한 뒤, 그것을 토대로 새롭게 구축하는 것이 중요합니다. 처음부터 다시 시작해야 한다는 압박을 느낄 필요가 없습니다.

크리스틴: 
저에게 큰 도움이 되었던 또 다른 방법은, 애자일 팀에서 홀로 있는 서비스디자이너일 때 커뮤니티에 손을 뻗는 것이었습니다. 프로젝트에서 유일한 서비스디자이너일 수도 있습니다. 그렇다면 동료 서비스디자이너들이나 디스커버리, 알파, 베타 단계를 경험한 다른 사용자 중심 디자인 전문가들과 교류해 보십시오. 그들의 맥락과 교훈을 배우고, 그것을 자신의 상황에 적용할 수 있습니다.

루이즈:
마지막으로, 잠재적인 활동 목록을 미리 정리해 두는 것도 도움이 됩니다. 지금까지 말씀드린 과정을 거친 뒤 “이것들이 유용하겠다”라고 생각되는 활동을 뽑아 하나의 리스트로 정리하는 것입니다. 오늘은 알파와 그 이후 단계에서 우리가 실제로 유용하게 사용했던 몇 가지 사례를 더 깊이 다뤄보겠습니다.

크리스틴:
앞서 언급했듯이, 우리는 다음 주부터 바로 활용할 수 있는 일곱 가지 실용적인 도구를 정리했습니다. 이제 하나씩 더 자세히 살펴보겠습니다.
첫 번째 도구는 가정을 기록하고 가설로 발전시키는 것입니다. 기본으로 돌아가겠습니다. 가정이란, 사실로 믿고 있지만 아직 검증되지 않은 것입니다. 예를 들어 “사용자는 이 내비게이션을 이해할 것이다”라든가 “사람들은 문서를 업로드하고 싶어 할 것이다” 같은 것입니다. 가설은 이런 가정을 검증 가능한 형태로 바꾼 것입니다. “우리는 사용자가 메인 내비게이션을 직관적으로 이해할 것이라 믿는다. 왜냐하면 그것이 익숙한 패턴을 따르기 때문이다. 사용성 테스트에서 작업 완료율이 80% 이상일 때 이 가설이 옳음을 알 수 있다.” 이런 식입니다.
그렇다면 가정은 프로젝트 전반에서 어디에 숨어 있을까요? 정부 디지털 신청 양식 프로젝트를 예시로 들어보겠습니다. 디스커버리 단계에서는 모든 가정을 기록하고 질문하며 잘 관리했습니다. 그런데 알파에 들어가자 갑자기 기술적 제약을 가정하기 시작했습니다. “레거시 시스템은 실시간 업데이트를 처리할 수 없다” 같은 것입니다.
또 사용자 행동에 대해서도 “사용자는 당연히 큰 파란 버튼을 먼저 누를 것이다”라는 가정을 했지만 기록하지 않았습니다. 베타에 이르자 성능에 대한 가정이 생겼습니다. “부하가 걸려도 괜찮을 것이다, 사용자는 그냥 적응할 것이다” 같은 것입니다.
여기서 핵심 통찰은, 가정은 디스커버리에서 끝나는 것이 아니라는 점입니다. 단지 형태가 달라질 뿐이며, 각 단계마다 새로운 불확실성이 등장한다는 것입니다.
제가 참여한 프로젝트에서는 ‘기록’이 안전망이 되었습니다. 컨플루언스에 산출된 ‘살아 있는 문서’로서 프로젝트와 함께 움직였습니다. 우리가 알고 있는 것과 가정하고 있는 것을 분리해 기록했고, 덕분에 향후 평가 패널에서도 증거 자료로 활용할 수 있었습니다.

루이즈:
두 번째 도구는 사용자 스토리 개발입니다. 다시 기본을 짚어보겠습니다. 사용자 스토리는 디스커버리 단계에서의 리서치에서 도출된 니즈로부터 나옵니다. 보통 이런 형식을 따릅니다. “나는 (사용자 유형)으로서 ~이 필요하다. 왜냐하면 ~을 하기 위해서이다.” 이런 형식입니다. 이 스토리들은 보통 스프레드시트 같은 한 곳에 모아 팀 전체가 접근하고, 사용자 니즈를 공유하는 데 사용됩니다. 또한 디자인 활동의 초점을 잡는 데 큰 도움이 됩니다.
서비스디자인이 사용자 스토리를 이어 받았을 때 유용하게 기여할 수 있는 방법 중 하나는 그것들을 ‘매핑’하는 것입니다. (감사합니다, 제가 클릭을 잊었네요.) 매핑이란, 예를 들어 여기 보이는 분홍색 박스로 표시된 사용자 스토리들을 사용자 여정이나 블루프린트와 연결하는 것입니다. 이는 어떤 여정 단계에 니즈가 집중되어 있는지, 어디에 더 많은 디자인 작업이나 테스트가 필요한지, 지식격차가 얼마나 되는지 등을 드러내 줍니다. 또한 특정 여정에 왜 니즈가 없는지, 추가 리서치가 필요한 영역은 어디인지 알 수 있습니다. (슬라이드에 ‘a good bird’라고 표시가 있는데, 사실은 원래 화살표였는데 오류로 저렇게 표시된 것입니다. 좀 당황스럽네요.)

크리스틴:
세 번째 도구는 ‘빠른 프로토타이핑’입니다. 가정을 시험하기 위한 빠르고 거친 방식이어야 합니다. 서비스디자이너는 사용자 중심 디자이너뿐만 아니라 애자일 팀의 모든 구성원을 참여시켜야 합니다. 결과물이 처음부터 화려하거나 기능적일 필요는 없습니다.

루이즈:
제가 참여했던 알파 프로젝트에서는 서비스디자이너로서 프로토타이핑의 전략과 방향을 주도했습니다. 주로 사용자 리서치 활동으로 활용했으며, 사용자 리서처와 함께했고 UX 디자이너는 이전 작업에서 가져온 화면을 빠르게 조합해 초기 아이디어와 위험한 가정을 검증하는 데 사용했습니다.
예를 들어, 우리는 알파 단계에서 “아무도 스프레드시트를 좋아하지 않을 것이다. 보기 흉하고, 너무 수동적이며, 협업이 불가능하다”라는 가정을 했습니다. 그런데 우리는 프로토타입을 통해 다양한 시각적 대안을 사용자에게 보여주고 어떤 형식을 기대하는지를 물었습니다. 놀랍게도 많은 사용자가 “나는 지방자치단체에서 일하고 있는데, 동료들과 늘 Microsoft 365 기반 스프레드시트를 쓴다. 협업도 가능하다”라고 답했습니다. 이 결과로 우리는 새 포털을 빌드하지 않아도 된다는 결론을 내렸고, 사람들이 익숙한 도구로 문제를 해결할 수 있었습니다. 디자이너로서는 아쉬웠지만, 사용자 관행에 맞추면서 시간과 예산을 절약할 수 있었습니다.

크리스틴:
저는 그 반대입니다. 디자이너이자 사서로서, 사실 좋은 스프레드시트를 굉장히 좋아합니다.
이제는 베타 단계에서의 빠른 프로토타이핑과 스토리보딩 사례를 소개하겠습니다. 다시 정부 디지털 포털 프로젝트입니다. 우리가 베타에서 직면했던 문제는, 재방문 사용자를 위한 랜딩 페이지가 잘 작동하지 않았다는 점입니다. 사람들이 혼란스러워했고, 실수를 반복했으며, 이 상태가 유지된다면 지원팀은 쏟아지는 문의로 마비될 상황이었습니다.
해결책은 문제를 추상적으로 설명하는 대신 두 가지 사용자 시나리오를 위한 로파이(LOFI) 프로토타입을 만드는 것이었습니다.
첫 번째 유형은 자기 신청서를 다시 확인하는 재방문 사용자이고, 두 번째 유형은 자신의 신청서와 다른 사람(예: 부모님)의 신청서를 함께 확인하는 사용자였습니다. 프로토타입은 의도적으로 거칠고 빠르게 제작했습니다. NHS와 GDS 프로토타이핑 키트를 사용해 일관성을 유지했고, 화려한 비주얼이 아니라 상호작용 패턴에 집중했습니다. 중요한 차이는 로파이 프로토타입은 화면이 어떻게 보이는지를 보여주는 데 그쳤지만, 스토리보드는 실제 사용자가 그 화면을 어떻게 이동하며 사용하는지를 보여주었다는 점입니다. 예를 들어, “사용자가 여러 신청서를 다루면서 마찰을 경험한다”라고 말하는 대신, “이해관계자 사라는 본인의 신청서를 찾으려고 로그인했지만 동시에 대리인으로 제출한 어머니의 신청서도 확인해야 했다”라는 구체적 상황을 시각화할 수 있었습니다.
이 접근법의 힘은 사용자 행동을 추측하지 않고 직접 관찰하고, 빠르게 반복하며, 인사이트를 곧바로 개발자에게 전달할 수 있었다는 데 있었습니다.
좀 더 간단하고 전달하기 쉬운 예로는, 다른 프로젝트의 베타 단계에서 Figma를 활용한 빠른 프로토타이핑이 있습니다. 이 프로젝트는 중앙정부 부처 데이터 분석가들을 위한 R Shiny 대시보드 플랫폼을 만드는 일이었습니다. 알파 단계에서 만든 프로토타입을 기반으로, 베타에서는 Figma를 활용해 전체 사용자 여정을 인터페이스 프로토타입으로 연결했습니다. 데이터 분석가가 경험하는 모든 접점마다 실제 사용자와 테스트할 수 있었습니다. 차별점은 개념을 시험한 것이 아니라, 실제 인프라와 연결된 실제 워크플로를 테스트했다는 점이었습니다. 하지만 여전히 사용자 피드백을 바탕으로 빠른 반복이 필요했습니다. Figma 덕분에 며칠이 아닌 몇 시간 안에 프로토타입을 만들 수 있었습니다.
예컨대 데이터 분석가들이 대시보드 요청 양식을 이해하지 못해 혼란스러워했을 때, 그날 오후 바로 프로토타입을 업데이트했고 다음날 새로운 버전을 테스트할 수 있었습니다.
최근에는 AI를 활용해 몇 분 만에 업데이트하는 실험도 하고 있습니다. 이렇게 해서 “대시보드를 만들어야 한다”라는 초기 단계부터 실제 인터페이스 배포까지 전체 흐름을 테스트했고, 그 결과를 모두 개발자에게 전달했습니다. 이처럼 서비스디자인은 제품 생애주기의 베타 단계에서도 실제 사용자 니즈와 기술 구현을 잇는 다리 역할을 하며 매일 사용하는 사람들에게 제대로 작동하는 서비스를 만드는 데 기여했습니다.

루이즈:
다음으로 유용한 도구는 서비스 비전을 정의하는 것입니다. 디스커버리 단계에서 이미 비전을 만들지 않았다면, 지금이 좋은 시기입니다. 포스트 디스커버리 단계에서 팀을 하나로 모으고, 모두가 무엇을 향해 일하는지 몇 문장으로 정리해 정렬시키는 데 매우 유용합니다. 이를 통해 모든 사람이 같은 방향을 바라볼 수 있습니다. 대표적인 프레임워크가 VOST 모델입니다. 비전(vision), 미션(mission), 성과(outcomes), 전략(strategy), 전술(tactics)로 구성되며, 맨 꼭대기의 비전을 중심으로 모든 요소가 흘러내리지만 결국 비전으로 이어집니다.

루이즈:
제가 참여한 프로젝트에서는 이를 변형해 VOGG 모델을 만들었습니다. 비전(vision), 미션(mission), 성과(outcomes), 목표(goals)로 구성했으며, 특히 회계연도 목표와 연계하는 데 효과적이었습니다. 이 모델을 통해 팀 전체가 동일한 목표에 집중할 수 있었고, 회계연도가 끝난 뒤에는 새로운 상황에 맞게 내용을 업데이트했습니다. 이러한 것들은 한 번 정해지면 고정되는 것이 아니라, 주기적으로 돌아보고 갱신할 가치가 있다는 점을 다시 강조하고 싶습니다. 프로젝트에는 늘 팀원이 들어오고 나가지만, 모두를 하나로 묶어주는 기준점이 반드시 필요합니다.

크리스틴:
이제 다섯 번째 도구인 서비스 블루프린트를 소개하겠습니다. 서비스 블루프린트는 흔히 디스커버리 단계에서 개발되는 경우가 많습니다. 디스커버리 마지막에 디자이너로부터 블루프린트를 받았을 수도 있고, 그렇지 않을 수도 있습니다. 받았다면 대체로 높은 수준의 개략적 형태에 머무는 경우가 많습니다. 알파 이후 단계에서는 실제 서비스가 처음부터 끝까지 어떻게 작동할지를 더 세부적으로 정리하고 문서화해야 합니다. 

루이즈:
제가 합류한 프로젝트에서도 디스커버리에서 블루프린트를 물려받았는데, 알파 단계에서는 그것을 활용해 사용자 스토리, 에픽, 문제를 매핑했습니다. 이를 통해 알파 초기 회의에서 “우리는 어디에 집중해야 하는가, 무엇부터 시작해야 하는가, 에너지를 어디에 쏟아야 하는가”를 논의할 수 있었습니다. 하지만 베타에 가까워질수록, 그 블루프린트가 너무 고수준이고 거의 이상적인 상태만 담고 있다는 것을 깨달았습니다. 실제 사용자와 파일럿을 진행하려면 더 구체적인 내용이 필요했습니다. 그래서 저는 다시 세부 블루프린트를 작성하며 다른 프로그램과의 연계, 지원 문서, 파일럿에서 주시할 부분 등을 추가했습니다. 또 한 단계 더 나아가 프로세스 맵을 만들고, 제품 오너와 긴밀히 협력해 구체적인 흐름을 상자 단위로 정리했습니다. 이를 통해 서비스디자인적 사고와 방법론을 제품 개발에 녹여낼 수 있었습니다. 그리고 이 문서는 신규 팀원의 온보딩 자료로도 유용했으며, 학습에 따라 지속적으로 업데이트해 팀 전체가 현재 서비스 상태와 변화 과정을 쉽게 확인할 수 있도록 했습니다.

크리스틴:
이제 베타에서 라이브로 전환하는 과정을 소개하겠습니다. (슬라이드에 또 ‘a good bird’라는 이상한 문구가 보이네요. 랜덤으로 생긴 오류 같습니다.) 왼쪽에는 베타 단계의 서비스 블루프린트가 보입니다. 이는 루이즈가 말한 프로젝트가 아니라, 데이터 분석가와 R Shiny 대시보드 여정을 다룬 프로젝트입니다. 왼쪽의 베타 블루프린트는 비교적 단순했습니다. 데이터 분석가와 대시보드, 기본 요청 프로세스가 담겨 있었고, 하나의 개념이 작동하는지를 검증하는 것이 초점이었습니다. 흔히 그렇듯이, 이 블루프린트는 모든 것이 잘 작동한다고 가정하는 ‘행복 경로(happy path)’를 그린 것이었습니다. 그러나 라이브 단계로 전환하면서, 저는 실제로 발생할 수 있는 모든 상황을 고려해야 했습니다. 따라서 라이브 블루프린트는 완전한 엔드 투 엔드 여정으로 구성했습니다.
라이브 블루프린트에는 일곱 단계와 여러 개의 스윔레인이 있었습니다. 프런트 스테이지에는 데이터 분석가들이 실제로 경험하는 과정이 담겨 있고, 백스테이지에는 AWS 프로비저닝, 보안, 배포 과정이 있었습니다. 겉으로 보기에는 베타 블루프린트와 비슷해 보일 수 있습니다. 하지만 실제로는 단순히 베타 단계의 프로세스와 블루프린트를 그대로 확장할 수 없었습니다. 라이브로 전환하면서는 MVP의 한계를 솔직하게 인정해야 했습니다.
사실 이런 작업을 더 일찍 했으면 좋았겠지만, 이 프로젝트에서는 라이브 전환 시점이 그런 기회였습니다. 예를 들어, 베타에서는 문제가 생겼을 때 서비스 데스크에 슬랙 메시지를 보내는 정도로 충분했을 수 있습니다. 하지만 라이브에서는 자동 모니터링과 명확한 응답 시간을 반드시 갖춰야 했습니다. 저는 이를 개발자와 기술 아키텍트와 함께 일하면서 배웠습니다.

또 블루프린트 오른쪽에도 여전히 가정이 들어 있었습니다. 예를 들어 데이터 분석가들이 충분한 GitHub 지식을 가지고 있을 것이라는 가정이 있었습니다. 그러나 이는 라이브 서비스의 성패를 가를 수 있는 가정이었고, 실제로 검증이 필요한 부분이었습니다.
이렇게 되니 팀 전체가 “라이브로 전환할 때 우리가 무엇에 기대고 있는가”를 이해할 수 있었습니다. 위험 대응을 위한 스윔레인에는 “요청이 거절되면 어떻게 할 것인가?”, “GitHub이 실패하면 어떻게 할 것인가?”, “성능에 문제가 생기면 어떻게 할 것인가?” 같은 상황을 기록했습니다.
즉, 베타 단계에서는 에지 케이스를 다루었다면, 라이브 단계에서는 운영 현실을 반영해야 했던 것입니다. 제가 현장에 있으면서 개발자와 기술 아키텍트와 나란히 작업했기 때문에 전환 계획에 실제 가치를 더할 수 있었고, 사용자 리서치 산출물이 거의 운영 블루프린트처럼 활용되어 팀과 운영 직원이 실제 서비스 경험을 제공하는 데 도움이 되었습니다.

루이즈:
또 하나 유용한 도구는 서비스 임팩트를 어떻게 포착하고 측정할 것인가입니다. 솔직히 말하면 저는 이 부분이 가장 어렵습니다. 제가 분석가적 사고가 부족하기 때문에 느끼는 것입니다만, 서비스디자이너가 가장 큰 가치를 더할 수 있는 영역 중 하나라고 생각합니다.
서비스디자인의 본질이 바로 서비스 자체를 설계하는 일이기 때문입니다. 여기서 유용한 출발점은 앞서 언급한 비전에서 성과(outcomes)로 내려와 KPI, 즉 핵심 성과 지표를 이 성과와 연결하는 것입니다. 정성적 지표와 정량적 지표를 모두 고려해야 합니다. 저는 정량적 지표를 다루는 것이 특히 어렵다고 느끼지만, 이럴 때는 데이터 분석가, 사용자 리서처, 또는 제품 오너 같은 전문가에게 도움을 구할 수 있습니다. 그들과 함께 어떤 지표가 의미 있는지 정의할 수 있습니다. 이렇게 정의된 지표가 있으면, 서비스디자이너는 이해관계자에게 자신이 만든 서비스의 가치를 설명할 수 있고, 실제로 의도했던 효과를 달성하고 있는지 확인할 수 있습니다. 한 번 서비스가 라이브되면, 이런 지표는 서비스의 성과를 측정하는 기본 표준이 됩니다. 이를 기반으로 서비스를 지속적으로 개선할 수 있습니다. 세상에 나온 서비스가 있다고 해서 끝나는 것이 아니기 때문입니다.
제가 참여했던 프로젝트에서는 이 과정을 다른 디자인 태스크처럼 다뤘습니다. 가상 공간에서 관련된 사람들을 모아, 프로젝트 초기에 정의했던 성과를 다시 검토했습니다. 그리고 “우리가 약속한 성과를 어떻게 측정할 것인가? 어떤 지표를 사용할 것인가? 데이터를 어떻게 수집할 것인가? 데이터 협약이나 채널이 필요한가? 마지막으로 누가 데이터를 모으고 해석할 책임을 질 것인가?” 같은 질문을 다뤘습니다. 실제 서비스가 라이브된 뒤에는, 초기 성과 지표들이 이상적이고 추상적인 경우가 많다는 것도 알게 되었습니다. 그래서 우리는 다시 돌아가 지표를 조정하며, 적절한 방법과 형식, 채널, 담당자를 마련하고 있습니다. 그래야만 서비스 런칭의 성과를 실제로 축하할 수 있기 때문입니다.

크리스틴:
이렇게 해서 도달한 것이 일곱 번째 도구입니다. 사용자 니즈를 기능 요구사항으로 번역하는 것입니다. 사용자 리서치 인사이트를 개발자와 기술 아키텍트가 실제로 빌드할 수 있는 형태로 바꾸는 일입니다. 기본부터 다시 설명드리겠습니다. 사용자 니즈는 사용자가 달성하려는 근본적인 문제, 목표, 결과를 말합니다. 사용자 관점에서 표현되며, 무엇을 필요로 하고 왜 필요한지를 담습니다. 때로는 감정적이고 맥락적이며 일상 언어로 표현됩니다. 반면 기능 요구사항은 시스템이 그 니즈를 충족하기 위해 어떻게 동작해야 하는지를 기술적으로 명확히 설명하는 것입니다. 개발자가 빌드할 수 있는 구체적 지침입니다.

제가 배운 것은, 단순히 사용자 니즈 목록을 개발자에게 던져주어서는 생산적이지 않다는 점입니다. 개발자가 무엇을 만들어야 하는지 알 수 없기 때문입니다. 마찬가지로 사용자 니즈를 이해하지 않은 채 기능 요구사항만 만들면 잘못된 것을 빌드하게 됩니다. 따라서 이 ‘번역’ 과정이 서비스디자인이 딜리버리 과정 전반에서 가치를 입증할 수 있는 핵심입니다. 사용자의 실제 니즈를 이해하지 못하면 결과물이 제대로 작동할 수 없기 때문입니다. 그래서 저는 이 프로젝트들에서 사용자 니즈를 체계적으로 분석해 개발자가 바로 적용할 수 있는 기술 요구사항으로 전환하는 작업을 해왔습니다.

제가 이 ‘번역’을 어떻게 해왔는지 말씀드리겠습니다. 저는 Jobs to be Done 프레임워크의 큰 팬입니다. 이를 R Shiny 대시보드 서비스를 사용하는 데이터 분석가 유형에 적용했습니다. 데이터 분석가가 반드시 수행해야 할 다섯 가지 핵심 업무는 다음과 같았습니다. 첫째, 관련 데이터를 탐색하고 접근하기. 둘째, 대시보드를 개발하고 반복하기. 셋째, 대시보드를 안전하게 공유하고 발행하기. 넷째, 성능을 모니터링하고 유지하기. 다섯째, 동료와 협업하며 피드백 받기.

저는 이를 스토리보드로 시각화했습니다. 화면 아래쪽에서 보실 수 있는데, 실제 데이터 분석가가 대시보드를 개발하는 과정을 어떻게 거쳐가는지 보여줍니다. 이건 이론적인 것이 아니라, 초기 리서치와 테스트에서 관찰한 워크플로 패턴을 포착한 것이었습니다. 각 업무는 기술적 역량과 인터페이스 기능에 매핑되었고, 이를 통해 중요한 워크플로가 누락되지 않도록 했습니다. 그리고 이 고수준의 업무들을 다시 내러티브로 쪼개어, 데이터 분석가가 실제로 해야 하는 다양한 측면을 담았습니다.

그 과정에서 영감을 얻은 것이 카드덱 형식이었습니다. 당시 아들과 UNO 게임을 자주 했는데, “이걸 카드덱으로 만들면 어떨까?” 하는 아이디어가 떠올랐습니다. 그래서 내러티브를 개발자와 기술 아키텍트가 함께 사용할 수 있는 잡 스토리 카드덱으로 바꿨습니다. 디지털 카드덱이었고, 다섯 가지 핵심 업무에 따라 나누었습니다. 각 스토리는 “When I… I want to… So that…” 형식으로 작성되어 맥락, 사용자가 해야 할 행동, 원하는 결과를 분명히 했습니다.

이 접근법은 사용자 요구를 일관성 있게 구조화하고 패턴을 파악할 수 있게 해주었습니다. 개발자들이 추상적인 사용자 니즈 보드를 해석하는 대신, 정확하고 검증 가능한 요구사항을 받아들여 기술적 해결책을 설계할 수 있었습니다. 개발자들은 이 카드들을 보고 어떤 기능을 만들어야 하고 그것이 사용자에게 왜 중요한지를 즉시 이해할 수 있었습니다.
이 역시 서비스디자인이 딜리버리 전 과정에서 가치를 더하고, 사용자 중심 사고를 기술 구현 단계까지 살아 있게 만드는 사례였습니다.

이제 이 프로젝트들에서 실제로 어떤 결과가 있었는지 말씀드리겠습니다.
우리가 이 일곱 가지 도구를 적용했을 때, 연쇄적인 개선 효과가 나타났습니다.
우선, 정부 온라인 신청 포털 프로젝트에서는 분리되어 있던 세 개의 트래킹 시스템을 하나로 통합했습니다. 그 결과 개발 프로세스가 단순화되었고, 팀의 효율성이 즉시 개선되었습니다. 이 단순화된 프로세스는 곧 명확한 요구사항으로 이어졌습니다. 기억하시겠지만, 처음에는 수용 기준이 없는 사용자 스토리 62개가 있었습니다. 이를 정리하면서 개발자들이 “무엇을 만들어야 하는지”를 명확히 알게 되었습니다. 혼란도, 추측도 사라졌습니다.

요구사항이 명확해지자 이번에는 이해관계자 측에서도 변화가 생겼습니다. 스토리보드가 복잡한 상호작용을 단순하게 이해할 수 있게 만들어 주었습니다. 덕분에 긴 설명 회의를 할 필요가 없었고, 이해관계자들은 사용자 경험을 바로 눈으로 확인할 수 있었습니다. 제품 오너와 딜리버리 매니저의 의사결정 속도가 크게 빨라졌습니다.

이 모든 것이 모여 성공적인 베타 런칭을 가능하게 했습니다. 정부 디지털 신청 포털에서는 실제 사용자 니즈를 충족하는 정제된 MVP를 제공할 수 있었습니다. 완벽하지는 않았지만, 엄격한 테스트를 통해 최소한의 핵심 니즈를 충족한다는 점을 입증했습니다. 그리고 더 중요한 점은, 제품을 딱 런칭하고 “끝났다” 하고 떠나지 않았다는 것입니다. 우리는 포스트 라이브 팀이 지속적으로 개선할 수 있는 프로세스를 마련했습니다. 즉, 서비스가 라이브된 뒤에도 계속 발전할 수 있는 토대를 만든 것입니다.

결국 이 일곱 가지 도구는 단순히 있으면 좋은 디자인 활동이 아니라, 딜리버리 전 과정에서 측정 가능한 효과를 만들어내는 실용적 도구임을 보여주었습니다.

루이즈:
그래서 이 자리에 서비스디자이너가 계시다면, 다음에 디스커버리를 마칠 때 그냥 리서치 산출물을 넘기고 자리를 떠나지 마시기 바랍니다. 스스로에게 질문해 보십시오. “내 서비스디자인 사고가 이 팀이 더 빠르고, 더 잘, 더 적은 문제로 빌드하도록 어떻게 도울 수 있을까?” 진짜 임팩트는 그 시점에서 생깁니다. 서비스디자인이 더 이상 필요하지 않은 것이 아니라, 오히려 훨씬 더 필수적이 되는 순간입니다.
오늘 저희가 알파와 베타 단계에 걸쳐 적용할 수 있는 일곱 가지 실용 도구를 소개해 드렸습니다. 익숙한 것도 있었을 것이고 새로운 것도 있었을 것입니다. 프로젝트 팀에서 막힐 때마다 떠올리실 수 있기를 바랍니다.

크리스틴 & 루이즈: 경청해 주셔서 감사합니다.