프로세스와 Build vs Buy

체크리스트·실험 리뷰·지적 정직성 + 자체 구축 vs 외부 솔루션 의사결정

Kohavi (2020) Ch.4.3~4.4 를 다룬다. 실험 성숙도가 올라갈 때 필요한 just-in-time 교육 (체크리스트·리뷰 미팅), 학습 공유 채널, 지적 정직성 4 가지 메커니즘을 정리한다. 이어서 외부 솔루션 vs 자체 구축의 의사결정을 9 가지 평가 항목·궤적·통합 요건의 함수로 정리한다.

Experimentation
A/B Test
Platform
저자

Kwangmin Kim

공개

2026년 05월 08일

1 정의

정의: 실험 프로세스와 플랫폼 의사결정

프로세스 (Process) — 실험 설계·실행·해석·학습 공유에 표준 절차를 부여하는 사회적 인프라. just-in-time 교육 (체크리스트·리뷰 미팅), 학습 공유 채널 (newsletter·institutional memory), 지적 정직성 강제 (다지표 가시성·자동 차단) 으로 구성된다.

Build vs Buy — 실험 플랫폼을 자체 구축할지 외부 솔루션 (Optimizely, AB Tasty, Adobe Target 등) 을 도입할지의 ROI 의사결정. Walk 단계에서 가장 자주 발생하며, 궤적 (anticipated growth) 과 통합 요건 (integration depth) 의 함수로 결정된다 (Kohavi, Tang, Xu, 2020, Ch.4.3~4.4).

2 개념 및 원리

2.1 Just-in-Time 교육의 원리

저자들은 모든 실험자에게 통계 교육을 강제하는 대신 실험 cycle 중 적절한 시점에 학습을 주입 하는 방식을 권장한다. 이유는 단순하다.

  • 실험 cycle 과 분리된 교육은 사용 시점에 망각 된다
  • 통계 전문가의 1:1 멘토링은 선형 비용 (실험자 수에 비례) 으로 늘어난다 → 확장 불가능
  • 체크리스트·리뷰 미팅은 점진 학습 을 가능하게 한다 — 처음 몇 번은 도움 필요, 이후 독립

이는 SE 의 code review 와 유사한 메커니즘이다. 모든 개발자에게 architecture 강의를 시키는 대신, 실제 PR 에 review 가 붙으면서 자연스럽게 패턴이 전파된다.

2.2 설계 시 체크리스트

Google Search 의 사례 (Kohavi, Tang, Xu, 2020, Ch.4.3).

체크리스트 항목 목적 진입 비용 (실험자)
가설은 무엇인가? 검증 가능한 주장으로 강제 낮음 — 자기 명료화 효과
어느 정도 효과 크기를 감지하려는가? MDE 명시 → 표본 크기 산출 가능 중간 — 비즈니스 임팩트 사고 필요
검정력 (power) 는? β 통제 → false negative 방지 자동화 (link to power calculator)
OEC·가드레일 지표는? 다지표 합의 → cherry-picking 방지 표준 패키지로 제공
무작위 단위는? SUTVA 위반 사전 점검 중간 — 도메인 지식 필요
실험 기간은? weekly seasonality·trigger rate 고려 자동 추정 도구
트리거링 조건은? trigger 율 낮으면 power 손실 (Ch.20) Run 단계 이상에서 필수

체크리스트의 핵심은 답을 강제 하는 것이 아니라 질문을 강제 하는 것이다. 실험자는 체크리스트를 채우면서 자신이 무엇을 모르는지 발견하고, 전문가는 검토 시 잘못된 답을 교정한다.

직관 — “질문이 답보다 중요한” 인지적 메커니즘

체크리스트가 단순 보고서가 아니라 학습 도구가 되는 이유는 자기 진단 효과 (metacognitive prompting) 다. 인간은 자신이 모르는 것을 인식하지 못하는 경향이 강하다 (Dunning-Kruger). 체크리스트는 다음 시퀀스로 이를 깬다.

1. 질문 받음 ("MDE 는?")
   ↓
2. 답하려 시도
   ↓
3. 모른다는 사실을 발견 (이때가 학습의 시작)
   ↓
4. 답을 찾기 위해 표준 도구 (power calculator) 사용
   ↓
5. 다음에는 같은 질문에 즉답 가능

핵심은 3 단계다. 체크리스트가 없으면 1~2 를 건너뛰고 “감으로” 실험을 시작해 4~5 가 영원히 일어나지 않는다. 같은 실수가 반복된다.

