9주차) 01 - 실험, 실험 설계

실험에 대한 이해

• PM에게 실험은 점점 필수적인 역량으로 여겨지고 있다.
• 실험은 가설이나 이론이 실제로 들어맞는지를 확인하기 위해 다양한 조건 아래에서 여러 가지 측정을 실시하는 일이고 지식을 얻기 위한 방법의 하나이다.
• 실험은 관찰과 함께 과학의 기본적인 방법의 하나이다.
• 관찰이 대상 그 자체를 있는 그대로 알아보는 일이라면 실험은 어떤 조작을 가해 그에 따라 일어나는 변화를 조사하고 결론을 내는 일이다.
• 스타트업에서의 실험은 린 스타트업 방버론의 핵심적인 내용으로 실험을 통해 '만들기 - 측정 - 학습'의 과정을 거치며 지속 가능한 사업을 구축해 나가는 것을 의미한다.

실험의 예시

• 회원가입 A/B Test
  • 회원가입 시 Funnel 개선을 진행하여 사용자 중 50%는 개선된 화면을 나머지 50%에게는 기존 화면을 노출하고 어떤 그룹에서 회원가입 완료 비율이 높았는지 확인해 보는 실험
• 랜딩 페이지 A/B Test
  • 제품 판매 랜딩 페이지를 변경하여 사용자 중 30%에게는 변경된 랜딩 페이지를 나머지는 70%에게는 기존 랜딩 페이지를 노출하고 어떤 그룹에서 결제 전환율이 높았는지 확인해보는 실험

실험의 중요성

• 고객 및 시장에 대한 정확한 학습
  • 명확한 데이터를 통해 고객과 시장이 원하는 바를 분명히 할 수 있다.
  • 학습은 유저 인터뷰를 통해서도 가능하지만 데이터는 이를 더 정확하게 보여준다는 점에서 차이가 있다.
• 자본 효율적 방식
  • 고객 및 시장에 대한 정확한 학습을 바탕으로 개발되는 제품은 그렇지 않은 제품에 비해 성공 확률이 훨씬 올라간다.
  • 실험을 하는 과정에서 불필요한 제품을 만드는데 들어가는 시간과 인력을 최소화할 수 있다.

실험에 대한 오해

• 실험은 간단하다.
  • 실험 또는 Test라는 단어로 인해 실험이 정식 출시보다 비용(시간 + 인력)이 적게 들 것이라는 착각
  • 유의미한 실험을 위해 진행하는 실험은 오히려 정식 출시보다 리소스가 더 많이 들 때도 있다.
  • 간단한 실험의 경우 실험 후 아무런 Insight를 얻지 못하는 경우가 발생할 수 있기에 내가 하려고 하는 실험이 정말 시간을 들일만 한지 Impact와 우선순위를 검토해볼 필요가 있다.
• 실험은 빨라야 한다.
  • 시간은 곧 비용이기 때문에 빠르게 유의미한 실험을 해보는 것은 매우 중요하다.
  • 하지만 모든 실험이 무조건 빠르게 끝나는 것은 아니다.
  • 하려고 하는 실험에 따라 혹은 제품의 상황에 따라 실험의 기간이 달라질 수 있다.
    예) 월간 재방문율에 관련한 실험을 하고 싶다면 실험 기간은 최소 한 달 이상이 되어야 한다.
• 모든 것을 실험해야 한다.
  • 실험을 통해 고객에 대해 다양한 학습을 하며 제품을 발전시켜 나가는 것은 매우 중요하다.
  • 하지만 첫번째에서 언급했듯이 실험을 하기 위해서는 그만큼 비용이 발생하기에 모든 것을 실험해 보면서 가는 것은 오히려 비효율적일 수 있다.
  • 투입하는 비용 대비 실험을 통해 얻을 수 있는 Insight가 많은지 비교를 해봐야 하며 실험을 하지 못하는 경우 유저 인터뷰 등 다른 방식을 통해 제품과 관련된 지식을 얻을 수 있도록 해야 한다. 

실험 프로세스

 

가설이란

