[A/B 테스트] 1부 모두를 위한 입문 주제_ch.4 실험 플랫폼과 문화

<A/B 테스트> 의 '1부 모두를 위한 입문 주제_ch.4 실험 플랫폼과 문화'의 내용을 요약 및 정리한 내용입니다.

 

https://product.kyobobook.co.kr/detail/S000060625360

A/B 테스트 | 론 코하비 - 교보문고

---

0. 개요

신뢰할 수 있는 종합 대조 실험을 실행하는 것은 많은 아이디어를 평가하고 데이터에 근거한 결정을 내리는 데 있어 과학의 황금율입니다. 종합 대조실험은 단순하게 실행할 수 있도록 함으로써 새로운 아이디어를 시도하는 비용을 줄이고, 선순환적인 피드백 루프의 가운데에서부터 배움을 얻고, 혁신을 가속화 시킵니다.

 

이번에는 강력하고 신뢰할 수 있는 실험 플랫폼을 구축하는데 초점을 맞춥니다.

 

실험을 시작할 때 조직이 일반적으로 겪는 다양한 단계를 보여주는 실험 성숙도 모델을 도입하는 것부터 시작해 실험 플랫폼을 구축하는 기술적 세부사항을 알아보겠습니다.

 

중요한 조직적 고려사항으로는 리더십, 프로세스, 교육, 이러한 업무들을 사내에서 실시해야 할지 외주를 주어야 할지의 여부, 결과를 최종적으로 어떻게 이용할까 등등이 있으며, 기술적 도구는 실험 설계, 배포, 확장과 분석을 지원해 영감을 얻는 것을 가속화 시킬 것 입니다.

 

1. 실험 성숙도 모델

실험성숙도 모델은 조직들이 데이터 중심적이고 A/B 실험을 통해 변화를 겪는 과정에서 겪을 네 가지 과정입니다.

1. 기어가기(crawl)

• 목표
  • 기초적인 전제 조건과 구체적인 가설 테스트에 필요한 요약 통계량을 계산할 수 있는 계측
  • 기본 데이터 과학 능력을 구축해 실험을 설계, 실행 및 분석 할 수 있도록 하는 것
• 대략 한 달에 한 번 실험을 진행합니다. 
• 다음 단계로 나아가기 위해 해당 단계에서 실험을 성공시키는 것은 매우 중요합니다.

2. 걷기(walk)

• 목표
  • 기어가기의 단계로부터 표준적인 지표를 책정해 조직이 더 많은 실험을 실행할 수 있도록 하는 것
• 대략 일주일에 한 번 실험을 진행합니다.
• 실험의 검증, A/A 테스트, 샘플 비율 불일치 (SRM) 테스트 등을 통해 신뢰도를 높여야합니다.

3. 달리기(run)

• 목표
  • 많은 실험을 규모있게 실행하는 것
  • 지표는 포괄적이며, 합의된 목표를 달성하거나 여러 지표 간의 상충관계를 알 수 있는 종합평가기준을 문서화하는데 까지 모든 방법을 실시해야 합니다.
• 대략 매일 실험을 진행합니다.
• 조직은 실험을 사용해 대부분의 새로운 기능과 변화 등을 평가하게 됩니다.

4. 날기(fly)

• 목표
  • 커진 규모의 테스트를 보조하기 위한 자동화
  • 모든 실험과 변화를 제도적 기억으로 만드는 것
  • 과거의 실험으로부터 학습하여, 놀라운 결과와 사례를 공유해 실험 문화를 향상시키는 것
• 대략 연간 수천 번의 실험을 진행합니다.
• 새로운 기능을 만드는 팀은 데이터 과학자의 도움 없이 대부분의 실험을 분석하는데 능숙합니다.

위의 단계를 거치면서 조직은 기술적 초점, 종합평가기준, 팀 설정까지도 변화하게 됩니다. 이제 위의 모든 단계에서 조직이 중점적으로 다뤄야 하는 리더십과 프로세스를 포함한 몇 가지를 알아보겠습니다.

1.1 리더십

실험을 중심으로 하는 강력한 문화를 확립하고 A/B 테스트를 제품 개발 과정의 필수 요소로 포함시키기 위해서는 적극적인 리더십이 매우 중요합니다.

 

조직이 실험하거나 실험하는 조직 문화를 만들어 갈 경우에도 역시 단계가 존재합니다. 해당 단계는 다음과 같습니다.

 

1. 최고의 연봉을 받는 사람들의 의견을 신뢰하기 때문에 측정과 실험을 필요하지 않는다고 단계입니다.
2. 주요 지표를 측정하고, 원인을 설명할 수 없는 차이를 고려하기 시작합니다. 하지만 조직은 정착되어 있는 규범, 신뢰와 패러다임 및 최고의 연봉을 받는 사람들의 의견에 의존하기 때문에 새로운 방법에 대한 강한 거부 반응을 보일수도 있습니다.
3. 지속적인 측정, 실험, 지식 수집을 통해 조직은 원인에 대한 기초적 이해와 모델의 작동에 대한 근본적 이해에 도달하게 됩니다. 

