A/B 테스트를 언제 하고 언제 하지 말아야 하나

들어가며

회의에서 이런 장면이 반복된다. 결제 폼에 필수 항목인데 별표가 안 붙은 칸이 있다. 누가 봐도 별표를 붙여야 한다. 그런데 실험 문화가 자리 잡은 팀일수록 이런 말이 나온다.

PM: “이것도 A/B 돌려서 확인하고 넣죠.” 디자이너: “별표 붙이는 걸요? 이건 그냥 넣으면 되는 거 아니에요?” PM: “그래도 데이터로 확인은 해야죠.”

그래서 팀은 별표 붙은 폼과 안 붙은 폼을 두 주 동안 나눠 보여준다. 두 주 뒤, 예상대로 별표 붙은 쪽이 낫다는 결과가 나온다. 그 두 주 동안 절반의 사용자는 별표 없는 열등한 폼을 봤고, 팀은 처음부터 알던 사실을 확인하느라 두 주를 썼다.

이 낭비를 보면 저자가 밀고 싶은 주장이 자연스럽게 선다. 이 글은 그 주장을 먼저 또렷이 세운 다음, 그 주장을 스스로 압박해서 어디까지가 맞고 어디부터 위험한지 갈라내는 글이다. 결론부터 말하면 저자의 주장은 절반만 맞다. 그리고 그 절반이 어느 절반인지 아는 게 이 글의 핵심이다.

저자의 주장: 명백한 건 그냥 하고, 모를 때만 테스트한다

저자의 출발점은 세 문장으로 요약된다.

첫째, 명백히 이상한 걸 좋게 고치는 데 A/B 테스트를 하는 건 낭비다. 위 장면의 별표가 그렇다. 깨진 걸 고치는 데 실험은 필요 없다.

둘째, 어느 안이 명백히 더 나은지 알 수 없을 때 하는 게 A/B 테스트다. 파란 버튼이 나은지 초록 버튼이 나은지 아무도 확신 못 할 때, 그때 사용자에게 물어보는 도구가 실험이다.

셋째, 그러니 모든 변경을 다 A/B 테스트해야 한다는 말은 너무 원론적이다. 확실한 것까지 다 실험에 태우면 시간과 트래픽이 명백한 걸 재확인하는 데 새어 나간다.

세 문장을 관통하는 하나의 원리는 이거다. 불확실성이 있을 때만 테스트하라. 확실하면 그냥 배포하라. 실험은 모름을 줄이는 도구지, 아는 걸 증명하는 의식이 아니다. 여기까지는 건강한 직관이고, 나도 대체로 동의한다. 문제는 이 원리가 딛고 선 한 단어에 있다.

그런데 명백함은 누가 정하나

세 문장이 전부 명백히라는 단어에 얹혀 있다. 명백히 이상한 것, 명백히 더 나은 것, 명백히 확실한 것. 그런데 이 명백함을 누가, 무슨 근거로 판정하나.

대개는 디자이너나 PM이 판정한다. 방 안에서 가장 목소리 큰 사람의 직관으로. 그리고 바로 이 지점이 애초에 A/B 테스트 문화가 생겨난 이유다. 디자이너와 PM의 당연히 이게 낫지가 실제로 자주 틀렸기 때문이다.

사례는 널려 있다. 명백히 더 깔끔하다고 자신하며 내놓은 리디자인이 전환율을 깎은 경우, 당연히 사용자가 편해할 거라던 단순화가 오히려 이탈을 늘린 경우. 큰 회사들이 버튼 색 하나, 문구 하나를 굳이 실험에 태우는 건 사람이 유난을 떨어서가 아니다. 자기 직관이 얼마나 자주 틀리는지 데이터로 여러 번 얻어맞았기 때문이다.

