[A/B테스트] 02 조직의 실험 플랫폼은 어떻게 구축되어 있을까?

책 <A/B 테스트(론 코하비.다이앤 탕.야 쉬 지음)>의 '04 실험 플랫폼과 문화'를 요약 및 관련 사례조사를 정리한 내용입니다.

---

1. 실험 성숙도 모델

조직이 강력하고 신뢰할 수 있는 실험 플랫폼을 구축하고, 실험 문화를 정착하기 위해서는 실험 성숙도를 관찰하고 개선하는 것이 중요합니다. 조직들이 A/B 실험을 통해 모든 변화를 실행하는 과정에서 겪을 수 있는 단계를 구성한 것이 '실험 성숙도 모델'이고 4단계가 있습니다.

 

아래 표를 보며 단계별 특징 몇 가지를 살펴보겠습니다.

출처 : Trustworthy Online Controlled Experiments (Ron Kohavi, 2020)

 

- 여기어때 항공팀 사례

22년 9월, A/B테스트 제품 개발툴 기업인 '핵클'의 인터뷰에서 '여기어때 항공팀'은 조직이 실험 성숙도 모델에서 걸음마 단계라고 말했습니다. 종종 ‘해당 안이 당연히 좋을 것 같은데 꼭 실험을 해야할까요?’하는 질문을 받기도 하는데, 막상 실험을 진행해보면 당연히 좋을 것이라고 생각한 안에서도 안 좋은 지표가 보일 때가 있었다고 하는데요. 이는 실험 문화가 정착되지 않은 걷기 단계의 특징이라고 할 수 있겠죠.

트래픽이 적은 항공 같은 신규 서비스는 아웃 라이어(outlier;통계적 자료 분석의 결과를 왜곡시키는 극단값)가 발생하면 P값이 틀어지기도 하기 때문에, '이 결과를 어떻게 모니터링할지'와 같은 부분에서 하나하나 규칙을 만들어가고 있는 단계를 거쳤습니. 또 ‘트래픽 양에 따라 어떤 case는 성공했다고 본다’와 같은 정책들을 만들어 오고 있기 때문에, 지금은 다음 단계로 발전했겠죠?

 

이어서 성숙도 모델 단계와 관련없이 조직이 중점적으로 다뤄야 하는 몇 가지 분야를 알아보겠습니다.

① 리더십

실험을 중심으로 하는 강력한 문화를 확립하고 A/B 테스트를 제품 개발 과정의 필수 요소로 포함시키기 위해서는 적극적인 리더십이 매우 중요합니다. 조직은 정착돼 있는 규범, 신념과 패러다임 및 HiPPO(최고의 보수를 받는 사람의 의견)에 강하게 의존하기 때문에 이들과 양립할 수 없는 새로운 지식을 제멜바이스 반사에 따라 거부할 수 있습니다. 지속적인 측정, 실험, 지식 수집을 통해서만 원인에 대한 기초적 이해와 모델의 작동에 대한 근본적 이해에 도달할 수 있습니다.

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

② 프로세스

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

교육의 경우, 실험 설계 및 실험 분석 중에 저스트-인-타임 프로세스를 수립하는 것은 조직을 실제로 한 단계 끌어올릴 수 있습니다. 구글의 예를 보면, 검색 작업을 하는 실험자들이 실험을 하고 싶을 때는 전문가들이 검토한 체크리스트를 작성해야 했습니다. 체크리스트에는 기본적인 질문들뿐만 아니라 검정력을 분석하기 위한 질문들도 있었습니다. 검정력 계산 도구를 체크리스트에 연결시키는 것으로 자동적으로 실험이 충분한 검정력을 갖고 있는지를 확인하게 했습니다. 이렇게 조직이 충분히 상향 평준화되면, 검색 조직은 더이상 그러한 명시적인 체크리스트 과정이 필요하지 않을 정도로 발전하게 됩니다.

③ 구축 vs 구매

빙, 구글, 링크드인은 초기에는 실험 플랫폼 용량 자체에 의해 성장이 둔화됐지만, 2017년 종합대조실험이 기능의 롤아웃을 위한 안전한 배포 매커니즘으로 자리잡음에 따라 종합대조실험을 대규모로 사용하기 시작한 마이크로소프트 오피스의 경우 '빙'에서 먼저 실험 플랫폼이 사용됐기 때문에 플랫폼은 제한 요인이 되지 않았습니다. 그래서 2018년 빙은 실험이 600% 이상 성장했습니다. 조직이 '모든 것을 테스트하는' 문화에 도달하면 성장이 둔해지며, 제약요인은 아이디어를 종합대조실험에 배포될 수 있는 코드로 변환하는 능력이 되는 것입니다.

