스타트업을 위한 '실험'과 '가설' 개념 설명

과학실 뺨치는 스타트업의 세계

스타트업에서 일하는 사람이라면 누구든 '실험'이라는 단어를 말하거나 들은 경험이 있을 겁니다. 회의실에서는 '빠르게 실험해 보자'라는 말이 오고 가고, 스타트업 채용공고의 자격요건란에는 "가설 설정 → 실험 설계 → 빠른 실행을 통해 제품을 발전시킨 경험이 있는 분" 같은 문구가 쓰여 있습니다. 모르는 사람이 보면 '스타트업에는 과학자들이 모여 있나?' 하고 생각할지도 모르겠습니다.

스타트업에서는 어떻게 실험이라는 말이 널리 쓰이게 되었을까요? 아마 린 스타트업(Lean Startup) 방법론이 끼친 영향이 클 것입니다.

린 스타트업 방법론은 과학적 방법론에 강하게 뿌리를 두고 있으며, 실험을 하는 것이 그 핵심 활동이다.
(The Lean Startup method is strongly rooted in the scientific method, and running experiments is a key activity.)
- Ash Maurya의 책 "Running Lean" 중에서

스타트업에서 일하는 사람이라면 누구든 린 스타트업 개념을 접해 본 적이 있을 것입니다. 빠르게 실험해서 가설을 검증하라는 말은 스타트업 업계에서는 금과옥조처럼 받들어집니다.

반면, 실험 개념은 스타트업에서 처음 일하는 분들이 가장 낯설어하는 개념이기도 합니다. 저도 이전에 스타트업에서 일할 때, (대기업에서 오신 분들로부터) '여기서 얘기하는 실험이 도대체 뭔가요?' 하는 질문을 종종 받곤 했습니다. 그리고 스타트업에서 일해 왔던 사람들도 습관적으로 실험을 이야기하지만, 그 의미를 명확하게 정의하지는 못하는 경우도 종종 보곤 했습니다.

가설, 실험, 테스트 등의 용어들을 습관적으로 쓰고 있긴 하지만, 의미를 정확하게 설명해 주는 곳을 찾기는 어렵습니다. 위에서 인용한 책 "Running Lean"에도 "What is an Experiment?"라는 섹션이 있지만, 충분하진 않습니다. 어쩌면 널리 쓰이는 용어일수록 명확한 정의 없이 쓰이게 되기 쉬운 것 같습니다. (다들 일상적으로 쓰는 용어에 관해 질문하면 똑똑하지 않게 보일까 봐 물어보기 어렵기도 하고...)

그래서 이 글에서는 스타트업에서 일하는 분들을 위해 실험과 가설 개념을 뽀개 보려고 합니다. 개념을 정의하기 전에, 실험에 대해 잘못 이해하는 경우부터 바로잡아 보겠습니다.

실험에 대한 오해들

오해 1. 실험은 '그냥 한 번', '가볍게' 해 보는 것?

스타트업에서 일을 하다 보면 '그냥 한 번 가볍게 실험해 보자'라는 말을 듣곤 합니다. (제가 제일 싫어하는 말 중 하나입니다!! 🤯) 이 말에는 두 가지 잘못된 생각이 숨어 있습니다. 하나는 '실험은 가볍게 하는 것이므로, 비용이 적게 든다'라는 생각이고, 다른 하나는 '실험은 가볍고 빠르게 하는 것이므로, 계획이 필요치 않다'라는 생각입니다.

1) 실험은 가볍게 하는 것이므로, 비용이 적게 든다...라는 잘못된 생각

일단 '그냥 한 번 가볍게 해 보는 것'이 절대 가볍지 않다는 것을 알아야 합니다. 몇 시간만 들여서 하면 되니까 가볍게 실험해 보자고 말하는 경우가 있습니다. 이런 말을 입에 달고 사는 사람일수록 우선순위에 대한 고려 없이 무책임하게 아이디어를 막 던지는 사람일 가능성이 높습니다.

업무는 항상 우리가 예상하는 것보다 더 오래 걸릴뿐더러, 실험을 하는 데 들이는 시간만큼 우리는 다른 일을 할 시간을 빼앗깁니다. 기회비용(opportunity cost)을 지불하게 되는 것입니다. 실험을 하자고 말하기 전에, 실험이 기회비용을 상쇄하고도 남을 만큼 우선순위가 높은지 판단하는 작업이 선행되어야 합니다.

