Statsig 입문 4편 — Experiments 깊이 · RCT · Allocation · 통계 함정

이 글은 Statsig 입문에서 운영까지 시리즈 4편이에요. 3편 Feature Flags 깊이 의 Built-in A/B 가 느슨한 검증 이었다면, 이번 4편은 과학적 의사결정 도구 — 정식 Experiment.

왜 정식 Experiment 가 따로 필요한가

3편의 Built-in A/B 는 gate 의 Pass / Fail 그룹을 자동 비교. 편하지만 통계 power 가 약함 — rollout 불균등, primary metric 명시 없음, 결정 도구로는 부족.

운영 환경에서 진짜 ship 결정 에 쓸 도구가 필요한데, 그게 Experiment. 무작위 통제 시험 (RCT) 의 모든 과학적 엄격성 을 SaaS 로 옮긴 것.

여기서 처음 들으면 어렵게 느껴지는 자리가 있어요. 통계 용어가 낯설어서. p-value (우연일 확률) · 신뢰도 구간 · SRM (분할 비율 어긋남) · Bonferroni (다중 비교 보정) · sequential testing 같은 단어가 한 번에 쏟아져요. 해결법은 각 개념의 비유 하나씩 잡기. 통계가 아니라 상식의 정리 가 본질.

Experiment 의 핵심 정의

무작위 통제 시험 (A/B 또는 A/B/n 테스트) 을 최소한의 노력으로 실행. 제품 변화와 고객 행동 간의 인과관계 확립 의 가장 신뢰할 수 있는 방법. — 공식 docs

RCT (Randomized Controlled Trial, 무작위 통제 시험) = 상관관계가 아닌 인과관계 측정의 표준. 의학·심리학에서 신약 효과 측정하는 동일 방법론.

왜 RCT 가 인과관계인가

비유 — 한 회사가 결제 버튼 색깔을 빨강으로 바꾸고 매출이 5% 올랐어요. 빨강이 원인인가 아니면 마침 그 주에 큰 마케팅 캠페인 이 있었나? 알 수 없음.

RCT = 같은 시간, 같은 조건 의 사용자들을 무작위 로 두 그룹 분할. 한 그룹 (control) = 파랑, 다른 그룹 (treatment) = 빨강. 외부 요인 동일 → 유일한 차이는 색깔 → 결과 차이 = 색깔의 인과 효과.

→ 비교 가능한 두 그룹 + 동시 실행 = RCT 의 본질.

3 핵심 개념

1. Variant (변형)

실험에서 테스트되는 제품의 특정 버전. A/B 테스트 = 현재 상태 (A, 대조군) + 수정된 상태 (B, 처리군). — 공식 docs

대부분 A/B (2 변형), 가끔 A/B/n (3+ 변형). 변형이 많을수록 각 그룹 sample 작아져 통계 power 약화.

2. Randomization Unit (무작위화 단위)

사용자가 control 또는 treatment 에 무작위로 할당 되는 엔티티. — 공식 docs

선택지는 네 가지. 가장 일반적인 건 User ID — 로그인한 사용자 단위라 UX 가 일관돼요. 로그인 전·비회원 영역은 Device ID 가 적합. Session ID 는 매 세션마다 변형이 바뀌어 UX 가 흔들리니 비권장. B2B 환경이면 Company ID · Custom ID 로 회사·조직 단위.

여기서 시험 함정이 하나 있어요 — 잘못된 단위 = 실험 결과 오염. B2B SaaS 가 userID 로 무작위화하면 같은 회사 사용자 A 가 control, B 가 treatment 가 됨. 동료끼리 다른 UI 보면 혼란 + 실험 결과 신뢰성 ↓. B2B 는 companyID 권장.

3. Allocation (할당)

사용자의 몇 퍼센트 를 실험에 할당할지. 작은 비율부터 시작 해 안정성 확인 후 증가 권장. — 공식 docs

일반 패턴:

Phase 1: 5% allocation → 안정성 확인 (1~2일)
Phase 2: 25% allocation → 초기 통계 수집
Phase 3: 50% allocation → 본격 측정 (1~2주)

