(영상) 피터 머홀즈가 말하는 UX와 디자인 조직의 변화 - 빈티드 UX 나이트

피터 머홀즈가 말하는 UX와 디자인 조직의 변화 - 빈티드 UX 나이트
UX Night at Vinted with Peter Merholz

리투아니아 빌뉴스의 Vinted 본사에서 열렸던 UX 커뮤니티 행사 영상을 소개합니다. 주제는 AI가 UX, 디자인 조직, 제품개발 방식, 리더십에 어떤 변화를 만들고 있는가입니다.
1부에서 만타스와 기드리우스는 Vinted 내부에서 AI를 실제 제품디자인과 개발 프로세스에 적용한 경험을 공유합니다. 핵심은 AI가 단순히 콘텐츠 생성 도구가 아니라, 디자이너가 코드, PR, 실험, 프로토타입까지 직접 다룰 수 있게 만드는 변화라는 점입니다. 그러나 도구보다 중요한 것은 병목을 찾고, 디자인시스템과 조직의 지식 기반을 AI가 활용할 수 있도록 준비하며, 사람들을 함께 끌고 가는 일이라고 설명합니다.
2부에서 피터 머홀즈는 AI 시대의 디자인 리더십을 이야기합니다. 그는 AI가 조직의 현재 상태를 증폭한다고 말합니다. 신뢰가 있는 팀은 더 강해지고, 불안한 팀은 더 혼란스러워진다는 뜻입니다. 따라서 리더의 역할은 작업을 지시하는 것이 아니라 좋은 일이 반복적으로 나올 수 있는 조건, 즉 심리적 안전감, 자율성, 숙련, 품질 기준, 팀 명확성을 만드는 것이라고 강조합니다.
전체적으로 이 행사는 “AI가 디자이너를 대체하는가”보다는 “AI 때문에 디자인의 진짜 역할이 무엇인지 다시 드러나는가”에 가깝습니다. 요약하면, Figma 화면을 예쁘게 만드는 일은 자동화될 수 있지만, 무엇을 만들지, 왜 만들어야 하는지, 어떤 품질을 지켜야 하는지 판단하는 일은 더 중요해졌다는 내용입니다.

원본 영상 : https://www.youtube.com/watch?v=5lAEMsXwf7A   
출처 : We Work at Vinted
공개일 : 2026. 6. 17.
번역 : 챗GPT 요약, 생략, 오역이 있을 수 있습니다. 링크된 원본 영상을 봐주세요.

 

만타스 수트쿠스와 기드리우스 얄로베츠카스

만타스 수트쿠스와 기드리우스 얄로베츠카스는 Vinted에서 제품디자인과 기술의 접점을 실험하고 있는 실무형 디자인 리더입니다. 만타스는 Staff Product Designer로서 AI를 개인 생산성 도구가 아니라 제품디자인의 사고와 실행 방식을 바꾸는 도구로 다룹니다. 그는 세컨드 브레인, Claude, Cursor, Lovable, Vercel 등을 활용해 리서치, 맥락 수집, 프로토타입 제작, 이해관계자 공유까지 이어지는 새로운 작업 흐름을 실험하고 있습니다.
기드리우스는 디자인과 엔지니어링을 넘나드는 Staff Design Technologist입니다. 제품디자이너, 프론트엔드 엔지니어, 디자인시스템 리더, 엔지니어링 리더의 경험을 바탕으로, AI가 실제 제품개발 환경에서 작동하려면 어떤 기반이 필요한지를 다룹니다. 특히 디자인시스템, 코드, 프로덕션 환경, PR, 실험 체계가 분리되어 있을 때 생기는 병목을 발견하고, 이를 AI가 활용 가능한 구조로 바꾸는 데 초점을 둡니다.
두 사람의 발표는 AI가 디자이너를 대체하는가라는 흔한 질문에서 벗어나 있습니다. 그들이 던진 핵심 질문은 더 현실적입니다. “AI를 통해 디자이너가 더 빨리 생각하고, 더 정확히 만들고, 더 많은 사람과 함께 제품을 개선하려면 조직은 무엇을 바꿔야 하는가?”입니다. 이들의 사례는 AI 시대의 디자인이 화면 제작을 넘어, 조직의 병목을 발견하고 실행 구조를 다시 짜는 일로 확장되고 있음을 보여줍니다.

 

피터 머홀즈

피터 머홀즈는 UX와 디자인조직 분야에서 25년 이상 활동해 온 대표적 사상가이자 실천가입니다. 그는 현대 UX 컨설팅의 방향을 만든 아답티브 패스 Adaptive Path의 공동창립자이며, Capital One, Kaiser Permanente, Groupon, OpenTable 등에서 디자인 리더십을 수행했습니다. 또한 『Org Design for Design Orgs』의 공동저자로, 사내 디자인팀을 어떻게 만들고 운영하며 성장시킬 것인가에 대해 가장 체계적으로 다룬 인물 중 한 명입니다. 최근 피터의 관심은 AI 시대의 디자인 리더십으로 확장되고 있습니다. 그는 AI를 단순한 도구 도입 문제가 아니라 조직의 현재 상태를 증폭하는 변화로 봅니다. 신뢰가 있는 팀은 AI를 통해 더 강해지지만, 불안과 혼란이 큰 팀은 그 문제도 함께 커진다는 관점입니다. 따라서 디자인 리더의 역할은 더 많은 산출물을 지시하는 것이 아니라, 좋은 일이 반복적으로 만들어질 수 있는 조건을 디자인하는 일이라고 말합니다. 그가 강조하는 핵심은 역할보다 팀, 산출보다 품질, 실행보다 판단입니다. AI가 화면 제작과 코드 작성의 장벽을 낮출수록 디자인의 가치는 오히려 더 선명해집니다. 무엇을 만들 것인지, 왜 만들어야 하는지, 어떤 품질 기준을 지켜야 하는지, 그리고 조직 안에서 사람들이 어떻게 함께 판단하고 실행할 것인지가 중요해지기 때문입니다. 피터 머홀즈의 관점은 AI 시대의 디자인을 기술 적응의 문제가 아니라, 디자인조직의 성숙도를 시험하는 문제로 보게 합니다.

---

전체 번역

오프닝

사회자:
체크, 체크, 체크.
여러분, 좋은 저녁입니다. 와!

Vinted의 UX Night에 오신 것을 환영합니다. 오늘 일정은 세 사람이 두 개의 발표를 진행하는 방식입니다. 계산해 보시면 조금 이상할 수 있지만, 결국에는 말이 될 것입니다.

요즘 모두가 이야기하고 싶어 하는 주제는 AI입니다. 그래서 오늘도 AI에 대해 이야기하겠습니다. 다만 서로 다른 층위에서 이야기하려고 합니다.

먼저 제 소중한 친구이자 동료인 만타스와 기드리우스를 소개하겠습니다. 이들은 Vinted 내부 현장에서 실제로 어떤 일이 벌어지고 있는지 공유할 예정입니다. 우리가 AI를 어떻게 바라보고 있는지, 무엇을 알고 있는지, 그리고 더 중요하게는 무엇을 아직 모르는지 이야기할 것입니다. 사실 우리가 아는 것보다 모르는 것이 훨씬 많습니다.

그다음에는 피터에게 이어가겠습니다. 피터는 더 넓은 관점에서 세상에서 어떤 일이 벌어지고 있는지, 조직들이 어떤 변화를 겪고 있는지, 디자인이 비즈니스 안에서 어떤 방식으로 참여하고 있는지, 그리고 AI가 디자인의 참여 방식을 어떻게 바꾸는지 이야기해 줄 것입니다.

그럼 바로 시작하겠습니다.

먼저 두 친구, 만타스와 기드리우스를 소개합니다. 기드리우스는 아마도 지금까지 가장 많은 직함을 가진 사람일 것입니다. 그는 제품디자이너였고, 프론트엔드 엔지니어였고, 다시 제품디자이너였고, 디자인 및 운영 디렉터였고, 엔지니어링 디렉터였으며, 지금은 스태프 디자인 테크놀로지스트입니다. 기드리우스의 직함에 박수를 보냅니다.

그는 장인정신에 대한 애정이 깊은 사람입니다. 동시에 마음이 따뜻하고, 함께 일하기 좋은 사람이며, 곁에 있다는 것이 특권처럼 느껴지는 동료입니다.

만타스도 소개하겠습니다. 만타스와 기드리우스는 정말 좋은 친구입니다. 이제 두 사람이 함께 일하게 되었고, 저도 그들과 함께 일하게 되었습니다. 정말 즐거운 일입니다.

만타스는 Vinted의 스태프 디자이너입니다. 개인적으로는 가족을 사랑하는 사람이고, 캠퍼밴을 좋아하며, 사진에도 관심이 많습니다. 그리고 그가 이 자리에 가져오는 매우 특별한 특성이 하나 있습니다. 바로 변화를 밀고 나가는 에너지입니다. 오늘 그 이야기도 하게 될 것입니다.

만타스와 기드리우스에게 박수 부탁드립니다.

[박수]

---

1부. Vinted 내부의 AI, 디자인, 병목

기드리우스:
UX, UX.
클리커가 필요합니다. 클리커를 다시 가져오겠습니다.

좋습니다. 이 슬라이드는 사실 별로 할 말이 없는 슬라이드입니다.

네, 이제 이 슬라이드입니다. 좋은 발표라면 당연히 인용문으로 시작해야 합니다. 여러분이 이 사람을 아실지는 모르겠습니다. 매우 유명한 SF 작가 윌리엄 깁슨입니다. 그는 이렇게 말했습니다.

“미래는 이미 와 있다. 다만 고르게 퍼져 있지 않을 뿐이다.”

이 말은 무슨 뜻일까요? 변화는 이미 일어나고 있다는 뜻입니다. 다만 그 변화가 모두에게 같은 속도와 같은 방식으로 일어나지는 않는다는 뜻입니다. 돈, 문화, 여러 조건, 그리고 오늘 우리가 이야기할 병목 때문입니다.

우리는 Vinted에서도 AI를 이런 관점으로 바라보고 있습니다. X.com의 블로그 글과 트윗을 보면 10배 디자이너, 100배 엔지니어 같은 말이 많이 나옵니다. 첫 번째 질문은 이것입니다. 도대체 그 사람들은 무엇을 마시거나 피우는 것일까요. AI 알약이라도 먹는 것일까요.

그리고 다음 질문은 이것입니다. 이것을 어떻게 Vinted로 가져올 수 있을까요. 특히 요나스는 이런 것들을 Vinted에 가져오고 싶어 합니다. 결국 질문은 이것입니다. 이 미래를 Vinted로 어떻게 가져올 것인가, 또는 우리 자신의 삶으로 어떻게 가져올 것인가입니다.

저와 만타스는 지난 1~2년 동안 AI에 대해 계속 대화해 왔습니다. 저는 좀 더 실천적이고 정치적인 관점에서 바라봤고, 기드리우스는 기술과 가능성의 관점에서 바라봤습니다. 동의하는 부분도 있고, 의견이 갈리는 부분도 있었습니다. 몇 가지 결론도 얻었고, 실제로 적용해 본 것도 있습니다. 오늘은 우리가 겪은 과정을 공유하려고 합니다.

만타스:
먼저 당연한 질문이 있습니다. 왜 AI인가? 왜 또 하나의 AI 발표가 필요한가?

중요한 점은 AI도 다른 기술과 마찬가지로 파도처럼 온다는 것입니다. 회사에게도, 디자이너에게도, 다른 산업이나 역할에 있는 사람에게도 경쟁 우위를 가질 수 있는 기회입니다.

우리가 앱을 만들기 시작했을 때, 클라우드 기술, 이커머스, 결제 시스템 같은 것들이 등장했을 때도 비슷했습니다. Vinted는 이런 것들을 대부분 갖고 있지만, 항상 처음부터 선두에 있었던 것은 아닙니다. 다만 빠르게 따라잡았습니다.

이 슬라이드는 Facebook 내부 커뮤니케이션 북에서 가져온 내용입니다. 지금 상황에도 꽤 잘 들어맞는다고 생각합니다. 요지는 빠르면 단지 현재 경주에서 이기는 것뿐 아니라, 다음 경주를 먼저 시작할 수 있다는 것입니다.

우리는 이것이 회사에도, 개인에게도 좋은 기회라고 생각합니다. 레버리지를 얻을 수 있습니다. 경쟁해야 하거나 더 높은 연봉 같은 것을 원한다면, 앞서 나갈 수 있는 좋은 기회입니다.

그다음 질문은 이것입니다. 도대체 AI의 영향을 어떻게 측정할 수 있을까요? 첫 번째 질문이 “AI란 무엇인가”라면, 두 번째 질문은 “AI의 영향을 어떻게 측정할 것인가”입니다. 오늘날 이에 대한 쉬운 답은 없습니다.

하지만 이유는 있습니다. 시스템 수준에서 보거나 제약이론의 관점에서 보면, 핵심은 이렇습니다. 어떤 시스템의 산출은 그 시스템에서 가장 큰 병목에 의해 결정됩니다.

예를 들어 물 호스를 생각해 보겠습니다. 호스에서 나오는 물의 양은 호스 안에서 가장 좁은 부분이 결정합니다. 수도꼭지를 아무리 세게 틀어도, 호스가 좁으면 물은 조금밖에 나오지 않습니다.

이 관점에서 보면, 병목이 있는 상태에서는 코드 라인이나 PR을 아무리 많이 만들어도 소용이 없습니다. 계획된 일 자체에서 막혀 있다면 거기서 멈추게 됩니다.

그래서 오늘 발표는 이 관점에서 진행됩니다. Vinted에서 이미 보이는 병목은 무엇인지, 이미 해결한 병목은 무엇인지, 그리고 여러분 회사에도 적용할 수 있는 것은 무엇인지 이야기하겠습니다.

이제 호스 이야기는 더 하지 않겠습니다. 대신 병목 이야기를 하겠습니다.

만타스:
기드리우스가 말했듯이 기술은 파도처럼 옵니다. Vinted도 기회를 찾으려고 했습니다. 약 1년 전 첫 번째 파도에서 우리는 기능 주간 동안 워크숍을 도입했습니다. 대화를 시작했고, 모두가 잘 아는 시몬 돌란타스도 초대했습니다. 이런 활동은 몇 가지 돌파구를 만들었습니다.

하지만 우리가 이해한 것은, 그 돌파구가 주로 콘텐츠 생성 영역에서 일어났다는 점입니다. 콘텐츠, 현지화, 리서치, 비주얼 UI에서는 이미 큰 변화가 있었습니다. 그런데 제품디자인에서는 아직 큰 돌파구가 없었습니다.

이 아이콘을 아는 분이 있을까요? 모르시겠죠. 제가 말했잖아요. 아무도 모를 거라고요. 이것은 swamp, 즉 늪입니다. 여기서는 pull request, PR을 뜻합니다.

디자이너가 제품을 직접 만들고, 코드 안에서 작업하고, PR을 만들고, 그다음 실험까지 들어가는 일입니다. AB 테스트도 해야 합니다. 이것이 우리가 건너고 싶었던 늪이었습니다.

물론 이것은 기술적 한계만의 문제가 아닙니다. 크로스플랫폼 환경 안에서 작동해야 하고, 여러 직능이 함께 일하는 크로스펑셔널 환경과 맞아야 합니다. 지난 10년 동안 형성된 조직 규범도 있습니다. 많은 사람은 우리가 지금까지 해 온 방식대로 계속해야 한다고 생각합니다. 물론 다르게 생각하는 사람도 많습니다.

그래서 우리가 이해한 것은 이것입니다. 사람들에게 그냥 “AI를 쓰세요”라고 말할 수는 없습니다. 직접 해 보지도 않고 “AI를 쓰세요”라고 할 수 없습니다. 이 늪은 스스로 건너야 합니다.

오늘은 그 이야기를 하겠습니다. 우리가 이야기할 내용은 다음과 같습니다. 필요한 조건, 우리가 실제로 해 본 실천, 사람들을 어떻게 함께 데려올 것인가, 그리고 Vinted에서 다음에 무엇이 올 것인가입니다.

기드리우스:
먼저 조건부터 시작하겠습니다. 어떤 일을 시작하기 전에 먼저 토대를 준비해야 합니다. 그리고 그 일을 할 사람이 필요합니다. 제가 그 사람입니다. 죄송합니다.

