04. 실험 플랫폼과 문화

 

실험 성숙도 모델

• 실험 성숙도 모델(Experiment Maturity Models) : 조직들이 A/B 실험을 통해 모든 변화를 실행하는 과정에서 겪을 가능성이 높은 단계를 구성한 것으로, 총 4단계
• 조직이 강력하고 신뢰할 수 있는 실험 플랫폼을 구축하고, 실험 문화를 정착하기 위해서는 실험 성숙도를 관찰하고 개선하는 것이 중요

 

단계와 관련없이 조직이 중점적으로 다뤄야 하는 분야

리더십

• 실험을 중심으로 하는 강력한 문화를 확립하고 A/B 테스트를 제품 개발 과정의 필수 요소로 포함시키기 위해서는 적극적인 리더십이 매우 중요함
• 실험하는 조직 문화를 만들어가는 최종 단계에 도달하기 위해서는 지속적인 측정, 실험, 지식 수집을 통해서만 가능함
  • 이를 위해 경영자와 매니저의 지원이 다양한 수준에서 수행돼야 함
    • 기능 출하를 목표로 하는 것이 아닌 지표 개선 관점에서 목표 설정
    • 조직의 가드레일 내에서 핵심 지표를 혁신하고 개선하기 위한 권한을 팀에게 부여할 것 (빨리 실패하는 문화 정착)
    • 실험 결과의 검토, 해석방법의 숙지, 해석기준의 강제 및 결과가 의사결정에 미치는 영향에 대해 투명성 부여
    • 이익에 점진적으로 공헌하는 프로젝트보다는 고위험/고수익 프로젝트의 포트폴리오 확보
      • 지속적인 혁신을 위해서는 실패로부터 배우는 것이 중요
• 리더는 단지 실험 플랫폼과 도구를 조직에 제공만해서는 안 되며, 조직이 데이터 중심 결정을 내릴 수 있도록 적절한 인센티브, 프로세스 및 권한을 제공해야 함

프로세스

• 조직이 실험 성숙의 단계를 거치면서, 신뢰할 수 있는 결과를 보장하기 위해서는 교육 과정과 문화적 규범을 확립하는 것이 필요함
• 교육은 모든 사람이 신뢰할 수 있는 실험을 설계하고 실행하며 그 결과를 올바르게 해석할 수 있는 기본적 이해가 가능하도록 할 것
  • 실험 설계 및 실험 분석 중에 just-in-time 프로세스를 수립하는 것이 조직을 한 단계 끌어올릴 수 있음
    • 처음 몇 번은 통계 전문가와 데이터 과학자의 도움을 필요로 함
    • 실험이 되풀이 되면서 실험자는 더 빠르고 독립적이 되며, 전문적인 검토자 역할을 수행할 수 있음
    • 단, 독특한 설계나 새로운 지표 필요 시에는 지원 필요
    • ex. 구글 : 검색 작업하는 실험자들이 실험을 하고 싶을 때 → 전문가들이 검토한 체크리스트 작성 → 조직이 충분히 상향 평준화되면 더 이상 명시적인 체크리스트 과정 불필요해짐
      • 체크리스트 : 가설 설정, 고려사항, 검정력 분석 위한 질문 및 계산 도구 등 확인
  • 분석 결과를 위한 정기적인 실험 검토 회의 진행
    • 전문가는 실험 결과의 신뢰도를 검증함
    • 논의를 통해 측정가능한 지표들의 트레이드오프를 문서화하고, OEC를 확립함
    • 실패한 실험에 대해 논의하고, 실패한 실험으로부터 배우는 곳
• 문화적 규범은 예상치 않았던 실패를 오히려 축하하고 항상 배우고 싶어하면서 혁신에 대한 기대를 설정하는데 도움을 줄 것
  • 실험을 성공시키고 규모를 확대시키기 위해서는, 배포 여부가 아닌 학습 그 자체가 가장 중요하다고 생각하는 지적 무결성으로 무장된 문화가 반드시 필요함
    • 이러한 관점에서 실험의 영향에 대한 완전한 투명성이 중요하며, 이를 달성하기 위한 방법
      • 많은 지표를 계산하고, OEC와 가드레일과 같은 중요한 지표 또는 기타 관련 지표들에 대한 실험 대시보드에서의 가시성을 높여 팀이 결과를 공유할 때 주관적 판단으로 일부 결과만 선정하지 못하도록 할 것
      • 예상치 못했던 결과, 직관을 구축하기 위한 많은 선행 실험에 대한 메타분석, 팀의 실험 통합 방법 등에 대한 뉴스레터나 이메일을 발송할 것 → 학습과 필요한 문화적 지원 강조를 위함
      • 실험이 중요한 지표에 부정적인 영향을 미치는 경우 실험자가 실험을 시작하기 어렵게 할 것
        • 지표를 함께 보면서 논쟁의 여지가 있는 의사결정을 공개적으로 토론할 수 있는 문화를 갖는 것이 좋음
      • 실패한 아이디어로부터 배우는 것을 받아들일 것

구축 vs 구매

