기획자에게 "데이터를 볼 줄 알아야 한다"는 말은 이제 너무 당연한 이야기처럼 들리는데, 실제로 이게 무슨 의미인지 구체적으로 이야기하는 경우는 적은 것 같습니다.
저도 예전엔 "대시보드 보는 법 배우면 되는 거 아닌가" 정도로 생각했는데, 몇 번의 경험을 거치면서 데이터 리터러시가 훨씬 더 근본적인 역량이라는 걸 깨닫게 됐어요.
이번 글에서는 제가 겪은 사례를 바탕으로, 기획자에게 데이터 리터러시가 왜 중요한지 정리해보려 합니다.
대시보드에서 숫자가 올랐다는 걸 확인하는 건 누구나 할 수 있습니다.
문제는 그 숫자가 왜 올랐는지를 판단하는 능력이에요.
저희 팀에서 한 번은 특정 기능의 사용률이 갑자기 20% 올랐다는 걸 보고 다들 좋아했는데, 알고 보니 그 주에 서버 오류로 다른 기능이 일시적으로 막혀서 사용자들이 그 기능으로 몰린 거였습니다.
숫자만 보고 "우리 개선이 효과가 있었다"고 결론 내렸다면 완전히 잘못된 판단을 할 뻔했어요.
데이터 리터러시란 결국 숫자 뒤에 있는 맥락과 원인을 의심하고 확인하는 습관이라고 생각합니다.
이 부분은 알면서도 실제 업무에서 계속 놓치게 되는 함정이었습니다.
저희가 신규 기능을 출시한 주에 전체 매출이 올랐다는 걸 보고 "이 기능이 매출을 끌어올렸다"고 보고했다가, 나중에 알고 보니 같은 시기에 대형 프로모션이 진행되고 있었다는 걸 놓쳤던 적이 있어요.
이 실수를 겪은 뒤로는 어떤 지표가 개선됐을 때 "다른 원인이 동시에 있었는가"를 먼저 체크하는 습관을 들이게 됐습니다.
간단하게는 프로모션, 시즌 이슈, 외부 언론 노출 같은 걸 캘린더에 같이 표시해두고, 지표를 볼 때 항상 같이 확인하고 있어요.
A/B 테스트를 돌릴 때 표본이 너무 작으면 결과를 신뢰할 수 없다는 걸 이론으로는 알고 있었는데, 실제로 이걸 무시하고 성급하게 결론을 내린 적이 있습니다.
사용자 200명 정도를 대상으로 한 테스트에서 클릭률이 5%포인트 차이가 났다고 "새 버전이 더 좋다"고 보고했다가, 데이터 분석팀에게서 "이 표본으로는 통계적으로 의미 있는 차이라고 보기 어렵다"는 피드백을 받았어요.
그 이후로는 테스트를 설계할 때 필요한 최소 표본 크기를 먼저 계산하고, 그 크기가 모일 때까지 결론을 미루는 습관을 들이게 됐습니다.
데이터 리터러시는 데이터를 "읽는" 능력뿐 아니라, 필요한 데이터를 정확하게 "요청하는" 능력도 포함한다고 생각합니다.
저는 예전에 데이터 분석팀에게 "이 기능 얼마나 많이 쓰는지 알려주세요"라고만 요청했다가, 정작 필요했던 "재사용률"이 아니라 "1회성 클릭 수"를 받아서 다시 요청을 해야 했던 적이 있어요.
이 경험 이후로는 데이터를 요청할 때 "어떤 지표를, 어떤 기간으로, 어떤 세그먼트로 나눠서"까지 구체적으로 명시하는 버릇이 생겼습니다.
이렇게 요청 자체를 정교하게 하는 것만으로도, 원하는 답을 받기까지 걸리는 시간이 훨씬 줄었어요.
역설적이게도, 데이터 리터러시가 높아질수록 "이 상황에서는 데이터가 충분하지 않다"는 걸 인정하는 것도 중요해졌습니다.
신규 시장에 진출하는 것처럼 과거 데이터가 없는 의사결정에서, 데이터가 없다는 이유로 결정을 무한정 미루는 것도 문제라는 걸 느꼈어요.
이런 상황에서는 최소한의 정성적 근거(사용자 인터뷰, 유사 서비스 벤치마크)로 가설을 세우고, 작게 시작해서 데이터를 빠르게 쌓는 방향으로 전환하는 판단이 필요합니다.
데이터 리터러시는 데이터가 있을 때 잘 쓰는 능력뿐 아니라, 데이터가 없을 때 어떻게 움직일지를 판단하는 능력까지 포함한다고 생각하게 됐어요.
저 혼자 데이터를 잘 본다고 해서 팀 전체 의사결정이 좋아지는 건 아니었습니다.
저희는 매주 짧게 "이번 주 지표 중 이상했던 것 하나"를 팀 전체가 같이 살펴보는 시간을 만들었어요.
처음엔 형식적으로 시작했는데, 몇 달 지나니 팀원들이 스스로 "이 숫자 이상한데요"라고 먼저 짚어주는 경우가 늘었습니다.
데이터를 해석하는 감각은 혼자 기르는 것보다 팀 전체가 같이 습관으로 만드는 게 훨씬 효과적이라는 걸 느꼈어요.
기획자가 통계학자가 될 필요는 없지만, 숫자를 보고 "그래서 뭐가 진짜 원인일까"를 계속 의심하는 태도는 반드시 필요하다고 생각합니다.
저도 몇 번의 실수를 겪으면서 이 감각을 조금씩 키워온 것 같고, 앞으로도 데이터를 대할 때 겸손하게 의심하는 태도를 계속 유지하려고 합니다. 데이터가 답을 주는 게 아니라, 데이터를 제대로 읽는 사람이 답을 찾아가는 거라는 걸 계속 되새기고 있어요.
'Planning · PM > 프로젝트 · PM' 카테고리의 다른 글
| 기획자의 산출물, 어디까지가 적정선인가 (0) | 2021.04.20 |
|---|---|
| 서비스 고도화 로드맵 짜는 법 (0) | 2021.04.12 |
| 협업 문서, 어디까지 표준화해야 할까 (0) | 2021.01.31 |
| 코로나 이후 비대면 서비스 기획에서 달라진 것들 (0) | 2020.11.22 |
| 재택근무 시대의 PM 협업 방식 변화 (0) | 2020.11.17 |