조직에서 변화를 이끄는 일은 어렵습니다. 특히 Vinted처럼 큰 조직에서는 더 어렵습니다. 여기에 AI를 얹으면 더 복잡해집니다. 적어도 제게는 AI가 매주 바뀌는 것처럼 느껴집니다.

그렇다면 무엇을 해야 할까요? 첫 번째는 스폰서십입니다. 그리고 적절한 사람을 적절한 위치에 배치하는 것입니다. 많은 지식이 있지는 않더라도, 최소한 호기심이 있고, 우리가 무엇을 하려는지 어느 정도 감을 가진 사람들입니다.

우리는 그렇게 시작했습니다. 엔지니어 몇 명을 데려왔고, PM도 데려왔습니다. 저도 이 구성에 포함됐습니다. 이것이 첫 번째 단계였습니다.

다음 단계는 비전을 세우는 것입니다. 우리가 무엇을 목표로 하는지 정해야 합니다.

우리가 처음 세운 방향은 이것입니다. 디자인하는 것과 코딩하는 것이 사실상 하나가 되어야 한다는 것입니다. 우리는 ‘코딩’이라는 말을 잘 쓰지 않습니다. ‘빌딩’, 즉 만드는 것이라고 말합니다. 요즘 아무도 그냥 코딩하러 간다고 말하지는 않으니까요.

결국 우리는 디자인하는 것과 만드는 것이 동의어가 되어야 한다고 봤습니다. 우리는 이 비전을 세웠고, 멋진 비전 프로그램도 만들었습니다. 지금도 그 방향을 향해 가고 있습니다. 이것이 첫 단계였습니다.

도구 이야기로 조금 돌아가 보겠습니다. 만타스가 이미 말했듯이, 1년 전 또는 그보다 더 전에 우리는 이런 도구들을 시도했습니다. Figma Make도 시도했습니다. AI 맥락에서는 1년 전도 아주 오래전처럼 느껴집니다.

그때는 너무 일렀습니다. 대부분 도구에 기능과 유연성이 부족했고, 모델도 충분히 좋지 않았습니다. 그래서 다시 Figma로 돌아갔습니다.

그러다 올해 2월 다시 시도했습니다. Lovable을 시도했고, 더 많이 투자했습니다. 디자이너와 PM 모두에게 다시 가져왔고, 이번에는 작동했습니다.

작동한 이유가 있습니다. 진입장벽이 매우 낮았습니다. 모델도 이미 좋아졌습니다. 일부 디자이너는 이제 Figma를 거의 쓰지 않기 시작했습니다. 만타스가 그중 한 명입니다. Lovable은 매우 비쌉니다. 요나스는 비용을 내고 싶어 하지 않습니다.

하지만 한 가지가 클릭됐습니다. Lovable이 만들어 내는 것은 우리가 재사용할 수 있는 코드라는 사실을 이해한 순간입니다. Lovable 밖에서 만든 것을 사용할 수도 있고, Lovable이 만든 것을 가져와 우리만의 것으로 만들 수도 있습니다.

그래서 우리는 Claude와 Cursor를 탐색하기 시작했습니다. 요즘 엔지니어들이 쓰는 도구입니다. 오늘 일론 머스크가 Cursor를 샀다고 들었는데, 앞으로 엔지니어들이 계속 쓸지는 모르겠습니다. 지켜봐야겠습니다.

이 도구들은 매우 고도화되어 있습니다. 무엇이든 할 수 있습니다. 가장 큰 어려움은 세팅에 많은 시간을 들여야 한다는 점입니다.

그래서 우리는 Claude, Cursor, 그리고 Lovable을 결합하면 어떻게 될까 생각했습니다. 그러면서 우리만의 도구를 만들기 시작했습니다. 실험으로 시작했고, 아직도 실험 단계입니다.

본질적으로 이 도구는 두 세계를 결합합니다. 프로토타입을 만들 수도 있고, 실제 제품을 만들 수도 있습니다. 프로덕션에 PR을 만들 수도 있습니다. 별도의 환경 설정이 필요 없고, 진입장벽이 낮으며, 사용하기 쉽습니다. 제가 써 봤는데 웹에서도 작동합니다.

하지만 훌륭한 도구와 훌륭한 모델이 있어도, 기반이 없으면 아무 의미가 없습니다. 특히 기반이 중요합니다.

우리는 디자인시스템에서 시작했습니다. 우리의 디자인시스템은 AI가 쓰도록 만들어진 것이 아니었습니다. AI가 사용할 수 있도록 준비해야 했습니다. 그래서 Figma에서 템플릿을 만들듯이 시간을 들여 템플릿을 만들었습니다.

이것은 로아스가 Lovable용으로 만든 템플릿입니다. 보시다시피 가짜 콘텐츠가 아니라 제 실제 콘텐츠입니다. 메시지를 쓸 수 있고, 원하는 것을 할 수 있는 완전한 기능형 프로토타입입니다.

또 우리는 흩어진 문서와 파일 속에 있던 지식을 중앙화하기 시작했습니다. AI를 활용해 더 높은 품질의 산출물을 규모 있게 만들려고 했습니다. CLS 등 많은 것들이 포함됩니다.

물론 제가 아는 한, 어떤 디자인시스템도 완벽하지 않습니다. 늘 투자가 필요합니다. 그래서 우리는 이렇게 생각했습니다. “AI가 할 수 있지 않을까?”

우리는 AI 우선의 디자인시스템을 만든다는 것이 무엇을 의미하는지 고민하기 시작했습니다. 여기 보이는 화면들은 AI가 생성한 것입니다. 디자이너가 만든 것이 아닙니다.

AI는 좋은 결과물을 만들 수 있습니다. 하지만 많은 자원을 투자해야 합니다. 우리는 이미 오픈소스 디자인시스템을 사용하는 것이 AI에게 더 쉬울 수 있다는 생각도 하기 시작했습니다. 예를 들어 shadcn 같은 것입니다. AI는 이미 많은 디자인시스템을 학습했기 때문입니다.

AI가 화면을 만들 수 있다면, 새 컴포넌트를 만들고 새로운 가이던스도 작성할 수 있어야 합니다.

---

실천: 직접 해 보기

만타스:
기드리우스가 기반과 도구를 작업하는 동안, 저는 시간이 조금 있었습니다. 요나스가 허락해 주었고, 저는 그 시간을 뭔가 하는 데 쓰기로 했습니다.

그래서 실제로 적용해 보기로 했습니다. 누군가 “어떻게 할 건가요?”라고 물으면 저는 항상 “Doing Method를 적용할 것입니다”라고 말합니다. 즉 워크숍을 만들고, 문서를 쓰고, 허락을 구하고, 정렬을 맞추고, 계획을 세우는 대신, 그냥 가서 해 보는 것입니다.

AI 도구에 대해 말하자면, 장벽은 지금까지 어느 때보다 낮습니다. 코딩 부분은 적어도 프론트엔드에서는 어느 정도 해결됐다고 볼 수 있습니다. 따라서 시작하지 않을 이유가 없습니다.

솔직히 말하자면, 저는 예전부터 도구 자체가 그렇게 중요하다고 생각하지 않았습니다. 문제는 보통 도구가 아니라 사람에게 있었습니다. 주도성, 스스로 결정하려는 욕구, 무언가를 만들려는 절박함, 능동성 같은 것이 문제였습니다. 이런 것들이 항상 밀고 나가고 그 위에 무언가를 쌓는 데 병목이 되어 왔습니다.

제가 이전 발표에서 디자이너의 기본 역량에 대해 말한 적이 있습니다. 그중 하나가 호기심이었습니다. 저는 여전히 그렇게 믿습니다. 호기심은 이 모든 것이 작동하게 하는 엔진입니다. 한계는 상상력과 토큰뿐입니다.

정리하자면, 아까 말했듯이 직접 해 보지 않고 “AI를 쓰세요”라고 말할 수는 없습니다. 그래서 저는 조금 탐색해 보기로 했습니다.

첫 번째 탐색은 제 문제에서 시작했습니다. 스태프 제품디자이너로서 제 일은 미래를 생각하는 동시에 과거를 이해하고, 많은 사람과 이야기하고, 정렬을 맞추는 것입니다.

보통은 무언가를 만들고, 그 정보를 다른 곳으로 옮깁니다. 그곳에서 사람들이 댓글을 남기고, 다시 작업하고, 회의에 가져가고, 답을 받고, 다시 다른 곳으로 옮깁니다. 결국 저는 컨베이어 관리자처럼 한 장소에서 다른 장소로 물건을 옮기는 사람이 되어 있었습니다. 제 시간이 너무 많이 들었습니다. 그래서 뭔가 해야겠다고 생각했습니다.

그때 카파시라는 똑똑한 사람이 자기만의 위키, 일종의 세컨드 브레인을 만들라고 제안했습니다. 주말이었고 시간이 있었습니다. 이것은 제 일뿐 아니라 저 자신에게도 필요하다고 생각했습니다.

그래서 그가 쓴 내용을 복사해서 Claude에 붙여 넣었습니다. Obsidian을 다운로드했습니다. Obsidian은 Finder와 비슷하지만 더 보기 좋게 생긴 도구입니다. 그리고 제 세컨드 브레인을 세팅했습니다.

기본 구조를 세팅하는 데 20분 정도 걸렸습니다. 그다음 무엇을 더 만들 수 있을지 탐색하기 시작했습니다.

제가 가진 모든 입력이 이 시스템으로 들어오게 했습니다. Google Docs에 접근할 수 있게 했고, Google 미팅에도 접근하게 했습니다. 캘린더에서 회의가 보이면 그 회의로 가서 전사 내용을 확인하고, 모든 정보를 가져와 저장하라고 했습니다. 노트가 있으면 저장하고, Google Docs를 공유하면 명령에 따라 읽고 저장하게 했습니다.

이것은 일종의 카탈로그 시스템처럼 작동했습니다. Claude가 그것을 조율했습니다. 전체 시스템은 텍스트 파일의 저장소입니다. Finder 안에 로컬로 저장되어 있습니다. 다른 곳에는 없습니다. 제가 가지고 있습니다. 이렇게 제 세컨드 브레인을 만들었고, 지금도 사용하고 있습니다.

이 시스템은 제 하루를 계획하는 데 도움을 줍니다. 요나스와의 회의를 준비하게 해 줍니다. 기드리우스와의 회의도 도와줍니다. 제가 잊은 것을 알려 주고, 때로는 사전 준비 작업까지 해 줍니다.

전체적으로 보면, 예전에 제가 해야 했던 사고 작업의 약 60%를 이 시스템에 던져 넣었습니다. 이제 저는 AI에 대해 이야기하는 데 더 집중할 수 있습니다.

[웃음]

그와 동시에 이 세컨드 브레인을 개선하고 있던 중, 아담에게 요청을 받았습니다. 공개할 수 없는 어떤 것들에 대한 콘셉트를 만들어야 했습니다. 그래서 저는 미래의 Vinted 버전을 몇 가지 만들어야 했습니다. 최대한 조심스럽게 말하고 있습니다. 그 미래에 대해 몇 가지 변형안도 필요했습니다.

처음에는 Lovable을 시작했습니다. 두세 시간 정도 사용해 보니 한계가 보였습니다. 쓸 수 없다고 판단했습니다. 물론 아무것도 만들 수 없다는 뜻은 아닙니다. 만들 수는 있습니다. 하지만 저는 제 도구를 더 효율적으로 만들고 싶었습니다. 제 필요에 맞게 조정하고, 스킬을 설치하고, 규칙을 설정하고, 에이전트가 작동하는 방식에 대해 더 많은 통제권을 갖고 싶었습니다.

그래서 Cursor를 시도하기로 했습니다. Cursor와의 사랑 이야기는 짧게 끝났습니다. 하지만 그 과정에서는 계속 Cursor를 사용했습니다. 왜냐하면 세컨드 브레인을 하나의 흐름 안에서 바로 쓰고 싶다는 것을 깨달았기 때문입니다.

그다음 Claude로 옮겼습니다. 15분 정도 걸렸습니다. 어려운 일은 아니었습니다.

저는 Lovable로 시작했고, 괜찮았습니다. 하지만 이후에는 세 개의 서로 다른 Vinted 구조를 만들 수 있었습니다. 모두 클릭 가능한 프로토타입이었고, 현재보다 훨씬 복잡한 정보구조를 담고 있었습니다. 몇 주 만에 만들었습니다.

그 몇 주 동안 리서치도 했고, 이해관계자와 공유도 많이 했습니다. 그들의 입력을 다시 가져오는 과정도 있었습니다. 하지만 이 전체 과정은 제가 보기에 10배 정도 더 빠르게 만들 수 있게 해 주었습니다. 입력을 받고 Figma로 가서 같은 것을 열 군데 고치는 방식보다 훨씬 빠릅니다.

이제 새 워크플로를 설명하겠습니다. 이것은 우리 디자인 프로세스를 어느 정도 나타냅니다.

첫 번째 단계인 이해 단계에서는 세컨드 브레인이 모든 입력을 수집했습니다. 저는 그것을 바탕으로 종합할 수 있었고, 리서치 계획이나 첫 프로토타입을 생각할 수 있었습니다. 어떤 상태가 필요하든 제 위키를 사용했습니다.

그다음 이 모든 것이 프롬프트로 전환되었습니다. 그 프롬프트는 계획 단계에 있었습니다. 이것은 조금 뒤에 이야기하겠습니다.

마지막으로 Vercel을 사용해 배포하고 공유했습니다. 다시 입력을 수집하고, 반복했습니다.

이 과정이 가져온 것은 이것입니다. 매번 다시 할 때마다 더 빠르고 효율적으로 할 수 있었습니다. 결과도 좋아졌습니다. 같은 실수를 반복하지 않도록 세팅했고, 매번 더 많은 맥락을 갖고 반복했기 때문입니다.

몇 주 동안 이 작업을 하며 얻은 결과 중 몇 가지를 공유하고 싶습니다.

첫 번째는, 무엇이든 배포하거나 공유하려면 GitHub가 필요하다는 것입니다. 저는 엔지니어가 아니기 때문에 Vinted의 GitHub 접근 권한도 없고, 무언가를 배포할 장소도 없었습니다. 그래서 제 학습 예산을 사용했습니다. 죄송합니다, 요나스가 여기 없네요.

[웃음]

그 접근 권한을 얻기 위해 학습 예산을 사용했습니다.

제가 배운 것은 이것입니다. 필요한 것이 있으면 에스컬레이션하고 얻어야 합니다. 디자이너에게 필요한 토큰이 너무 적었습니다. 저는 IT팀에 가서 “제가 이런 것을 만들고 있습니다. 제가 받을 수 있는 가장 많은 토큰이 필요합니다”라고 말했습니다. 제 사용량을 보여 줬습니다. 첫 주에 제가 사용량 1위였습니다. 그래서 지금은 거의 무제한 같은 것을 받았습니다.

이것은 농담입니다. 하지만 어느 시점에 회사 전체에서 토큰을 가장 많이 쓴 사람을 보니 만타스와 저였습니다. 엔지니어들을 다 이기고 있었습니다. 저희가 뭘 하고 있는지는 잘 모르겠습니다.

두 번째는 자신만의 작업 방식을 찾는 것입니다. 자기 모델을 시험해 보고, 무엇이 자신에게 맞는지 찾아야 합니다. 예를 들어 저는 계획을 세우거나 프롬프트를 만들 때 먼저 텍스트 와이어프레임을 요청하는 것이 유용하다는 것을 배웠습니다. HTML 와이어프레임으로 탐색하면, 실제로 만들기 전에도 거의 전체 레이아웃을 갖고 작업할 수 있습니다. 시간과 토큰을 많이 절약합니다.

세 번째는 속도를 조절하는 것입니다. 저는 작은 번아웃을 몇 번 겪었습니다. 누가 저를 밀어붙인 것은 아닙니다. 자연스럽게 그렇게 됐습니다. 동시에 서너 개, 다섯 개의 에이전트를 서로 다른 맥락에서 계속 돌리다 보면, 사흘이나 나흘 뒤에는 뇌가 튀겨진 것처럼 느껴집니다.

그래서 속도를 조절해야 합니다. 멈추는 법을 배워야 합니다. 에이전트가 일하는 동안 콘서트를 보러 가거나 산책을 해야 합니다. 에이전트는 계속 일하게 해도 됩니다. 하지만 자신은 속도를 조절해야 합니다.