반드시 모든 기업이 자체 실험 플랫폼을 구축해야 하는 것은 아닙니다. 특히 성숙도 모델의 걷기 단계에서 구축 또는 구매를 결정하는 것은 투자수익률(ROI) 결정인데요! 이 결정을 내릴 때 고려해야 할 몇 가지 질문을 정리해 보았습니다.

• 외부 플랫폼이 필요로 하는 기능을 제고할 수 있는가? : 실험 유형, 웹사이트 속도, 사용하고자 하는 차원과 지표 등
• 자체 구축하면 비용이 어떻게 될까? : 대규모 시스템을 구축하는 것은 비용이 많이 든다.
• 실험이 증가하면서 어떤 것이 필요할까? : 실험에 모멘텀과 수요가 있고, 양이 증가할 가능성이 있다면 내부에서 구축
• 실험이 시스템 사양과 배포 방법에 통합될 필요가 있는가? : 외부 솔루션을 활용해 더 많은 실험의 영향을 입증하기

 

2. 인프라와 도구들

실험 플랫폼 구조 예시 - 우아한 형제들 배달의 민족 서버 파트 구조

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

빙, 링크드인, 또는 구글에서의 실험 플랫폼을 살펴보면 4가지 큰 구성 요소가 있습니다.

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

각 구성 요소들을 자세히 알아볼까요?

 

① 실험 정의, 설정과 관리

많은 실험을 실행하기 위해 실험자들은 실험 라이프 사이클을 쉽게 정의, 설정 및 관리할 수 있는 방법이 필요합니다. 실험을 정의하거나 구체화하기 위해서는 소유자, 이름, 설명, 시작일과 종료일 등의 필드가 필요합니다. 또한 플랫폼은 버그 수정 등의 이유로 실험이 여러 번 반복될 수 있도록 해야 합니다.

모든 반복 시행은 동일한 실험 아래서 관리돼야 하고, 플랫폼에는 많은 실험과 많은 반복 시행을 쉽게 관리할 수 있는 인터페이스 그리고/또는 도구가 필요합니다.

또한 실험이 실제 사용자에게 영향을 미치기 때문에 정식으로 실험하기 전 실험 내용을 확인하기 위해 추가 도구나 워크로드가 필요합니다. 옵션들을 기본적인 점검에 추가해 특히 실험이 대규모 실행되는 시기인 날기 단계에서는 플랫폼에 의한 세 가지 사항에 대한 지원이 필요합니다. 이것들은 실험의 안전성을 높여 줍니다.

• 실험 시작 및 확대 방법의 자동화
• 실시간에 가까운 모니터링 및 경보, 나쁜 실험 조기 포착
• 불량 실험 자동 탐지 및 종료

 

② 실험 배포

실험 사양을 설정했다면 사용자의 경험에 영향을 줄 수 있도록 사양을 배포할 필요가 있습니다. 배포에는 일반적으로 아래 두 가지 구성 요소를 포함합니다.

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

실험 인프라는 변형군의 할당, 생산 코드, 시스템 파라미터 및 값을 제공해야 합니다. 이 인터페이스는 실험 플랫폼 구조에서 변형군 할당 서비스로 표시되며, 성능상의 이유로 변형군에의 할당에 관련된 파라미터 값만을 출력할 것인지 파라미터 값을 포함한 완전한 설정을 출력할지를 선택할 수 있습니다.

변형군을 할당한 후엔 시스템이 사용자에게 적절한 실험을 제공하는지 확인해야 합니다. 아키텍처에는 크게 세 가지 선택이 있습니다.

구분	설명	장점	단점
첫 번째	할당된 변형군에 기반한 코드 포크를 생성한다.	변형 할당이 실제 코드 변경에 가깝게 발생해서 트리거링 처리가 더 쉽다.	포크된 코드 경로를 관리하는 것이 어려워져 기술적 부담을 증가시킬 수 있다.
두 번째	파라미터화된 시스템으로 이동하며, 여기서 실험에서 테스트하고자하는 모든 가능한 변경사항은 실험 파라미터에 의해 제어돼야 한다.	두 번째 옵션을 사용하는 경우 트리거링을 보다 쉽게 처리할 수 있고, 코드 부담을 줄인다.	-
세 번째	getVariant() 호출조차도 제거한다. 대신, 워크플로우 초기에 변형군 할당이 수행되고, 변형군에 관련된 설정과 해당 변형군과 사용자에 대한 모든 파라미터 값이 남은 워크플로우로 전달된다.	시스템이 확장돼 수백에서 수천 개의 파라미터를 갖게 되면, 파라미터 처리를 최적화하는 것이 좋은 성능을 낸다.	변형군 할당을 조기에 수행하므로 트리거링을 처리하는 것이 더 어렵다.

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

 