또 다른 메커니즘은 표면적 ↔︎ 깊은 사고의 강제 전환이다. “효과 크기 5%” 라고 답하기 위해 실험자는 “5% 가 비즈니스에 무엇을 의미하는가?” 를 생각해야 한다. 이는 통계 전문가 없이도 실험자가 자신의 도메인 지식을 통계적 사고에 결합하도록 유도한다 — 외주 분석으로는 불가능한 학습이다.

2.3 분석 리뷰 미팅

분석 시점의 리뷰는 다음 순서로 진행된다.

1. 신뢰성 검증
   - 계측 누락 / SRM / 트리거 비율 이상
   - 신뢰성 결함 발견 시 결과 해석 보류
        ↓
2. 결과 해석
   - OEC·가드레일·세그먼트별 효과
   - p-value·CI 표준 해석
        ↓
3. 출시·중단 권고
   - 출시 시 어떤 가드레일이 위반되는가?
   - 중단 시 무엇을 학습했는가?
        ↓
4. 메타 학습
   - 유사 실험 패턴 발견 → 지표 정의 업데이트

저자들은 리뷰 미팅이 같은 제품·같은 OEC 를 공유하는 팀들 끼리 진행되어야 한다고 강조한다. 다른 도메인 팀이 섞이면 컨텍스트 부재로 비생산적이 된다 (Kohavi, Tang, Xu, 2020, Ch.4.3).

직관 — 왜 신뢰성 검증을 가장 먼저 보는가

분석 리뷰의 인지적 함정은 결과부터 보고 마음에 들면 신뢰성을 의심하지 않는 비대칭이다. “우리 가설이 맞았다 (p < 0.001)” 를 보면 곧장 출시 결정으로 가고 싶은 충동이 강하다. 이때 SRM 검사를 나중에 하면, 결과에 대한 사전 신념 (motivated reasoning) 이 검증 결과 해석을 오염시킨다.

리뷰 미팅의 첫 단계를 결과 표시 전에 신뢰성 검증 으로 강제하는 것이 이 함정을 막는다. 신뢰성 검증을 통과하면 결과를 보고, 통과하지 못하면 결과는 없는 것으로 처리된다. 이는 단순한 순서가 아니라 인지적 보호 장치 다.

2.4 학습 공유 — 4 채널

학습이 사람·미팅 안에 갇히면 조직 차원의 메타 분석이 불가능하다. 저자들은 4 가지 공유 채널을 권장한다.

  1. Newsletter / Twitter feed — 놀라운 결과 (실패·성공 모두) 를 정기 broadcast
  2. Curated homepage — 핵심 실험·메타 분석 lead 를 큐레이션
  3. Social network on platform — Booking.com 처럼 실험에 대한 토론 댓글 자동 attach
  4. Institutional memory (Ch.8) — 검색 가능한 과거 실험 DB

이 4 채널은 수동 학습 (newsletter) → 능동 학습 (search) 으로 이어지는 점진 모델이다. Crawl·Walk 단계는 newsletter 만으로 충분하고, Run·Fly 단계는 institutional memory 가 필수가 된다.

2.5 지적 정직성 — 4 가지 메커니즘

저자들은 결과보다 학습이 우선 이라는 문화를 강제하는 4 가지 구체 메커니즘을 제시한다 (Kohavi, Tang, Xu, 2020, Ch.4.3).

  1. 다지표 가시성 강제 — OEC·가드레일·관련 지표를 대시보드에 항상 함께 표시. 한 지표만 cherry-pick 해서 공유할 수 없다.
  2. Newsletter 로 놀라운 결과 broadcast — 실패·성공 모두. 학습 공유가 cultural norm 이 되도록.
  3. 부정적 실험 차단 단계화 — warning → notification → block 의 3 단계. 가드레일 위반 시 자동 차단까지 가능하지만, 차단보다 공개 토론 이 더 좋다고 저자는 권고. 차단은 책임 회피 기제로 작동할 수 있다.
  4. 실패 학습 culture — “어떤 가설이 왜 실패했는가” 를 정기 공유. 다음 실험의 설계가 개선된다.

이 4 가지는 모두 결과 cherry-picking 의 비대칭 동기 에 대한 대응이다. 사람은 자신의 가설이 맞았다는 데이터를 우선 노출시키려는 동기가 강하다. 지적 정직성은 이 동기를 의지로 이기는 것이 아니라 시스템으로 강제 해야 지속 가능하다.