• 가설은 실험을 통해 반증 가능한 구체적이고 명시적인 진술이다.
• 예) 현재 3단계로 구성된 회원가입 Flow를 1단계로 줄이면 회원가입 전환율이 10% 상승할 것이다.
  예) 상품 랜딩 페이지에 고객들이 만족한 후기를 추가한다면 구매 전환율이 5% 상승할 것이다.

가설과 가정의 차이

• 가정은 반증 가능한 형태로 진술되니 않은 암묵적인 믿음이나 추측이다.
• 예) 고객들은 회원가입 과정이 너무 길다고 느낄 것이다.
  예) 고객들은 다른 사람들의 후기를 보고싶어 할 것이다.

가설을 수립하는 방법

• 가정을 가설로 변환하기
  • 실험을 통해 반증 가능한 형태로 -> 어떤 지표가 어떻게 변할 것인지
  • 구체적이고 명시적으로 -> 제품을 어떻게 변화를 시킬 것인지
• xyz가설 템플릿 활용하기
  • 적어도 x퍼센트의 y는 z할 것이다.
  • 예) 적어도 10%의/ 대기질 지수가 100 이상인 도시에 사는 사람들은/ 120달러짜리 휴대용 오염 탐지기를 구매할 것이다.

실험 설계하기

• 실험 설계 항목
  • 실험 대상
    • 실험을 진행할 타겟 고객
    • 테스트할 가설에 따라 다르지만 일반적으로 아래와 같은 항목이 포함된다.
        1. 앱 서비스인 경우 Android/IOS 앱 최소 버전
        2. 앱 내에서 수집하는 유저의 인구통계학 정보(나이, 성별, 지역 등)
  • 실험 기간
    • 정확한 표현을 위해 실험 시작 날짜와 종료 날짜를 명확하게 표시해 주는 것이 좋다.
        1. 실험 시작 일자: 2023.11.27 00:00 KST
        2. 실험 종료 일자: 2023.12.26 23:59 KST
        3. 실험 진행 기간: 30일
    • 실험 관련 개발 및 테스트 진행 상황에 따라 실험 기간이 변경될 수 있으며 실험 진행 중 다른 요인(샘플 사이즈가 충분히 확보되지 않음 등)에 의해 실험 기간이 조정될 수 있다.
  • 조작 변인
    • 가설을 검증하기 위해 실험군과 대조군 간 변화를 주는 요소이다.
    • 조작 변인은 여러 개가 될 수 있으며 조작 변인이 늘어날 수록 실험군의 개수도 늘어나게 된다.
    • 주로 이 부분을 어떻게 설정하느냐에 따라 실험을 위한 개발 리소스(인력 + 시간)가 어느 정도 들지가 달라지게 된다.
  • 인원(Sample Size)
    • 몇 명의 인원에게 실험할지이다.
    • 실험군과 대조군에는 동일한 인원이 배정되어야 한다.
    • 전체 서비스 대상 유저에게 실험할 수도 있지만 많은 고객에게 서로 다른 경험을 주는 것에 대한 위험도 있기 때문에 적절한 Sample size를 결정하여 실험하는 것이 바람직하다.
  • 성공 지표(Success Metric)
    • 실험의 목표가 되는 지표이자 실험의 성공/실패를 판단하는 지표이다.
    • 보통은 특정 지표를 증가시키고자 하는 것이 일반적이다.
    • 지표에 대한 정의와 함께 목표 숫자까지 설정하는 것이 좋다.
      예) 회원가입 전환율 2% 상승 (회원가입 전환율: 앱 설치 후 24시간 이내에 회원가입을 완료한 비율)
  • 가드레일 지표(Guardrail Metric)
    • 실험으로 인해 영향을 받아 안좋아지면 안 되는(최소한 현재 수준을 지켜야 하는) 지표이다.
    • 어떤 실험을 할 때 특정 지표에 안 좋은 영향을 줄 수 있기 때문에 이럴 것으로 예상되는 지표가 있다면 이 지표를 가드레일 지표로 설정하고 모니터링하는 것이 필요하다.
    • 가드레일 지표가 설정해 놓은 기준 이상으로 영향을 받는다면 실험을 중단할지에 대한 고려도 미리 해봐야 한다.
      예) 구매 전환율을 높이는 실험에서 앱 내 구매 유도를 많이 하다 보면 사용자에게 부정적인 영향이 갈 수 있다. -> Daily Retention을 가드레일 지표로 설정하고 모니터링할 필요가 있다.
  • 보조 지표 - 필수는 아니다.
    • 실험이 영향을 주는 참고성 지표이다.
    • 어떤 실험을 할 때 성공 지표를 올리고자 설계한 것이 성공 지표가 올라감으로써 연관이 있는 다른 지표에도 영향을 줄 수 있다.
    • 이렇게 영향을 받을 수 있는 지표들 중 모니터링하고 싶은 지표들을 선택하여 같이 모니터링 하면 실험을 통해 더 많은 Insight를 얻을 수 있다.
      예) Daily Retention을 높이는 실험을 위해 앱에서 유저가 사용할 수 있는 다양한 기능 마련 -> 이로 인해 '체류 시간' 지표도 같이 올라갈 수 있다.

