실험 설계의 기초 — Theory of Change 와 4 단계 절차 (Buisson Ch.8 overview)

1 정의

정의: Theory of Change (ToC)

비영리·정부 기획 분야에서 빌려온 framework — 실험의 개입 (intervention) 과 비즈니스 목표 (goal) 사이의 인과 메커니즘을 명시적으로 연결하는 도구 (Buisson, 2021, Ch.8).

한 문장 형식:

“[INTERVENTION] 을 시행하면 [BEHAVIORAL LOGIC] 을 통해 [TARGET METRIC] 으로 측정되는 [BUSINESS GOAL] 을 달성한다.”

AirCnC 사례:

“[1-click booking 버튼] 을 시행하면 [예약 프로세스 시간 단축] 을 통해 [예약 완료 확률] 로 측정되는 [더 높은 매출] 을 달성한다.”

CD 표현:

1-click 버튼 ──→ 예약 프로세스 시간 단축 ──→ 예약 완료 (Y/N) ──→ 매출

직관 — ToC 의 4 구성 요소가 모두 필요한 이유

분석가의 자연스러운 직감: “버튼 만들고 A/B 테스트 돌리면 끝.”

이 직감의 함정:

• Intervention 만: 무엇을 측정할지, 왜 효과가 있을지 모름 → 결과 해석 불가
• Business Goal 만: 측정 어려움 (수익 vs 매출 vs 만족도?) → 모호
• Target Metric 만: 비즈니스적으로 의미 있는지 모름 → 운영 metric 만 좋아져도 비즈니스 의미 없을 수도
• Behavioral Logic 만: 실제 효과 검증 안 됨 → 추측만

4 가지 모두 명시하면:

• 실험 결과가 비즈니스 의사결정에 직결
• 결과 해석 명확 (예상한 메커니즘이 작동했는가?)
• 실패 시 진단 가능 (어느 화살표가 부서졌는가?)
• 비즈니스 파트너와 의사소통 명료

→ ToC 는 실험의 계획 + 의사소통 + 분석 의 통합 도구.

2 실험 설계의 4 단계

전체 절차

1. 계획 (Plan)
   ├── Theory of Change 명시
   ├── Business Goal + Target Metric 결정
   ├── Intervention 정의
   └── Behavioral Logic 표현

2. Random Assignment (배정)
   ├── Timing: 언제 배정?
   ├── Level: 누구 단위로?
   └── Tracking: 어떻게 기록?

3. Sample Size / Power Analysis
   ├── 효과 크기 가정 (MDE)
   ├── 통계적 power 결정
   └── 표본 크기 산출

4. Analysis (분석)
   ├── 회귀 또는 t-test
   ├── 효과 추정 + 신뢰구간
   └── 비즈니스 함의 추출

각 단계가 다음 단계의 전제. 1 단계 (계획) 가 가장 중요 — Buisson 강조: “실험 실패의 가장 흔한 원인은 부실한 계획.”

직관 — Plan 단계의 무게

비유: 건축의 설계 vs 시공.

• 시공 (실행) 이 더 보이는 작업이지만
• 설계 (계획) 가 건물의 운명 결정

분석가의 흔한 함정: “빨리 실험 시작하자, 결과 봐서 결정하자.”

→ 실험이 끝나도 결과 해석 못함. 다시 계획 단계로 돌아가는 비용.

좋은 분석가의 default: 실험 시작 전 1~2 주 계획에 투자. 실험 중 변경 최소화.

→ Buisson 의 ToC 가 이 계획을 체계화하는 도구.

3 AirCnC 사례 — 1-click Booking 실험

3.1 사례 설정

비즈니스 맥락

AirCnC 경영진이 결정:

“선두 온라인 쇼핑몰처럼 우리도 ‘1-click booking’ 버튼을 만들자. 예약률을 높일 것이다.”

이 단순한 아이디어를 ToC 로 분해:

INTERVENTION:    1-click booking 버튼 (예약 페이지)
BUSINESS GOAL:   더 높은 매출
TARGET METRIC:   예약 완료 확률 (booking probability)
BEHAVIORAL LOGIC: 예약 프로세스 시간 단축으로 인한 이탈률 감소

이 ToC 가 분석가의 작업 시작점.

직관 — “Intervention” 이라는 단어의 함정

Buisson 의 anecdote:

“한 번은 비즈니스 파트너에게 ‘개입 (intervention)’ 이 필요하다고 했다. 파트너는 ‘내 일이 잘못되었다는 의미인가? 왜 개입한다고?’ 라며 분노.”

용어의 정치학:

• “Intervention” = 통계 용어 (control vs treatment 의 구분)
• 비즈니스 청자에게는 “교정” 의 의미로 들림 → 부정적 반응

권장:

• 실험 일반 논의 → “intervention”, “treatment”, “control”
• 특정 실험 의사소통 → 구체적 용어 (“새 버튼”, “기존 디자인”)

→ 분석가가 청자에 따라 언어 조정. 같은 개념을 다르게 표현.

4 4 구성 요소 — 자세히

4.1 1. Business Goal (비즈니스 목표)

정의

회사의 궁극적 목적. 실험의 존재 이유.

수준의 선택:

• 너무 일반적: “이익 증가” — 측정 어려움, 합의 어려움
• 너무 구체적: “이번 분기 ROI 12.5% 정확” — 유연성 없음
• 적절: “매출 증가”, “비용 감소”, “고객 retention”, “전환율 상승” — 명확하면서 측정 가능

AirCnC 사례: “더 높은 매출”.

이 한 단어가 분석가와 비즈니스 파트너 간 합의의 시작점.

직관 — Business Goal 명시가 합의를 드러내는 이유

흔한 시나리오:

• 마케팅: “비용 줄이고 싶다”
• 제품: “매출 늘리고 싶다”
• 운영: “고객 만족도 늘리고 싶다”

세 부서가 같은 실험에 대해 다른 goal 가정. ToC 명시 안 하면 결과 해석에서 충돌:

• 마케팅: “비용 안 줄어서 실패”
• 제품: “매출 늘었으니 성공”
• 운영: “만족도 변화 없어서 무관”

→ 실험 결과가 모두에게 다른 의미. 의사결정 마비.

해결: ToC 의 Business Goal 칸을 1 단어로 명시. “이 실험은 매출 증가만 본다.” 다른 부서가 동의하지 않으면 실험 시작 전 합의.

→ 작업의 1 단어 합의가 1 달의 분쟁을 막는다.

4.2 2. Target Metric (목표 지표)

정의

Business Goal 을 정량화하는 측정 가능한 변수.

Trade-off:

• 이익에 가까운 metric — 비즈니스 의미 명확, 그러나 noise 큼 (다른 변수의 영향)
• 개입에 가까운 metric — Noise 작음, 그러나 비즈니스 의미 약할 수도

해결: Leading Indicator (선행 지표).

예:

• LTV (3 년) 대신 3 개월 booking amount
• 사용량 대신 sign-up
• 만족도 대신 NPS
• 매출 대신 booking probability

AirCnC: “예약 완료 확률” (booking probability).

직관 — 왜 Booking Probability 인가, Booking Amount 가 아닌가?

분석가의 logic:

• 1-click 버튼이 결제 절차 단축 → 이탈 감소 → 예약 완료 ↑
• 그러나 1-click 버튼이 결제 금액 을 바꿀 이유는 없음
• 따라서 Booking Amount 는 noise 만 추가하고 신호 추가 안 함

수학적으로:

\[\text{Revenue} = \text{Booking Probability} \times \text{Average Amount}\]

만약 1-click 의 효과가 Booking Probability 에만 있다면, Revenue 를 target 으로 쓰면 Average Amount 의 noise 가 들어옴 → 효과 검출 어려움.

→ Target Metric 을 noise 가 작은 직접 metric 으로 지정. 더 적은 표본으로 효과 검출 가능.

