A/B 테스트는 웹 개발에서 가장 성공적인 아이디어 중 하나입니다. 그것은 의견을 증거로 대체했습니다. "사용자들이 초록색 버튼을 선호할 것 같아요"라는 말을 테스트 가능한 주장으로 바꾸어 놓았습니다. 제정신인 사람이라면 누구도 느낌(vibes)에 의존하여 제품을 출시하는 시절로 돌아가고 싶어 하지 않을 것입니다.

따라서 이 글은 "A/B 테스트는 멍청하다"라는 내용의 글이 아닙니다. A/B 테스트는 _좁은 범위의 가설들이 내재된 좋은 도구_입니다. 그리고 그 가설들은 2010년의 웹에서 비롯되었습니다. 그중 세 가지가 조용히 무너지고 있습니다. 그중 하나는 올해 이미 무너졌습니다.

그 가설들을 살펴봅시다. 일단 한 번 보고 나면, 다시는 이전처럼 볼 수 없을 것입니다.

가설 1: 최적화할 가치가 있는 "평균 방문자"가 존재한다

A/B 테스트는 다음과 같이 묻습니다: 어떤 변형(variant)이 승리하는가? 단 하나입니다. A와 B를 실행하여 승자를 얻고, 그 승자를 모든 사람에게 배포합니다.

하지만 "승자"란 전체 트래픽 믹스(traffic mix) 전체에 걸쳐 평균적으로 가장 높은 성과를 낸 변형을 의미합니다. 그리고 당신의 트래픽은 하나의 청중이 아닙니다. 그것은 서로 겹겹이 쌓여 있는 여러 청중의 집합입니다:

• Hacker News를 통해 유입되어 모든 글자를 읽는 개발자
• LinkedIn 광고를 통해 유입되어 4초 안에 가격을 확인하고 싶어 하는 구매자
• 당신이 무엇을 하는지 이미 알고 있는 재방문 사용자
• 다른 시간대에 있는 3G 휴대폰 사용자

A/B 테스트는 이들 모두를 하나의 숫자로 압축하고 평균값이 가장 좋은 변형을 선택합니다. 이는 평균 방문자를 위해 최적화하는 것이며, 평균 방문자란 존재하지 않습니다. 그것은 누구에게도 맞지 않는 평균적인 조종사를 위해 설계된 Norden 폭격기 조종석과 같습니다. 당신은 A/B 테스트에서 승리할 수 있지만, 여전히 모든 실제 세그먼트(segment)에게 그들이 가질 수 있었던 것보다 더 나쁜 경험을 보여줄 수 있습니다.

"서로 다른 방문자는 서로 다른 것을 원한다"는 사실을 받아들이는 순간, 단일 승자는 더 이상 목표가 되지 않습니다. 당신이 실제로 원하는 것은 _누가 나타났느냐에 따라 조건화된(conditioned on) 올바른 변형_입니다.

가설 2: 통계적 유의성(significance)에 도달할 만큼 충분한 트래픽이 있다

아무도 입 밖으로 내기 싫어하는 부분이 바로 여기입니다: 대부분의 A/B 테스트는 통계적 유의성(statistical significance)에 도달하지 못하며, 그럼에도 팀들은 배포를 진행합니다.

필요한 표본 크기(sample size)는 효과(effect)가 작을수록 잔인할 정도로 커집니다. 80%의 검정력(power)과 95%의 신뢰 수준(confidence)에서, 3%의 기본 전환율(baseline conversion rate)이 3.3%로 상승하는 것(실제로는 10%의 존중할 만한 상대적 상승임)을 감지하려면 대략 다음과 같은 수치가 필요합니다:

n ≈ 16 * p(1-p) / (MDE)²
  ≈ 16 * 0.03 * 0.97 / (0.003)²
  ≈ 변형(variant)당 약 51,000명의 방문자

즉, 단 하나의 변경 사항에 대한 단 한 번의 테스트를 위해 약 10만 명의 방문자가 필요하다는 뜻입니다. 대부분의 사이트는 한 달 동안 이 정도의 트래픽을 확보하지 못합니다. 그래서 실제로 일어나는 일은 다음과 같습니다:

• 테스트를 2주 동안 실행합니다.
• 대시보드에는 B안이 "12% 상승"했다고 표시됩니다.
• p-value(p-값)는 0.34입니다.
• 누군가가 "이 정도면 충분해, 배포하자"라고 말합니다.