③ 실험 계측

사용자 행동 및 시스템 정의와 같은 기본 계측을 이미 기록하고 있다고 가정해 볼까요? 특히 새로운 기능을 테스트할 때, 새로운 기능을 반영하기 위해 이러한 계측 방법을 업데이트할 필요가 있으며 이렇게 함으로써 적절한 분석이 가능합니다. 기어가기 단계에서는 이러한 수준의 계측에 초점을 맞추고, 리더십을 가진 사람은 계측이 지속적으로 검토되고 개선되고 있는지 확인해야 합니다.

어떤 실험 조건과 반복 실험이 실행되고 있더라도 실험에 대한 모든 사용자 요청과 상호작용을 계측해야 합니다. 반복 실험의 계측은 특히 실험을 개시하거나 실험 대상을 확대할 때 특히 중요합니다.

달리기와 날기 단계에 도달하면 반사실적인 것, 즉 실험을 하지 않았다면 어떤 일이 일어났을지를 기록하기를 원할 수 있는데요! 반사실적 로깅은 성능 관점에서 비용이 많이 들 수 있기 때문에, 이것이 필요한 시기에 대한 지침을 수립해야 합니다. 제품에 사용자가 피드백을 입력할 수 있는 공간이 있는 경우 그 피드백과 변형군 ID가 반드시 기록돼야 하는데, 이것은 피드백이 변형군에 고유한 경우에 특히 유용합니다.

 

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

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

 

단일계층법

변형군의 할당은 사용자가 실험 변형군에 일관성 있게 할당되는 과정입니다. 걷기 단계에서는 일반적으로 실험의 수가 적고, 각 실험 변형군에 총 트래픽의 특정 비율을 할당하는 식으로 모든 트래픽을 분할하는 것이 일반적입니다. 예를 들어, 트래픽의 60%가 하나의 대조군과 두 개의 실험군으로 구성된 실험에 할당되고, 나머지 40%가 하나의 대조군과 하나의 실험군으로 구성된 실험에 할당될 수 있습니다.

버킷에 대한 사용자 할당은 무작위적이면서도 결정론적이어야 하고, 할당을 모니터링하는 것이 핵심인데요! 구글, 마이크로소프트 같은 회사들은 버킷 기능을 모니터링해 랜덤화 코드에서 오류를 발견했습니다.

장점	단점
- 간단하다. - 여러 실험을 동시에 실행할 수 있다(각 사용자는 단일 실험에만 있다).	- 각 실험이 충분한 검정력을 갖도록 충분한 트래픽이 필요하기 때문에, 동시에 실행할 수 있는 실험의 수에 제한이 있다. - 초기 단계에서도 여러 명의 사용자에 대해서 동시에 실행되기 때문에, 운영상 어렵다. - 동시성을 관리하려면 수동 방식을 해야 하는데, 이것으로는 규모를 확장시킬 수가 없다.

 

동시 실험

실험을 확대하기 위해서는 각 사용자가 동시에 여러 실험을 할 수 있는 일종의 동시 실험 시스템으로 이행해야 합니다. 이를 달성하는 한 가지 방법은 각 층이 단일계층 방식처럼 동작하는 여러 실험 계층을 갖는 것입니다. 여러 계층 간의 실험의 직교성을 보장하려면, 사용자를 버킷에 할당할 때 계층 ID를 추가하면 됩니다.

리퀘스트가 들어오면 변형군에의 할당이 각 계층에 대해 한 번씩 수행되는데, 이는 제품 코드와 계측 모두 변형군 ID 벡터를 처리해야 함을 의미합니다. 동시 실험 시스템의 주요 문제는 계층을 어떻게 결정하는가에 있고, 몇 가지 옵션이 있습니다.

한 가지는 완전 요인 실험 설계를 완전 요인 플랫폼 설계로 확장하는 것입니다. 사용자는 실행 중인 모든 실험에서 한 변형군에 할당되는데, 각실험은 고유한 계층 ID와 연관되므로 모든 실험은 서로 직교합니다. 동일한 실험의 반복은 사용자에게 일관성있는 경험을 보장하기 위해 통상 동일한 해시ID를 공유합니다.

이 플랫폼 설계의 주요 단점은 잠재적 충돌로, 두 개의 상이한 실험의 특정 실험조건이 공존하면 사용자에게 좋지 않은 경험을 제공할 가능성을 피할 수 없습니다.