만약 프로덕트에서 기능을 개발하는, 그래서 엔지니어가 시간을 투입하는 실험의 경우 더 큰 비용이 듭니다. 개발하느라 쓰이는 엔지니어의 몸값, 그렇게 만든 코드를 나중에 유지보수하는 데 드는 시간, 제품이 복잡해지고 사용성이 나빠짐으로써 치르는 비용 등등... 이런 점을 고려하면 결코 실험이 가볍다고, 혹은 자원이 적게 든다고 말할 수 없습니다.

2) 실험은 가볍고 빠르게 하는 것이므로, 계획이 필요치 않다...라는 잘못된 생각

그리고 실험은 결코 가벼워서는 안 됩니다. 실험이 가벼워야 한다고 생각하는 분들은 부디 조금만 더 무겁게 생각해 주시길 바랍니다. 빠른 실험을 해서는 안 된다는 말을 하려는 것은 아닙니다. 다만 실험을 '가볍게만' 생각해서 '날림'으로 하지는 말자는 말을 하고자 합니다.

가볍게 빠르게 한 번 실험해 보자고 말하는 사람 중 다수는 실험을 제대로 설계하지 않습니다. 실험은 새로운 지식을 획득하기 위한 것인데, 이를 위해 필요한 것들(누구를 대상으로 얼마나 어떤 실험을 할 것인지, 어떤 지표로 성공 여부를 판단할 것인지 등)을 제대로 설계하지 않는 경우가 많습니다.

실험을 하면서 지표를 추적하지 않는 경우도 많습니다. 프로덕트의 경우 일단 기능을 배포한 뒤에 지표 데이터를 분석하지 않고 지나가는 경우가 많습니다. 지표를 추적한다고 하더라도 단기적으로 몇 명이 그 기능을 이용했는지 기능 채택(feature adoption) 지표 정도만 보고 끝나는 경우가 많습니다. 우리의 가설이 맞았는지 틀렸는지를 판단할 수 있는 성공 지표, 프로덕트에 영향을 끼치는지 확인하기 위한 가드레일 지표 등을 설정하지 않는 실험이 수도 없이 많습니다. (성공 지표, 가드레일 지표 등에 대해서는 이 글을 참고해 주세요.)

그리고 실험 후 후속 조치를 제대로 하지 않는 경우도 많습니다. 실험 하나가 끝나면 (주로 프로덕트 기능을 배포하고 나면) 빠르게 실험을 해야 한다면서 다음 액션 아이템으로 넘어가는 거죠. 실험을 면밀히 리뷰하고, 실험을 통해 새롭게 알게 된 것이 무엇인지 정리하지 않습니다. 이러면 조직 차원에서는 얻는 것이 하나도 없습니다. 스타트업에서 일하는 사람들이라면 '실험'이라는 미명하에 이렇게 흘러가 버린 일들을 수없이 봤을 것입니다.

오해 2. 실험을 일단 '많이' 하는 게 무엇보다 중요하다?

빠르게 많은 실험을 하는 것은 중요합니다. 실험의 개수가 많아질수록 성공하는 실험의 개수도 많아지고, 그에 따라 사업도 더 빠르게 성장할 수 있기 때문입니다. 그런데, 질(quality)은 무시한 채 양(quantity)에만 몰두하면 이런 부작용이 생길 수 있습니다.

회사에서는 실험 개수(한 달에 실험 OO개를 한다)를 목표 지표로 설정합니다. 구성원들은 사업 목적을 달성하는 것보다는 할당량을 채우듯이 실험 개수를 늘리는 데만 집중하게 되고, 점점 실험을 위한 실험을 하게 됩니다. 하다 하다 할 게 없어서 버튼 색깔을 바꾸는 실험처럼 별 의미 없는 실험을 하게 됩니다. 업무 담당자들은 '왜 이렇게 무의미한 실험을 해야 하는지 모르겠다'라고 자조하게 되고, 팀 사기가 떨어집니다. 이렇게 되는 이유는, 실험 '개수'에만 집중할 경우 실험할 가치가 있을 만한 가설을 설정하는 과정을 생략하게 되기 때문입니다.

빠르게 실험을 하는 것이 중요한 이유는, 실험을 하는 만큼 우리가 더 많은 정보를 얻게 되기 때문입니다. 실험을 통해 정보를 얻는 것은 명확한 가설이 있는 상태에서 실험을 설계했을 때 가능합니다. 가설도 없고, 실험 설계도 없이 '일단 많이 하는' 것으로는 안됩니다. 실험의 양(quantity)은 중요하지만, 최소한의 질(quality)이 담보되지 않으면 하지 않으니만 못할 수도 있습니다.

