최근에 실험 결과를 집계하다가 큰 실수를 했다. 실험안이 기존안보다 여러 측면에서 우세하다고 결론을 내렸는데, 알고 보니 집계 과정에 오류가 있었고 다시 확인해보니 실험안이 지고 있었던 것이다. 더군다나 (위너라고 판단한) 실험안을 기반으로 다음 실험을 준비하고 있었는데, 오류를 알게 된 시점은 실험 결과를 공유한 후 2주가량 지난 시점이었다. 결국 나의 실수로 인해 개발자와 디자이너, PO 등 팀원들의 시간과 리소스가 2주가량 낭비되는 결과가 초래되었다. 데이터로 잘못된 의사결정을 내렸을 때 팀에게 미치는 영향이 얼마나 큰지 비로소 실감한 사건이었다.

사건 요약

• 퍼널 전환율 개선을 위해 실험을 오픈했고, 나는 로그 정의와 실험 집계를 맡았다.
• 사용자가 시도를 할 때마다 새로 발번되는 세션 아이디가 있었다. 이것을 기준으로 처음과 끝을 left join하여 전환율을 구했다.
• 그런데 알고 보니.. 중간 단계에서 세션 아이디가 재발급되는 로직이 있었다. 한번 생성된 세션 아이디는 그대로 유지된다고 인지하고 있었기 때문에 실험 결과 지표가 과소집계되고 있었다.
• 모수가 충분히 쌓이고, 같은 팀이었던 개발자와 DA에게 실험 결과를 공유하여 결과를 같이 해석하는 과정에서 이 사실을 발견했다.

무엇을 놓쳤나

시간을 과거로 돌린다면, 쿼리 검증을 더 여러번 해서 이 실수를 좀더 빨리 발견할 수 있었을까? 그럴 확률은 매우 희박해보였다. 그렇지만 다시는 이런 실수를 반복하면 안 되기 때문에, 실험 초반부터의 중간 모니터링과 후반에 결론을 내리기까지의 과정을 세세하게 돌아볼 필요가 있었다. 그리고 마침 요즘 읽고 있던 <유시만의 글쓰기 특강>에서 '글쓰기 규칙'을 설명하는 부분을 읽던 중 내 상황에 일대일로 대응되는 부분을 발견했다.

아래는 "주장은 반드시 논증하라" 챕터에서 내가 겪은 상황을 적용하여 발췌한 글이다.

• 가설은 반드시 논증되어야한다.
• 논증하려면 근거나 이유를 밝혀야한다. 먼저 기준이 되는 지표를 제시한다. 지표 기반으로 데이터를 요약함으로써 가설을 증명한다.
• 이럴 경우 다른 사람은 그 가설에 동의할 수도 있고 반박할 수도 있다. 가장 손쉬운 방법은 지표에 이의를 제기하고 다른 지표를 제안하는 것이다. 지표는 받아들이면서 다른 근거로 반박할 수도 있다. 예컨대 기존에 A라는 전환율이 70% 라는 것을 알고 있는데, 실험 결과를 계산해보니 A의 전환율이 50%였다면, 집계 과정의 오류를 의심하거나 표본이 대표성을 띄지 못한다고 이의를 제기할 수 있는 것이다.

이렇듯 주장을 하기 위해서는 가설과 논증의 과정을 반복하는 과정이 꼭 필요하다. 이 과정을 혼자 하는 것은 객관성이 떨어질 수 있고 분명 한계가 있기때문에, 다른 사람에게 검증을 요청하는 것도 좋은 방법이다. 처음에 미리 구상해놓은 큰그림에 데이터를 이리저리 끼워맞추는 일만큼은 절대 하면 안 된다. 논증하지 않은 가설은 일종의 취향에 불과하다.

그래서 실험 오픈을 위해 해야할 것

실험 오픈전 해야할 일

• 1) 로그 정의, 로그 QA하기
• 2) 어떤 지표로 위너 선정할지 핵심 지표 정하기
• 3) 실험과 상관 없이 변동이 생기면 안 되는 가드레일 지표 정하기
• 4) 핵심 지표와 가드레일 지표가 기존에는 어느정도 수준인지 확인하기

이번에 놓쳤던 부분이 4번이다. 이번에는 실험에 편입된 기존안과 실험안의 전환율만 비교했다. 평소에 이 전환율이 어느 정도라는 것을 실험 오픈 전에 알고 있었다면, 실험 결과에서 기존안의 전환율이 유독 낮은 이유를 이상하다고 생각했을 것이고 좀 더 빠르게 집계 오류를 찾을 수 있었을 것이다.

평소에 이 지표를 대시보드로 모니터링하고 있었다면 바로 확인 가능할 것이고, 그렇지 않다면 실험 오픈 전에 기존 지표가 어느정도인지 미리 집계해서 확인해야한다. 실험 기간을 산정하기 위해 대략적으로 계산하는 것이 아니라, 세부 조건까지 확인해서 정확하게 확인해야한다. (e.g. OS간 차이가 있지는 않은지, 실험 대상 한정하기 위해 분모의 조건을 더 세밀하게 정의할 필요는 없는지)

실험 오픈 후 1~2일 후 해야할 일

• 1) 기존안과 실험안 로그가 기대했던 대로 남는가 (e.g. 실험안 로그가 기존안에도 남고 있지는 않은가)
• 2) 실험 오픈전에 집계했던 수치와, 실험 오픈 후 기존안의 수치가 어느정도 비슷한가
• 3) 실험 세팅이 잘 되어 있는가 (e.g. 실험 타겟 설정)
• 4) 집계 쿼리 로직이 정확한가

당연한 것 아냐? 라고 생각했던 투두리스트지만, 뼈아프게도 내가 한번씩 실수해본 경험이 있는 항목들이다.. 일련의 크고 작은 경험들로 인해 나는 더이상 나를 믿지 않기로 했다..! 적어도 지금까지 한 실수는 다시 반복하지 않도록 당분간 이 점검 리스트를 실험 오픈할 때마다 캘박해놓고 습관으로 만들어야겠다.