마지막으로 모든 것을 문서화해야 합니다. 자신이 배운 것을 직접 기록하는 것도 중요하지만, 에이전트가 스스로 기록하게 하는 것도 중요합니다. 내가 무엇을 좋아하고 싫어하는지, 같은 실수를 반복하지 않도록 세팅해야 합니다.

이 두 번의 탐색 이후에도 저는 아직 이 늪을 완전히 건넜다고 느끼지 못했습니다. 아까 말한 것처럼 디자이너가 코드에서 작업하고 PR을 만들고 AB 테스트를 하는 수준까지 가야 했습니다.

그래서 AI 미션을 진행하던 한 엔지니어와 이야기했습니다. 그는 “금요일마다 pull request를 해 보면서 마켓플레이스 코드에서 뭔가를 바꿔 보면 어떻겠냐”고 말했습니다.

우리는 규칙을 세웠고, 지금까지 다섯 번 시도했습니다. 성공도 있었고 실패도 있었습니다. 조금 더 설명하겠습니다.

처음에는 아주 단순하게 시작했습니다. 실험 없이 시작했습니다. 세 번째는 성공할 수 있었지만 어쨌든 실패했습니다. 네 번째는 실험을 통과하지 못했습니다. 다섯 번째는 작동했습니다. 아직 결과를 기다리고 있지만, 영향이 있을 것이라고 생각합니다.

제가 말하려는 요지는 증거를 찾아야 한다는 것입니다. 공유할 수 있고, 스스로 더 밀고 나갈 동기를 줄 수 있는 증거가 필요합니다.

저는 관찰만 한 것이 아닙니다. 우리만 PR Friday를 한 것도 아닙니다. 지난주 아그네는 디자인 뎁스뿐 아니라 이미 내부 프로젝트의 반복 작업에서 완전한 PR을 수행하는 방법을 발표했습니다.

보너스도 여기 있습니다. 그는 분석을 위해 데이터 사이언티스트 자원을 얻지 못했습니다. 그래서 MCP를 세팅해 분석을 수행한 방법을 공유했습니다. 그것은 이미 실험으로 이어졌습니다.

그리고 마지막으로 기드리우스와 프린시펄 PM은 Vinted의 생성형 경험을 만들었습니다. 처음에는 완료까지 1년 정도 걸릴 것으로 생각했습니다. 그런데 한 달 정도 만에 했습니다.

이 모든 것은 하나의 증거로 이어집니다. 우리가 원한다면 모두 할 수 있다는 증거입니다.

그리고 이것은 조금 긴 이야기지만 가장 중요한 부분입니다. 성공도 좋지만, 더 중요한 것은 병목을 발견하는 것입니다.

아까 말했듯이 모든 것을 문서화해야 합니다. 잊지 않도록 위키에 적어 두어야 합니다. 나중에 그것을 들고, 그 병목을 해결하는 데 도움을 줄 사람들과 이야기해야 합니다.

이것은 많은 병목을 발견하는 데 도움이 됐습니다. 중요합니다. 나중에 다른 사람들도 같은 길을 지나가게 될 것이기 때문입니다. 여러분이 그 병목을 해결해 두면, 그들은 더 멀리 갈 수 있습니다.

마지막으로 실천 단계에서 우리가 얻은 큰 배움은 우리가 현재 어디에 있는지 이해하게 됐다는 점입니다. 이것은 현재 엔지니어링과 다른 기능 조직들과 어느 정도 합의한 내용입니다.

우리는 tier 1 수준의 pull request는 할 수 있다고 합의했습니다. 유지보수, 디자인 뎁스, 버그, 위생 작업 같은 것은 이미 할 수 있습니다. 나머지는 기드리우스가 작업 중인 프로토타이핑 환경에서 다루고 있습니다. 이것은 핸드오프를 위해 필요합니다.

엔지니어들은 이 점을 좋아했습니다. 우리가 너무 많은 것을 하지는 않을 것이라는 점을 이해했기 때문입니다. 우리가 그렇게 미친 것은 아니지만, 동시에 엔지니어들이 별로 하고 싶어 하지 않는 부분을 어느 정도 맡을 수 있습니다. 그러면 엔지니어들은 엔지니어링에 집중할 수 있습니다.

저는 이것도 여전히 승리라고 봅니다. 문이 열렸기 때문입니다. 기술은 계속 발전할 것이고, 언젠가는 tier 2부터 시작하게 될 수도 있습니다.

---

사람들을 함께 데려오기

기드리우스:
만타스가 자기 실천에 사용한 원칙들을 보여 주었습니다. 하지만 결국 다른 사람들도 참여시켜야 합니다. 변화는 고립된 한 지점에서 일어나지 않습니다. 조직 전체에서 일어납니다.

우리가 사용한 첫 번째 원칙은 매우 중요합니다. 여러분 자신도 회사의 병목일 수 있다는 점을 이해해야 합니다.

이를 해결하기 위해 우리는 앞으로 나아가는 방식은 자기 자신을 민주화하는 것이라고 합의했습니다. 이것이 무슨 뜻일까요? 여러분이 무엇을 하든, 그 지식과 도구를 AI나 다른 사람들에게 노출해야 한다는 뜻입니다.

디자인에도 적용됩니다. 무엇을 하든, 엔지니어와 PM을 포함해 누구나 디자인할 수 있다는 사고로 전환해야 합니다. 처음에는 미친 생각처럼 들렸습니다.

하지만 사고를 “우리가 고품질 디자인을 만든다”에서 “우리는 고품질 디자인이 만들어지도록 보장한다”로 바꾸면, 여러분은 작업 자체가 아니라 인프라와 결과를 소유하게 됩니다.

이 원칙은 엔지니어링, 제품, 데이터, 사실상 모든 곳에 적용됩니다.

여기 보시면, 우리 법무 총괄인 엘레나도 Lovable을 사용해 무언가를 만들고 있다고 썼습니다. 콘텐츠디자인팀은 콘텐츠를 생성하기 위한 스킬을 작성하고 있습니다. DSA는 실험 스킬을 작업 중입니다. 새로운 실험을 자동으로 만들 수 있게 하려는 것입니다. 아마 엔지니어링과 함께 하는 작업일 것입니다.

만타스:
짧게 말하겠습니다. 여러분은 자신이 가장 진보적이고, 가장 똑똑하고, 천재라고 생각할 수 있습니다. AI로 온갖 미친 일을 하고 있기 때문입니다. 하지만 보통 여러분만 그런 것은 아닙니다.

변화가 한 곳에서만 일어나지 않는다는 점을 이해해야 합니다. 가서 사람들과 이야기하십시오. 그들이 무엇을 하고 있는지 배우고 이해하십시오. 특히 엔지니어링부터 시작하는 것이 좋습니다. 그들이 이 미래를 어떻게 보는지 이해해야 합니다.

디자이너로서 여러분이 가진 가장 큰 기술과 역량은 사람들을 정렬시키는 것입니다. 이것이 우리의 직업입니다. 누군가 미래의 모습을 생각하고 있다면, 사람들이 적어도 같은 방향을 보도록 정렬시키십시오. 그래야 일을 최적화할 수 있습니다.

우리가 엔지니어링, DSA 등과 함께 작업하기 시작했을 때 병목이 더 빨리 드러나기 시작했습니다. 모든 것을 해결한 것은 아니지만, 여러 기능 조직의 사람들이 같은 방향을 보면 도움이 됩니다.

또 하나 중요한 점은 모든 사람이 처음부터 같은 속도로 미래를 바라보지는 않는다는 것입니다. 그래도 괜찮습니다. 어떤 사람은 몇 년 앞에 살고, 어떤 사람은 현재에 머물고 싶어 합니다.

제가 배운 것은, 중요한 것은 “나는 AI 알약을 먹었고 미래에 대해 맞고 싶다”가 아니라는 점입니다. 중요한 것은 그 AI 알약을 퍼뜨려서 모두가 조금은 같은 미친 상태가 되게 하는 것입니다.

회의론자나 늦게 따라오는 사람도 함께 데려와야 합니다. 문서만 공유하지 말고 실제로 참여시켜야 합니다.

예를 들어 제프를 말하는 것은 아닙니다. 제프는 훌륭하고 저는 그를 좋아합니다. 하지만 제프가 우리가 겪고 있는 어려움과 병목을 이해하게 하는 방법 중 하나는, 성공했던 다섯 번째 PR Friday에 그를 드라이버로 초대한 것이었습니다.

그는 직접 PR을 만들고, 실험을 수행하는 전체 흐름을 경험했습니다. 그 후 실험팀에 돌아가 개선 목록을 가져갔고, 이미 여러 개선을 요청했습니다. API와 관련된 부분, 읽기 전용이 아닌 부분 등입니다. 자세히 들어가지는 않겠습니다.

이 방식은 사람들에게 AI 알약을 조금 더 먹이는 데 도움이 됐습니다. 다시 말하지만, 문서만 쓰지 말고 사람들을 실제 시도에 참여시키십시오. 그러면 그들은 생각보다 더 많은 것이 가능하다는 것을 배웁니다. 모든 것이 가능하다는 것은 아니지만, 생각보다 더 많은 것이 가능합니다. 그리고 그들도 Doing Method를 사용하게 됩니다.

기드리우스:
맞습니다. 지금은 Doing Method가 확실히 더 쉬운 방법입니다.

마지막 부분입니다. 이 부분은 리더십팀에서 많이 수정했습니다. 원래는 이 주제로 세 장 정도 슬라이드가 있었는데 줄였습니다.

저는 처음에 “변화는 리더십에서 시작된다”고 썼다가 “공유된 책임”으로 바꿨습니다.

변화는 양쪽에서 일어납니다. 위에서 아래로, 아래에서 위로 모두 일어납니다. 리더들이 도구를 만져 보지 않았다면, 개인 기여자들에게 변화를 기대할 수 없습니다.

성장 목표를 세우고, 채용하고, 사람을 평가하는 리더십이 AI 도구를 직접 시도하지 않고 개인 기여자를 어떻게 평가할 수 있을까요? 이것은 중요한 문제입니다. 그래야 격차를 줄일 수 있습니다.

저희에게 그런 문제가 있다는 말은 아닙니다. 일반적인 이야기를 공유하는 것입니다.

리더십이 사람들을 새로운 미래로 데려가는 방법을 묻는다면, 저는 항상 이렇게 답할 것입니다. Doing Method를 쓰십시오.

시간이 있다면 그레이스 호퍼를 꼭 찾아보시기를 권합니다. 그는 프로그래밍을 숫자에서 단어로 바꾼 사람입니다. 그때도 사람들은 “이제 어떻게 프로그래밍하나, 우리 일자리가 없어지는 것 아닌가”라고 말했습니다. 그는 그 시대에 정말 많은 놀라운 일을 했습니다.

그가 남긴 발표 중에는 사람들이 미래를 더 많이 생각해야 하고, 리더십이 단지 관리하는 것이 아니라 사람들을 미래로 함께 데려가야 한다는 내용의 훌륭한 발표가 있습니다.

---

앞으로 무엇을 할 것인가

기드리우스:
제가 무슨 말을 하려 했는지 기억해야겠습니다. 아, 기억났습니다.

우리는 우리가 경험한 병목을 조금 다뤘습니다. 일부는 해결했고, 전부는 아닙니다. 우리가 가질 수 있는 미래의 일부도 보았습니다. 하지만 아직 거기에 도달하지는 못했습니다. 디자인과 코딩이 아직 하나가 아니라는 점도 인정합니다.

지난 3~4개월 동안 많은 변화가 있었습니다. 그래서 이제 우리의 비전도 어느 정도 확장해야 합니다.

다음 질문은 이것입니다. 우리는 어디로 가야 할까요? 이 변화를 가능하게 하려면 어떤 영향을 만들어야 할까요?

세 가지에서 시작합니다.

첫 번째는 AI를 동료로 보는 것입니다. 민주화를 생각할 때 가장 먼저 떠오르는 것은 PM이 디자인하거나 엔지니어가 디자인할 때도 고품질 산출물을 만들 수 있어야 한다는 점입니다.

AI를 동료로 가져오고 싶습니다. 여러분이 디자이너이든 아니든, 고품질이고 영향력 있는 변화를 만들 수 있도록 도와주는 동료입니다. 물론 결국에는 프로덕션으로 가는 변화입니다.

우리는 스킬을 만들기 시작했습니다. 현재 이 스킬들은 더 나은 결정을 내리고, 피드백을 주고, 일부 작업을 완료하도록 돕는 가이던스 제공자처럼 작동합니다.

우리는 모든 디자이너를 대체하려는 것이 아닙니다. 목표는 디자이너가 훨씬 더 역량 있게, 더 영향력 있는 일을 할 수 있도록 만드는 것입니다. 결국 이 AI 어시스턴트는 디자이너뿐 아니라 PM, 엔지니어, 다른 사람들에게도 좋은 동료가 될 수 있습니다.

두 번째도 매우 중요합니다. 만타스의 사례를 생각해 보십시오. 그의 지식은 그의 컴퓨터에 있습니다. 로컬에 있습니다. 만타스의 지식이 있고, 여러분의 지식이 있습니다. 하지만 그것은 집단 지식이 아닙니다.

회사에서 일할 때는 집단 지식이 필요합니다. 조직이 성장하고 발전하면서 공유되고 확장되는 지식입니다.

그래서 우리는 공유 메모리 뱅크라는 아이디어를 실험하고 있습니다. 여러 사람이 자기 에이전트를 연결할 수 있는 구조입니다. 궁극적으로 AI가 모두에게서 배우고, 모두를 통해 더 좋아지며, 특정 작업을 하는 사람이 그 학습을 가져와 재사용할 수 있게 하려는 것입니다.

세 번째는, AI로 미친 듯이 많은 일을 할 수 있지만 제품개발은 팀 스포츠라는 점입니다. 팀으로 일하면 오래 남는 것을 만듭니다.

질문은 이것입니다. 팀 전체를 AI로 어떻게 데려올 것인가?

제가 AI에 프롬프트를 넣고 싶은 것이 아닙니다. 제 팀이 AI에 프롬프트를 넣을 수 있기를 원합니다. 제 팀이 디자인하고, 제 팀이 출시하기를 원합니다. 그래서 사람들이 함께 일할 수 있게 하는 도구가 필요합니다.

결국 가장 큰 병목은 정렬, 커뮤니케이션, 협업이기 때문입니다.

---

1부 마무리

만타스:
이제 끝에 도달했습니다. 요약하겠습니다.

미래는 이미 여기 있습니다. Vinted에도 이미 와 있습니다. 우리는 그 일부를 보고 있습니다.

AI는 여러분이 더 많은 일을 할 수 있게 합니다. 10배, 100배라고 부르든 무엇이라 부르든 말입니다. 그리고 앞으로 더 좋아질 것입니다. 이것이 메시지입니다.

하지만 가장 큰 도전은 병목을 해결하는 것입니다. 병목을 식별하고 다뤄야 합니다. 이것은 여러분이 일하는 회사에도 적용되고, 개인 자신에게도 적용됩니다. 지금 가장 큰 기회는 바로 여기에 있습니다.

마지막으로, 최전선에 도달하려면 회복력, 고집스러운 낙관주의, 몇 번의 실패, 배움, 약간의 건강한 정신병, AI 알약, 그리고 그 여정을 함께 나눌 사람이 필요합니다.

[박수]

---

1부 Q&A

사회자:
와. 기드리우스와 만타스, 감사합니다. 질문을 위해 몇 분만 쓰겠습니다. 질문 있으시면 손을 들어 주세요. 마이크가 필요하겠네요.

질문자 1:
안녕하세요, 여러분. 디자이너들이 코드로 들어가는 모습을 보니 반갑습니다. 그런데 방 안에 코끼리가 하나 있는 것 같습니다. 엔지니어가 디자인으로 들어가는 것은 어떻습니까? 다시 말해 프론트엔드 엔지니어는 무엇을 하게 됩니까?

기드리우스:
제가 답하겠습니다.

저는 실제로 AI 엔지니어링 미션팀 워크숍에 있었습니다. 비슷한 내용을 발표하면서 “우리가 디자인을 민주화할 것이니 여러분도 디자인할 수 있습니다”라고 말했습니다. 그랬더니 그들은 “왜 그래야 하죠? 저는 아무것도 디자인하고 싶지 않습니다”라고 했습니다.