전체 사용자의 50% 가 실험에 참여 → 그 중 50/50 으로 control / treatment 분할 → 즉 전체의 25% 가 treatment.

여기서 정말 중요한 시험 함정 — Allocation 을 감소시키면 그룹 할당에 편향 발생 (공식 docs). 50% → 25% 로 줄이면 기존 50% 의 사용자 중 일부 무작위 제외 — 그 결과 남은 그룹 특성 변동. → 늘리기는 OK, 줄이기는 신중.

Statsig 의 실험 생성 6 단계

Step 1. 기본 설정

console 에서 실험명 · 설명 · 가설. 가설은 명시 작성 — "새 추천 알고리즘이 결제 전환율을 5% 이상 올린다" 같은 측정 가능한 진술.

Step 2. Scorecard — Metric 설정

Scorecard = 실험의 측정 기준. Primary Metric 은 결정에 쓸 핵심 지표 로 1개 필수, Secondary Metric 은 부수 지표 라 다수 가능.

Primary 의 의미 — 통계적 유의 + Primary 가 좋아짐 = ship 결정. Secondary 만 좋아져도 결정 근거 불충분.

대표 Primary 는 결제 전환율, 회원 가입 완료율, 7일 retention, 매출 per user 같은 최종 비즈니스 결과. 대표 Secondary 는 페이지 체류시간, 클릭률, 에러율, 응답 시간 같은 과정 지표.

Step 3. Allocation 설정

전체 사용자 중 N% 가 실험에 진입. 각 variant 의 50/50 또는 우대 분할 가능.

Allocation: 50%
  Variant Control: 50% (= 전체의 25%)
  Variant Treatment: 50% (= 전체의 25%)

Step 4. Targeting

3편의 Targeting Rules 동일. VIP 사용자만 실험 참여 같은 조건.

Inline targeting = 실험 내부에서 직접 condition 설정. Gate reference = 기존 Feature Gate 의 결과로 실험 진입 제한.

Step 5. ID Type 선택

기본 = userID. Device 단위 실험 이면 deviceID · B2B 면 companyID.

Step 6. 통계 설정

세 가지를 정해요. Confidence Level 은 95% 가 기본이고 90% · 99% 도 선택 가능. Correction 은 다중 비교 시 Bonferroni 보정(여러 메트릭 검정 시 임계값 엄격화) 적용. Target duration 은 운영 일수 또는 노출 수로 종료 조건을 미리 박아 둠.

Layer — 격리된 실험

다른 실험에 노출된 사용자를 제외 하려면 전용 Layer 생성. — 공식 docs

Layer 의 필요성

여러 실험이 겹쳐 동작하면 상호 간섭 위험. 결제 버튼 색깔 실험 과 추천 알고리즘 실험 이 같은 사용자 group 에 적용되면, 결제 전환율 변화가 어느 실험의 효과 인지 모호.

Layer = 동일 사용자가 한 Layer 의 한 실험에만 참여. 서로 격리.

Layer A: 결제 관련
  ├─ 결제 버튼 색깔 실험
  └─ 결제 step 수 줄이기 실험
Layer B: 추천 관련
  ├─ 추천 알고리즘 V1 vs V2
  └─ 홈 carousel 순서 실험

같은 사용자가 Layer A 의 결제 색깔 실험 + Layer B 의 추천 실험 동시 참여 OK. 단 Layer A 안의 두 실험 동시 참여 X.

→ 큰 회사의 여러 동시 실험 운영의 핵심 도구.

통계적 유의성 — 핵심 개념 풀이

여기서 몇 가지 통계 용어를 비유로 풀어요.

p-value — 우연일 확률

비유 — 동전 100번 던져서 앞면 60번 나옴. 공정한 동전이라도 우연히 60번 나올 확률 = 약 5%. 이게 p-value.

p < 0.05 = 통상적 통계적 유의성 기준. 우연이 아닐 가능성 95%.

Confidence Interval (CI, 신뢰 구간) — 효과의 범위