최종 단계에 도달하기 위한 경영자와 매니저의 지원 방법들

최종 단계에 도달하기 위해, 경영자와 매니저의 지원은 여러 상이한 수준에서 수행돼야 하며, 방법들은 아래와 같습니다.

 

1. 공유 목표를 확립하기 위한 프로세스에 참여하여, 높은 수준의 가드레일 지표에 합의하고, 종합평가기준을 확립하기 위해 상충관계를 문서화합니다.
2. 새로운 기능의 개발을 목표로 하는 대신 핵심 지표 개선 관점에서 목표를 설정합니다.
   • 이렇게 변화하는 것은 근본적인 변화의 시작이나, 실험을 문화로 만드는 것은 매우 어려운 일에 해당합니다.
3. 조직의 가드레일 내에서 핵심 지표를 혁신하고 개선하기 위한 권한을 팀에게 부여합니다.
   • 이는 수많은 아이디어가 실패할지라도 실패를 통해 빠르게 개선되도록 만듭니다.
   • 이를 통해 빨리 실패하는 문화가 정착됩니다.
4. 절적할 계층 및 높은 데이터 품질을 기대합니다.
5. 실험 결과의 검토, 해석 방법의 숙지, 해석 기준의 강제 및 해당 결과가 의사결정에 미치는 영향에 대해 투명성을 부여합니다.
6. 실험에 의한 많은 의사결정은 최적화를 위한 정보 제공에 있어서 큰 도움이 됩니다.
7. 이익에 점진적으로 공헌하는 프로젝트보다는 고위험/고수익 프로젝트의 포트폴리오를 확보합니다.
   • 지속적인 혁신을 위해서는 실패로부터 배우는 것이 중요하기에 실패했을 경우, 실패를 이해합니다.
8. 장기적 실험을 위한 장기적 목적의 학습을 지원합니다.
   • 실험은 개별 기능에 변화에 대한 의사결정에 유용할 뿐아니라 다양한 측정 및 평가에 중요한 역할을 합니다.
9. 장기 지표 변화를 예측할 수 있는 단기적으로 예측가능한 지표를 확립합니다.
   • 이는 짧은 출시 주기로 민첩성을 향상시켜 실험을 위한 건강하고 빠른 피드백 루프를 생성합니다.

 

이처럼 리더는 단지 실험 플랫폼과 도구를 조직에 제공만해서는 안됩니다. 리더는 조직이 데이터 중심 결정을 내릴 수 있도록 적절한 인센티브, 프로세스 및 권한을 제공해야 하며,  조직이 이러한 활동에 활동에 참여하는 리더십은 특히 첫번째 단계인 기어가기와 두번째 단계인 걷기 성숙도 단계에서 조직을 목표에 맞추기 위해 매우 중요한 역할을 합니다.

1.2 프로세스

• 조직이 실험 성숙의 단계를 거치면서, 신뢰할 수 있는 결과를 보장하기 위해서는 교육 과정과 문화적 규범을 확립하는 것이 필요합니다.
  • 교육은 모든 사람이 신뢰할 수 있는 실험을 설계하고 실행하며 그 결과를 올바르게 해석할 수 있는 기본적인 이해가 가능하도록 한다.
  • 문화적 규범은 예상치 않았던 실패를 오히려 축하하고 항상 배우고 싶어하면서 혁신에 대한 기대를 설정하는데 도움을 줍니다.

1.2.1 교육

교육의 경우, 실험 설계 및 실험 분석 중 적시교육 시스템을 수립을 통해 조직을 한 단계 끌어올릴 수 있습니다. 

 

적시교육 시스템의 경우 아래와 같은 단계로 수립됩니다.

 

1. 일반적으로 실험자가 실험을 수행할 때, 처음 몇 번은 통계 전문가와 데이터 과학자의 도움을 필요로 합니다.
2. 이후 실험이 되풀이 되면서 실험자는 더 빠르고 독립적이게 됩니다.
3. 실험자가 경험이 많을수록 전문적인 검토자 역할을 하는 것이 가능해지나, 경험이 많은 실험자라도 일반적으로 독특한 설계나 새로운 지표가 필요한 실험에 대해서는 통계 전문가나 데이터 과학자의 지원을 필요로 합니다.
4. 기업은 직원들이 실험의 개념을 계속 상기시하도록 강좌를 열어 교육을 엽니다. 

이러한 교육은 점차 실험을 수용하는 문화가 성숙해지면서 더욱 인기가 높아지게 됩니다.

 

정기적인 실험 검토 회의

분석 결과를 위한 정기적인 실험 검토 회의 역시 적시교육에 효과가 있습니다.

 

• 회의에 실험자들이 출시 여부 권고안은 도출하는 논의를 진행하기 전에, 전문가를 통해 실험 결과의 신뢰도에 대한 피드백이 가능합니다.
• 논의를 통해 목표, 가드레일, 품질 및 디버그 지표에 대한 이해를 넓힐 수 있습니다. 이는 앞으로 발생할 수 잇는 문제들에 대해 예상할 수 있게 합니다.
  • 많은 고위험/고보상 아이디어는 첫 번째 시행에서 성공하지 못하며, 실패로 성공으로 나아가기 위해 필요한 개선 사항들뿐만 아니라 나아가야할 시기를 결정하는 것을 학습합니다.