• 고려해야 할 질문들
  • 외부 플랫폼이 필요로 하는 기능을 제고할 수 있는가?
    • 실험할 실험 유형(플랫폼 등), 웹사이트 속도, 사용하고자 하는 차원과 지표, 추가 데이터를 통합 가능여부 등
  • 자체 구축하면 비용이 어떻게 될까?
    • 대규모 시스템 구축은 어렵고 비용이 많이 듦
  • 실험이 증가하면서 어떤 것이 필요할까?
    • 실험에 모멘텀과 수요가 있고, 외부 솔루션으로는 대응할 수 없을 정도로 양이 증가할 가능성이 있으면, 내부에서 구축할 것
  • 실험이 시스템 사양과 배포 방법에 통합될 필요가 있는가?
    • 복잡한 디버깅 상황에서와 같이 배포와 실험 간 긴밀한 통합이 필요한 경우, 외부 솔루션으로는 더 어려울 것

인프라와 도구들

• 기업에서 실험 규모를 확대시키는 것에는 실험 플랫폼을 위한 인프라 구축 뿐만 아니라 회사의 문화, 개발 및 의사결정 프로세스에 실험을 깊이 편입할 수 있는 도구와 프로세스 구축도 포함됨
• 실험 플랫폼의 목표는 실험을 셀프 서비스화하고 신뢰할 수 있는 실험을 실행하는 데 드는 추가 비용을 최소화하는 것
• 실험 플랫폼은 실험 설계 및 배포에서 실험 분석까지 프로세스의 모든 단계를 포함해야 함

실험 플랫폼의 구성 요소

1. 실험 정의, 설정과 관리

• 실험 라이프 사이클을 쉽게 실험 정의, 설정 및 관리할 수 있어야 함 (실험 이름, 설명, 기간 등)
• 버그 수정, 점진적 대상자 확대 등의 이유로 실험이 여러 번 반복될 수 있도록 해야 함
• 실험하기 전 실험 실행 내용을 확인하기 위해 추가 도구나 워크로드가 필요함 → 테스트 코드에서의 승인 절차 등
• 날기 단계에서는 플랫폼에서 실험의 안정성을 높이기 위해 아래와 같은 지원 필요
  • 실험 시작 및 확대 방법 자동화
  • 실시간에 가까운 모니터링 및 경보, 나쁜 실험 조기 포착
  • 불량 실험 자동 탐지 및 종료

2. 실험 배포

• 배포에 포함되는 두 가지 구성 요소
  • 실험의 정의, 변형군 할당 및 기타 정보를 제공하는 실험 인프라
  • 실험 할당에 따라 변형군마다의 행태를 구현하는 생산 코드 변경
• 실험 인프라는 변형군의 할당, 생산 코드, 시스템 파라미터 및 값을 제공해야 함
• 변형군을 할당한 후엔 시스템이 사용자에게 적절한 실험을 제공하는지 확인해야 함

3. 실험 계측

• 사용자 행동 및 시스템 정의와 같은 기본 계측은 항상 기록되어야 함
• 어떤 실험 조건과 반복 실험이 실행되고 있더라도 실험에 대한 모든 사용자 요청과 상호작용을 계측해야 함
  • 반복 실험의 계측은 특히 실험을 개시하거나 실험 대상을 확대할 때 특히 중요함
• 달리기와 날기 단계에 도달하면 반사실적인 것, 즉 실험을 하지 않았다면 어떤 일이 일어났을지를 기록하기를 원할 수 있음
  • 반사실적 로깅은 매우 어렵지만 필요하며, 성능 관점에서 비용이 많이 들 수 있기에 필요한 시기에 대한 지침을 수립해야 함

4. 실험 스케일링 : 변형 할당 심층 분석

• 걷기에서 달리기 단계로 이행함에 따라 실험에 충분한 통계적 검정력을 제공하기 위해, 각 변형군에 사용자들의 충분한 비율이 할당돼야 함
  • 최대 검정력을 원하는 경우 실험은 5:5로 실행되며 모든 사용자를 포함할 것
• 실험 횟수를 확대하려면 사용자가 여러 실험에 참여해야 하는데, 이를 수행하는 방법은 아래 2가지 방법이 있음

1) 단일계층법

• 변형군의 할당은 사용자가 실험 변형군에 일관성 있게 할당되는 과정
• 동일한 실험을 실행하는 두 버킷을 비교할 경우 버킷은 통계적으로 유사한 것으로 가정함
  • 각 버킷에는 대략 동일한 수의 사용자가 있어야 함 → 국가, 플랫폼 등과 같이 세분화하면 버킷 내 분할 결과도 거의 동일할 것
  • 핵심 지표는 거의 동일한 값을 가져야 함
• 단일 계층법에서 발생할 수 있는 문제
  • 할당을 모니터링하는 것이 핵심
    • 구글, 마이크로소프트 등 많은 회사들은 버킷 기능을 모니터링해 랜덤화 코드에서 오류를 발견함
  • 이월 효과
    • 이전 실험은 현재 실험에 대한 버킷에 영향을 줄 수 있음 → 재정규화로 모든 실험에서 버킷이 오염되지 않도록 하는 것이 일반적인 해결책
