(영상) '0'에서부터 디자인 성공으로: 뮤즈의 페르소나 재구축 사례 – 마리나 리코. 베를린 헬스컨퍼런스 2025.10.14.

뮤즈의 시니어 서비스디자이너 마리나 리코는 500명 규모의 R&D 조직에서 ‘페르소나’를 도입하려다 거의 아무도 사용하지 않는 실패를 겪었습니다. 이후 그녀는 문제의 원인이 단순한 툴이 아니라 ‘운영화(operationalization)’ 부재에 있음을 깨닫고, 협업 구조와 책임 체계를 재설계했습니다. 팀 간 공감과 실제 사용을 이끌기 위해 슬랙, 워크숍, 파일럿, 지라(Jira) 연동 등을 통해 페르소나를 업무 프로세스에 통합했습니다. 그 결과, 조직 전반에서 디자인 리서치가 실질적 의사결정 도구로 정착하며 고객 중심 문화가 확산되었습니다.

'0'에서부터 디자인 성공으로: 뮤즈의 페르소나 재구축 사례 – 마리나 리코. 헬스컨퍼런스 2025.10.14. 베를린
https://www.hatchconference.com/
From Zero Adoption to Design Success: Marina Rico on Fixing Personas at Mews (Hatch Conference 2025.10.14. Berlin, Silent Green Kulturquartier)
출처 : Hatch Conference https://www.youtube.com/@hatchconference
원본 영상 : https://www.youtube.com/watch?v=bPi7s8CTSa0
번역 : 챗GPT (요약, 생략, 오류가 있을 수 있습니다. 원본을 확인해주세요.)  

뮤즈(Mews)는 호텔 운영을 위한 클라우드 기반 소프트웨어 플랫폼 기업으로, 호텔의 프런트·예약·결제·객실관리 등 다양한 운영 시스템을 통합하고 자동화해, 숙박 산업의 디지털 전환을 지원하는 SaaS 기업입니다.

마리나 리코(Marina Rico)는 뮤즈의 시니어 서비스디자이너로, UX리서치와 디자인옵스(Design Ops)를 잇는 역할을 맡고 있습니다. 그녀는 조직 내 서비스디자인 프로세스를 구축하고, 리서치 인사이트를 실제 제품 전략에 반영하는 체계를 만드는 일을 담당합니다.
이 발표 「 '0'에서부터 디자인 성공으로 From Zero Adoption to Design Success」에서 마리나 리코는 실패한 페르소나 도입 사례를 되짚으며, 조직 규모가 큰 테크 기업에서 디자인 리서치와 협업이 실제로 작동하도록 만드는 운영적 설계(operational design)의 중요성을 강조했습니다.

---

도입 (Introduction)

안녕하세요, 여러분. 제 발표에 와주셔서 감사합니다.
꽤 많은 분들이 오신 것 같아서, 아주 친근한 분위기일 것 같습니다.
저를 초대해주신 Hatch에도 감사드립니다.

오늘 저는 하나의 이야기를 들려드리려 합니다.
이것은 우리가 ‘페르소나(Persona)’를 조직 내에 도입하려 시도했던 이야기이며,
그 과정을 통해 고객 인사이트를 기반으로 디자인하도록 만들고자 했던 시도에 관한 이야기입니다.

그리고 제가 ‘시도했다(tried)’라는 단어를 쓴 이유는, 사실 첫 번째 시도에서는 거의 ‘제로(0)’ 수준의 도입률을 기록했기 때문입니다.

이렇게 발표를 시작하다니 끔찍한 방식인 건 저도 압니다.
하지만 곧 좋아질 것이니 걱정하지 않으셔도 됩니다.

제 이름은 마리나 리코(Marina Rico)입니다.
저는 뮤즈(Mews)에서 시니어 서비스디자이너(Senior Service Designer)로 일하고 있습니다.

페르소나 도입의 어려움 (The challenge of implementing personas)

뮤즈에서 저는 디자인옵스(Design Ops) 부서에 속해 있습니다.
뮤즈의 디자인옵스는 UX 리서치(UX Research)와 서비스디자인(Service Design)으로 구성되어 있습니다.

혹시 뮤즈(Mews)를 모르시는 분들을 위해 간단히 설명드리면, 뮤즈는 클라우드 기반 소프트웨어로, 호텔이 운영을 간소화하고 고객 경험을 향상시키도록 돕는 플랫폼입니다. 우리는 세계를 더 환대(hospitable)하는 곳으로 만드는 것을 비전으로 삼은 스케일업(scale-up) 기업입니다.