실험이란 무엇인가?

그럼 실험이 무엇인지 살펴보겠습니다.

실험(實驗, experiment)은 가설이나 이론이 실제로 들어맞는지를 확인하기 위해 다양한 조건 아래에서 여러가지 측정을 실시하는 일이다. 지식을 얻기 위한 방법의 하나이다. 실험은 관찰(측정도 포함)과 함께 과학의 기본적인 방법의 하나이다. (위키백과)

과학적 실험의 정의이지만, 스타트업에서 하는 실험에도 적용되는 정의입니다. 여기서 핵심은 '실험은 몰랐던 것을 알아내기 위해 (=지식을 얻기 위해) 하는 활동'이라는 점입니다. 실험이라고 이름 붙인 뭔가를 하긴 했는데, 아무것도 알아낸 게 없다면 뭔가 잘못하고 있다는 신호로 받아들여야 합니다. 가설을 명확히 하지 않고, 실험 설계를 하지 않으면 이런 상황에 부닥치게 됩니다.

앞에서 인용한 실험의 정의를 다시 한번 뜯어볼까요? 실험에는 이런 요소들이 있습니다.

1. 가설이나 이론이 실제로 들어맞는지:
   • 실험에는 확인하고자 하는 가설을 세우는 것이 선행됩니다.
   • '가설'이 무엇인지는 잠시 뒤에 설명하겠습니다.
2. 다양한 조건 아래에서:
   • 실험 방법은 다양할 수 있습니다.
   • 검증하는 가설의 종류에 따라서 실험의 형태와 방식은 달라집니다.
3. 여러 가지 측정을 실시하는 일:
   • 측정을 해야 실험입니다. 측정하지 않고 '일단 가볍게 한번 해 보는' 것은 실험이 아닙니다.
   • 정량적인 데이터를 모을 수 있으면 가장 좋지만, 정성적인 피드백을 수집하는 것 역시 좋은 측정입니다.
4. 지식을 얻기 위한 방법의 하나:
   • 실험을 하는 이유는 '우리가 모르는 것을 알아내기 위해서'입니다.
   • '그냥 가볍게 해 보는' 실험으로는 모르는 것을 알아내기 어렵습니다. 실험 설계가 필요합니다.

실험의 예시

이런 것들이 스타트업에서 하는 실험에 해당합니다.

• 제품의 사용자 온보딩(onboarding) 플로우를 변경하는 A/B 테스트: 사용자 중 90%에게는 기존 온보딩 플로우를 보여주고, 10%의 고객에게는 새로운 온보딩 플로우를 보여줘서 어느 쪽에서 더 많은 사용자가 활성화되는지 살펴보는 것도 실험의 일종입니다.
• 가격을 변경하는 A/B 테스트: 트래픽의 50%에게는 기존 가격을 보여주고, 나머지 50%에게는 인상된 가격을 보여줘서, 가격 인상 시 구매 전환율이 어떻게 변화하는지 보는 것도 실험의 일종입니다.
• 아직 개발하지 않은 제품의 수요를 파악하기 위해 랜딩페이지를 만들어서 하는 스모크 테스트(smoke test)도 실험의 일종입니다. 열심히 시간과 자원을 들여서 제품을 개발했는데 수요가 없다면 낭패니까 실험으로 미리 리스크를 줄이는 것입니다. 스모크 테스트는 이런 식으로 진행할 수 있습니다. (퍼블리에 발행한 글에서 인용했습니다)
  1. 아직 제품을 만들지 않은 상태에서, 제품을 소개하는 웹 페이지를 하나 만듭니다.
  2. 페이지에는 '이 제품에 관심 있는 사람들은 이메일 주소를 입력해 주세요. 제품에 대한 정보를 보내 드립니다'와 같은 문구를 씁니다.
  3. 얼마나 많은 사람이 관심을 보이는지 파악합니다. 많은 수의 사람이 이메일 주소를 입력한다면, 시장이 존재한다는 뜻입니다.
  4. 이 페이지에 사람들을 유입시키기 위해 페이스북이나 구글 등에 광고를 소액 집행하기도 합니다.