3 Build vs Buy — Walk 단계의 핵심 의사결정

Walk 단계는 외부 솔루션으로 시작했던 조직이 자체 구축으로 전환할지 결정하는 시점이다. 저자들은 9 가지 평가 항목 + 비용 + 궤적 + 통합 요건 의 함수로 의사결정을 권장한다.

3.1 9 가지 평가 항목

항목 외부 솔루션이 약한 시그널 Build 가 필요한 가정
실험 유형 JS 기반 → 백엔드 미지원 서버·클라이언트·모바일 모두 필요
사이트 속도 추가 JS 가 페이지 로딩 지연 지연 자체가 핵심 지표 (Ch.5)
지표 자유도 세션화·percentile 미지원 복합 지표 (tail latency, sessionized) 필요
무작위 단위 사용자 식별자 외부 전송 제약 프라이버시 (Ch.9) 강제 + 내부 식별자 사용
데이터 join 외부 데이터 통합 불가 구매·반품·인구통계 join 필요
실시간성 일 단위 결과 NRT 로 bad experiment 분 단위 차단
제도적 기억 미지원 메타 분석·과거 결과 검색 필요
최종 구현 WYSIWYG 임시 구현 실험 코드 = 프로덕션 코드
dual logging 외부·내부 로그 불일치 단일 진실원 (single source of truth) 필요

각 항목은 이진 판단 이 아니라 현재·미래 양쪽 으로 평가한다. 현재 외부 솔루션이 충분해도 1~2 년 안에 한계가 보이면 build 를 미리 시작하는 것이 ROI 가 높다.

가정의 검증 — “성장 궤적은 정말 그만큼인가?”

Build 결정의 가장 흔한 함정은 성장 궤적의 과대 추정이다. 조직이 “내년에 실험 1000 건/년” 을 자신하면서 build 에 1 년을 투자했지만, 실제로는 200 건/년 에 머물면 sunk cost 가 누적된다.

저자들은 현재 momentum 과 demand 의 객관적 신호 를 강조한다. 신호 예시: - 외부 솔루션 한계로 포기한 실험이 분기당 5+ 건 - 지표 자유도 부족으로 임시 분석 스크립트가 누적 - 통합 부족으로 dual logging 부담이 증가

이런 신호 없이 “곧 그렇게 될 것” 이라는 추정만으로 build 를 시작하면 위험하다. 이 가정이 깨지면 — 외부 솔루션 비용보다 자체 구축 + 운영 비용이 훨씬 커지면서 ROI 가 음수가 된다.

3.2 자체 구축 비용

저자들은 자체 구축이 “어렵고 비싸다” 는 점을 명시한다 (Ch.4.3 의 후속 절들이 인프라 4 컴포넌트 + 변종 배정 + 분석을 다룬다 — 모두 자체 구축이 필요한 영역).

비용 항목 외부 솔루션 자체 구축
초기 구현 라이선스 fee + integration 6~12 개월 엔지니어링 (5~10 명)
운영 외부 SLA 24/7 oncall + 모니터링
확장 단계별 라이선스 증액 일정 비용 → marginal 비용 ↓
통합 깊이 API 한계 무제한 (CI/CD·feature flag·로깅)
학습 곡선 짧음 길지만 도메인 전문성 축적

저자들의 권고: Walk 단계에서 외부 솔루션으로 ROI 를 검증하고, 궤적이 명확해진 후 build 결정. 이 sequence 는 “build first” 의 sunk cost 위험과 “buy forever” 의 천장 위험 사이에서 가장 robust 하다.

3.3 통합 요건 — Configuration·Deployment

저자들이 build 의 강한 신호로 강조하는 것은 시스템 configuration·deployment 와의 통합 요건 이다 (Kohavi, Tang, Xu, 2020, Ch.4.3, Ch.15 cross-link).

  • 실험 = 프로덕션 코드의 변종 → CI/CD 와 분리 불가
  • feature flag 시스템과 variant assignment 가 통합되면 ramping (Ch.15) 자동화 가능
  • 외부 솔루션은 일반적으로 이 통합이 약해, 복잡한 디버깅이 필요할 때 한계

이는 외부 솔루션 = 별도 시스템, 자체 구축 = 코어 인프라의 일부 라는 근본 차이다. 조직이 실험을 코어 인프라로 받아들이는 시점이 build 결정의 임계점이 된다.

4 왜 필요한가

4.1 프로세스 부재의 결과