• 논의를 통해 측정가능한 지표들의 상충관계를 문서화하고, 종합평가기준을 확립하게 합니다.
• 서로 다른 팀이 논의를 통해 서로에게서 배울 수 있도록 합니다.
  • 단 팀이 너무 다양하거나 도구화에 대한 성숙도가 불충분하다면, 이는 비생산적 일수도 있습니다.
• 이러한 유형의 검토는 두번째 단계인 걷기 후반이나 세번째 단계의 달리기의 성숙도의 실행 단계에서 유용합니다.

 

제도적 기억

• 위와 같은 플랫폼과 프로세스를 통해 광범휘한 실험에서 얻은 학습을 기록하여 다양한 방법을 통해 공유할 수 있습니다.
• 제도적 기억은 네번째 단계인 날기 단계에서 점점 더 유용해집니다.

 

1.2.2 문화적 규범

실험을 성공시키고 규모를 확대시키기 위해서는 결과 또는 변경을 출시할지의 여부가 아니라, 학습 그 자체가 가장 중요하다고 생각하는 지적 무결성 문화 또한 반드시 필요합니다. 따라 실험의 영향에 대한 완전한 투명성이 중요합니다.

 

실헝의 영향에 대한 완전한 투명성을 달성하기 위한 방법은 아래와 같습니다.

 

1. 많은 지표를 계산하고 지표들에 대한 실험대시보드에서의 가시성을 높여 팀이 결과를 공유할 때 주관적 판단으로 일부 결과만 선정하지 못하도록 합니다.
2. 예상치 못했던 결과, 선행 실험에 대한 메타분석, 실험 통합 밥법 등에 대한 뉴스레터나 이메일을 발송합니다.
3. 실험이 중요한 지표에 부정적인 영향을 미치는 경우 실험자가 실험을 시작하기 어렵게 합니다.
4. 실패한 아이디어로부터 배우는 것을 받아들입니다.

 

1.3 구축 대 구매

실험의 구축 또는 구매는 투자수익률에 대한 결정입니다. 그렇기에 반드시 모든 기업이 자체 실험 플랫폼을 구축해야 한다고 권고하지는 않으며, 이는 특히 두 번째 단계인 걷기 단계에서 구축 또는 구매 결정은 중요한 영향을 미칩니다.

 

구축할지 구매할지 결정을 내릴 때 고려해야할 몇 가지 질문들의 예시는 아래와 같습니다.

 

1. 외부 플랫폼이 필요로 하는 기능을 제고할 수 있는가?
   • 실행할 실험 유형을 고려해야 합니다.
     • 많은 타사 솔루션은 모든 유형을 포괄할 만큼 다재다능하지 않습니다.
   • 웹사이트 속도를 고려해야 합니다.
     • 여러 외부 솔루션에는 페이지 로드를 느리게 하는 것으로 알려진 자바스크립트가 추가적으로 필요합니다.
     • 이러한 지연 시간의 증가는 사용자 참여에 영향을 미칩니다.
   • 사용하고자 하는 차원과 지표를 고려해야 합니다.
     • 광범위한 비지니스 보고서를 개별적으로 구축해야만 하는 경우에 차원과 지표의 공통 언어를 확립하는 것이 어려우며, 플랫폼을 구매하는 경우에는 이러한 일관성을 확보하는 것이 더 어려울 수 있습니다.
   • 어떤 무작위 추출 단위를 사용할지, 어떤 데이터의 공유를 허용할지를 고려해야 합니다.
     • 통상 어떤 정보를 외부관계자에게 전달하는 것에 대해 제한이 있거나 추가 비용이 들 수 있습니다.
   • 상이한 시스템의 신뢰도를 저하시키는 복합성을 질문을 통해 고려해야 합니다.
     • 외부로 데이터 기록이 가능한가?
     • 고객이 두 장소에 기록을 남길 필요가 있는가?
     • 절충하기 위한 도구가 있는가?
   • 추가 데이터를 통합할 수 있는가?
     • 일부 외부 시스템은 외부 데이터를 결합하는 것에 제한이 존재합니다.
   • 거의 실시간에 가까운 결과가 필요한가?
     • 이는 종종 나쁜 실험을 빠르게 감지하고 멈추는데 유용합니다.
   • 자신만의 제도적 기억을 확립할 만큼 충분한 실험을 하고 있는가?
     • 많은 제 3자 실험 시스템은 제도적 기억 기능을 가지고 있지 않습니다.
   • 최종 버전의 기능을 실제로 구현할 수 있는가?
     • 실험을 대규모로 수행하는 경우, 재구현이 필요한 경우가 많기에 제한 요소가 됩니다.
2. 자체 구축하면 비용이 어떻게 될까?
   • 대규모 시스템을 구축하는 것을 어렵고 비용이 많이 듭니다. 