• 기술을 개발하기 전에 일단 수작업으로 서비스를 제공함으로써 제품에 수요가 있는지 알아보는 '메커니컬 터크(Mechanlcal Turk)', 혹은 '오즈의 마법사(Wizard of Oz)' 프로토타입
  • 특히 기술적으로 복잡한 솔루션을 만들려고 하는 경우, 많은 시간과 자원을 투입해서 기술을 개발했는데 제품에 대한 수요가 없다면 낭패입니다.
  • 이런 경우 미리 수요를 알아보기 위해 수작업으로 테스트를 할 수 있습니다.
  • 예를 들면, 구글이 인수한 Q&A 플랫폼 Aardvark는 사용자들이 질문을 올리면 적합한 전문가를 매칭해서 답변을 제공해 주는 서비스인데, 초반에는 머신러닝과 같은 기술을 사용하지 않고 직원들이 직접 질문에 맞는 전문가를 매칭했다고 합니다. 그러면서 값비싼 기술을 개발하지 않고도 제품에 대한 수요를 알아볼 수 있었습니다. (출처)

가설: 실험의 중심에 있는 것

앞에서 실험을 제대로 하기 위해서는 가설을 명확히 설정해야 한다고 반복해서 이야기했습니다. 그런데 가설이란 무엇일까요?

퍼블리에 발행한 '가설 검증은 비즈니스의 기본이다' 에서 저는 가설에 대해 다음과 같이 설명했습니다.

"가설이란, 어떤 문제나 사안에 대해서 우리가 가진 추측을 가리킵니다. 가설이 '사실'이 아니라 '추측'인 이유는 아직 사실 여부를 판단할 근거가 충분하지 않기 때문입니다. 가설을 사실로 받아들이기 위해서는, 가설을 입증하는 충분한 근거가 모여야 합니다.

처음 사업을 시작하는 스타트업이 시장과 고객, 제품 등에 대해서 가진 생각은 모두 가설에 불과합니다. 대표적으로 이런 가설들이 있습니다.

- 고객 가설: 우리의 타깃 고객은 어떤 사람들인지
- 문제 가설: 고객들은 어떤 문제를 가졌는지
- 시장 규모 가설: 이런 문제를 가진 고객의 규모(시장 규모)가 얼마나 큰지
- 솔루션 가설: 고객들의 문제를 해결하기에 가장 좋은 방법은 무엇인지

아무 근거 없는 허무맹랑한 생각만으로 시작하는 스타트업은 드물겠지만, 어쨌든 이 생각들은 각자 가진 지식과 경험에 근거한 추측(educated guess)에 불과합니다. 스타트업은 사업을 하면서 가설이 사실인지 여부를 확인해야 합니다.

이 글을 쓰고 1년여가 지났는데, 그사이 가설 개념에 대해 제가 가진 생각도 조금 바뀌었습니다. 위에서 얘기한 추측(educated guess)은 엄밀히 말하면 가설(hypothesis)이라기보다는 가정(assumption)입니다. 우리는 가설과 가정 개념을 뭉뚱그려서 '가설'이라는 이름으로 부르곤 하는데, 두 개념을 구분하면 생각을 조금 더 명확하게 할 수 있습니다.

가설(hypothesis)과 가정(assumption) 구분하기

앞에서 이야기했듯, 우리는 비슷하지만 다른 두 가지 개념을 뭉뚱그려서 가설이라고 부릅니다.

• 실험을 통해 반증 가능한 구체적이고 명시적인 진술, hypothesis 개념을 가리킬 때도 가설이라는 단어를 쓰고
• 가설과 달리 반증 가능한 형태로 진술되지 않은 암묵적인 믿음이나 추측, assumption 개념을 가리킬 때도 가설이라는 단어를 씁니다.

그래서인지 실험 계획을 세울 때 가설(hypothesis) 대신에 가정(assumption)을 쓰게 되는 경우가 종종 생깁니다. '랜딩페이지를 개선하면 전환율이 증가할 것이다' 정도로 가설을 세우는 거죠. 이런 가정은 실험으로 반증하기 어렵습니다. 랜딩페이지를 어떻게 바꾸는 것이 개선인지, 전환율이 증가한다는 것은 어느 정도인지 등에 대해서 명확하게 정의하지 않았기 때문입니다.

그래서 저는 가설(hypothesis)과 가정(assumption) 개념을 구분해서 쓰기를 제안합니다. 가설과 가정은 이렇게 정의해 볼 수 있겠습니다.