이번 발표를 준비하면서 제가 여러분께 진짜로 전달하고 싶은 것은, 조직 안에서 어떤 것을 도입하려 할 때 그것이 얼마나 어려운 일인지에 관한 부분입니다. 우리의 경우, R&D 조직의 인원이 500명 이상이었습니다. 꽤 큰 조직이지요.

그래서 오늘은 우리가 어떻게 그 일을 시도했는지, 그 과정에서 어떻게 실패했는지, 그리고 어떻게 회복했는지를 이야기하려 합니다. 오늘 여러분과 함께 우리가 배운 점들—좋았던 점과 나빴던 점—을 함께 살펴볼 수 있다면 정말 좋겠습니다.

이야기의 시작으로 돌아가 보겠습니다.

지난 2월, 우리 조직은 리오거나이제이션(reorganization, 조직 개편)을 단행했습니다. 의도는 아주 단순했습니다.
고객을 더 전체적으로(holistically) 이해하고, 더 빠르고 명확하게(faster and cleaner) 의사결정을 내리려는 목적이었습니다.

그래서 우리는 흔히 알고 있는 제품 오너십(Product Ownership) 구조, 즉 트리오(trio) 형태에서 벗어나
호텔 사업장의 구조를 그대로 반영한 새로운 구조로 전환했습니다.

예를 들어,

• Front of House(프론트오브하우스)는 고객과 직접 또는 간접적으로 상호작용하는 모든 부분,
• Back of House(백오브하우스)는 운영의 중추로서 수익 및 비용 관련 모든 요소,
• Fintech(핀테크)는 거의 스핀오프처럼 작동하며,
  모든 고객이 원활하고 강력한 금융 서비스 및 결제 서비스를 이용할 수 있도록 보장하는 역할을 맡았습니다.
• 그리고 Platform(플랫폼) 부문이 있는데,
  바로 그곳이 디자인옵스(Design Ops)가 속한 부서입니다.
  우리는 나머지 모든 부문에 수평적 지원(horizontal support)을 제공하려 합니다.

첫 번째 시도의 실패 (What went wrong in the first release)

제품 쪽에서 일해본 분들이라면 공감하시겠지만, 요즘 세상은 점점 더 제품 중심(product-driven)으로 흘러가고 있습니다.
어느새 기능(feature)을 얼마나 빠르게 제공하고, 그 기능을 어떻게 측정하느냐가 더 중요해진 세상이 되어버렸습니다.

하지만 그 기능을 사람들이 어떻게 경험하는지는 그만큼 중요하게 다뤄지지 않습니다.
이건 서비스디자인을 하는 저 같은 사람에게는 매우 아쉬운 부분입니다.
우리는 어떤 것을 ‘만드는 사람’이지만, 그것이 실제로 어떻게 작동하는지, 사용자에게 어떤 경험을 주는지에 대해
충분히 집중하지 못하고 있기 때문입니다.

그래서 저는 이번 리오거나이제이션 관련 문서를 읽으며 굉장히 반가웠습니다.
거기에는 이렇게 쓰여 있었습니다.

“기능 중심의 부서가 아니라 사용자 페르소나(Persona)를 기준으로 구조를 설계한다.”

리더십 레벨에서 처음으로 ‘페르소나’라는 단어가 공식적으로 등장한 것이었습니다.
우리 팀에게는 아주 좋은 신호였지요.
우리가 실제로 서비스를 제공하는 사람들—즉, 고객—에게 더 가까이 다가가려 한다는 의미였으니까요.

그래서 디자인옵스팀은 이 ‘페르소나’를 조직이 고객 중심성(customer centricity)을 실현할 수 있는 핵심 도구로 만들기로 했습니다.

물론 이전에도 우리는 페르소나를 가지고 일하려 시도한 적이 있었습니다.
몇몇은 만들어져 있었지만, 그것이 실제로 얼마나 사용되고 있는지는 확신할 수 없었습니다.

그래서 우리는 먼저 현황 점검(pulse check)을 하기로 했습니다.
디자이너와 PMS(Product Management System) 팀 모두에게 설문을 보내어,
그들이 페르소나를 어떻게 사용하고 있는지, 얼마나 익숙한지를 파악하고자 했습니다.

