Statsig 입문 1편 — 통합 플랫폼 종합 (Feature Flag · 실험 · 분석 · Infra)

오늘부터 Statsig 입문에서 운영까지 시리즈를 시작해요. 1편은 Statsig 가 도대체 뭘 해주는 플랫폼인가 의 큰 그림 + 각 축이 어떻게 작동하는지 의 깊이.

처음 들으면 어렵게 느껴지는 이유

Statsig 가 처음 헷갈리는 건 서로 달라 보이는 것 들이 한 플랫폼에 묶여 있어서예요.

첫째, Feature Flag — 코드 안에 박힌 기능 ON/OFF 스위치. 둘째, Experimentation (A/B 테스트) — 어느 버전이 더 좋은지 비교 실험. 셋째, Product Analytics — 사용자가 실제로 어떻게 쓰는지 추적. 넷째, Infra Analytics — 서비스 헬스 · OpenTelemetry (분산 관측 표준, 줄여서 OTel) 메트릭/트레이스.

이 넷이 왜 같이 있어야 하나 가 처음엔 잘 안 보여요.

해결법은 비유 하나로. Statsig = "실험실 + 안전 차단기 + 사용자 행동 추적실 + 서버실 계기판" 이 한 회사에 있는 도구. 새 기능을 작은 그룹에만 켜고 (Feature Flag — 차단기) · A/B 두 버전 으로 비교하고 (실험실) · 어느 버튼을 더 누르는지 분석하고 (분석실) · 서버가 잘 도는지 모니터링한다 (계기판). 넷이 한 데이터 흐름 으로 묶여 있어야 "이 새 기능 켰더니 매출이 7% 올랐는데 동시에 API 지연도 12% 늘었다" 같은 cross-layer 결론 이 가능해져요.

Statsig 한 줄 정의

Ship, measure, & learn with the same tools as the world's largest Tech companies. — 공식 welcome

쉽게 풀면 — 대형 Tech 회사가 자체적으로 만든 도구 와 동등한 기능을 SaaS (Software as a Service, 클라우드 구독형 서비스) 로 제공한다는 게 Statsig 의 마케팅 포인트. Meta · Brex · OpenAI 같은 회사들이 thousands of experiments per year 를 운영하는 동일한 인프라를 작은 회사도 즉시 쓸 수 있게 한 게 핵심.

네 축 — 깊이 풀이

축 1: Feature Flags (안전 차단기)

비유 — 새 기능을 전체 사용자 에게 한 번에 켜면 위험. Feature flag = 전기 차단기처럼 일부만 켜는 스위치.

대표 사용 패턴은 네 가지로 좁혀져요. 내부 직원만 새 기능을 쓰게 하거나, 5% 사용자에게만 점진 rollout 을 돌리거나, 문제 생기면 재배포 없이 즉시 OFF 로 끄거나, 국가별·티어별·디바이스별로 차별 노출하는 식.

코드에서는 if 문 한 줄 로 분기:

if (statsig.checkGate('new_checkout_flow')) {
  // 새 결제 흐름
} else {
  // 기존 결제 흐름
}

배포는 코드 한 번, 켜고 끄기는 대시보드 클릭 으로.

Feature Gate vs Dynamic Config vs Experiment — 3 유형 분기

여기서 시험 함정이 하나 있어요. Statsig 의 "feature flag" 가 실제로는 3가지 유형 으로 분기돼요.

// Feature Gate
if (statsig.checkGate('show_premium_banner')) { ... }

// Dynamic Config
const config = statsig.getConfig('checkout_thresholds');
const minOrderValue = config.get('min_order_value', 50);
const freeShippingFrom = config.get('free_shipping_from', 100);

// Experiment
const exp = statsig.getExperiment('button_color_test');
const buttonColor = exp.get('color', 'blue');

Feature Gate 는 단순 토글, Dynamic Config 는 파라미터 묶음, Experiment 는 통계적 비교. 같은 기술 기반이지만 목적이 달라요.

Feature Gate 의 옵션 — 단순 토글 이상

Feature Gate 는 단순 ON/OFF 그 이상이에요. 점진적 자동 rollout 을 짜는 Scheduled Rollouts (10% → 20% → 50% → 100% 단계 진행), 특정 사용자만 강제로 ON/OFF 하는 Overrides (QA · VIP 사용자용), gate A 가 OFF 면 gate B 도 OFF 로 묶이는 계층 관계 Holdouts (종속 gate), gate 를 켰을 때 비활성 group 대비 효과 가 자동으로 측정되는 내장 A/B, 배포 전에 미리 돌려보는 Gate Testing 도구 까지. 결국 단순 boolean 분기 + 통제권·관찰력 강화.

축 2: Experimentation (A/B 실험)

비유 — 그냥 켜는 것 과 비교 실험 은 다름. Experimentation = 통제군 A vs 실험군 B 를 통계적으로 비교.

대표 사용은 결제 버튼 색깔 빨강 vs 초록, 추천 알고리즘 A vs B, 가격 9.99 vs 12.99, 카피 "무료 시작" vs "지금 가입" 처럼 두 버전을 동시에 노출하고 어느 쪽이 통계적으로 우수한지 가르는 자리.

Feature flag 와 차이 = 무작위 통제 시험 (Randomized Controlled Trial, RCT) + 통계적 유의성. 50% / 50% 분할 + 사용자 행동 측정 + p-value · 신뢰도 구간 계산까지 자동.

핵심 통계 개념

여기서 헷갈리는데 — p-value 와 CI 는 같은 동전의 두 면. p-value < 0.05 = 95% CI 가 0 을 포함하지 않음 (= 통계적 유의). 둘 다 우연일 확률 을 측정.

무작위화 단위 (Randomization Unit) — 시험 함정

가장 흔한 함정 — 어느 단위로 무작위화 할 것인가. User 단위는 같은 사용자가 항상 같은 variant 를 받아 일관성이 가장 높고 제일 흔한 선택. Device 단위는 로그인 전 환경에 쓰고, Session 단위는 매 세션마다 새 변형을 받아 UX 일관성이 깨져 비권장. Custom 은 회사·계정·organization 단위로 묶는 방식, B2B 환경에서 주로 써요.

→ B2C 는 user, B2B 는 organization 이 일반적. 잘못된 단위 = 실험 결과 오염.

Experiment 의 lifecycle

1. 가설 정의 — "버튼 색깔 빨강이 결제율 ↑ 한다"
2. Allocation 설정 — 50/50 split, 무작위화 단위 = user
3. Primary metric 지정 — 결제 전환율
4. 실험 시작 — production traffic 의 N% 만 실험 진입
5. 충분한 sample 수집 (대체로 1~4주)
6. 통계 분석 — p-value · CI 자동 계산
7. 결정 — 통계적 유의 + 비즈니스 임팩트 → ship
8. 종료 후 — variant 를 전체 rollout 또는 폐기

축 3: Product Analytics (사용자 행동)

비유 — 기능을 켰는데 효과 있나? 사용자가 어디서 이탈하는지? Product Analytics = 사용자 여정 추적.

Metrics Explorer 의 6 차트 종류

Statsig 의 분석 도구 Metrics Explorer 가 제공하는 차트:

각각 다른 도메인 질문 에 대응. funnel 은 conversion 최적화, retention 은 장기 engagement, lifecycle 은 churn 분석.

Dashboards — 종합 view

여러 차트 + Feature Gate · A/B test · 실험 snapshot 을 하나의 dashboard 로 묶음. 팀 공유 + 정기 review 의 표준.

여기서 정말 중요한 시험 함정 — Statsig 의 강점은 세 축이 통합된 데이터 에 있어요. Feature flag 켰을 때의 funnel 변화, 실험 group 별 retention 비교, Feature flag 별 메트릭 자동 영향 측정 같은 cross-축 query 가 자연스러워요. 별도 도구 (LaunchDarkly + Optimizely + Mixpanel) 로 따로 운영하면 데이터 stitching 이 큰 부담.

축 4: Infra Analytics (인프라 모니터링)

비유 — 코드 안 메트릭이 아니라 서비스 헬스. 응답 시간 · 에러율 · 처리량 같은 infra 레벨 모니터링.

핵심 — OpenTelemetry 호환. 기존에 OTel 로 metric · trace 수집 중이면 Statsig 가 sink 역할.

이 자리가 흥미로운 이유 — 실험 결과 와 인프라 영향 을 한 dashboard 에서 볼 수 있어요. "새 알고리즘 켰더니 결제율 7% ↑ 인데 백엔드 latency p99 가 200ms 늘었다" 같은 trade-off 결정.

추가 부수 기능으로 Session Replay (사용자 실제 화면 replay, debug · UX 분석용) 와 Web Analytics (웹사이트 일반 분석, Google Analytics 유사) 도 함께 묶여 있어요.

한 줄 — Statsig 의 4 축 = Feature Flag · Experimentation · Product Analytics · Infra Analytics 이 통합 데이터 로 묶여 있다.

Statsig Cloud vs Warehouse Native — 5축 비교

Statsig 의 가장 중요한 차별점 중 하나 — 데이터 hosting 두 옵션.

옵션 A: Statsig Cloud

이벤트 데이터를 Statsig 인프라 에 보냄. 빠른 시작, fully managed.

무료 plan 은 실제 운영 시작이 가능한 규모인 월 200만 이벤트 까지 받아주고, Dashboard · Metrics Explorer · Insights 같은 핵심 분석 도구가 모두 포함되며, 인프라 관리 부담이 없어요.

옵션 B: Statsig Warehouse Native (WHN)

우리 회사 데이터 웨어하우스 에 원본 데이터 그대로 두고 Statsig 가 쿼리만 실행. Enterprise 계약 필수.

지원 웨어하우스 = Snowflake · BigQuery · Databricks · Redshift.

두 방식 은 갈래가 갈려요. 하나는 3rd party SDK 사용 — 사용자가 feature assignment 를 직접 관리하면서 exposure 데이터만 Statsig 에 제공. 다른 하나는 Statsig SDK 사용 — Statsig 가 무작위화 를 처리하고 결과를 우리 웨어하우스 에 그대로 기록.

5축 비교

→ 작게 시작 + 빠른 도입 = Cloud, 큰 회사 + 데이터 통제 + 기존 dbt (data build tool, SQL 기반 데이터 변환 도구) 모델 재사용 = Warehouse Native.

데이터 통제권의 의미

Warehouse Native 의 진짜 가치 = 데이터가 우리 회사 밖으로 안 나감. PII (Personally Identifiable Information, 개인 식별 정보) · 매출 데이터 · 사용자 행동 같은 민감 데이터를 외부 SaaS 에 전송 X. GDPR (EU 개인정보 규제) · CCPA (캘리포니아 소비자 프라이버시법) · KISA (한국 인터넷진흥원) 같은 규제 환경에 유리.

SDK — 22종 거의 모든 환경

Client SDK 13종

JavaScript · React · React Native · Next.js · Angular · Swift (iOS/macOS/tvOS) · Android · .NET Client · Roku · Unity · Dart/Flutter · C++ Client.

왜 이렇게 많나 — Feature Flag 는 사용자 디바이스 마다 평가해야 효과적이라 모든 frontend platform 커버 필요.

Server SDK 9종

Node.js · Java · Python · Go · Ruby · .NET Server · PHP · Rust · C++ Server.

Client vs Server 깊이 비교

→ 한 회사가 Server + Client 동시 사용 이 일반적. Java Spring Boot Server SDK + React Client SDK + iOS Swift SDK 식.

일관성 보장

같은 user ID 면 Server · Client · iOS · Android 모든 SDK 가 같은 variant 반환. Statsig 의 deterministic hashing 이 보장. 운영의 핵심 기둥.

통합 — 이미 쓰는 도구와 자연스럽게

Statsig 의 또 다른 강점 = 기존 도구 와 통합.

Slack 통합

실험 결과를 daily summary 로 채널에 자동 publish. p-value 변화 알림, 통계 유의 도달 시 알림. 의사결정 빠름.

Segment · Rudderstack 통합

이미 CDP 로 이벤트 수집 중인 회사가 추가 SDK 통합 없이 Statsig 활용 가능. Segment destination 으로 Statsig 추가 = 1 클릭. 큰 회사의 일반적 도입 경로.

시나리오 — 기존 stack 별 도입 패턴

도입 결정 가이드 — 언제 가야 하나

여기서 시험 함정이 하나 있어요 — Statsig 같은 플랫폼 을 도입할 시점이 생각보다 늦으면 운영 비용 폭증.

도입 시그널 (3개 이상 해당 = 검토 시점)

• Feature flag 가 코드 안 boolean 으로 박혀 매 새 기능 = 재배포 필요
• A/B 테스트 가 spreadsheet · 수작업 분석
• 사용자 행동 분석을 3~4 개 도구 로 나눠서 봄
• 프로덕션 롤백 이 코드 revert + 재배포 외 방법 없음
• 데이터 분석가가 각 실험마다 ad-hoc SQL 작성
• 팀 간 실험 우선순위·결과 가 흩어져 있음
• cross-축 분석 (flag 켰을 때 retention 변화 등) 이 불가능

작은 회사라면 Cloud + 무료 plan 으로 시작.

도입 미루기 좋은 case

초기 1~2개월 prototyping 단계, 사용자 100명 미만, 실험 자체가 의미 없는 도메인 (예: 단순 내부 도구) 셋 중 하나라면 굳이 서둘 필요가 없어요.

시작 흐름 — 어디부터

공식 welcome 페이지의 Getting Started 3 단계 흐름:

1. SDK Quickstart

가장 가까운 SDK 골라 5분 안 설치. JavaScript 가 가장 빠르고 server SDK 도 docs 가 친절. 첫 feature gate 박는 데 30분도 안 걸려요.

2. Intro to Statsig (플랫폼 이해)

핵심 개념 · 기능 학습. 이 글이 그 역할을 한국어로 풀어낸 셈.

3. Warehouse Native (해당 시)

대규모 환경 또는 데이터 통제 필요시. Enterprise 계약 필수라 PoC (Proof of Concept, 개념 검증) 후 결정 권장.

자주 만나는 사고 — 도입 단계

사고 1: Server secret 노출

원인 — Server SDK key 를 frontend 코드 또는 git public repo 에 박음.

해결 — Server SDK key 는 backend 만. Client 측 = Client SDK key (공개 가능). 또는 env var · secrets manager.

사고 2: 같은 user 인데 다른 variant

원인 — Server 와 Client SDK 의 user ID 가 동기화 안 됨 (예: Server 는 internal ID, Client 는 anonymous ID).

해결 — 둘 다 같은 stable user ID 사용. anonymous 단계는 device ID, 로그인 후 user ID 로 전환 + custom IDs 활용.

사고 3: Feature gate 너무 많이 생성

원인 — 매 기능마다 gate 생성 → 100+ 개 누적 → 운영 부담.

해결 — 기능 GA (General Availability, 정식 출시) 후 gate 제거 — temporary gate vs permanent gate 구분.

사고 4: 실험 통계 결과 잘못 해석

원인 — 짧은 sample + p-value 잠깐 < 0.05 → 결정.

해결 — 충분한 sample (대체로 각 variant 수천 명) + 1주 이상 + 비즈니스 임팩트 검증.

사고 5: 비싼 메트릭 폭증

원인 — 모든 사용자 행동을 event 로 보냄 → 200만 이벤트/월 초과.

해결 — 핵심 메트릭만 + aggregated event (10초 단위 batch).

다음 단계 — 본 시리즈에서 다룰 자리

공식 docs 의 주요 페이지 = 본 시리즈의 후속 글:

• SDK Quickstart — 실제 SDK 설치 + 첫 gate (다음 글)
• Feature Flags 깊이 — Gate · Dynamic Config · Override · Holdout · Scheduled Rollout
• Experimentation 깊이 — RCT 설계 · Allocation · 통계 분석 · SRM (Sample Ratio Mismatch, 표본 비율 불일치) detection
• Product Analytics 깊이 — 6 차트 · Funnels · Retention · Cohort
• Warehouse Native 깊이 — Snowflake/BigQuery 통합 · dbt 모델 활용
• CDP 통합 — Segment · Rudderstack 의 Statsig destination
• Slack · 운영 통합 — Daily digest · Alert · 의사결정 워크플로

시험 직전 한 번 더 — Statsig 입문 함정 압축 노트

• Statsig = Feature Flag + Experimentation + Product Analytics + Infra Analytics 통합 SaaS
• 4 축이 통합 데이터 흐름 으로 묶여 있는 게 핵심 차별
• 별도 도구 (LaunchDarkly + Optimizely + Mixpanel) = 데이터 stitching 부담
• 추가 부수 = Session Replay · Web Analytics
• Feature Gate = boolean 토글
• Dynamic Config = JSON 구조화 데이터 (파라미터 튜닝)
• Experiment = variant 할당 + 통계적 비교
• 같은 SDK 기반, 목적이 다름
• Feature Gate 옵션 — Scheduled Rollouts · Overrides · Holdouts · 내장 A/B · Gate Testing
• Experimentation 통계 — Variant · Randomization Unit · Primary/Secondary Metric · p-value · 신뢰도 구간
• 무작위화 단위 — B2C 는 user, B2B 는 organization
• 잘못된 단위 = 실험 결과 오염
• 실험 lifecycle — 가설 → allocation → primary metric → sample 수집 → 통계 분석 → 결정
• Product Analytics 6 차트 = Metric Drilldown · Funnels · Retention · Distribution · User Journeys · Lifecycle
• Dashboards = 차트 + Feature Gate · A/B · 실험 snapshot 통합
• cross-축 query = Statsig 의 핵심 강점 (flag 켰을 때 funnel 변화 등)
• Infra Analytics = OpenTelemetry 호환, infra 레벨 메트릭/트레이스
• Statsig Cloud — 무료 plan 200만 이벤트/월, fully managed
• Warehouse Native (WHN) — Snowflake · BigQuery · Databricks · Redshift, Enterprise 계약
• WHN 두 방식 — 3rd party SDK / Statsig SDK
• 5축 비교 — 데이터 소스 · 분석 유연성 · 데이터팀 · 비용 · 확장성
• 작게 시작 = Cloud, 큰 회사 + 데이터 통제 = WHN
• 보안·규제 환경 = WHN 필수
• SDK 22종 = Client 13 + Server 9
• Client SDK = initialize 시 evaluated values + 로컬 lookup
• Server SDK = rule set 메모리 + 매 요청 평가
• Server secret 절대 공개 X (Client key 만 공개 가능)
• 같은 user ID = Server · Client · iOS · Android 모두 같은 variant (deterministic hashing)
• 통합 = Webflow · Shopify · Slack · Segment · Rudderstack · Hightouch · mParticle · Snowflake · BigQuery
• Slack = 실험 결과 daily summary · p-value 변화 알림
• Segment destination 으로 Statsig 추가 = 큰 회사 일반 경로
• 도입 시그널 (3개+) = boolean flag · 수작업 A/B · 분석 분산 · 롤백 어려움 · ad-hoc SQL · cross-축 불가
• 도입 미루기 OK = 초기 prototyping · 사용자 100명 미만
• 사고 — Server secret 노출 · user ID 비동기화 · gate 폭증 · 짧은 sample 통계 오판 · 이벤트 폭증
• Server SDK key 는 backend 만, Client SDK key 는 공개 가능
• temporary gate vs permanent gate 구분
• 실험 = 충분 sample (각 variant 수천 명) + 1주 이상 + 비즈니스 임팩트

공식 문서: Statsig Welcome · Understanding Platform · Feature Flags Overview · Experiments Overview · Product Analytics Overview 에서 원문을 확인할 수 있어요.

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

다음 글:

• 2편 — SDK Quickstart · 30분 첫 Feature Gate
• 3편 — Feature Flags 깊이 · Targeting · Rollout · Holdout
• 4편 — Experiments 깊이 · RCT · Allocation · 통계 함정
• 5편 — Product Analytics 깊이 · 6 차트 · Funnel · Retention
• 6편 — Warehouse Native 깊이 · Snowflake · BigQuery · dbt 결합