비유 — 치즈 평균 가격 을 추정. 5,000 ~ 7,000원 이라고 추정 = "참 평균이 이 범위에 있을 확률 95%" = 95% CI.

실험 결과:
  Treatment - Control = +3.5%
  95% CI: [+1.2%, +5.8%]

해석 — 참 효과가 +1.2% ~ +5.8% 사이일 확률 95%. CI 가 0 을 포함하지 않음 = p < 0.05 = 통계적 유의.

p-value 와 CI 의 관계

p-value < 0.05 ⇔ 95% CI 가 0 을 포함하지 않음. 두 표현은 같은 동전의 두 면.

운영에서 — p-value 만 보면 효과의 크기 가 안 보임. CI 도 함께 봐서 실효 크기 판단 권장.

함정 1: p-hacking — 통계 결과 조작

시험 함정 — 같은 데이터를 여러 방식으로 분석 하다가 p < 0.05 우연히 나오는 것 만 채택.

흔한 패턴

실험 종료 후 segment 별 분석 으로 한국 사용자만·iOS 만 잘라 보다가 어떤 segment 에서 우연히 유의 가 나오는 경우. 여러 메트릭 을 동시에 들여다보다 그 중 하나만 유의 한 걸 채택하는 경우. 실험 기간 을 유의해질 때까지 연장 하는 경우.

20번 분석하면 우연으로 한 번은 p < 0.05 — false positive.

해결 — Bonferroni 보정

여러 메트릭 동시 검정 = 임계값 보정. 일반적 0.05 대신 0.05 / N (N = 메트릭 수) 사용.

3개 메트릭 동시 검정:
  보정 전: p < 0.05
  보정 후 (Bonferroni): p < 0.05 / 3 = 0.0167

→ 더 엄격한 기준 으로 false positive 줄임. Statsig 의 Correction 옵션이 이것.

함정 2: Peeking · Sequential Testing

시험 함정 — 실험 매일 결과 봐서 통계적 유의 도달하자마자 종료.

왜 위험한가

전통적 통계 = 고정 sample 크기 가정. 매일 결과 보고 즉시 종료 = false positive 확률 폭증.

원래 0.05 false positive rate
  → 매일 peek 하면 실제 0.20+ 까지 폭증

5번 종료 결정 기회 = 5 번의 우연 가능성. 실제로는 false positive.

해결 — Sequential Testing

Sequential Testing (순차 검정) = peek 가능 하면서도 false positive rate 통제 하는 통계 방법.

핵심 — 매번 peek 마다 임계값 조정. 초기에는 더 엄격, 시간 지날수록 완화. 전체적으로 0.05 유지.

Statsig 의 기본 통계 엔진 이 sequential testing 활용 (Enterprise plan). peek 안전 + 조기 종료 가능.

그냥 매일 보는 게 OK 인가

대시보드 모니터링은 OK, 결정 (ship) 은 충분한 sample 도달 후. sequential testing 없는 plan = 고정 기간 미리 정해서 sticking.

함정 3: Sample Ratio Mismatch (SRM)

여기서 정말 미묘한 함정 — 무작위 분할이 실제로 일어나지 않음.

문제 정의

50/50 무작위 분할로 설계 → 실제 데이터 = 48% / 52%. 우연일까 버그일까?

Sample Ratio Mismatch (SRM, 분할 비율 어긋남) = 예상 분할 비율 ≠ 실제 분할 비율 이 통계적으로 유의 한 경우. 거의 항상 버그 신호.

흔한 원인

가장 자주 보는 건 Bot/crawler 차별 — 한쪽 variant 만 bot 이 더 많이 hit 해서 비율이 어긋나는 경우. 에러로 사용자 이탈 — treatment 의 코드 버그로 해당 사용자 trace 가 안 남는 경우. 로그인 transition — anonymous 단계의 무작위 + 로그인 후 ID 변경 → 한쪽 group 만 카운트되는 경우. Cache 문제 — 한쪽 variant 가 CDN 캐시에 더 잘 박혀 latency 와 사용자 행동이 갈리는 경우. Targeting bug — rule 의 일부 조건이 한쪽 그룹만 영향 주는 경우.