just-in-time 교육·리뷰·지적 정직성 메커니즘이 없으면 다음 함정이 발생한다.

  • Drift in interpretation — 실험자마다 p-value·CI 해석이 달라진다. 한 팀에서 “유의” 라고 부르는 효과 크기가 다른 팀에서는 “무의미” 가 된다.
  • Cherry-picking 일상화 — 한 지표가 +5% 인 결과를 부각하고 다른 지표가 -3% 인 사실을 숨긴다. 대시보드에 가드레일이 항상 보이지 않으면 이 행동이 합리적으로 느껴진다.
  • 반복 작업 누적 — 같은 가설을 여러 팀이 독립적으로 다시 검증한다. 학습 공유 채널 부재의 직접 결과.
  • Walk 단계 정체 — 신뢰 검증·표준 분석이 표준화되지 않으면 Run 단계로 넘어갈 수 없다.

4.2 잘못된 Build 결정의 결과

  • 너무 일찍 build — 1~2 년 엔지니어링 투자 후 실험 빈도가 외부 솔루션 한계 안에 머물면 sunk cost
  • 너무 늦게 build — 외부 솔루션 한계로 포기한 실험이 누적되어 의사결정 품질이 저하 + 경쟁사 대비 학습 격차 누적
  • 하이브리드 함정 — 일부는 외부, 일부는 자체로 운영하면 dual logging 비용 + 결과 불일치 + 분석 코드 중복

저자들의 권고는 진단 → 결정 → 명시적 cutover 순서다. 단계적 마이그레이션은 복잡도를 증가시킨다.

5 응용 사례

5.1 LinkedIn — 점진적 자체 구축

LinkedIn 의 실험 플랫폼 (XLNT) 은 Walk 단계 후반에 자체 구축으로 전환했다 (Xu et al. 2015). 주요 동기 (사전지식 보강).

  • 외부 솔루션은 사용자 식별자 외부 전송 정책과 충돌
  • 복합 지표 (engagement, network value) 가 외부 솔루션의 표준 지표 외부
  • CI/CD 와 통합된 ramping 필요

전환 후 4 년 내 실험 빈도 10 배 성장 (Figure 4.1).

5.2 Microsoft Office — 재활용 빠른 진입

Microsoft Office (2017) 는 Bing 의 실험 플랫폼을 재활용하여 build 비용을 sunk 처리. 첫 해 1000+ 실험, 다음 해 +600% 성장. 이는 같은 회사 내 플랫폼 재활용 이 build vs buy 의 제 3 옵션 임을 보여준다.

5.3 Booking.com — Social Network 통합 실험 플랫폼

Booking.com 은 실험 플랫폼에 social network 기능 (실험 결과에 댓글·토론) 을 통합. 학습 공유의 4 채널 중 가장 active 한 케이스. 이는 외부 솔루션으로는 불가능한 깊이의 통합이다.

6 예시 — Build vs Buy 결정 모델

Walk 단계 조직의 build vs buy 의사결정을 단순화한 NPV 모델.

import numpy as np

# 가정
EXP_PER_YEAR_INITIAL = 50      # 현재 빈도
GROWTH_RATE = 1.6              # 연간 성장 (Walk → Run 가는 궤적)
HORIZON_YEARS = 5
EXTERNAL_LICENSE_PER_YEAR = 200_000   # 외부 솔루션 라이선스
EXTERNAL_LIMIT_EXPERIMENTS = 500      # 외부 솔루션 한계
BUILD_COST_INITIAL = 1_500_000        # 자체 구축 1 년차
BUILD_OPS_PER_YEAR = 500_000          # 운영 비용
VALUE_PER_EXPERIMENT = 10_000         # 실험 1 건 평균 비즈니스 가치

discount = 0.10

def npv(cashflows, r=discount):
    return sum(cf / (1 + r) ** t for t, cf in enumerate(cashflows))

# 시나리오 1: 외부 솔루션 (한계 초과 시 가치 없음)
external_cf = []
for t in range(HORIZON_YEARS):
    n_exp = min(EXP_PER_YEAR_INITIAL * (GROWTH_RATE ** t), EXTERNAL_LIMIT_EXPERIMENTS)
    cf = n_exp * VALUE_PER_EXPERIMENT - EXTERNAL_LICENSE_PER_YEAR
    external_cf.append(cf)

