Statsig 입문 6편 — Warehouse Native 깊이 · Snowflake · BigQuery · dbt 결합

이 글은 Statsig 입문에서 운영까지 시리즈 6편이에요. 1편 종합 에서 다뤘던 Cloud vs Warehouse Native 5축 비교가 큰 그림이었다면, 이번 6편은 Warehouse Native (WHN, 자체 웨어하우스 기반 운영 모델) 쪽을 깊이 들여다봐요. 큰 회사, 규제 환경, 기존 dbt (데이터 변환 도구) 를 굴리는 회사가 실전에서 어떻게 쓰는지에 초점.

왜 Warehouse Native 가 필요한가

1편의 Cloud vs WHN 5축 비교 를 다시 정리해볼게요:

여기에 6편에서 한 줄을 더 얹어요 — 데이터가 우리 회사 밖으로 안 나간다.

도입 결정의 결정타 — 세 가지

WHN 을 진짜 필요로 하는 회사는 세 시그널 중 하나라도 강해요:

1. 데이터 규모 — 일 수억 event 이상이면 Cloud 가격 모델이 부담
2. 데이터 통제 — PII (개인 식별 정보) · 매출 · 금융 데이터를 외부 SaaS 에 전송 X
3. 기존 분석 자산 — Snowflake/BigQuery · dbt 모델 · SQL 분석가 팀이 이미 있음

세 시그널이 0개면 Cloud 가 명확히 정답이고, 1개 이상이면 WHN 검토를 시작할 만해요.

Enterprise 필수

여기서 짚어둘 자리 — WHN = Statsig Enterprise plan 필수. Cloud 의 무료 plan 200만 이벤트/월 같은 self-serve 진입은 없어요. 데모, 영업, 계약 절차를 모두 거칩니다.

도입 결정 자체가 작게 시작하는 도구 선택이 아니라 큰 전략 결정에 가까워요.

두 사용 모델 — Full Platform vs Existing Experiments

WHN 도입에는 두 갈래 길이 있어요. 어느 길로 갈지가 첫 번째 큰 결정.

모델 A: Full Platform (전체 플랫폼)

Targeting · 실험 설정 · 할당 및 분석 모두 — Feature Flag · Auto Rollouts · Holdouts 포함. — 공식 docs

Cloud 와 같은 end-to-end 경험을 유지하면서 데이터는 우리 웨어하우스에 둬요. 새 회사가 처음부터 WHN 으로 시작한다면 권장 경로.

[Statsig WHN]
  ├─ Feature Gate UI (3편 기능 모두)
  ├─ Experiment 설계 UI (4편 기능 모두)
  ├─ Statsig SDK → user assignment
  ├─ Statsig 가 무작위화 + assignment 결정
  ├─ assignment data → 우리 웨어하우스 저장
  ├─ event data → 우리 웨어하우스 저장
  └─ 분석 결과 → 우리 웨어하우스 + Statsig UI

Cloud 의 모든 기능을 그대로 쓰면서 데이터 통제권까지 가져가는, 가장 흔한 도입 경로.

모델 B: Existing Experiments (기존 실험 분석만)

타사 또는 내부 시스템의 기존 실험에 대해 전체 실험 측정 도구 (CUPED · 계층화 샘플링 · 스위치백 테스트 등) 제공. — 공식 docs

이미 자체 실험 시스템을 굴리는 경우예요 (예: LaunchDarkly + 자체 분석, 또는 Optimizely + Snowflake). 실험 assignment 는 그대로 두고 분석 layer 만 Statsig 로 바꿔 끼우는 모델.

[기존 시스템]
  ├─ LaunchDarkly · Optimizely · 자체 — assignment 결정
  └─ assignment data → 우리 웨어하우스 저장

[Statsig WHN]
  ├─ 우리 웨어하우스에서 assignment 읽기
  └─ Statsig 의 통계 엔진 (CUPED · Stratified · ...) 으로 분석