실험 설계 항목과 유의 사항

• 실험 대상
  • 실험을 하려는 목적과 실험의 대상이 일치하는지 확인해야 한다.
  • 예를 들어 신규 가입 유저의 활성도를 위한 목적의 실험을 진행한다고 했을 때 다음과 같이 실험 대상을 정할 필요가 있다.
    예) 가입 후 7일이 되기 전의 유저
  • 가입 후 7일이 지난 유저에게 실험을 노출하게 되는 경우 실험에 적합하지 않은 유저의 데이터가 들어와 Bias가 생길 수 있으며 유저에게도 부정적인 경험이 갈 수 있다.
• 실험 기간
  • 실험 기간이 너무 짧은 경우 데이터 분석 시 실험 기간으로 인한 Bias가 발생하거나 통계적 유의성을 확보하지 못해 실험이 무의미해지는 경우가 발생할 수 있다.
  • 실험이 너무 길어지게 되는 경우 유저에게 서로 다른 경험을 제공하는 시간이 길어지는 위험이 있고 다른 실험을 하지 못하게 되는 상황도 발생할 수 있다.
  • 적절한 실험 기간을 설정하는 것이 중요하다.
  • 실험 기간을 설정할 때는 서비스의 특성과 통계적 유의성이 확보될 수 있는지를 고려하여 조정이 되어야 한다.
  • 서비스 특성의 경우 서비스마다 이용 주기에 차이가 있어 발생하게 된다.
    예) 매일 접속하는 SNS 서비스 vs 1주일에 한 번 이용하는 세탁 서비스
  • 요일별(주중/주말)로 편차가 발생할 수 있기 때문에 실험 기간을 최소 1주 이상으로 잡는 것이 좋다.
  • 샘플 사이즈가 크다면 실험 기간이 짧아도 문제가 없지만 샘플 사이즈가 작다면 실험 기간을 최소 2주로 두고 2주 후 통계적 유의성이 확보되지 않았다면 실험 기간을 조정하는 것이 좋다.
• 조작 변인
  • 조작 변인을 설계할 때 실험을 진행하려는 가설이 조작 변인을 통해 검증될 수 있는지 확인이 필요하다.
  • 조작 변인 외에 다른 부분에서는 변화가 있지 않도록 설계 시 주의를 기울여야 한다.
• 성공 지표
  • 성공 지표를 고를 때는 어떤 것의 결과가 되는 지표가 아니라 그 지표를 구성하고 우리가 변화를 만들 수 있는 지표를 고르는 것이 좋다.
  • 아래 매출을 예시로 들어보면 매출이라는 지표는 '사용자 수'와 '결제 전환율'의 곱으로 구성이 되므로 우리가 변화를 주고자 하는 지표를 둘 중 하나로 고르는 것이 좋다.
    예) 사용자 수 X 결제 전환율 = 매출

실험 개발 및 배포/실험 진행하기

• 실험 설계 이후 프로세스

• PM은 개발 시 확장성 고려해야 한다.
  • 단발성 실험이 아닌 이번 실험의 결과에 따라 후속 실험이 추가로 필요하다고 판단되는 경우에 해당한다.
  • 위와 같은 경우에 개발자와 미리 커뮤니케이션을 진행해 후속 실험에 대한 계획을 간단하게라도 공유해 복잡도가 적고 확장성이 있는 방식으로 개발을 하는 것이 좋다.
  • 이를 통해 후속 실험 시 개발 리소스가 적게 들거나 이번 실험에서 한 개발로 후속 실험 시 리소스가 지나치게 많이 드는 상황을 방지할 수 있다.
