실험은 누적 효과를 가져와요. 확률적으로 더 가능성이 높은 쪽을 확인하고 채택하며, 전환율을 0.1%라도 누적시켜나가는 활동들을 해야 합니다.
👉🏻 해당 인터뷰는 2부입니다. 1부는 여기에서 확인하세요.
Leanna) 프로덕트, UX, 인게이지먼트를 포함하여 13개의 팀이 있는데요. 현재까지 프로덕트팀만 보면 80명이 함께하고 있네요. 핵클은 프로덕트 팀의 PO, UX팀에서 많이 사용하고 있는 것 같아요.
Leanna) 프로덕트팀의 PO는 아래와 같은 프로세스를 프로덕트 채널에서 항상 진행하고 있어요.
아이데이션을 할 때부터, 데이터 분석에 기반해서 이야기를 하고 있어요. 아이데이션에서 나온 좋은 아이디어를 가지고, 제품이 해결하고자 하는 문제를 정의하고 합의하기 위해 1-pager를 작성, 리뷰하고 있습니다. 실험을 진행할 때는 중요하게 볼 지표(목표 설정)와 지표를 포함한 가설을 설정합니다.
Leanna) 프로덕트팀은 슬랙 채널을 적극적으로 활용하고 있어요.
#1-Pager Review 채널에 실험에 관한 도움을 요청하면, 저희와 상관없는 팀에서도 많은 의견을 주시기도 합니다. 감사한 일이죠.
.jpg)
#ab테스트 채널에서 PO는 실험의 시작과 끝을 공지합니다. 실험에 대한 결과를 공유드리면, Data lab에서 추가적으로 분석한 내용을 첨부해주시기도 합니다.
결과에 대한 공지는 메일을 통해 전사로 공유합니다. 실험뿐만 아니라 결과와 레슨런을 확산하는 일도 중요하다고 생각해요.
Leanna) 너무 자주 모니터링을 했던 것! 작은 지표는 자주 흔들릴 수 있는 건데, 첫 A/B 테스트를 했을 때는 너무 많은 고민을 했어요. 나중에 보니, 지표가 안정화되는 시기가 있다는 걸 알게 됐죠.
실험 목표 설정 시에 분모는 기본적으로 A/B 테스트 노출 기준으로 설정하면 되는데, 특정 이벤트 기준으로 설정하는 것과는 어떤 차이가 있는지 궁금했습니다. 알고 보니 특정 이벤트 기준은 실험 노출 후에 특정 이벤트를 수행한 경우만 측정하는 고급 기능이더라고요. 첫 A/B 테스트는 모든 것들이 생소하고 어려웠던 것 같아요. 해보고 보면 별 것 아니지만..
여기어때 항공팀은 실험 조직의 성숙도로 치면, 아직은 걸음마 단계라고 생각해요. ‘해당 안이 당연히 좋을 것 같은데 꼭 실험을 해야할까요?’하는 질문을 받기도 합니다. 하지만 막상 실험을 진행해보면, 당연히 좋을 것이라고 생각한 안에서도 안 좋은 지표가 보이기도 해요.
트래픽이 적은 항공 같은 신규 서비스는 아웃 라이어(outlier;통계적 자료 분석의 결과를 왜곡시키는 극단값)가 발생하면 P-value가 틀어지기도 하다보니, '이 결과를 어떻게 모니터링할지?'와 같은 부분에서 하나하나 규칙을 만들어가고 있는 단계예요. ‘트래픽 양에 따라 어떤 case는 성공했다고 본다’와 같은 정책들을 마련하고 있습니다.
Randy) 개발자들이 숫자를 덜 믿는 경향이 있다고 생각해요. 가설을 세우고, 실험을 진행했고, 그 결과가 좋았으면 납득하면 되는데, 의심하기 시작하는 거예요.
🧐: 기대했던 바와 다르게 지표가 안 좋으면, 이 날 분명히 있었을 거야!
🤯: 지표가 좋으면, (불안감을 갖으며) 진짜 좋은 게 맞을까?
사용자가 잘 분배된 게 맞는지, 이벤트가 누락 없이 잘 집계되었는지.. 데이터 검증부터 다시 해보는 겁니다. 핵클에서 진행한 실험 데이터를 자동화해서 AWS S3로 가져가는 이유도 그런 이유가 있는 것 같아요. [AWS S3 Data Export는 엔터프라이즈 플랜에서 제공합니다. 👉🏻핵클 플랜 알아보기]
Leanna) 어떤 실험이냐에 따라 중요하게 보는 지표는 다른데, 공통적으로는 CVR(Conversion Rate;전환율)을 높이는 걸 중점적으로 보고 있어요. 전사차원의 GMV(Gross Merchandise Volume;총 거래액), CVR도 무시할 수 없기 때문에 핵클에서는 <자주 쓰는 목표>로 등록하여 모니터링 지표로 보고 있습니다.
input/output/가드레일/모니터링 지표 선정은 도메인에 따라 매우 달라지는 것 같아요. 항공 같은 경우, 이전에 전사 GMV, CVR을 성공 지표로 봤었는데, 항공권을 구매한 사람들이 다른 것을 구매할 확률이 높진 않다보니, 전사 지표로 유의미한 성공을 결정하긴 어려워지더라고요. 그래서, 항공 도메인은 ‘전사 지표는 참고용으로만 보자’라는 기조로 가고 있어요.
Randy) 핵클은 API가 아닌 SDK를 제공해 준다는 점이요! API 방식의 경우 A/B 테스트의 분배 결과를 받아오기 위해 서버 간 통신이 필요하기 때문에, 통신을 위한 별도 서버를 관리해야 합니다. 외부 통신이므로 지연이 발생할 수 있고, 외부 네트워크 환경에 따라 최악의 경우 결과를 받아오지 못할 수도 있어요. 이 부분을 모니터링해야 하기 때문에 서버 자체 관리뿐만 아니라 레이턴시 관리 또한 신경써야 합니다. 반면 핵클은 SDK를 제공하기 때문에 레이턴시 걱정이 없어서 좋았어요.
Randy) 해보고 싶은 실험은 항상 많지만, 현재까지는 서비스 초기이다 보니 UX 디자인 실험 위주로 많이 했습니다. 사실 항공 서비스는 항공권 조회, 예약 과정 자체가 느린 편이에요. A그룹은 기존 안으로, B그룹은 예약 화면으로 변경해두고 추후 문자로 안내드린다던지 UX 개선을 실험해 볼 수 있겠네요. 백엔드 실험 필요하신 가요 Leanna님? 언제든지 말씀하세요.
Leanna) 너무 좋은데요? 생각하지 못했던 포인트인 것 같아요. 현재 항공에서는, 각 페이지 별로 - PLP(Product Listing Page;상품 목록 페이지)나 PDP(Product Detail Page;상품 상세 페이지) - 준비 중인 실험이 있습니다.
Leanna) 너무 어려운 질문이네요. 저는 실험이 누적 효과를 가져온다고 생각해요. 항공 서비스는 신사업이다 보니, 저희 내부에서는 기대감이 커요.
“대박나면 어떡하지!”
그렇지만 현실은 다를 때도 있고. 저희가 해야 하고, 할 수 있는 것은 0to1을 넘어서 1toN을 만들어야 하는 건데요. 실험을 진행하면서, 확률적으로 더 가능성이 높은 쪽을 확인하고 채택하며, 전환율을 0.1%라도 누적시켜나가는 활동들을 해야 합니다. 그렇게 되면, 프로덕트와 개발팀의 노력은 당연히 비즈니스 성장으로 이어질 수밖에 없어요.
Rosie님이 기술 블로그에 올려 주신 실험도, 저희 내부에선 사실 B안이 되게 좋을 거다, 어쩌면 대박일 거다라는 기대도 갖고 있었어요. 로또를 사는 마음으로 실험을 시작했는데, 의외로 B안이 안 좋은 거예요. 실험을 하지 않았다면 의심 없이 B안으로 론칭했을 것이고, 전사적으로 부정적인 효과(Site Wide Effect)가 발생하지 않았을까요? 사실 실험은 성공 케이스를 찾아내는 것보다 실패 케이스를 배포하지 않는 것에도 의의가 있어요.
Leanna) 커머스 업계는 경쟁도 치열하고 변화도 너무 빨라요. 고객이 원하는 것을 가장 쉽고 빠르게 확인하는 게 A/B 테스트라고 생각합니다. 실험에 기반해서 제품팀을 개발하는 여기어때 항공팀이라면, 전통적인 항공업계에서 새로운 혁신을 만들어 낼 수 있을 겁니다!
Leanna) 항공업계에는 오래 있었지만, PO업무는 처음이에요. 훌륭한 팀원들과 일하면서 날마다 성장하고 있어요. 핵클 A/B 테스트도 그 과정에서 큰 도움이 되고 있습니다.
Rosie) Vue.js+typescript로 프론트 작업을 하고 있는데 Vue.js 전용 SDK가 없어서 조금 아쉬웠어요. Javascript SDK와 플러그인을 사용해서 현재는 잘 사용하고 있습니다.
Randy) 좋은 툴 만들어주셔서 잘 쓰고 있습니다. 핵클 화이팅!
***
.png)