Target Metric 의 함정

4.2.1 함정 1: 측정 불가 Metric

WRONG: “1-click 버튼은 예약 경험을 더 쉽게 만든다.”

문제: “쉽다” 어떻게 측정?

• 제품 매니저의 사후 판단? — 측정 아님
• 고객 인터뷰? — 표본 작음, 주관적

CORRECT: “예약 완료 후 2 문항 설문에서 ‘쉬움 평가’ ≥ 4 (1~5 점).”

명확한 측정 절차 + 임계값.

4.2.2 함정 2: Laundry List 함정

WRONG: “성공 = 예약률 OR 예약 금액 OR 만족도 OR NPS 향상.”

문제: 4 개 metric 중 1 개라도 통계적 유의 → false positive 위험 (multiple testing).

CORRECT: 1~3 개 metric 사전 명시 + Bonferroni 보정.

4.2.3 함정 3: 사후 결정

WRONG: 결과 보고 metric 선택. “예약률 변화 없지만 세션 시간 늘어남 → 성공.”

문제: P-hacking, false discovery.

CORRECT: 실험 시작 전 metric 등록 (preregistration).

→ 임상 시험의 preregistration 표준이 비즈니스 분석에도 적용.

직관 — OEC 의 양면성

OEC (Overall Evaluation Criterion) — 여러 metric 의 가중 평균.

장점:

• 단일 숫자로 의사결정
• Trade-off 명시 (예: 매출 70% + 만족도 30%)

단점 (Buisson 의 우려):

• “가중치 = 0.7” 같은 숫자에 합의 어려움
• 결과 해석 불투명 (“OEC 가 0.5 늘었다 → 무슨 의미?”)
• ToC 의 메커니즘 분석 어려움

대안:

• 1~3 개 metric 명시
• 각 metric 의 효과 별도 보고
• 비즈니스 파트너가 종합 판단

비즈니스 분석에서 OEC 는 큰 회사 (Microsoft, Google) 가 선호. 작은 팀에서는 1~3 metric 가 일반적.

4.3 3. Intervention (개입)

정의

실험에서 변경되는 것 — Treatment.

질문:

• 무엇을 바꾸는가?
• 어떻게 구현되는가?

AirCnC 사례:

• “1-click booking 버튼 추가”

그러나 단순한 한 줄 뒤에 많은 결정:

• 버튼 위치 (페이지 어디에)
• 버튼 색깔 (기존 색 vs 강조 색)
• 버튼 텍스트 (“1-click 예약” vs “바로 예약”)
• 사용 가능 조건 (어떤 고객이 사용 가능?)
• 클릭 후 동작 (다음 페이지? 추가 액션?)

A/B Test 의 한계 — Buisson 의 경고

함정: 1-click 버튼이 빨간색 (다른 버튼은 파스텔). 매출 증가.

해석 후보:

1. 1-click 의 효과
2. 빨간색 (눈에 띔) 의 효과
3. 둘 다

실험으로 분리 불가능 — 두 변경이 한꺼번에.

이게 A/B Test 의 본질적 한계: 실험은 implementation 도 함께 테스트.

권장:

“가장 작은 intervention 을 테스트하라.”

먼저:

1. 색깔만 변경 (intervention A)
2. 위치만 변경 (intervention B)
3. 1-click 변경 (intervention C)

각각의 효과 분리 후 통합.

또는 동시에 여러 1-click 디자인 (4 개) 비교 → 디자인 선택 효과 측정.

직관 — Omnibus Test 의 위험

비즈니스 파트너의 흔한 요청:

“이번에 색깔, 위치, 텍스트, 1-click 모두 바꾸자. 빨리 결과 봐.”

Omnibus test (한꺼번에 변경) 의 결과:

• 효과 있으면 어떤 변경 때문인지 모름
• 효과 없으면 어떤 변경이 부정적인지 모름
• 다음 실험을 어떻게 설계할지 모름

분석가의 대응:

• 합의: “이번 omnibus 는 ‘breakage 없음’ 만 확인. 효과 측정 아님.”
• 또는: 변경을 분리 + 순차 실험 권장

이 단호함이 분석의 가치 보호.

4.4 4. Behavioral Logic (행동 논리)

정의

Intervention 이 Target Metric 에 미치는 메커니즘. CD 의 화살표.

AirCnC 사례:

1-click 버튼
    ↓
예약 프로세스 시간 단축 (mediator)
    ↓
이탈률 감소
    ↓
예약 완료 (Y/N) — Target Metric
    ↓
매출 — Business Goal

각 화살표가 가설. 실험 결과로 검증·반증.

직관 — 왜 Logic 이 필수인가

분석가가 Logic 명시하면:

1. 사전 검증 가능:
   • “예약 시작-완료 사이에 진짜 이탈 많은가?” — 데이터로 점검
   • 이탈 적으면 가설 자체가 틀림 → 실험 의미 없음
   • 빠른 검증으로 6 개월 실험 비용 절약
2. 결과 해석 풍부:
   • 예약률 ↑ + 시간 ↓ → 가설 일치 (메커니즘 작동)
   • 예약률 ↑ + 시간 변화 없음 → 다른 메커니즘 (재해석)
   • 예약률 변화 없음 + 시간 ↓ → 메커니즘은 작동하나 효과 미미 (다른 단계 점검)
3. 다음 실험 가이드:
   • 어디가 약한 고리인지 파악
   • 후속 실험 설계

직관 — Einstein 의 격언

“한 시간 안에 문제를 풀어야 한다면, 55 분은 문제를 생각하고 5 분은 해결책을 생각한다.”

— Albert Einstein (자주 인용)

비즈니스 실험에 적용:

• 55 분: ToC 명시, behavioral logic 검증, intervention 구체화
• 5 분: 통계 도구 적용

대부분의 실패한 실험: 5 분에 문제, 55 분에 통계.

→ ToC framework 가 55 분의 사고 도구.

4.5 Behavioral Logic 의 사전 검증

Pre-experiment 점검

ToC 의 화살표가 진짜인지 사전 검증:

1-click 버튼
    ↓ (가설 1: 시간 단축?)
예약 프로세스 시간 단축
    ↓ (가설 2: 시간 단축 → 이탈 감소?)
이탈률 감소
    ↓ (가설 3: 이탈 감소 → 예약 완료 ↑?)
예약 완료

각 가설의 사전 검증:

가설	검증 방법	데이터
가설 1	1-click prototype 의 시간 측정 (UX 테스트)	10 명의 stopwatch 데이터
가설 2	기존 데이터에서 시간 vs 이탈률 회귀	과거 6 개월 booking 시간 + 이탈
가설 3	이탈률과 예약 완료의 관계	동일

만약 가설 1 이 reject (시간 단축 안 됨) → 실험 자체가 무의미. 6 개월 실험 비용 절약.

직관 — UX 테스트의 효율

10 명 UX 테스트 (50 만원 + 1 주): - 시간 단축 가설 검증

A/B 테스트 (수억 원 + 6 개월): - 시간 단축 + 이탈 감소 + 예약 완료 모두 검증

순서: UX → A/B Test 가 효율적.

→ 비싼 실험 전에 싼 사전 검증.

4.6 기대 효과 추정

Best Case Scenario

ToC 의 효과 정량화:

• “현재 예약 시작자의 X% 가 시간 때문에 이탈”
• “1-click 으로 모든 시간 이탈자가 완료” (best case)
• 예약률 ↑ = X%

X 의 추정:

• 데이터 분석 (이탈 패턴)
• UX 인터뷰
• 도메인 직관

X = 30% 이고 구현 비용 1 억이라면:

• 30% 예약률 증가 가치 vs 1 억 비교
• 1 억 회수 못 하면 실험 자체 안 함

→ Best case 가 손익분기 안 넘으면 실험 안 함. 시간 절약.

