brunch

매거진 PM의 일상

라이킷 12 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 진용진 Oct 25. 2020

기획자의 일 - A/B 테스트

A/B 테스트에서 고려할 사항 몇 가지

지난 몇 달간 PM으로 참여했던 프로젝트들이 A/B 테스트 주도로 진행되었습니다. 한 달에 적게는 2개부터 많게는 5개의 A/B 테스트를 동시에 진행했습니다. 일부 프로젝트는 테스트군이 1개가 아닌 2개인 A/B/C 테스트(대조군: 테스트군A: 테스트군B)로 진행되어 상대적으로 프로젝트 관리 난이도가 높았던 시기도 있었습니다.

사실 많은 테크 기업들이 A/B테스트를 강조합니다. 하지만 실제 개발 프로세스에서 활용할 수 있는 A/B 테스트 플랫폼을 갖춘 기업들이 많지 않습니다. 다행히 제가 소속된 회사는 A/B 테스트 플랫폼을 잘 갖추고 있으며, 이를 현업 부서에서 활발히 잘 활용하고 있습니다.

이번 글은 이러한 A/B 테스트 플랫폼 구축을 다루는 기술적 이야기를 다루지 않습니다. 대신에 그동안 A/B 테스트 기반으로 프로젝트를 진행하면서 개인적으로 배웠던 점들을 회고 차원에서 남겨보고자 합니다.

실험을 위한 구현 범위를 고민하기

테스트의 목표는 우리가 알고 싶은 것을 빠르게 실험하여 궁금증을 해결하는 것입니다. 완벽한 제품을 만드는 것이 아니고, 빠른 시일 내에 가설을 검증하는 것이 목표이기 때문에 품질과 일정 수준으로 트레이드오프(trade-off)를 감수해야 합니다. 하지만 프로덕트 오너십이 강한 멤버들이 일하는 팀(Team) 일 수록 품질에 대한 기대는 높기 때문에 이에 대한 작업 산출물에 대하여 사전에 합의가 필요합니다.

예를 들면 쇼핑 검색에 사용자 취향에 따른 옵션을 설정하는 기능을 테스트한다고 가정하겠습니다. 테스트의 목표는 쇼핑 검색에서 사용자가 새로 추가된 취향 옵션 UI를 많이 사용하는지 전환율을 1차적으로 살펴보고, 이에 따른 후행지표로 검색 쿼리와 상품 조회수가 증가하는지 측정할 것입니다.

이제 제품의 개발 범위를 고민하게 될 것입니다. 새로운 기능을 위해서 사용자의 취향 데이터를 검색엔진에 색인해야 합니다. 프로덕트의 품질 관점에서 고민하면 서비스가 보유한 전체 상품 단위로 취향 데이터를 색인해야 보다 좋은 검색 결과를 얻을 수 있습니다. 하지만 상품 단위로 색인하면 데이터 볼륨이 커지기 때문에 개발 및 관리 범위가 커질 수밖에 없습니다. 테스트의 목표가 새로 제공되는 UI에 대한 사용성 검증이기 때문에 과제 범위를 ‘상품 단위 색인’이 아닌, ‘쇼핑몰 기준으로 색인’하는 것으로 줄일 수 있습니다 (대부분 쇼핑 서비스에서 쇼핑몰 수는 상품 수 보다 규모가 상당히 적습니다).

이 정도 작업으로도 사용자가 변경된 쇼핑 검색 옵션의 변화를 느낄 수 있고, 이에 대한 사용성을 충분히 검증을 할 수 있습니다. 그리고 A/B테스트 결과가 기대만큼 나오지 않으면(예: 새로운 UI 사용률이 낮거나, 검색 쿼리수가 유의미하게 증가하지 않음), 테스트 결과를 반영할 수 없기 때문에 투입된 리소스 관점에서도 상대적으로 리스크가 낮아집니다.

그럼 A/B테스트의 품질은 어느 정도를 생각해야 할까요? 이는 서로 생각이 다를 것 같습니다. 다음 주제와 이어지는 질문이겠지만 저는 개인적으로 ‘120% 품질을 만들 수 있는 팀의 능력(capacity)이 있다면 100% 수준을 고려한다’로 최근 생각하고 있습니다.

실험도 중요하지만 정식 배포 시나리오도 고려하기

린스타트업은 매우 실용적인 프레임워크입니다. 저도 린스타트업이 처음 나왔을 때, 원문을 구매해서 요약 번역할 정도로 많은 관심을 가졌습니다. 여전히 린스타업이 추구했던 가치를 지지하지만, 시대가 바뀌면서 접근법에 있어 재고할 부분은 존재한다고 생각합니다. 우선 린스타트업이 부상하기 시작했던 2010년대 초반은 ‘mobile first, web second’, ‘moblie only’ 이런 논의가 있을 정도로 여전히 pc웹의 영향력이 높았더 시절입니다. 린스타트업에 나오는 다수의 사례들도 웹 기반의 지속적인 배포를 할 수 있는 프로덕트 중심입니다. 하지만 최근 대부분 프로덕트는 모바일 네이티브 앱 중심으로 변화했고, 웹 기반 프로덕트처럼 수시로 배포할 수 있는 환경이 아닙니다. 따라서 극초기 프로덕트가 아닌 이상 MVP에 대한 관점이 달라져야 하며, 결과물의 품질도 일정 수준 이상이 되어야 하는 상황입니다.

