<A/B 테스트 - 신뢰할 수 있는 온라인 종합 대조 실험> 책의 Ch. 4 정리
모든 챕터별 정리 내용은 아래에서 확인 가능하다.
<A/B 테스트 - 신뢰할 수 있는 온라인 종합 대조 실험> - 챕터별 정리 포스팅 읽기
Ch.4 주요 내용:
강력하고 신뢰할 수 있는 실험 플랫폼, 실험 문화 구축하기
목차
1. Experimentation Maturity Models
1.1 실험 성숙도 단계
조직이 data-driven 해지고, ABT를 통해 모든 변화를 실행하는 과정에서 겪게되는 단계
한 조직은 이러한 단계를 거치며 기술적 초점, OEC, 팀 설정까지도 바뀌게 될 것
1단계: Crawl (연 10회 가량 실험 진행)
•
목표: 실험을 설계, 실행, 분석할 수 있도록 기초적인 전제 조건을 갖추어 요약통계량 계산, 가설검정을 할 수 있도록 하는 것
•
소수의 실험을 성공적으로 진행해서 다음 단계로 나아가기 위한 모멘텀 창출
2단계: Walk (연 50회 가량 실험 진행)
•
목표: Standard metric을 정의하고 조직이 더 많은 실험을 실행할 수 있도록 하는 것
•
실험 검증, AA 테스트, SRM(sample ratio mismatch) 테스트 등을 통해 실험의 신뢰도 향상
3단계: Run (연 250회 가량 실험 진행)
•
목표: 많은 실험을 규모 있게 실행하는 것
•
포괄적인 metric set 설정, 지표간의 트레이드오프를 포착하는 OEC 성문화 (7장 참고)
4단계: Fly (연간 수천번 실험 진행)
•
변화를 추진하는 표준으로 ABT를 진행하는 단계
•
데이터과학자 없이도 대부분의 (특히 간단한) 실험 분석이 가능
•
목표: 모든 실험과 변화를 기억하는 제도(institutional memory)를 확립하고, 과거 실험으로부터 학습하고, 놀라운 결과와 best practice를 공유해서 실험 문화를 향상 (8장 참고)
1.2 단계와 상관없이 다뤄야 하는 조직 차원의 분야
Leadership
Data-driven 의사결정을 내리기 위해 리더십은 적절한 incentives, processes, empowerment를 조직에 제공해야 한다. 리더십의 이런 활동은 Crawl, Walk 단계에서 특히 중요하다.
•
조직이 실험하는 조직문화를 만들어갈 때 거치는 단계
1.
HiPPO(Highest Paid Proson’s Opinion)를 신뢰 → 측정과 실험은 필요 없다 자만
2.
주요 지표를 측정하고 이유를 설명할 수 없는 원인을 고려하기 시작하지만 여전히 조직은 견고한 규범,신념, 패러다임 및 HiPPO에 강하게 의존하기에 이와 반대되는 지식을 거부할 수도 있음
3.
지속적 측정, 실험, 지식 수집을 통해서만 조직은 원인에 대해 이해하고, 모델이 작동할 수 있다
•
3단계 도달을 위해서는 아래와 같은 경영자와 매니저의 지원이 필요함
◦
공유된 목표를 확립하고 높은 레벨의 목표 지표, 가드레일 지표에 합의(18장), OEC 확립을 위한 단계로서 트레이드오프를 성문화(7장)
◦
특정 기능 출하 대신 지표 개선 관점에서 목표를 설정 (’지표를 개선하는 기능만 출시한다’)
◦
조직의 가드레일 내에서 key metric을 혁신하고 개선하기 위한 권한을 팀에게 부여. 빨리 실패하는 문화 정착
◦
적절한 계측 및 높은 데이터품질을 기대
◦
실험 결과의 검토, 해석 방법의 숙지, 해석 기준의 강제 및 이들 결과가 의사결정에 미치는 영향에 대해 투명성의 부여
◦
실험이 가장 도움이 되는 결정은 최적화에 관한 부분. 장기간의 일련의 실험은 전체적인 전략에 대해서도 정보 제공할 수 있음
◦
고위험/고수익 프로젝트의 포트폴리오를 확보 (점진적으로 이익에 공헌하는 프로젝트 보다도)
지속적 혁신을 위해서는 실패로부터 배우는 것이 중요
◦
데이터 수집만을 위한 실험 혹은 ROI 확립을 위한 것과 같은 실험을 통한 장기적 학습을 지원
실험은 출시 의사결정 뿐 아니라 다양한 이니셔티브에 대한 영향측정 및 ROI 평가에도 중요한 역할(5장)
◦
짧은 release cycle로 건강하고 빠른 피드백루프를 생성하기 위해서 민감한 대리지표를 확립(7장)
Process
•
교육
◦
모든 사람이 신뢰성있는 실험을 설계하고 실행하고 결과를 올바르게 해석할 수 있는 기본적 이해를 가능하게 함
◦
실험 설계, 분석시 Just-in-time process: 체크리스트 작성 후 전문가 검토
◦
이러한 경험을 쌓을수록 실험자는 전문가와 데이터 과학자의 도움 필요 → 빠르고 독립적
•
문화적 규범
◦
정기적인 실험 리뷰 회의
▪
go-no go decision + 실험의 신뢰도 검증, 측정 가능한 지표간 트레이드오프를 성문화하고 OEC 확립, 실패한 실험으로부터 학습
▪
서로 다른 팀을 미팅으로 모아 서로에게서 학습하게 함 (context는 충분히 공유되어 있어야 함)
▪
Walk 후반, Run의 성숙도에서 효과적일 것으로 추정
◦
학습 공유와 이를 통한 institutional memory
▪
Fly 성숙도 단계에서 점점 더 유용
◦
실험 영향에 대한 투명성 확보
▪
실험을 통한 출시 여부 결정보다도 학습 그 자체가 중요하다고 생각하는 지적 무결성 문화 필요
▪
투명성 달성을 위한 방법
•
많은 지표를 계산하고, OEC나 가드레일 및 관련 지표 등 중요 지표는 실험 대시보드에서 가시성을 높여, 팀이 결과 공유시 cherry-pick 하지 못하도록 함
•
예상치 못한 결과, 선행 실험에 대한 메타 분석, 팀의 실험 통합 방법에 대한 공유(뉴스레터, 이메일 등)
•
실험이 중요 지표에 부정적 영향을 미치는 경우 실험자가 실험을 시작하기 어렵게 하기
•
실패로부터 학습하는 것을 받아들이기
Build vs. Buy
•
선택을 위한 고려사항
◦
외부 플랫폼이 필요로 하는 기능을 제공할 수 있는가?
◦
자체 구축에 드는 비용이 얼마인가?
◦
조직의 실험 니즈는 어떤 추세인가?
▪
이런 유형의 인프라 투자는 현재 니즈에 기반하는 것이 아니라, 예측에 기반을 두고 이루어짐
▪
실험 모멘텀과 수요가 있고, 외부 솔루션으로는 대응하지 못할만큼 양이 증가할 가능성이 있다면 내부 구축
◦
실험이 시스템 사양과 배포 방법에 통합될 필요가 있는가?
•
조직의 자체 플랫폼 구축을 위한 투자와 투자에 대한 의지가 부족할 수 있는데, 의사 결정 전에 외부 솔루션을 활용해 더 많은 실험의 영향을 입증하는 것이 타당할 수 있음
2. Infrastructure and Tools
실험 플랫폼은 실험 설계 및 배포에서 실험 분석까지 프로세스의 모든 단계를 포함해야 한다. 실험 플랫폼에는 크게 4가지 구성요소가 있다
•
사용자 인터페이스(UI) 또는 애플리케이션 프로그래밍 인터페이스(API)를 통한 실험 정의, 설정 및 관리로 실험 시스템 설정에 저장된다.
•
실험군 할당 및 파라미터화를 커버하는 서버 측 및 클라이언트 측 실험 배포
•
실험 계측
•
p값과 같은 통계 테스트와 지표의 정의 및 계산을 포함하는 실험 분석
2.1 실험 정의, 설정과 관리
•
플랫폼에는 많은 실험과 많은 반복 시행을 쉽게 관리할 수 잇는 인터페이스/도구가 필요
◦
실험자가 실험 라이프 사이클을 쉽게 정의, 설정 및 관리할 수 있는 방법 필요
◦
하나의 실험에 대해 반복 시행이 가능해야 함
▪
실험 결과를 기반으로 기능을 진화시키기 위한 것으로, 실험 중 발견된 버그 수정도 포함
▪
실험을 점진적으로 보다 광범위한 실험 대상자에게 시행
•
실험 전 개입내용을 확인하기 위한 추가도구나 워크로드 필요
•
대규모 실험이 실행되는 Fly 단계에서는 다음 지원이 필요
◦
실험 시작 및 확대 방법의 자동화
◦
실시간에 가까운 모니터링 및 경보, 나쁜 실험 조기 포착
◦
불량 실험 자동 탐지 및 종료
2.2 실험 배포
실험 인프라가 제공해야 하는 것
•
변형군의 할당(variant assignment)
•
생산 코드, 시스템 파라미터 및 값
2.3 실험 계측
•
사용자 행동 및 시스템 성과와 같은 기본 계측을 이미 기록하고 있다고 가정
•
특히 새로운 기능을 테스트할 때에는 계측 방법 업데이트를 통해 적절한 분석이 가능
Crawl 단계에서 이러한 수준의 계측에 초점을 맞추고, 리더십이 지속적으로 모니터링해야 함
•
Run, Fly 단계에서는 반사실적인 로깅이 필요할 수 있다 (20장)
2.4 실험 스케일링: 변형 할당 탐구
최대 검정력을 원할 때 실험은 50:50으로 실행되며 모든 사용자를 포함한다. 실험 횟수를 확대하려면 사용자가 여러 실험에 참여해야 하는데, 이를 수행하는 방법은 아래와 같다.
Single-Layer Method(단일계층법)
•
각 실험 변형군에 총 트래픽의 특정 비율을 할당하는 식으로 모든 트래픽을 분할
•
장점: 간단하고 여러 실험을 동시에 실행 가능(각 사용자는 단일 실험에만 있음)
•
단점: 동시에 실행할 수 있는 실험의 수에 제한. 실험 트래픽 관리가 운영상 어려움
Concurrent Experiments (동시 실험, 중첩, 오버래핑)
•
각 사용자가 동시에 여러 실험을 할 수 있음
•
각 층이 단일계층 방식처럼 동작하는 여러 실험 계층을 갖는 것이 한가지 방법.
계층을 어떻게 결정하는가에 몇 가지 옵션이 있음
1.
Full factorial platform design
•
사용자는 모든 실험에 동시에 참여 (실행 중인 모든 실험에서 한 변형군에 할당)
•
단점: 잠재적 충돌. 사용자에게 좋지 않은 경험을 제공할 가능성 (실험간 상호작용을 고려해야 함)
2.
Nested platform design
•
열악한 사용자 경험을 초래할 가능성이 있는 실험은 동일한 계층에 두어, 동일한 사용자에 대해 실행되는 것을 방지
3.
Constraints-based platform design
•
실험자가 제약조건을 지정하고, 시스템은 그래프 색상 알고리즘을 사용해 우려사항을 공유하는 두 개의 실험이 사용자에게 동시 적용되지 않도록 함
2.5 실험 분석 도구
실험 성숙도의 최종 단계로 넘어가기 위해서는 자동화된 분석이 필요하다. 이는 팀이 시간 소모적인 adhoc 분석을 할 필요가 없게 하고, 보고서의 방법론이 견고하고 일관되며 과학적 기반을 갖도록 하기 위해 중요하다.
분석 자동화 단계
•
데이터 처리: 실험 결과를 계산하고 시각화하는 데 사용할 수 있는 상태로 데이터를 가져오는 것
•
주요 지표를 요약하고 강조 표시해 의사결정자가 출시 여부 결정을 내리는데 도움을 줌
◦
OEC 검사, 분할 수행 전에 신뢰도 검사를 먼저 수행해야 함
◦
실험 데이터를 보기 전에 데이터 처리, 계산은 테스트/점검 되어 프로세스의 신뢰도를 보장해야 함
◦
데이터 시각화 작성: 이해하기 쉬운 방법으로 주요 지표, 흥미로운 지표와 세그먼트를 강조
가이드
•
조직이 Run, Fly 단계로 나아가면서 수많은 지표가 존재할 수 있음. 실험결과 해석이 복잡해질 수 있는데, 교육도 가능하지만 0.05보다 적은 유의수준을 사용하면 해석이 쉬워질 수 있음
•
시각화 도구를 사용해 모든 실험 결과에 대한 지표별 뷰를 생성하라. 이해관계자는 이를 통해 주요 지표의 글로벌 상태를 면밀히 모니터링하고 어떤 실험이 가장 효과적인지 확인할 수 있다. 이러한 투명성은 실험에 대한 조직의 전반적 지식을 향상시킨다.
•
시각화도구는 institutional memory에 접근해서 어떤 실험이 진행되었고, 왜 그런 의사결정이 내려졌으며, 지식발견과 학습을 가능하게 하는 성공/실패를 포착하게 하는 훌륭한 관문
Chloe’s Comment
•
현재 회사에서 실험 툴 및 문화를 개선하기 위한 TF에 참여 중이어서 각 꼭지마다 회사의 현재 상황과 비교하면서 볼 수 있어 도움이 되었다. 회사가 노력하고 있는 부분, 부족한 부분을 생각해보게 되었고, 앞으로 TF가 진행되면서 이 책의 내용을 많이 참고하게 될 것 같다. 다만 상세한 내용들은 모두 뒤 쪽의 챕터를 참조하라고 되어 있어서 책 전체를 열심히 중도 포기하지 말고 읽어야겠다. ㅎㅎ