그래서 다시 같은 메시지로 돌아갑니다. 하고 싶다면 할 수 있어야 합니다. 그렇다고 모두가 디자인해야 하거나, 모두가 코딩해야 한다는 뜻은 아닙니다.

이 가능성과 역량이 매우 큰 기회를 열어 줍니다. 이 워크숍에서 가장 인상 깊었던 점은 AI 엔지니어링 미션팀이 목표에 이런 문장을 썼다는 것입니다. 정확히 말하면 “팀 안의 누구나 Vinted 회원에게 변화를 출시할 수 있어야 한다”는 내용이었습니다. 그것이 목표라고 생각합니다.

질문자 2:
다이어그램에서 아이디어가 흐르고, 호스의 큰 부분을 차지하다가 병목이 나오고, 개발 시간이 나오는 구조를 보여 주셨습니다. 만약 아이디어 실행의 병목을 제거해서 더 많은 아이디어를 실행할 수 있게 된다면, 좋은 아이디어가 실행되도록 어떻게 보장할 수 있을까요? 그저 평범한 아이디어들이 자유롭게 통과해 개발되고 실행되는 것은 어떻게 막을 수 있습니까?

만타스:
저는 이것을 시작 단계의 관점에서 봐야 한다고 생각합니다. 우리는 아직 품질에 투자할 수 있는 지점까지 도달하지 않았습니다. 물론 스킬을 통해 가능한 만큼 할 수는 있습니다. 하지만 우리가 지금 사물의 시작점에 있다는 점을 이해해야 합니다.

우리는 개척 단계에 있습니다. 월드리 매핑에는 개척자, 정착민, 도시계획가 같은 단계가 있습니다. 우리는 지금 첫 단계에 있습니다. 우리의 목표는 가능하다는 것을 보여 주는 것입니다. 그것이 항상 최고의 품질은 아닐 수 있습니다. 하지만 우리는 빠르게 배우고 있습니다.

질문에 직접 답하지는 못했을 수 있지만, 시간이 필요하다고 말하고 싶습니다. 더 많이 연습해야 더 나아질 수 있습니다. 변화가 일어날 때마다 약간의 혼란은 생깁니다.

기드리우스:
제가 덧붙이겠습니다. 예를 들어 우리가 만든 스킬 중 몇 가지는 디스커버리 초기 단계를 다룹니다. 만타스와 프린시펄 PM 모두에게서 들은 의견이 있습니다. 그들은 이 스킬이 우리가 말하는 시니어 PM의 기준을 세운다고 말했습니다.

즉 어떤 레벨에서 일하든, 이 스킬을 사용하면 시니어 PM처럼 작동할 수 있다는 것입니다. 이것이 기준을 더 높이는 데 사용할 도구라고 생각합니다. 오늘날에도 우리가 출시하는 모든 것이 훌륭한 것은 아닙니다.

만타스:
마무리하자면, Figma의 오토 레이아웃은 이미 몇 년 전부터 있었습니다. 그런데 저는 아직도 디자이너들에게 우리가 오토 레이아웃을 제대로 쓰지 못하고 있다고 말하고 보여 줍니다.

계속 디자이너들에게 오토 레이아웃을 배우라고 압박할 수도 있습니다. 아니면 스킬을 만들 수도 있습니다. 접근 방식은 다르지만, 결국 더 나은 결과에 도달할 수 있다고 봅니다.

질문자 3:
발표 감사합니다. 병목에 대해 생각해 보았습니다. 만약 우리 모두가 디자인하고 코드도 작성하고, 모든 회사가 그렇게 한다고 가정해 보겠습니다. 그런데 우리가 해결책이라고 만든 것이 실제 병목이 아니라 단순히 더 많이 생산하는 것일 수도 있습니다. 아까 병목은 커뮤니케이션이나 정렬이라고 말하셨고, 그것은 여전히 남아 있습니다. 적어도 완전히 다루지는 못한 것 같습니다. 모두를 정렬시키는 마법은 어디에 있습니까? 모두가 쓰는 디자인 MCP 서버 같은 것입니까? 아니면 공유 패키지 같은 스킬입니까? 아이디어가 있습니까? 철학적인 질문이고, 두 번째 질문도 있습니다.

기드리우스:
철학적인 질문에 먼저 답하겠습니다. 실무적인 질문은 이 사람이 답할 것입니다.

간단히 말하면 프로세스가 바뀝니다. 저는 PM과 일하면서 이것을 경험했습니다. 기술적으로는 PM과 일하는 것보다 AI와 일하는 것이 더 쉽습니다. 물론 우리는 둘 다 있습니다.

[웃음]

그 이유는 공유 도구가 없기 때문입니다. 만약 제가 함께 앉아 있고, Slack 채널이 있고, PM도 같은 Slack 채널에 있다면, 우리는 같은 채널에서 프롬프트를 넣을 수 있습니다. AI는 전체 맥락을 얻습니다. 제가 말하는 것은 PM도 보고, PM이 말하는 것은 저도 봅니다. 우리는 같은 프로토타입을 만들고, 같은 것을 출시합니다.

도구를 생각해 보면, 사람은 여전히 사람이기 때문에 모든 것을 완전히 해결할 수는 없습니다. 하지만 일부 문제는 도구 때문에 생깁니다. 그래서 더 나은 도구는 병목을 줄일 것입니다. 우리는 애초에 AI를 위한 준비가 되어 있지 않았기 때문입니다.

만타스:
요약하자면, 현재 있는 프로세스를 개선하는 접근도 가능합니다. 누가 무엇을 할 수 있는지, 우리의 프레임워크와 원칙은 무엇이어야 하는지 보고, 그것을 배포하고 설교하는 방식입니다. “이렇게 생각해야 합니다”라고 말하는 식입니다.

하지만 도구 관점에서 생각할 수도 있습니다. 도구를 통해 비슷한 결과를 얻을 수 있습니다. 같은 스킬, MCP, 지식 등이 그 예입니다. 이것을 해결하면 프로세스에도 영향을 줍니다.

처음에 우리는 목적 스킬을 도입했습니다. 지금도 그것을 따릅니다. 목적, 기능, 형태입니다. 이것을 문서로 만들고 배포할 수도 있었습니다. 하지만 우리는 그것을 위한 스킬을 만들기로 했습니다.

이 스킬은 사용자가 목적을 생각하게 합니다. 기능을 생각하게 합니다. 그리고 아직 우리가 제대로 배우지 못한 오토 레이아웃까지 포함해 적절한 형태를 제공합니다. 이것은 프로세스와 품질에 영향을 줍니다. 같은 결과를 얻는 다른 방식입니다.

질문자 3:
감사합니다. 두 번째 질문입니다. 프로토타입을 보여 주셨고, 아직 tier 2, tier 3라고 하셨습니다. 사람들이 쓰고 버리는 disposable prototype이 길이라고 보십니까? 아니면 모두가 기여하고 같은 페이지를 유지하는 master prototype이 필요하다고 보십니까?

기드리우스:
현재로서는 두 가지 개념을 모두 갖고 있습니다. 만타스와 많은 논쟁을 했습니다. 우리는 프로덕션으로 가고 프로토타입은 잊을 것인가, 아니면 프로토타입과 프로덕션을 함께 둘 것인가.

우리는 양쪽에서 접근하고 있습니다. 두 가지를 모두 갖는 이유는, 큰 변화를 탐색할 때는 프로덕션에서 하는 것이 말이 안 되기 때문입니다. 반대로 작은 변화는 프로덕션에서 하는 것이 맞습니다.

좋은 점은 아마도 Git tree에서는 우리가 수동으로 만든 현실적인 프로토타입을 프로덕션에서 생성할 수 있을 것이라는 점입니다. 본질적으로 프로덕션 코드에서 프로토타입을 생성하게 될 것입니다. 그러면 그것이 마스터가 될 수 있습니다. disposable로 만들어도 상관없습니다.

사회자:
좋습니다. 마지막 질문 하나만 받겠습니다.

질문자 4:
감사합니다. 저는 PM이라서 조금 침입자 같은 느낌이 듭니다. 죄송합니다.

실무적인 질문입니다. 리더십과 어떻게 이야기해야 할까요? 아까 변화는 아래에서도 위에서도 와야 한다고 하셨습니다. 저는 꽤 큰 조직에서 일합니다. 그들은 우리에게 “AI, AI, AI를 하자!”라고 외칩니다. 하지만 실제로는 리스크팀이 사방에서 막습니다. 도구 접근도 제한되고, 무엇에 접근할 수 있는지도 제한됩니다.

저도 위키 같은 것을 만들고 싶지만, 거버넌스와 리스크 등 때문에 거의 불가능합니다. 어떻게 이야기해야 할지 아이디어가 있을까요?

만타스:
Vinted에 지원하시면 됩니다.

[웃음]

또는 제가 다시 같은 말을 반복하겠습니다. Doing Method입니다. 밀고 나가고, 접근 권한을 찾고, 얻으십시오. 개인 학습 예산이든 무엇이든 사용하십시오.

리더십과 일하는 방식에 대해서는, 그들을 계속 회의론자나 늦게 따라오는 사람으로 둘 수도 있습니다. 아니면 함께 무언가를 만들도록 참여시킬 수도 있습니다.

이것은 실제로 하나의 과업입니다. 저는 스태프이고, 이것이 제 일상 업무입니다. 비전을 팔고, 사람을 정렬시키고, 참여시키고, 밀고 나가는 기술이 필요합니다. 그런 관점에서는 스태프 역할의 사람이 필요할 수도 있습니다.

기드리우스:
제가 덧붙이겠습니다. 어떤 각도를 말하는지 모르겠습니다. 보안 문제라면, 제가 가장 먼저 할 일은 보안팀에 이 문제를 해결하게 하는 것입니다.

로컬에서 실행되는 모델도 있습니다. 컴퓨터에서 돌리면 아무것도 유출되지 않습니다. 공유하고 싶지 않은 정보를 제거해 주는 모델도 있습니다. 여러 방법이 있습니다.

보안팀이 이런 것을 모른다면, 아마 보안팀에도 AI 알약을 좀 먹여야 할 것입니다.

사회자:
정말 감사합니다. 훌륭했습니다. 두 분은 이후에도 남아 있을 테니 추가 질문이 있으면 나중에 해 주시면 됩니다.

이제 다음 슬라이드로 넘어가겠습니다.

---

피터 머홀즈 소개

사회자:
이제 피터 머홀즈를 소개하게 되어 정말 기쁩니다.

여러분은 피터의 글을 아실 것입니다. 그는 크리스틴 스키너와 함께 『Org Design for Design Orgs』를 공동 집필했습니다. 디자인팀을 이끄는 분이라면 적어도 그 책을 알고 있거나 읽어 보셨을 것입니다.

피터는 제가 개인적으로 즐겨 듣는 팟캐스트인 Finding Our Way도 운영합니다. 좋은 게스트와 흥미로운 대화가 많습니다.

개인적으로 저는 여러 방식으로 피터와 함께 일할 수 있는 특권을 가졌습니다. 처음에는 그 책에서 시작했습니다. 제가 역할 초기에 무엇을 해야 할지 전혀 몰랐을 때, 그 책은 정말 필요한 명확성을 제공해 주었습니다.

이후 문제가 더 크고 복잡해졌을 때 피터가 코칭을 해 주기로 했습니다. 적어도 제게 피터의 사고는 명확성의 원천이었습니다.

지금 우리에게 또다시 명확성이 정말 필요한 상황입니다. 기대치를 너무 높이려는 것은 아니지만, 여러분, 피터 머홀즈를 환영해 주십시오.

[박수]

---

2부. 피터 머홀즈 발표

도입

피터 머홀즈:
안녕하세요, 여러분. 저는 피터입니다. 저는 캘리포니아 오클랜드에 살고 있습니다.

제가 왜 빌뉴스에 있는지 궁금하실 수 있습니다. 저는 휴가 중입니다. 저는 휴가 때 이런 일을 합니다. 혹시 키 큰 17세 소년을 보셨다면, 제 아들 줄스입니다. 저는 그를 이런 행사에 데리고 다닙니다.

저는 전 세계를 여행할 때 지역 디자인 및 UX 커뮤니티를 만나는 것을 좋아합니다. 일종의 병입니다. 또 이런 커뮤니티가 함께 모일 수 있는 기회를 만드는 것도 좋아합니다.

사실 저는 몇 년 전부터 이런 일을 해 왔습니다. 4년 전 유럽에 왔을 때도 비슷한 일을 했습니다. 하지만 지금 우리 산업과 세상에는 혼란과 카오스가 많습니다. 상당 부분은 제 나라 때문에 생긴 일이기도 합니다. 사과해야 할까요? 잘 모르겠습니다. 이상한 상황입니다.

어쨌든 이런 혼란과 카오스 속에서 커뮤니티는 필수입니다. 연결되고, 서로 이야기하고, 함께 이 상황을 이해하는 것이 중요합니다. 그래서 사람들이 모이는 촉매가 되는 일을 즐깁니다.

게다가 오늘 바깥 날씨가 조금 맑아 보이긴 하지만, 여러분도 그 날씨에서 벗어나 이곳에 들어와서 좋으실 것입니다. 오늘 날씨는 꽤 끔찍했습니다.

오늘 제가 공유할 것은 생각들의 모음입니다. 휴가를 떠나기 전 여러 발표에서 했던 내용을 섞은 것입니다. 제가 무엇을 썼는지 어렴풋이 기억합니다. 잘될 것입니다.

다만 아주 명확한 하나의 서사는 없습니다. 디자인, AI, 리더십에 관한 생각의 산책이라고 봐 주시면 됩니다.

흥미로웠던 점이 하나 있습니다. 이전 발표에서 “조건”이라는 단어를 사용했습니다. 저도 디자인 리더십에 많이 초점을 둡니다. 그래서 여기에도 디자인 리더십의 관점이 있습니다. 이 방에 모두가 리더인 것은 아니지만, 대부분 적용 가능하다고 생각합니다.

이전 발표에서 “조건”이라는 단어를 쓴 것이 흥미로웠습니다. 지금 새로운 도구와 기술을 다룰 때 우리가 보고 있는 주제 중 하나가 바로 이것입니다. 이 도구들은 현재 상태를 증폭하고 가속합니다. 따라서 그 조건을 설정한 뒤, 그것이 증폭되고 가속되도록 해야 합니다.

그 조건을 의도적으로 설정하지 않으면, 많은 조직에서 지금 겪고 있는 혼란을 얻게 됩니다.

---

디자인이라는 기능의 특수성

피터 머홀즈:
먼저 디자인에 대한 설명으로 시작하겠습니다. 모두가 같은 위치에서 디자인을 바라보는 것은 아니기 때문입니다. 또 우리 중 많은 사람은 함께 일하는 사람들이 왜 우리를 이해하지 못하는지 이해하는 데 어려움을 겪습니다.

저는 이것을 조금 분석해 봤습니다. 저는 디자인이라는 기능이 독특하다고 봅니다.

저는 조직디자이너입니다. 그래서 디자인을 단지 장인정신, 실천, 프로세스로만 보지 않습니다. 회사 안에서 특정한 가치를 전달할 책임을 가진 부서로 봅니다.

그렇게 보면 디자인은 다른 기능과 같지 않습니다. 마케팅, 세일즈, 제품관리, 엔지니어링과 다릅니다.

몇 가지 이유가 있습니다.

첫째, 디자인은 임원급 기능으로서는 새롭습니다. 요나스는 디자인 VP입니다. 하지만 디자인 VP라는 역할이 생긴 지는 대략 20년 정도밖에 되지 않았습니다. 다른 기능의 VP들은 훨씬 오래전부터 있었습니다.

그래서 디자인은 임원급에서 비교적 새로운 권한을 가진 기능입니다. 이것은 우리가 덜 성숙하다는 뜻이기도 합니다. 우리는 여전히 기능으로서 우리가 무엇인지 정의해 가고 있습니다.

이미 임원 테이블에는 많은 사람이 앉아 있었습니다. 그런데 우리가 팔꿈치로 비집고 들어가며 “저희도 여기 있습니다”라고 말하는 상황입니다. 그러면 그들은 “우리는 당신 없이도 잘하고 있었는데, 이 수준에서 디자인이 정말 필요합니까?”라고 생각합니다.