그러니 저자의 규칙에는 숨은 전제가 하나 있다. 우리가 명백함을 신뢰성 있게 판정할 수 있다는 전제. 그런데 이 전제가 바로 사람이 자기를 속이는 지점이다. 명백히 낫다는 느낌은 진짜 명백해서 오는 게 아니라, 내가 그 안을 만들었거나 이미 좋아하기 때문에 오는 경우가 많다. 저자의 첫째 주장, 명백한 걸 테스트하는 건 낭비라는 말은, 그 명백함이 진짜일 때만 성립한다. 가짜 명백함까지 낭비라며 그냥 배포하면, 그건 절약이 아니라 검증 없는 도박이다.

여기서 낭비 주장을 버리자는 게 아니다. 명백함을 두 종류로 갈라야 한다는 거다.

두 종류의 명백함

명백함에는 성격이 다른 두 가지가 섞여 있다. 이 둘을 갈라놓지 않아서 논쟁이 헛돈다.

첫째는 외부 기준으로 검증되는 명백함이다. 나 말고 다른 사람이, 나와 무관한 잣대로 확인해도 같은 결론이 나오는 종류다. 필수 항목에 별표가 없는 건 폼 설계 규칙 위반이라 명백하다. 버튼을 눌러도 다음 화면으로 안 넘어가는 건 깨진 플로우라 명백하다. 스크린 리더가 읽지 못하는 이미지 버튼은 접근성 기준 위반이라 명백하다. 로딩이 8초 걸리던 화면을 2초로 줄인 건 측정된 성능 개선이라 명백하다. 법이 요구하는 동의 절차를 넣는 건 법적 요구라 명백하다. 이런 명백함은 내 취향과 무관하게 바깥에 근거가 있다. 여기엔 A/B 테스트가 필요 없다. 그냥 배포하면 된다.

둘째는 내부 확신으로서의 명백함이다. 딱 봐도 이게 낫잖아, 이게 더 세련됐잖아 하는 종류다. 근거를 캐물으면 결국 내 감이 그렇다로 돌아온다. 새 레이아웃이 더 좋아 보인다, 이 문구가 더 설득력 있다, 이 색이 더 신뢰감을 준다. 전부 판정하는 사람의 머릿속에만 근거가 있다. 이런 명백함은 위험하다. 앞 절에서 본, 자주 틀리는 바로 그 직관이 여기 들어 있다.

저자의 낭비 주장을 이 구분 위에 다시 얹으면 깔끔해진다. 첫째 종류의 명백함에서는 저자가 전적으로 옳다. 외부 기준으로 명백한 걸 테스트하는 건 진짜 낭비다. 별표를 두 주 실험하는 건 어리석다. 하지만 둘째 종류의 명백함에서는 저자가 위험하다. 내부 확신을 명백함으로 착각하고 테스트를 건너뛰면, 그게 바로 실험 문화가 막으려던 실수다.

그러니 실무에서 던질 질문은 이거다. 지금 내가 느끼는 이 명백함은 어느 쪽인가. 바깥에 검증 가능한 근거가 있나, 아니면 내 확신이 근거의 전부인가. 이 질문 하나가 배포와 테스트를 가른다.

불확실성만이 게이트가 아니다

여기까지 오면 저자의 규칙이 이렇게 다듬어진다. 외부 기준으로 명백하면 배포, 내부 확신뿐이라 불확실하면 테스트. 깔끔해 보인다. 그런데 저자의 둘째 주장, 불확실할 때 하는 게 A/B 테스트라는 말에도 구멍이 있다. 불확실성이 테스트를 켜는 유일한 스위치가 아니라는 거다. 진짜로 불확실한데도 테스트를 하지 말아야 하거나 아예 못 하는 경우가 있다.

첫째, 표본이 부족해 검정력(statistical power)이 안 나올 때다. 이 블로그의 표본 크기 글에서 다뤘듯이, 작은 차이를 잡으려면 표본이 많이 필요하다. B2B처럼 주간 방문이 수백 명인 제품에서는, 진짜 불확실한 변경이라도 유의한 결론이 나올 만큼 표본이 안 쌓인다. 불확실한데 테스트할 수가 없다. 이럴 땐 실험 대신 다른 근거로 정해야 한다.