처음에는 꽤 쉬웠습니다.
왜냐하면 우리가 설정한 카테고리들이 업계 표준을 그대로 반영하고 있었기 때문입니다.

그렇게 범주를 정리한 뒤, 우리는 스스로에게 물었습니다.
“좋아요, 그렇다면 이제 우리 조직에는 어떤 페르소나들이 존재하나?”
그런데 어느 시점에서 멈춰야 했습니다.
왜냐하면 처음 초안에서 36개의 페르소나가 나왔기 때문입니다.
“뭐라고요? 이건 너무 많잖아요.”
상황이 통제 불가능하게 흘러가고 있었죠.

그래서 우리는 숫자를 줄이기로 했습니다. 결국 24개로 압축했습니다.
오른쪽에서 보실 수 있는 것들이 실제로 우리가 완성한 프로필들입니다.
각 페르소나의 프로필을 매우 구체적이고 입체적으로(texture) 만들었습니다.
그래서 나중에 팀과 이야기할 때, 그들이 각 인물의 맥락을 명확히 이해할 수 있도록 했습니다.

우리는 템플릿을 갖췄고, 프로필을 완성했습니다.

이제 다음 단계는 공유와 확산(socialize)이었습니다.

우리는 수많은 슬랙(Slack) 채널을 만들었습니다.
그리고 R&D 내 모든 팀을 워크숍에 초대했습니다.
“이것이 여러분의 페르소나입니다. 이제 바로 사용할 수 있습니다.”라고 말했습니다.

우리는 또 Loom 비디오를 녹화했습니다.
그 영상에서 “이것이 고객 중심성을 높이는 데 페르소나가 어떻게 도움이 되는가”를 설명했습니다.

그리고 그것을 슬랙에 게시했습니다. 이건 저희 디렉터 디에고가 슬랙에 올린 글입니다.
“페르소나가 준비됐습니다!”

그랬더니 사람들은 정말 난리가 났습니다. 이모티콘이 쏟아졌고, 댓글이 폭주했습니다.
우리는 서로 하이파이브를 하며 “우와, 해냈다!” 했습니다.

하지만… 이 발표가 어떻게 시작됐는지 기억하시죠?
“거의 0에 가까운 도입률(near zero adoption)” 말입니다.

그 순간, 저는 속으로 생각했습니다.
“이제 내가 할 일은 다 했다. 그만두자.”
물론 실제로 그만두진 않았지만, 그때의 기분은 정말 그랬습니다.
다시 회사에 돌아오지 말아야겠다는 생각까지 들 정도였습니다.

저는 꽤 큰 좌절감을 느꼈습니다.
왜냐하면 사람들에게 “페르소나를 사용하고 있습니까?”라고 물었는데, 그들은 “아니요”라고 답했기 때문입니다.

저는 그들을 초대해 함께 페르소나를 공동 제작(co-create)했고,
그들이 직접 제안한 요구를 반영해 만들었지만, 정작 그들은 그것을 사용하지 않았습니다.

저는 꽤 화가 났습니다.
하지만 동시에, “여기엔 뭔가 이유가 있을 거야”라고 생각했습니다.
이건 단순히 잘못된 시도가 아니라, ‘작동하지 않는 무언가’가 있었던 것입니다.

그리고 그때 깨달았습니다.
우리가 잊은 것은 아니었지만, 운영화(operationalization) 단계에 충분히 주의를 기울이지 않았다는 점입니다.

우리는 너무 빨리 결과물을 만들어 
“여기, 페르소나가 있습니다. 이제 사용하면 됩니다.”라고 던져버렸습니다.
하지만 언제, 어떤 단계에서, 어떻게 사용해야 하는지, 그것이 어떤 가치를 주는지, 어떻게 실행 가능한 형태(actionable form)로 바꿀 수 있는지를 설명하지 않았습니다.

우리가 말로만 반복하던 바로 그 부분, “페르소나를 실행 가능한 형태로 만들어야 한다”는 부분을 잊어버린 것입니다.

그래서 우리는 조금 울었습니다. 그리고 나서 해야 할 일을 했습니다.
즉, 사람들과 다시 시작했습니다.

우리가 한 일은 세 가지입니다.