• 가설(Hypothesis)
  • ‘광고 랜딩페이지를 기존의 A에서 B로 변경하면, 랜딩페이지가 A일 때보다 회원가입 전환율이 15% 이상 증가할 것이다’라는 식으로 반증 가능한 구체적인 진술입니다.
  • 반증 가능하다는 것은 다시 말해 실험을 통해서 거짓이라는 것을 입증할 수 있다는 것입니다. (실험을 해 보면 위 문장이 사실인지 아닌지 알 수 있습니다)
  • 우리가 실험을 계획할 때는 이런 식으로 구체적인 가설을 세워야 합니다.
• 가정(Assumptions)
  • 우리가 고객, 시장 등에 대해 가지고 있는 추측입니다.
  • 가정에는 다양한 유형이 있습니다. 예를 들면 이런 것들입니다.
    • ‘우리 잠재 고객은 OOOO라는 문제를 가지고 있을 것이다’
    • ‘OOOO라는 문제를 가지고 있는 사람이 많을 것이다.’
    • ‘고객이 OOO로 전환하지 않고 이탈하는 이유는 OOOO일 것이다.’
    • ‘잠재 고객에게 도달하는 마케팅 채널로는 OOO 채널이 효과적일 것이다.’
  • 가설처럼 반증 가능한 구체적인 형태로 만들어지지는 않은, 암묵적인 믿음입니다.
  • 우리는 이 믿음과 추측이 아직 사실인지 아닌지 모릅니다. 사실이 아닌 가정을 믿고 많은 시간과 자원을 투입했다가는 비용을 낭비할 위험(risk)이 있습니다.
  • 가정이 사실인지 아닌지 확인하기 위해 우리는 실험을 합니다. 특히 시간과 자원이 제한된 스타트업에서는 실험이 중요합니다.

가정(assumption)을 검증하기 위해 가설(hypothesis)로 변환하기

앞에서 설명한 실험, 가설, 가정 개념을 서로 연결 지어 보면 이렇게 정리할 수 있습니다.

• 우리가 실험을 하는 목적은 모르는 것을 알아내는(=지식을 얻는) 것입니다.
• 특히 스타트업은 여러 가정들(아직 검증되지 않은 추측과 믿음, 즉 assumption) 위에서 움직입니다.
• 검증되지 않은 가정들을 믿었다가는 많은 시간과 자원을 낭비할 위험(risk)이 있습니다. 스타트업은 시간과 자원을 적절히 투입해서 가정을 검증하기 위해 실험을 합니다.
• 우리는 특히 위험성(risk)이 큰 가정을 검증해야 합니다. 위험성이 큰 가정이란, 만약 참이 아닌 경우 사업 혹은 액션아이템이 실패할 가능성이 높아지는 가설입니다.
• 실험을 하려면 실험 설계가 필요합니다. 특히 실험 설계의 중심에는 가설 설정이 있습니다.
• 가설 설정이란, 암묵적인 믿음인 가정(assumption)을 반증 가능하고 구체적인 형태의 가설(hypothesis)로 만드는 것입니다.

일을 하다 보면 특히 마지막 포인트인 '가정을 가설로 변환하기'를 간과하게 되기 쉽습니다. 우리가 뭔가 액션 아이템을 구상할 때는, 수많은 가정(assumption)들을 깔게 됩니다. 암묵적인 믿음인 가정을, 실험으로 테스트할 수 있는 명시적인 가설로 변환해서(making implicit assumptions explicit) 테스트하지 않으면, 우리는 그만큼 위험에 노출되게 됩니다.

예시) 가정(assumption)을 명시적인 가설(hypothesis)로 만들어 검증하기

예를 들어서 설명해 보겠습니다. 음식 배달을 필요로 하는 소비자들과 음식 배달을 제공하는 식당(공급자)들을 매칭시키는 양면시장(two-sided marketplace) 플랫폼이 있습니다. 이 플랫폼 업체에서는 공급자인 식당의 리텐션(retention, 잔존율) 지표를 개선하는 것이 중요한 과제입니다.

공급자를 담당하는 팀원 중 한 명이 '식당 사장님들에게 유용한 정보를 제공하는 유튜브 채널을 만들어서 운영하자'라는 아이디어를 냅니다. 유튜브 채널을 만들면 공급자들이 계속해서 이 플랫폼을 이용하게 될 거라면서요.