Detection

대부분 카이제곱 검정 으로 자동 감지. Statsig dashboard 에서 SRM 경고 표시.

→ SRM 발생 시 결과 무효 + 원인 디버깅 후 실험 재시작. 결과 신뢰 X.

함정 4: 너무 짧은 sample

통계 power 부족

시험 함정 — 3일 만에 실험 종료. 효과가 있어도 p < 0.05 도달 X = false negative.

기본 가이드 — 최소 1주 운영해서 요일 효과를 흡수. 각 variant 당 수천 명 이상 모이도록 (메트릭에 따라 다름). Statsig 의 Power Analysis 로 필요 sample 을 사전 추정 하면 안전.

Weekly Seasonality

사용자 행동 = 요일별 다름. 월~금 vs 주말 = 다른 패턴. 최소 7일 운영 = 요일 효과 평균화.

함정 5: Novelty Effect · Primacy Effect

Novelty Effect (신규성 효과) — 새 기능이라 일시적으로 클릭률 ↑. 1~2주 후 정상화.

Primacy Effect (초기 거부 효과) — 기존 사용자 처음엔 거부감, 익숙해진 후 evaluation 가능.

→ 실험 운영 기간 을 최소 1~2주 + 이상치 안정화 까지 확보.

실험 Lifecycle — 8 단계 의사결정

1. 가설 정의 — "새 알고리즘이 결제율 ↑"
2. Allocation · Metric · Layer 설정
3. 작은 allocation (5%) 시작 — 안정성 확인
4. SRM check — 무작위화 정상?
5. Allocation 증가 (25% → 50%)
6. 충분 sample + 기간 도달
7. 통계 분석 — p-value · CI · 비즈니스 임팩트
8. 결정:
   - 통계 유의 + 의미 있는 효과 → ship (Rollout)
   - 통계 유의 but 미미한 효과 → 폐기
   - 통계 비유의 → 추가 sample 또는 폐기

좋은 가설 vs 나쁜 가설

나쁜 예

"새 디자인이 좋을 것" — 측정 불가. "버튼 색깔이 영향 줄 것" — 어떤 영향인지 모호. "전반적으로 개선" — primary metric 자체가 흐릿.

좋은 예

"빨강 버튼이 결제 전환율을 5% 이상 올린다 (CI 95%)" — 측정 가능 + 임계값. "새 추천 알고리즘이 첫 결제까지 시간을 30% 단축한다" — 명시적 metric. "홈 carousel 개선이 7일 retention 을 +2pt 올린다" — 정확한 metric.

→ 측정 가능 + 명시적 임계값 + 단일 primary metric.

비즈니스 임팩트 vs 통계 유의성

여기서 정말 중요한 자리 — 통계 유의 ≠ 비즈니스 결정.

실험 결과: +0.3% 결제율 (p < 0.001, 매우 유의)

→ 통계적으로 명확하게 효과 있음. 단 효과 크기가 0.3% → 비즈니스 결정엔 마진 충분한가 추가 검토.

0.3% × 연 매출 1000억 = 3억이라 ship 가치. 반대로 0.3% × 연 매출 1억 = 30만원이라 운영 비용이 효과보다 커서 폐기.

→ CI 의 하한값 도 검토 ("최악의 경우 +0.1% 만 올라도 가치 있나").

자주 만나는 사고 — Experiment 운영

사고 1: 잘못된 Randomization Unit

원인 — B2B 인데 userID 로 무작위화 → 같은 회사 내 다른 변형.

해결 — companyID 로 무작위화 + 결과 신뢰성 검증.

사고 2: Allocation 감소 → 편향

원인 — 50% → 25% 로 줄임 → 남은 사용자 특성 편향.

해결 — 늘리기만. 줄여야 하면 기존 실험 종료 + 새 실험 시작.

사고 3: 여러 메트릭 → false positive

원인 — Primary 1 + Secondary 5 → Secondary 중 하나 유의 라 ship 결정.