• PM은 실험 시작 전 모니터링 대시보드 세팅해야 한다.
  • 실험이 시작된 후 PM이 지속적으로(1일 1회) 확인해야 하는 것은 바로 대시보드이다.
  • 대시보드를 통해 실험이 잘 진행되고 있는지 어떻게 진행되고 있는지를 확인할 수 있다.
  • 때문에 실험이 시작된 후 지표를 편하게 파악하기 위해서는 대시보드 세팅을 실험 시작 전 미리 해놓는 것을 추천한다.
• 유관 부서 커뮤니니케이션
  • Product Team
    • 실험을 위해 내가 담당하는 기능 외에 다른 PM이 담당하는 기능에도 영향이 가는 상황이라면 해당 기능 PM과 커뮤니케이션을 진행 후 실험에 대해 우려사항이 없는지 합의를 진행해야 한다.
      예) 실험을 위해 다른 PM이 담당하고 있는 '홈 화면'에 변화가 필요한 경우
    • 위의 커뮤니케이션은 상세 PRD 및 디자인 완료 후 실제 개발이 들어가기 전에 진행하는 것이 바람직하다.
    • 추가적으로 실험 시작 후 혼선을 방지하기 위해 실험에 대한 내용을 Product Team 전체에게 알리는 것이 좋다.
  • Product Operation Team
    • 실험 진행 중 Operation Team에서 모니터링 하고 있는 지표에 변화가 가거나 유저에게 관련된 문의 사항이 올 수 있으므로 실험 진행 전 미리 Product Operation Team과 커뮤니케이션을 진행해야 한다.
    • 실험 관련된 문의 사항에 대해 Operation Team과 협업하여 미리 예상 질문과 답변을 마련해 놓는다면 이런 상황이 발생했을 때 쉽게 대처할 수 있다.
  • Back office Part(Legal & Finance)
    • 실험 설계 상황에 따라 Back office Part와 커뮤니케이션해야 하는 상황이 있을 수 있다.
    • 특히 진행하고자 하는 실험이 유저의 개인 정보를 다루는 등 법률적인 검토가 필요하다면 실험 설계 전에 미리 생각하고 있는 내용을 검토받는 것이 바람직하다.
    • 법률 검토를 받지 않고 프로세스를 진행하다 나중에 이슈가 발생하는 경우 실험 설계부터 다시 진행해야 하는 일이 발생할 수 있으므로 주의가 필요하다.
    • 이 외에 매출 관련 실험을 하는 경우 Finance Team에게 실험 내용일 미리 공유하는 것이 바람직하다.

실험 개발 및 진행 시 주의사항 - 실험을 진행했는데 아무런 결과를 얻을 수 없으면 최악이다.

• 가설과 제품의 합
  • 실험하고자 하는 가설이 제품에 잘 반영이 되어 잇는지 지속적인 확인이 필요하다.
  • 특히 개발을 하다 보면 현실적인 이슈(리소스 문제, 타 팀과의 협업에서 발생하는 문제 등)로 인해 제품 Spec이 변경되는 일이 발생하기도 한다.
  • 이때 가설과 제품의 합을 따지지 않고 계속 변경하다 보면 실험을 진행하더라도 가설을 확인할 수 없게 되는 상황이 발생할 수 있으니 Spec 변경이 필요한 경우 이를 잘 고려해야 한다.
• 꼼꼼한 QA
  • 실험 관련 개발을 배포하기 전 프로덕트 QA와 데이터 로깅 QA가 진행이 되어야 한다.
  • 일반적으로 프로덕트 QA는 PM과 QA Manager가 같이 진행하며 PM은 상세 Spec 대로 제품에 로직이 반영이 되어 있는지 확인해 봐야 하며 특히 실험군에 적용되는 조작 변인이 잘 구현되어 있는지 확인이 필요하다.
  • 일반적으로 데이터 로깅 QA는 DA가 진행하며 진행여부에 대해 PM이 체크를 진행해 주면 된다. 만약 DA가 없다면 PM이 주도적으로 챙겨야 한다.
