과도한 AB 테스트

AB 테스트에 대한 글을 읽으면, 간단한 문구 수정이나 버튼 색상 변경 만으로도 전환율이 몇 배 이상 높아졌다, 매출이 몇 십 퍼센트 늘어났다는 주장을 쉽게 볼 수 있다. 단순한 변경만으로 그런 극적인 효과를 얻을 수 있다는 게 미덥지 않지만, 어떤 변경이 긍정적 효과를 주는지 확인하는 수단으로 AB 테스트는 좋은 방법이다.

어떤 변경사항을 적용한 후 전환율에 변화가 생겼다면, 그게 변경사항 때문인지 다른 외부 요인 때문인지 어떻게 알 수 있을까? AB 테스트를 이용하면 해당 변경 사항이 어떤 영향을 미치는지 확인할 수 있다. 사용자를 두 집단으로 나누어, 일정 기간 동안 한쪽에는 변경사항을 적용하지 않은 A안을 보여주고, 다른 쪽에는 변경사항을 적용한 B안을 보여준 후, 어느 쪽의 결과가 더 좋은지를 비교하면 변경사항이 미친 효과를 확인할 수 있다.

AB 테스트를 진행할 때는, 먼저 가설을 세우고 가설을 검증할 지표를 정의해야 한다. 테스트를 수행한 다음에는 가설이 맞았는지 검증하여 새로운 사실을 배우는 절차를 거치게 된다. 가설이 맞았으면 맞은 대로, 틀렸으면 틀린 대로 새로운 사실을 배우게 되며, 그 사실을 바탕으로 사이트를 계선할 수 있다.

예전에 다녔던 회사에는 모든 변경이 AB 테스트를 거쳐야 한다는 규칙이 있었다. AB 테스트에서 이겨야만 정식 적용이 가능했다. 그럴듯해 보이는 이 규칙에는 내가 보기에 심각한 문제가 있었다.

첫 번째 문제는, AB 테스트의 결과가 책에서 주장하는 것처럼 극적으로 나타나지 않는다는 점이었다. 어느 쪽이 낫다고 확실히 말하기 어려운 정도의 차이를 보이는 경우가 대부분이었다. 예를 들어, 테스트에서 B안이 A안보다 0.1% 높은 전환율을 보였다면 정말 B안이 낫다고 말할 수 있을까? 이 정도의 차이가 통계적으로 의미 있다고 말할 수 있을까?

새로운 요구사항은 계속 들어왔지만 AB 테스트에서 이겨야 정식으로 적용할 수 있었기 때문에, 각 팀마다 진행 중인 AB 테스트가 몇 개씩 쌓여 있었고 회사 전체로는 수십 개의 AB 테스트가 동시다발로 진행되었다. 과연 수십 개의 AB 테스트가 동시에 진행중인 상황에서, 특정 AB 테스트의 결과를 보고 A안이 나은지 B안이 나은지 어떻게 판단하겠다는 것인지도 의문이었다. 물론 사용자 그룹을 주의 깊게 나누고 적절한 통계 기법을 사용한다면 불가능하지는 않겠지만, 정말 그렇게 하고 있는지도 알 수 없었다.

또 다른 문제는, 뭔가 정책적으로 바꿔야 하는 것까지도 AB 테스트를 거쳐야 하다 보니 서비스 자체를 개선하기가 너무 어려웠다는 점이다. 롤백이 매우 어려운 상황이라면 AB 테스트에서 무조건 이겨야 하는데, 기대한 결과가 나오지 않자 원하는 결과가 나올 때까지 몇 달이나 AB 테스트를 지속하는 경우도 있었다. AB 테스트가 지속되는 동안에도 다른 수정 요청을 계속 처리해야 하기 때문에 개발팀 부담은 이만저만 아니었다. 그러나 중요 변경사항을 적용하려면 대표가 'AB 테스트에서 이겼는지?' 확인했기 때문에 다른 방법이 없었다.

그런 와중에 AB 테스트 건수로 팀을 평가하겠다는 공지가 내려왔다. 각 개발팀은 좋은 평가를 받기 위해 온갖 잡다한 아이디어를 짜내 AB 테스트를 수행하기 시작했다. 어떤 가설을 세웠고 어떤 사실을 배웠는지는 중요하지 않았다. AB 테스트 건수를 늘리는 게 중요했다. 예전에 이미 수행했던 AB 테스트를 조금 바꿔 다시 진행하는 경우도 많았다. 그땐 졌지만 이번에는 이길 수도 있지 않겠냐는 것이었다. 무작위로 AB 테스트를 진행하면서 소가 뒷걸음치다 쥐를 잡는 격으로 운 좋게 대박이 걸리는 경우도 있었지만, 그 성공은 다른 성공으로 이어질 수 없었다.

게다가 AB 테스트 아이디어가 있다면 다른 팀의 소스 코드를 수정해도 괜찮다는 지시가 내려왔다. 대부분의 AB 테스트는 프론트엔드에 집중되기 때문에 여러 팀에서 프론트엔드 소스를 건드리기 시작했다. 배포하기 전에 프론트엔드를 담당하는 팀의 코드 리뷰를 거쳐야 했지만, 코드 리뷰에서 코드의 문제점을 이야기하면 'AB 테스트를 위한 임시 코드니까 일단 그냥 넘어가자, 나중에 정식으로 반영하게 되면 그땐 잘 하겠다'는 답이 돌아올 뿐이었다.

AB 테스트를 적용하기 위해 코드에는 if문이 들어갔다. 코드 수준에서 어떻게 AB 테스트를 지원할 지에 대한 충분한 고민 없이 if문을 추가하는 방법을 사용하다보니 코드 여기저기가 if문으로 지저분해졌다. 정해진 기간 동안 AB 테스트를 수행한 후 관련 코드를 제거한다면 좋겠지만, AB 테스트가 기약 없이 늘어질 때가 많았다. 코드에도 AB 테스트를 위한 if 브랜치가 점점 늘어났고, 코드도 점점 복잡해졌다.

AB 테스트가 사업 발전에 어떤 긍정적 영향을 미쳤는지는 명확하지 않았다. 그러나 부정적 효과는 명확하게 보였다. 온갖 설익은 아이디어가 AB 테스트란 명목으로 서비스에 추가되었다. 코드가 필요 이상으로 복잡해져 간단한 수정에도 오랜 시간이 필요했다. 장애도 잦아졌다. 아마도 경영진은 이 사실을 인정하지 않겠지만 말이다.