직관 — Most Likely vs Best Case

Best case 는 “모든 가설이 100% 맞을 때”. 현실은 그보다 작은 효과.

Most Likely scenario:

• “30% 의 50% 가 1-click 으로 회복” → 15% 예약률 ↑

이 추정이 Sample Size 결정의 입력 (다음 단계).

분석가의 절차:

1. Best case 점검: 손익분기 넘는가? Yes → 진행
2. Most likely 추정: 정확한 효과 가정
3. Sample size 결정: most likely 효과 검출에 충분한 표본
4. 실험 실행 + 분석

→ Best case 와 Most likely 모두 ToC 의 사전 분석 산출물.

5 Random Assignment — 배정

5.1 Timing 결정

언제 배정?

AirCnC 의 두 가지 timing 후보:

A. 첫 페이지 도착 시 배정
B. 예약 페이지 도착 시 배정 (1-click 이 보이는 시점)

A 의 문제:

• 많은 방문자가 예약 페이지 도달 안 함 → 실험 표본의 일부만 진짜 효과 노출
• 실험 효율 낮음 (큰 표본 필요)

B 의 장점:

• 모든 배정자가 1-click 노출 가능
• 실험 효율 높음

→ Buisson 권장: Treatment 에 노출되는 사람만 배정.

원칙: “Production 에서 누가 treatment 를 받게 되나” 와 같게.

직관 — Treatment 가 production 에서 어떻게 작동하는가

상상: 1-click 버튼이 출시 후 production 에 들어감.

• 첫 페이지 방문자 모두 노출? — No, 예약 페이지 가는 사람만 노출
• 따라서 실험에서도 같음: 예약 페이지 도착자만 배정

이 일치가 실험의 외적 타당도 확보.

만약 다른 timing 으로 실험하면:

• 실험 결과: “1-click 효과 = X%”
• Production: “예약 페이지 도착자에게만 적용 → 효과 = ?”
• X% 가 production 효과와 다를 가능성

→ Timing 의 일관성 = 실험 결과의 production 외삽 가능성.

5.2 Level 결정

누구 단위로 배정?

AirCnC 의 후보:

Level	의미	장단점
Visit	방문 1 회마다 새 배정	표본 큼, 노출 일관성 ↓ (한 사람이 control + treatment)
Booking	예약 1 건마다	중간
Customer Account	한 계정에 한 배정 (영구)	표본 작음, 노출 일관성 ↑
Person	가족 계정 분리	가장 정밀, 데이터 어려움

Buisson 권장: 사람에 가장 가까운 level.

이유: 인간은 기억 있음. 한 사람이 1-click 본 후 다음 방문에 안 보이면 혼란.

직관 — Level 의 비즈니스 함의

Customer level 배정의 의미:

• 한 고객은 실험 기간 내내 같은 그룹
• 일관된 경험 → 명확한 노출
• Cookie 또는 user ID 로 추적

Visit level 배정의 의미:

• 한 고객이 첫 방문 control, 두 번째 treatment
• 혼란스러운 경험 → 효과 측정 흐림
• 통계적 가정 (독립성) 위반 가능

→ Customer level 이 default. 단, 한 명이 여러 방문 하면 sample size 가 visit-level 보다 작아짐 (다음 단계 고려).

5.3 A/A Test 검증

직관 — 시스템 점검

Random assignment 시스템이 정말 무작위인가?

A/A Test:

• 두 그룹에 같은 (control) 버전 노출
• 두 그룹의 metric 차이 통계 검정
• 차이 없으면 → 시스템 OK
• 차이 있으면 → 시스템 버그 (assignment, logging 등)

이 사전 검증이 실험 전체의 신뢰성 확보. Microsoft, Booking.com 등의 실험 platform 표준.

6 Sample Size — 도입

6.1 Power Analysis 의 입력

4 가지 입력

표본 크기 계산에 필요:

1. MDE (Minimum Detectable Effect): 검출하고 싶은 최소 효과
2. Baseline rate: 현재 metric 의 평균
3. Alpha (α): false positive 비율 (보통 0.05)
4. Power (1-β): 진짜 효과를 검출할 확률 (보통 0.8)

이 4 가지로 표본 크기 산출 (자세한 절차는 E-BUI8-3).

직관 — MDE 의 비즈니스 의미

MDE = “이 정도 효과를 검출 못 하면 비즈니스적으로 의미 없다.”

AirCnC 사례:

• Best case: 예약률 + 30%
• Most likely: + 15%
• 손익분기: + 5%

MDE = 5% 또는 더 보수적 (3%).

MDE 작을수록 표본 크게 필요. Trade-off:

• MDE = 5% → 1 만 명 표본
• MDE = 3% → 3 만 명 표본
• MDE = 1% → 25 만 명 표본

→ MDE 결정이 표본 크기의 가장 큰 결정 요인.

6.2 ToC 가 Sample Size 에 미치는 영향

직관 — Behavioral Logic 이 표본 크기 줄임

ToC 의 Logic 이 Target Metric 을 noise 작은 metric 으로 지정 → 표본 크기 감소.

예 1: Target = Revenue (금액)

• Noise 큼 (개별 booking 금액 분산 큼)
• 큰 표본 필요 (10 만 명)

예 2: Target = Booking Probability (이진)

• Noise 작음 (개별 변동 작음)
• 작은 표본 (1 만 명)

같은 효과 검출에 10 배 차이.

→ ToC 의 Behavioral Logic + Target Metric 결정이 실험 비용을 결정.

7 분석 — 마지막 단계

단순 비교

배정 + 실험 후 분석:

• Control 그룹의 metric: \(\hat{p}_C\)
• Treatment 그룹의 metric: \(\hat{p}_T\)
• 효과: \(\hat{p}_T - \hat{p}_C\)
• 통계적 유의성: t-test, z-test, 또는 Bootstrap CI

AirCnC 의 가상 결과:

• \(\hat{p}_C = 25\%\)
• \(\hat{p}_T = 27\%\)
• 효과 = +2%p (또는 +8% relative)
• 95% CI: [+1%p, +3%p]
• p-value < 0.001

직관 — 결과의 ToC 통합 해석

단순 보고: “1-click 이 예약률 +2%p 증가 (p < 0.001).”

ToC 통합 보고:

“ToC 의 가설 (1-click → 시간 단축 → 예약 완료 ↑) 이 검증됨. Booking probability +2%p 증가, 95% CI [+1%p, +3%p]. Best case (+30%) 의 약 1/15 수준이지만, MDE (+5%p) 보다 큰 효과로 비즈니스적으로 의미 있음. Mediator (시간) 도 -3 분 감소 확인 → 메커니즘 일치. Production 적용 권장.”

ToC 가 결과 보고의 framework 제공.

8 응용 — 다른 비즈니스 실험

8.1 SaaS Onboarding 실험

ToC

분석 질문: “튜토리얼 추가가 retention 을 높이는가?”

INTERVENTION:    가입 후 5 분 튜토리얼 추가
BUSINESS GOAL:   고객 retention (LTV)
TARGET METRIC:   30 일 활성 사용자율
BEHAVIORAL LOGIC: 핵심 기능 학습 → 첫 가치 경험 → 지속 사용

CD:

튜토리얼 ──→ 기능 학습 ──→ 첫 가치 경험 ──→ 30일 활성
                                              ↓
                                         LTV

Random assignment: customer 단위 (cookie ID).

8.2 이메일 캠페인 실험

ToC

분석 질문: “맞춤형 이메일이 구매를 늘리는가?”

INTERVENTION:    개인화된 추천 이메일 (vs 일반 뉴스레터)
BUSINESS GOAL:   매출
TARGET METRIC:   이메일 후 7 일 내 구매율
BEHAVIORAL LOGIC: 관련성 있는 추천 → 클릭 → 구매