3. 실험이 증가하면서 어떤것이 필요할까?
   • 실험에 대한 인프라 투자는 실험 수의 예측에 기반을 두고 이뤄줘야 합니다.
   • 실험에 대한 수요가 있고 외부 솔루션으로는 대응할 수 없을 정도로 양이 증가할 가능성이 있으면, 내부에서 구축해야 합니다.
   • 내부 솔루션을 구축하는데 시간이 많이 걸리지만, 외부 솔루션을 통합하는데도 많은 노력이 필요하며, 회사가 확장됨에 따라 다른 솔루션으로 전환하는 경우 더욱 그러합니다.
4. 실험이 시스템 사양과 배포 방법에 통합될 필요가 있는가?
   • 실험은 연속적인 배포 프로세스의 필수적인 부분이 될 수 있습니다.
   • 실험과 엔지니어링 시스템이 사양과 배포를 처리하는 방법 사이에는 많은 시너지가 있으며, 더 복잡합 디버깅 상황에서와 같이 배포와 실험 간의 긴밀한 통합이 필요한 경우에는 제3자 솔루션으로는 더 어려울 수 있습니다.

단, 조직에서 독자 플랫폼을 구축하기 위한 투자와 투자에 대한 의지가 아직 부족할 수 있으므로, 독자적인 실험 플랫폼을 구축하기 위한 여부와 시기를 결정하기 전에 외부 솔루션을 활용해 더 많은 실험의 영향을 입증하는 것이 중요합니다.

2. 인프라와 도구들

• 실험 플랫폼을 만드는 것은 실험으로 혁신을 가속화하는 것에 그치지 않고 의사결정을 위한 결과의 신뢰도를 확보하는데도 중요합니다. 이는 기업에서 실험의 규모를 확대시키는 것에는 실험 플랫폼을 위한 인프라 구축뿐만 아니라 회사의 문화, 개발 및 의사결정 프로세스에 실험을 깊이 편입할 수 있는 도구와 프로세스 구축도 포함합니다.
• 실험 플랫폼의 목표는 실험을 셀프 서비스화하고 신뢰할 수 있는 실험을 실행하는데 드는 추가 비용을 최소화하는 것이 됩니다.

실험 플랫폼은 실험 설계 및 배포에서 실험 분석까지 프로세스의 모든 단계를 포함해야 합니다. 이러한 실험 플랫폼의 4가지 큰 구성 요소는 아래와 같습니다.

 

1. 사용자 인터페이스(UI)또는 애플리케이션 프로그래밍 인터페이스(API)를 통한 실험 정의, 설정 및 관리로 실험 시스템 설정에 저장됩니다.
2. 실험군 할당 및 파라미터를 커버하는 서버 측 및 클라이언트 측 실험 배포
3. 실험 계측
4. p값과 같은 통계 테스트와 지표의 정의 및 계산을 포함하는 실험 분석

 

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

• 많은 실험을 실행하기 위해 실험자들은 실험 라이프 사이클을 쉽게 정의, 설정 및 관리할 수 있는 방법이 필요합니다.
• 실험을 정의하거나 구체화하기 위해서는 다양한 필드가 필요하며, 플랫폼은 아래와 같은 이유로 실험이 여러 번 반복될 수 있도록 해야 합니다.
  • 실험 결과를 기반으로 기능을 진화시키기 위한 것으로, 이는 실험 중에 발견된 버그 수정을 포함할 수도 있습니다.
  • 실험을 점진적으로 보다 광범위한 실험대상자에게 시행한다. 이는 사전에 정의된 대상자들을 통하거나, 보다 큰 비율로 외부 사람들을 통해 이뤄질 수 있습니다.
• 모든 반복 시행은 동일한 실험 아래서 관리돼야 합니다. 일반적으로 플랫폼이 다르면, 서로 다른 반복 시행이 필요할 수 있지만 하나의 실험에 대해서는 반복할 경우, 하나의 결과만이 나와야합니다.
• 플랫폼에는 많은 실험과 많은 반복 시행을 쉽게 관리할 수 있는 인터페이스와 도구가 필요합니다.
  • 기능적으로는 다음의 사항들이 포함되야 합니다.
    
    1. 실험 사양서의 초안 작성, 편집 및 보존
    2. 실험 초안의 반복 시행과 현재 실행중인 반복 시행의 비교
    3. 중지된 실험을 포함한 과거 실험들 또는 실험의 시계열 보기
    4. 생성된 실험, ID, 변형 군 반복 시행을 자동적으로 할당하고, 실험 설정에 추가하는 것, 이는 실험 계측에 필요합니다.
    5. 설정 불일치, 유효하지 않은 타겟 실험 대상자 등과 같은 설정에 명백한 오류가 없는지 검증하는 것
    6. 실험 시작/ 종료뿐만 아니라 실험 상태 확인 ,인간의 실수에 방지하기 위해, 보통 실험 소유자나 특별히 허가를 받은 개인만이 실험을 시작할 수 있습니다. 그러나 사용자를 해치는 비대칭성 때문에, 실험 소유자에게 확실히 정보를 주기 위해 경보가 생성되지만, 누구나 실험을 중단할 수 있다.