해결 — Primary 만 ship 결정, Secondary 는 추가 정보. 또는 Bonferroni 보정.

사고 4: SRM 무시

원인 — 50/50 인데 47/53 분할 → 우연이라고 무시 후 결정.

해결 — SRM 경고 = 무조건 디버깅. 원인 모르면 결과 무효.

사고 5: Peeking → 조기 종료

원인 — 3일째 p < 0.05 라 ship → 실제는 우연.

해결 — Sequential testing 사용 또는 고정 기간 미리 정함.

사고 6: 너무 작은 효과로 ship

원인 — +0.1% 효과 가 p < 0.01 이라 ship → 비즈니스 가치 없음.

해결 — 효과 크기 임계값 (예: 1%+) 미리 정의.

사고 7: Novelty effect 로 잘못된 ship

원인 — 첫 주 큰 효과 보고 ship → 1개월 후 정상화 + 효과 0.

해결 — 최소 2주 운영 + 마지막 며칠 trend 안정화 확인.

사고 8: Layer 미설정으로 cross-실험 간섭

원인 — 두 관련 실험이 같은 사용자 에 동시 적용 → 효과 분리 불가.

해결 — 논리적으로 관련된 실험 은 같은 Layer.

운영 권장 패턴

Pattern 1: 표준 실험 lifecycle

1. 가설 작성 (측정 가능 · 명시적 임계값)
2. Primary metric 1개 · Secondary 2~3개 선정
3. Sample size 계산 (Power analysis)
4. Layer 결정 (관련 실험과 격리)
5. Allocation 5% 시작
6. SRM check (24시간 후)
7. Allocation 50% 까지 증가
8. 최소 1주 · 권장 2주 운영
9. 통계 + 비즈니스 임팩트 판단
10. Ship · 폐기 · 추가 분석 결정

Pattern 2: 가설 template

가설: [기능 변경] 이 [primary metric] 을 [임계값] 이상 [개선 방향] 시킨다

예시:
"새 추천 알고리즘 (treatment) 이 7일 retention 을 절대값 1.5pt 이상 올린다
 (control 대비, 95% CI 하한값 ≥ +0.5pt 기준)"

Pattern 3: Power analysis 활용

# 사전 추정
baseline_retention = 0.25         # 25%
expected_lift = 0.015              # 1.5pt 절대 증가
required_sample_per_variant = power_analysis(
    baseline=baseline_retention,
    lift=expected_lift,
    power=0.8,                     # 80% power
    alpha=0.05
)
# → 약 N 명 per variant 필요

운영 환경의 user traffic 으로 필요 기간 추정. 너무 작은 효과 = 비현실적 기간 → 실험 안 함 의 결정도 OK.

Pattern 4: Layer 설계

Layer "Checkout":
  - 결제 버튼 색깔 실험
  - 결제 step 수 실험
  - 결제 에러 메시지 실험

Layer "Discovery":
  - 추천 알고리즘 실험
  - 검색 ranking 실험
  - 홈 carousel 실험

Layer "Pricing":
  - 가격 표시 실험
  - 할인 전략 실험

기능 영역별 layer 분리. 새 실험은 가장 관련된 layer 에 추가.

Pattern 5: SRM 자동 alert

SRM detection threshold: 0.01 (chi-square p-value)
Notify: Slack #experiment-alerts
Auto-action: 실험 자동 pause (Enterprise)

매일 SRM check + 발생 시 즉시 alert. 결과 신뢰성 의 안전선.

Pattern 6: 실험 결과 weekly review

매주 정기 실험 dashboard review 미팅에서 진행 중 실험들의 progress 를 확인하고, 유의 도달 후 결정 회의를 진행, 종료 실험은 가설 vs 결과 복기까지 마무리.

→ 실험 문화 의 정착. 데이터 기반 의사결정 의 습관.

시험 직전 한 번 더 — Experiments 깊이 함정 압축 노트

