Statsig 입문 7편 — CDP · Slack · MCP · Webhook 운영 통합

이 글은 Statsig 입문에서 운영까지 시리즈 7편이에요. 1편 종합 · 2편 SDK · 3편 Feature Flags · 4편 Experiments · 5편 Product Analytics · 6편 Warehouse Native 까지 Statsig 내부 기능 을 모두 봤다면, 이번 7편은 Statsig 와 사외 도구의 연결 — 통합 layer.

왜 통합이 운영의 마지막 자리인가

Statsig 가 훌륭한 플랫폼 이라도 우리 회사 의 다른 도구 들과 연결 안 되면 섬 이 돼요. 이미 Segment 로 이벤트 수집 중인데 Statsig SDK (Software Development Kit, 개발 라이브러리) 를 또 박아야 할 때, 실험 결과를 Slack 으로 자동 공유 하고 싶을 때, gate 변경을 사내 audit (감사) 시스템 에 기록해야 할 때, 메트릭 alert 가 PagerDuty 로 가야 할 때, Cursor IDE (Integrated Development Environment, 통합 개발 환경) 에서 AI 가 Statsig 작업을 도와줬으면 할 때 — 모두 통합 layer 가 답이에요. 7편은 그 자리의 깊이.

통합의 4 카테고리

각각 다른 운영 문제 에 답해요. 모두 알 필요 X — 우리 회사에 해당하는 것 만.

CDP 통합 — 이미 수집 중인 이벤트 재활용

CDP (Customer Data Platform) 란

CDP = 모든 사용자 이벤트의 중앙 수집소. 한 코드 — 여러 destination 자동 분배.

[웹/앱]
   ↓ analytics.track("checkout_completed", {...})
[Segment CDP]
   ↓ (자동 분배)
   ├─ Google Analytics
   ├─ Mixpanel
   ├─ Salesforce
   ├─ Snowflake
   └─ Statsig         ← 통합 destination

이미 CDP 운영 중 인 회사에 Statsig 추가 = 1 클릭. SDK 통합 부담 없음.

Segment + Statsig

Segment destination 으로 Statsig 추가:

Segment Catalog → Statsig → Connect
  Config:
    - Server Key (Statsig)
    - User ID mapping (Segment userId → Statsig userID)
    - Event filter (어떤 event 만 Statsig 로)

이러면 Segment 의 모든 analytics.track 이 자동으로 Statsig 의 logEvent 처럼 동작.

Rudderstack · Hightouch · mParticle

Rudderstack = Segment 의 open-source 대안. self-hosted 가능.

Hightouch = Reverse ETL (Extract-Transform-Load 의 역방향) — 우리 웨어하우스 데이터를 Salesforce · Statsig · 다른 SaaS 로 push.

mParticle = 모바일 중심 CDP. iOS · Android 의 깊은 통합.

→ 다 비슷한 패턴 — CDP destination 으로 Statsig 추가.

CDP 통합의 함정

여기서 시험 함정이 하나 있어요 — CDP 통합 시 user ID mapping 이 가장 중요. Segment 의 anonymousId 와 로그인 후 userId 를 Statsig 의 customIDs 와 정확히 맞춰야 2편의 deterministic hashing 이 일관 동작해요.

잘못된 mapping:
  Segment anonymousId="xyz-123" → Statsig deviceID="xyz-123"
  로그인 후 Segment userId="user-456" → Statsig userID 안 박힘
  → 같은 사용자가 두 다른 entity 로 인식 → variant 바뀜

해결 — 명시적 user ID transition — 로그인 시점에 anonymousId + userId 동시 박기 (Statsig 의 customIDs 활용).

Slack 통합 — 3 알림 카테고리

Slack 통합 — Product Notifications · General Notifications · Personal Notifications 3 categories. — 공식 docs

1. Product Notifications

제품 수준 활동 + 상태 변경 의 알림.