만약 이 팀이 실험을 하지 않는 팀이라면 즉시 유튜브 채널을 운영하기 시작할 것입니다. 유튜브 채널을 만들고, 출연자를 섭외하고, 영상을 촬영 및 편집하고, 영상을 더 많이 보게 만들기 위한 홍보를 하고 등등... 만약 이렇게 해서 좋은 결과(이 경우 리텐션 지표 개선)가 나오면 다행이지만, 지표 개선에 실패하는 경우 팀 입장에서는 손해가 크게 됩니다.

만약 이 팀이 실험을 적극적으로 하는 팀이라면, 조금 다르게 접근할 것입니다. 일단 '유튜브 채널을 만들어서 운영하면 리텐션 지표가 개선될 것이다'라는 것이 하나의 커다란 가정(assumption)이라는 것을 알아차리고, 이 가정이 사실에 얼마나 부합하는지 검증하려고 할 것입니다.

실험을 적극적으로 하는 팀은 커다란 가정 아래 더 많은 암묵적인 가정들이 더 많이 깔려 있음을 알아차립니다. 이 가정들이 모두 참이 되어야만 리텐션 지표 개선이라는 목표를 이룰 수 있습니다.

1. 공급자들이 우리가 제공하고자 하는 정보를 필요로 할 것이다.
   (이 가정이 참이 아닌 경우, 우리 채널은 실패할 가능성이 크다.)
2. 공급자들의 눈높이에 맞는 영상을 우리 팀이 만들어낼 수 있을 것이다.
   (이 가정이 참이 아닌 경우에도 우리 채널은 실패할 가능성이 크다.)
3. 공급자들은 정보에 대한 필요를 다른 곳이 아닌, 우리 플랫폼에서 운영하는 채널에서 충족시키고자 할 것이다.
   (이 가정이 참이 아닌 경우, 만약 공급자들이 이미 다른 곳에서 충분히 필요를 충족시키고 있을 경우, 우리 채널의 성공 가능성은 작아진다.)
4. 공급자 유저들 중 상당수가 이 유튜브 채널에서 영상을 시청할 것이다.
   (이 가정이 참이 아닌 경우, 공급자들 중 소수만 유튜브 채널을 보게 될 것이고, 그러면 리텐션 지표에 끼치는 영향은 미미해진다.)

이 가정들 중 1번 가정은 특히 위험성(risk)이 높습니다. 만약 이 가정이 참이 아니라면, 즉 공급자들이 별로 정보를 필요로 하지 않는다면 유튜브 채널을 만들고 운영하는 것 자체가 의미 없기 때문입니다.

이런 가정은 어떻게 검증해 볼 수 있을까요? 꼭 유튜브 채널을 운영하는 형태로 실험을 할 필요는 없습니다. 공급자들이 얼마만큼 정보를 필요로 하는지 알기 위해 인터뷰나 설문조사를 해 볼 수도 있고, 수요를 검증하기 위해 스모크 테스트(smoke test)를 해 볼 수도 있습니다.

만약 인터뷰로 검증한다면 이런 식으로 인터뷰를 해 볼 수 있습니다. (이 경우 인터뷰가 실험의 한 종류입니다.)

• 가정(assumption): 공급자들은 우리가 제공하고자 하는 정보를 필요로 할 것이다.
• 가설(hypothesis): 공급자를 20명 만나서 인터뷰를 했을 때, 10명 이상은 정보 부족에서 실질적인 문제를 느낀다고 이야기할 것이다.
  • '20명 중 10명 이상'은 물론 객관적이고 절대적인 기준이라고 할 수는 없습니다. 하지만 스타트업에서 실험을 할 때는 '모래 위에 선 긋기' 식으로 기준을 정할 필요가 있습니다. 더 자세한 내용은 <린 분석> 책, 혹은 이 아티클을 참고해 주세요. https://leananalyticsbook.com/1000-how-were-validating-the-opportunity-for-lean-analytics-book/
• 실험: 플랫폼을 이용하고 있는 공급자 20명을 무작위로 선정해서 1대1로 인터뷰한다.
  • 단, '정보 부족이 문제라고 느끼나요'와 같은 유도 질문은 하지 않는다.
  • 평소에 식당을 운영하면서 느끼는 문제들을 Stack Rank 하는 식으로 인터뷰를 진행한다.
  • '정보 부족'에 해당하는 문제가 3위 안에 드는 경우, 정보 부족에서 실질적인 문제를 느끼고 있는 것으로 간주한다. (이것 역시 '모래 위에 선 긋기'입니다.)

다른 가정들도 마찬가지로, 유튜브 채널을 만들지 않은 채로 (다시 말해, 자원을 크게 들이지 않고) 검증해 볼 수 있습니다. 가정이 얼마나 사실에 부합하는지 검증하는 데 필요한 만큼의 실험을 얼마든지 해 볼 수 있습니다.

정리하자면 이렇습니다.

• 우리가 뭔가 액션 아이템에 대해서 생각할 때는, 그 밑에 여러 가정(assumption)들을 암묵적으로 깔고 있습니다.
• 그 가정들이 참이 아닌 경우, 액션 아이템은 실패할 수 있습니다. 즉, 가정에는 위험성(risk)이 따릅니다.
• 가정들 중 특히 위험성이 높은 것들은 꼭 실험을 통해 검증해야 합니다.
• 이를 위해서는 암묵적인 가정들을 명시화해서 가설로 변환하는 작업이 필요합니다. 반증 가능한 가설로 변환한 뒤에야 실험을 할 수 있습니다.

실험군과 대조군, 꼭 필요할까?

얼마 전에 한 미팅에서 실험 개념(위와 같은)을 이야기하는데, 팀원 한 분이 저에게 질문했습니다. "실험을 할 때는 실험군과 대조군을 설정해야 하지 않나요? 그렇지 않으면 지표에 변화가 있더라도 실험 때문이라고 확신할 수 없지 않나요?" 하고요.

여기서 팀원분이 말한 것은 엄밀한 의미에서의 실험인 통제된 실험(controlled experiment)입니다. 통제된 실험이란 "실험군과 대조군을 설정해서, 실험군과 대조군 사이에 서로 다른 처치(treatment)를 하되, 그 처치를 제외한 다른 변인에는 차이가 없도록 해서 (이를 변인 통제라 합니다), 그 처치가 결과에 영향을 미치는지 확인하는 연구 방식"입니다.

A/B 테스트와 같은 실험이 통제된 실험의 한 종류입니다. 통제된 실험은 실험으로 한 처치(treatment)가 결과에 영향을 끼치는지, 인과관계를 파악할 수 있다는 장점이 있습니다. 실험 처치를 제외하고는 다른 변수에 차이가 없으니, 실험군과 대조군에서 차이를 보이는 원인은 실험 처치밖에 없다고 보는 것이죠.

반면, 앞에서 언급한 메커니컬 터크(Mechanical Turk) 또는 오즈의 마법사(Wizard of Oz), 스모크 테스트와 같은 실험은 변인 통제를 하는 실험은 아니기 때문에 인과관계를 파악할 수는 없습니다. A/B 테스트처럼 객관적인 판단 기준(통계적 유의미성, p-value 개념 등을 활용한)을 세우기도 어렵구요.

그럼 스타트업도 실험을 할 때는 꼭 실험군과 대조군을 설정해서, 모든 변수를 잘 통제해서 해야만 할까요? 저도 예전엔 그렇게 생각했는데, 지금은 꼭 그럴 필요는 없다고 생각합니다. 왜냐면 스타트업이 실험을 하는 목적은 '완벽한 실험'을 하는 데 있는 것이 아니라, 의사결정을 위한 정보를 얻는 데 있기 때문입니다. 지금 저는 이런 식으로 생각합니다.

• 실험은 새로운 지식과 정보를 얻기 위해 하는 것입니다.
• 스타트업의 맥락에서 다시 얘기하면, 실험의 목표는 의사결정을 위한 정보를 확보하는 것입니다.
• 아무 정보 없이 가정(assumption)만 가지고 의사결정을 하기에는 위험성(risk)이 크므로, 가정이 얼마만큼 사실에 부합하는지 검증하는 것입니다.
• 그런데, 우리는 불확실한 세상에 살고 있어서 100퍼센트 확실한 정보를 가지고 의사결정을 할 수는 없습니다. 100퍼센트 확실한 정보를 가질 때까지 기다리는 것은 의사결정의 속도를 늦추기 때문에 바람직하지도 않습니다.
• 우리가 실험에 기대하는 것은 100퍼센트 확실한 정보가 아니라, 의사결정에 자신감을 더할 수 있는 만큼의, 꼭 필요한 만큼의 정보(just enough information)입니다.
• 변수를 잘 통제한 실험을 할 수 있으면 물론 좋겠지만, 스타트업은 실험실이 아닌 현실세계에서 사업을 하고 있기 때문에 모든 실험을 통제된 실험으로 할 수는 없습니다.
• 검증하고자 하는 가정에 따라서, 검증 방법(실험 방법)은 달라집니다. 변수를 통제한 실험을 해야 할 수도 있고, 유저 인터뷰를 할 수도 있고, 스모크 테스트나 메카니컬 터크 실험을 할 수도 있습니다.
• 중요한 것은 완벽하게 통제된 실험을 하는 것이 아니라, 가정이 얼마나 사실에 부합하는지 확인함으로써 리스크를 낮추는 것입니다.