# 시나리오 2: 자체 구축 (한계 없음, 1 년차 build cost)
build_cf = [-BUILD_COST_INITIAL]
for t in range(1, HORIZON_YEARS):
    n_exp = EXP_PER_YEAR_INITIAL * (GROWTH_RATE ** t)
    cf = n_exp * VALUE_PER_EXPERIMENT - BUILD_OPS_PER_YEAR
    build_cf.append(cf)

print(f"External NPV: ${npv(external_cf):,.0f}")
print(f"Build    NPV: ${npv(build_cf):,.0f}")
print(f"Crossover delta: ${npv(build_cf) - npv(external_cf):,.0f}")

예상 결과 (가정 조합 기준).

External NPV: $11,490,000   (Year 4 부터 한계 초과 → 가치 stagnation)
Build    NPV: $14,820,000   (Year 5 까지 무제한 성장)
Crossover delta: $3,330,000

해석: 성장률 1.6 배·5 년 horizon 가정에서 build 가 +$3.3M 우위. 그러나 가정이 깨지면 (성장률 1.2 로 둔화 → 외부 솔루션 한계 5 년 내 미도달) build 의 NPV 가 음수가 될 수 있다. 모델의 결론 보다 가정의 robustness 가 의사결정의 핵심 이다.

직관 — NPV 수식의 의미와 할인율 풀이

NPV 함수의 핵심은 다음 한 줄이다.

\[\text{NPV} = \sum_{t=0}^{T} \frac{CF_t}{(1+r)^t}\]

여기서 \(CF_t\) 는 t 년차 현금흐름, \(r\) 은 할인율 (위 코드에서 0.10 = 10%). 왜 미래 가치를 \((1+r)^t\) 로 나누는가?

세 가지 해석이 가능하다.

  1. 기회 비용 — 같은 돈을 다른 곳 (예: 채권·시장 인덱스) 에 투자하면 연 r% 수익. 미래의 $1 은 현재의 \(1/(1+r)\) 과 동치
  2. 불확실성 할인 — 미래 현금흐름은 불확실하다. 멀수록 더 큰 할인
  3. 소비 선호 — 사람은 미래의 소비보다 현재의 소비를 선호 (시간 선호)

위 모델에서 \(r = 0.10\) 은 1 년차 $1 = 5 년차 $1.61. 즉 5 년 후 $1M 의 가치는 현재 $620K ($1M / 1.61). 이 깎임은 build 1 년차의 비용 ($1.5M) 이 5 년차 가치보다 더 큰 가중치를 가진다는 의미다.

이 메커니즘 때문에 build 의 ROI 는 horizon 길이에 매우 민감 하다. 3 년 horizon 이면 build 가 회수되지 않을 가능성이 크고, 7 년 horizon 이면 거의 항상 우위. 의사결정 시점의 시야가 build vs buy 결정 자체를 재구조화한다.

반사실 시나리오 — 가정이 깨질 때

위 NPV 모델의 결론을 뒤집을 4 가지 시나리오를 보자.

  1. 성장률 1.2 (둔화) — 외부 솔루션 한계 5 년 내 미도달. Build NPV < External NPV.
  2. 할인율 20% (불확실성 큰 시장) — 미래 가치가 빠르게 깎임. Build 회수 어려움.
  3. 외부 솔루션 라이선스 $1M / 년 (high-touch) — Build 가 더 빨리 우위.
  4. Build cost $5M (잘못된 견적) — sunk cost 가 누적되어 Build NPV 음수.

이 4 가지 중 어떤 것도 실제로 일어날 수 있다. 그래서 NPV 단일 숫자가 아니라 민감도 분석 (sensitivity analysis) 으로 의사결정한다 — 가정 1~2 개가 어긋나도 결정이 robust 한가? 이 robustness 가 부족하면 “더 많은 정보 수집” 으로 미루는 것이 옳은 선택이다.

모델의 한계

위 NPV 모델은 다음을 무시한다.

  • 통합 가치 — CI/CD 통합으로 발생하는 디버깅 시간 절감, NRT alerting 으로 발생하는 위험 회피
  • 학습 곡선 — Build 첫 해는 운영 안정화로 실험 빈도 자체가 떨어짐
  • 외부 솔루션 lock-in — 마이그레이션 비용

실제 의사결정은 NPV 만으로 결정하지 말고, 통합 요건의 critical 정도와 외부 솔루션 한계의 명확성을 함께 평가한다.

7 관련 주제

선행 — Ch.4 시리즈

후속 — Ch.4 시리즈

관련 챕터

다른 카테고리 연결

Subscribe

Enjoy this blog? Get notified of new posts by email: