experiment

name	experiment
description	A/B 실험을 설계하고 결과를 판독한다. 가설·지표·표본·기간·판정기준을 잡고, 결과가 나오면 유의성과 다음 액션을 신중히 해석한다. "실험 설계 / A/B 테스트 / 이거 유의미해? / 실험 결과 봐줘" 요청 시.

작업 흐름(항상): 왜(목적·의도) → 무엇을 → 어떻게 → 기존 컨텍스트·리서치 → 기획 → 시각화 → 호출·실행 → 🔁회고·보완. 자세히 [[method]].

실험 설계 & 결과 판독

실험은 잘못 다루면 틀린 확신을 준다(성급한 결론·p-해킹). 그래서 무작정 결론내지 않는다.

무작정 하지 않기 (중요)

결과 판독은 통계적 함정이 많다. 바로 "유의미함/아님"을 단정하지 말고, 먼저 "이렇게 설계/판독을 도와줄 수 있어요 — 이 정보가 필요해요" 를 알리고 표본·기간·지표를 확인한 뒤 진행한다.

모드 A — 설계

1. 가설: "무엇을 바꾸면(원인) → 무엇이 좋아진다(결과)" + 왜 그렇게 믿나(근거/추정 구분).
2. 지표: 1차 지표 1개(성공 판단) + 가드레일 지표(악화되면 안 되는 것).
3. 대상·분배: 누구를, 어떻게 나눌지(무작위·비율). 오염 요인 점검.
4. 표본·기간: 감지하려는 효과 크기 대비 대략적 표본/기간 감(정밀 계산이 필요하면 그렇다고 말함). 너무 이르게 끄지 않기.
5. 판정 기준·시점: 미리 정한다(사후에 바꾸지 않기). 실패 시 롤백.
6. 롤아웃 계획: 이기면 어떻게 확대.

모드 B — 결과 판독

• 데이터를 받아: 효과 방향·크기, 표본/기간이 충분한지, 우연 가능성.
• 주의: 상관≠인과, 다중비교·조기중단·세그먼트 체리피킹 경계. 근거 없는 유의성 주장 금지, 불확실은 불확실로.
• 판정: 채택/기각/판단보류(더 필요) + 왜. 다음 액션.

산출

설계서 또는 판독 리포트 + "왜 이렇게 봤는지". 결정은 [[decision-log]]에 기록, 지표는 [[metrics-report]]와, 스펙은 [[write-spec]]와 연결.

원칙 (코칭)

통계를 진리로 포장하지 않기 · 미리 정한 기준 지키기 · 왜를 설명 · 판단은 사람 · 신입이 실험적 사고를 배우게 짚어주기.