둘째, 디자인은 조직적으로 낯섭니다. 우리는 창의적이고, 감정적이고, 모호하며, 인간 중심적입니다. 이런 가치는 다른 기능들과 자주 공유되지 않습니다.

셋째, 디자인은 쉽게 측정되기 어렵습니다. 디자인만의 OKR을 식별하기 어렵습니다. 해 본 분들은 알 것입니다. 오늘 자세히 다루지는 않겠지만, 이것도 나중에 이야기할 수 있습니다. 저는 그 문제를 많이 생각합니다.

넷째, 디자인의 가치는 주로 다른 팀의 일을 촉진하거나 증폭하는 데 있습니다. 우리는 보통 직접 가치를 전달하지 않습니다. 제품팀과 엔지니어링팀과 협업하고, 마케팅과 협업합니다. 서비스디자인을 한다면 HR이나 운영팀과도 협업할 수 있습니다. 우리는 직접 가치를 전달하기보다, 다른 팀이 자기 가치를 더 잘 전달하도록 돕습니다. 이것이 제가 말하는 촉진과 증폭입니다.

그리고 우리에게는 또 하나의 문제가 있습니다. 디자인은 poorly defined, 즉 제대로 정의되지 않은 기능입니다.

디자인은 아주 작은 UI 디테일부터 5년짜리 옴니채널 제품전략까지 모든 것을 의미할 수 있습니다. 그 안에 리서치, 콘텐츠, 접근성 같은 기능이 포함되기도 합니다. 이것들이 디자인일까요? 디자인이 아닐까요? 다른 기능들은 디자인처럼 이렇게 서로 다른 하위 기능을 품고 있지 않은 경우가 많습니다.

또 디자인씽킹 같은 것도 있습니다. 이것도 디자인의 책임일까요?

이 마지막 부분에서 제가 말하려는 것은, 사람들이 디자인에게 무엇을 요청해야 하는지 모른다는 것입니다. 디자인이 할 수 있는 모든 것을 우리는 알고 있지만, 그것을 전달하기는 어렵습니다.

그래서 우리는 이미 조직 안에서 좋은 일을 하려고 할 때 이런 혼란을 안고 있습니다. 그런데 이제 우리는 전례 없는 강도와 불확실성 아래에서 일하고 있습니다.

요나스가 언급한 팟캐스트 Finding Our Way에서 저는 제시 제임스 개릿과 공동 진행을 합니다. 게스트로 폴 포드가 나온 적이 있습니다. 재미있는 에피소드였습니다. 그는 정말 웃긴 사람입니다.

그가 말한 것 중 하나는, AI가 역사상 최악의 기술 롤아웃이라는 것이었습니다. 이 기술은 그냥 우리 책상 위에 던져졌습니다. 조정도 없고, 조직도 없고, 계획도 없습니다. 모두가 이것을 어떻게 이해해야 할지 정신없이 달리고 있습니다.

동시에 우리는 모두 업무 시간의 몇 퍼센트를 AI에 써야 한다는 지시를 받습니다. 토큰도 많이 써야 합니다. 말도 안 되는 상황입니다. 이 기술이 얼마나 형편없이 배포됐는지를 보여 줍니다.

디자이너 펀드라는 곳에서 연구를 했습니다. 디자인 기반 스타트업에 투자하는 벤처캐피털입니다. AI와 디자인에 대한 연구였습니다. 보고서를 내려받을 수 있습니다. 제목은 아마 State of AI Design 같은 것이었을 것입니다. 그런 단어들을 검색하면 찾을 수 있을 것입니다.

그 보고서에는 많은 발견이 있었지만, 제게 특히 눈에 띈 것이 있습니다. 작년에 디자이너들은 평균적으로 세 개의 AI 도구를 사용했습니다. 2026년에는 같은 집단이 일곱 개를 사용하고 있었습니다.

그런데 아마 모두가 서로 다른 일곱 개를 쓰고 있을 것입니다. 이미 수십 개의 도구가 있다는 것을 우리는 압니다. 하지만 모든 디자이너가 자기 툴킷에 없던 일곱 개의 새 도구를 이해해야 한다면, 그리고 그 도구들이 서로 다르면서도 비슷한 일을 한다면, 또 다른 사람들이 쓰는 도구와도 다르다면 어떻게 될까요?

이전 발표에서 들은 것처럼 수많은 도구가 있고, 아무도 이것을 조직하거나 조정하지 않습니다. 모든 디자이너가 자기 혼자 알아서 이해해야 합니다.

게다가 정해진 go-to stack도 없습니다. 어떤 도구를 어떤 순서로 쓰는 것이 가장 좋은지 모릅니다. 그래서 디자이너들 사이에 불안, 좌절, 고립감이 생깁니다.

이 도구들로 할 수 있는 일은 많습니다. 이제 우리는 디자이너들이 사실상 프로덕션에 커밋하는 것까지 기대하게 됩니다. 이것도 해야 하는 일일까요? 디자이너들은 자기 역할이 무엇인지, 자기 일을 어떻게 해야 하는지 이해하려고 애쓰고 있습니다.

대부분의 조직에서는 이 일을 가능하게 하는 맥락이 거의 제공되지 않았습니다. 이것이 모든 회사가 직면한 도전입니다.

여러분이 이것을 느끼고 있다면, 여러분만 그런 것이 아닙니다. LinkedIn에서 다른 모든 사람이 자기 솔루션에 확신을 가진 것처럼 보인다고 해서 속지 마십시오. 거짓말이라고까지 말하고 싶지는 않지만, 상당수는 포장하고 있을 것입니다.

---

AI는 현재 상태를 증폭한다

피터 머홀즈:
제가 내부 리더십팀을 대상으로 발표했던 회사 중 하나가 General Motors였습니다. 준비 과정에서 디자인 VP인 알렉스와 이야기했습니다. 그곳에는 디자인 리더가 많습니다.

준비 과정에서 그가 이런 이야기를 공유했습니다. 그들이 발견한 문제 중 하나는 PM들이 요구사항을 명확하게 전달하지 못한다는 것이었습니다.

그런데 좋은 사례도 있었습니다. 어떤 PM은 AI를 사용해 매우 단순한 디자인을 만들었습니다. 디자이너들은 그것을 좋아했고, 바로 이어받아 발전시켰습니다. 그 결과 모두가 더 좋아졌습니다. PM은 디자이너가 이해하는 언어를 더 빠르고 잘 사용할 수 있었고, 디자이너는 자기가 가장 잘하는 일을 했습니다. 디자인 말입니다.

PM의 의도는 “내가 디자이너가 되겠다”가 아니었습니다. 의도는 “내 생각을 더 잘 전달하겠다”였습니다. 디자이너는 그것을 이해하고 이어받았습니다.

이 사례는 PM들이 도구를 갖게 되면 디자인까지 해 버리는 것 아니냐는 디자이너들의 우려에 답합니다. 어떤 조직에서는 실제로 그렇게 됩니다. 하지만 GM의 이 팀에서는 PM이 도구를 사용해 생각을 전달했고, 이것은 긍정적으로 작동했습니다. 그 결과 PM과 디자이너가 더 잘 만날 수 있었습니다.

여기서 몇 가지 교훈이 있습니다.

첫째, 도구가 핵심은 아닙니다. 우리는 도구에 매우 집중합니다. 도구가 많기 때문입니다. 하지만 이전 발표에서도 들었듯이, 도구에 너무 스트레스받을 필요는 없습니다.

둘째, 명확한 의도가 필요합니다. 무엇을 해야 하는지 아는 적절한 사람들이 필요합니다.

셋째, 에고를 낮춰야 합니다. PM이 약간 디자인을 하거나 디자이너가 PRD나 코드를 다루더라도 사람들이 자기 영역을 방어하지 않아야 합니다. 공유 목표가 있어야 합니다.

AI는 이미 있는 것을 증폭합니다.

제가 최근 하고 있는 일 중 하나는 listening tour입니다. 실제로 여행을 다니는 것은 아니고, 집에 앉아 전 세계 디자인 임원들과 이야기하며 지금 무슨 일이 벌어지고 있는지 감을 잡는 것입니다.

이 과정에서 계속 반복해 나온 주제가 바로 이것입니다. AI는 이미 있는 것을 증폭합니다. 신뢰가 있는 집단이라면 AI는 그 집단이 좋은 목표를 향해 더 좋고 빠르게 일하게 만들 것입니다. 하지만 두려움이 있거나 불안한 집단이라면 AI는 그것도 증폭합니다.

그래서 조건을 설정해야 합니다. 이전 발표에서도 들은 것처럼 말입니다.

제게 이것은 상당 부분 리더십의 기본에 관한 문제입니다. 오늘 리더십 기본 과정을 깊게 다룰 시간은 없습니다. 하지만 앞으로 이야기하면서 몇 가지를 짚겠습니다.

기본 주제는 이것입니다. 디자이너, 특히 디자인 리더는 보통 일을 지시하는 것에 집중합니다. 좋은 것이 세상에 나가도록 하거나 사람들에게 무엇을 하라고 말하는 것이 자신의 일이라고 생각합니다.

하지만 이제는 일을 지시하는 것보다 조건을 만드는 일이 더 중요합니다.

여러분의 가치는 그동안 좋은 일을 전달하는 능력에 있었습니다. 이제는 좋은 일이 반복적이고 지속 가능하게 만들어지는 공간과 시스템을 형성하는 능력에 있습니다. 우리는 정원사가 되고, 건축가가 됩니다. 더 이상 반드시 손으로 키보드를 두드려 작업물을 직접 전달하는 사람이 아니어도 됩니다. 좋은 일이 자라날 수 있는 시스템을 만드는 것입니다.

---

팀: 역할보다 스킬

피터 머홀즈:
그 길에서 몇 가지 단계가 있습니다. 첫 번째는 팀입니다.

이분은 캐런 핸슨입니다. 그는 Chase Bank의 최고디자인책임자였을 때 우리 팟캐스트에 출연했습니다. 미국 Chase Bank에서 UX 인력을 350명에서 1,000명 이상으로 키웠습니다. 하나의 팀입니다. 말도 안 되는 규모입니다.

그가 팟캐스트에서 공유한 내용은 이것입니다. 디자인 리더가 들어왔을 때 첫 번째 일은 강하고 탄탄한 팀을 만드는 것입니다. 팀이 탄탄하지 않으면 변화를 밀어붙일 수 없습니다.

AI 때문에 지금 팀, 역할, 이런 주제가 매우 흥미로운 주제가 되고 있습니다.

이분은 칭 젠입니다. Cloudflare에서 디자인 운영 책임자로 일했던 경험에 대해 많이 쓰고 있습니다. Figma 중심의 팀을 AI 도구 중심으로 전환한 경험을 공유하고 있습니다. 지금은 디자이너들이 더 이상 Figma를 많이 쓰지 않는다고 합니다.

그가 여러 교훈을 공유했는데, 저는 역할에서 스킬로 이동한다는 점에 집중하겠습니다.

우리가 마주해야 할 것은 역할, 즉 디자이너, 제품매니저, 디자인 테크놀로지스트, 엔지니어 같은 구분이 지금은 덜 중요해지고 있다는 점입니다.

무엇이 죽어가고 있을까요?

“그건 제 일이 아닙니다”라는 방어입니다. 제가 수없이 봐 온 장면입니다. 디자이너들이 자기 제품매니저가 일을 제대로 하지 않는다고 불평합니다. 하지만 자신들이 무엇이 필요한지 알고 있어도 “그건 제 일이 아닙니다. 다른 사람의 일입니다”라며 거부합니다. 이것은 방어가 될 수 없습니다.

또 하나는 역할 기반 도구 소유권입니다. 예를 들어 Cloudflare 경험에서는 이 과정을 지나고 나니 마케터와 PM이 디자이너보다 Figma를 더 많이 쓰게 됐다고 합니다. 도구와 역할의 연결이 떨어져 나가고 있습니다.

무엇이 변하고 있을까요? 직함입니다. 디자이너에서 빌더로, PM에서 제품 사람으로 바뀝니다. 커리어 래더도 변합니다.

저는 조직디자이너로서 사람들이 자기 역할 안에서 어떻게 성장하는지 많이 생각합니다. 스킬 기반이지 역할 기반이 아니라는 말은 매우 중요합니다.

이것을 보여 주는 또 다른 훌륭한 글을 쓴 사람이 있습니다. 특히 저처럼 조직디자인에 관심이 있다면 아주 뛰어난 글입니다. 이분은 클레이 파커 존스입니다. Airbnb의 디렉터로, 내부 조직디자인 역량을 이끌고 있습니다.

그는 우리 같은 의미의 디자이너는 아닙니다. Airbnb의 내부 조직을 디자인하는 일을 돕는 사람입니다.

그는 AI가 제품디자인 업무뿐 아니라 조직 전반에 어떤 함의를 갖는지 이야기하면서 매우 간단한 개념을 제시했습니다. 이제 우리는 role clarity, 즉 역할 명확성이라는 개념을 넘어야 한다는 것입니다.

너무 오랫동안 우리는 “나는 디자이너다. 내 일은 무엇인가? 디자이너로서 어떻게 성장할 것인가?” 또는 제품매니저, 엔지니어, 리서처로서 자기 역할을 명확히 하는 데 집착했습니다.

그는 이제 그것에서 벗어나야 한다고 말합니다. 역할 명확성은 오래된 뉴스입니다. 솔직히 말하면 산업화 시대의 사고에 가깝습니다.

대신 team clarity, 즉 팀 명확성으로 이동해야 합니다. 제가 보기에는 대부분의 회사가 이것을 매우 못합니다. 사람들을 한 방에 모아 놓고 명확한 목표와 달성해야 할 것이 무엇인지에 대한 감각을 주는 일을 잘하지 못합니다.

역할 명확성에 최적화하면 모두가 자기 자신만 생각합니다. 자기 역할 안에서 뛰어나 보이거나 초과 달성하기 위해 무엇을 해야 하는지만 생각합니다.

팀 명확성으로 전환하면, 이제 한 무리의 사람들이 함께 무엇을 성취할 수 있을지 이해하도록 돕게 됩니다.

제가 잠시 멈춘 이유는, 이 방에 있는 거의 모두가 농구라는 스포츠를 이해할 것 같다는 생각이 들었기 때문입니다. 미국에서도 항상 그런 것은 아닙니다.

요즘 포지션리스 농구를 생각해 보십시오. 더 이상 1번부터 5번까지 역할이 고정되어 있고, 포인트가드는 X만 하고, 슈팅가드는 Y만 하는 방식이 아닙니다. 키가 7피트 5인 웸비 같은 선수가 센터이면서 3점슛을 쏘고 가드 기술도 갖고 있습니다.

우리는 그런 세계로 이동하고 있습니다. 상속받은 고정 역할보다 스킬이 중요한 세계입니다.

팀을 제대로 구성하려면, 조직 안에서 무언가를 하기 위해 팀이 어떤 스킬을 가져야 하는지 생각해야 합니다.

여기 보이는 것은 주로 디자인 스킬과 전문 스킬의 목록입니다. 제품 조직이라면 여기에 기술 스킬도 필요하고, 비즈니스 스킬도 필요하고, 마케팅 스킬도 필요할 수 있습니다.

하지만 이것은 역할이 아닙니다. 스킬과 역할이라는 개념을 분리해야 합니다. 필요한 스킬을 맞춰야 합니다.

그리고 사람들에게 목적을 주어야 합니다. 여기 있는 문장들을 다 읽지는 않겠습니다. 그러면 밤새 있어야 합니다. 이것들은 제가 디자인팀들이 자기들이 무엇을 성취하려는지 감각을 갖도록 도와주며 함께 만든 목적 선언문들입니다.

목적 선언문과 스킬이 있으면, 역할은 그렇게 많이 필요하지 않습니다. 필요한 것은 그 목적을 달성하는 데 필요한 스킬 조합을 가진 네 명에서 일곱 명 정도의 사람을 한 방에 모으는 것입니다.

우리가 이동하는 방향은 이것입니다. 쉽지는 않을 것입니다. 규모 있는 조직은 모두 관료제 안에서 작동합니다. 그리고 관료제는 역할을 사랑합니다. 아주 많이 사랑합니다. 관료제는 역할 위에 만들어져 있습니다.

