사용자의 행동 데이터, 시장 데이터, 성과 데이터 등을 기반으로 의사결정을 내리고 제품을 기획하는 방식
데이터 드리븐 기획 사례 1. 넷플릭스
넷플릭스는 데이터를 단순한 리포트용 숫자가 아니라 실제 제품 의사결정의 핵심 도구로 사용했다.
-
넷플릭스는 콘텐츠를 장르, 시대, 분위기, 플롯의 결말 방식 등 1,000개 이상의 태그로 분류하고, 이를 통해 수많은 마이크로 장르를 정의해 추천에 활용한다.
-
넷플릭스는 데이터를 활용해 콘텐츠 투자와 제작 의사결정도 수행한다.
- 단순 조회 수만 보는 것이 아니라, 완료율, 시청 시간대, 정지·되감기·빨리감기 같은 세부 행동 데이터를 통해 어떤 콘텐츠가 실제로 깊게 소비되는지를 파악한다.
- 글에서 소개된 Arrested Development 사례는 이를 잘 보여준다. 넷플릭스는 시즌 3까지 시청한 이용자 중 얼마나 많은 사용자가 시리즈를 끝까지 봤는지를 보고, 추가 시즌 제작 여부와 어떤 요소가 특히 반응을 얻었는지를 판단했다고 한다.
- 데이터가 창의성과 충돌하기만 하는 것이 아니라, 오히려 창의적 선택을 더 정교하게 만들 수 있다
- 넷플릭스는 데이터를 활용해 어떤 아이디어가 누구에게 통할 가능성이 높은지 먼저 파악하고, 그 위에서 창작자와 제작진이 실제 콘텐츠를 완성해 나가는 구조를 만들었다.
- 데이터가 예술적 판단을 완전히 대체하는 것이 아니라, 창의적 시도에 대한 불확실성을 줄여주는 역할을 했다.
➡️ 넷플릭스는 데이터를 단순한 성과 측정 수단이 아니라 가설을 세우고 리스크를 줄이는 도구로 사용
데이터 드리븐 기획 사례 2. 토스 데이터로 내린 의사결정, 뒤집어 엎기
PM은 왜 데이터를 봐야할까?
- PM은 다양한 이해관계자와 함께 일하기 때문에, 의견이 아니라 데이터를 기반으로 논리적인 대화를 만들어낼 수 있어야 한다.
- 이 사례에서도 처음에는 여러 요금제를 내는 것보다 100GB 요금제 하나만 출시하는 것이 더 단순하고 효율적일 것이라고 판단했다.
- 데이터상으로도 여러 개를 출시한다고 이용률이 크게 늘 것 같지 않았기 때문이다.
처음에는 ‘100GB 요금제 1개면 충분하다’고 생각했다
- 하지만 사용자 인터뷰를 반복하면서 이상한 신호가 보였다. 많은 사용자가 “굳이 100GB까지는 필요 없다”고 느끼고 있었던 것이다.
- 이때 중요한 것은 이 정성적인 반응을 그냥 느낌으로 두지 않고, 얼마나 큰 문제인지 정량적으로 확인하는 것이었다.
정성적인 유저 보이스를 정량적인 문제로 바꾸기
- 그래서 현재 사용 중인 요금제, 제공 데이터량, 실제 사용량, 그리고 어떤 사용자가 100GB 단일형에 반응하는지를 추가로 조사했다.
- 그 과정에서 처음 수집한 데이터가 고용량 사용자에게 다소 치우쳐 있었을 가능성도 발견했다.
- 그래서 이를 전체 통신 시장의 요금제 분포와 비교해보니, 실제로는 고용량 사용자보다 저용량 사용자가 더 많았고(4:6), 100GB 단일형은 시장의 60% 정도를 차지하는 저용량 사용자를 충분히 고려하지 못하는 구조라는 점이 드러났다.
문제는 ‘요금제 개수’가 아니라 ‘무엇을 보여주느냐’였다
- 이후 알게 된 것은 문제의 핵심이 단순히 “요금제를 몇 개 출시할 것인가”가 아니었다는 점이다.
- 사용자는 대체로 현재 자신이 쓰는 요금제와 비슷한 수준의 상품을 선택하는 경향이 있었다.
- 그래서 저용량 사용자는 저용량 요금제를, 고용량 사용자는 고용량 요금제를 더 잘 선택할 수 있도록 보여주는 방식이 필요했다.
- 여기에 현재 데이터 제공량이 부족한지, 혹은 남는지까지 파악하는 질문을 추가해 추천 정확도를 높였다.
요금제 제안 방식
- 요금을 보여줄 때, 요금 하나만 보여주는 단일형, 여러개를 보여주는 목록형, 토스에서 추천하는 추천형을 비교한 유저 테스트에서는 추천형이 가장 높은 반응을 얻었다.
- 이 사례를 통해 느낀 것은, 데이터 드리븐 의사결정이란 처음부터 정답을 맞히는 것이 아니라, 정성적인 사용자 보이스를 정량적으로 검증하고, 새로운 근거가 생기면 기존 결정을 수정해가는 과정이라는 점이다.
진행 상황은 ‘정답’이 아니라 ‘검증 과정’으로 공유해야 한다
- 또 하나 배운 점은, 의사결정을 뒤집는 것을 두려워하기보다 왜 방향을 다시 봐야 하는지 근거를 팀과 공유하는 것이 더 중요하다는 것이다.
- 처음 판단이 틀렸다고 말하는 것이 아니라, 새로운 데이터와 리서치 결과를 반영해 더 나은 방향으로 업데이트한다고 설명할 수 있어야 한다.
- PM에게 필요한 것은 확신을 고집하는 태도가 아니라, 근거를 바탕으로 판단을 수정할 수 있는 태도라고 생각했다.
데이터 드리븐 기획 사례 3. 토스: 사용자의 공감 얻으면서 제품 뜯어고치기
사례 요약
토스의 인벤토리 팀은 홈 상단의 인텔리전스 영역을 운영하는 팀이다. 이 영역은 연체 알림, 대출 제안, 혜택 안내처럼 사용자에게 필요한 정보를 맞춤형으로 보여주는 공간이며, 팀은 이를 더 “똑똑하게” 만들기 위해 어드민 제품과 관련 지표를 관리하고 있다.
처음에는 팀의 핵심 지표 중 하나인 클릭률이 계속 상승하고 있었기 때문에, 정량적으로는 제품이 잘 작동하고 있는 것처럼 보였다. 그러나 동시에 사내 문제 제보 채널에서는 인텔리전스와 관련된 부정적 피드백이 점점 많아지고 있었다. 예를 들어, 문구가 허위 광고처럼 느껴진다거나, 반복적으로 노출되어 불쾌하다는 식의 의견이 쌓이기 시작한 것이다.
이 지점에서 중요한 문제의식이 생겼다.
클릭률이 좋다고 해서 정말 사용자 경험도 좋은 것인가?
겉으로 보이는 정량 지표 너머에 다른 문제가 숨어 있을 수 있다는 의심에서 출발한 것이다.
문제를 구체화한 과정
처음에는 사내 제보 채널에 올라온 의견을 주제별로 분류했다.
하지만 이 정도로는 “문제가 있다”는 느낌만 있을 뿐, 정확히 무엇이 문제인지 알기 어려웠다. 그래서 다시 시간순으로 제보를 정리해보았고, 특정 시점 이후부터 기술적 오류보다 사용성과 관련된 부정 경험 제보가 늘어나고 있다는 흐름을 발견했다.
그다음에는 실제 사용자 의견을 확인하기 위해 설문조사를 진행했다. 먼저 만족도를 1점~5점으로 받고, 이후에는 왜 그런 점수를 주었는지 주관식 응답을 받았다. 수백 개의 응답을 분석해보니 패턴은 보였지만, 여전히 어떤 요소가 핵심 문제인지는 불분명했다.
그래서 설문을 한 단계 더 구체화했다. 만족도 점수와 함께, 그 점수를 준 이유를 선택지 형태로 받도록 설계한 것이다. 이를 통해 어떤 불만과 어떤 만족이 상대적으로 더 많이 나타나는지 정량적으로 비교할 수 있게 되었다. 약 1만 명 수준의 응답을 분석한 결과, 부정 평가를 한 사용자에게서 반복적으로 등장하는 키워드가 바로 “광고”였다.
핵심 발견: 사용자는 무엇을 광고라고 느끼는가
이후 유저 인터뷰를 진행한 결과, 사용자가 광고라고 느끼는 기준은 단순히 “배너 영역에 떠 있다”는 위치의 문제가 아니었다. 오히려 다음과 같은 요소들이 중요했다.
- 자신과 상관없는 내용이라고 느껴질 때
- 과장되거나 낚시성 문구처럼 느껴질 때
- 클릭 후 예상했던 결과와 다른 화면이 나올 때
- 경험해보지 못한 내용이라 신뢰가 생기지 않을 때
즉, 사용자는 배너 자체를 광고라고 판단하는 것이 아니라, 자신이 예상한 가치와 실제 경험이 어긋날 때 광고라고 인식한다는 점이 드러난 것이다.
여기서 또 하나 중요한 개념이 등장한다. 바로 확실함이다.
사용자는 문구를 봤을 때, 누르면 어떤 화면이 나오고 어떤 행동을 하게 될지가 어느 정도 그려져야 안심한다. 반대로 예상과 다른 결과가 나오면 그 순간 그것을 “광고” 혹은 “낚시성 경험”으로 받아들인다.
해결 방향
이 문제를 해결하기 위해 팀은 몇 가지 장치를 마련했다.
첫째, UX 라이팅 가이드라인을 만들었다.
어떤 식으로 문장을 쓰면 되는지, 어떤 표현은 피해야 하는지를 사례 중심으로 정리하였다.
둘째, 좋은 문구 템플릿을 제공했다.
정직하면서도 클릭률이 높았던 문구 사례를 템플릿화하여 팀원들이 참고할 수 있도록 한 것이다.
셋째, 광고 문법 검사 기능을 추가했다.
문구만 보았을 때 클릭 후 어떤 결과가 나올지 예상 가능한지, 낚시성 표현은 아닌지를 시스템 차원에서 점검하는 기능이다.
넷째, 정성 지표를 볼 수 있는 대시보드를 기획했다.
만족도 점수뿐 아니라 사용자가 실제로 어떤 이유로 만족하거나 불만족했는지까지 담당자들이 직접 볼 수 있도록 하여, 정량 지표와 정성 피드백을 함께 점검할 수 있게 했다.
이 사례는 단순히 문제를 발견하는 데서 끝나지 않고, 사용자 경험에 대한 인사이트를 조직 안에서 반복적으로 활용할 수 있는 구조로 바꾸는 과정까지 이어진 것이다.
