A/A 테스트를 아시나요?

A/B 테스트를 진행하기 전, 해당 실험 플랫폼의 결과를 신뢰할 수 있는지 어떻게 확인할까요? 이런 경우 A/A 테스트를 먼저 실험해볼 것을 권장합니다. 변화가 없는 같은 페이지를 두고 A vs A로 실험하는 것입니다. 어느 한쪽이 더 개선율이 높다는 유의미성이 검증되면, 사실상 해당 실험 플랫폼은 앞으로도 신뢰할 수 없는 결과를 제공할 확률이 높습니다. 오늘은 A/A 테스트가 무엇인지, 실험 플랫폼을 비교해보고 핵클(Hackle)을 통한 A/A TEST 진행 방법에 대해 알아보겠습니다. 

A냐 B냐 그것이 문제로다

유튜브 앱 댓글 정렬에 ‘시간순’ 필터가 생겼습니다. 시간순 필터는 타임코드가 동반된 댓글들만 모아, 유저가 해당 영상 타이밍에 맞는 다른 유저들의 댓글을 쉽게 확인할 수 있도록 돕는 자동 댓글 정렬 기능입니다. 6개월 전부터 카더라로 접한 시간순 필터를 드디어 마주하게 되었는데요. 아직까지 BETA 배지가 붙어있는 걸로 보아, 점진적 배포를 통해 6개월만에 제 아이디가 실험군에 포함된 것으로 보입니다. 

이렇듯 프로덕트 관리자는 사용자 경험에 영향을 주는 기능이나 제품 기획 시, 좌측 사진처럼 기존안을 보여주는 대조군 A, 우측 사진처럼 새로운 기능이 동반된 실험군 B로 유저 그룹을 나누어 A/B 테스트를 진행합니다. (A/B를 넘어 A/B/C/D/E 등 동시에 다양한 문제 해결 방법으로 테스트를 진행할 수도 있습니다.)

A/B 테스트를 통해 해당 기능이 원했던 목적대로 특정 문제를 해결하는지, 기획 당시의 가설을 검증할 수 있습니다. 또한 문제 해결에 얼마나 효과적인지 그 수치를 측정할 수도 있습니다. 이러한 변화로 인해 다른 지표나 사용자 경험에는 문제가 없는지 등 리스크도 동시에 확인이 가능합니다. 

그런데 말입니다. A/B Testing 툴이 말해주는 테스트의 결과, 그대로 믿어도 될까요? 알고 보니 잘못된 데이터라던가, 목적과 다른 지표를 설정한다는 등 과정에서의 실수가 있을 수도 있죠. 또한 마케팅으로 인한 뜻밖의 변수나 모수가 너무 적다는 등 실험 진행 과정에서도 충분히 외부의 영향을 받을 수 있습니다. 만약 모수가 충분하고 외부 변수도 없는 데이터로 적합한 지표를 잘 세팅했다면, 실험 플랫폼의 결과를 그대로 믿어도 될까요? 이를 확인하기 위해 먼저 A/A 테스트를 진행하는 것이 좋습니다.

A/A 테스트란?

실험 플랫폼의 신뢰도를 측정하기 위한 테스트로 보통 실험 플랫폼을 교체할 때 미리 진행합니다. 대조군 A와 동일한 페이지를 실험군 B로 설정하여 세팅 자체는 A vs B로 진행하지만, 사실상 같은 콘텐츠와 기능을 노출하기 때문에 A vs A의 실험 결과를 측정합니다. 대부분의 A/B 테스트는 특정 지표의 전환율 상승을 목표로 진행한다면, A/A 테스트는 결과에 차이가 없는지 확인을 목표로 진행합니다. 

웬만하면 서비스 체험 기간에 진행하여, 구매 및 구축 전 미리 해당 플랫폼의 신뢰도를 측정하는 것을 권장합니다. 더불어 이미 검증하여 사용하는 플랫폼이라 하더라도, 종종 A/A 테스트를 진행하여 해당 실험 결과의 신뢰도를 유지할 수 있도록 합니다. 다만 A/A 테스트는 많은 모수를 필요로 하기 때문에, 충분한 기간을 두고 진행하는 것이 좋습니다. 

테스트 실험 플랫폼 ‘핵클(Hackle)’

다음은 실험 플랫폼 핵클(Hackle)입니다. 최근 A/A 테스트에 관심을 갖게 된 이유가 실제로 실험 플랫폼을 옵티마이즐리에서 핵클로 교체했기 때문인데요. 플랫폼을 교체한 이유와 사용하면서 느낀 핵클의 장단점에 대해 알아보겠습니다.

1) 이용 요금

먼저 사용하던 옵티마이즐리의 경우, 연간 이용 요금이 최소 $36,000로 약 4,000만 원에서 시작하며, 연 단위 계약으로만 이용할 수 있습니다. 그리고 웹과 앱을 실험할 수 있는 구독 모델이 따로 분류되어 웹과 앱을 둘 다 실험해야 하는 서비스의 경우, 그만큼의 비용을 추가로 지불해야 합니다. (2021년 12월 기준)

반면 핵클은 무료 체험 기간을 통해 우선 A/B 테스트를 비용의 장벽 없이 도입할 수 있습니다. 또한 사용량에 기반한 과금 정책, 월 단위로 이용 가능한 요금제를 운영하고 있어 앱과 웹을 둘 다 실험할 경우, 옵티마이즐리처럼 구독 모델을 두 번 계약할 필요가 없어 합리적입니다.

2) 커뮤니케이션 비용

옵티마이즐리는 한국에 오피스를 운영하지 않으며, 한국어를 통한 지원 역시 제공되지 않습니다. 이로 인해 기술적으로 해결해야 하는 문제가 발생한 경우, 시차나 언어로 인한 커뮤니케이션 비용이 발생할 수밖에 없습니다. 하지만 핵클은 한국어 서비스 가이드부터 직관적인 대시보드로 인해 누구나 쉽게 이용이 가능합니다. 또 익숙한 채널톡 챗봇을 통해 언제든 도움을 구할 수 있으며, 국내 유저들을 통해 실험된 다른 서비스들의 사례나 내부 세미나 자료 공유 등을 통해 인사이트를 얻기에 편리합니다.

3) 기술 부채 방지

핵클은 종료된 실험의 경우, 따로 코드 정리 요청 메일을 주는 점이 인상 깊습니다. 종료된 A/B 테스트와 관련된 코드를 제거하지 않으면, 테스트의 그룹 분배 코드에 대한 기술 부채가 증가해 서비스 안정성에 영향을 미칠 수 있다는 내용입니다. 사용량에 기반한 과금 정책을 운영하는 핵클에서 종료된 실험임에도 트래픽이 발생하고 있다면, 먼저 제거 요청 메일을 준다는 점이 고객 입장에선 감동적인 포인트로 다가왔습니다.

더불어 A/B 테스트 진행 중 이상 징후 발생 시, 해당 실험을 세팅한 사용자는 직접 모니터링 알람 메일을 받아볼 수 있습니다. 다만 한 가지 아쉬웠던 부분은 부정적인 시그널에만 알림 기능이 제공되는 점입니다. 해당 테스트 결과의 신뢰도를 표현하는 p-value가 0.05 미만이 되었거나, 유의미하다는 Significant 배지가 일정 기간 지속된 경우 등 실험의 긍정적인 시그널에도 알림을 제공한다면, 더 빠른 확인이 가능할 것으로 기대됩니다. 

핵클로 실험해본 A/A 테스트

그럼 핵클로 A/A 테스트를 진행해보겠습니다. 목록에는 간단하게 실험키, 실험 이름, 실험 상태, 실험 생성일 정보가 담겨있습니다. 실험 이름은 [부서명] 실험 위치 및 목적에 대해 간단히 기입하면 A/B 테스트를 동시에 진행하는 다른 팀과 한눈에 비교 가능합니다. 이를 위해 [+ 새 A/B 테스트 생성하기] 버튼을 클릭합니다.

A/A 테스트는 최대한 많은 모수가 확보될 수 있는 환경에서 진행하는 것이 좋습니다. 최대한 많은 사람들을 대상으로 실험해야 해당 데이터가 유의미하다는 검증을 더 빠르게 확인할 수 있기 때문입니다. 분모에 해당될 값으로 메인 페이지를 본 이벤트로 권장합니다.

분자에 해당하는 값은 가장 많은 행동을 유도하면서도 변수가 없는 타깃을 고릅니다. 예를 들어 요즘 IT의 메인 페이지에서 유저들은 서비스 콘텐츠를 가장 크게 분류한 1) GNB (NEW, 기획, 디자인, 개발, 프로덕트, 아웃소싱, 프리랜싱), 2) 검색창, 가장 강조되어 노출되는 3) 메인 콘텐츠 (아티클: 빙글빙글 돌아가는 로딩만 로딩이 아니야!), 그 외 세로 레이아웃의 4) 서브 콘텐츠 등을 클릭할 수 있습니다. 

GNB, 검색창, 메인 콘텐츠, 서브 콘텐츠 중 유의미한 데이터 확보를 위해 가장 많은 행동을 유도하는 항목은 어떤 것이 있을까요? GNB는 유저의 관심사에 따라 분산된 확률이 높기에 배제합니다. 어차피 A vs A 같은 페이지를 보여주더라도 콘텐츠 역시 유입 유저의 관심사가 클릭을 좌우하기 때문에, 가장 변수가 없을 타깃인 ‘검색창'을 클릭한 or 검색 결과 화면을 본 이벤트로 분자 값을 설정합니다.

1) 테스트 정보 기입 

간단한 A/B 테스트 정보를 기입합니다. 이름에는 간단한 부서명과 실험 위치, 목적에 대해 작성합니다. 설명에는 간단한 설명을 기재할 수도 있고, 저의 경우 실험 문서 링크를 첨부하고 있습니다. 선택사항이지만 가설까지 작성하여 해당 대시보드를 보는 사람들에게 왜 이 실험을 진행하는지, 한번 더 공통된 목적을 가질 수 있도록 리마인드 합니다. 

• 이름: [웹사이트 플랫폼] 메인 페이지 A/A TEST
• 설명: https://www.notion.so/wishket/experiment/docs (설명을 위한 예시 링크입니다.)
• 가설: PO는 A/A 테스트를 통해 변경된 실험 플랫폼의 결과를 신뢰할 수 있다.

2) 테스트 그룹 설명 기입 

다음은 기존안 A와 개선안 B에 대한 설명을 간단히 기입합니다. A/A 테스트의 경우, 변화 없이 동일한 페이지를 보여줄 예정이기 때문에 동일하게 기입합니다. 

요즘IT의 경우 데스크톱에서는 검색이 인풋창으로, 모바일 웹에서는 돋보기 아이콘으로 UI가 다르게 설정되어 있기 때문에, 비즈니스 관련 콘텐츠는 데스크톱으로 더 많이 본다는 가정하에 데스크톱 유저로만 타깃을 한정합니다. 

• 그룹 A: 요즘IT 메인 페이지를 본 데스크톱 유저
• 그룹 B: 요즘IT 메인 페이지를 본 데스크톱 유저

3) 테스트 타기팅 설정 

다음은 A/B 테스트 타기팅 규칙을 정합니다. 위에서 살펴봤듯이 데스크톱과 모바일 웹에서의 검색 UI가 다르기 때문에, 데스크톱 유저가 더 많다는 가정하에 다른 기기의 유저는 실험에서 제외합니다. 

• 1번: deviceType
• 2번: 다음 중 하나가 아닌
• 3번: mobile, tablet, smarttv

4) 테스트 지표 설정

이제 본격적으로 A/B 테스트할 지표를 설정합니다. 목표 이름에 어떤 지표를 볼 것인지 짧게 기재 후, 분모와 분자를 설정합니다. 분모 또는 분자에 해당하는 이벤트와 필터를 선택하고 계산 유형을 설정합니다. A/A TEST의 경우 한 유저의 다중 선택을 카운팅 하지 않기 위해 Unique Visitor로 계산합니다. (해당 사진 속 이벤트와 필터명은 설명을 위해 임의로 기재한 예시입니다. 요즘IT의 실제 이벤트 정보와는 무관합니다.) 

성공 기준은 임의로 “그룹 A 대비 증가 시”로 설정합니다. A/A 테스트는 동일한 화면을 보여주기 때문에, 대조군 A와 비교하여 B의 지표가 증가하거나 감소하지 않아야 합니다. 

5) 트래픽 할당 

SDK 연동이 되었다는 가정하에, 실험 LIVE 전 마지막으로 할당할 트래픽 비중을 설정합니다. 처음에는 20~30% 정도의 비중으로 시작하여, 서비스 안정성에 영향을 미치지 않는 선에서 조금씩 트래픽 비중을 높여 점진적으로 배포합니다. 

A/A 테스트 라이브온!

위 과정을 거쳐 A/A 테스트를 시작합니다. 실험은 요일의 영향을 받지 않기 위해 최소 1주일 이상 테스트를 진행할 것을 권장합니다. 실험 플랫폼의 신뢰도를 측정하기 위한 실험인 만큼 Unique Visitor의 모수가 많이 쌓일 수 있도록 조금 더 긴 기간을 계획합니다. 

p-vlaue는 그룹 A 대비 개선율이 통계적으로 얼마나 유의미한지 설명합니다. 0부터 1까지의 값을 나타낼 수 있으며, 일반적으로 0.05 미만인 경우 통계적으로 유의미하다고 판단할 수 있습니다.

해당 실험은 충분한 모수를 갖고 진행하였으며, 3주 동안 진행한 결과 A/A TEST에서 대조군 A에 비해 실험군 B의 개선율은 +0.18%, p-vlaue는 0.6384로 측정되었습니다. 개선율도 비등하고, 통계 자체도 0.05 이상으로 유의미하지 않다는 지표가 유지되어 해당 실험을 종료했습니다. 

유저는 의도대로 행동하지 않는다

지금까지 A/A 테스트와 진행 과정에 대해 살펴보았습니다. 마지막으로 핵클에서 공개한 국내 A/B 테스트 사례 중 가장 인상 깊었던 내용을 소개합니다.

우리는 왜 실험을 해야 할까요? 바로 고객의 마음을 쉽게 예측할 수 없기 때문입니다. 프로덕트를 분석하고 기획해보면 ‘우리 유저는 여기서 이렇게 행동할 거야.’라는 착각에 빠지기 쉽습니다. 하지만 막상 실험해보면 예상과 다른 경우가 많습니다. 유저가 우리 예상과 다르게 행동할 수도 있고, 예상대로 행동했지만 다른 사이드 이펙트가 발생할 수도 있습니다. 또한 예상했던 것보다 훨씬 더 성과가 좋을 수도 있고, 때로는 안 좋은 결과를 초래할 수도 있습니다. 무엇이든 직접 해보아야 알 수 있는 것들이 많습니다. 새로 시작된 2022년엔 더 많이 실험하고 행동하여, 성장하는 한 해 보내시길 바랍니다.

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.