오늘 이것을 모두 풀 시간은 없습니다. 하지만 제가 말하는 것이 쉽지 않다는 것은 압니다. 다만 우리가 모두 도입하고 있는 AI 도구 때문에 무언가가 깨질 것 같거나, 깨져야 할 것처럼 느껴집니다.

---

품질: 디자인은 ‘좋다’를 어떻게 정의할 것인가

피터 머홀즈:
이제 전환하겠습니다.

첫 번째가 팀이었다면, 이제는 이전 발표에서도 살짝 다뤘지만 깊이 들어가지는 않았던 품질에 대해 이야기하겠습니다.

서로 다른 기능은 “좋다”를 어떻게 정의할까요?

엔지니어링은 매우 명확한 정의를 갖고 있습니다. 업타임 비율, 속도, 버그 수, 코드 유지보수성 같은 것입니다.

제품팀도 어느 정도 명확한 정의를 갖고 있습니다. 요구사항 충족, 정시 납기, 전환율, KPI, OKR 같은 것입니다.

디자인의 “좋다”는 무엇일까요?

“보면 압니다.”

대부분의 디자인팀은 품질에 대한 명확한 기준이 없습니다. 있다고 해도 제품팀의 기준을 빌려와 이름만 바꾼 경우가 많습니다.

그 방식으로는 어떤 논쟁도 이길 수 없습니다.

디자이너가 어떤 것이 아직 출시할 준비가 되지 않았다고 생각하지만 왜 그런지 명확하게 설명하지 못하는 상황은 앞으로 더 가속될 문제입니다. AI 이전에도 있었던 문제지만 앞으로 더 커질 것입니다.

엔지니어링은 “우리 기준의 품질은 충족합니다”라고 말하고, 제품팀도 “우리 기준의 품질은 충족합니다”라고 말하면, 디자이너가 명확한 품질 정의를 만들지 않는 한 그것은 출시될 것입니다.

이제 품질 기준 프레임워크를 빠르게 훑겠습니다. 여기에는 내용이 많고, 더 많은 슬라이드도 있지만 밤 10시까지 있고 싶지는 않습니다.

프레임워크는 기초, 경험, 결과, 정체성으로 구성됩니다. 이 순서에는 논리가 있습니다. 끝에서 설명하겠습니다.

먼저 기초입니다. 기초는 우리가 어느 정도 보편적으로 받아들일 수 있는 엔지니어링적 품질 기준에 가장 가까운 것입니다.

예를 들어 휴리스틱입니다. 제이콥 닐슨의 사용성 휴리스틱은 30년 동안 존재해 왔습니다. 여전히 좋습니다. 작동합니다. 여러분이 자기 도구에 휴리스틱 평가를 하지 않고 있다면, 잘못하고 있는 것입니다. 그냥 시작해야 합니다.

PURE라는 프로세스도 있습니다. 휴리스틱 평가를 점수표로 만드는 방식입니다. NN/g 웹사이트에서 더 찾아볼 수 있습니다. 휴리스틱 평가를 숫자로 바꿀 수 있어 커뮤니케이션하기 쉽고, 벤치마크로 쓰기도 쉽습니다.

접근성도 있습니다. 이것도 평가하기 꽤 쉽습니다. 여러분의 것이 얼마나 접근 가능한지 알려 주는 도구가 많이 있습니다.

이것이 기초입니다. 하지만 아주 최소한의 기초입니다. 디자인에는 그보다 훨씬 더 많은 것이 있습니다.

그다음은 경험의 품질입니다. 여기에는 몇 가지 측면이 있습니다.

먼저 자기보고와 태도입니다. 사용자가 어떤 일을 한 뒤 설문을 주고 그 경험이 어땠는지 묻는 방식입니다.

SUS, System Usability Scale을 아시는 분 있습니까? 몇 분 손을 드셨네요. 이것은 40년 동안 존재해 왔습니다. 저는 10~20년 전쯤 이것을 별로라고 생각해 버렸습니다. 그런데 최근 5년 동안 제 이전 커리어 전체보다 더 많은 팀이 SUS를 쓰는 것을 봤습니다. 경험의 품질을 다른 사람에게 전달하는 방식으로 사용하고 있습니다.

오래됐기 때문에 일종의 작은 NPS처럼 도구와 표준이 많이 있습니다. 다른 경험과 벤치마킹하며 자신이 얼마나 잘하고 있는지 알 수 있습니다. 저는 이것이 NPS보다 낫다고 봅니다. 실제 가치를 끌어낸다고 생각하기 때문입니다. NPS에 대해서라면 하루 종일, 일요일에는 두 번이라도 비판할 수 있습니다.

SUS는 10문항 설문이라 조금 무거울 수 있습니다. UX-Lite는 4문항 설문으로 더 가벼운 대안입니다. 요지는 경험이 어땠는지 사람들에게 물어보라는 것입니다.

물론 이것들 중 하나만으로 충분하지는 않습니다. 하지만 합치면 경험에 대한 꽤 전체적인 이해를 만들 수 있습니다.

그다음은 행동 기반 사용성입니다. 사용자가 여러분이 원하는 일을 실제로 할 수 있는지 보는 것입니다. 오류율, 정확도, 작업 시간, 과업 완료율 같은 것이 있습니다. 모두 점수화할 수 있고, 경험이 사람들에게 어떻게 작동하는지 이해하는 데 도움을 줍니다.

그다음은 경험 원칙입니다. 여기서부터는 디자이너로서 조금 더 주관적인 영역으로 들어갑니다.

여러분 중 많은 분이 경험 원칙을 사용하고 있을 것입니다. 이것은 최근 클라이언트 사례입니다. 최종적으로 원하는 결과는 마찰을 제거하는 것이었습니다. 원칙, 이 사례에서는 기준이라고 부른 것은 초록색 상자에 있는 내용입니다.

한 발 앞서가기, 직접성과 명확성으로 부담을 최소화하기, 생태계에 집착하기, 채널과 맥락 전반의 연속성 유지하기 같은 것입니다.

여러분도 전달하는 경험에 대해 비슷한 원칙들을 갖고 있을 것입니다. 하지만 각 원칙마다 그 원칙이 달성되고 있는지 알려 줄 측정 지표를 식별했습니다. 초기 단계라 다섯 개를 모두 쓰지는 않을 수 있습니다. 어떤 방식으로 원칙을 달성했는지 알 수 있을지 브레인스토밍한 것입니다.

이 정도의 엄격함이 필요합니다.

결과에 대해 이야기하겠습니다. 우리가 가진 도전 중 하나는 팀들이 비즈니스 결과를 내라는 요구를 받는다는 점입니다.

“제품 결과로 팀에 권한을 부여하라. 비즈니스 결과가 아니라”라는 훌륭한 글이 있습니다. 만약 여러분이나 여러분의 제품팀이 매출, 수익성, 비용 절감 같은 비즈니스 결과를 직접 내라는 요구를 받고 있다면, 잘못된 것을 요구받고 있는 것입니다.

이것들은 비즈니스 결과입니다. 후행 지표입니다. 팀이 이것을 직접 다루려면 보통 다크패턴이나 이상한 인터페이스 조작으로 사람들이 클릭하게 만드는 식으로 가게 됩니다.

대신 제품 결과에 집중해야 합니다. 인간 행동을 측정하되 제품에 특화된 방식으로 측정해야 합니다. 제품 OKR, 채택, 유지, 만족도, 참여, 효율성 같은 것입니다. 이런 제품 결과가 달성되면 결국 비즈니스 결과로 이어질 가능성이 있습니다.

이 글은 제가 리더십 코칭을 하면서 가장 많이 인용하는 글입니다. Product Talk에 있는 글입니다. 테레사 토레스의 Continuous Discovery로 유명한 곳입니다. 그가 쓴 글은 아니지만 그 웹사이트에 있습니다.

마지막으로 잊지 말아야 할 것은 정체성과 브랜드입니다. 우리는 마케팅디자이너를 포함한 디자이너들입니다. 정체성과 브랜드는 중요합니다. 제품 및 사용자 경험팀에서 품질의 한 측면으로 종종 간과됩니다.

경쟁이 치열한 제품 카테고리를 생각해 보십시오. 기초, 경험, 결과는 그 카테고리 안에서 매우 비슷해질 가능성이 높습니다.

예를 들어 AI를 생각해 보십시오. ChatGPT, Claude, Gemini 등 기본적인 채팅 인터페이스는 점점 비슷해질 것입니다. 이들은 기초, 경험, 결과 측면에서 거의 같은 것을 원합니다.

그렇다면 정체성이 이 도구들 사이의 중요한 차이가 되기 시작합니다. 디자이너로서 품질의 한 척도는 우리가 어떤 정체성을 명확하게 전달하고 있는지입니다. 사람들이 그것과 어떤 관계를 맺게 되는지입니다.

AI 도구이든, Duolingo, Babbel, Rosetta Stone 같은 언어 학습 도구이든, Mailchimp, Kit, HubSpot 같은 SaaS 도구이든 마찬가지입니다.

브랜드와 제품디자인에 대해서는 많이 쓰이지 않았습니다. 예전에 IDEO에 있었고 지금은 독립적으로 활동하는 알라나 거니가 몇 년 전 좋은 글을 쓴 것이 있습니다.

이 순서와 구조는 제가 5~6년 동안 품질 관련 내용을 가르쳐 오면서 정리해 온 것입니다. 하지만 이 형식은 올해 초 홍 쉬와 대화한 뒤 개발했습니다. 그는 Adyen의 제품경험 책임자이고 시카고에 있습니다. 그가 이와 매우 비슷한 프레임워크를 공유해 주었습니다.

그 철학은 이것이었습니다. 디자이너가 통제할 수 있는 것은 무엇이고, 무엇은 통제를 공유해야 하는가?

이 순서가 바로 그것입니다. 기초는 디자이너가 거의 통제할 수 있습니다. 그냥 하면 됩니다. 월요일이나 내일부터 할 수 있습니다. 별도 계측도 필요 없고, 허락도 필요 없습니다.

경험으로 가면 SUS나 사용성 테스트를 해야 합니다. 이제 계측이 필요합니다. 설문을 추가해야 하고, 클릭 데이터 같은 것도 필요합니다.

결과로 가면 이제 통제 밖으로 나갑니다. 제품팀이나 다른 팀과 공유해야 하는 영역입니다.

마지막으로 정체성은 가장 통제 밖에 있습니다. 브랜드와 정체성에 접근하면, 한 번도 들어 본 적 없는 임원들이 갑자기 여러분의 일에 큰 관심을 보이기 시작합니다. 그것이 그들이 속한 비즈니스를 반영하기 때문입니다.

이것은 일종의 롤아웃 계획입니다.

홍과 이야기할 때 나온 말이 있습니다. “제가 그냥 사용자 경험이 형편없다고 말한다고 해서 제품 파트너나 엔지니어링 파트너가 만족할 것이라고 생각하지 않습니다. 우리가 이것을 고치지 않으면 당신이 이 제품에 대해 앞서 정의한 성공 지표를 달성하지 못할 것이라고 말해야 합니다.”

저는 올해 초부터 품질에 대해 많이 이야기하기 시작했습니다. 이유는 AI slop, 즉 AI로 만든 저품질 덩어리의 위협 때문입니다.

AI로 만들기가 너무 쉬워졌습니다. 그러면 AI로 쓰레기를 잔뜩 만들 위험이 있습니다. 품질 기준이 없으면 쓰레기의 홍수를 막을 장치가 없습니다.

그래서 조직 전체에서 명확한 품질 기준이 필요합니다. 쓰레기가 그 품질 기준을 충족하지 못하면 출시되지 않도록 해야 합니다.

엔지니어링이나 제품, 마케팅은 “우리 기준에서는 괜찮습니다”라고 할 수 있습니다. 하지만 더 높은 기준을 유지하려 한다면, 그 기준을 어디에 둘 것인지 명시적이고 의도적으로 정의하는 것은 우리의 몫입니다.

---

좋은 일을 위한 조건

피터 머홀즈:
여기서 너무 지루하게 하지는 않겠습니다. 디자인 품질 관리 캐스케이드라는 멋진 슬라이드가 있지만 넘어가겠습니다. 정말 훌륭한 내용입니다. 여러분은 제가 이것을 설명해 주길 바라실 수도 있지만, 넘어가겠습니다.

이것도 넘어가겠습니다. 아직 더 있습니다. 대화 시간도 있어야 합니다.

다음은 아주 빠르게 짚겠습니다. 이것은 AI 이전부터 제가 주장해 온 내용입니다. 하지만 조건을 이야기할 때 좋은 일을 하는 환경을 생각하면 흥미롭습니다.

좋은 일을 가능하게 하려면 조건이 그 일을 가능하게 해야 합니다. 제가 본 바로는 디자인에서 특히 중요한 세 가지가 있습니다.

가장 중요한 것은 심리적 안전감입니다. 사실상 타협할 수 없습니다. 디자이너와 제품팀이 좋은 일을 하려면, 아이디어, 질문, 우려, 실수에 대해 말했을 때 처벌받거나 창피를 당하지 않을 것이라는 믿음이 있는 공간을 만들어야 합니다. 팀이 대인관계적 위험을 감수해도 안전하다고 느껴야 합니다.

디자이너는 무언가를 시도하고, 벽에 던져 보고, 실험하고, 프로토타입을 만들어야 합니다. 우리가 스케치하는 것의 90%가 나쁘다는 것을 알아야 합니다. 그래도 괜찮습니다. 그 아이디어들을 밖으로 꺼내야 나머지 10%의 금을 얻을 수 있습니다.

그런데 그 90%의 나쁜 아이디어에 대해 사람들이 “그건 나쁜 일이야. 일을 잘못하고 있어. 틀렸어”라고 말하기 시작하면, 우리는 그것을 붙잡아 두게 됩니다. 안전한 것만 하게 됩니다. 혁신하지 않고, 경계를 밀지 않습니다. 심리적 안전감이 필요한 이유입니다.

두 번째는 자율성입니다. 사람들은 자기 일에 대한 통제권을 원합니다. 지금 아주 흥미로운 도전입니다. 사람들은 소유감을 유지하고 싶어 합니다. 무엇을 하라고 지시받기보다, “이것을 달성하라. 어떻게 할지는 당신이 찾아라”라는 방식을 원합니다.

하지만 임원들이 업무의 20%는 도구를 써야 한다는 식으로 지시하면, 그것이 자신에게 관련이 있든 없든 자율성을 빼앗게 됩니다. 그것은 동기를 떨어뜨립니다.

세 번째는 숙련입니다. 숙련, 장인정신, 실천이 지금 매우 흥미로운 도전이 될 것입니다. 그것은 무엇을 뜻할까요?

미하이 칙센트미하이는 『Flow』라는 책을 썼습니다. 그는 사람들이 자기 숙련 수준과 같거나 약간 높은 수준에서 일하려고 한다는 것을 발견했습니다.

너무 낮은 수준에서 일하면 어떨까요? 시니어, 스태프, 프린시펄 디자이너가 온보딩 플로우만 하고 있다면, 그는 disengage, 즉 몰입을 잃을 것입니다. “온보딩 플로우는 15년 동안 했습니다. 이제 언제 다른 일을 합니까?”라고 느낄 것입니다.

반대로 주니어 디자이너가 시니어 제품매니저와 시니어 엔지니어가 있는 제품디자인·엔지니어링 팀 한가운데 던져지면 압도됩니다. 결국 시키는 일만 하게 되고, 그것 역시 몰입을 떨어뜨립니다.

AI 이전에도 대부분의 애자일 실천은 숙련이라는 개념을 약화시켰습니다. 개인을 팀 안에 넣고, 그 사람이 시니어라면 잡무도 해야 했습니다. 그것은 좌절을 만듭니다. 주니어라면 압도됩니다.

고립된 디자이너가 제품 사람들과 엔지니어들 사이에서 혼자 일하는 상황은 없어야 합니다. 나중에 대화할 수 있습니다.

---

비즈니스 가치와 신뢰

피터 머홀즈:
시간상 비즈니스 가치에 대한 내용은 많이 건너뛰었지만, 이 이야기는 공유하고 싶습니다.

에이미 로키가 우리 팟캐스트에 나왔습니다. 저는 그가 한 말을 듣고 “오, 흥미롭다”고 생각했습니다.

그녀의 팀이 ServiceNow에서 AI 이니셔티브를 이끌 수 있었던 이유에 관한 이야기입니다.