A/B 테스트에서 구현 범위는 많은 고민을 안겨줍니다. 앞선 논의에서 가설을 검증할 수 있는 수준의 개발 범위의 장점에 대해 이야기했습니다. 잘 아시다시피 A/B테스트를 하는 이유는 팀의 제약된 리소스 안에서 효율적으로 일하는 것이 목적입니다. 하지만 품질 또는 꼭 포함되어야 하는 스펙을 희생하고 진행한 A/B테스트는 성과분석에서 좋은 결과가 나와도, 이후에 많은 검토사항과 리소스 부담을 팀에게 안겨줄 가능성이 높습니다. 이는 특히 A/B 테스트를 종료하고, 해당 결과를 전체 사용자 대상으로 정식 적용하는 과정에서 이슈가 나타나기 시작합니다.

예를 들어 검색 서비스에 검색어를 저장하는 기능을 A/B 테스트하는 것으로 가정하겠습니다(참고로 최근 Etsy가 해당 기능을 A/B테스트했습니다). 2주의 이터레이션 주기에 맞춰 해당 기능을 테스트할 것을 계획하다 보니 기존에 존재하던 검색어 신고 기능을 디자인 상으로 검토하는 일정이 촉박해졌습니다. 그래서 해당 기능 관련해서 운영팀에 양해를 구하고, A/B 테스트군에 한정하여 검색어 신고 기능을 UI 상으로 제거하기로 결정했습니다 (조금 극단적인 예시지만...). 2주간 테스트를 진행하였고, 성과분석 결과에 따르면 검색어 저장 기능을 유저가 잘 활용하는 기능으로 성공한 실험으로 검증되었습니다.

이제 검색어 저장 기능을 전체 사용자에게 적용하고자 합니다. 하지만 기존의 A/B 테스트와 달리 바로 전체 사용자에게 배포를 할 수 없는 상황입니다. 왜냐하면 오로지 실험과 가설 검증을 위한 범위만 생각하다 보니 운영팀의 KPI와 연관도가 높고, 검색 서비스 운영에 중요한 신고 기능에 대한 고려를 미뤄두었기 때문입니다. 물론 2주 동안 검색어 저장이라는 기능의 사용성에 대한 인사이트(Insignt)를 얻어냈습니다. 하지만 A/B 테스트 결과를 전체 사용자에게 적용하기 위해 검색 신고 기능에 대한 디자인 및 운영에 미치는 영향을 검토하기 위해 최소 2주의 일정이 필요하게 됩니다.

A/B 테스트가 빠르게 가용할 수 있는 리소스 내에서 가설을 검증하는 역할을 하지만, 극단적으로 해당 과제만을 생각하는 실험은 추후에 또 다른 리소스 부담을 가져올 수밖에 없다는 것을 한번 생각해봐야 할 것 같습니다.

플랫폼 확장 시나리오를 고려하기

대부분의 기업들, 특히 스타트업들은 한정된 개발 리소스의 제약이 큰 이슈입니다. 특히 최근 동향은 클라이언트 개발자 채용이 힘든 상황입니다. 따라서 A/B 테스트도 iOS, 안드로이드(Android) 두 개 플랫폼 모두 진행하는 것은 최근 주가가 높은 클라이언트 개발 리소스를 비효율적으로 활용하는 것으로 해석될 수 있습니다. 실제로 많은 스타트업들이 A/B 테스트를 특정 플랫폼을 중심으로 진행하는 것으로 알고 있습니다. 예를 들면 A라는 기능에 대한 테스트를 iOS에서 진행하고, 성과분석 결과 성공한 것으로 해석되면 해당 기능을 iOS 전체 사용자뿐만 아니라 안드로이드 플랫폼으로도 확장하는 것입니다.

A/B 테스트를 활발히 하는 조직은 다양한 실험을 시도하는 것을 중요하게 여기는 DNA를 가지고 있습니다. 따라서 우선 A/B테스트를 연속적으로 시도하고 이에 대한 학습을 중요하게 여길 가능성이 높습니다. 예를 들면 iOS에서 검색어 저장 기능 관련해서 A/B 테스트를 진행하고, 해당 테스트의 성과분석이 성공적으로 마무리되면 바로 안드로이드에 검색어 저장 기능을 확장 배포하는 것이 아닌 다른 새로운 A/B테스트를 다음 이터레이션에 진행하는 방식을 상상할 수 있습니다.

따라서 플랫폼 확장에 대한 일정을 별도로 조율하는 것이 프로젝트 관리 관점에서 도전적인 업무가 될 가능성이 높습니다. 결국 A/B 테스트는 일부 사용자를 대상으로 성공사례를 만든 것에 불과하기 때문에, 사업 전체적으로 임팩트(impact)를 만들기 위해서는 A/B테스트 결과를 전체 사용자에게 배포하는 과정을 꼭 거쳐야 합니다.

또한 이미 특정한 플랫폼에서 성공한 A/B 테스트 결과를 그대로 다른 플랫폼에 적용하는 것에도 리소스 투입이 적지 않게 투입됩니다. iOS와 안드로이드 UX 가이드가 달라 별도의 디자인 작업이 필요하며, 개발을 위해서 별도 이터레이션을 할애하는 리소스 투입이 불가피합니다. 물론 가설 검증을 위한 시간을 절약하는 이점이 있지만, 생각보다 플랫폼 확장을 위한 리소스가 전체적인 프로젝트 관리에 있어 무시할 수 없는 일정을 차지하게 될 것이란 것을 체감하실(하셨을) 것입니다.

지금까지 A/B 테스트에 대하여 제가 직접 겪은 경험을 바탕으로 기획자 또는 PM이 고려해야 할 사항들을 정리했습니다. 사실 A/B테스트를 바라보는 팀의 철학 및 업무 방식에 따라서 접근법은 매우 다양할 것 같습니다. 제가 정리한 내용들은 A/B테스트 및 프로젝트 관리의 다양한 변수 중에서 일부로 이해해주시길 부탁드리겠습니다.

* 이미지 출처: The agitator, license details

keyword