• 실험이 실제 사용자에게 영향을 미치기 때문에 정적으로 실험하기 전 실험 실행 내용을 확인하기 위해 추가 도구나 워크로드가 필요합니다. 특히 실험이 대규모 실행되는 시기인 네번째 단계인 날기 단계에서는 중요하며, 이는 실험의 안정성을 높입니다.
  • 플랫폼에 의한 지원이 필요한 사항들은 다음과 같습니다.
    
    1. 실험 시작 및 확대 방법의 자동화
    2. 실시간에 가까운 모니터링 및 경보, 나쁜 실험 조기 포착
    3. 불량 실험 자동 탐지 및 종료

 

4. 실험 배포

실험 사양을 설정했다면 사용자의 경험에 영향을 줄 수 있도록 사양을 배포해야 합니다.

배포에는 일반적으로 다음 두 가지 구성 요소가 포함되며, 이는 다음과 같습니다.

 

1. 실험의 정의, 변형군의 할당 및 기타 정보를 제공하는 실험 인프라
2. 실험 할당에 따라 변형군마다의 행태를 구현하는 생산 코드 변경

 

실험 인프라는 다음을 제공해야 합니다.

 

• 변형군의 할당
  
  • 사용자 요청과 그 속성이 주어질때, 이 요청은 어떤 실험군과 변형군의 조합에 따라 할당돼야 하는가?
  • 변형군의 할당은 독립적이어야 합니다.
  • 대부분의 경우, 할당은 실험 사양 설정과 ID의 준랜덤 해시를 통해 이뤄집니다.
• 생산코드, 시스템 파라미터 및 값
  
  • 사용자가 적절한 경험을 제공받도록 어떻게 보장할 것인가?
  • 상이한 생산 코드와 어떤 코드와 어떤 시스템 파라미터를 어떤 값으로 변경해야 하는가를 관리해야 합니다.

4.1 변형군의 할당 

변형군의 할당에 관한 인터페이스는 성능상의 이유로 변형군의 할당에 관한 파라미터 값만을 출력할 것인지 파라미터 값을 포함한 완전한 설정을 출력할지를 선택할 수 있습니다.

 

어느 경우든 변형군 할당 서비스가 분리된 서버일 필요가 없으며, 공유 라이브러리를 통해 클라이언트나 서버에 직접 통합할 수 있습니다.

 

또한 어느 경우든, 변형군 할당 서비스의 단일한 구현은 의도치 않은 편차와 버그를 방지하는데 매우 중요합니다.

 

인프라를 구현할 때, 특히 대규모로 운용하는 경우에는 어떠한 성격이 중요한지 고려해야하며, 또한 클라이언트 기반 실험과 서버기반 실험 사이에는 실험의 배포까지도 차이가 존재합니다.

 

또 다른 고려사항은 워크플로우의 어디에서 변형군 할당이 일어나는가입니다. 변형군 할당은 여러 곳에서 발생할 수 있으며, 클라이언트 측 또는 서버 측을 정적으로 사용하는 생산 코드의 외부에서도 발생할 수있다. 따라 이러한 결정을 내리기 전에 더 나은 정보를 얻기위해서는 다음과 같은 주요 질문을 고려해야 합니다.

 

1. 워크플로우의 어느 시점에서 변형군에의 할당에 필요한 모든 정보가 존재하는가?
2. 실험 할당은 워크플로우의 한 시점에서만 수행하도록 허용할 것인가, 아니면 여러 시점에서 수행하도록 허용할 것인가?
   
   • 실험 플랫폼을 구축하는 초기 단계인 경우, 단순성을 유지하기 위해 실험 할당이 발생하는 시점은 하나만 지정하는 것을 권장합니다. 하지만 실험 할당 시점이 여럿인 경우, 이전에 발생한 실험 할당이 워크플로우 중에서 나중에 발생한 실험 할당에 편향을 주지 않도록 하기 위해 직교성의 보장이 필요합니다.

4.2 생산 코드, 시스템 파라미터 및 값

변형군을 할당했으므로 시스템이 사용자에게 적절한 실험을 제공하는지 확인해야 합니다.

 

아키텍처에는 아래와 같이 크게 세 가지 선택이 있습니다.

 

첫번째 아키텍처는 할당된 변형군에 기반한 코드 포크를 생성합니다.

 

variant = getVariant(userId)
IF (variatn == Treatment) then
	buttonColor = red
Else
	buttonColor = blue

 

• 장점
  • 변형 할당이 실제 코드 변경에 가깝기 발생하기 때문에 트리거링 처리가 더 쉽습니다.
• 단점
  • 포크된 코드 경로를 관리하는것이 상당히 어려워질 수 있기 때문에 기술적 부담을 증가시킬수 있습니다.

---

두 번째 아키텍처는 파라미터화된 시스템으로 이동하며, 여기서 실험에서 테스트 하고자 하는 모든 가능한 변경사항은 실험 파라미터에 의해 제어되어야 합니다. 또한 모드 포크를 계속 사용하는것을 선택 할 수도 있습니다.

 