• 장점
  • 간단하며, 여러 실험을 동시 실행할 수 있음(각 사용자는 단일 실험에만 존재)
• 단점
  • 각 실험이 충분한 검정력을 갖도록 충분한 트래픽이 필요하기 때문에, 동시에 실행할 수 있는 실험의 수에 제한이 있음
  • 초기 단계에서도 여러 명의 사용자에 대해서 동시에 실행되기 때문에, 실험 트래픽 관리 운영이 어려울 수 있음
  • 동시성을 관리하려면 수동 방식을 해야 하는데, 이것으로는 규모를 확장시킬 수가 없음 → 결국 규모가 확장되면 프로그램에 의한 할당 방식으로 이행됨

2) 동시 실험

• 실험을 확대하기 위해선, 각 사용자가 동시에 여러 실험을 할 수 있는 일종의 동시 실험 시스템으로 이행해야 함
  • 이를 해결하는 방법은 각 층이 단일 계층 방식처럼 동작하는 여러 실험 계층을 갖는 것
  • 여러 계층 간에 실험의 직교성을 보장하려면, 사용자를 버킷에 할당할 때, 계층 ID를 추가해야 함
• 요청이 들어오면 들어오면 변형군에의 할당이 각 계층에 대해 한 번씩 수행되고, 이는 제품 코드와 계측 모두 변형군 ID 벡터를 처리해야 함을 의미함
• 동시 실험 시스템의 주요 문제
  • 계층을 어떻게 결정하는지가 핵심
    • 1. 완전 요인 실험 설계를 완전 요인 플랫폼 설계로 확장하는것
      • 사용자는 모든 실험에 동시에 참여하게 됨
      • 동일한 실험의 반복은 사용자에게 일관성있는 경험을 보장하기 위해 통상 동일한 해시 ID를 공유해야 함
      • 단점 : 두 개의 상이한 실험의 특정 실험조건이 공존하면, 사용자에게 좋지 않는 경험을 제공할 가능성 존재
        • 예를 들어, 실험 1에서 파란색 텍스트를 테스트하고 실험2에서 파란색 배경을 테스트 → 이 경우, 우연히 두 가지 실험 모두에 할당된 사용자에게는 끔찍한 경험이었을 것
        • 따라서 실험 간의 상호작용을 고려하지 않으면 각 실험에 대해 독립적으로 측정한 결과도 부정확할 수 있음
        • 단, 모든 상호작용이 나쁜 영향을 초래하는 것은 아니라는 점에 유의해야하며, 때로는 두 개의 실험효과를 독립적으로 더하는 것보다 상호작용으로 더 좋은 결과를 보이는 경우도 존재함
    • 2. 계층적 플랫폼 설계 혹은 제약조건 기반 플랫폼 설계 사용
      • 계층적 설계는 시스템 파라미터가 계층으로 분할되므로, 결합해서 열악한 사용자 경험을 초래할 가능성이 있는 실험은 반드시 동일한 계층에 있어야 하고, 설계에 의해 동일한 사용자에 대해 실행되는 것을 반드시 방지해야 함
      • 제약 조건 기반 설계는 실험자가 제약조건을 지정하고, 시스템은 그래프 색상 알고리즘을 사용해 우려사항을 공유하는 어떤 두 개의 실험이 사용자에게 동시에 적용되지 않도록 함

5. 실험 분석 도구

• 실험 성숙도의 최종단계로 넘어가기 위해서는 자동화된 분석이 필요함
  • 이는 팀이 시간 소모적인 임시 분석을 할 필요가 없게 하고, 보고서의 이면에 있는 방법론이 견고하고 일관되며 과학적으로 기반을 갖도록 하기 위해 중요함

분석 자동화 단계

1. 데이터 처리
   1. 목적 : 실험 결과를 계산하고 시각화하는데 사용할 수 있는 상태로 데이터를 가져오는 것
2. 데이터 계산
   1. 목적 : 주요 지표 요약 및 강조 표시를 통해 의사 결정자가 출시/출시보류 결정을 내리는데 도움을 주는 것
   2. 세그먼트별 지표의 데이터 계산, p값/신뢰구간 계산, SRM 점검과 같은 신뢰도 검사가 필요함
3. 데이터 시각화
   1. 목적 : 이해하기 쉬운 방법으로 주요 지표와 흥미로운 지표와 세그먼트를 강조하기 위함
   2. 시각화 도구를 사용해 모든 지표별 뷰를 생성하면, 이 뷰를 통해 이해관계자는 주요 지표의 글로벌 상태를 면밀히 모니터링 하고 어떤 실험이 가장 효과적인지 확인할 수 있음
      1. 시각화 도구는 제도적 기억에 접근을 가능하게 해 무엇이 실험됐는지, 왜 그러한 의사결정이 내려졌는지 그리고 그러한 지식의 발견과 학습으로 이어지는 성공과 실패를 포착하기에 매우 적합함

 

참고
읽어보면 좋은 참고 자료 : Data for PM