필터 — 팀별 · 태그별 · 앱별 분리. 모든 알림이 한 채널 X = 노이즈 폭증.

2. General Notifications

Statsig 시스템 상태 + 행정 업데이트. API 서비스 중단/복구, 새 feature 출시 안내, 가격/plan 변경, 보안 업데이트가 여기로 들어와요. Statsig 자체 의 상태라 거의 관리자만 구독.

3. Personal Notifications

개인 계정 의 알림 + 이메일 preference. 본인이 만든 gate · experiment 의 진행 상태, 본인이 follow 한 메트릭의 변화, 본인 댓글에 대한 답글이 여기로 와요 — PM · 개발자 개인 dashboard. 본인 책임 영역만.

Slack 통합의 실전 channel 설계

#statsig-releases       (Product: Gate ON/OFF)
#statsig-experiments    (Product: Experiment 시작/종료/결과)
#statsig-alerts         (Product: Metric alert · 이상치)
#statsig-audit          (Product: 보안 · 권한 · 운영자 변경)
#statsig-ops            (General: API · 시스템 상태)

5 채널 분리 = 알림 받는 사람 자율 구독. 우리 팀과 관련된 것만.

Daily Digest 패턴

Subscriptions — daily/weekly 정기 snapshot 을 이메일/Slack 으로 전송. — 공식 docs (5편)

Daily Digest = 매일 정해진 시간 주요 dashboard snapshot 을 Slack 또는 email 로.

Daily 09:00 AM Slack:
  - 어제 매출 · 신규 가입 · DAU
  - 진행 중 실험 3개 progress
  - 어제 변경된 Feature Gate 5개

Weekly 월요일:
  - 주간 핵심 metric 변화
  - 종료된 실험 결과
  - 새 시작 실험 안내

수동 확인 없이도 의사결정자가 상태 인지. 문제 발생 즉시 detect.

Webhook 통합 — 사내 시스템 연결

Webhook 의 의미

Webhook (이벤트 발생 시 외부 URL 로 자동 호출하는 방식) = Statsig 의 이벤트 (gate 변경 · 실험 시작 · ...) 가 발생하면 지정한 URL 로 HTTP POST. 사내 자체 시스템 으로 연결.

운영 사용 case

case 1: 사내 audit 시스템

Statsig audit event → Webhook → 사내 audit DB
  → 누가 언제 어떤 gate 를 변경했는지 영구 기록
  → 컴플라이언스 reporting

case 2: 사내 deployment 시스템 연동

Statsig "production gate 100% rollout 도달" → Webhook
  → 사내 deploy system 에 신호
  → 자동으로 gate 코드 cleanup PR 생성

case 3: 별도 metric 시스템

Statsig metric alert → Webhook → DataDog · 자체 monitoring
  → 통합 dashboard

Webhook 의 보안

서명 검증 — Statsig 가 보내는 HTTP POST 에 signature header 가 붙어요. 수신 측에서 우리만 아는 secret 으로 검증. 이때 쓰는 게 HMAC (Hash-based Message Authentication Code, 해시 기반 메시지 인증 코드).

import hmac
import hashlib

