지난 글까지 다룬 지표는 모두 오프라인 지표다. 고정된 세트에 모델을 돌리고 점수를 매기는 방식이라 싸고 빠르고 반복 가능하다. 그런데 그 점수가 올랐다고 해서 사용자에게 더 좋아졌다는 보장은 없다. 오프라인 지표는 우리가 원하는 것을 직접 재지 않고 대신 잴 수 있는 것을 재기 때문이다.
셋째 줄이 실제로 자주 겪는 일이다. 답을 더 자세하게 쓰도록 프롬프트를 고치면 채점 모델은 대체로 점수를 올려 준다. 그런데 사용자는 긴 답에서 필요한 문장을 못 찾아 다시 묻는다. 오프라인에서는 개선이고 온라인에서는 후퇴다.
A/B 테스트는 사용자를 무작위로 두 무리로 나눠 한쪽에는 기존 것을, 다른 쪽에는 새것을 보여 주고 행동의 차이를 재는 방법이다. 대리 지표를 거치지 않고 원하는 것을 직접 재는 유일한 방법이라서, 오프라인 평가를 아무리 잘 만들어도 이것을 대신하지는 못한다.
지표를 세 층으로 나눈다
실험 하나에 지표를 하나만 두면 그 지표만 올리고 다른 것을 망가뜨리는 변경이 통과한다. 층을 나눠 두면 그런 변경이 걸린다.
| 층 | 무엇인가 | 실험에서 하는 일 |
|---|---|---|
| 핵심 지표 | 이 실험이 올리려는 것 | 하나만 정한다. 여기서 이겨야 채택 |
| 가드레일 지표 | 망가지면 안 되는 것 | 나빠지면 핵심이 이겨도 중단 |
| 진단 지표 | 왜 그렇게 됐는지 설명하는 것 | 판단에 쓰지 않고 해석에만 쓴다 |
핵심 지표는 하나여야 한다. 둘을 두면 하나가 오르고 하나가 내렸을 때 결정 규칙이 없어지고, 그 자리에서 사람의 취향이 들어온다. 둘 다 중요하면 실험 전에 어떻게 합칠지를 정해 둔다.
가드레일에는 보통 이런 것들이 들어간다 — 오류율, p95 응답 지연, 요청당 비용, 안전 규칙 위반율, 이탈률. 이 목록은 실험마다 새로 만들지 말고 공통으로 두고 전부에 붙인다. 실험 담당자가 그때그때 정하면 자기 변경이 망가뜨릴 만한 것을 빼놓게 된다.
진단 지표는 판단에 안 쓴다고 못 박아 두는 것이 중요하다. 여러 지표를 보다 보면 유리해 보이는 것을 골라 결론을 만들게 되는데, 그것을 막는 유일한 방법이 어느 지표로 결정할지 실험 전에 적어 두는 것이다.
얼마나 돌려야 하는가
표본 크기는 실험을 시작하기 전에 계산한다. 나중에 계산하면 이미 본 결과가 계산에 섞인다.
먼저 MDE(Minimum Detectable Effect)를 정한다. 「이만큼보다 작은 차이는 알아채지 못해도 괜찮다」는 값이고, 사업적으로 의미 있는 최소 크기로 정한다. 채택률 4.0%를 4.2%로 올리는 것이 의미 있다면 MDE는 0.2%p다.
비율 지표에서 무리당 필요한 표본 수는 대략 이렇게 잡는다.
유의수준 5%, 검정력 80%면 이다. 기준 비율 , MDE 를 넣으면 무리당 약 30만 명이 나온다. 이 숫자가 감당 안 되면 실험을 못 하는 것이 아니라, 그만큼 작은 차이를 알아낼 수 없다는 뜻이다. MDE를 키우거나 더 민감한 지표를 찾아야 한다.
민감한 지표를 찾는 것이 대개 더 현실적이다. 이탈률처럼 드물게 일어나는 사건보다 「답을 복사한 비율」이나 「재질문 없이 끝난 비율」처럼 자주 일어나는 사건이 훨씬 적은 표본으로 갈린다. 가장 중요한 지표가 가장 재기 어려운 지표인 경우가 많으므로, 핵심 지표는 그것으로 두되 실험 판정은 더 민감한 대리 지표로 하고 장기 지표는 따로 누적해 보는 방식을 쓴다.
기간도 함께 정한다. 표본이 하루 만에 모여도 최소 한 주는 돌린다. 요일에 따라 사용 양상이 다르고, 월요일만으로 낸 결론은 주말에 뒤집힌다.
도중에 보면 안 되는 이유
계산한 표본이 모일 때까지 기다리는 것이 어려워서, 매일 결과를 보다가 유의해지면 멈추고 싶어진다. 이것이 peeking이고, 실험을 망치는 가장 흔한 방법이다.
위 그림의 실험은 A와 B가 실제로 똑같다. 그런데 p값은 매일 흔들리고, 14번 흔들리다 보면 어느 날은 0.05 아래로 내려간다. 유의수준 5%란 「차이가 없을 때 잘못 유의하다고 말할 확률이 한 번에 5%」라는 뜻이지 「열네 번 봐도 5%」라는 뜻이 아니다. 매일 보고 멈출 수 있게 하면 실제 오탐률은 20~30%까지 오른다.
막는 방법은 셋이다.
- 멈출 날을 미리 정하고 그날까지 결과를 안 본다. 가장 확실하고 가장 지키기 어렵다
- 가드레일만 매일 본다. 오류율이 튀는 것은 즉시 알아야 하므로 이쪽은 봐야 한다. 핵심 지표만 가려 둔다
- 여러 번 보는 것을 전제로 한 방법을 쓴다. 볼 때마다 기준을 엄격하게 만들거나, 언제 멈춰도 유효하도록 설계된 신뢰구간을 쓴다. 도구가 지원하면 이쪽이 실용적이다
나눠 주는 자리에서 새는 것들
통계보다 먼저 깨지는 것이 배정이다. 여기가 틀리면 위의 계산이 전부 의미를 잃는다.
사용자 단위로 배정한다. 요청 단위로 나누면 한 사람이 한 대화 안에서 A와 B를 섞어 만나고, 그 사람의 만족도가 어느 쪽 것인지 알 수 없게 된다. 로그인 전이라 사용자 식별자가 없으면 세션 단위로 하되 세션이 끝날 때까지 같은 쪽에 머물게 한다.
캐시를 갈라 둔다. 프롬프트 캐시나 응답 캐시를 두 무리가 공유하면 A가 만든 결과를 B가 받는다. 캐시 키에 실험 배정을 넣는다.
배정을 로그에 남긴다. 나중에 「이 요청이 어느 쪽이었나」를 답할 수 없으면 분석을 못 한다. 실험 식별자와 배정을 요청 로그에 함께 적는다.
신기함 효과를 감안한다. UI가 눈에 띄게 바뀌면 첫 며칠은 그냥 새로워서 지표가 오른다. 첫 이틀을 빼고 다시 계산해 보면 이 효과가 얼마나 컸는지 대충 보인다.
그리고 시작 전에 A/A 테스트를 한 번 돌려 보는 것이 좋다. 양쪽에 똑같은 것을 보여 주는 실험이고, 여기서 지표가 유의하게 갈린다면 배정이나 로깅이 새고 있다는 뜻이다. 실험 기반을 처음 만들 때는 반드시 거친다.
트래픽이 적을 때
모든 팀이 30만 명을 모을 수 있는 것은 아니다. 사내 도구나 초기 제품이면 하루 사용자가 수백 명이다. 이때 쓸 수 있는 것들이 있다.
섀도 배포는 새 것에 실제 트래픽을 흘리되 결과를 사용자에게 보여 주지 않고 기록만 한다. 사용자 행동은 못 재지만 오류율·지연·비용은 실제 트래픽 분포로 잴 수 있고, 위험이 없다. 새 모델을 붙일 때 첫 단계로 좋다.
인터리빙은 두 시스템의 결과를 한 화면에 섞어 보여 주고 사용자가 어느 쪽을 골랐는지 센다. 같은 사람이 두 시스템을 동시에 비교하는 셈이라 사람 사이의 차이가 상쇄되어, 무리를 나누는 방식보다 훨씬 적은 표본으로 갈린다. 결과가 목록으로 나오는 검색·추천에 쓰기 좋고, 답이 하나인 대화형에는 붙이기 어렵다.
전환점 분석도 있다. 무리를 나누지 않고 전체에 새것을 배포한 뒤 배포 전후를 비교하는 방식이다. 계절성과 다른 변경이 섞여 들어가므로 약한 증거지만, 효과가 아주 클 때는 쓸 만하다. 약한 증거라는 것을 보고에 함께 적는 것이 조건이다.
정리
오프라인 평가는 빠르게 거르는 체이고 A/B 테스트는 최종 판정이다. 둘 중 하나만으로는 운영이 안 된다 — 오프라인만 있으면 대리 지표를 올리는 변경이 통과하고, 온라인만 있으면 매번 며칠씩 기다리느라 개발이 멈춘다.
그래서 순서를 이렇게 둔다. 오프라인으로 거르고, 섀도로 안전을 확인하고, A/B로 판정한다. 그리고 판정에 쓸 지표와 멈출 날을 시작 전에 적어 둔다. 이 두 줄을 적어 두는 것만으로 대부분의 실험 사고가 사라진다.
읽어주셔서 감사합니다. 😊