데이터가 쌓일수록 왜 답은 더 멀어질까요
"숫자는 거짓말을 하지 않는다"는 말, 한 번쯤 들어보셨을 겁니다. GA에 쌓인 유저 플로우, 히트맵 위의 클릭 지점, A/B 테스트의 전환율 수치. 이 숫자들은 마치 완벽한 진실처럼 느껴지곤 합니다.
그런데 한 가지 불편한 질문을 드려볼게요.
데이터가 충분히 쌓였는데도, 왜 같은 문제가 반복되는 걸까요?
심리학에는 확증 편향(Confirmation Bias)이라는 개념이 있습니다. 사람은 자신이 믿고 싶은 것을 뒷받침하는 근거만 선택적으로 받아들이는 경향이 있습니다. 데이터를 다루는 우리도 예외가 아닙니다. 문제는 이 편향이 데이터 수집 이후가 아니라, 무엇을 측정할지 결정하는 설계 단계에서부터 시작된다는 점입니다.
많은 팀이 "어떤 데이터를 얼마나 많이 모았는가"에 집중합니다. 하지만 잘못된 질문에서 출발한 데이터는 아무리 많이 쌓여도 잘못된 방향을 가리킬 뿐입니다. 데이터의 양이 아니라, "우리가 원하는 질문에 답할 수 있는 데이터를 설계했는가"가 핵심입니다.
상관관계를 인과관계로 착각하는 순간
심리학자 B.F. 스키너의 유명한 실험을 아시나요? 비둘기에게 먹이를 무작위로 주었을 때, 비둘기는 자신이 특정 행동을 했기 때문에 먹이가 나왔다고 '믿기' 시작했습니다. 패턴 없는 곳에서 패턴을 찾아내는 것—이것이 인간 뇌의 본능입니다.
데이터를 읽을 때도 같은 일이 일어납니다. 히트맵을 보니 특정 버튼 근처에서 유저들이 오래 머무른다면, 우리는 자연스럽게 "이 버튼이 매력적이라서"라고 해석합니다. 하지만 실제로는 그 버튼 옆에 배치된 필수 안내 문구를 읽느라 머무는 것일 수 있습니다.
데이터는 '무엇이 일어났는지(What)'는 보여주지만, '왜 일어났는지(Why)'는 말해주지 않습니다. 이 '왜'를 밝히기 위해서는 트래킹 코드를 추가하는 수준을 넘어, 연구 설계 단계부터 근본적인 질문을 먼저 던져야 합니다.
좋은 데이터는 좋은 질문이 아니라, 좋은 스키마에서 나옵니다
여기서 한 걸음 더 나아가야 합니다.
올바른 질문을 갖췄다고 해서 끝이 아닙니다. 그 질문에 답할 수 있으려면, 데이터를 담는 구조 자체—즉 데이터 스키마—가 그 질문에 맞게 설계되어 있어야 합니다.
예를 들어 "왜 사용자가 결제 직전에 이탈하는가?"라는 질문을 갖고 있다고 가정해 봅시다. 그런데 현재 수집하는 데이터가 단순히 '페이지별 이탈률'뿐이라면, 그 질문에는 영원히 답할 수 없습니다. 이탈이 일어난 시점은 알 수 있어도, 이탈이 일어난 맥락—사용자가 어떤 단계에서 어떤 감정 상태에 있었는지—은 포착되지 않기 때문입니다.
좋은 인풋을 원한다면, 인풋을 담는 그릇부터 바꿔야 합니다. 데이터 스키마는 단순한 기술적 설계가 아니라, "우리가 어떤 질문에 답하고자 하는가"를 구조적으로 선언하는 행위입니다.
스키마를 바꾸기 전에 거쳐야 할 과정
그렇다면 스키마를 어떻게 바꿔야 할까요? 이 질문에 답하기 전에 반드시 거쳐야 할 과정이 있습니다. 바로 '방법론적 유효성 감사(Methodological Validity Audit)'입니다.
이 감사는 "트래킹 코드를 더 심을까요?"라는 질문에 답하는 게 아닙니다. "지금 우리가 수집하는 이 데이터가, 우리가 풀고자 하는 비즈니스 문제의 본질을 담아낼 수 있는가?"를 먼저 묻는 과정입니다.
현업에서 자주 마주치는 상황을 예로 들어볼게요.
클라이언트가 "전환율이 낮으니 결제 버튼 주변의 스크롤 깊이를 늘려야 한다"고 주장합니다. 이 시점에서 방법론적 감사를 거치면 전혀 다른 진단에 도달하는 경우가 많습니다. 실제 문제는 스크롤 깊이가 아니라, 결제 직전 단계에서 사용자가 서비스를 신뢰하지 못하게 만드는 구조적 결함—예를 들면 지나치게 복잡한 약관 동의 과정—일 수 있습니다. 데이터는 '어디서 이탈했는지'만 보여줄 뿐, '왜 이탈했는지'는 설명하지 못하기 때문입니다.
감사를 통해 진짜 질문을 찾아낸 뒤에야, 비로소 그 질문에 맞는 스키마 설계가 가능해집니다.
"우리 업종은 달라서 안 될 것 같다"는 생각이 드신다면
"우리는 B2B라서 다르다", "규모가 작아서 복잡한 감사 과정은 무리다"라는 반응, 이해합니다. 그런데 이런 생각 자체가 하나의 인지적 회피일 수 있습니다. 심리학에서는 이를 현상 유지 편향(Status Quo Bias)이라고 부릅니다. 변화보다 지금 방식이 편하기 때문에, 변화를 막는 이유를 찾는 경향이죠.
문제는 업종이나 규모가 아닙니다. 문제의 본질을 구조적·설계적 관점에서 바라보지 못하는 데 있습니다.
오히려 B2B SaaS처럼 유저 여정이 복잡하고 의사결정 주체가 여럿인 환경일수록, 잘못 설계된 스키마가 초래하는 피해는 기하급수적으로 커집니다. 데이터에 의존하는 것이 아니라, 데이터가 담고 있는 맥락(Context)을 이해하는 것—그리고 그 맥락을 담을 수 있는 구조를 먼저 설계하는 것—이 핵심입니다.
지금 당장 실행할 수 있는 3단계 액션 플랜
1단계. 질문 재정의 (The Why)
"무엇을 측정할 것인가?" 대신 "우리가 해결하려는 근본적인 문제는 무엇인가?"로 질문을 바꿔보세요. '전환율을 높이는 것'이라는 목표를 '사용자가 서비스의 가치를 명확히 인지하지 못하게 만드는 구조적 장벽을 제거하는 것'으로 재정의하는 것처럼요. 질문이 바뀌면, 측정해야 할 데이터도 달라집니다.
2단계. 스키마 재설계 (The Structure)
질문이 바뀌었다면, 다음은 그 질문에 답할 수 있는 데이터 구조를 새로 설계해야 합니다. 기존 이벤트 트래킹 항목을 그대로 두고 분석 방식만 바꾸는 것으로는 부족합니다. "이 질문에 답하려면 어떤 맥락 데이터가 필요한가?"를 먼저 정의하고, 그에 맞게 수집 항목과 구조를 처음부터 다시 설계해야 합니다. 가설 → 측정 항목 → 기대 결과의 논리적 연결이 스키마 안에 녹아 있어야 합니다.
3단계. 비(非)행동 데이터 수집 도입 (The Context)
클릭 수나 체류 시간 같은 행동 데이터 외에, 사용자가 느끼는 감정적 맥락을 수집하는 구조도 스키마에 포함되어야 합니다. 특정 단계에서 사용자가 어떤 고민을 했는지, 어떤 질문을 품었는지—이런 정성적 데이터를 의도적으로 수집하는 프로세스가 있어야 행동 데이터가 비로소 의미를 가집니다.
이 과정에서 가장 어려운 것은 기술적인 구현이 아닙니다. "이 데이터 구조가 맞다"는 관성적 믿음을 스스로 의심하는 태도를 갖추는 것입니다. 그 의심에서 출발해야만, 데이터가 가진 진짜 가치를 발견할 수 있습니다.
📝 핵심 요약
데이터 툴은 현상을 보여줄 뿐, 그 현상의 근본적인 원인을 설명하지 못합니다.
좋은 인풋은 좋은 질문만으로는 부족합니다. 그 질문을 담을 수 있는 데이터 스키마가 먼저 설계되어야 합니다.
진정한 데이터 기반 의사결정은 수집 이후의 분석이 아닌, 설계 단계의 방법론적 검증에서 시작됩니다.
데이터를 단순한 증거로 받아들이기보다, 가설을 검증하는 도구로 바라보는 관점의 전환이 필요합니다. 그리고 그 전환은 분석 단계가 아니라, 스키마를 설계하는 바로 그 순간부터 시작됩니다.
SHAREABLE INSIGHT
"데이터 기반 의사결정의 진짜 함정은 데이터의 양이 아니라, 방법론적 유효성(Methodological Validity)의 부재에 있습니다. 좋은 인풋을 원한다면 분석 방식이 아니라 데이터 스키마부터 바꿔야 합니다. 올바른 질문을 먼저 정의하고, 그 질문에 답할 수 있는 구조를 설계 단계에서 검증하는 것—그것이 데이터가 진짜 가치를 갖는 유일한 방법입니다."
출처: Nielsen Norman Group (NN/g) (https://www.nngroup.com/articles/research-tool-problems/)