{3줄 요약}

데이터 기반 설계는 개인적 감이 아니라 데이터 근거로 설계 결정을 뒷받침하는 방식이에요.
데이터는 무엇이 일어났는지는 말해 주지만 왜인지는 말하지 않아서 인터뷰 등과 함께 읽어야 해요.
어떤 숫자를 볼지 고르는 선택이, 숫자를 읽는 행위보다 더 중요한 설계 결정이에요.

이 방법을 쓰는 맥락

데이터 기반 설계는 이런 상황에서 특히 강력해요:

  • 두 가지 설계 방향 중 어느 것이 더 나은지 A/B 테스트로 결정할 때
  • "이 화면에서 왜 사용자가 이탈하는지" 퍼널 데이터로 확인할 때
  • 출시 이후 개선이 실제로 지표를 바꿨는지 측정할 때
  • 이해관계자에게 설계 결정의 근거를 보여줄 때

"우리 팀은 데이터가 없어요"라는 경우는 생각보다 드물어요.
구글 애널리틱스, Firebase, Amplitude — 많은 팀이 이미 데이터를 수집하고 있지만 설계 결정에 연결하지 않아요.

단계별 실행 방법

1단계 — 질문부터 정하기

데이터를 보기 전에 "무엇을 알고 싶은가"를 먼저 써요.

좋은 질문 예시:

  • "결제 3단계에서 이탈율이 높은데, 어느 필드에서 막히는가?"
  • "새 온보딩 흐름이 7일 재방문율을 개선했는가?"
  • "iOS와 Android 사용자의 기능 사용 패턴이 다른가?"

질문 없이 데이터를 보면 눈에 띄는 숫자에 이끌려요. 흥미롭지만 지금 풀어야 할 문제와 관계없는 것을 분석하게 돼요.

Eric Ries는 《Lean Startup》에서 이걸 "허영 지표(Vanity Metrics)"와 "실행 가능한 지표(Actionable Metrics)"의 차이로 설명했어요.
총 가입자 수는 허영 지표예요.
"7일 내 재방문한 가입자 비율"은 실행 가능한 지표예요.
어떤 질문을 하느냐가 어떤 데이터를 보느냐를 결정해요.

2단계 — 올바른 데이터 소스 선택하기

질문에 따라 어디서 데이터를 가져올지 달라져요.

질문 유형 데이터 소스
어느 화면에서 이탈이 많은가 퍼널 분석 (Amplitude, Mixpanel)
사용자가 뭘 클릭하는가 히트맵, 세션 리코딩 (Hotjar, FullStory)
A가 나은가 B가 나은가 A/B 테스트 도구 (Optimizely, Firebase)
사용자 만족도 NPS 설문, 인앱 설문
기능별 사용률 이벤트 트래킹

데이터 소스를 잘못 선택하면 잘못된 답을 얻어요.
이탈율을 낮추고 싶은데 클릭 히트맵만 보면, 어디서 나가는지는 모르고 어디를 많이 클릭했는지만 알게 돼요.

3단계 — 데이터에서 패턴 찾기

수집한 데이터에서 반복되는 패턴을 찾아요. 이상 수치(Anomaly)도 중요해요.

패턴을 찾는 방법:

  • 코호트 분석: 같은 기간에 가입한 사용자들을 묶어서 시간에 따른 행동 변화를 봐요. "지난달 가입자들은 이번달 가입자들과 7일 재방문율이 왜 다를까?"
  • 퍼널 분석: 단계별 이탈율을 봐요. 100명이 결제를 시작했다면 각 단계에서 몇 명이 완료했는가.
  • 세그먼트 비교: iOS vs Android, 신규 vs 기존, 연령대별로 나눠서 봐요. 전체 지표는 괜찮지만 특정 집단에서만 문제가 있을 수 있어요.

쿠팡이 모바일 앱 결제 전환율을 개선할 때, 전체 이탈율은 비슷해도 신규 사용자의 이탈율이 기존 사용자보다 2배 높다는 것을 코호트 분석으로 발견했어요.
개선 방향이 "신규 사용자 결제 경험 최적화"로 좁혀졌어요.

4단계 — 데이터가 말하는 "무엇"을 "왜"로 연결하기

데이터는 무엇이 일어났는지만 말해요.
왜 그런지는 인터뷰나 관찰이 필요해요.

예시:

  • 데이터: 결제 2단계에서 40%가 이탈해요
  • 인터뷰 발견: "배송비가 여기서 처음 나와서 놀랐어요"
  • 가설: 배송비를 이전 단계에서 미리 보여주면 이탈이 줄 것이다
  • 실험: 상품 페이지에서 배송비 표시 → A/B 테스트

이 4단계 흐름이 없으면 데이터를 보고도 "그래서 무엇을 바꾸지?"를 모르게 돼요.

5단계 — 변경 후 측정하기

설계를 바꿨으면 그게 실제로 지표를 바꿨는지 확인해요.

A/B 테스트: 일부 사용자에게 새 디자인을, 나머지에게 기존 디자인을 보여주고 결과를 비교해요.

Before/After 비교: A/B 테스트가 어렵다면, 출시 전후 같은 기간을 비교해요.
다만 다른 변수(시즌, 마케팅 캠페인)가 영향을 줄 수 있으니 해석에 주의해요.

통계적 유의성(Statistical Significance): 차이가 실제인지 우연인지 판단하는 기준이에요.
일반적으로 95% 신뢰 수준 이상이어야 의미 있는 차이로 봐요.
샘플 수가 충분하지 않으면 같은 실험을 반복해도 결과가 달라질 수 있어요.

하지 말아야 할 것

데이터를 해석에 맞게 고르지 마세요: 원하는 결론이 있을 때 그것을 지지하는 데이터만 찾는 것을 확증 편향(Confirmation Bias)이라고 해요.
불편한 데이터도 같이 봐야 해요.

충분하지 않은 샘플로 결론 내리지 마세요: 100명의 데이터와 10,000명의 데이터에서 같은 비율이 나왔다고 같은 신뢰도가 아니에요.

데이터로 창의적 탐색을 막지 마세요: "데이터에 없으면 안 해요"라는 태도는 과거 행동 기반 데이터가 미래 혁신을 막는 함정이에요.
사용자는 아직 경험하지 않은 것을 데이터로 요청할 수 없어요.

실행 후 확인하기

  • 분석 시작 전에 질문을 먼저 정했나요?
  • 질문에 맞는 데이터 소스를 선택했나요?
  • 데이터의 "무엇"을 사용자 인터뷰로 "왜"와 연결했나요?
  • 설계 변경 후 지표 변화를 측정했나요?
  • 원하는 결론에 맞는 데이터만 선택하지는 않았나요?

관련 아티클

참고 문헌

  • Alistair Croll & Benjamin Yoskovitz, 《Lean Analytics》(2013) - 허영 지표와 실행 가능한 지표의 차이, 코호트 분석, 측정 가능한 목표 설정의 핵심 방법론이에요. 이 글의 "질문부터 정하기" 원칙의 근거예요.