def verify_statsig_webhook(body: bytes, signature: str, secret: str) -> bool:
    expected = hmac.new(
        secret.encode(),
        body,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

왜 검증? — 누구나 우리 webhook URL 을 알면 fake event 보낼 수 있음. signature = 진짜 Statsig 가 보낸 것 보장.

REST API — 프로그래밍적 통제

Statsig 의 모든 console UI 작업 이 REST API 로도 가능.

자주 쓰는 API

Gate / Config / Experiment 조회 · 생성 · 수정:

GET    /console/v1/gates                  → 전체 gate 목록
POST   /console/v1/gates                  → 새 gate 생성
GET    /console/v1/gates/{id}             → 특정 gate 상세
PATCH  /console/v1/gates/{id}             → gate 수정
DELETE /console/v1/gates/{id}             → gate 삭제

Audit log 조회:

GET /console/v1/audit_logs?startTime=...&endTime=...

Metric 조회:

GET /console/v1/metrics
GET /console/v1/metrics/{name}/results

인증

Authorization: Bearer console-XXXXX
Content-Type: application/json

Console API Key (Server Secret 과 다름) 발급. 관리자 권한 작업이라 보안 매우 중요.

운영 사용 case

case 1: 대량 gate cleanup (script)

import requests

def list_temporary_gates():
    response = requests.get(
        "https://statsigapi.net/console/v1/gates",
        headers={"STATSIG-API-KEY": CONSOLE_KEY}
    )
    return response.json()["data"]

def archive_gate(gate_id):
    requests.patch(
        f"https://statsigapi.net/console/v1/gates/{gate_id}",
        headers={"STATSIG-API-KEY": CONSOLE_KEY},
        json={"isArchived": True}
    )

# 분기별 cleanup
gates = list_temporary_gates()
old_gates = [g for g in gates if g["lastModified"] < "2026-01-01"]
for g in old_gates:
    archive_gate(g["id"])

case 2: gate-as-code (Terraform 유사 패턴)

# gates/checkout_flow.yml
name: new_checkout_flow
type: temporary
owner: checkout-team
expires: 2026-08-01

rules:
  - name: Internal team
    condition:
      type: email
      operator: contains_any
      values: ["@statsig.com"]
    pass_percentage: 100

  - name: Production rollout
    condition:
      type: environment_tier
      operator: any_of
      values: ["production"]
    pass_percentage: 5

이 YAML 을 CI/CD (Continuous Integration/Delivery, 지속 통합·배포) 로 Statsig 에 sync — gate 정의를 git 으로 버전 관리. config-as-code.

Rate Limit

Statsig API = rate limit 있음 (분당 요청 수). 대량 작업 시 backoff + retry 필수.

MCP — AI 개발 도구 통합

Statsig MCP (Model Context Protocol) 서버 — Codex · ChatGPT Connector · Cursor IDE · Claude Code 와 연동. — 공식 docs

MCP 가 뭔가

Model Context Protocol = AI 도구 (Claude · GPT · Cursor) 가 외부 시스템에 접근 하는 표준 인터페이스. Anthropic 이 주도하는 오픈 스펙.

Statsig MCP = Statsig 의 console API 를 AI 도구가 쉽게 호출하도록 wrapping.

지원 AI 도구

MCP 기능 7 범주

사용 case

case 1: AI 가 gate cleanup 도움

[Cursor IDE 에서]
"6개월 이상 변경 없는 temporary gate 모두 archive 해줘"

[Claude Code via MCP]
→ Statsig MCP 의 Audit Log + Feature Gate API 호출
→ 조건 맞는 gate 식별
→ 사용자 확인 후 archive 실행

case 2: IDE 작업 흐름 요약

[Cursor 에서 PR 작성 중]
"이 PR 이 영향 줄 Feature Gate 들 확인해줘"

[Claude Code via MCP]
→ 변경된 코드의 checkGate 호출 식별
→ Statsig MCP 로 각 gate 상태 조회
→ "gate A 는 production 100% rollout 중 — 안전. gate B 는 dev/staging 만 — 영향 X"

case 3: 일괄 작업 자동화

[ChatGPT 에서]
"신규 회원 가입 funnel 분석을 위한 metric 5개 만들어줘"

[ChatGPT via MCP]
→ Statsig MCP 의 Metric POST API 5번 호출
→ funnel 단계 별 metric 생성

MCP 의 미래

AI 도구가 SaaS 와 자연스럽게 통합 하는 미래의 표준. Statsig MCP 가 얼리 어답터. 다른 SaaS (Notion · Linear · GitHub) 도 MCP 서버 제공 시작.

→ AI agent 가 우리 운영 도구들을 자연스럽게 다룸.

모니터링 통합 — Datadog · PagerDuty · OpenTelemetry

Datadog 결합

Datadog = 인프라 모니터링 표준. Statsig 와 결합:

• Statsig metric alert → Datadog (webhook)
• Datadog 의 application metric → Statsig event (1편의 Infra Analytics)
• 통합 dashboard (Statsig dashboard 의 결과 + Datadog infra 데이터)

PagerDuty

Critical alert → PagerDuty → 담당 엔지니어 page.

Statsig metric alert: "error_rate > 5%"
  → Webhook → PagerDuty Incident
  → on-call 엔지니어 자동 호출

운영 production 안전 의 핵심 layer.

OpenTelemetry

1편의 Infra Analytics 의 표준 — OpenTelemetry (OTel, 분산 추적·메트릭 수집 오픈 스펙) 호환. 기존 OTel 로 metric · trace 수집 중이면 Statsig 가 sink (도착지) 역할.

Application → OTel collector → Statsig (Infra Analytics)
                              ↘ Datadog · Jaeger · etc.

OTel 한 set 으로 여러 destination. 인프라 메트릭의 표준.

운영 워크플로 자동화 — 종합 패턴

위 통합들을 조합 한 자동화 워크플로:

워크플로 1: 실험 의사결정 자동화

실험 시작 (Statsig)
  ↓
Slack #experiment-channel 알림
  ↓
1주 후 통계 유의 도달
  ↓
Slack #experiment-results 알림 (Daily Digest)
  ↓
PM 이 메시지 reaction (✓ ship 또는 ✗ 폐기)
  ↓
Webhook → 사내 system → ship 또는 archive 자동 실행

워크플로 2: Gate 변경 audit 자동화

Feature Gate 변경
  ↓
Audit log webhook
  ↓
사내 audit DB 영구 기록
  ↓
주요 변경 (production 100% rollout) = PagerDuty alert
  ↓
slack #audit-channel 알림

워크플로 3: Cost monitoring 자동화 (WHN)

Statsig WHN (Warehouse Native, 6편) compute 사용량 (REST API)
  ↓
일별 cost 추적 dashboard
  ↓
예산의 80% 도달 = Slack alert
  ↓
100% 도달 = PagerDuty + 자동 query throttle

워크플로 4: AI 보조 운영

PM 이 Cursor IDE 에서 PR 작성 중
  ↓
Cursor + Claude Code via MCP
  ↓
"이 변경은 gate A 의 rollout 95% 와 관련"
  ↓
"gate A 는 다음 주 100% 도달 예정"
  ↓
PR 메시지에 자동 추가 + slack 알림

자주 만나는 사고 — 통합 운영

사고 1: CDP user ID mapping 잘못

원인 — Segment anonymousId vs userId 와 Statsig customIDs 불일치 → 같은 사용자가 두 entity 로 인식.

해결 — 로그인 transition 명시 + customIDs 활용 + 정기 검증.

사고 2: Slack 알림 폭증

원인 — 모든 gate · experiment · audit 가 한 채널 → 노이즈 압도.

해결 — 5 채널 분리 + 필터 + Daily Digest 우선.

사고 3: Webhook signature 검증 누락

원인 — fake webhook 으로 사내 시스템 임의 트리거 가능.

해결 — 모든 webhook = HMAC signature 검증.

사고 4: REST API rate limit hit

원인 — 대량 cleanup script 에서 분당 1000 요청 → rate limit.

해결 — exponential backoff + retry · 시간 분산 처리.

사고 5: Console API key 유출

원인 — Console API key (관리자 권한) 가 script · git history 에 노출 → 누구나 gate · experiment 임의 변경 가능.

해결 — secrets manager + 즉시 rotation if 유출.

사고 6: MCP 권한 너무 넓게

원인 — AI 도구에 console 의 모든 권한 부여 → AI 가 prod gate 실수 변경 가능.

해결 — MCP key 의 최소 권한 설정 (read-only · 특정 project 만) + audit log review.

사고 7: Daily digest 의 부정확한 데이터

원인 — 전날 데이터 미완성 (web event 의 delay) → digest 의 결제율 false 하락.

해결 — 24~48시간 delay window 확보 후 digest 발송.

사고 8: Webhook 의 처리 실패

원인 — Webhook 의 수신 endpoint 가 일시 down → 이벤트 손실.

해결 — Statsig 의 webhook retry (자동) + 사내 endpoint 의 idempotency (같은 요청 여러 번 와도 결과 동일) 보장.

운영 권장 패턴

Pattern 1: 표준 CDP 셋업

1. Segment 운영 중 → Segment destination 으로 Statsig 추가
2. User ID mapping 명시:
   - anonymousId → Statsig customIDs.deviceID
   - userId → Statsig userID
3. Event filter — Statsig 가 분석할 event 만 선택
4. SDK 별도 통합 X (Segment 가 모든 분배)

Pattern 2: Slack 채널 5 분리

slack_channels:
  releases:       "#statsig-releases"      # Gate ON/OFF
  experiments:    "#statsig-experiments"   # Experiment 시작/종료
  results:        "#statsig-results"       # Pulse 결과
  audit:          "#statsig-audit"         # 변경 · 권한
  alerts:         "#statsig-alerts"        # Metric · 이상치

각 채널 = 해당 팀만 구독. 노이즈 ↓.

Pattern 3: gate-as-code (Terraform 유사)

git repo:
  statsig-config/
    gates/
      checkout_flow.yml
      pricing_test.yml
    experiments/
      ...
    segments/
      ...

CI/CD:
  on PR merge → Statsig REST API 로 sync
  diff check → 변경 review

git 으로 버전 관리 + PR review + audit trail.

Pattern 4: Webhook + 사내 audit 시스템

@app.post("/webhooks/statsig")
def handle_statsig_webhook(request):
    # 1. signature 검증
    if not verify_statsig_webhook(
        body=request.body,
        signature=request.headers["X-Statsig-Signature"],
        secret=STATSIG_WEBHOOK_SECRET
    ):
        return 401

    event = request.json()

    # 2. 사내 audit DB 기록
    audit_db.insert({
        "source": "statsig",
        "event_type": event["type"],
        "actor": event["actor"],
        "target": event["target"],
        "data": event["data"],
        "received_at": now()
    })

    # 3. critical event 알림
    if event["type"] in ["gate_100_rollout", "experiment_concluded"]:
        pagerduty_alert(event)

    return 200

표준 webhook 핸들러.

Pattern 5: Daily Digest + Weekly Review

Daily 08:00 KST Slack:
  - 어제 매출 · 신규 가입 · DAU
  - 진행 중 실험 3개 progress (CI 그래프)
  - 어제 변경 Feature Gate 5개

Weekly 월요일 회의:
  - 종료 실험 결과 review
  - 새 실험 가설 검토
  - production 의 metric trend 분석

수동 dashboard check → 자동 push.

Pattern 6: MCP 안전 도입

1. Read-only Console API key 발급 (조회만)
2. AI 도구 (Cursor · Claude Code) 에 MCP 설정
3. 1주 운영 — audit log 점검 + 정확성 확인
4. Write 권한 점진 추가:
   - 첫째 — Metric · Segment (저위험)
   - 둘째 — Dynamic Config
   - 셋째 — Gate · Experiment (검증 후)
5. Production Gate write 는 *항상 사람 confirm*

AI 통합의 점진적 신뢰 구축. production gate 자동 변경 은 피함.

통합 도입 우선순위 — 어디부터

회사 단계별 권장 도입 순서:

단계 1 (시작 — 1주 안)

• Slack 알림 — 최소 audit channel + experiment results
• Daily Digest — email 한 통이라도 시작

단계 2 (1~3개월)

• CDP 통합 (이미 운영 중인 경우)
• Webhook + 사내 audit (컴플라이언스 요구 있는 경우)

단계 3 (3~6개월)

• REST API + gate-as-code
• 모니터링 통합 (Datadog · PagerDuty)

단계 4 (운영 안정 후)

• MCP + AI 도구
• 운영 워크플로 자동화

→ 작게 시작 + 점진 확장. 한 번에 모두 X.

시험 직전 한 번 더 — 통합 종합 함정 압축 노트

• 통합 4 카테고리 = CDP · 메시징 · 운영 통합 · 모니터링
• CDP 4종 = Segment · Rudderstack · Hightouch · mParticle
• CDP = 이벤트 수집 중앙소, 한 코드 여러 destination
• Segment destination 으로 Statsig 추가 = 1 클릭 통합
• 함정 — user ID mapping (anonymousId · userId · customIDs)
• 로그인 transition 명시 + customIDs 활용
• Slack 3 카테고리 = Product · General · Personal
• Product = gate · experiment · alert · audit
• General = 시스템 상태 · 행정
• Personal = 개인 dashboard
• 5 채널 분리 = releases · experiments · results · audit · alerts
• Daily Digest = 매일 정기 dashboard snapshot 자동
• Weekly = 주간 review 자료
• Webhook = Statsig 이벤트 → HTTP POST → 사내 시스템
• 사용 case = audit DB · deploy 자동 · 별도 monitoring
• Webhook 보안 = HMAC signature 검증 필수
• 검증 누락 = fake event 위험
• REST API = console UI 의 프로그래밍 버전
• 주요 endpoint = gates · experiments · metrics · audit_logs
• 인증 = Console API Key (Server Secret 과 다름)
• Console API Key = 관리자 권한, 매우 민감
• 함정 — rate limit (backoff + retry)
• 함정 — key 유출 (secrets manager)
• 사용 case — bulk cleanup · gate-as-code · CI/CD 동기
• gate-as-code = git + YAML + CI/CD sync
• 버전 관리 + PR review + audit trail
• MCP (Model Context Protocol) = AI 도구 통합 표준
• 지원 도구 = Codex · ChatGPT · Cursor IDE · Claude Code
• MCP 7 범주 = Audit · Dynamic Config · Experiment · Gate · Layer · Metric · Segment
• 각 범주 GET/POST
• 사용 case = gate cleanup · PR 영향 분석 · 일괄 작업
• 함정 — MCP 권한 너무 넓게 (최소 권한 + 점진 확장)
• production gate 자동 변경 X (사람 confirm)
• 모니터링 통합 = Datadog · PagerDuty · OpenTelemetry
• Datadog = metric alert · application metric → Statsig event
• PagerDuty = critical alert → on-call
• OpenTelemetry = OTel collector 의 sink 로 Statsig
• 운영 워크플로 자동화 종합:
• 실험 의사결정 자동화 (Slack reaction → ship 자동)
• Gate audit (webhook → 사내 DB → critical PagerDuty)
• Cost monitoring (WHN compute → threshold alert)
• AI 보조 (Cursor + MCP → PR 영향 분석)
• 함정 — Slack 알림 폭증 → 채널 분리
• 함정 — Daily digest 부정확 (24~48시간 delay)
• 함정 — Webhook 처리 실패 → idempotency
• 도입 우선순위:
• 1주: Slack + Daily Digest
• 1~3개월: CDP + Webhook audit
• 3~6개월: REST API + 모니터링
• 안정 후: MCP + 자동화

공식 문서: Statsig Integrations · Slack Integration 에서 원문을 확인할 수 있어요.

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

이전 글:

• 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 결합

다음 글:

• 8편 — Session Replay · Web Analytics · Infra Analytics
• 9편 — 시리즈 마무리 · 도입 결정 · 경쟁 도구 · 학습 경로