4.3A/B 테스트와 반복 개선

두 방법은 경쟁 관계가 아니라 순서 관계입니다.

• 오프라인 평가는 고정된 데이터셋에 후보를 돌려 점수를 냅니다. 빠르고 싸고 반복 가능하지만, 실제 사용자 행동은 알 수 없습니다.
• 온라인 실험은 실제 트래픽을 나눠 후보를 노출합니다. 진짜 답을 주지만 느리고, 나쁜 후보가 실제 사용자에게 노출되는 위험을 감수합니다.

따라서 순서는 오프라인으로 좁히고 온라인으로 확인입니다. 오프라인 점수가 기준선보다 낮은 후보를 온라인에 올리는 것은 사용자를 대상으로 확인 사살을 하는 일입니다. 반대로 오프라인 점수만 보고 전면 배포하는 것도 위험합니다. 오프라인 지표는 대개 대리 지표이고, 사용자가 실제로 그 개선을 체감하는지는 다른 문제이기 때문입니다.

프로 시험에서는 "오프라인 점수가 올랐으니 배포해도 되는가"를 묻는 상황이 자주 나옵니다. 판단 기준은 오프라인 지표가 사업 지표와 얼마나 연결되어 있는지 검증된 적이 있는가입니다. 연결이 검증된 적 없는 대리 지표의 상승만으로는 배포 근거가 약합니다.

실험을 시작하기 전에 문서로 못 박아야 하는 항목이 있습니다. 시작한 뒤에 정하면 결과를 보고 유리한 쪽으로 정하게 됩니다.

1. 무작위화 단위 — 요청 단위인가, 사용자 단위인가, 조직 단위인가. 같은 사용자가 요청마다 다른 버전을 보면 경험이 일관되지 않고, 사용자 단위 지표를 오염시킵니다. 대개 사용자 단위가 안전합니다.
2. 주 지표 하나와 가드레일 지표들 — 무엇이 좋아지면 성공인지 하나로 정합니다. 동시에 나빠지면 안 되는 것(지연시간, 비용, 안전성)을 가드레일로 둡니다.
3. 실험 기간과 최소 표본 — 시작 전에 정하고, 도중에 바꾸지 않습니다.
4. 중단 조건 — 가드레일이 어느 선을 넘으면 즉시 중단할지 미리 정합니다.

주 지표를 하나로 좁히는 이유는 명확합니다. 지표를 열 개 보면 그중 하나는 우연히 좋아지고, 사람은 그 하나를 근거로 삼게 됩니다.

# 무작위화 단위를 사용자로 고정한다.
# 요청마다 무작위로 배정하면 같은 사용자가 버전을 오가게 된다.
def assign_variant(user_id: str, experiment: str) -> str:
    digest = hashlib.sha256((experiment + ":" + user_id).encode()).hexdigest()
    return "treatment" if int(digest[:8], 16) % 2 == 0 else "control"

해시 기반 배정은 상태를 저장하지 않아도 같은 사용자가 항상 같은 버전을 보게 만듭니다. 실험 이름을 해시에 섞는 이유는, 여러 실험이 동시에 돌 때 같은 사용자가 항상 같은 쪽에만 배정되는 편향을 막기 위해서입니다.

실험 결과를 잘못 읽는 방식은 몇 가지로 정해져 있습니다. 프로 시험은 이 함정들을 알고 있는지 묻습니다.

• 조기 중단(peeking) — 매일 결과를 들여다보다가 유의미해 보이는 순간 멈추면, 우연한 변동을 진짜 효과로 오인할 확률이 크게 올라갑니다. 사전에 정한 기간을 채우는 것이 기본입니다.
• 다중 비교 — 지표를 여러 개 보면 그중 일부는 우연히 유의미하게 나옵니다. 주 지표를 미리 정해 두는 이유입니다.
• 유의성과 크기의 혼동 — 표본이 크면 아주 작은 차이도 통계적으로 유의미해집니다. 유의미한가와 의미 있게 큰가는 다른 질문입니다. 효과 크기와 신뢰구간을 함께 보아야 합니다.
• 분할 오염 — 두 집단에 공통 캐시나 공유 상태가 있으면 처치가 대조군에 새어 나갑니다. 프롬프트 캐시를 두 버전이 공유하는 구성이 대표적입니다.
• 신규 효과 — 변화 자체가 잠시 지표를 움직이는 현상입니다. 짧은 실험일수록 이 영향을 크게 받습니다.

세 번째 항목이 실무에서 가장 자주 오해됩니다. "p값이 작으니 배포하자"는 논리는 효과 크기를 보지 않은 것입니다. 지연시간이 5% 늘어나는 대가로 정확도가 0.3%p 오른다면, 통계적으로 유의미하더라도 받아들일 이유가 없을 수 있습니다. 판단은 언제나 트레이드오프 위에서 이뤄집니다.

일회성 실험은 프로젝트이고, 반복 개선은 체계입니다. 체계로 만들려면 실험이 끝난 뒤의 절차까지 정해져 있어야 합니다.

• 결과 기록 — 이긴 실험만이 아니라 진 실험도 기록합니다. 왜 안 됐는지가 다음 가설의 재료가 됩니다.
• 승자 반영과 정리 — 채택된 변경은 기본값으로 승격하고, 실험 분기 코드를 제거합니다. 남겨 두면 조합이 폭발합니다.
• 회귀 사례 편입 — 실험에서 드러난 실패 입력을 회귀 데이터셋에 추가합니다.
• 다음 가설 — 결과를 근거로 다음에 무엇을 시험할지 한 줄로 남깁니다.

이 순환이 돌면 평가 데이터셋이 시간이 지날수록 실제 실패를 더 잘 반영하게 됩니다. 반대로 순환이 끊기면 데이터셋은 처음 만든 시점에 고정되고, 시스템은 변했는데 평가만 과거에 머무는 상태가 됩니다.

에이전트처럼 여러 단계를 거치는 시스템에서는 어느 단계를 바꿨는지 실험 단위로 분리하는 것이 중요합니다. 프롬프트와 도구 정의와 모델을 한꺼번에 바꾸고 실험하면, 좋아졌다는 사실은 알아도 무엇 때문인지는 알 수 없습니다. 알 수 없으면 다음 개선으로 이어지지 않습니다.