기획자가 SQL을 배워도 데이터로 설득하지 못하는 이유

SQL을 배우고 나서 회의가 달라지셨나요? 질의는 직접 돌릴 수 있게 됐는데 회의 결론은 여전히 목소리 큰 쪽으로 기운다면, 문제는 도구가 아닙니다. 먼저 결론부터 말씀드리겠습니다. 기획자가 데이터로 설득하지 못하는 이유는 쿼리 실력이 아니라 질문의 순서 때문입니다. 숫자를 뽑기 전에 “어떤 결과가 나오면 내 주장이 틀린 것인가”를 정하지 않으면, SQL은 이미 정해둔 결론을 장식하는 도구가 됩니다. 순서를 바꾸면 같은 데이터로도 회의가 달라집니다.

기획자가 SQL을 배워도 회의가 그대로인 이유

먼저 조직 쪽 상황을 보겠습니다. 웨이브스톤이 2025년 발표한 조사에서 포춘 1000대 기업 중 데이터 문화를 실제로 정착시켰다고 답한 곳은 24%에 그쳤습니다. 데이터 주도 조직이라고 답한 비율도 37% 수준입니다. 포레스터 조사에서는 응답자의 74%가 더 데이터 중심으로 일하고 싶다고 답했지만, 원하는 변화를 실제로 구현했다는 응답은 29%였습니다.

숫자를 다룰 사람이 없어서 생긴 격차가 아닙니다. 대시보드는 이미 넘칩니다. 그런데도 결정은 대개 회의실에서 뒤집힙니다. 왜일까요?

관점을 바꿔보겠습니다. 우리가 회의에 들고 가는 표는 대부분 결정을 내리기 위한 자료가 아니라 이미 내린 결정을 지지하는 자료입니다. 기능을 만들고 싶어서 근거를 찾고, 리텐션이 낮다고 말하고 싶어서 낮게 나오는 구간을 잘라 옵니다. (저도 오래 그렇게 했습니다.) 상대는 그것을 정확히 알아봅니다. 그래서 다른 구간을 잘라 온 표로 맞섭니다. 이 회의는 데이터 회의가 아니라 표를 든 취향 대결입니다.

숫자가 결론을 만들지 못하는 지점

과학계는 같은 문제를 먼저 겪었고, 이름까지 붙여두었습니다. 결과를 본 뒤에 가설을 만드는 관행, 즉 HARKing입니다. 노섹 연구진은 2018년 미국국립과학원회보에 실은 글에서 진짜 문제를 이렇게 짚었습니다. 기존 관찰로 가설을 만드는 일과 새로운 관찰로 가설을 검증하는 일은 다른 작업인데, 실무에서 이 둘이 뒤섞인다는 것입니다. 사후 해석을 검증으로 착각하는 순간 결과의 신뢰도는 무너집니다.

해법으로 제안된 것이 사전 등록입니다. 데이터를 보기 전에 가설과 분석 방법을 시간이 기록되는 문서에 적어두는 방식입니다. 연구자의 자유도를 스스로 묶는 장치입니다.

프로덕트 조직에서 이 원리는 그대로 통합니다. 카너먼이 말한 대로 사람은 눈앞에 보이는 정보만으로 그럴듯한 이야기를 완성합니다. 보이지 않는 데이터는 이야기에 포함되지 않습니다. 그래서 표를 먼저 열면, 표 안에서 가장 눈에 띄는 숫자를 중심으로 이야기가 만들어집니다. 그 이야기는 대체로 매끄럽고, 대체로 검증된 적이 없습니다.

숫자를 뽑기 전에 네 줄을 먼저 적습니다

포퍼가 과학과 비과학을 가른 기준은 증명 가능성이 아니라 반증 가능성이었습니다. 어떤 관찰이 나오면 이 주장이 틀린 것인지 미리 말할 수 있어야 주장이라는 것입니다. 이 기준을 기획 문서에 옮기면 네 줄이 됩니다.

세 번째 줄이 핵심입니다. 기각 조건이 비어 있는 문서는 검증 문서가 아니라 계획 발표문입니다.

예전에 반려동물 용품의 사이즈 선택 문제를 다룬 적이 있습니다. 구매 과정에서 치수를 재는 일이 번거로워 이탈이 난다는 가설이었고, 신용카드를 기준자로 삼아 사진에서 치수를 자동 추정하는 방식을 떠올렸습니다. 그때 팀과 먼저 정한 것은 개발 일정이 아니라 접는 조건이었습니다. 보호자 50여 명에게 시험해서 추정 치수와 실측의 오차가 허용 범위를 넘으면 이 방향을 접는다고 적었습니다. 결과 자체보다 이 문장 하나가 팀을 편하게 만들었습니다. 아무도 자기 아이디어를 방어할 필요가 없어졌기 때문입니다.

요청받은 지표와 답해야 할 질문은 다릅니다