둘째, 지표가 목표를 실험 기간 안에 못 담을 때다. 브랜드 리뉴얼이나 대규모 리디자인을 생각해보자. 진짜 효과는 사용자가 새 정체성에 익숙해진 몇 달 뒤에 나타나는데, 실험 초반에는 노벨티 효과(novelty effect)로 숫자가 튀거나 변화 저항으로 떨어진다. 이 블로그의 국소 최적 글에서 본 것처럼, 큰 변경은 단기 지표가 골짜기를 지나는 중이라 두 주짜리 A/B로는 반대편 산의 높이를 못 잰다. 측정 창이 목표를 못 담으면 실험은 잘못된 답을 자신 있게 내놓는다.

셋째, 판돈이 너무 작을 때다. 안 A와 안 B 중 뭘 골라도 결과 차이가 미미하다면, 실험을 세팅하고 두 주를 기다리는 비용이 잘못 고를 때의 손실보다 크다. 이럴 땐 그냥 하나 정하고 넘어가는 게 싸다. 동전을 던져도 된다. 실험은 공짜가 아니라 세팅, 트래픽, 대기 시간, 분석이라는 비용을 치르는 도구다.

넷째, 되돌리기 힘든 일방문(one-way door) 결정일 때다. 한번 하면 되돌리기 어려운 결정, 예를 들어 데이터 구조를 바꾸거나 가격 정책을 뒤엎는 일은 A/B로 살짝 실험하고 말 대상이 아니다. 일부 사용자에게 되돌릴 수 없는 변경을 시험 삼아 적용하는 것 자체가 위험하다. 이런 결정은 정성 조사로 미리 깊게 파거나, 소수에게 먼저 여는 단계적 출시로 위험을 관리하는 게 낫다.

정리하면 불확실성은 테스트의 필요조건이지 충분조건이 아니다. 불확실해도 검정력이 없으면 못 하고, 지표가 목표를 못 담으면 하면 안 되고, 판돈이 작으면 할 필요가 없고, 되돌릴 수 없으면 다른 방법이 낫다. 저자의 둘째 주장은 방향은 맞지만 스위치를 하나만 본다.

모든 걸 테스트하라는 도그마의 존재 이유

이제 저자의 셋째 주장으로 가자. 모든 변경을 다 A/B 테스트해야 한다는 말은 너무 원론적이다. 뻣뻣한 도그마라는 거다. 맞다. 별표까지 두 주 실험하는 팀이 그 도그마의 희생자다.

그런데 이 도그마가 왜 생겼는지를 무시하면 안 된다. 이 도그마는 게을러서 생긴 게 아니라, 앞에서 본 둘째 종류의 명백함, 그러니까 내부 확신의 과신을 막으려는 교정 장치로 생겼다. 사람은 자기 직관을 명백함이라고 부르는 데 능하다. 그래서 어떤 조직은 아예 규칙을 뻣뻣하게 못 박는다. 네 확신을 못 믿겠으니 다 테스트해. 이 규칙은 개별 사안에서는 낭비를 만들지만, 조직 전체로 보면 자기기만을 구조적으로 차단한다.

쉽게 말해 이 도그마는 무딘 안전장치다. 정교하진 않아서 별표 같은 명백한 것까지 붙잡지만, 무딘 대신 사람의 과신에 뚫리지 않는다. 저자의 규칙은 반대다. 정교해서 명백한 건 잘 통과시키지만, 명백함의 판정을 사람에게 맡기는 순간 과신에 뚫린다. 그러니 저자가 도그마를 비웃을 때 잃는 게 있다. 도그마가 지키던 그 방벽이다.

그렇다고 도그마로 돌아가자는 게 아니다. 무딘 안전장치의 목적, 즉 과신 차단을 유지하면서 무딤은 걷어내는 게 정답이다. 그러려면 테스트할지 말지를 명백하다 아니다라는 한 축이 아니라, 여러 축의 비용·효익으로 판단해야 한다.

보정된 판단틀: 테스트 가치의 다섯 축