variant = getVariant(userId)
IF (variatn == Treatment) then
	buttonColor = variant.getParam("buttonColor)
Else
	buttonColor = blue

 

또는 다음과 같이 바꿀 수 있습니다.

 

variant = getVariant(userId)
...
buttonColor = variant.getParam("buttonColor")

 

• 첫번째 아키텍처의 트리거링을 보다 쉽게 처리할 수 있는 장점을 유지하면서도 코드 부담을 줄일수 있습니다.

---

세 번째 아키텍처는 getVariant() 호출조차도 제거합니다. 대신, 워크플로우 초기에 변형군 할당이 수행되고, 변형군에 관련된 설정과 해당 변형군과 사용자에 대한 모든 파라미터 값이 남은 워크플로우로 전달됩니다.

 

buttonColor = config.getParam("buttonColor)

 

• 장점
  • 더 좋은 성능을 낼 수 있습니다.
  • 시스템이 확장되어 수백에서 수 천개의 파라미터를 가지게 되면, 실험이 단지 몇 개의 파라미터에만 영향을 미칠 가능성이 있더라도, 파라미터 처리를 최적화하는 것이 성능 측면에서 매우 중요하게 됩니다.
• 단점
  • 아키텍처는 변형군 할당을 조기에 수행하므로 트리거링을 처리하는 것이 어렵습니다.

 

어떤 아키텍처를 선택하든 실험 실행의 비용과 영향을 측정해야 합니다.

 

또한 실험 플랫폼은 성능에 영향을 미칠 수 있으므로, 실험 플랫폼 외부에서 일부 트래픽을 실행하는 것은 그 자체가 현장 속도 지연시간, CPU 활용율 및 기계 비용 또는 기타 요인 등의 플랫폼에 의한 영향을 측정하기 위한 실험이 됩니다.

 

5. 실험 계측

사용자 행동 및 시스템 성과와 같은 기본 계측을 이미 기록하고 있다고 가정합니다. 

 

특히 새로운 기능을 테스트 할 때, 새로운 기능을 반영하기 위해 이러한 계측 방법을 업데이트할 필요가 있으며 이렇게 함으로써 적절한 분석이 가능합니다.

• 첫번째 단계인 기어가기 단계에서는 이러한 수준의 계측에 초점을 맞추고, 리더십을 가진 사람은 계측이 지속적으로 검토되고 개선되고 있는지 확인해야 합니다.

어떤 실험 조건과 반복 실험이 실행되고 있더라도 실험에 대한 모든 사용자 요청과 상호작용을 계측해야 합니다.

• 모든 서버와 클라이언트에서 사용자의 실험 조건이 동시에 변경되는 것이 아니므로, 반복 실험의 계측은 특히 실험을 개시하거나 실험 대상을 확대할 때 특히 중요합니다.
• 또한 많은 경우, 실험을 하지 않았다면 어떤일이 일어났을 지와 같은 반사실적인 것을 원할 수 있습니다.
  • 특히 시스템 파라미터화된 아키텍처에서, 변형군 할당이 일찍 일어나는 경우, 반사실적 로깅이 매우 어렵지만 이는 필요한 과정입니다. 
  • 하지만 반사실적 로깅은 성능 관점에서 비용이 많이 발생하므로, 이것이 필요한 시기에 대한 지침을 수립해야 합니다. 

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

 

회사가 두번째 단계인 걷기에서 세번째 단계인 달리기 단계로 발전함에 따라 실험에 충분한 통계적 검정력을 제공하기 위해, 각 변형군에 사용자들의 충분한 비율이 할당되어야 합니다.

 

최대 검정력을 원하는 경우 실험은 50%/50%실행되며 모든 사용자를 포함합니다. 또한 실험횟수를 확대 하기 위해서는 사용자가 여러 실험에 참여해야 합니다. 이번에는 이것을 수행하는 방법에 대해서 알아보겠습니다.

 

6.1 단일 계층법

• 변형군의 할당은 사용자가 실험 변형군에 일관성 있게 할당되는 과정입니다. 
• 이는 두 번째 단계인 걷기단계에서 많이 사용됩니다.
• 일반적으로 실험의 수가 적으며, 각 실험 변형군에 총 트래픽의 특정 비율을 할당하는 식으로 모든 트래픽을 분할하는 것이 일반적입니다.
• 일반적으로 해시함수를 사용해 사용자를 버킷에 일관성 있게 할당합니다.
• 또한 버킷에 대한 사용자 할당은 무작위적이면서도 결정론적이여야합니다. 동일한 실험을 실행하는 두 버킷을 비교할 경우 버킷은 통계적으로 유사한 것으로 가정합니다.
  • 각 버킷에는 대략 동일한 수의 사용자가 있어야 합니다. 국가, 플랫폼 또는 언어와 같은 핵심 차원으로 분해한다면 버킷 내의 분할 결과도 거의 동일 할 것입니다.
  • 핵심 지표는 거의 동일한 값을 가져야 합니다.

단일 계층법에서 발생할 수 있는 문제 두 가지

1. 랜덤화 코드에서의 오류 발생시
   • 할당을 지속적인 모니터링을 통해 해결 할 수 있습니다.
2. 이월효과
   • 이전 실험이 현재 실험에 대한 버킷에 영향을 줄 수 있습니다.
   • 재정규화 또는 셔플링으로 모든 실험에서 버킷이 오염되지 않도록 해야 합니다.

단일계층법의 장점과 단점

• 장점
  • 간단하며 여러 실험을 동시에 실행할 수 있습니다.
  • 실험이 동시에 실행되는 경우가 거의 없는 초기 성숙 단계에서는 효과가 좋습니다.
• 단점
  • 각 실험이 충분한 검정력을 갖도록 충분한 트래픽이 필요하기 때문에, 동시에 실행할 수 있는 실험의 수에 제한이 존재합니다.
  • 초기 단계에서도 실험이 한 명의 사용자에 대해서만 수행되는 것이 아니라, 여러 명의 사용자에 대해서 동시에 실행되기 때문에, 단일 계측 시스템으로 실험 트래픽을 관리하는 것은 운영상 어려울 수 있습니다.

 

6.2 동시 실험

• 단일 계층법을 넘어서 실험을 확대하기 위해선, 각 사용자가 동시에 여러 실험을 할 수 있는 일종의 동시 실험 시스템으로 이행해야 합니다. 이를 해결하는 방법은 각 층이 단일 계층 방식처럼 동작하는 여러 실험 계층을 갖는 것입니다.
• 여러 계층 간에 실험의 직교성을 보장하려면, 사용자를 버킷에 할당할 때, 계층 ID를 추가해야 하며, 이는 제약 조건을 지정하는 다른 방법을 추가하는 곳이기도 하다는 특징이 있습니다.
• 요청이 들어오면 들어오면 변형군에의 할당이 각 계층에 대해 한 번씩 수행됩니다. 이는 제품 코드와 계측 모두 변형군 ID 벡터를 처리해야 함을 의미합니다.

동시 실험 시스템의 주요 문제_계층을 어떻게 결정하는가

동시 실험 시스템의 주요 문제를 해결하기 위한 방법의 몇 가지는 아래와 같습니다.

 

6.2.1 완전 요인 실험 설계를 완전 요인 플랫폼 설계로 확장하는것

• 완전 요인 실험설계에서는 모든 요인의 가능한 조합이 변형군으로 테스트됩니다.
• 이를 플랫폼으로 확장하면 사용자는 모든 실험에 동시에 참여하게 됩니다. 즉, 사용자는 실행 중인 모든 실험에서 한 변형군에 할당됩니다.
• 각 실험은 고유한 계층 ID과 연관되므로 모든 실험은 서로 직교하며 독립적입니다.
• 동일한 실험의 반복은 사용자에게 일관성있는 경험을 보장하기 위해 통상 동일한 해시 ID를 공유하며, 병렬 실험 구조에 의해 분산형 방식으로 실험수를 간단히 확대할 수 있습니다.

단점

• 잠재적 충돌이 발생할 수 있습니다.
• 두 개의 상이한 실험의 특정 실험조건이 공존하면, 사용자에게 좋지 않는 경험을 제공할 가능성이 존재합니다.
  • 예를 들어, 실험 1에서 파란색 텍스트를 테스트하고 실험2에서 파란색 배경을 테스트할 수 있습니다.
  • 이 경우, 우연히 두 가지 실험 모두에 할당된 사용자에게는 끔찍한 경험이었을 것입니다.

주의점

• 두 실험은 서로 상호작용 합니다. 따라 두 실험간의 상호작용을 고려하지 않으면 각 실험에 대해 독립적으로 측정한 결과도 부정확할 수 있습니다.
• 단, 모든 상호작용이 나쁜 영향을 초래하는 것은 아니라는 점에 유의해야하며, 때로는 두 개의 실험효과를 독립적으로 더하는 것보다 상호작용으로 더 좋은 결과를 보이는 경우도 존재합니다.

정리

• 트래픽을 분할할 때 통계적 검정력의 감소가 상호작용의 잠재적 우려보다 큰 경우 요인 플랫폼 설계를 할 수 있습니다.
• 이러한 실험을 독립적으로 설정한다면, 어떤 실험이 상호작용을 해서 상호작용에는 어떤 효과가 있을까의 분석이 가능합니다.
• 물론 유의한 상호작용이 없는 경우에도 각 실험은 개별적으로 분석할 수 있으며, 각 실험은 최대의 검정력을 얻기 위해 이용 가능한 트래픽 전량을 향유할 수 있습니다.

6.2.2 계층적 플랫폼 설계 & 제약조건 기반 플랫폼 설계

• 열약한 사용자 경험을 방지하기 위해 계층적 플랫폼 설계 또는 제약조건 기반 플랫폼 설계를 사용할 수 있습니다.
• 계층적 설계
  • 시스템 파라미터가 계층으로 분할되므로, 결합해서 열악한 사용자 경험을 초래할 가능성이 있는 실험은 반드시 동일한 계층에 있어야 하고, 설계에 의해 동일한 사용자에 대해 실행되는 것을 반드시 방지해야 합니다.
  • 예를 들어 공통 UI요소(예 : 페이지 헤더 내의 모든 정보)를 위한 하나의 계층, 본문을 위한 또 하나의 계층, 백엔드 시스템으 위한 세번째 계층, 파라미터를 위한 네번째 계층 등이 있을 수 있습니다.
• 제약 조건 기반 설계
  • 실험자가 제약조건을 지정하고, 시스템은 그래프 색상 알고리즘을 사용해 우려사항을 공유하는 어떤 두 개의 실험이 사용자에게 동시에 적용되지 않도록 합니다.
  • 자동적으로 상호작용을 탐지하기 위한 시스템은 제약 조건 기반 설계의 확장을 통해 가능합니다.

 

7. 실험 분석 도구

 

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

 

7.1 분석 자동화의 단계

 

1. 데이터 처리

• 목적 : 실험결과를 계산하고 시각화하는데 사용할 수 있는 상태로 데이터를 가져오는 것
• 사용자 요청에 대한 계측은 여러 시스템에서 발생할 수 있으므로, 데이터처리에는 일반적으로 상이한 로그를 분류 및 결합하고, 로그를 정제하고 세션화 및 증강하는 것이 포함됩니다. 또란 이러한 과정을 데이터 쿠킹 이라고 부릅니다.

 

2. 데이터 계산

• 목적 : 주요 지표 요약 및 강조 표시를 통해 의사 결정자가 출시/출시보류 결정을 내리는데 도움을 주는 것
• 세그먼트별 지표의 데이터 계산, p값/신뢰구간 계산, SRM 점검과 같은 신뢰도 검사도 필요합니다. 또한 어떤 세그먼트가 자아 흥미로운지 자동으로 파악하기 위한 분석을 포함할 수 있습니다.
• 종합평가기준을 검사하고 분할을 수행하기 전에 신뢰도 검사를 먼저 수행해야 한다는 점을 유의해야 합니다.
• 또한 실험 데이터를 보기 전에도 모든 데이터의 처리와 계산은 철저히 테스트되고 점검되어 이들 프로세스의 신뢰도 역시 보장해야 합니다.

 

3. 데이터 시각화

• 목적 : 이해하기 쉬운 방법으로 주요 지표와 흥미로운 지표와 세그먼트를 강조하기 위함
• 지표는 상대적 변화로 표시되며 결과가 통계적으로 유의한 경우, 종종 현저한 변화를 두드려지게 하기 위해 색상 코드는 사용합니다.
• 또한 지적인 무결성을 추구하는 문화를 구축하기 위해 결과가 추적될 수 있고, 접근 가능한 공통의 정의를 사용하고, 정의가 자주 검토되고 협의 및 업데이트되는 것을 보장할 필요가 있습니다.

 

7.2 시각화 도구를 사용하는 이유

 

조직이 세번째 단계인 달리기와 마지막 단계인 날기 단계로 전환함에 따라 많은 지표가 존재할 수 있습니다.

 

이는 계층별 또는 목적별로 지표를 그룹화 하는 경우가 여기에 해당합니다.

 

지표의 수가 증가함에 따라 다중 테스트가 더욱 중요해지고, 실험자들로부터 다음과 같은 한 가지 공통적인 문제가 발생한다는 것을 발견했다. 해당 지표는 무관해 보이는데 왜 크게 움직였습니다.

 

이 경우 교육이 도움이 될 수도 있지만, 표준 0.05 보다 작은 p값 임계값을 사용하는 도구의 옵션도 효과적이다.

 

임계값이 낮아지만 실험자는 가장 유의미한 지표를 신속하게 파악할 수 있다.

 

시각화 도구를 사용해 모든 실험 결과에 대한 지표별 뷰를 생성하면 이를 쉽게 파악할 수 있습니다

 

이 뷰를 통해 이해관계자는 주요 지표의 글로벌 상태를 면밀히 모니터링 하고 어떤 실험이 가장 효과적인지 확인할 수 있습니다. 또한 이러한 투명성은 실험 소유자와 지표 소유자 간의 대화를 장려하며, 회사에서의 실험에 대한 전반적인 지식을 증가시킵니다.

 

또한 시각화 도구는 제도적 기억에 접근을 가능하게 해 무엇이 실험됐는지, 왜 그러한 의사결정이 내려졌는지 그리고 그러한 지식의 발견과 학습으로 이어지는 성공과 실패를 포착하기에 매우 적합한 도구입니다.

---

Q. 확인 문제

다음은 실험성숙도 모델의 단계에 해당하는 목표들이다. 목표를 보고 해당 하는 단계를 작성해주세요. 

 

1. 많은 실험을 규모있게 실행하는 것

2. 모든 실험과 변화를 제도적 기억으로 만드는 것

3. 표준적인 지표를 책정해 조직이 더 많은 실험을 실행할 수 있도록 하는 것 

4. 기초적인 전제 조건과 구체적인 가설 테스트에 필요한 요약 통계량을 계산할 수 있는 계측

 

A. 정답

드래그하면 오른쪽에 정답이 나옵니다 :)

 

1. 달리기(run)

2. 날기(fly)

3. 걷기(walk)

4. 기어가기(crawl)