이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
데이터 기반 가설 실험에서 제가 먼저 하는 것은 가설을 측정 가능한 형태로 다듬는 것입니다. '유저가 이 기능을 좋아한다'는 가설은 실험 설계를 할 수 없지만, '이 버튼을 누른 사용자가 구매까지 이어지는 비율이 다른 버튼보다 높다'는 형태로 만들면 측정할 수 있습니다.
UX 수업 팀 프로젝트에서 앱 온보딩 흐름 개선 A/B 테스트를 설계했습니다. 기존 흐름과 단순화된 흐름을 비교하여 3일 유지율 차이를 지표로 잡았는데, 결과적으로 단순화된 쪽이 11% 높게 나왔습니다. 실패는 샘플 크기를 너무 작게 잡아서 통계적으로 유의미한지 확인을 못 한 것이었는데, 이후 실험 설계 전에 샘플 크기 계산을 먼저 하는 습관을 만들었습니다.
가설 실험은 '확인하고 싶은 것'을 '측정할 수 있는 것'으로 번역하는 작업이라고 생각합니다. 그 번역이 잘 되어야 실험도 의미가 있습니다.
데이터 가설 실험에서 중요하게 생각하는 건 처음부터 크게 검증하려 하지 않는 것입니다. 소규모 실험으로 빠르게 틀렸는지 확인하고, 맞는 방향이라는 신호가 오면 그때 크게 가는 게 낫다고 생각해요.
졸업 프로젝트에서 커뮤니티 앱 UI 개선 가설을 세웠을 때, 전체 사용자에게 적용하기 전에 테스트 그룹 20명에게 먼저 피드백을 받았습니다. 그 결과 애초 가설이 틀렸다는 게 일주일 만에 드러났어요. 20명 단계에서 포착하지 못했다면 전체 배포 후에 발견했을 거예요. 실패는 20명 그룹을 선정할 때 기존 헤비 유저만 포함시켜서 신규 유저 반응을 놓친 것이었습니다.
좋은 가설 실험은 틀릴 기회를 싸게 만드는 것이라고 생각합니다. 빠른 실패가 학습 속도를 결정한다는 걸 그 경험에서 배웠어요.
가설 실험 결과를 볼 때 제가 먼저 하는 건 '이 결과가 실제 효과인가, 아니면 다른 요인인가'를 따져보는 것입니다. 데이터가 나왔다고 해서 바로 결론을 내리면 방향이 틀릴 수 있거든요.
수업 팀 프로젝트에서 이벤트 기간 중 트래픽 급증 원인을 분석했을 때, 처음엔 새 배너 때문이라고 결론냈는데 나중에 같은 기간에 외부 커뮤니티에서 자연 유입이 있었다는 걸 발견했습니다. 배너 효과와 자연 유입을 분리하지 않은 거예요. 실패는 데이터가 나오자마자 첫 가설을 확인한 것처럼 해석한 것이었습니다. 이후로는 결과를 보기 전에 '이 기간에 다른 변화가 있었나'를 먼저 체크하는 습관을 만들었어요.
데이터는 사실을 보여주지만, 해석은 사람이 하는 것입니다. 그 해석 단계에서 편향을 줄이는 게 가설 실험의 진짜 어려운 부분이라고 생각해요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.