그녀는 ServiceNow의 CXO입니다. 그곳에 6~7년 정도 있었습니다. 실제 C-suite급 인물입니다. 최고디자인책임자가 실제 C-suite에 있는 경우는 드뭅니다.

우리는 팟캐스트에서 그녀를 인터뷰했고, 제가 어떤 질문을 했는지는 정확히 기억나지 않지만, 그녀가 이런 식으로 답했습니다. 그녀가 말하는 동안 저는 지금 보여드릴 것을 시각화하기 시작했습니다.

“우리는 사용자 인사이트를 추적할 수 있습니다. 그것을 우리가 그 문제를 해결하고 있다는 디자인 산출물에 연결할 수 있습니다. 그것을 PRD에 붙일 수 있고, 그다음 epic과 story에도 연결할 수 있습니다. 이렇게 연결 조직을 보여 줄 수 있습니다. 즉, 이 사용자 인사이트를 해결하는 것을 출시했을 때 해당 문제와 관련된 고객 이슈가 실제로 감소했다는 것을 보여 줄 수 있습니다.”

그녀는 전체 이야기를 연결할 수 있었습니다. 그리고 그것을 다시 설명할 수 있었습니다.

이것은 그녀에게 ServiceNow 안에서 엄청난 신뢰를 주었습니다. 그녀의 팀이 하는 일이 비즈니스 가치를 전달한다는 것을 보여 줄 수 있었기 때문입니다.

그 결과 그녀는 SUS를 사용한 사람 중 한 명이었습니다. 제가 묻지 않았는데도 그녀는 SUS가 자신들이 전달하는 경험의 품질을 보여 주는 데 어떻게 도움이 되었는지 이야기했습니다.

그녀는 SUS와 critical user journeys를 사용해 UIX 품질 측정 시스템을 만들었습니다. 이것은 Google에서 온 프로세스입니다. 저는 그전에는 들어본 적이 없었습니다. 검색하면 더 알아볼 수 있습니다.

그들은 제품 전반에 걸쳐 이를 체계적으로 운영했고, SUS 점수를 50점대에서 90점대로 올렸습니다. 그 결과 분기별 임원 제품 리뷰에 자리를 얻게 됐습니다.

그리고 그다음에는 그것을 AI에도 적용하기 시작했습니다. 결국 ServiceNow에서 AI 관련 많은 작업이 디자인에 의해 주도되었습니다. 그녀가 자신의 팀이 비즈니스를 지원한다는 것을 보여 주었고, 그 신뢰를 얻었기 때문입니다.

조직에는 세 가지 종류의 권력이 있습니다.

첫 번째는 지위 권력입니다. 당신이 상사이고, 모두에게 무엇을 하라고 말할 수 있습니다.

두 번째는 전문성 권력입니다. 어떤 것을 아는 사람이고, 사람들이 그것이 중요하다고 생각하기 때문에 당신의 말을 듣습니다.

세 번째는 관계 권력입니다. 사람들을 데려오고, 동료들과 연결을 만들며, 당신의 방향으로 함께 오게 하는 힘입니다.

우리는 조직의 권력을 생각할 때 지위 권력을 과대평가하는 경향이 있습니다. 상사가 말하면 그것이 중요하다고 생각합니다.

하지만 실제로 가장 중요한 것은 보통 관계 권력입니다. 제가 리더십 워크숍을 가르칠 때, 조직 안 사람들과 관계를 어떻게 만들고, 그들을 자신의 의제로 어떻게 데려올지에 많은 시간을 씁니다.

전문성 권력은 UX가 흔히 머무는 곳입니다. “우리가 사용자 리서치를 했고, 사용자가 원하는 것을 압니다. 그러니 알려드리겠습니다”라는 식입니다. 그런데 아무도 신경 쓰지 않으면 우리는 놀랍니다. “하지만 우리는 알고 있는데요”라고 말하지만, 상대는 “그래도 관심 없습니다”라고 합니다.

UXer들은 사용자 인사이트 같은 전형적 전문성의 중요성을 과대평가합니다. 그것만으로는 판을 움직이는 경우가 많지 않습니다.

하지만 지금은 AI의 순간입니다. 이전 발표에서도 들었듯이, 지금은 전문성이 중요한 창이 열려 있습니다.

제 listening tour의 일부로 만난 한 기술 중심 회사의 임원이 있습니다. 디자인팀은 40~50명 정도입니다. 그녀는 제품팀이 이끌 수도 있었던 곳에서 디자인팀이 실제로 이끌고 있다고 말했습니다. 제품 조직에는 AI 도입에서 뒤처진 사람이 디자인 조직보다 더 많았던 것 같습니다.

그래서 디자인팀이 그들의 일을 대신했습니다. 제품팀이 전략을 이끄는 데 AI를 사용하기보다 구경꾼에 가까웠기 때문입니다. 그 결과 디자인은 현재 매우 상류로 올라가고 있고, 많은 선도적 역할을 맡게 되었습니다.

이 도구와 기술을 받아들이고 앞서 나가는 디자이너는 지금과 같은 혼란의 순간에 두드러질 수 있습니다. 슬라이드 위의 문구는 “프롬프트를 통제하는 사람이 제품을 통제한다”입니다. 제 팟캐스트 파트너 제시가 한 말입니다. 그는 AI 전환 작업을 많이 하고 있습니다.

따라서 여러분은 이 도구에 익숙해지고, 사용하고, 전문성을 보여 줄 책임이 있습니다. 그렇게 하면 이 혼란의 순간에 귀 기울여야 할 사람으로 설 수 있습니다.

---

디자인의 역할은 어디로 이동하는가

피터 머홀즈:
이제 몇 장만 더 보겠습니다. 여기부터는 조금 잡다한 내용입니다. 최근 들은 몇 가지 주제를 끝부분에 넣었습니다.

방금 말한 같은 임원과 이야기하면서, 앞서 더블 다이아몬드도 봤습니다. 그가 제게 지적한 것이 있습니다. 그의 조직에는 AI를 좋아하는 두 유형의 사람이 있습니다. 우리는 더블 다이아몬드를 사용해 이야기했습니다.

첫 번째는 전략가들입니다. 여기 앞쪽에 있는 사람들입니다. 그들은 AI를 좋아합니다. 실제 데이터를 가지고 6개월, 12개월, 18개월 뒤의 비전형 미래 경험을 프로토타입으로 만들 수 있기 때문입니다. 그것을 사용자에게 보여 주고, 어떻게 사용할지 감을 얻고, 반복할 수 있습니다. 이제 디자이너에게 부탁하지 않아도 어느 정도 실제처럼 보이고 느껴지는 것을 만들 수 있습니다.

두 번째는 두 번째 다이아몬드의 뒷부분에 있는 사람들입니다. 코딩도 하거나 코드에 더 가까이 가고 싶었던 디자이너들입니다. 늘 핸드오프가 필요했고, 엔지니어링과 어색한 부분이 있었습니다. 이제 그들은 엔지니어링과 파트너가 되어 실제 출시되는 것이 명세와 디자인에 맞는지 확인합니다.

이 두 집단은 지금 매우 즐거워하고 있습니다.

그리고 세 번째 집단이 있습니다. 이들은 자기 역할과 목적이 무엇인지 이해하려고 애쓰고 있습니다. 양쪽에서 압박을 받고 있기 때문입니다.

전통적인 워크플로와 와이어프레임 중심의 UXer는 조금 길을 잃은 느낌을 받습니다. 양쪽에서 작업이 들어오고 있기 때문입니다.

---

디자인 생산과 진짜 디자인

피터 머홀즈:
품질에 대해 조금 이야기했습니다.

제가 쓴 글 중 하나는 우리 산업의 문제에 관한 것입니다. 옛날 웹 시대, Adaptive Path를 시작하던 시절에는 품질의 벨커브가 넓게 퍼져 있었습니다. 아마 나쁜 쪽에 더 많았을 것입니다.

90년대 후반과 2000년대 초반 웹 사용자 경험을 기억할 만큼 나이가 있는 분들은 알 것입니다. 많은 경험이 형편없었습니다. 하지만 동시에 매우 흥미롭고 미친 시도를 하는 사람들도 있었습니다. Flickr나 Etsy 초기에 유용하면서도 새로운 사용자경험과 인터페이스의 가능성을 밀어붙이던 시도들이 있었습니다.

시간이 지나면서 2015년, 2016년쯤부터 지금까지 우리는 바닥을 높였습니다. 정말 나쁜 경험은 훨씬 줄었습니다. 여러분이 사용하는 모바일 뱅킹 앱은 아마 제 역할을 꽤 잘할 것입니다. 그것이 바로 바닥을 높인 것입니다.

하지만 저는 우리가 천장도 낮췄다고 봅니다. 지난 10년 정도 동안 많은 디자인은 생산으로 바뀌었습니다. 우리는 화면을 만드는 것을 디자인 작업과 혼동했습니다.

자기 직업이 걱정되는 분들, 이전 발표를 들으며 우려하신 분들께 말하자면, 자기 일이 Figma를 잘 다루고 화면을 엔지니어에게 넘기는 것이라고 생각했다면 걱정해야 할지도 모릅니다. 그것은 사실 디자인이라기보다 생산입니다. 생산을 폄하하는 것은 아니지만, AI 도구가 매우 잘하는 일이기 때문입니다.

그래서 기회는 다시 디자인을 더 넓게 바라보는 데 있습니다. 20여 년 전 우리가 이 모든 것을 함께 알아가던 때를 다시 떠올리는 것입니다.

---

디자인의 가치 제안 다시 정의하기

피터 머홀즈:
제시와 저는 AI 전환에 대해 둘이서만 이야기하는 에피소드를 했습니다. 거기서 나온 몇 가지 문장을 공유하겠습니다.

지금 디자인에게는 기회가 있습니다. 우리가 생산자가 되지 말자는 이야기입니다. 더 이상 우리의 가치가 엔지니어를 바쁘게 만들 화면을 생산하는 데 있어서는 안 됩니다. 사실 애초에 그것이 우리의 가치였어서는 안 됩니다. 이제 그것을 넘어가야 합니다.

따라서 우리의 가치 제안을 명확히 해야 합니다. 각 팀은 자신이 전달하는 가치에 대한 아주 명확한 이해를 가져야 합니다. 앞서 클레이 파커 존스의 팀 명확성 개념을 말했습니다. 팀은 자신들이 어떤 가치를 전달하는지 명확히 이해하고, 그것을 커뮤니케이션해야 합니다.

그리고 그것을 명확히 할 뿐 아니라 확장해야 합니다. 지금의 혼란 속에서 디자인의 가치를 다시 프레이밍할 기회가 있습니다.

이 도구가 우리가 이미 전달하던 가치를 지원합니까? 아니면 이전에는 전달할 수 없었던 가치를 전달하게 해 줍니까?

여러분이 원래 전달해야 한다고 알고 있었지만, 어떤 이유로 하지 못했던 가치는 무엇입니까? 이 도구들이 그것을 어떻게 가능하게 할 수 있을까요?

여기까지입니다. 감사합니다.

[박수]

---

피터 머홀즈 Q&A

사회자:
놀랍습니다. 피터, 정말 감사합니다. 10분 정도 질문을 받겠습니다. 8시 30분을 너무 넘기고 싶지는 않습니다. 여러분이 서로 이야기할 시간도 있어야 하니까요. 이게 강의처럼 되어 버린 것이 좀 이상하긴 하지만, 정말 훌륭했습니다.

질문 받을 시간이 있습니다. 손 들어 주세요. 부끄러워하지 마세요.

질문자 1:
조금 다른 질문일 수 있습니다. 피터가 하고 있는 팟캐스트가 궁금합니다. 어떤 내용인지 조금 설명해 주실 수 있습니까?

피터 머홀즈:
물론입니다.

팟캐스트 이름은 Finding Our Way입니다. 저는 제시 제임스 개릿과 공동 진행합니다. 제시와 저는 Adaptive Path의 일곱 창립자 중 두 명입니다. 25년 넘게 함께 일해 왔습니다.

팟캐스트는 팬데믹 직전에 시작했습니다. 6~7년 전입니다. 디자인과 디자인 리더십에 관한 팟캐스트입니다.

처음에는 저와 제시가 오랜만에 서로 이야기하고 근황을 나누는 방식이었습니다. 한동안 함께 일하지 않았기 때문입니다. 이후에는 주로 디자인 리더를 인터뷰하기 시작했습니다. 물론 폴 포드나 데이브 그레이처럼 다른 게스트도 있었습니다. 최근에는 테레사 토레스도 나왔는데 훌륭한 게스트였습니다.

결국 이 팟캐스트는 디자인, 디자인 리더십, 그 안의 도전에 관한 대화가 되었습니다. 지난 1년 동안은 예상하시겠지만 AI에 대해 많이 다뤘습니다. 지금 벌어지는 일을 어떻게 항해할 것인지에 관한 내용입니다.

질문해 주셔서 감사합니다.

질문자 2:
리더십 관련 질문을 드리고 싶습니다. 상사가 바로 저기 계시긴 하지만요.

[웃음]

AI를 조직에 들여오는 것은 아래에서 위로, 위에서 아래로 모두의 공유 책임이라는 이야기를 조금 하셨습니다. 그 부분을 조금 더 말씀해 주실 수 있을까요?

리더들의 책임, 특히 사람을 이끄는 리더들의 책임에 대해 묻고 싶습니다. 저희 같은 스태프도 리더십의 일부이지만, 여기서는 people leader 관점에서 묻고 싶습니다. 이런 변화를 어떻게 가져와야 할까요? 조직은 그런 리더들이 개인 기여자에게 변화를 가져가도록 어떻게 확인하고 도울 수 있을까요?

피터 머홀즈:
조건에 집중해야 합니다. 제가 좋은 일을 위한 조건으로 말한 세 가지, 즉 심리적 안전감, 자율성, 숙련이 있습니다. 특히 심리적 안전감이 가장 중요합니다. 이것들이 존재하고 존중받고 있는지 확인해야 합니다.

특히 자율성이 중요합니다. 양날의 검이기도 합니다. 사람들에게 자기 앞의 문제를 어떻게 해결할지 알아낼 자율성을 주고 싶습니다. 무엇을 하라고 지시하는 대신 말입니다.

하지만 동시에 지금은 도구가 너무 많습니다. 자율성에 너무 많이 의존하면 사람들이 압도될 수 있습니다.

그래서 제가 썼고 믿고 있는 것 중 하나는 디자인 운영에 대한 투자입니다. 보통 과소투자되는 영역입니다.

제가 인용한 사람 중 정말 깊이 들어가 있는 사람은 Cloudflare의 Z였습니다. 그는 임원이나 다른 리더가 아니라 디자인 운영 담당자였습니다.

AI와 디자인에 관해 우리가 만들려는 전환은 주로 운영상의 도전입니다. 28개, 35개, 52개의 도구가 있을 때 그것을 이해하려고 한다고 해 봅시다. 모두에게 알아서 하라고 하는 대신, 운영 담당자가 “이 팀은 이 두세 개 도구를 시도하고, 저 팀은 저 두세 개 도구를 시도합시다”라고 조정할 수 있습니다.

도구를 분산시키되 조정된 방식으로 분산합니다. 각 팀이 배운 것을 다시 중앙으로 가져오고, 다시 퍼뜨립니다. 어떤 팀이 “이 도구 조합이 우리에게 아주 잘 맞습니다”라고 발견하면, 그것을 조직 전체로 확산할 수 있습니다.

이것은 운영적 노력입니다. 운영은 일하는 방식에 관한 것이고, 이 도구들은 대부분 일하는 방식에 관한 것이기 때문입니다.

회사가 구조조정을 하면서 디자인 운영 인력을 줄인 것은 안타깝습니다. 운영 담당자는 직접 출시하지 않으니 필요 없다고 생각합니다. 하지만 지금 우리는 그 어느 때보다 그들이 필요합니다. 이런 노력을 조정하고, 사람들을 함께 데려오기 위해서입니다. 교육, 계획, 커뮤니케이션, 이런 모든 것이 필요합니다.

따라서 저는 운영에 투자하라고 말하겠습니다.

또 리더들이 할 수 있는 것은, 가능한 한 번아웃을 막는 것입니다. 제가 이야기한 리더들은 모두 번아웃 상태입니다. 앞에서 두 분이 말한 것도 맞습니다. 리더도 도구가 무엇을 할 수 있는지 알 정도로는 익숙해져야 합니다.