여기서부터가 흥미로운 지점입니다. 순서를 지켜도 잘못된 질문에 답하면 설득은 되지 않습니다.

원가 관리 시스템을 개선할 때 현업에서 받은 요청은 명확했습니다. 차트를 넣어달라는 것이었습니다. 요청대로 만들었다면 저는 차트를 만들었을 겁니다. 그런데 실제로 그분들이 매일 하던 일을 따라가 보니, 영업 쪽 숫자와 운영 쪽 숫자를 각각 다른 화면에서 조회해 손으로 옮겨 적고 있었습니다. 필요한 것은 시각화가 아니라 한 화면에서의 비교였습니다. 차트를 요청한 이유는 두 숫자를 나란히 놓을 방법이 그것밖에 떠오르지 않아서였습니다.

이 구분을 습관으로 만들면 회의가 짧아집니다.

• 요청받은 지표: 상대가 말한 숫자 (차트, 리텐션, DAU)
• 답해야 할 질문: 그 숫자로 무엇을 결정하려는가
• 결정의 갈림길: 어떤 값이면 A를, 어떤 값이면 B를 택하는가

세 번째 항목에 답이 안 나오면 그 조회는 아직 필요하지 않습니다. 노스스타 지표가 매출이 아니어야 하는 이유도 같은 자리에 있습니다. 지표는 성적표가 아니라 결정을 나누는 선이어야 합니다.

상담 로그를 22만 건 분석했던 적도 있습니다. 규모가 크면 답이 나올 줄 알았는데, 로그는 무엇이 일어났는지만 알려줄 뿐 왜 그랬는지는 말해주지 않았습니다. 상담사 몇 분과 이야기를 나눈 뒤에야 로그의 특정 패턴이 무엇을 뜻하는지 읽혔습니다. 정량 데이터는 질문의 범위를 좁히고, 정성 데이터는 그 안에서 이유를 채웁니다. 유저 인터뷰에서 유도 질문이 위험한 이유를 함께 보시면 순서가 더 분명해집니다.

설득은 숫자가 아니라 먼저 합의한 기준에서 나옵니다

마지막으로 팀 전체가 공유하면 좋은 사실이 하나 있습니다. 코하비와 톰케가 하버드 비즈니스 리뷰에 정리한 바에 따르면, 마이크로소프트에서 잘 설계되고 실행된 실험 중 목표 지표를 실제로 개선한 것은 약 3분의 1이었습니다. 나머지 3분의 2는 효과가 없거나 오히려 나빴습니다.

이 숫자가 회의실에서 하는 일은 겸손의 권고가 아닙니다. 틀리는 것이 기본값이라는 사실을 미리 공유하면, 틀렸다는 결과가 누구의 패배도 되지 않습니다. 기각 조건을 먼저 적자는 제안이 받아들여지는 것도 이 전제가 깔린 팀에서입니다. A/B 테스트의 속도가 설계에서 결정된다는 이야기의 앞단에도 같은 합의가 있습니다.

작은 실험 하나를 제안합니다. 다음 기획 문서의 목표 지표 아래에 기각 조건 한 줄을 넣어보세요. “2주 뒤 이 수치가 X 미만이면 되돌린다.” 그 한 줄이 들어가면 리뷰의 질문이 바뀝니다. 이 기능이 좋은가에서, 우리가 무엇을 보면 판단할 것인가로 옮겨 갑니다. PRD가 기능 목록이 아니어야 하는 이유도 여기에 닿아 있습니다.

쿼리는 나중에 배워도 됩니다

기획자에게 SQL은 분명 쓸모 있는 도구입니다. 조회 요청을 기다리는 하루가 10분으로 줄면 검증할 수 있는 가설의 수가 달라집니다. 다만 순서가 바뀌면 도구는 방향을 잃습니다.

숫자를 열기 전에 다섯 줄을 적어보시길 권합니다. 무엇을 결정하려 하는가, 어떤 지표를 볼 것인가, 어느 쪽으로 움직일 것으로 보는가, 무엇이 나오면 내가 틀린 것인가, 언제 판정할 것인가. 이 다섯 줄이 있는 회의에서는 데이터가 무기가 아니라 심판이 됩니다. 그때부터 설득은 여러분이 하는 일이 아니라 기준이 하는 일이 됩니다.

참고 자료

• Brian A. Nosek, Charles R. Ebersole, Alexander C. DeHaven & David T. Mellor, “The Preregistration Revolution”, PNAS, 2018
• Ron Kohavi & Stefan Thomke, “The Surprising Power of Online Experiments”, Harvard Business Review, 2017
• Karl Popper, 『Conjectures and Refutations: The Growth of Scientific Knowledge』, Routledge, 1963
• Daniel Kahneman, 『Thinking, Fast and Slow』, Farrar, Straus and Giroux, 2011
• Wavestone, “Data and AI Leadership Executive Survey 2025”