분석 도구만 Statsig 로 교체하고 기존 시스템은 대체하지 않아요.

어느 모델 선택?

분석부터 시작해서 검증한 뒤 전체로 넓히는 게 위험 분산 패턴이에요.

4 단계 워크플로 — WHN 도입 흐름

Step 1: 웨어하우스 연결

Statsig 가 우리 웨어하우스에 SQL 쿼리를 실행할 수 있도록 connection 을 설정해요.

필요한 것 — Statsig 가 읽고 쓸 수 있는 사용자 계정 (warehouse 별로 형태 다름).

최소 권한 (예: Snowflake) :

-- 읽기
GRANT USAGE ON DATABASE prod_analytics TO ROLE statsig_role;
GRANT USAGE ON SCHEMA prod_analytics.events TO ROLE statsig_role;
GRANT SELECT ON ALL TABLES IN SCHEMA prod_analytics.events TO ROLE statsig_role;

-- 쓰기 (assignment · 분석 결과 저장용)
GRANT CREATE TABLE ON SCHEMA prod_analytics.statsig TO ROLE statsig_role;
GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA prod_analytics.statsig TO ROLE statsig_role;

-- compute (쿼리 실행)
GRANT USAGE ON WAREHOUSE STATSIG_WH TO ROLE statsig_role;

원칙은 최소 권한 + 별도 schema/database 격리예요. 기존 production 테이블에 사고가 번지지 않도록 차단.

Step 2: 메트릭 정의

입력 데이터 = 어떤 table 의 어떤 column 이 event 인가를 정의해주는 단계.

-- 예: 우리 회사의 event table
CREATE TABLE analytics.events (
    user_id VARCHAR,
    event_name VARCHAR,
    event_timestamp TIMESTAMP,
    properties VARIANT
);

Statsig 에 매핑하면:

Event Table: analytics.events
  user_id column: user_id
  timestamp column: event_timestamp
  event_name column: event_name
  properties column: properties (JSON)

이러면 Statsig 가 우리 event 를 인식해요. 이제 Metric 을 정의:

Metric "Daily Revenue":
  Type: Sum
  Event: purchase
  Value: properties.revenue

5편의 7 Metric Type 모두 정의 가능. Statsig UI 로도, SQL 로도 가능해요.

Step 3: 노출 로깅

Full Platform 모델:

• Statsig SDK 가 checkGate · getExperiment 호출 → assignment 결정
• assignment 가 우리 웨어하우스의 exposure table 에 저장
• 우리 event 와 user_id join 으로 분석

Existing Experiments 모델:

• 우리 기존 시스템의 assignment 데이터를 그대로 두고
• Statsig 가 그 테이블을 읽기만 함

Step 4: 가설 + 분석

4편의 Experiments 깊이 의 모든 기능에 더해 WHN 만의 추가 통계 도구를 쓸 수 있어요.

지원 웨어하우스 — 4 주요 + 패턴

Statsig WHN 이 일반적으로 지원하는 데이터 웨어하우스:

웨어하우스마다 통합 패턴이 조금씩 달라요:

Snowflake

- 별도 warehouse (compute) 권장 — STATSIG_WH 같은 이름
- size = X-Small 또는 Small 시작 (분석 query 크기에 따라)
- auto-suspend = 60초 (idle 시 자동 정지 = 비용 절약)
- multi-cluster = 동시 query 많을 때

BigQuery

- 별도 project 또는 dataset 권장
- on-demand vs reserved slots 비용 모델 선택
- partition + clustering 으로 쿼리 비용 절감
- BigQuery ML 활용 가능

Databricks

- SQL Warehouse 또는 standard cluster
- Delta Lake 의 ACID (트랜잭션 4 속성) 활용
- Unity Catalog 로 권한 통합 관리
- 기존 Spark/ML 모델 결합

Redshift

- 별도 RA3 노드 또는 serverless
- Materialized View 로 자주 쓰는 query 캐싱
- Workload management (WLM) 로 priority
- 기존 AWS 생태계 통합

회사의 기존 웨어하우스를 그대로 써요. 새 인프라를 따로 깔 필요가 없다는 게 핵심.

Table 구조 — Statsig 가 기대하는 schema

Event Table

CREATE TABLE events (
    user_id          VARCHAR        NOT NULL,
    event_name       VARCHAR        NOT NULL,
    event_timestamp  TIMESTAMP      NOT NULL,
    value            DOUBLE,
    properties       VARIANT/JSON   -- Snowflake: VARIANT, BigQuery: JSON
);

핵심 column 은 user_id · event_name · event_timestamp. 5편의 Event 4 구성 (eventName · value · metadata · timestamp) 과 정확히 같은 구조예요.

Exposure Table (Full Platform)

CREATE TABLE statsig_exposures (
    user_id        VARCHAR        NOT NULL,
    experiment_id  VARCHAR        NOT NULL,
    variant_id     VARCHAR        NOT NULL,
    exposed_at     TIMESTAMP      NOT NULL,
    properties     VARIANT/JSON
);

Statsig SDK 가 assignment 시점에 자동 INSERT 해요. 분석 단계에서 event 와 join 할 때 쓰는 키.

User Table (선택)

CREATE TABLE users (
    user_id     VARCHAR        NOT NULL,
    signup_date DATE,
    country     VARCHAR,
    tier        VARCHAR,
    custom_props VARIANT/JSON
);

Targeting 정확도를 올리는 용도. 가입일, tier, country 처럼 비교적 안정된 사용자 속성이에요. event 마다 매번 보낼 필요 없이 user table 에서 join 해 쓰면 돼요.

Metric Table (Statsig 가 생성)

CREATE TABLE statsig_metrics (
    metric_name    VARCHAR,
    user_id        VARCHAR,
    metric_value   DOUBLE,
    metric_date    DATE,
    properties     VARIANT/JSON
);

분석 결과를 사전 집계해서 저장하는 테이블이에요. 같은 query 를 반복할 때 비용이 확 줄어요.

핵심 분석 도구 3종

도구 1: Pulse Analysis — 가설 검증

Pulse Analysis — 가설 검증 및 메트릭 영향도 측정. — 공식 docs

4편 실험 분석의 WHN 버전이에요. control vs treatment 의 primary/secondary metric 을 비교하고 p-value, CI 를 자동으로 계산해줘요. 우리 웨어하우스의 데이터 위에서 직접 실행.

Pulse "button_color_test":
  Date Range: 2026-05-01 ~ 2026-05-14
  Primary Metric: checkout_conversion_rate
  Control: Variant A
  Treatment: Variant B

→ 결과:
  Control:    12.5% (n=50,000)
  Treatment:  13.2% (n=50,012)
  Lift:       +5.6% (95% CI: +1.2%, +9.9%)
  p-value:    0.024 ✓ 유의

도구 2: Metrics Explorer — 인구 분석

5편의 Metrics Explorer 의 WHN 버전이에요. 6 차트를 모두 쓸 수 있고, 우리 웨어하우스의 사용자 데이터를 전부 활용해요.

도구 3: Exposure Analysis — 노출 패턴 분석

Exposure Analysis — 첫 노출 분석 및 실험 상호작용 파악. — 공식 docs

Exposure 는 사용자가 실험에 참여한 시점이에요. 여기서 보는 것들:

• 첫 노출까지 걸린 시간 — 가입 후 며칠 만에 실험에 진입했는지
• 실험 간 상호작용 — 두 실험에 동시 노출된 사용자 비율
• Sample Ratio Mismatch (4편 SRM, 그룹 비율 불일치) 정밀 검사
• exposure drift — 시간이 흐르면서 group 비율이 어떻게 변하는지

실험 신뢰성을 검증하는 핵심 도구.

고급 통계 기법 — WHN 특화

WHN 의 진짜 차별은 고급 통계 기법이에요. 일반 Cloud 에서도 일부 제공하지만 WHN 에서 가장 풍부하게 쓸 수 있어요.

CUPED — 분산 감소

CUPED (Controlled-experiment Using Pre-Experiment Data) = 실험 전 데이터로 분산을 감소시켜서 같은 sample 로도 통계 power 를 30~50% 끌어올리는 기법.

비유로 보면 — 시험 결과를 비교할 때 입학 성적까지 같이 보면 진짜 학습 효과가 더 잘 보이는 것과 같아요.

작동:

일반 분석:
  Treatment - Control = +0.5% (p=0.08, 비유의)

CUPED 적용 (실험 전 7일 데이터 활용):
  Treatment - Control = +0.5% (p=0.02, 유의)

같은 효과 크기지만 분산이 줄어 p-value 가 작아져요. 효과가 작거나 기간이 짧아도 detect 가 가능해지는 거예요.

Stratified Sampling — 계층 무작위화

Stratified Sampling = 사용자를 sub-group 으로 나눈 다음 각 group 안에서 무작위 분할하는 방식.

비유 — 그냥 50/50 무작위 분할과 남자 50/50 + 여자 50/50 분할의 차이. 후자가 gender balanced 를 보장해줘요.

왜 필요한가:

• VIP 사용자가 한쪽 variant 로 몰리면 결과가 왜곡됨
• 국가별 분포 불균등
• 디바이스별 차이

Stratified 를 쓰면 각 segment 안에서 정확히 50/50 이 맞춰져서 분포 불균형이 사라져요.

Switchback Testing — 시간 단위 무작위화

Switchback Test = 전체 사용자를 시간 단위로 교대시키는 실험. user 단위 무작위화가 어려운 상황에서 써요.

대표 사용 case:

• 모든 사용자에게 같은 가격을 노출해야 할 때 — user 단위로 다른 가격은 X
• Two-sided marketplace — driver/rider 모두 같은 algorithm 사용 필요
• 네트워크 효과가 있는 기능

작동:

2026-05-01 09:00 ~ 12:00 → 모든 사용자 Variant A
2026-05-01 12:00 ~ 15:00 → 모든 사용자 Variant B
2026-05-01 15:00 ~ 18:00 → 모든 사용자 Variant A
2026-05-01 18:00 ~ 21:00 → 모든 사용자 Variant B
...

→ 시간 단위 randomization
→ 시간별 metric 비교

Uber, DoorDash 같은 marketplace 의 표준 기법이에요.

기타 advanced 기법

• CUPAC — CUPED 의 일반화 (covariate adjustment)
• Sequential Testing (4편 peeking 해결)
• Hierarchical Bayesian — group 별로 다른 효과 추정
• Quantile Test — median, P90 같은 분위수 효과

통계학 박사 수준의 도구를 클릭 한 번으로 굴린다는 점, WHN 의 가장 강력한 차별점이에요.

Cost Management — 비용 절약

WHN 의 가장 큰 운영 고민은 웨어하우스 cost.

비용 발생 원인

1. Compute time — Statsig 가 실행하는 SQL 쿼리 시간
2. Data scan — 큰 table 스캔 시 데이터 양 (BigQuery on-demand)
3. Storage — Statsig 가 생성한 metric/exposure table
4. Concurrent queries — 동시 query 폭증

절약 방법 — 7 권장

1. Partition + Cluster — Snowflake clustering, BigQuery partitioning + clustering, Redshift sort keys. 자주 쓰는 date, user_id, event_name 으로 나누면 스캔 데이터가 확 줄어요.

-- BigQuery
CREATE TABLE events (...)
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id, event_name;

2. Materialized View — 자주 쓰는 집계 결과를 미리 계산해둬요.

-- Snowflake
CREATE MATERIALIZED VIEW daily_user_metrics AS
SELECT
    user_id,
    DATE(event_timestamp) as date,
    COUNT(*) as event_count,
    SUM(CASE WHEN event_name = 'purchase' THEN 1 ELSE 0 END) as purchase_count
FROM events
GROUP BY 1, 2;

3. 별도 warehouse · auto-suspend — Statsig 전용 compute pool 을 두고 idle 60초 후 자동 정지.

4. 분석 데이터만 retain — raw event 90일 + aggregated 영구 패턴. 오래된 raw 는 자동 삭제.

5. 쿼리 monitoring — 가장 비싼 쿼리를 골라 최적화해요.

-- Snowflake: 비싼 쿼리
SELECT query_text, total_elapsed_time, credits_used_cloud_services
FROM SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORY
WHERE start_time > DATEADD(day, -7, CURRENT_TIMESTAMP())
ORDER BY credits_used_cloud_services DESC
LIMIT 20;

6. Concurrency 제한 — Statsig 의 동시 쿼리 수에 cap 을 둬요.

7. Sample data — 분석 단계에서 10% sample 로 빠르게 prototype 한 뒤, 최종만 100% 로 돌려요.

비용 예시 (대략)

(웨어하우스 cost 만, Statsig license 별도)

Cloud 무료 plan 의 200만 event/월 무료와 비교하면 작은 회사는 Cloud 가 압도적이에요. 대규모이면서 통제까지 필요한 경우가 WHN 의 자리.

데이터 통제권 — WHN 의 진짜 가치

GDPR · KISA · 금융 규제

문제 — Cloud SaaS 는 사용자 데이터 (이메일, IP, 행동) 를 외부로 전송해요. 규제 환경별로 보면:

• GDPR (유럽) — 사용자 명시 동의 + 데이터 처리 위탁 계약
• KISA · 개인정보보호법 (한국) — 국외 이전 제한
• PCI DSS (결제) — 카드 정보 외부 전송 X
• HIPAA (의료, 미국) — 의료 데이터 통제
• FedRAMP (정부) — 클라우드 인증

WHN 은 데이터가 우리 웨어하우스 안에 머물고, Statsig 는 메타데이터와 분석 결과만 받아요. 규제 환경에서 compliance 작업이 훨씬 단순해져요.

Privacy 안전 패턴

1. PII column → user 테이블에 별도 schema, Statsig 권한 X
2. event 테이블 = pseudonymized user_id 만 (이메일 · 실명 X)
3. private attributes (3편) → 절대 외부 안 보냄
4. retention policy → 자동 삭제 by 가입일/이벤트일

WHN 에 회사의 기존 PII handling 을 결합하면 통합 privacy 체계가 만들어져요.

dbt 모델 결합 — 실전 큰 회사 패턴

큰 회사들은 대부분 dbt 로 데이터 모델링을 해요. WHN 과 자연스럽게 결합되는 지점.

dbt 모델로 metric 정의

-- models/metrics/daily_active_users.sql
{{ config(
    materialized='incremental',
    unique_key=['date', 'user_id']
) }}

SELECT
    DATE(event_timestamp) AS date,
    user_id,
    COUNT(*) AS event_count,
    MAX(CASE WHEN event_name = 'app_open' THEN 1 ELSE 0 END) AS is_active
FROM {{ ref('events') }}
{% if is_incremental() %}
WHERE event_timestamp >= (SELECT MAX(date) FROM {{ this }})
{% endif %}
GROUP BY 1, 2

이 dbt model 의 결과가 곧 Statsig 의 metric 정의 input. 팀의 single source of truth 가 dbt 와 Statsig 양쪽에 동시에 자리 잡아요.

dbt model 의 재사용

[dbt 모델 layer]
  ├─ stg_events           (정제된 raw event)
  ├─ dim_users            (사용자 차원)
  ├─ fct_purchases        (결제 fact)
  └─ rpt_daily_metrics    (일일 metric)

[Statsig WHN]
  ├─ Event Table = stg_events
  ├─ User Table = dim_users
  ├─ Metric "Daily Purchases" = fct_purchases 의 COUNT
  └─ Metric "ARPU" = rpt_daily_metrics 의 revenue/user

dbt 가 비즈니스 로직을 통일하고, Statsig 가 실험과 분석 도구 역할을 맡아요. 각자 강점을 가져가는 구조.

Test 통합

# dbt tests
models:
  - name: fct_purchases
    columns:
      - name: user_id
        tests:
          - not_null
      - name: revenue
        tests:
          - dbt_utils.accepted_range:
              min_value: 0

dbt test 가 Statsig 분석에 들어가는 input 데이터의 품질을 보장해줘요. 잘못된 메트릭은 곧 잘못된 결정으로 이어지니까요.

Cloud vs WHN 의사결정 가이드 — 7 질문

도입을 결정할 때 7 질문 checklist 를 돌려봐요:

1. 데이터 규모 = 일 이벤트 1M+ 인가? (yes = WHN 검토)
2. 데이터 통제 = 규제·금융·의료 환경인가? (yes = WHN 거의 필수)
3. 기존 웨어하우스 = Snowflake·BigQuery·Databricks·Redshift 가 활성인가? (yes = WHN 자연스러움)
4. 분석가 팀 = SQL 분석가/데이터 엔지니어가 있나? (yes = WHN 풀 활용)
5. dbt = 데이터 모델링 구축 중인가? (yes = WHN 시너지)
6. 유연한 분석 = 정형 차트 외 custom 분석이 자주 필요한가? (yes = WHN)
7. 예산 = Enterprise license + warehouse cost 감당 가능한가? (yes 필수)

WHN 도입 권장 = 7 중 5+ 해당. Cloud 권장 = 7 중 3 이하. 중간 = Cloud 시작 → 성장 후 마이그레이션.

도입 시나리오 — 4 가지 회사 유형

시나리오 1: Pre-PMF Startup (사용자 < 10K)

PMF (Product-Market Fit, 제품-시장 적합) 도달 전 단계.

선택: Statsig Cloud (무료 plan)
이유: 데이터 규모 작음, 빠른 iteration 우선, 분석가 없음
WHN 마이그레이션 시점: 사용자 100K+ 또는 시리즈 A 후

시나리오 2: 성장 단계 (사용자 100K~1M)

선택: Statsig Cloud Pro/Enterprise
이유: 자동화의 가치 ↑, 통계 강력 도구 필요
WHN 검토 시점: 데이터 통제 필요해진 후

시나리오 3: 대형 SaaS (사용자 1M+, B2B/B2C)

선택: Warehouse Native
이유: Snowflake/BigQuery 이미 활용, 분석가 팀, dbt 운영
도입 모델: Full Platform (신규 실험) + Existing (마이그레이션)

시나리오 4: 금융·의료·정부 (규제 강함)

선택: Warehouse Native (필수)
이유: PII/금융 데이터 외부 전송 X
도입 모델: Full Platform + private deployment 옵션
주의: 데이터 격리 architecture 사전 검증

자주 만나는 사고 — WHN 운영

사고 1: Warehouse cost 폭증

원인 — 자주 쓰는 metric 의 full table scan 이 반복돼서.

해결 — partition, cluster, materialized view 에 sample 까지 함께 활용.

사고 2: 권한 너무 넓게

원인 — Statsig role 에 ALL TABLES SELECT 를 줘서 민감 PII 까지 노출.

해결 — 최소 권한 + 별도 schema/database 격리.

사고 3: dbt model 변경 → Statsig metric 깨짐

원인 — dbt model 의 column 이 바뀌었는데 (이름, type, 의미) Statsig 가 알 수 없어서 그대로 깨져요.

해결 — dbt model 의 contract (column 정의 명시) 를 박아두고 변경 시 Statsig metric 도 함께 손봐요.

사고 4: Event timestamp timezone 혼동

원인 — event_timestamp 가 UTC 와 KST 로 혼용되어 분석 결과가 오염.

해결 — 모든 timestamp 는 UTC 로 통일하고, user-facing 표시에서만 timezone 을 변환.

사고 5: SRM detection 못 함

원인 — Existing Experiments 모델에서 기존 assignment data 의 무작위화 검증을 안 한 경우.

해결 — Exposure Analysis 도구로 SRM 을 정기 점검.

사고 6: CUPED 의 적절성 안 확인

원인 — CUPED 가 모든 metric 에 효과적인 게 아니에요. 일부 metric 은 pre-experiment data 가 noise 라서 CUPED 가 오히려 power 를 떨어뜨려요.

해결 — Statsig 의 CUPED preview 로 예상 power 향상을 확인한 뒤 적용.

사고 7: Switchback test 의 carry-over effect

원인 — A → B 전환 후에도 사용자에게 이전 A 의 효과가 남는 경우예요 (예: 가격 변경 후에도 어제 본 가격이 기억에 남음).

해결 — switch 기간을 충분히 두고 (15분 → 1시간 등) carry-over 분석 모델을 함께 돌려요.

사고 8: 비싸진 후 마이그레이션 어려움

원인 — WHN 도입 6개월 운영했는데 cost 가 예상의 3배 → Cloud 회귀를 검토하게 되는 상황.

해결 — 도입 전 PoC (Proof of Concept, 검증용 소규모 도입) 와 비용 시뮬레이션을 미리 해둬요. 한 번 자리잡으면 메트릭 정의 재구성 때문에 마이그레이션 난도가 확 올라가요.

운영 권장 패턴

Pattern 1: PoC 도입

Week 1-2: Cloud 무료 plan 으로 SDK + 기본 Gate 시작
Week 3-4: 실험 1~2개 + 결과 보기
Week 5-8: WHN 검토 — 데모 + cost 시뮬레이션
Week 9+: 결정 — WHN 확장 또는 Cloud 유지

큰 결정일수록 작게 시작해서 검증한 다음에 키워요.

Pattern 2: dbt + Statsig 통합 layer

[Raw events]
   ↓ dbt staging
[Cleaned events]
   ↓ dbt marts
[Domain metrics]
   ↓ Statsig metric 정의
[Statsig 분석]

dbt 가 데이터 모델링, Statsig 가 실험·분석 도구. layer 를 분리해 둬요.

Pattern 3: 비용 모니터링 dashboard

Daily metric:
  - Statsig 가 쓴 compute time
  - Top 10 비싼 쿼리
  - 월 누적 비용 추정

WHN cost 자체도 Statsig 의 Dashboards 로 추적하고, 예산을 넘으면 알람이 가게 해둬요.

Pattern 4: privacy 격리 schema

Database: prod_analytics
  Schema: pii (Statsig 권한 X)
    - users_with_pii (이메일 · 실명)
  Schema: events (Statsig SELECT)
    - events (pseudonymized user_id)
  Schema: statsig (Statsig CREATE/INSERT)
    - exposures
    - metrics

PII 와 분석 데이터를 물리적으로 갈라 둬요.

Pattern 5: 정기 audit

월별 작업:
  - Statsig role 권한 review (최소 권한 유지)
  - cost trend 점검
  - 비싼 쿼리 최적화
  - dbt model 변경 → Statsig metric 동기화
  - SRM detection 정기 보고

WHN 은 지속 운영 노력이 필요해요. Cloud 처럼 zero-touch 가 안 됩니다.

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

• WHN = 데이터를 우리 웨어하우스 에 두고 Statsig 가 쿼리만
• 3 시그널 강함 시 도입 검토 — 데이터 규모 · 통제 · 기존 분석 자산
• Enterprise plan 필수 (Cloud 무료 plan 같은 self-serve X)
• 두 사용 모델 — Full Platform (전체) vs Existing Experiments (분석만)
• Full = 신규 시작 권장, Existing = 기존 시스템 + 통계 강화
• 단계적 = Existing → Full
• 4 단계 워크플로 — Connect → Define → Log → Analyze
• 연결 시 권한 — 최소 권한 + 별도 schema 격리
• 지원 웨어하우스 4종 — Snowflake · BigQuery · Databricks · Redshift
• 각 웨어하우스 별 통합 패턴 차이 (compute 분리 · partitioning · cluster · auto-suspend)
• Table 구조 핵심 = Event · Exposure · User · Metric
• Event = user_id · event_name · timestamp · value · properties
• Exposure = assignment 기록 (Full Platform 자동 생성)
• User = 안정 속성 (가입일 · tier · country)
• 분석 도구 3종:
• Pulse Analysis — 가설 검증 (4편의 실험 분석 WHN 버전)
• Metrics Explorer — 6 차트 (5편)
• Exposure Analysis — 첫 노출 · SRM · 실험 상호작용
• 고급 통계 기법 — WHN 의 핵심 차별
• CUPED — 실험 전 데이터로 분산 ↓ → 통계 power 30~50% 향상
• Stratified Sampling — segment 별 정확한 50/50 (분포 균형)
• Switchback Test — 시간 단위 randomization (marketplace · 가격)
• 기타 = CUPAC · Sequential Testing · Hierarchical Bayesian · Quantile Test
• Cost Management = WHN 의 가장 큰 운영 고민
• 비용 원인 — compute time · data scan · storage · concurrency
• 절약 7종 — partition · materialized view · auto-suspend · retention · 쿼리 monitoring · concurrency 제한 · sample
• 회사 규모별 월 비용 차이 큼 (소규모 $200 ~ 대규모 $20K+)
• 데이터 통제권 = WHN 의 진짜 가치
• 규제 = GDPR · KISA · PCI DSS · HIPAA · FedRAMP
• Privacy 패턴 = PII schema 격리 + pseudonymized user_id + private attributes + retention
• dbt + WHN 결합 — 큰 회사 표준 패턴
• dbt = 데이터 모델링, Statsig = 실험·분석 도구 (layer 분리)
• dbt test = Statsig 분석 input 품질 보장
• Cloud vs WHN 의사결정 7 질문 — 규모 · 통제 · 기존 웨어하우스 · 분석가 · dbt · 유연성 · 예산
• 5+ 해당 = WHN, 3 이하 = Cloud, 중간 = 단계적
• 도입 시나리오 4종 = Pre-PMF · 성장 · 대형 SaaS · 규제 강함
• 함정 — 비용 폭증 (partition · view)
• 함정 — 권한 너무 넓게 (최소 권한)
• 함정 — dbt model 변경 → metric 깨짐 (contract + 동기화)
• 함정 — timestamp timezone (UTC 통일)
• 함정 — Existing model SRM 검증 누락
• 함정 — CUPED 부적합 metric (preview 확인)
• 함정 — Switchback carry-over (충분 switch 기간)
• 함정 — 도입 후 마이그레이션 어려움 (사전 PoC + 비용 시뮬레이션)
• 패턴 — PoC 도입 (Cloud → WHN 검토 → 결정)
• 패턴 — dbt + Statsig layer 분리
• 패턴 — 비용 모니터링 dashboard
• 패턴 — privacy 격리 schema (PII · events · statsig)
• 패턴 — 월별 정기 audit (권한 · 비용 · 쿼리 · 메트릭 · SRM)

공식 문서: Statsig Warehouse Native Introduction 에서 원문을 확인할 수 있어요.

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

이전 글:

• 1편 — 통합 플랫폼 종합 (Feature Flag · 실험 · 분석 · Infra)
• 2편 — SDK Quickstart · 30분 첫 Feature Gate
• 3편 — Feature Flags 깊이 · Targeting · Rollout · Holdout
• 4편 — Experiments 깊이 · RCT · Allocation · 통계 함정
• 5편 — Product Analytics 깊이 · 6 차트 · Funnel · Retention

다음 글:

• 7편 — CDP · Slack · MCP · Webhook 운영 통합
• 8편 — Session Replay · Web Analytics · Infra Analytics
• 9편 — 시리즈 마무리 · 도입 결정 · 경쟁 도구 · 학습 경로