첫째, 동맹(ally)을 찾았습니다.
우리는 고통(pain)을 느끼고 있으면서도 의욕(appetite)이 있는 팀들을 골랐습니다.
항상 조직 안에는 디자인 마인드가 강하거나, 고객 중심성을 적극적으로 실천하려는 사람이 있기 마련입니다.
그들을 찾아서 우리의 동맹으로 삼았습니다.

그 과정에서 저는 처음 존재조차 몰랐던 사람들을 새롭게 알게 되었습니다.
예를 들어, 우리 조직 내에는 ‘Product Enabler’라는 직책을 가진 사람이 있었는데,
그가 우리를 다른 팀과 연결해주는 다리 역할을 해주었습니다.

또한 우리는 여러 팀이 수행해온 리서치에서 각 페르소나에 관한 세부 정보를 최대한 모았습니다.
그 결과, 우리의 페르소나들은 훨씬 풍부하고 현실적인 질감을 얻게 되었습니다.

둘째, 워크플로우 단계(workflow steps)를 추가했습니다.
어느 시점에서 우리는 이렇게 생각했습니다.
“우리가 직접 이걸 시스템에 녹이지 않으면 절대 작동하지 않겠구나.”

그래서 Jira Pro Discovery에 새로운 태그를 만들었습니다.
(이는 모든 제품 배포(delivery)를 관리하는 툴입니다.)

우리는 이렇게 규칙을 세웠습니다.

“어떤 화면도 ‘이 디자인이 누구를 위해 만들어졌는가(persona)’라는 태그 없이 배포될 수 없다.”

조금은 엄격하게 들릴 수도 있지만, 이 규칙 덕분에 사람들이 실제로 생각하게 되었습니다.
“내가 지금 디자인하는 이 기능은 누구를 위한 것인가?”

또한 같은 페르소나를 대상으로 일하는 여러 팀을 모아 서로의 인사이트를 교환하게 했습니다.
그 덕분에 각 팀은 자신이 놓치고 있던 관점을 새롭게 발견할 수 있었습니다.

이 두 가지가 결합되자 세 번째 현상이 일어났습니다.
바로 ‘사례(examples)’와 ‘작은 성공(victories)’이 생겨나기 시작한 것입니다.

우리는 이런 사례들을 적극적으로 소개했습니다. 
제가 직접 슬랙에 이렇게 메시지를 올렸습니다.

“여러분, 이미 페르소나를 실제로 적용하고 있는 팀들이 있습니다!”

사람들에게 “누군가는 이미 실행하고 있다”는 것을 보여준 것이죠.
그리고 실제로 세 가지 구체적인 사례가 나왔습니다.

사례 1.
우리 디자이너 엘렌(Elene)이 자신의 PMS 팀과 함께 아이데이션 세션을 진행했습니다.
그들은 자신들의 모든 페르소나와 Job-to-be-Done(해야 할 일)을 연결해, 각각이 화면 디자인에 어떻게 다른 영향을 주는지를 살펴봤습니다. 그 결과, 서로 다른 사용자 집단이 서로 다른 요구를 가지고 있음을 깨달았고, 이 인사이트를 기반으로 다음 분기 로드맵을 조정했습니다.

사례 2.
우리의 프린시펄 디자이너 다이애나(Diana)가 리서치를 수행했습니다.
보통은 리서치 후에 ‘Best Western’이나 ‘Choice Hotels’ 같은 일반 고객 사례를 중심으로 인사이트를 발표하곤 했습니다.
하지만 이번에는 달랐습니다. 그녀는 호텔의 프런트 에이전트(front agent)가 실제로 무엇을 원하는지, 그들의 시점에서 리서치 결과를 발표했습니다. 그건 아주 신선한 접근이었습니다.
사람들은 그 새로운 내러티브 방식에 열광했습니다.

사례 3.
또 다른 디자이너 애덤(Adam)은 ‘Glen’이라는 내부 시스템을 활용하기 시작했습니다.
Glen은 일종의 사내 검색 어시스턴트로, Miro, Slack, Confluence 등 모든 소스에서 정보를 불러올 수 있습니다.
그는 이를 통해 각 페르소나 관련 데이터를 연결하고 실제 프로젝트에 바로 활용할 수 있도록 만들었습니다.

이 모든 과정을 통해 우리는 배웠습니다.
페르소나를 성공적으로 정착시키려면 도구(tool)가 아니라, 관계, 책임, 행동(action)이 필요하다는 것을요.

그리고 무엇보다, ‘실패’를 솔직하게 공유하고 함께 배운 경험이 우리 조직의 디자인 문화(design culture)를 한층 성숙하게 만들었습니다.
이것이 바로 “제로 도입률에서 디자인 성공으로” 가는 우리의 여정이었습니다.
그래서 저는 앞으로의 의사결정, 이 경우에는 권한 관리(permissions)나 ID 매니저와 관련된 의사결정에 도움이 될 수 있는 피드백을 제공할 수 있었습니다.

제가 그 메시지를 보낸 후, 갑자기 조직의 분위기가 바뀌기 시작했습니다.
이전에는 “제 디자인옵스 워크숍에 오세요, 제발요” 같은 느낌이었다면,
이제는 “여러분 팀에 이런 이익이 있습니다. 이렇게 실제로 적용할 수 있습니다.”라는 접근으로 바뀐 것입니다.

그건 단지 세 가지 사례에 불과했습니다.
사실 그 외에도 훨씬 많은 사례들이 프로세스 안에 정리되어 있었지만, 그 세 가지 예시만으로도 사람들에게 그 가치가 충분히 전달되었습니다.

그때부터 우리는 마침내 터널 끝에 빛이 보이기 시작했습니다.
저는 정말 기뻤습니다.

그런데 정말 재미있는 일이 벌어졌습니다.
매우 인간적인 반응이었지요. 다른 팀들이 이렇게 말하기 시작했습니다.
“어? 저 팀이 페르소나를 쓰고 있네? 우리도 어떻게 활용할 수 있을까?”

그들은 페르소나의 활용이 흥미롭다고 느꼈고, 이제는 로드맵에 무엇을 포함해야 할지를 더 폭넓게 사고하기 시작했습니다.
또 특정 페르소나만을 염두에 두고 편향되게 디자인하지 않으려는 시도도 보였습니다.

그렇게 하다 보니, 어느 순간부터 저는 요청이 폭발적으로 늘어나기 시작했습니다.
예를 들어 이런 요청들이었습니다.
“저희 팀이 지금 비전을 수립 중인데요, 페르소나를 기반으로 어떤 스토리를 만들 수 있을지 이야기할 수 있을까요?”
또는,
“우리 회사에서 자금을 관리하는 사람들에 대해 더 알아야 할 것 같습니다. 핀테크 관련 페르소나에 대해 더 배우고 싶습니다.”
혹은 더 나아가,
“저희 팀에 관련 정보가 있고, 페르소나를 다듬고 싶어하는 디자이너들이 있습니다. 그들과 연결해주실 수 있나요?”
이런 식으로 협업 요청이 잇따랐습니다.

어느 시점에서는 우리 팀이 회사 전체 주간 회의인 ‘부시(Bush)’ 세션에도 초대되었습니다.
이 회의는 전 직원이 참여하는 자리입니다.

그때부터 주요 리더십과 임원급 인사들이 우리를 주목하기 시작했습니다.
심지어 CEO인 맷(Matt)도 회의 중에 우리를 언급했습니다.
이제 이 주제가 조직 전체에서 폭넓게 논의되는 수준으로 확산된 것이었습니다.

정말 성공적인 순간이었고, 처음으로 “이제 잘 되고 있구나”라는 실감을 할 수 있었습니다.

하지만 동시에, 제대로 작동하기 시작하자 ‘아직 부족한 부분들’도 보이기 시작했습니다.
우리는 완전히 바닥까지 떨어졌던 시점에서 출발했지만, 조금씩 개선되어 왔습니다.
그럼에도 불구하고 우리는 여전히 ‘정상(peak)’에 도달하고 싶었습니다.

그래서 지금도 그 과정을 계속 진행 중입니다.
9월 말에서 10월 초까지는 우리가 발견한 문제점들을 해결하기 위한 계획을 모두 구현할 수 있기를 바라고 있습니다.

현재 우리가 추진 중인 개선 과제는 세 가지입니다.

첫째, 디스커버리 폼과 근거 링크(Discovery forms and links to evidence)입니다.
이제 R&D 팀이 특정 페르소나를 대상으로 리서치나 디스커버리를 요청할 때는 그 요청이 반드시 우리를 거치게 됩니다.

우리는 우선순위 평가 기준(criteria of prioritization)에 따라 어떤 요청이 더 중요하고 시급한지를 판단하고,
그 우선순위에 따라 리서치를 수행합니다.

그 결과로 얻은 모든 인사이트는 Confluence에 저장됩니다.
그래서 누구나 언제든 그 링크를 통해, 즉 인사이트의 원천(source)으로 다시 돌아가 확인할 수 있습니다.

둘째, 워크플로우 설계(Workflow design)입니다.
우리는 이제 어떤 단계에 있든 상관없이 누구나 자신의 ‘페르소나 여정(Persona Journey)’에 맞게 도움을 받을 수 있는 흐름을 만들었습니다.

즉,
“나는 내 페르소나가 누구인지 모르겠다”는 사람부터,
“나는 이미 정보를 가지고 있고 페르소나에 기여하고 싶다”는 사람까지
모두 지원할 수 있는 프로세스입니다.

이를 위해 우리는 영국(London)에서 개발된 AI 에이전트를 도입했습니다.
이 AI는 각 사용자가 어디서 출발하든, 적절한 방향으로 안내해주는 역할을 합니다.

어떤 경우에는 Confluence 페이지로 연결될 수도 있고,
어떤 경우에는 이메일을 보내 우리 디자인옵스팀의 지원을 받는 방식이 될 수도 있습니다.

이 시스템은 앞으로 더욱 자동화되어, 사람들이 명확한 출발점(concrete starting point)에서 시작할 수 있도록 도울 것입니다.

셋째, 책임 및 거버넌스 규칙(Ownership and governance rules)입니다.
우리는 이것을 만드는 데 정말 많은 시간이 걸렸습니다.

처음 시작할 때 우리는 조금 안일하게 접근했습니다.
“아, 페르소나를 만들어보자. 이미 어느 정도 기반은 있잖아.” 
이런 식으로 시작했지요.

그런데 곧 깨달았습니다. 이건 정말 엄청나게 큰 작업이었습니다.

그래서 우리는 명확한 담당자(contact point), 명확한 프로세스(process)가 필요했습니다.

“언제 업데이트할 것인가?”
“UX 리서치 팀은 어느 부분을 맡고, 서비스디자인 팀은 어떤 역할을 담당할 것인가?”
“비슷한 요구를 가진 팀들이 있을 때, 어떻게 연결할 것인가?”

이런 모든 것들을 이제는 문서로 명확히 정리했습니다.
그리고 감사하게도 지금은 그 프로세스를 잘 따르고 있습니다.

이것이 현재 시점의 모습입니다.
우리의 파이프라인(pipeline)을 보면, 꽤 바쁩니다. 요청이 정말 많습니다.

그중 일부는 이미 진행 중이고, 일부는 완료된 상태입니다.
예를 들어 CFO 페르소나는 지난주에 마무리되었습니다.
그리고 이제 곧 “Longest Stay(장기 숙박자)” 페르소나를 시작할 예정입니다.

할 일이 많다는 건 좋은 일입니다.

이것이 이야기의 끝입니다. 정확히 말하면 ‘끝’이라기보다, 현재의 시점입니다.

지금까지 우리가 겪은 모든 과정을 공유했으니, 이제 여러분과 나누고 싶은 것은 우리가 얻은 교훈입니다.
여러분이 비슷한 시도를 할 때 도움이 되길 바랍니다.

“무엇을 다르게 했어야 할까요?”

다시 시작한다면, 저는 세 가지를 반드시 다르게 할 것입니다.

첫째, 모든 협업에서 ‘가치 교환(value exchange)’을 명확히 할 것.

어느 시점에서부터 사람들은 단지
“캘린더에 잡혀 있으니까 워크숍에 참석해야지.”
이런 이유로 참여하고 있었습니다.

그런데 이런 태도로 참여하는 것과,
“나는 지금 이 워크숍에서 앞으로 사용할 툴을 직접 만들고 있다.
이 도구는 수많은 의사결정에 영향을 줄 것이다.”
라는 인식으로 참여하는 것은 완전히 다릅니다.

우리는 그 ‘가치’를 구체적으로 설명하지 못했습니다.
다시 시작한다면 저는 훨씬 단순하고 명확하게 말할 것입니다.

“이제부터 우리는 페르소나를 도입합니다.
그로 인해 생기는 이점은 A, B, C입니다.
여러분의 디자인 프로세스에서 이렇게(X, Y 단계에서) 사용할 수 있습니다.
이것이 여러분이 얻을 수 있는 구체적 가치입니다.”
즉, 혜택을 구체적으로 말하라.
이것이 첫 번째 교훈입니다.

둘째, 커뮤니케이션은 콘텐츠만큼 중요하다.

우리는 큰 실수를 했습니다.
너무 ‘넓게(broad)’ 퍼뜨리려 했던 것입니다.
영상도 만들고, 슬랙에도 올리고, 전사 공지도 했습니다.

하지만 정작 중요한 운영화(operationalization) 단계를 간과했습니다.

우리는 그 과정을 일방향(cascade)으로 흘려보냈습니다.
다시 시작할 수 있다면, 저는 그렇게 하지 않을 것입니다.

아마 작은 규모로,
한 팀과 함께 파일럿(pilot)부터 시작했을 것입니다.
그 팀의 필요를 살펴보고,
그들의 작은 성공(victories)을 관찰했을 것입니다.

그 다음 다른 팀에서도 같은 과정을 반복했겠지요.

그러면 어느 시점에서,
사람들은 서로 이야기하기 시작합니다.
“그 팀이 이렇게 했대.”
“우리는 저 부분을 참고해보자.”
이렇게 ‘성공 스토리’가 생깁니다.
그 시점에 가서야 전사적으로 커뮤니케이션을 했더라면, 모두가 “이건 우리 거야.”라는 주인의식(buy-in)을 가졌을 것입니다.
그들은 이미 자신들의 흐름(flow) 안에 이 도구가 자리 잡았다고 느꼈을 것입니다.

셋째, 열정(enthusiasm)은 전략이 아니지만, 후원(endorsement)은 전략이다.

열정만으로는 부족합니다. 우리는 이 사실을 아주 뒤늦게 깨달았습니다.

명확한 범위(scope),
분명한 스폰서(sponsor),
그리고 소유자(owner), 경계(boundary)가 필요합니다.
리오그 문서에 “페르소나 기반 구조로 전환한다”는 말이 들어 있는 것은 좋지만, 그게 곧 실행력을 보장하는 것은 아닙니다.

‘호의(goodwill)’만으로는 확산되지 않습니다. 호의는 확장되지 않습니다.
따라서, 여러분의 조직에서 ‘기폭제(trigger)’가 될 사람, 즉 실제로 행동을 일으킬 수 있는 사람을 찾아야 합니다.
그들을 중심으로 구조를 세워야 합니다.

물론 우리는 모든 걸 잘못한 건 아닙니다.
몇 가지는 정말 잘한 것도 있습니다.
그 부분은 저도 자랑스럽게 생각합니다.

첫째, ‘찾을 수 있음(findability)’이 중요합니다.

우리가 Dovetail을 사용하지 않는다는 사실을 깨달았을 때, 우리는 아주 훌륭한 결정을 내렸습니다.
즉, Confluence로 전환한 것입니다.
어떤 사람들에게는 Dovetail보다 덜 흥미로울 수도 있습니다. 기능이 제한적이기 때문입니다.
하지만 현실적으로 Confluence는 모두가 이미 알고 있고, 모두가 접근할 수 있는 공간입니다.
뮤즈(Mews)에서는 사람들이 어떤 정보를 찾을 때 가장 먼저 가는 곳이 바로 그곳입니다.

또한 Confluence는 링크로 인덱싱(indexable)됩니다.
즉, 어떤 것을 검색하면 다른 문서나 슬랙, 미로(Miro) 등에서 관련된 참고 자료까지 함께 제시됩니다.

뮤즈처럼 속도가 매우 빠른 조직에서는 사람들을 잃는 순간, 곧 ‘관심’을 잃는 것입니다.
한 번 원하는 정보를 찾지 못하면, 그 다음에는 다시 오지 않습니다.

그래서 모든 콘텐츠는 접근 가능하게, 직관적으로 찾을 수 있게, 읽기 쉽게 만들어야 합니다.

둘째, 조금 시간이 걸리더라도 ‘보여주고, 모범을 보이라(Showcase and lead by example)’는 것입니다.

작은 성공이라도 생기면, 즉시 그것을 공유하고 이렇게 말해야 합니다.
“이게 바로 우리가 한 일입니다.
이렇게 작동합니다. 이게 바로 그 가치입니다.
그리고 여러분도 이렇게 활용할 수 있습니다.”

우리가 그렇게 사례를 공개하자, 많은 사람들이 우리에게 메시지를 보내기 시작했습니다.
그들은 “이거 정말 유용하다”고 말했습니다.

놀라운 점은, 그 반응이 R&D 조직 외부에서도 왔다는 것입니다.
제품 마케팅(Product Marketing) 팀,
GTM(Go-To-Market) 팀,
그리고 심지어 데이터 인사이트(Data Insights) 팀에서도 연락이 왔습니다.

그들은 이렇게 말했습니다.
“이걸 우리 쪽에서도 활용할 수 있을 것 같아요.”

예를 들어,
제품 마케팅 팀은 이를 활용해 제품 판매 논리(argumentary selling)를 구성할 수 있었고, GTM 팀은 “앞으로 총지배인(General Manager)들이 무엇에 관심을 가질까?”를 파악해 그에 맞는 세일즈 전환 전략을 세울 수 있었습니다.

이처럼 여러분은 누가, 어떤 방식으로, 당신의 도구를 유용하다고 느낄지 결코 알 수 없습니다.
그러니 공유를 두려워하지 말아야 합니다. 공유는 두렵지만, 공유해야 합니다.

셋째, 너무 뻔한 말처럼 들릴지 모르지만—절대 포기하지 말라(Don’t surrender).

실수로부터 배우십시오. 그리고 계속 나아가야 합니다. 이건 절대 쉬운 일이 아닙니다.

발표의 초반에 제가 말했듯이, 이 과정을 시도한다면 정말 힘든 일이 될 것입니다.
인내심이 필요합니다.
때로는 우회로(workaround)를 만들어야 할 수도 있습니다. 하지만 결국은 그만한 가치가 있습니다.

이제 마지막 이야기입니다.

이 발표를 들으면서
“우리 조직에서는 이걸 어떻게 적용할 수 있을까?”
라고 생각하셨다면, 제가 드리고 싶은 조언은 이것입니다.

조직의 핵심을 바꾸는 강한 변화는 그만큼 강한 추진력(strength)이 필요합니다.

그래서 첫 번째로 해야 할 일은, 자신의 조직이 가진 디자인 성숙도(design maturity)를 정확히 이해하는 것입니다.
디자인 성숙도의 ‘사다리’ 어느 단계에 서 있는가에 따라 접근 방식은 완전히 달라집니다.

또한, 사람들의 행동(behavior)을 살펴봐야 합니다. 그리고 자신에게 이렇게 물어야 합니다.

“무엇이 사람들로 하여금, 단순히 자신이 만드는 제품을 넘어, 더 넓은 관점을 갖게 만드는가?”
저는 그 답이 전략(strategy)이라고 생각합니다.

왜냐하면 전략이야말로 우리 모두를 연결하는 지점이기 때문입니다.
그리고 그것이 이번 프로젝트가 리오그 문서(Memo)에 포함된 이유이기도 합니다.

하지만 그것만으로는 충분하지 않습니다. 이건 일종의 ‘공식(formula)’과 같습니다.
전략만 있고 문화(culture)와 프로세스(process)가 빠지면 안 됩니다.
이 세 가지가 모두 함께 계획에 포함되어야 합니다.

그리고 기억하십시오. 결국 도구(tools)는 도구일 뿐입니다.

진정 중요한 것은, 그 도구가 사람들에게 실제로 가치를 주는가입니다.
그들이 그것을 자신의 일상적인 업무 흐름(workflow) 안에 포함시킬 수 있는가.
그리고 그것을 통해 자신 있게 결과물을 낼 수 있는가.
그게 본질입니다.

결국 중요한 것은 그게 ‘페르소나(persona)’이든, 다른 어떤 프레임워크이든 상관없습니다.
무엇이든 조직에 새로운 것을 도입하려 한다면, 사람들에게 투자(invest)해야 합니다.
왜냐하면, 마지막에 남는 것은 결국 도구가 아니라, 문화(culture)이기 때문입니다.

당신이 구축한 문화, 그리고 그 안에서 사람들이 스스로 성장하고 empowered(주체적으로 행동)하게 된다는 사실,
그것이 가장 오래 지속되는 성과입니다.
그리고 그 문화를 만들어내는 서사는, 한 번 만들어지면 영구히 남습니다.

그러니 시도해보세요. 그리고 행운을 빕니다.
감사합니다.