축하합니다. 당신은 방금 노이즈(noise)를 배포하고 그것을 데이터라고 기록했습니다. 그리고 당신은 다음 스프린트에서도 똑같은 일을 반복할 것입니다. 왜냐하면 수학적 근거가 없을 때조차 그 의식(ritual)이 엄격하게 느껴지기 때문입니다. 검정력이 부족한(Underpowered) 테스트는 직관보다 나은 것이 아닙니다. 그것은 단지 실험실 가운을 입은 직관일 뿐입니다.

가설 3: 웹은 에피소드 단위로 테스트할 수 있을 만큼 충분히 느리게 움직인다

A/B 테스트는 **배치 프로세스(batch process)**입니다. 실험을 설정하고, 변형(variants)을 고정하고, 달력이 유의성을 부여할 때까지 기다렸다가, 승자를 선택하고, 실험을 종료합니다. 결정 하나를 내리는 데 몇 주가 걸립니다.

2026년의 배치 방식에는 두 가지 문제가 있습니다:

후회 문제(The regret problem). 테스트 기간 전체 동안, 당신은 점점 더 성능이 나쁘다고 의심되는 변형(variant)으로 트래픽의 약 50%를 계속 보냅니다. 증거가 쌓이고 있음에도 불구하고, 테스트 설계상 종료일까지 그 비용을 계속 지불해야만 합니다. 문헌에서는 이 낭비되는 트래픽을 _후회(regret)_라고 부르며, A/B 테스트는 구조적으로 이 후회를 극대화합니다.

노후화 문제(The staleness problem). 당신이 선정된 승자는 테스트 기간 동안 가졌던 트래픽 구성(traffic mix)에 최적화된 것입니다. 그 후 Product Hunt 런칭이 이루어지거나, 캠페인으로 인해 유입 경로 구성이 바뀌거나, 계절성이 닥치면, 당신의 "승자"는 이제 더 이상 존재하지 않는 오디언스(audience)에 맞춰 조정된 상태가 됩니다. 당신은 다음 분기 테스트가 올 때까지 이 사실을 알지 못할 것입니다.

여기서의 대안은 새로운 것이 아니라, 단지 프론트엔드(frontend)에서 충분히 활용되지 않았을 뿐입니다: 바로 **멀티 암드 밴딧 (multi-armed bandits)**입니다. 고정된 분할 대신, 당신은 학습함에 따라 승리하고 있는 쪽으로 트래픽을 이동시키며, 약간의 탐색 (exploration) 상태를 유지합니다.

// A/B 테스트: 내내 50/50으로 고정, 마지막에 결정
const variant = Math.random() < 0.5 ? "A" : "B";

...

동일한 근거를 바탕으로 하지만 후회 (regret)는 훨씬 적으며, 결코 "끝나지" 않습니다 — 그저 계속해서 적응할 뿐입니다. 배치 실험 (batch experiment)이 연속적인 프로세스가 됩니다.

올해 이 가설을 무너뜨린 가정: 방문하는 모든 이는 인간이다

위의 모든 가정은 여전히 _사람_이 당신의 페이지에 접속하여, 인상을 형성하고, 결정을 내리는 세상에 머물러 있습니다. A/B 테스트는 근본적으로 **세션(session)에 걸친 인간 행동 (human behavior)**에 관한 이론입니다.

그런데 당신의 트래픽 중 의미 있는 일부가 더 이상 인간이 아니게 되었습니다.

최근 로그를 살펴보았다면 확인했을 것입니다: GPTBot, ChatGPT-User, Claude-User, PerplexityBot, 그리고 누군가를 대신해 질문에 답하기 위해 — 종종 당신의 자바스크립트 (JavaScript)를 실행하지 않은 채 — 당신의 페이지를 가져오는 에이전트 (agents)의 거센 물결를 말입니다. 그들은 스크롤하지 않습니다. 퍼널 (funnel)을 통해 A/B 테스트를 거치지도 않습니다. 두 번째 방문에서 돌아와 전환 (convert)하지도 않습니다. 그들은 읽고, 추출하고, 떠납니다. 당신이 정성스럽게 테스트한 히어로 헤드라인 (hero headline)은 그들에게 아예 _렌더링 (rendered)_조차 되지 않을 수도 있습니다.

이는 당신이 패치(patch)할 수 없는 방식으로 A/B 테스트를 망가뜨립니다:

• 그들을 동일한 방식으로 측정할 수 없습니다. 세션도 없고, 퍼널도 없으며, 종종 JS도 없기 때문에 클라이언트 측 실험 프레임워크 (client-side experiment framework)조차 실행되지 않습니다.
• 동일한 것을 최적화할 수 없습니다. 사실을 추출하는 에이전트에게 "어떤 버튼이 더 잘 전환되는가"는 무의미합니다. 질문은 _"내 콘텐츠가 읽기 쉽고 답변 가능한가?"_로 바뀌며, 이는 완전히 다른 목표입니다.
• 현재의 도구에서는 그들이 보이지 않습니다. 대부분의 분석 도구 (analytics)는 JS를 사용하지 않는 에이전트 트래픽을 조용히 누락시키므로, 가장 빠르게 성장하는 방문자 세그먼트가 당신이 A/B 테스트를 수행하는 데이터에 나타나지도 않습니다.

A/B 테스트를 통해 훌륭한 에이전트 경험 (agent experiences)을 만들어낼 수는 없습니다. 왜냐하면 그 전제 조건인 '당신이 유도할 수 있는 결정을 내리는 인간'이 존재하지 않기 때문입니다. 당신은 (a) 에이전트 트래픽을 일급 시민 세그먼트 (first-class segment)로 보고, (b) 인간을 위한 목표와는 다른 목표를 에이전트를 위해 최적화해야 합니다.

그렇다면 무엇이 이를 대체할까요?

'아무것도 없는 것'도 아니고, '하나의 영리한 도구'도 아닙니다. 변화의 핵심은 테스트 (testing) (단일 승자를 찾아 모두에게 배포하는 것)에서 적응 (adapting) (누가 — 혹은 무엇이 — 나타났는지에 따라 조건부로 적절한 경험을 제공하는 것)으로의 전환입니다.

• 평균이 아닌 세그먼트별로 (per segment) 최적화하십시오. 서로 다른 페르소나 (personas), 소스, 디바이스는 서로 다른 변형 (variants)으로 수렴할 수 있습니다.
• 분할된 트래픽을 3주 동안 고정하는 대신, 효과가 있는 쪽으로 트래픽을 지속적으로 (continuously) 할당하십시오.
• 에이전트를 그들만의 목적 함수를 가진 독자적인 세그먼트로 취급하십시오. 그들의 목적은 클릭이 아니라 가독성 (legibility)입니다.

구체적으로 이는 "실험 #47을 설정한다"는 느낌보다는, 무엇이 적응형인지 선언하고 시스템이 수렴하도록 맡기는 방식에 가깝습니다:

// 무엇이 변할 수 있는지, 그리고 무엇이 "좋은 것"인지를 표시합니다.
// 시스템은 방문자별로 결정하며 — 인간과 에이전트를 포함하여 — 계속해서 학습합니다.
<Adaptive goal="signup">
...

이 논거의 솔직한 버전

A/B 테스트가 쓸모없어진 것은 아닙니다. 만약 당신이 엄청난 트래픽을 보유하고 있고, 수백만 건의 세션이 발생하는 사이트의 결제 흐름 (checkout flow)처럼 단 하나의 높은 이해관계가 걸린 인간 대상의 결정이 있다면, 깔끔한 A/B 테스트는 여전히 옳고 엄격한 선택입니다. 그 영역에서는 계속 사용하십시오.

하지만 대부분의 팀처럼 통계적 유의성 (significance)에 도달할 만큼의 트래픽이 충분하지 않고, 하나의 퍼널 (funnel) 안에 여러 오디언스 (audiences)가 숨어 있으며, 사람이 아닌 소프트웨어인 방문자의 비중이 점점 늘어나고 있다면, 기존의 도구는 설계된 적 없는 가설들을 지탱하라는 요구를 받고 있는 것입니다. 이것은 A/B 테스트를 비난하는 것이 아닙니다. 단지 A/B 테스트가 설계되었던 웹이 그 밑바닥에서 조용하고 영구적으로 변하고 있을 뿐입니다.

웹은 이질적이고, 연속적이며, 비인간적으로 변했습니다. 우리의 최적화 도구 또한 그래야 합니다.

저는 바로 이러한 변화를 중심으로 SentientUI를 구축하고 있습니다. 에피소드 중심의 테스트(episodic tests) 대신 적응형 인터페이스(adaptive interfaces)를 제공하며, 에이전트 트래픽(agent traffic)을 일급 시민 세그먼트(first-class segment)로 취급합니다. 적응(adaptation)과 에이전트 가독성(agent-legibility) 부분이 실제로 내부에서 어떻게 작동하는지 확인하고 싶다면 SDK는 오픈 소스로 공개되어 있습니다. 여러분의 로그는 어떤 모습일지 궁금합니다. 여러분의 트래픽 중 비인간(non-human) 트래픽은 이미 어느 정도나 되나요? 댓글로 숫자를 남겨주세요.