한 팀의 무기에서 모두의 기본기로: 실험이 조직의 공용어가 되는 순간, Diffusion ①

channel_editor_icon 신진수

20시간 전

지난 글(바로가기)에서는 Commitment, 개인의 용기로 생긴 균열을 조직의 뼈대로 굳히는 단계를 이야기했습니다.
한 팀이 “이건 실험으로 결정한다”를 규칙으로 삼고, 반복해서 실험할 수 있는 구조를 만들기 시작하는 단계였죠.
그런데 Commitment 단계가 성공하면 새로운 문제가 생깁니다.

처음에는 데이터팀이나 소수의 실험 전문가가 가설을 다듬고, 대상자를 나누고, 결과를 해석해줍니다.
하지만 실험의 가치를 경험한 팀이 늘어날수록 요청은 빠르게 쌓입니다.
데이터팀의 인원은 그대로인데, 실험을 시작하려는 팀은 계속 늘어나게 됩니다. 결국 조직은 선택해야 합니다.

데이터팀이 모든 실험을 계속 대신할 것인가
아니면 다른 팀도 스스로 실험할 수 있게 만들 것인가

네 번째 단계인 Diffusion은 그 선택에 답하는 단계입니다. 이번 Diffusion은 2개의 파트로 진행합니다.

Awareness → Belief → Commitment → Diffusion → Embeddedness

1. Diffusion이란 무엇인가

Diffusion은 대규모 실험이 제품의 성과를 좌우한다는 사실을 리더십이 받아들이고, 실험의 도구와 표준, 교육을 조직 전체로 확산하는 단계입니다.

Commitment가 “한 팀이 실험으로 결정한다”였다면, Diffusion은 “어느 팀이든 실험으로 결정할 수 있다”로 넓히는 일입니다. 소수 전문가의 무기였던 실험이 마케터, 기획자, 개발자도 꺼내 쓸 수 있는 모두의 기본기가 되는 순간이죠.

다만 여기서 중요한 건 단순히 실험 권한을 열어주는 것이 아닙니다.누구나 실험할 수 있게 만들면서도, 그 결과를 계속 믿을 수 있어야 합니다. 실험을 널리 퍼뜨리는 것보다 더 어려운 일은, 널리 퍼진 실험의 품질과 신뢰를 지키는 일이기 때문입니다.

Diffusion은 실험을 단순히 많이 하는 단계가 아닙니다.

“데이터팀이 모든 과정을 일일이 통제하지 않아도 신뢰할 만한 실험이 반복적으로 만들어지는 구조를 갖추는 단계입니다.”

2. “그냥 다들 실험해”는 왜 실패하는가

실험이 효과적이라는 걸 확인한 조직에서 가장 흔히 나오는 반응은 단순합니다.“앞으로 모든 팀이 실험을 많이 해봅시다.”

하지만 제 경험상 이런 방식은 거의 항상 다른 종류의 혼란을 만듭니다. 실험 수가 늘어난다고 해서 좋은 의사결정만 늘어나는 것은 아니기 때문입니다.

표본이 지나치게 작은 실험, 결과를 본 뒤 유리한 지표만 골라낸 실험, 원하는 결과가 나올 때까지 세그먼트를 계속 나눈 분석도 함께 늘어납니다. 전환율이 몇백 퍼센트 상승했다는 극적인 결과가 나왔지만 실제로는 사용자 몇 명의 행동에 불과한 경우도 생깁니다.

여기서 조직적인 문제도 시작됩니다. 팀마다 지표의 정의가 다르고, 실험마다 성공 기준이 달라집니다. 결과가 애매하면 다시 데이터팀으로 결과 해석 요청이 몰리고, 실패한 실험은 제대로 기록되지 않은 채 성공 사례만 공유됩니다.

가장 심각한 경우는 실험을 돌리기는 하지만, 정작 의사결정은 이전과 똑같이 하는 것입니다.

결과가 리더의 예상과 일치하면 “데이터로 검증됐다”고 말하고, 예상과 다르면 “이번 실험은 특수한 사례”라고 넘겨버립니다. 실험은 많아졌지만 결과가 회의실의 직급을 이기지 못한다면, 도구만 확산됐을 뿐 의사결정 방식은 아직 확산되지 않은 겁니다. 그래서 Diffusion은 “더 많이 실험하자”는 구호가 아닙니다.

아무나 실험해도 크게 틀리지 않도록 길을 깔고, 결과가 예상과 다르더라도 같은 규칙으로 판단하게 만드는 일입니다. 그 길은 조직 내 표준화된 도구, 문화, 교육, 그리고 운영 방식으로 만들어집니다.