열악한 사용자 경험을 방지하기 위해 계층적 플랫폼 설계 또는 제약조건 기반 플랫폼 설계를 사용할 수 있습니다. 확장성을 위해 구글, 링크드인, 마이크로소프트 및 페이스북은 이러한 설계의 일부 변형된 버전을 사용하고 있다고 합니다.

계층적 설계에서는 시스템 파라미터가 계층으로 분할되므로, 결합해서 열악한 사용자 경험을 초래할 가능성이 있는 실험은 반드시 동일한 계층에 있어야 하고, 설계에 의해 동일한 사용자에 대해 실행되는 것을 반드시 방지해야 합니다.

제약조건 기반 설계에서는 실험자가 제약조건을 지정하고, 시스템은 그래프 색상 알고리듬을 사용해 우려사항을 공유하는 어떤 두 개의 실험이 사용자에게 동시에 적용되지 않도록 합니다. 자동적으로 상호작용을 탐지하기 위한 시스템은 이것의 유용한 확장이 될 수 있습니다.

 

⑤ 실험 분석도구

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

먼저 분석을 자동화하려면 데이터 처리가 필요한데, 여기서 목적은 실험 결과를 계산하고 시각화하는 데 사용할 수 있는 상태로 데이터를 가져오는 것입니다.

처리가 끝난 데이터를 얻으면, 주요 지표를 요약하고 강조 표시해 의사 결정자가 출시/출시 보류 결정을 내리는 데 도움을 주는 것이 목표입니다. 이를 위해서는 세그먼트별 지표의 데이터 계산, p값/신뢰구간 계산, SRM 점검과 같은 신뢰도 검사도 필요합니다.

계산이 끝나고 나면 이해하기 쉬운 방법으로 주요 지표와 흥미로운 지표와 세그먼트를 강조하기 위해 데이터 시각화를 작성하는 것이 가능합니다. 시각화 도구를 사용해 모든 실험 결과에 대한 지표별 뷰를 생성하면, 이 뷰를 통해 이해관계자는 주요 지표의 글로벌 상태를 면밀히 모니터링하고 어떤 실험이 가장 효과적인지 알 수 있습니다.

따라서 시각화 도구는 제도적 기억에 접근을 가능하게 해 무엇이 실험됐는지, 왜 그러한 의사결정이 내려졌는지 그리고 그러한 지식의 발견과 학습으로 이어지는 성공과 실패를 포착하기 위한 훌륭한 관문이라고 할 수 있습니다.

 

 

지금까지 실험 플랫폼의 구성 요소를 정리해 보았는데, 자료를 찾아보던 중 여러 기업들에서 실험 플랫폼 구축기를 올려 주고 있는 것을 발견했습니다. 실험 플랫폼을 구축하고 있는 실제 기업들의 사례를 자세히 알고 싶은 분들을 위해 우아한형제들, 오늘의집, 뱅크샐러드의 기술 블로그를 첨부하며 마무리하겠습니다~

 

1. 우아한 형제들-실험과 기능플래그를 위한 실험플랫폼 구축하기

실험과 기능플래그를 위한 실험플랫폼 구축하기 | 우아한형제들 기술블로그

2. 오늘의 집-A/B 실험 플랫폼 구축기

오늘의집 A/B 실험 플랫폼 구축기 - 오늘의집 블로그

3. 뱅크샐러드-뱅크샐러드의 실험플랫폼 분석 인프라 살펴보기

뱅크샐러드의 실험플랫폼 분석 인프라 살펴보기 | 뱅크샐러드

---

이번 글에서도 간단한 퀴즈를 하나 준비했습니다. 열심히 풀어 주세요! (ง •̀_•́)ง

Q. 다음 '실험 플랫폼과 문화'에 대한 설명 중 틀린 것을 골라서 바르게 고쳐주세요.

① 실험 성숙도 모델에서 실험 횟수가 일 1회인 단계는 '달리기' 단계이다.

② 조직이 중점적으로 다뤄야 하는 분야에는 리더십이 있고, 리더는 실험 플랫폼과 도구를 조직에 제공만 하는 것이 좋다.

③ 성숙도 모델의 걷기 단계에서 실험 플랫폼의 구축 또는 구매를 결정하는 것은 투자수익률(ROI) 결정을 내리는 것이다.

④ 완전 요인 플랫폼 설계의 단점은 잠재적 충돌인데, 이러한 안 좋은 사용자 경험을 방지하기 위해 계층적 플랫폼 설계를사용할 수 있다.

답(드래그): ② 리더는 단지 실험 플랫폼과 도구를 조직에 제공'만' 하는 것이 아니라, 조직이 데이터 중심 결정을 내릴 수 있도록 적절한 인센티브, 프로세스 및 권한을 제공해야 합니다.