• Experiment vs Built-in A/B (3편) — 엄격한 검증 도구 vs 느슨한 모니터링
• RCT (무작위 통제 시험) = 인과관계 측정의 표준
• 동시 실행 + 무작위 분할 + 외부 요인 동일 = 유일한 차이는 변경
• Variant 3 종 = Control (A) · Treatment (B) · A/B/n
• 변형 많으면 그룹 sample ↓ → 통계 power 약화
• Randomization Unit = User · Device · Session · Company · Custom
• B2C = userID, B2B = companyID
• Session = UX 비일관 (비권장)
• 잘못된 단위 = 결과 오염
• Allocation = 실험 참여 사용자 비율
• 작게 시작 (5%) → 단계적 증가 (25% → 50%)
• Allocation 감소 = 그룹 편향 발생 (늘리기만 권장)
• 실험 생성 6 단계 = 기본 → Scorecard → Allocation → Targeting → ID Type → 통계 설정
• Primary Metric = 결정 기준 (1개 필수)
• Secondary Metric = 부수 정보 (다수 가능)
• ship 결정 = Primary 가 통계 유의 + 의미 있는 효과
• Layer = 격리된 실험 group
• 한 Layer 안 = 사용자가 한 실험만 참여
• 다른 Layer = 동시 참여 OK
• 큰 회사의 여러 동시 실험 필수
• p-value = 우연일 확률
• p < 0.05 = 통계적 유의 (관행)
• Confidence Interval (CI) = 효과 추정 범위
• 95% CI 가 0 포함 X = 유의
• p-value · CI 는 같은 동전 두 면
• 효과 크기 (CI) 도 함께 검토
• p-hacking 함정 — 여러 분석으로 p < 0.05 hunting
• 해결 = Bonferroni 보정 (0.05 / N)
• Peeking 함정 — 매일 결과 보고 조기 종료
• false positive rate 폭증 (0.05 → 0.20+)
• 해결 = Sequential Testing (Statsig 기본 엔진)
• 없는 plan = 고정 기간 미리
• Sample Ratio Mismatch (SRM) = 예상 분할 ≠ 실제
• 흔한 원인 = bot 차별 · 코드 버그 · 로그인 transition · cache · targeting bug
• 자동 detection (카이제곱)
• SRM 발생 = 결과 무효 + 디버깅
• 너무 짧은 sample = false negative
• 최소 1주 (요일 효과) + 권장 2주
• Power analysis 로 필요 sample 추정
• Novelty Effect = 새 기능 일시 클릭률 ↑ → 1~2주 후 정상
• Primacy Effect = 거부감 → 익숙해진 후 evaluation
• 통계 유의 ≠ 비즈니스 결정
• 효과 크기 × 비즈니스 규모 = 가치 판단
• CI 하한값 검토 (최악의 경우)
• 좋은 가설 = 측정 가능 + 명시적 임계값 + 단일 primary
• 실험 lifecycle 8 단계 = 가설 → 설정 → 5% 시작 → SRM check → 증가 → 충분 sample → 분석 → 결정
• 사고 — 잘못된 단위 · Allocation 감소 · 다중 메트릭 · SRM 무시 · Peeking · 작은 효과 ship · Novelty · Layer 미설정
• 패턴 — 표준 lifecycle · 가설 template · Power analysis · Layer 설계 · SRM alert · weekly review

공식 문서: Experiments Overview · Create New Experiment 에서 원문을 확인할 수 있어요.

시리즈 다른 편 (앞뒤 글 모음)

이전 글:

• 1편 — 통합 플랫폼 종합 (Feature Flag · 실험 · 분석 · Infra)
• 2편 — SDK Quickstart · 30분 첫 Feature Gate
• 3편 — Feature Flags 깊이 · Targeting · Rollout · Holdout

다음 글:

• 5편 — Product Analytics 깊이 · 6 차트 · Funnel · Retention
• 6편 — Warehouse Native 깊이 · Snowflake · BigQuery · dbt 결합
• 7편 — CDP · Slack · MCP · Webhook 운영 통합
• 8편 — Session Replay · Web Analytics · Infra Analytics
• 9편 — 시리즈 마무리 · 도입 결정 · 경쟁 도구 · 학습 경로