그래서 정직한 결론은 불확실할 때만 테스트하라가 아니다. 테스트의 가치를 다섯 축으로 저울질하라다. A/B 테스트는 도덕적 기본값이 아니라 비용이 드는 도구고, 그 도구를 쓸 값어치가 있는지는 다음 다섯 개가 같이 정한다.

첫째, 불확실성이다. 결과를 정말 모르나. 외부 기준으로 이미 명백하면 이 값은 0에 가깝고, 테스트할 이유도 사라진다. 내 확신뿐이라면 불확실성은 높다.

둘째, 판돈(stake)이다. 잘못 고르면 손실이 큰가. 결제 플로우 전체를 바꾸는 결정은 판돈이 크고, 잘 안 보이는 안내 문구 색은 판돈이 작다. 판돈이 작으면 불확실해도 그냥 정하는 게 싸다.

셋째, 검정력이다. 그 결론을 낼 만큼 표본이 모이나. 트래픽이 충분하면 높고, B2B처럼 표본이 적으면 낮다. 검정력이 안 나오면 테스트는 무승부만 뱉는다.

넷째, 측정가능성이다. 우리가 재는 지표가 진짜 목표를 실험 기간 안에 담나. 굿하트의 법칙 글에서 봤듯이 대리 지표(proxy metric)만 오르고 진짜 목표는 깎이는 경우, 혹은 효과가 몇 달 뒤에야 오는 경우엔 측정가능성이 낮다.

다섯째, 되돌림 가능성이다. 틀렸을 때 무를 수 있나. 되돌리기 쉬우면 가볍게 테스트하고, 일방문 결정이면 실험보다 정성 조사와 단계적 출시가 낫다.

이 다섯을 곱셈처럼 생각하면 편하다. 어느 하나가 0에 가까우면 테스트 가치가 통째로 무너진다. 불확실성이 없으면(명백하면) 곱이 0이라 배포. 검정력이 없으면 곱이 0이라 못 함. 판돈이 없으면 곱이 작아 그냥 정함. 다섯 축이 다 넉넉할 때, 즉 진짜 불확실하고 판돈이 테스트 비용을 정당화하고 검정력이 나오고 지표가 목표를 담고 되돌릴 수 있을 때, 그때가 A/B 테스트가 제값을 하는 자리다. 그 밖에는 판단과 정성 조사로 간다.

이 틀로 앞의 장면들을 다시 보면 답이 저절로 나온다. 별표는 불확실성이 0이라 배포. 파란 버튼 대 초록 버튼은 다섯 축이 다 받쳐주면 테스트. B2B 온보딩은 검정력이 낮아 묶음 실험과 정성으로. 브랜드 리뉴얼은 측정가능성이 낮아 실험 대신 장기 관찰로. 하나의 규칙이 아니라 하나의 저울이다.

마무리

들어가며의 별표로 돌아가자. 그걸 두 주 테스트한 팀은 어리석었다. 저자 말이 맞다. 외부 기준으로 명백한 건 그냥 배포해야 한다. 하지만 저자의 규칙을 그대로 들고 나가면 반대편 절벽이 기다린다. 내 확신을 명백함으로 착각하고 검증을 건너뛰는 절벽, 애초에 실험 문화가 막으려던 바로 그 실수다.

그래서 이 글의 착지점은 저자의 세 문장을 버리는 것도, 그대로 받드는 것도 아니다. 명백하면 배포, 불확실하면 테스트라는 한 줄을 다섯 축의 저울로 바꾸는 거다. A/B 테스트는 지켜야 할 도덕이 아니라 값을 치르는 도구다. 값을 치를 만할 때만 쓰고, 아니면 판단하고, 판단이 위험하면 정성으로 보강한다.

그리고 이 모든 것보다 앞서는 규율이 하나 있다. 배포 버튼에 손을 올리기 전에 자신에게 묻는 것이다. 지금 내가 느끼는 이 명백함은 바깥에서 검증되는 명백함인가, 아니면 그냥 내 확신인가. 이 질문에 정직하게 답할 수 있으면 나머지 판단은 따라온다. 실험을 언제 하고 언제 말지는, 결국 내 명백함을 얼마나 의심할 줄 아느냐의 문제다.