Pitfall 경계: “이메일 열람률” 만 측정하면 비즈니스 의미 부족 (열람 ≠ 구매).

9 코드 예시 — Python 으로 ToC 와 실험

9.1 ToC 명시 클래스

from dataclasses import dataclass
from typing import Optional


@dataclass
class TheoryOfChange:
    """Buisson 의 ToC framework Python 구현."""
    intervention: str
    business_goal: str
    target_metric: str
    behavioral_logic: str
    mde: float  # Minimum Detectable Effect
    baseline: float  # Current metric value
    expected_effect: Optional[float] = None  # Most likely effect

    def to_sentence(self) -> str:
        """ToC 를 한 문장으로 표현."""
        return (
            f"Implementing [{self.intervention}] "
            f"will help us achieve [{self.business_goal}], "
            f"as measured by [{self.target_metric}], "
            f"through [{self.behavioral_logic}]."
        )

    def to_cd(self) -> str:
        """CD 표현 (텍스트)."""
        return (
            f"{self.intervention} "
            f"──→ {self.behavioral_logic} "
            f"──→ {self.target_metric} "
            f"──→ {self.business_goal}"
        )


# AirCnC 사례
aircnc_toc = TheoryOfChange(
    intervention="1-click booking 버튼",
    business_goal="더 높은 매출",
    target_metric="예약 완료 확률",
    behavioral_logic="예약 프로세스 시간 단축 → 이탈률 감소",
    mde=0.02,  # 2% 절대 차이
    baseline=0.25,  # 현재 예약률 25%
    expected_effect=0.04,  # 예상 효과 4%p
)

print("=== ToC 한 문장 ===")
print(aircnc_toc.to_sentence())
print("\n=== CD 표현 ===")
print(aircnc_toc.to_cd())

직관 — ToC 의 코드 표현

이 데이터 클래스가 분석가에게 주는 것:

• 실험마다 ToC 명시 강제
• 빠진 component (예: behavioral_logic) 자동 감지
• 분석 보고서 자동 생성 (to_sentence)

→ ToC 가 단순 문서가 아닌 실험 분석의 첫 입력.

9.2 Random Assignment 시뮬레이션

import numpy as np
import pandas as pd

def random_assignment(customer_ids, treatment_prob=0.5, seed=42):
    """Customer 단위 무작위 배정."""
    np.random.seed(seed)
    n = len(customer_ids)
    assignments = np.random.uniform(0, 1, n) < treatment_prob
    return pd.DataFrame({
        "customer_id": customer_ids,
        "group": np.where(assignments, "treatment", "control"),
    })


# 1000 명 고객
customers = pd.DataFrame({
    "customer_id": range(1000),
    "age": np.random.normal(40, 12, 1000).clip(18, 80),
    "tenure": np.random.exponential(2, 1000).clip(0, 20),
})

# 배정
assigned = random_assignment(customers["customer_id"])

# 배정 점검 (A/A 같은 효과)
combined = customers.merge(assigned, on="customer_id")
print("=== 배정 비율 ===")
print(combined["group"].value_counts())

# 두 그룹의 baseline 특성 비교 (A/A 검증)
print("\n=== 그룹별 baseline ===")
print(combined.groupby("group")[["age", "tenure"]].mean())

직관 — A/A 검증의 자동화

배정 직후 점검:

• 두 그룹의 baseline 특성 (age, tenure) 비슷한가?
• 비슷하면 → 무작위 배정 OK
• 다르면 → 시스템 점검 (random seed 문제? sampling bias?)

이 자동 점검이 실험 시스템 신뢰성의 첫 보장.

9.3 시뮬레이션 — 실험 결과 분석