3. How 1: 반복되는 실수는 도구가 막아야 한다

첫 번째는 도구입니다.

중요한 것은 단순히 실험을 쉽게 만드는 데 있지 않습니다. 사람이 매번 기억하고 확인해야 했던 함정을 도구가 대신 막아주는 것이 더 중요합니다.

실험을 조직 전체로 확산할 때 가장 먼저 고민해야 할 것도 실험 생성 버튼이 얼마나 편리한지가 아닙니다. 실험을 시작하기 전에 어떤 정보를 반드시 입력하게 할 것인지, 어떤 조건이 충족되지 않으면 실행할 수 없게 할 것인지, 결과 화면에서 어떤 지표를 우선적으로 보여줄 것인지를 먼저 설계해야 합니다.

예를 들어 표본이 충분하지 않다면 경고를 띄우고, 대조군과 실험군의 배정 비율이 예상과 다르면 (Sample Ratio Mismatc)이를 자동으로 탐지할 수 있어야 합니다. 실험 도중 핵심 지표를 임의로 바꾸거나, 충분한 기간이 지나지 않은 결과를 성급하게 성공으로 해석하지 못하도록 제한할 수도 있습니다.

에어비앤비의 실험 시스템도 같은 문제의식에서 출발했습니다. 온라인 통제 실험은 사용자를 이해하는 강력한 방법이지만, 설계와 해석 과정에는 실수하기 쉬운 지점이 많습니다. 그래서 반복되는 분석을 자동화하고 자주 발생하는 오류를 시스템이 먼저 막도록 설계했습니다. 전문가가 아니어도 실험을 쉽게 시작할 수 있게 하되, 잘못된 결론에는 쉽게 도달하지 않도록 만든 것입니다.

새로운 기능을 처음부터 기능 플래그 뒤에서 출시하고, 그 플래그를 곧바로 실험과 연결하는 것도 같은 맥락입니다. 기능을 모두 개발한 뒤 사후적으로 실험을 붙이는 것이 아니라, 출시 과정 자체에 실험 가능성을 내장하는 것이죠.

Diffusion 단계에서 좋은 도구란 데이터 전문가의 작업을 빠르게 만들어주는 도구가 아닙니다. 전문가가 매번 기억해서 막아야 했던 함정을, 전문가가 없는 자리에서도 시스템이 대신 막아내는 도구입니다.

4. How2 “ 실험을 조직의 공용어로 만든다

두 번째는 표준입니다.

제가 실무에서 여러 팀의 데이터를 함께 보다 보면, 같은 이름의 지표가 서로 다른 의미로 사용되는 경우를 자주 마주합니다. 어떤 팀은 결제 완료를 전환으로 보고, 다른 팀은 결제 화면 진입까지를 전환으로 봅니다. 리텐션이나 활성 사용자도 기준 시점과 대상에 따라 전혀 다른 숫자가 나올 수 있습니다.

각 팀 안에서는 큰 문제가 아닐 수 있지만, 실험이 여러 팀으로 확산되면 이야기가 달라집니다. 같은 지표를 보고 있다고 생각했는데 실제로는 서로 다른 숫자를 비교하게 되고, 결과를 공유하는 자리에서도 실험의 의미보다 지표 정의를 확인하는 데 더 많은 시간을 쓰게 됩니다.

중요한 것은 모든 팀이 똑같이 일하게 만드는 것이 아닙니다. 표준이 필요한 이유는 같은 단어를 같은 의미로 사용하고, 서로 다른 실험을 같은 기준 위에서 이해할 수 있게 만드는 것입니다.

실험 대상, 그룹 배정 방식, 핵심 지표와 보호 지표, 판단 기간을 공통된 형식으로 남기고, 지표도 이름뿐 아니라 계산 기준과 제외 조건까지 함께 정의해야 합니다. 다만 표준화해야 할 것은 지표와 분석 방식만이 아닙니다. 실험을 시작하기 전에 무엇을 합의할지도 정해야 합니다.

어떤 문제를 풀려는지, 핵심 가설은 무엇인지, 어떤 지표를 성공 기준으로 볼지, 결과에 따라 어떤 행동을 할지를 미리 명확히 해야 합니다.
저 역시 결과를 본 뒤 처음에 중요하다고 했던 지표보다 더 좋아 보이는 숫자에 시선이 옮겨가는 장면을 종종 보았습니다.

이렇게 성공의 정의를 사후에 바꾸기 시작하면, 실험은 가설을 검증하는 도구가 아니라 기존 판단과 주장을 정당화하는 도구가 되기 쉽습니다.

그래서 좋은 실험 문서는 단순한 결과 보고서가 아닙니다. 데이터 기반 의사결정을 위해 구성원들이 미리 합의한 기준을 남기는 기록에 가깝습니다.

실험이 끝난 뒤 무엇을 그럴듯하게 설명했는지보다, 시작 전에 무엇을 함께 약속했는지가 더 중요합니다.

5. How3 : 모든 사람을 통계 전문가로 만들 필요는 없다

세 번째는 교육입니다.

도구와 표준이 갖춰져 있어도, 실험의 기본 원리를 이해하지 못하면 확산은 오래가지 못합니다. 그렇다고 모든 구성원을 통계 전문가로 만들 필요는 없습니다.

제가 실무에서 더 중요하다고 느낀 것은 통계적인 수식을 가르치는 일보다, 결과를 받아들이는 규칙을 함께 익히는 일이었습니다. 무엇을 성공으로 볼지 실험 전에 정하고, 결과가 마음에 들지 않더라도 기준을 함부로 바꾸지 않으며, 핵심 지표가 나빠졌을 때 좋아 보이는 보조 지표 하나만 골라 성공이라고 해석하지 않는 태도입니다.

계산과 분석은 점점 도구와 AI가 대신할 수 있습니다. 하지만 어떤 결과가 나왔을 때 무엇을 할 것인지까지 AI가 대신 정해주지는 못합니다.

그래서 실험 교육의 목적은 모두를 분석가로 만드는 데 있지 않습니다. 서로 다른 직군이 같은 규칙으로 질문하고, 같은 기준으로 결과를 받아들이게 만드는 데 있습니다.

가설, 대조군, 핵심 지표, 보호 지표, 의사결정 기준이 조직 안에서 같은 의미로 사용되기 시작하면, 실험은 더 이상 데이터팀에 넘기는 숙제가 아닙니다. 조직이 함께 사용하는 사고방식이 됩니다.

6. How4 : 권한을 나눴다면 책임도 함께 나눠야 한다

Diffusion에서 자주 빠지는 요소가 하나 더 있습니다. 바로 4번째 운영 방식과 책임입니다.

제가 실무에서 자주 마주한 장면은 이렇습니다. 실험을 시작할 때는 각 팀이 주도하지만, 결과가 애매해지는 순간 판단은 다시 데이터팀으로 돌아옵니다. 핵심 지표와 보조 지표가 서로 다른 방향을 가리키거나, 여러 실험이 같은 사용자 경험에 동시에 영향을 주면 “그래서 어떤 결정을 내려야 하느냐”는 질문이 데이터팀에 몰립니다.

이런 상황을 겪으며 느낀 것은, 실험을 넓힌다는 일이 단순히 생성 권한을 나눠주는 것만으로는 충분하지 않다는 점입니다. 누가 실험을 승인하고 중단할지, 실험이 충돌할 때 누가 우선순위를 조정할지, 지표가 엇갈릴 때 누가 최종 결정을 내릴지까지 함께 정해야 합니다.

이 책임이 명확하지 않으면 실험 권한은 각 팀에 분산되지만, 판단의 책임은 여전히 데이터팀에 남습니다. 실험 수는 늘어나는데 병목은 사라지지 않고, 해석과 검수 요청만 더 복잡해집니다. 결국 확산이라기보다 병목의 위치를 뒤로 옮긴 셈이 됩니다.

좋은 Diffusion은 자율성과 책임을 함께 나누는 일에 가깝습니다. 일반적인 실험은 각 팀이 스스로 운영하되, 위험도가 높거나 여러 팀에 영향을 주는 실험은 중앙 조직이 검토할 수 있습니다. 공통 지표와 플랫폼은 데이터 조직이 관리하되, 가설과 최종 의사결정은 비즈니스 팀이 소유해야 합니다.

제가 생각하는 실험의 확산은 모두에게 버튼을 누를 권한을 주는 일이 아닙니다. 자신이 세운 가설과 그 결과를 받아들이고, 그에 따른 결정까지 책임질 수 있게 만드는 일에 더 가깝습니다.

다음 글에서는 이렇게 확산된 실험을 무엇으로 평가해야 하는지, 그리고 Diffusion의 두 번째 파트에서 데이터 조직의 역할이 어떻게 달라지는지를 이어서 살펴보겠습니다.