• 실험 배포 후 지표 모니터링
  • 실험 진행 시 주요 지표 모니터링이 계속 이루어져야 한다.
  • 특히 실험 출시 후 3일 정도는 주요 지표를 통해 실험 진행이 잘 되고 있는지 체크가 필요하다.
  • 실험을 배포했는데 지표에 아무런 변화가 없다면 문제가 있는 건지 상황 파악이 필요하다.(주로 실험군/대조군에 유저들이 편입이 안되고 있거나, 데이터 로깅이 누락되었거나 하는 등의 이슈)
  • 상황 파악 후 이후 빠르게 대응이 되어야 하며 이슈 대응이 끝난 시점에 실험 설계 중 실험 기간만 변경하여 다시 실험이 진행되어야 한다.

실험 결과 분석

• 결과 분석 시 우선적으로 중요하게 봐야 할 부분은 주요 지표들(성공/가드레일)을 체크하고 통계적 유의성을 검증하는 것이다.
• 통계적 유의성
  • 통계적 유의성은 모집단에 대한 가설이 가지는 통계적 의미를 말한다.
  • 어떤 실험 결과 자료를 두고 '통계적으로 유의하다.'라고 하는 것은 확률적으로 봐서 단순한 우연이라고 생각되지 않을 정도로 의미가 있다는 뜻이다.
  • 반대로 '통계적으로 유의하지 않다.'라고 하는 것은 실험 결과가 단순한 우연일 수도 있다는 뜻이다.
  • 즉 통계적 유의성을 확인하며 실험에서 나타난 결과가 우연에 의한 것인지 아닌지를 판단할 수 있다.
• P-value(P값)이란
  • 통계적 유의성을 검정하기 위해 p-value 값을 사용한다.
  • 보통은 5%(0.05)를 기준으로 많이 보며 p-value가 5%보다 작으면 통계적으로 유의하다고 판단한다.
  • 단순한 수치의 차이보다는 p-value를 보며 실험의 결과를 판단해야 한다.

후속 액션

• User Research
  • 실험을 통해 '데이터'는 나왔지만 데이터 이면에 숨겨진 유저들의 생각과 의도까지는 파악이 불분명할 때가 있다.
  • A/B Test를 진행해서 실험군 A가 성공 지표가 더 높게 나왔다는 데이터는 있지만 왜 유저들이 실험군 A에서 우리의 성공 지표를 올렸는지 그렇게 행동한 이유까지는 알 수 없기 때문이다.
  • 해서 보통 미리 세워둔 가설을 통해 유저들의 생각과 의도를 파악하는데 불충분하다고 느끼는 경우 추가적으로 유저 인터뷰를 통해서 이를 알아볼 수 있다.
• 후속 실험 설계
  • 실험에서 목표로 했던 지표를 계속 올려야 하는 상황이라면 실험의 성공/실패 여부와 관계없이 다음 실험을 또 진행할 수 있다.
  • 이번 실험이 성공했다면 가설 수립 시 우선순위가 낮아 실험에 적용되지 못한 가설을 채택하여 실험을 하거나 이번 실험 시 도출된 Insight를 통해 새롭게 가설을 수립하여 실험을 진행할 수 있다.
  • 이번 실험이 실패했다면 실험의 원인 분석 후 해당 가설을 재확인할 필요가 있는지 파악 후 필요하다면 다시 실험을 필요하지 않다면 위의 과정을 똑같이 진행하면 된다.
• 전면 배포 & 대시보드 세팅
  • 실험이 성공했다면 실험군에 적용했던 조작 변인을 전체 서비스에 적용하는 전면 배포 과정을 거친다.(회사 내부 상황에 따라 다를 수 있다.)
  • 개발은 이미 된 상황이기 때문에 개발자와 함께 전면 적용 시 고려해야 할 부분이 추가적으로 없는지 검토 후 배포하면 되며 배포 시 조직 내에 적용 내용을 공유해야 한다.
  • 또한 실험 진행을 위해 모니터링 대시보드를 다시 제품 health check 및 지표 확인용 대시보드로 바꿔주어야 한다.