그런데 제가 인터뷰한 한 사람은 이렇게 말했습니다. “저는 Figma에서도 거의 디자인해 본 적이 없습니다. AI 도구는 더더욱 그렇습니다.” 그는 Sketch가 쓰이던 시절 디자인 임원이 되었고, Figma가 나왔을 때는 “들어가서 코멘트는 하지만 오토 레이아웃은 전혀 이해하지 못했습니다”라고 했습니다.

그런 리더들도 이제 “Lovable, Cursor, Magic Path, Pencil, 이런 것을 다 배워야 하나요?”라고 묻습니다. 아마도 어느 정도는 배워야 할 것입니다.

리더로서 그 도구들을 모두 완전히 능숙하게 다뤄야 하느냐? 아마 아닐 것입니다. 하지만 그것들에 대해 신뢰할 수 있는 대화를 할 수 있을 만큼은 알아야 합니다.

팀이 어떤 도구 세트를 사용할지, 그 도구들을 어떻게 연결해 가치를 만들지 알아낼 수 있는 공간을 만들어야 하느냐? 그렇습니다.

디자인이 어떻게 작동하는지 이해해야 하느냐? 당연합니다. 프로세스에서 손을 씻을 수는 없습니다. 좋은 디자인으로 이어지는 입력과 출력이 무엇인지에 대해 관점이 있어야 합니다.

제가 건너뛴 디자인 품질 관리 캐스케이드도 있습니다. 검색해 보시면 제가 쓴 글을 볼 수 있습니다.

리더, 특히 임원이 해야 할 또 하나의 일은 품질을 정의하는 것입니다. 이것은 임원의 책임입니다. 반드시 임원이 직접 Confluence나 Notion 문서에 품질 정의를 써야 한다는 뜻은 아닙니다. 하지만 그것이 이루어지도록 해야 합니다. 모두가 품질에 대해 공유된 이해를 갖도록 만드는 것은 임원의 책임입니다.

질문자 3:
피터, 감사합니다. 디자이너 관점에서 보면 AI가 생산 부분을 해결한다고 말씀하셨습니다. 이제 우리는 더 나은 가치를 전달하는 데 집중할 수 있다고 하셨습니다. 그 더 나은 가치는 무엇입니까? 비즈니스 감각입니까? 사용자를 더 잘 아는 것입니까? 무엇입니까?

피터 머홀즈:
짧게 답하면, 그렇습니다. 둘 다입니다.

제게는 더 많은 부분이 첫 번째 다이아몬드 쪽에 있다고 생각합니다. 무엇을 만들어야 하는가? 왜 만들어야 하는가? 우리가 생각조차 하지 못한 것은 무엇인가?

우리는 탐색적이지 않게 됐습니다. 아까 큰 벨커브를 보여 드렸습니다. 벨커브가 넓을 수 있었던 이유는 탐색이 많았기 때문입니다. 좋은 쪽에서는 많은 탐색이 있었죠.

우리는 그 탐색적 사고방식을 잃었습니다. 비슷한 문제에 대해 이미 아는 해법을 적용하는 쪽으로 갔습니다.

구체적인 이름은 말하지 않겠습니다. 미국의 한 온라인 뉴스 서비스 회사가 있었습니다. 새로운 최고디자인책임자가 들어왔고, 그에게 2~3년 뒤 미래 모바일 경험의 비전을 만들라는 과제가 주어졌습니다.

그는 자신이 직접 그것을 전달할 사람이 아니라는 것을 알고 있었습니다. 그는 조직을 이끄는 사람이었습니다. 그런데 조직을 둘러보니, 팀 안에 그런 종류의 디자인 작업, 즉 더 먼 미래의 비전 작업을 할 줄 아는 사람이 없다는 것을 깨달았습니다.

그것은 현재 제품의 다음 반복과는 다른 종류의 디자인입니다. 그래서 그는 그런 작업을 해 본 외부 컨설턴트를 데려와야 했습니다. 비전 작업을 어떻게 해야 하는지 이해하는 사람이었습니다.

그 작업이 이루어졌고, 이제 그 미래 모바일 작업은 그 회사가 실행하는 주요 로드맵이 되었습니다.

이 사례를 공유한 이유는, 생산을 하지 않을 때 더 넓고 확장적으로 생각할 수 있다는 점을 보여 주기 위해서입니다. 여러분의 조직이 해결할 수 있는 문제는 무엇인가?

비즈니스 감각도 말씀하셨습니다. 맞습니다. 왜 이런 흥미로운 새 아이디어가 여러분의 비즈니스에 적합한지 설명할 수 있어야 합니다.

아까 에이미 로키 사례를 보여 드린 이유도 그 때문입니다. 인사이트를 임팩트와 연결할 수 있어야 합니다. 디자이너들은 보통 이 전체 이야기를 연결하는 데 능숙하지 않습니다. 그런 것들이 필요합니다.

질문자 4:
이 질문을 최대한 간결하게 줄여 보려고 했습니다. 잘됐는지 모르겠습니다.

당신은 디자인을 측정 가능한 지표로 압축할 수 있다고 제안하는 것 같습니다. 팀이 측정되고 평가받을 수 있게 한다는 것입니다. 회사의 건강을 위해서요.

그런데 그렇게 하는 순간 저 같은 엔지니어가 와서 이렇게 말할 수도 있습니다. “좋습니다. 이것을 AI에 연결합시다. 자율적으로 돌게 합시다. 팀에 더 많은 스트레스를 추가합시다.”

그렇게 되면 또 다른 번아웃 루프를 만든 것이 아닐까요?

피터 머홀즈:
이것은 건강한 기업문화가 필요한 지점입니다.

왜냐하면 디자인을 측정하는 것에만 해당하는 문제가 아니라, 무엇이든 벤치마킹하고 측정할 때 적용되는 문제이기 때문입니다.

물론 모든 것을 숫자로 바꾸는 문제에 대해 철학적 논의를 할 수도 있습니다. 최근 나온 『The Score』라는 훌륭한 책이 있습니다. 모든 것을 측정할 때 어떤 일이 벌어지는지, 사람들이 그 지표에 맞춰 일하게 되면서 세상에서 우리를 행복하게 만드는 것을 놓치는 문제에 관한 책입니다.

그래서 지표에 문제가 있다는 것도 압니다. 하지만 비즈니스는 지표를 통해 소통한다는 것도 압니다.

디자이너가 디자인 언어로 비즈니스 청중과 소통하려 할 때 문제가 생깁니다. 상대는 “느낌이라는 게 무슨 뜻인지 모르겠습니다. 제게는 의미가 없습니다”라고 합니다.

하지만 그들은 점수, SUS, 벤치마크, 작업 시간 같은 것은 이해합니다.

그래서 제게 지표는 공유된 대화를 위한 방식입니다. 여러분의 팀이 하는 일을 다른 팀과 연결하는 능력입니다.

그것이 스트레스나 번아웃을 유발하는 방식으로 쓰일 수 있느냐? 그럴 수 있습니다. 저는 아직 그 정도까지 깊게 생각하지는 않았습니다. 솔직히 디자이너들이 보통 지표를 너무 못 다루기 때문에, 먼저 지표의 공간에 도달해야 합니다. 그다음에 그 지표를 건강하게 사용하는 방법을 이야기할 수 있습니다.

AI는 증폭입니다. 건강한 조건이 있고 그것을 증폭하면 좋습니다. 하지만 독성 있는 조건이 있고 그것을 증폭하면, 디자인 산출물을 측정하든 아니든 번아웃으로 이어질 것입니다.

답을 완전히 하지는 못했습니다. 제가 아직 그 함의를 충분히 생각하지 못했기 때문입니다.

하지만 예를 들어 토큰 사용량 리더보드 같은 것은 아주 멍청한 짓입니다. 엔지니어에게 더 많은 코드 라인을 쓰라고 말하는 것과 같습니다. 우리는 그것이 멍청하다는 것을 압니다. 그런데 다시 이런 나쁜 방식으로 성과와 생산성을 측정하려 하고 있습니다.

문제는 측정 자체가 아니라, 측정 지표의 어리석음입니다. 우리는 산출물이 아니라 결과에 집중해야 합니다. 비즈니스는 이것을 계속 다시 배워야 합니다.

사회자:
마지막 질문 하나 더 받을까요? 네, 하나 더 하겠습니다.

질문자 5:
먼저 빌뉴스에 와 주셔서 정말 좋다고 말씀드리고 싶습니다. 저는 4년 전 미국에서 이 나라로 이사 왔고, 이곳을 사랑합니다. 그래서 와 주셔서 좋습니다.

피터 머홀즈:
이민을 권장하시는 건가요?

[웃음]

질문자 5:
네, 저는 나가고 싶었습니다. 이해하실 겁니다.

저는 콘텐츠디자인 리더십 역할을 해 왔습니다. 발표 중 역할에서 팀 역학으로 이동한다는 부분, 그리고 관계 권력에 대한 부분이 매우 인상적이었습니다.

하지만 이렇게 큰 변화가 있어도 회사들은 “내 말대로 하되, 내가 하는 대로 하지는 말라”는 식일 때가 많습니다. 저는 미래 리더나 리더십으로 이동하고 싶은 사람들과 많이 이야기합니다.

역할이 흐려지고, 사람들이 이전에는 맡지 않았던 팀을 이끌 기회를 갖는 팀 중심의 비전을 어떻게 발전시킬 수 있을까요? 그들이 개선하도록 어떻게 도울 수 있을까요?

피터 머홀즈:
훌륭한 질문입니다.

제가 이것을 공유한 이유 중 하나는, 여기에 대해 좋은 글이 나오고 있기 때문입니다. 그것들이 어느 정도 영향을 미칠 수 있습니다. Airbnb가 하고 있다면, 고려해 볼 가치가 있다는 식의 모델이 될 수 있습니다.

본질적으로 우리가 이야기하는 것은 어떤 형태의 변화관리입니다. 현재의 방식이 있고, 새로운 방식으로 작동하고 싶습니다. 그리고 그 새로운 방식이 무엇인지 어느 정도 감이 있습니다.

우리는 “모든 팀에는 디자이너, 콘텐츠디자이너, 리서처, 제품매니저, 그리고 여러 엔지니어가 있어야 한다”는 방식에서 벗어나고 싶습니다. 대신 적절한 스킬 조합을 가진 사람들의 그룹을 갖고 싶습니다.

저는 디자이너이지만 늘 글을 잘 쓰는 사람이었습니다. 그래서 콘텐츠라이터, 콘텐츠디자이너, 콘텐츠전략가의 관점을 어느 정도 수행합니다. 반대로 저는 형편없는 비주얼디자이너입니다. 그것은 제가 가져오는 스킬이 아닙니다. 저는 비주얼디자인 스킬을 가진 사람이 필요합니다. 어쩌면 그 사람은 프론트엔드 개발 스킬도 갖고 있을 수 있습니다.

이것이 제가 말한 것입니다. 역할은 이미 개인이 하는 일을 설명하기에 부족했습니다. 우리는 직무기술서보다 훨씬 더 복잡한 사람들입니다.

따라서 필요한 스킬의 범위와 목적을 갖춘 팀을 모으면 어떻게 될지 생각해야 합니다.

변화관리 관점에서는 작게 시작해야 합니다. 조직 안에서 기회가 있는 부분을 찾습니다. 반드시 핵심 미션은 아니지만, 조직이 관심을 갖는 영역이면 좋습니다. 작은 혁신팀 같은 곳입니다.

그리고 제안합니다. “다른 방식으로 일해 봅시다. 이 도구들이 역할을 흐리게 만든다고 하니, 그것을 받아들여 봅시다. 사람들을 모아 팀으로 함께 일하게 하고, 이 도구들을 사용해 어떤 일이 일어나는지 봅시다.”

작게 시작하고, 표준적인 제품팀 구성원이 없어도 무너지지 않았다는 것을 보여 줍니다. 그래도 훌륭한 일을 할 수 있었다는 것을 보여 줍니다. 그다음 다시 시도하거나, 다른 그룹과 시도합니다. 작게 시작해 거기서부터 쌓아 가는 것입니다.

물론 이런 변화가 실현되기까지는 시간이 오래 걸릴 것입니다.

제가 쓴 글에서도 말했듯이, 저는 20년 동안 역할에 맞서 싸워 왔습니다. Adaptive Path에서도 모두를 경험디자이너라고 부르려고 했습니다. 리서치 스킬이 더 많든, 비주얼 스킬이 있든, IA 스킬이 있든 모두 경험디자이너라고 부르려 했습니다.

그때 우리가 그렇게 하지 못했던 이유 중 하나는 관료제가 아니었습니다. 우리는 30명 정도였기 때문에 하고 싶은 대로 할 수 있었습니다. 문제는 정체성이었습니다.

사람들은 “아니요, 저는 사회과학 박사학위를 갖고 있습니다” 또는 “저는 SCAD에서 서비스디자인 학위를 받았습니다. 저는 서비스디자이너입니다”라고 말했습니다.

정체성은 큰 문제입니다. 이 모든 것의 하위 주제 중 하나가 정체성입니다.

정체성은 디자이너, 더 넓게 말하면 UXer를 뒤로 붙잡아 온 가장 큰 요인 중 하나입니다. 다른 누군가가 UXer에게 한 일보다, UXer 스스로의 정체성이 더 많이 붙잡았습니다.

“저는 그 일을 하지 않습니다. 그건 제 일이 아닙니다. 저는 X입니다.” 이것이 정체성입니다. 전문적 소속감에 단단히 붙잡혀 있는 것입니다. 하지만 그것은 여러분이 만들고 싶은 영향과 반드시 연결되지는 않습니다.

그래서 작게 시작하십시오. 그룹을 모으십시오. 이전 알렉스 사례에서 말한 no ego, 즉 에고를 내려놓는 태도를 가지십시오. “나는 X이므로 XYZ를 하고, 당신은 A이므로 ABC를 한다”는 식의 사고를 내려놓으십시오.

다시 농구 비유를 쓰겠습니다. 다섯 명의 사람이 있고, 상대 팀보다 더 많은 점수를 넣고, 상대가 점수 내는 것을 막으려는 것입니다. 그 다섯 명이 그 목표를 달성할 수 있는 방식이 무엇이든 그것이 최선입니다. 그리고 다섯 명의 구성에 따라 방식은 달라집니다.

그런 사고방식이 조직에서 어떻게 적용될 수 있을까요? 아마 그런 식일 것입니다. 아직 많이 실험해 보지는 못했습니다. 어떻게 작동해야 하는지는 알지만, 시간이 걸릴 것입니다.

여기서 진행된 실험들에서도 그런 모습을 조금 볼 수 있다고 생각합니다. 팀들이 역할을 흐리며 함께 일하고 있습니다.

기드리우스:
우리가 만든 생성형 경험에 대해 이야기했습니다. 그 작업은 본질적으로 PM과 저, 두 사람이 함께한 일이었습니다.

그 경험에서 제가 얻은 흥미로운 점이 있습니다. 이제 다음 것을 이야기할 때, 그 PM이 처음 한 말은 “와서 이것을 함께 작업해 달라”였습니다.

제가 “디자이너가 필요한가요?”라고 물었더니 그는 “아니요. 저와 함께 이것을 만드는 사람이 필요합니다”라고 했습니다.

저는 이것이 변화라고 생각합니다. 어떤 일을 하느냐가 아니라, 함께 일하기 때문에 목표에 더 빨리 도달하는 것입니다. 이것이 가장 큰 변화입니다.

피터 머홀즈:
훌륭한 질문입니다.

사회자:
이제 마무리할까요? 사람들이 조금씩 나가고 있네요. 시간이 늦어지고 있습니다. 하지만 정말 놀라운 시간이었습니다. 피터, 감사합니다.

피터 머홀즈:
저도 감사합니다.

사회자:
와 주신 모든 분들께 감사드립니다. 기드리우스와 만타스의 훌륭한 발표에도 감사드립니다.

아직 음료와 음식이 남아 있으니 머물러 주세요. 얼마나 늦게까지 있을 수 있죠?

운영진:
9시요?

사회자:
한 시간 정도 더 하죠.

운영진:
한 시간 정도요. 한 시간 더 머무르세요. 9시 40분까지요.

[웃음]

사회자:
그럼 지켜보겠습니다.