기능 출시를 위해 몇 달간 작업했지만 지표가 충분히 좋아지지 않는다면, 프로젝트를 접어야 할까? 실험 지표가 계속 부진할 때는 핵심 지표를 가려내고 데이터와 통계의 한계를 점검한 뒤, 필요하면 출시 전략이나 프로젝트 자체를 다시 판단해야 한다.

규모가 큰 제품을 출시한다면 실험 시스템의 지표를 바탕으로 기능의 출시 여부를 결정하는 경우가 많다. YouTube에서는 방대한 사용자 집단뿐 아니라 실험 대상 범위도 크다. 제품의 거의 모든 요소에서 지표가 나오고 실험 파이프라인을 거친다. 수십억 명의 사용자에게서 수만 개의 지표를 계산하는 규모다. 작은 변경도 예외 없이 실험을 거칠 수 있다.1

이런 환경에서는 여러 이유로 출시 지표가 오랫동안 부진한 이른바 ‘지표 지옥(Metrics Hell)’에 빠질 수 있다.2 어떤 버그를 고쳐도 다른 지표 묶음이 계속 나쁘게 나오는 식이다. 제품 하나가 수백 개의 지표를 추적하면 팀은 하나를 개선할 때마다 다른 지표가 나빠지는 상황을 반복해서 맞닥뜨릴 수 있다. 이런 과정은 며칠에서 몇 주, 몇 달, 운이 나쁘면 몇 년까지 이어진다.

중요한 지표를 우선한다

모든 지표를 똑같이 중요하게 취급하면 팀이 발목을 잡힐 수 있다. 지표마다 우선순위를 정하고, 팀이 핵심 지표에 합의해야 한다.

대개 핵심 지표는 비즈니스 목표나 OKR 지표다. 여기에 사용자 경험과 기술적 완성도를 함께 살피는 3~4개의 좋은 지표를 더할 수 있다. 팀과 함께 반드시 추적할 지표를 정하고, 의미가 없거나 오해를 부르거나 잡음이 큰 지표는 폐기하거나 개선하기로 합의한다.

데이터 인프라의 신뢰도를 확인한다

지표가 어떻게 만들어지는지 충분히 이해하지 못하면 문제가 생길 수 있다. 예를 들어 모바일 플랫폼 간 텔레메트리 수집에 차이가 있어 Android의 데이터가 iOS보다 더 잘 잡힐 수 있다. 구현 방식에 따라 지표의 의미가 조금씩 다를 수도 있다. 정상적인 경로에서는 데이터가 수집되지만 일부 예외 상황에서는 누락되거나, 사용자 데이터의 이상치가 결과를 조용히 왜곡할 수도 있다.

한 팀에서는 조직의 엄격한 접근 제한 때문에 사용자 로그를 쉽게 확인할 수 없었다. 팀은 로그에서 근거를 찾기보다 지표만 보고 원인을 추측하는 경향이 커졌다. 로그에 더 쉽게 접근할 방법을 마련한 뒤에는 문제의 근본 원인을 훨씬 빠르게 찾을 수 있었다. 감에 의존해 수정하는 대신 시스템 데이터에서 단서를 연결할 수 있게 된 것이다.

데이터 파이프라인이 느린 것도 문제다. 실험 데이터가 들어오기까지 5일이 걸리면 팀의 실행 속도가 느려진다. 팀과 함께 데이터 점검 작업을 진행해 텔레메트리와 로깅의 누락 구간을 찾거나 시스템을 개선해 실험에 걸리는 시간을 줄일 수 있다.

통계 방법의 한계를 이해한다

실험 시스템이 95% 신뢰구간을 사용한다면 지표가 틀릴 가능성도 여전히 5%다. 이는 통계의 특성이다.

실험 규모 계산기를 사용하면 통계적 유의성을 얻기 위해 얼마나 많은 트래픽을 실험에 배정해야 하는지 파악할 수 있다. 중요한 실험이라면 신뢰구간 기준을 높이는 방안도 고려할 수 있다. 때로는 99% 신뢰구간을 사용하지만, 이 경우 훨씬 많은 실험 트래픽이 필요하다.

A/A 테스트, 즉 귀무가설 검정을 실행하면 실험 배정 방식이 실제로 무작위인지 확인할 수 있다. 또한 잡음이 크거나 분산이 높은 지표를 파악하는 데 도움이 된다.

값에 상한이 없는 지표는 특히 주의해야 한다. 정상적인 사용자 행동에 대한 예상 범위를 크게 벗어난 사용자 한 명이나 흐름 하나가 결과를 왜곡할 수 있다. 합계나 평균 대신 중앙값 또는 p95·p99를 측정하는 지표를 만드는 편이 나을 수 있다.

장기 전략으로 설명하고 후속 점검을 약속한다

이 방법은 주로 경영진과 출시를 논의할 때 쓰는 관점 전환이다. 팀이 최선을 다했는데도 지표가 계속 부진하다면, 출시를 당장의 순이익이 아니라 미래의 기회를 만들기 위한 투자로 설명할 수 있다. 지금은 비용을 감수하고 나중의 기회를 얻는다는 구상이다.

다만 지표가 왜 부진한지 모른 채 경영진에게 가서는 안 된다. 먼저 데이터를 신뢰할 수 있는지, 지표가 무엇을 나타내는지 이해해야 한다.

이 방식을 택한다면 장기 홀드백 실험을 설정할 수 있다. 출시 압박 없이도 이후에 근본적인 문제를 고칠 수 있는 여지를 남기는 방법이다.

실험이 적합하지 않은 경우도 있다

대형 기술 기업이나 그에 가까운 회사에서는 실험이 기본 요건이자 문화의 일부일 수 있다. 반면 사용자가 100명인 스타트업에는 실험이 필요하지 않을 가능성이 크다. 이런 경우에는 고객과 직접 대화하고 인터뷰하는 편이 나을 수 있다. 사용자 기반이 변동하는 상황에서는 실험 결과에 잡음이 많고 결과 자체도 바뀌기 쉽다. 실험을 아예 중단하거나 결과를 신중하게 해석하는 방법도 있다.

끝내 해결되지 않으면 프로젝트를 중단한다

받아들이기 어렵더라도 매몰 비용 오류는 실제로 발생한다. 오랫동안 돌파구를 찾지 못했고 경영진에게 프로젝트의 전략적 중요성을 설득하기도 어렵다면 손실을 줄이고 다음 기회로 넘어갈 때일 수 있다.

프로젝트를 접는 일은 쉽지 않지만, 계속 손실을 키우는 편이 모두에게 더 고통스럽다. 마무리를 지으면 팀이 새로운 기회에 집중할 수 있다.

1 물론 오타를 고치거나 로거를 몇 개 추가하는 정도는 예외일 수 있지만, 실제로 거의 모든 변경이 실험을 거친다.

2 이 표현은 더 현명한 제품 리더들이 만들었고, 여기서 다루는 내용과 비슷한 내부 메모도 작성했다. 그 아이디어는 오래 기억에 남았으며, 현재 직장에서 읽은 가장 중요한 문서 중 하나라고 생각한다.