"우리 회사엔 데이터가 없어서요." "제가 다루기엔 너무 어려워서요" "시간이 없어서요" 디자이너끼리 모이면 한 번쯤 듣게 되는 말이에요. 근데 모두 모여 이 책을 함께 읽고 나니까 보이더라고요. 디자이너들의 발목을 잡고 있던 건 데이터의 부재가 아니라 데이터를 향한 두려움이라는 점이요.
이번 듀오톤 사내 북스터디에서 함께 읽은 책은 이미진(란란) 작가의 《데이터 삽질 끝에 UX가 보였다》였습니다. 17년 동안 데이터 없는 환경에서 어떻게든 사용자 데이터를 모으고 해석해 온 분의 생생한 이야기를 읽으며 디자이너들이 함께 풀어낸 자기 반성과 실무 이야기를 공유합니다.
01. "왜 데이터가 무섭지?" — 스스로에게 먼저 질문을 던지자
책을 열자마자 좀 의외였다는 반응이 많았어요. 데이터를 잘 다루는 법이 먼저 나올 줄 알았는데, 데이터 앞에서 망설이는 자기 자신을 들여다보는 이야기가 먼저 등장하니까요. 작가는 자기한테 '왜?'를 다섯 번 반복해서 물어보면 두려움의 뿌리가 보인다고 권합니다. 5 Whys라고도 불리는 해결법이에요.
5 Whys: 도요타의 다이이치 오노가 고안한 문제 해결 기법으로, 문제의 겉보기 증상이 아닌 근본 원인을 찾을 때까지 "왜?"라는 질문을 5회 반복하는 방법론
디자이너 D "코딩으로 데이터를 정제하는 방법이 요즘 진짜 많이 나와 있잖아요. 그걸 도전하기가 너무 두려웠는데, 왜 그런가 계속 파고들어 봤거든요. 결국엔 '완벽한 데이터를 뽑아서 인사이트까지 무조건 도출해야 한다'는 막연한 부담이 있더라고요. 시작 못 했던 이유가 사실은, 제가 너무 완벽하길 기대해서였던 거예요."
디자이너 A "이 책에서 5 Whys가 정말 좋다고 생각했어요. 스스로한테 물어보면 더 이상 핑계가 안 통하거든요. '내가 해야 할 수밖에 없는 상황'이 되고, '아, 이제 그냥 한 번 해보자'가 돼요."
이 부분에서 멋쩍게 웃은 디자이너가 많았어요. 데이터를 못 다뤄서가 아니라, 시작도 하기 전에 결과를 미리 그려놓고 있었던 게 진짜 문제였다는 걸 알아챈 거죠. 책의 첫 챕터 제목이 〈데이터 기반 UX가 어려운 건 당신 탓이 아니다〉인 이유가, 모두에게 납득되는 순간이었습니다.
02. "에이전시는 데이터가 없잖아요" — 정의를 다시 그어보면
책이 인하우스 환경을 기반으로 쓰여 있다 보니, "그럼 에이전시인 우리는 어떻게 적용해야 할까" 하는 이야기가 자연스레 화두가 되었습니다. 이 답답함이 풀린 건 디자이너 B가 자기 프로젝트를 돌아보면서 꺼낸 사례에서였습니다.
디자이너 B "한 캐릭터 IP 브랜드 프로젝트를 할 때, 저희는 사용자 스터디보다 브랜드 자체를 스터디했어요. 캐릭터 성격이랑 캐릭터들이 살고 있는 세계관이 노션에 디테일하게 정리돼 있더라고요. 그것도 일종의 데이터죠. 팀 리더분은 직접 팝업 스토어에 가셔서 사람들이 어떤 포인트에서 매력을 느끼는지, 어떤 걸 사고 싶어 하는지 보고 오셨대요. 필드 리서치라고 하셨던 것 같아요. 사실 데이터 드리븐이라고 하면 아니라고 생각하기 쉬운데, 따져보면 그렇게 데이터를 수집한 부분들이 있긴 있었어요."
꼭 GA 퍼널만 데이터인 건 아니었습니다. 브랜드 세계관 정리, 팝업 현장 관찰, 경쟁사 페이지 전수 조사, 디렉터 분들과 나눈 대화 기록까지. 매일 하던 일들이 알고 보면 다 데이터 수집이었어요.
책에 나오는 인하우스 사례를 그대로 가져올 수 없는 환경이라면, 디자이너가 이미 손에 들고 있는 모든 것이 데이터가 될 수 있다는 걸 보여준 사례였어요.
03. 진행하기 전 잠깐 멈추기
스터디에서 자주 화제가 됐던 게, 디자이너가 받은 기획 정보를 어떻게 재구성하는지 보여주는 예시였어요. 받은 그대로 펼치지 말고, 한 번 더 정보를 정리하고 옮겨 적는 시간을 두라는 이야기였습니다.
디자이너 C "디렉터 분께서 정리해 주시는 기획안이 있거든요. 이 사이트에 어떤 문제가 있고, 어떤 목표가 있고, 왜 리뉴얼을 해야 하고, 이 기업의 특징은 뭐고. 근데 그걸 한 번 읽으면서 노션에 제 언어로 다시 써요. 그러면서 디자인 컨셉도 도출하고, 그 회사에 대해서 다시 한 번 공부도 되고요. 디렉터 분께서 정리해 주신 거지만, 디자이너가 또 따로 궁금해하는 정보가 있거든요. 거기서 그 질문 항목도 자연스럽게 생겨요."
디자이너 B "원래 성격은 정리해서 시작하는 스타일이었어요. 근데 입사하니까 '이거 하세요' 하고 시키니까 일단 핀터레스트부터 들어가서 레퍼런스를 찾게 되더라고요. 그 방식에 점점 익숙해지고 있었어요. 책에서는 '내가 해야 할 건 뭐고, 무엇을 위해서 이걸 하지?'를 정하고 시작하니까, 좀 더 과녁을 탁 명중하는 느낌이라고 했거든요. 저한테 필요한 게 이런 방식이었어요."
받은 기획서 그대로 작업하면 결과물에 디자이너 의도가 별로 안 담긴다는 게, 자리에서 모두가 공감한 부분이었어요.
내 언어로 한 번 옮겨 적는 그 짧은 시간이 디자이너의 의도와 생각이 들어가는 자리가 됩니다. 디자이너 C는 그렇게 정리해 둔 노션이, 다음에 비슷한 프로젝트가 들어왔을 때 진짜 큰 참고가 됐다고 덧붙였어요.
04. "근거가 있어야 받아들여진다" — 다른 디자인 시스템에서 답 가져오기
대기업이랑 일해 보면 다들 한 번쯤 느끼는 게 있어요. '말'만으로는 의사결정이 안 움직인다는 거. 책에서도 비슷한 결의 이야기를 합니다. 데이터는 그냥 분석용이 아니라, 우리가 만든 디자인을 누군가 받아들이게 만드는 도구이기도 하다고요.
디자이너 C "한 대기업 디자인 시스템 작업을 할 때였는데, 페이지마다 사업부가 다르니까 같은 컴포넌트인데도 다 다르게 쓰이고 있었어요. 페이지마다 디자인을 다른 사업부에서 관리하고 있었거든요. 드롭다운 리스트 하나만 봐도 텍스트만 있는 것, 아이콘이 앞에 오는 것, 안에 이미지가 들어간 것, 진짜 다 달랐어요. 이걸 우리가 정의해야겠다 싶은데, 우리 마음대로 정리하면 안 받아들여지잖아요. 그래서 머티리얼 디자인, 카본, 라이트닝 같은 대표적인 시스템들을 다 조사했어요. 그들은 어떻게 정의해서 어떻게 쓰고 있는지. 그러고 나서 '우리는 이렇게 정리해야 할 것 같습니다'를 가져갔거든요. 그제서야 큰 이견이 없었어요."
데이터 드리븐이라는 말이 꼭 GA 대시보드만 가리키는 건 아니죠. 다른 디자인 시스템들이 같은 컴포넌트를 어떻게 정의하는지 모은 표 하나도 충분히 근거가 됩니다.
의사결정자가 고개를 끄덕이게 만드는 건, 화려한 결론보다 그 결론까지 가는 자료의 양과 결이라는 걸 이 사례가 잘 보여줬어요. 그리고 그 자료는 평소에 다양한 레퍼런스들을 수집하고 정리해온 사람한테 쌓이고요.
05. "질문이 적을수록 좋다"의 진짜 뜻 — 설문 설계는 사실 데이터 수집의 시작
책의 설문조사 파트에서 다들 한 번 멈췄던 문장이 있어요. "질문은 적을수록 좋다." 처음엔 갸웃했는데, 이야기를 풀어 보니까 그 말의 의도가 자연스럽게 정리됐습니다.
디자이너 D "이 말의 진짜 의도는 '무조건 적게'가 아닌 것 같아요. 불필요한 질문이 너무 많은 게 안 좋다는 뜻이었을 거예요. 저도 팀 프로젝트에서 설문지를 만들 때 질문 수를 거의 절반으로 쳐냈거든요. 처음엔 궁금한 것들 위주로 다 적었다가, '이 질문들의 결과를 종합했을 때 인사이트가 안 나올 것 같다' 싶은 것들을 빼고, '이건 인터뷰로 파악하는 게 더 적합하다' 싶은 것들을 빼고요. 5분 걸린다고 해놓고 30분 걸리는 설문, 자주 보잖아요. 응답자에게 친절한 설문이 결국 이탈률도 적은 것 같아요."
질문 하나하나가 어떤 인사이트로 이어지는지 미리 그려본 다음에, 잘 안 이어지는 질문은 인터뷰로 빼거나 떨어뜨려 놓는 일. 사실 이 작업이 디자이너의 판단이 가장 많이 들어가는 부분이거든요. 많이 묻는 게 아니라, 잘 묻는 게 먼저인 거죠. 스터디에서 자주 반복된 결론은 이거였어요.
“설문은 답을 받는 도구이기 전에, 어떤 결론을 미리 그리고 있는지 점검하는 도구이기도 하다.”
응답자가 끝까지 답할 수 있는 설문이, 결과적으로 가장 좋은 데이터로 돌아온다는 점도 함께 말이에요.
06. 데이터는 원래 엉망이라는 것, 좋은 데이터는 같이 만들어 가는 것
책 후반부에서 다들 "이거 너무 현실적이다" 했던 페이지가 데이터 정제 파트였어요. 데이터는 깔끔하게 도착하지 않거든요. 누락되고, 중복되고, 매핑은 어긋나 있고요. 이 이야기는 자연스럽게 두 갈래로 흘렀어요. 하나는 데이터 자체가 원래 엉망이라는 것, 또 하나는 그 엉망인 데이터를 다듬는 사람들 사이의 소통 문제였습니다.
디자이너 C "예전에 IoT 회사에 다닐 때, 데이터를 한 번에 천 개 이상 받았어요. 근데 IoT 특성상 데이터가 완전하지 않을 때가 있어요 갑자기 누락되거나, 공백이거나, 중복이거나. 데이터 분석가분들이 그냥 다 채우거나 바꾸시더라고요. 책을 보면서 '아, 이분들 이걸 계속 수동으로 해 오셨구나' 하니까, 저도 할 수 있겠다 싶어졌어요. 데이터가 처음부터 완벽한 게 아니라 수정하고 정리해 가는 거구나, 하고요."
디자이너 A "고객사가 '알아서 하세요' 하면 우리도 태도가 소극적이 돼요. 근데 '이건 이런 배경이라 이렇게 해 주세요', '데이터 이 정도는 드릴 수 있어요' 하면서 적극적으로 나오시면, 우리도 적극적으로 데이터를 찾고 묻게 돼요. 최근에 진행한 한 대기업 프로젝트는 가운데에 되게 적극적인 협력 대행사가 껴있었거든요, 그러니까 '한번 이런 것도 활용해 봐도 되지 않을까' 하는 마음이 생기더라고요."
좋은 데이터는 누군가 디자이너에게 깔끔하게 가공해서 던져 주는 게 아니라 디자이너가 직접 정제에 손을 대고, 고객사랑 핑퐁을 주고받으면서 같이 만들어 가는 거라는 것, 데이터 환경 자체가 사람 사이의 관계 위에 만들어진다는 것이 스터디를 진행하면서 또렷해진 결론이었습니다.
스터디 막판에 한 디자이너가 이런 얘기를 덧붙였어요. "예전엔 못 한다고 핑계 댔던 일들을, 요즘은 GA 화면 캡처 하나 떠서 AI한테 던지면 어디서부터 손대야 할지 알려주거든요. 시도 자체의 비용이 진짜 많이 낮아졌어요." AI가 GA 트래킹이나 스크롤 뎁스 추적 같은 작업의 진입 장벽을 확 낮춰 주는 시대잖아요. 도구는 점점 쉬워져 가고, 남은 건 우리가 어떻게 끌어다 쓸지의 문제라는 말에 다들 고개를 끄덕였습니다.
마무리
많은 디자이너가 매일 비슷한 고민을 안고 일합니다. "내 디자인이 정말 유저 목표까지 닿고 있을까", "개발자에게 기능 수정을 요청할 근거가 부족한데 어떻게 하지", "우리 조직의 데이터 리터러시가 낮은데 어떻게 데이터로 일하자고 제안하지?" 이번 자리에서 듀오톤 디자이너들이 풀어놓은 답답함도 다 그 모양들이었어요.
같이 읽고 경험을 나누면서 한 가지가 확실해졌습니다. 데이터는 누군가 가져다주는 게 아니라, 손대는 만큼만 쌓인다는 거. 갈증을 푸는 시작이 거창한 결심이 아니라, 받은 기획서를 한 번 옮겨 적는 일, GA 화면 캡처 한 장을 AI한테 던져 보는 일 같은 작은 시도라는 것도요. 그제야 책 제목 속 '삽질'이라는 단어가 다르게 읽혔습니다. 헛된 일이 아니라, 결국 한 삽을 푸는 것에서부터 시작해야 한다는 것으로요.
독자 분들은 데이터 드리븐한 디자인을 위해 어떤 시도를 하고 계신가요? 환경을 핑계로 미뤄두고 있던 일이 있다면, 이 글을 핑계 삼아 함께 작은 시도 하나 해보시는 건 어떨까요?
긴 글 읽어주셔서 감사합니다.
👉 오픈패스(OPENPATH)에서 제공하는 교육 과정을 통해 나만의 뾰족한 관점을 만들어보세요.
이 글은 듀오톤 사내 북스터디 녹음을 바탕으로 OPENPATH 블로그 에디터가 AI의 도움을 받아 정리·작성했습니다.
책 정보: 이미진(란란) 지음, 《데이터 삽질 끝에 UX가 보였다》, 한빛미디어, 2025