def simulate_experiment(toc: TheoryOfChange, n_per_group=5000, true_effect=None,
                        seed=42):
    """ToC 기반 실험 시뮬레이션."""
    if true_effect is None:
        true_effect = toc.expected_effect

    np.random.seed(seed)

    # Control: baseline rate
    control_outcomes = np.random.binomial(1, toc.baseline, n_per_group)

    # Treatment: baseline + true_effect
    treatment_outcomes = np.random.binomial(1, toc.baseline + true_effect, n_per_group)

    # 분석
    p_C = control_outcomes.mean()
    p_T = treatment_outcomes.mean()
    diff = p_T - p_C

    # 표준 오차 (이항 분포)
    se = np.sqrt(p_C * (1 - p_C) / n_per_group + p_T * (1 - p_T) / n_per_group)
    z = diff / se
    from scipy.stats import norm
    p_value = 2 * (1 - norm.cdf(abs(z)))

    return {
        "p_control": p_C,
        "p_treatment": p_T,
        "diff": diff,
        "se": se,
        "z": z,
        "p_value": p_value,
        "ci_lo": diff - 1.96 * se,
        "ci_hi": diff + 1.96 * se,
    }


# AirCnC 실험
result = simulate_experiment(aircnc_toc, n_per_group=5000)
print("=== 실험 결과 ===")
print(f"  Control 예약률: {result['p_control']:.3f}")
print(f"  Treatment 예약률: {result['p_treatment']:.3f}")
print(f"  차이: {result['diff']:.3f} (95% CI: [{result['ci_lo']:.3f}, {result['ci_hi']:.3f}])")
print(f"  p-value: {result['p_value']:.6f}")

# ToC 통합 해석
if result["diff"] > aircnc_toc.mde:
    print(f"\n→ MDE ({aircnc_toc.mde:.3f}) 초과 효과 검출. Production 권장.")
else:
    print(f"\n→ MDE ({aircnc_toc.mde:.3f}) 미만 효과. 비즈니스 의미 약.")

직관 — 시뮬레이션의 가치

이 시뮬레이션이 분석가에게 주는 것:

• 실험 시작 전 결과 예상
• MDE vs 실제 효과 비교
• Sample size 적정성 점검 (충분히 narrow CI?)
• 비즈니스 의사결정 시뮬레이션

비즈니스 파트너에게:

“Most likely scenario (4%p 효과) 에서 5000 명/그룹으로 실험 시 95% CI 가 [3%p, 5%p]. MDE 2%p 보다 충분히 큰 효과.”

이 사전 시뮬레이션이 실험 설계 의사결정 도구.

10 ToC 의 자기 검증 체크리스트

분석가의 사전 점검

ToC 가 잘 만들어졌는지 자체 점검:

• Business Goal 이 한 단어로 명확 (매출/비용/retention 등)
• Target Metric 이 측정 가능 + 사전 등록
• Intervention 이 가능한 작은 단위 (omnibus 회피)
• Behavioral Logic 이 CD 화살표로 표현 가능
• 각 화살표가 사전 검증 가능 (UX 테스트, 과거 데이터)
• Best Case 가 손익분기 초과
• Most Likely 가 MDE 초과
• Random Assignment 의 timing + level 결정
• Sample Size 산출 가능

체크 9 항목 중 1 개라도 빠지면 실험 설계 보강.

11 관련 주제

11.1 Ch.8 의 형제 글

• E-BUI8-1 변화 이론과 목표 지표 — 단계 1 자세히
• E-BUI8-2 무작위 배정 시점·수준 — 단계 2 자세히
• E-BUI8-3 검정력 분석 (부트스트랩) — 단계 3 자세히

11.2 이전 챕터

• E-BUI4-3 데이터 검증과 반복 정제 — Ch.4: CD 짓기
• E-BUI5-2 백도어 기준과 M-패턴 — Ch.5: Confounding 제거

11.3 후속 챕터

• E-BUI9-0 층화 무작위 배정 overview — Ch.9: 층화 배정
• E-BUI10-0 군집 무작위 배정 overview — Ch.10: 군집 배정

11.4 Phase F (Kohavi A/B Testing) cross-link

• Phase F — Trustworthy A/B Testing 정통

11.5 카테고리 진입점

• Experimentation 학습 로드맵 — 11 Phase × 7 교재 매핑