파라미터 페이지를 227개 배포했습니다. 대출 계산기의 금액×금리 조합 115개, 연봉 앱의 상위 백분위 111개, 실수령액표 1개입니다. 이미 있던 데이터에 URL만 새로 준 것이라 제작비는 거의 들지 않았습니다.
착수하면서 판정 규칙을 먼저 적어뒀습니다.
네이버 롱테일 세션(홈 랜딩 제외) 28일 합계가 기준선 173 대비 +30% 이상(≥225). 창은 배포일+14일부터 28일.
색인 지연을 흡수하려고 창을 뒤로 밀었고, '롱테일'의 정의는 말이 아니라 코드에 박았습니다. 판정일에 정의를 정하면 그건 사후 바 이동이니까요.
질문 하나 드리겠습니다. 당신의 A/B 임계는 "아무것도 안 했을 때의 값"을 알고 있습니까?
판정 창이 열리기 전에 숫자를 한 번 봤습니다
창은 배포 2주 뒤에 열립니다. 그 전에 채널이 어떻게 움직이는지 궁금해서 앱별로 갈라봤습니다. 그리고 개입하지 않은 앱들만 따로 합산했습니다.
비개입군 네이버 롱테일 세션
14일 전: 56
현재: 2514.5배입니다. 제가 아무것도 안 한 앱들에서요.
원인은 금방 나왔습니다. 나흘 전에 포트폴리오 전체의 SEO를 손봤습니다. 루트 경로 308 리다이렉트를 정리하고 푸터에 로케일 링크를 넣은 작업입니다. 그게 채널 전체를 밀어 올렸습니다.
그러면 제 판정 규칙은 어떻게 됩니까. 기준선 173에 +30%는 225입니다. 채널이 4.5배가 되는 중이면, 227페이지가 세션을 단 한 건도 만들지 않아도 225는 넘습니다.
이게 위험한 이유는 FAIL이 나와서가 아닙니다. PASS가 나와도 원인을 모른다는 게 문제입니다. 통과한 판정에서 배울 게 없으면 그 판정은 비용만 치른 겁니다. 분모가 없는 게이트를 한 번 겪고 나서 임계는 조심스럽게 다뤄왔는데, 이번엔 분모가 아니라 비교 대상이 썩어 있었습니다.
여기서 선택지가 셋이었습니다
당신이라면 어느 쪽으로 가겠습니까?
- 임계를 올린다. +30%로는 추세를 못 거르니 +80%쯤으로.
- 판정일을 뒤로 민다. 추세가 가라앉을 때까지 기다린다.
- 임계와 창은 그대로 두고, 비교 대상을 바꾼다.
1번은 가장 흔하고 가장 나쁩니다. 사전등록한 바를 결과가 나오기 전에 올리는 건, 판정을 미뤄서 바를 세게 만드는 것과 방향만 반대인 같은 죄입니다. 그 숫자에는 근거가 없습니다. "추세를 이기려면 얼마여야 하는가"를 임계에 손으로 적어 넣는 순간, 다음 판정은 제 기분이 정합니다.
2번도 바 이동입니다. 창 길이는 검정력의 일부입니다.
3번으로 갔습니다. 같은 +30% 바를 추세 위에 세웁니다.
TREATED_HOSTS = ("loan.ootssu.com", "salary.ootssu.com") # 227p 증설 대상
# 배포 전 28일 실측 분해
# 개입군 32 · 비개입군 127 · attach 14 → 합 173 = BASELINE (창 정의 확인)
BASE_TREATED = 32
BASE_CONTROL = 127판정식은 이렇게 됩니다.
expected = 32 × (비개입군_판정창 / 127)
PASS ⇔ 개입군_판정창 ≥ 1.30 × expected임계 1.30도, 창 09-22~10-19도, 롱테일 정의도 안 건드렸습니다. 비교 대상만 "고정 기준선"에서 "비개입군이 예측한 값"으로 바꿨습니다. 그리고 이건 사후 바 이동이 아닙니다 — 판정 창이 아직 열리지 않았습니다. 데이터를 보고 바를 옮긴 게 아니라, 데이터가 생기기 전에 비교 대상을 고친 겁니다. 이 구분이 전부입니다.
1차 절대 임계는 지우지 않고 남겼습니다. 사전등록은 사전등록이니까요. 다만 결론은 2차로 읽습니다.
대조군을 오염시킨 건 저였습니다
여기서 한 번 더 걸렸습니다. 보정을 넣은 그날, 다른 앱에 궁합 페이지 30개를 배포했습니다.
그 앱도 대조군에 들어 있습니다. 그런데 대조군은 "아무것도 안 한 앱들의 추세"여야 합니다. 판정 창 안에서 자기도 페이지를 늘린 앱이 섞이면 대조군이 부풀고, expected가 커지고, 개입군이 넘어야 할 바가 저절로 세집니다. 방향만 반대일 뿐 역시 바 이동입니다.
그렇다고 판정 끝날 때까지 40일 동안 증설을 멈출 이유는 없습니다. 늘린 앱을 양쪽에서 빼면 됩니다.
# 판정창 안에 '자기 증설'을 받은 앱은 대조군이 아니다.
# attach 2026-09-10 궁합 페이지 30개. /ko/pair/... 는 롱테일로 집계된다.
EXPANDED_HOSTS = ("attach.ootssu.com",)기준선 분해도 같이 정정했습니다. 종전에는 비개입군을 141로 뒀는데 그 안에 이 앱의 14가 들어 있었습니다. 판정 창에서 빼면서 기준선에는 두면 분자와 분모가 다른 모집단이 되어 비율이 통째로 틀어집니다. 그래서 127로 내렸습니다. 32 + 127 + 14 = 173, 원래 기준선과 맞습니다.
그리고 규칙 자체를 코드 주석에 남겼습니다 — 앞으로 페이지를 늘릴 때마다 그 호스트를 EXPANDED_HOSTS에 추가할 것. 안 그러면 판정이 조용히 보수화됩니다. 조용한 건 다음에 또 놓친다는 뜻입니다.
마지막으로 0 나눗셈을 막았습니다. 비개입군이 0이면 expected가 0이 되고 어떤 값이든 PASS가 됩니다. 그때는 판정불가를 돌려줍니다. 측정 실패를 0으로 치환하면 틀린 판정이 원장에 남습니다.
자가진단 3개
- 대조군을 실제로 세어봤는가. "다른 건 안 건드렸다"는 기억이 아니라 숫자여야 합니다. 저는 세어보고 나서야 4.5배를 알았습니다.
- 판정 창 안에서 내가 다른 데를 건드렸는가. 건드린 대상은 대조군에서 빼고, 기준선 분해도 같은 모집단으로 맞추세요. 한쪽만 빼면 비율이 통째로 틀어집니다.
- 바를 고치는 시점이 창이 열리기 전인가 후인가. 전이면 설계 수정이고 후면 사후 바 이동입니다. 같은 코드 변경도 시점이 죄를 정합니다.
솔직한 부분
이 글에는 결과가 없습니다. 판정일은 10월 20일이고, 아직 창도 열리지 않았습니다. 227페이지가 효과가 있었는지 저는 모릅니다.
제가 고친 건 효과가 아니라 효과를 알아볼 수 있는 상태입니다. 그게 대단한 작업은 아니었습니다 — 상수 몇 개와 호스트 목록 하나, 커밋 두 개입니다. 대단하지 않은 만큼, 안 했으면 10월 20일에 초록불 하나를 얻고 아무것도 모른 채 다음 227페이지를 만들었을 겁니다.
지금 돌고 있는 실험이 하나 있다면, 대조군 숫자를 한 번만 뽑아보세요. 판정일에 뽑으면 늦습니다.