프론트엔드 개발자의 AB 테스트 비기술적 측면에 대한 생각들

프론트엔드 개발자로서 AB 테스트를 진행하면서, 코드 작성만큼이나 프로젝트의 성패를 결정하는 또 다른 중요한 측면이 기술 외적인 영역에도 있다는 것을 생각하게 되었습니다.

특히 협업의 중요성과 요건을 적절히 판단하는 것이 효과적인 테스트를 위해 필수적이라는 생각이 들었습니다.

이러한 과정에서 개발자가 주도적으로 함께 고민하고 의견을 제안하는 것은 더 나은 결과를 도출할 수 있는 요소라는 생각이 들어 이에 관해 이야기 해보고자 합니다.

AB 테스트란?

AB 테스트는 데이터에 기반한 의사결정을 통해 제품을 개발할 수 있는 효과적인 수단입니다.

새로운 기능을 출시하거나 UX Flow를 변경하고자 할 때 동일한 기간 실제 사용자를 대상으로 기존 vs 신규 안을 적용하고, 해당 변경 상황으로 발생한 영향을 정확하게 측정할 수 있습니다.

💡 협업의 중요성

크몽 프로덕트 팀에서는 AB 테스트를 하기 위해 올해부터 핵클 이라는 플랫폼을 사용하고 있습니다.

개선하고자 하는 점에 대해 프로젝트 기획과 가설을 세우고 핵클에서의 대부분의 AB 테스트 설정까지 프로젝트 오너(PO)가 진행해 주시고, 해당 피쳐에 대해서는 디자이너가 시안을 잡아주시는데, 그 과정에서 개발자들도 적극적으로 협업해야 프로젝트의 성공을 더 향상할 수 있다고 생각합니다.

💡 요건에 대해 적절히 판단하여 진행하기

해당 작업이 AB 테스트를 적용하기에 과연 적절한 작업 인가에 대한 고민이 있었던 적도 있었습니다.

각자가 맡은 역할과 의견을 존중하면서 작업자도 자유롭게 의견을 낼 수 있다고 생각합니다. 각자 직군의 입장에서 해당 작업에 대해 적절한 판단과 의사결정은 프로젝트를 진행하는 데 있어 중요합니다.

1. GNB, LNB 영역의 개선 프로젝트를 진행하면서 AB 테스트도 함께 진행하고 싶다 → GNB, LNB 영역은 모든 페이지 상단에 노출되는 영역으로 해당 영역의 content load 처리로 인해 좋지 않은 사용자 경험을 제공할 우려가 있다. 해당 영역은 테스트를 진행하지 않고 모니터링을 통해 판단하기로 결정.
2. 검색 결과 같은 로직을 통한 AB 테스트를 하고 싶다, 대조군(A 안)과 실험군(B 안) API의 버전을 달리하여 테스트했던 방식을 Boolean 타입의 파라미터로 대조군과 실험군을 구분하기로 하면 어떨까? → 실험군이 하나일 경우에는 대응이 가능하나 실험군이 n개 이상일 경우에는 대응이 어려우니 variant 값을 보내서 구분하도록 하는 게 좋을 것 같다.

n개의 실험군에도 대응이 가능할 수 있도록 의견 제시

💡 개발자도 함께 고민해 보고 참견해 보기

개발만 하는 개발자가 아니라, 프로덕트를 만들어 가는 구성원으로서 개발 외적으로 함께 고민해 보면 간과한 부분을 미리 잡을 수 있고 좋은 방향으로 이끌어 갈 수 있을 것입니다. 개발자가 챙길 수 있는 최소한의 영역이라도 함께 챙겨보고, 함께 고민해 봅시다.

1. 모수가 적절한가? → 특정 카테고리에서만 노출되는 경우, 특정 이벤트 페이지에 국한되는 경우는 마케팅하지 않는 경우에는 상당히 모수가 적어 AB 테스트를 하는 데에 부정확할 수 있다.
2. 지표가 적절한가? → 올바른 지표를 설정하는 것은 AB 테스트를 하는 과정에서 아주 중요한 요소로 함께 고민해 봅시다.

성공 지표: 회사가 궁극적으로 달성하고자 하는 것 / 하나 혹은 최소한의 지표들

보조지표: 테스트와 직접적으로 관련된 지표 / 변경 상황과의 인과관계를 확인하고 싶은 지표

가드레일 지표: 비즈니스를 보호하는 지표 / 실험 결과의 신뢰성을 확인하는 지표

3. 테스트 기간은 적절한가? → 답정너(답은 정해져 있으니, 너는 대답만 해) 식으로 AB 테스트를 판단하여 충분한 기간을 가지지 않고 결론짓지 않도록 합니다.

4. 개선안의 구현을 잘하자 → 요건에 대해 기술적인 구현 방식에 대해 잘 생각해 보고 적절한 판단을 내리도록 합니다.

기술적인 사이드 이펙트를 방지하고 요건은 만족하는 방안으로 개발하기로 논의

클릭한 서비스에 대해 비슷한 서비스를 추천하는 위젯

5. 의문의 요소는 해소하고 한마음으로 진행하자 → 누가 봐도 개선안이 더 나아 보이는 요건인데 왜 테스트해야 하나요? 또한 다른 부분에 대해 의문을 가져본 적 없으신가요? 프로젝트를 진행하는 과정에서 불편한 의문의 요소는 해소하고 한 마음 한 방향으로 나아갑시다.

📝 AB 테스트에서 누가 봐도 개선안이 나아 보이는 요건을 테스트하는 이유는 무엇인가요?

검증과 측정의 필요성: 개선안이 나아 보이는 것은 주관적인 느낌에 불과할 수 있습니다. AB 테스트는 데이터로 검증하고 측정하여 객관적으로 유의미한 효과를 가지는지 판단할 수 있습니다.

예상과 다른 결과의 가능성: 때로는 예상치 못한 결과나 다른 예상외 영역에 영향을 미칠 수도 있습니다. 이러한 상황을 미리 식별하고 방지할 수 있습니다.

💡 AB 테스트 코드 제거도 잘 챙기기

레거시 코드를 좋아하는 개발자는 누구도 없을 것입니다. 종료한 테스트에 대해서는 제거 및 코드 정리도 잊지 말고 잘 챙겨서 이후 작업에 영향이 가는 것을 방지하고 깔끔하게 마무리 지읍시다.

크몽에서는 AB 테스트 명세와 담당 팀, 진행 상황을 공유하여 시작부터 마무리까지 모두 함께 잘 챙길 수 있도록 하고 있습니다.

지금까지 AB 테스트 작업하면서 느꼈던 프론트엔드 개발자의 입장에서 기술 외적인 부분에 대해 적어보았습니다.

감사합니다! 🙂