당신의 A/B 테스팅은 실패하지 않았습니다.
그러니까 계속 A/B 테스팅을 해보세요-
Summary.
A/B 테스팅을 하는 UX 디자이너들은 논리적이고 체계적이며 겸손합니다. 연속되는 A/B 테스팅의 실패에 좌절하기보다는 계속 노력하고 시도해보셨으면 합니다. 당신의 A/B 테스팅은 사실 '실패'가 아니었을 수도 있으니까요.
A/B 테스팅이라는 쉬우면서 어려운 일
A/B 테스팅은 쉽게 생각하면 쉽지만 어렵게 생각하면 어려운... 그런 가깝고도 먼 존재인 것 같습니다. 뭔가 '정석'이라고 규정된 방식이나 방법론도 딱히 없고요, 그냥 서비스의 여러 상황(리소스, 비지니스적 상황)에 따라 유연하게 적용해야 하는 프로세스이죠. 그러다 보니 아직 A/B 테스팅을 해보지 않거나 익숙하지 않은 많은 사람들에게는 매우 어렵고 사치스러운 작업(?)으로 인식이 되고 있는 것도 같습니다. 솔직히 그런 인식에 대해서 저도 어느 정도 공감은 할 수 있을 것 같습니다. 저는 A/B 테스팅을 어렵게 생각하는 인식이 크게는 두 가지 정도 이유로 오는 것 같다고 생각하는데요, 그중 첫 번째는 실제로 A/B 테스팅을 위해서는 일을 더 해야 하는 매우 고단한 작업인 이유이고, 두 번째 이유는 환경적인 제약조건 때문에 A/B 테스팅을 시작도 못하다 보니 괜히 더 풀리지 않는 숙제 같은 불편한 인식이 생겨버려서 그렇다고 생각합니다. 저 역시 A/B 테스팅을 처음 접했을 때는 '사용자의 경험을 어떻게 가설 하나, 작은 기능 하나를 기준으로 결론 내릴 수 있느냐'며 거부감을 표하기도 했었습니다. 다만 지금은 그때와 생각이 달라진 게 있다면, A/B 테스팅으로 쉽게 증명되지 않는 사용자 경험은 물론 많이 있지만, 증명되고 개선될 수 있는 경험들 또한 제 생각보다는 많이 있다는 것입니다.
제가 A/B 테스팅을 하면서 알게 된 점 중 하나는 A/B 테스팅을 할 수 있는 방법이 정말 다양하다는 것입니다. '반드시 트래픽을 실시간으로 두 갈래로 나눠서 테스팅을 해야지만 A/B 테스트라고 부를 수 있다'라든가 'Optimizely나 Google Analytics와 연동을 하여 데이터를 증명해야만 한다'라든가... 그런 얘기를 듣다 보면 참 안타깝습니다. 딱 그런 이야기들이 A/B 테스팅의 본질을 흐리는 것 같다는 생각이 들어서요. 툴이 중요한 게 아니고 완벽한 프로세스가 중요한 게 아니라, 내 가설을 증명할 수 있는 현실적으로 가장 효율적인 방법을 찾는 게 저는 A/B 테스팅이라고 생각합니다. 상품 페이지의 전환율을 측정하려고 할 때 상품 페이지에 유입되는 트래픽을 꼭 기술적으로 반으로 나눠 계산하지 않아도 됩니다. 차라리 A, B 안의 상품 페이지를 따로 만들어서 페이스북 광고 등을 집행할 때 트래픽의 반은 A안으로, 트래픽의 반은 B안으로 보내서 결과만 보는 것도 서비스의 상황에 따라서는 더 현실적으로 쉬운 방법일 수도 있습니다. 상품페이지 A안 B안의 디자인을 하루는 A안으로, 하루는 B안으로 전환시켜가면서 일정기간 동안 짝수일 홀수일의 퍼포먼스를 비교해봐도 좋고요. 심지어 제가 위에 언급한 제가 지금까지 시도해보지 않은 더 효율적이고 간단한 테스트 방법들이 있을 수도 있습니다. 명심하세요, A/B 테스팅은 어떤 툴과 어떤 방식으로 진행을 하느냐가 중요한 게 아니라 나의 가설을 어떻게 가장 효과적으로 증명할 수 있을까에서 시작되어야 한다는 점을요.
A/B 테스팅을 한다는 것은 당신이 멋진 UX 디자이너라는 뜻입니다.
A/B 테스팅은 전에 포스팅한 'UX 디자이너와 데이터가 만날 때'라는 글에서 말한 바와 같이, 데이터로 검증이 되는 효과를 통해 UX 디자이너의 성과를 인정받기 매우 효과적인 방법이라는 점에서 참 매력적인 것 같다고 이야기했었습니다. 하지만 이번에는 A/B 테스팅 자체에 대한 장점보다 A/B 테스팅을 진행하는 사람들에 대한 이야기를 좀 해봤으면 합니다. A/B 테스팅을 선호하는 UX 디자이너들을 보며 제가 개인적으로 느낀 특징들은 다음과 같습니다.
논리적: 공돌이 출신 UX 디자이너인 저에게만 유난히 매력적으로 느껴지는 특성인지는 모르겠으나... 자신이 증명하고 싶은 사용자의 경험을 논리적인 맥락으로 정리할 수 있다는 점이 저는 너무 멋진 것 같습니다. 물론 모든 사용자의 경험이 수치적으로 증명될 수는 없겠으나 그래도 그 와중에 증명이 될 수 있는 지표들을 논리적으로 도출해보고, 그 지표들과 사용자 경험을 잇는 논리력을 펼치는 UX 디자이너가 저는 너무 멋지다고 생각합니다. A/B 테스팅을 하는 UX 디자이너들은 논리력으로 가설과 예상 목표를 도출해야 하기에 점점 논리적이 되는 것 같다고 저는 생각합니다.
체계적: 논리적으로 가설과 목표를 도출하는 역량과는 조금 다른 맥락에서 A/B 테스팅을 하는 UX 디자이너들은 체계적인 것 같아 멋진 것 같습니다. 제가 여기서 말하는 체계적인 특성은 Project Manager들이 지니고 있는 특성과 비슷한 개념인 것 같습니다. 어떤 것이 가설을 검증하기 위한 가장 효율적인 방식과 일정이 될지를 고민하고 동료들과 협의하고 그렇게 역할에 맞추어 진행을 하는 체계적 특성이 A/B 테스팅 경험을 쌓으면 쌓을수록 비례하여 느는 것 같다고 느껴져 멋진 것 같습니다. 이 역량을 높이는 UX 디자이너일수록 점차 Product Manager의 역할으로까지 성장하는 것 같기도 하고요.
겸손함: 제가 개인적으로 A/B 테스팅을 선호하는 UX 디자이너들을 멋지게 생각하는 가장 큰 이유입니다. UX 디자이너는 사용자의 경험을 진심으로 이해하고 공감하기 위해 다양한 노력을 해야 합니다. 제가 개인적으로 사용자를 진심으로 공감하고 이해하기 위해 가장 중요하다고 생각하는 태도는 '나는 우리 사용자에 대한 모든 답을 가지고 있지 않다'라고 내 편견부터 버리는 일인데요, A/B 테스팅 역시 그 동일한 태도를 대전제로 진행되는 방법론인 것 같다 생각됩니다. '내 생각에 우리 서비스의 이용자는 이런이런 이유로 이런이런 기능/경험을 원할 것이다. 하지만 나의 가설이 정답은 아니기에 증명을 먼저 했으면 한다'는것이 제가 개인적으로 해석하는 A/B 테스팅의 경험이고, 그 경험을 한마디로 줄인다면 나의 편견과 자존심을 낮추는 겸손함이라고 생각합니다. 그래서 저는 A/B 테스팅을 선호하는 UX 디자이너들은 겸손하다고 보이는 것 같습니다. 그리고 겸손한 UX 디자이너들은 결국 사용자에 가장 가까이 도달하는 것 같습니다.
당신의 A/B 테스팅은 실패하지 않았습니다.
A/B 테스팅을 하다 보면 사실 좀 좌절(?)하고 싶을 때가 있습니다. A/B 테스팅을 좀 해보신 분들은 아시겠지만, 대부분의 테스팅은 '실패'로 끝나거든요(여기서 말하는 '실패'는 내가 세운 가설이 예상한 목표에 오히려 악영향을 미치거나 혹은 아무런 긍정적 기여를 하지 못했을 때를 말합니다). 그렇게 저 역시 실패 릴레이를 펼치던 중 요즘 들어 문득 들게 된 고민이 하나 있는데요, '과연 A/B testing에서 '실패'했다고 하는 테스트는 정말 실패한 것이 맞을까?'라는 의문이 그것입니다. 제가 의문을 제기하는 가장 큰 이유는 '만약 경험은 맞았는데 내가 증명하려고 하는 가설과 목표가 달랐다면?'이라는 가능성 때문입니다. 가설은 말 그대로 가설입니다. 똑같은 경험을 놓고 보았을 때도, 그 경험을 솔루션으로 생각하는 가설은 단 한 개가 아닐 수 있습니다. 내가 만들어낸 새로운 경험의 영향력 중에는 그 경험을 설계한 나도 모르는 영향력이 있을 수 있다는 말입니다. 그만큼 사용자 경험이라는 것은 유기적이고 광범위한 것이니까요. A/B 테스팅을 많이 진행하시는 분들은 공감하실 수 있겠지만, A/B 테스트 성공 횟수와는 크게 상관없이 A/B 테스트 횟수가 늘어날수록 서비스의 전반적이 지표가 호전되는 현상이 생깁니다. 저는 이 현상 역시 가설로는 설명되지 않았지만 테스트를 통해 새로워진 작은 사용자 경험들이 모여 발생한 효과가 아닐까 생각합니다. 지표로 증명이 깔끔하게 되지 않는 경험이라고 해도 그 모두가 사용자의 경험입니다. 혹시라도 A/B 테스팅의 연속적인 '실망스러운' 결과에 속상하신 UX 디자이너분들이 있다면, 그래도 기운 내서 또다시 도전하고 테스팅을 하셨으면 좋겠습니다. 당신의 A/B 테스팅은 실패하지 않았을 수도 있었으니까요.