마무리 & 요약

실험과 가설이라는 커다란 개념을 다루려고 욕심을 내다 보니, 글 한 편에서 여러 이야기를 했습니다. 글에서 다룬 개념들을 머릿속에서 정리하실 수 있도록 요약을 해 보겠습니다. 긴 글 읽어 주셔서 감사하고, 궁금하신 점이 있으면 언제든 메일 보내 주세요!

• 스타트업에서는 실험을 강조하는데, 실험이란 말을 잘못 쓰는 경우들이 있다.
• 실험이란 무엇인가? 몰랐던 것을 알아내기 위해 하는 활동이다.
• 실험의 중심에는 가설이 있다.
• 가설이란 무엇인가? 우리가 사업, 시장, 고객 등에 대해 가지고 있는 추측이다... 라고 퍼블리에 발행한 글에서 설명했는데, 이건 엄밀히 얘기하면 가설(hypothesis)이라기보다는 가정(assumption)이다.
• '가설'이란 말이 보통은 hypothesis와 assumption 두 가지 개념을 모두 가리키는 말로 쓰이는데, hypothesis와 assumption을 구분해서 생각하는 것이 좋다. 가정은 사실이라고 믿는 추측 혹은 추정을 가리킨다. 가설은 그 추측을 실험으로써 반증 가능하게 만든 진술을 가리킨다.
• 우리가 실험을 하는 것은... 우리가 참이라고 믿는 가정(assumption)을 반증 가능한 가설(hypothesis)로 만들고, 이를 테스트하는 것이다. 가정이 참이라고 믿고 그냥 전면적으로 진행했다가는 팀이 가진 소중한 시간과 자원을 낭비하게 될 수 있으니까.
• 많이 간과되는 것: making implicit assumptions explict. 우리가 뭔가 액션 아이템에 대해서 생각할 때, 그 밑에 있는 assumption이 여러 가지 있다. 액션 아이템이 성공하려면 그 가정들이 참이 되어야 한다. 묵시적인 가정들을 explicit하게 만들어야 한다. 각각의 가정들이 얼마나 risky한지 평가하자. 그리고 risky한 가정들은 꼭 실험으로써 테스트하자. 테스트할 때는 testable한 형태의 hypothesis로 바꾸자.
• 그럼 실험을 할 때는 꼭 실험군과 대조군을 설정해서, 통제된 환경에서 해야 할까? 나도 예전엔 그렇게 생각했는데, 꼭 그럴 필요는 없다고 생각한다.
• 실험을 하는 목적은 의사결정에 자신감을 더하기 위한 정보를 얻는 것이다. 이런 측면에서 생각하면. 어차피 100퍼센트 확신을 갖고 의사결정을 할 수는 없기 때문에. 의사결정에 필요한 만큼의 정보(just enough information)만 확보하면 된다.
• 검증하고자 하는 가설에 따라서, 가설을 검증하는 (실험) 방법은 달라진다. 변수를 통제한 실험을 해야 할 수도 있고, 유저 인터뷰를 할 수도 있고, 등등. 중요한 것은 의사결정에 필요한 만큼의 정보, just enough information을 확보하는 것이다.

(2024.05.12 업데이트: 가설과 실험 개념 등을 비롯해 PM/PO들에게 필요한 기반 지식을 꾹꾹 눌러 담은 강의를 시작했습니다. 아래 링크를 클릭해서 강의를 살펴보실 수 있어요. 이 글에서 더 많이 업데이트된 내용이 담겨 있습니다.)

시작하는 PM/PO들에게 알려주고 싶은 모든 것 | 김민우 - 인프런

김민우 | 프로덕트 매니저(PM/PO)로서의 전문성을 키우고 싶은 분들에게 알려주고 싶은 모든 것을 꾹꾹 눌러 담았습니다., ‘물경력’ 또는 ‘잡부’가 아닌, 전문성 있는 PM/PO 되기프로덕트 매니저(PM/PO)는 고유의 전문성을 제품 조직에 기여할 수 있는 직군입니다.…

인프런