Statsig 입문 8편 — Session Replay · Web Analytics · Infra Analytics

이 글은 Statsig 입문에서 운영까지 시리즈 8편이에요. 1~7편에서 메인 4 축 + 통합 을 봤다면, 이번 8편은 그 옆자리에 붙는 부수 기능 — Session Replay · Web Analytics · Infra Analytics 를 깊이 들여다봐요.

부수 기능 vs 메인 기능 — 왜 부수인가

1편의 4 축 (Feature Flag · Experimentation · Product Analytics · Infra Analytics) 중 대부분 회사가 먼저 도입하는 건 앞 3 축이에요. 부수 기능은 이렇게 자리가 달라요.

부수란 가치는 분명한데 모든 회사가 즉시 필요한 건 아니라는 뜻이에요. 우리 회사 상황을 보고 선택적으로 도입하면 돼요.

Session Replay — 사용자 화면을 실제 영상처럼

Session Replay 가 답하는 질문

• 왜 결제 단계에서 이탈 하는가? (funnel(전환 깔때기) 만으로 안 보이는 실제 사용자 행동)
• 버튼이 안 보이는 화면 있나? (responsive(화면 크기 적응) 디자인 디버그)
• 특정 사용자의 에러 reproduce(재현)
• UX 가설 검증 (실험 데이터 + 실제 사용 영상)

5편 Product Analytics 의 6 차트 는 aggregate(집계) 추세를 봐요. Session Replay 는 개별 사용자 경험의 깊이를 봐요.

어떻게 작동하나

재생은 Statsig 콘솔에서 동영상처럼 작동하지만, 실제로는 웹사이트의 직렬화된 표현. rrweb 오픈소스 라이브러리 사용 — 성능·공간 효율적. — 공식 docs

진짜 영상이 아니에요. DOM 변화와 사용자 입력(mouse · click · scroll · keyboard) 의 sequence 를 기록하고, 재생할 때 DOM 을 재구성하는 방식이에요.

rrweb 의 의미

rrweb = Record and Replay the Web 의 오픈소스 라이브러리예요. 산업 표준이라 Statsig · LogRocket · FullStory · Hotjar 도 비슷한 기술을 써요.

장점:

• 영상 대비 크기 1/100 (DOM event 만 기록)
• 재생 시 원본 CSS · interactive element 그대로
• 검색 가능 (특정 event 로 jump)

단점:

• iframe · canvas · video 의 일부는 정확 재현 X
• 상대 시간 sync 가 끊길 수 있음

운영 사용 case

case 1: 결제 funnel 디버그

5편의 Funnel 차트:
  cart_added → checkout_started (38% drop !)

→ Session Replay 로 *drop 사용자 영상* 10개 보기
→ 공통 발견: "결제 버튼 클릭 시 모달 안 뜸"
→ JS error 확인 → 수정

aggregate 만 봐선 원인을 추론하기 어려워요. 영상을 보면 진짜 원인이 드러나요.

case 2: A/B 실험 의외 결과 분석

[4편 Experiments]
  Treatment 의 결제율이 5% 떨어짐 (p < 0.01)

→ 의외 결과 — 가설은 "올라간다" 였음
→ Session Replay 의 Treatment 그룹 영상 분석
→ 발견: "새 디자인의 결제 버튼이 모바일에서 키보드에 가림"
→ 모바일 layout 수정

여기서 Treatment(실험군) 는 실험에서 새 안을 받은 그룹이에요. 결과 수치만 보고 ship 을 결정하면 위험해요. 왜 그런 결과가 나왔는지까지 영상으로 짚어야 안전해요.

case 3: 사용자 신고 reproduce

"결제 안 됐어요" 고객 문의
  → user_id 로 Session Replay 검색
  → 해당 사용자의 최근 세션 영상
  → "쿠폰 적용 후 결제 버튼 disable" 발견
  → 즉시 수정 + 환불 처리

CS · 운영 입장에서 정말 강력한 도구예요.

Privacy + 마스킹 — 중요 자리

이 자리는 정말 중요해요. 민감 데이터를 record 하면 안 돼요.

• 비밀번호 입력
• 카드 번호
• 주민등록번호
• 개인 메시지 · 이메일 내용

rrweb 의 마스킹 옵션:

// Statsig SDK
sessionReplay.start({
  maskTextSelector: '.sensitive, [data-private]',
  maskInputs: true,            // 모든 input 마스킹
  maskAllText: false,
  ignoreSelector: '#chat-window'  // 완전 제외
});

권장 패턴:

1. maskInputs: true — 모든 <input> 자동 마스킹 (기본 default 권장)
2. data-private 속성 — 민감 element 마킹 → 자동 마스킹
3. .sensitive CSS class — 마찬가지
4. iframe 안 외부 위젯 — 광고 · 결제 위젯은 완전 ignore

Privacy 규제

6편 GDPR · KISA 관점에서 Session Replay 는 고위험 영역이에요.

• 명시적 동의 (consent banner — 동의 배너) 필수
• PII(개인 식별 정보) 마스킹 사후 검증
• 유럽 / 한국 사용자 는 강한 통제
• 데이터 처리 위탁 계약 명시

운영에 넣기 전 법무 · 컴플라이언스 review 를 거쳐야 해요. 너무 가볍게 시작하면 사고로 이어져요.

비용 — Storage 부담

Session Replay = event sequence + DOM 저장. 한 사용자 5분 세션 = 약 100KB ~ 1MB.

사용자 10만 명 / 일 평균 5분 세션:
  - 일 100,000 × 500KB = 50GB
  - 월 = 1.5TB
  - 90일 retention = 4.5TB

여기서 retention(보관 기간) 이 길수록 storage 가 기하급수로 늘어요. Sampling(표본 추출) 이 사실상 필수고, 모든 세션을 record 하는 회사는 없다고 봐도 돼요.

운영 권장 — Sampling

// 5% sample
sessionReplay.start({
  sampleRate: 0.05,
  // 또는 조건부:
  conditionalRecord: (user) => {
    return user.tier === "premium"      // VIP 만
      || user.country === "KR"           // 특정 국가
      || isInActiveExperiment(user);     // 실험 참여자
  }
});

전략:

• 문제 발생 가능성 높은 사용자 우선 (신규 가입 · 실험 group)
• VIP 사용자 (분석 가치 ↑)
• 에러 발생 사용자 (CS 대응)
• 그 외 5~10% sample

Web Analytics — GA 의 대안 / 보완

Web Analytics 가 답하는 질문

• 방문자 수 · 페이지뷰 · 세션 통계
• traffic source (검색 · referral · direct · 광고)
• 페이지별 인기 · 체류시간
• 디바이스 · 브라우저 분포

일반적인 웹 분석 도구의 Statsig 버전이에요. GA · Adobe Analytics · Plausible 같은 도구의 대체재로 보면 돼요.

GA · Adobe 와의 차이

Statsig Web Analytics 의 진짜 가치

별도 도구가 아닌 Statsig 의 다른 4 축과 한 데이터.

[GA 별도 운영 시]:
  Web Analytics → GA dashboard
  Feature Flag → Statsig
  Experiment → Statsig
  → 연결 분석 = SQL join 부담

[Statsig Web Analytics]:
  웹 traffic + Feature Flag + Experiment = 한 dashboard
  → cross-축 query 자연스러움

7편 통합 view 에서 봤던 별도 도구 stitching 부담을 피하는 자리예요.

자동 추적 항목

대부분 web analytics 가 최소 코드로 자동 수집:

• Page Views — pageview 자동
• Sessions — 시작/종료 자동
• Traffic Source — referrer + UTM 자동
• Geo — IP 기반 국가/도시
• Device — User Agent 자동
• Outbound Clicks — 외부 링크 클릭
• Form Interactions — form 제출

Statsig SDK 하나로 자동 수집되니 추가 코드가 거의 안 들어요.

도입 결정 — GA 와 병행 vs 대체

GA 와 병행 (권장 시작):

- GA 는 그대로 (마케팅팀 · SEO)
- Statsig Web Analytics 추가 → 실험 결합 분석
- 6개월 평가 후 결정

Statsig 만 사용 (큰 결단):

- GA 종료
- 모든 분석 = Statsig 통합
- 마케팅팀 · SEO 도 Statsig 학습 필요

대부분 회사가 가는 길은 GA + Statsig 병행이에요. 마케팅 분석은 GA, 제품 실험과 Web 결합 분석은 Statsig 로 나누면 안전해요.

Infra Analytics — OpenTelemetry 깊이

4 축 중 가장 새로운 자리

1편 에서 본 4 축 중 4번째가 Infra Analytics 예요. Datadog · New Relic · Grafana 같은 인프라 모니터링 영역에 Statsig 가 들어온 셈이에요.

Collect metrics and traces through OpenTelemetry (OTEL). — 공식 docs

핵심은 OpenTelemetry 호환이에요. 별도 SDK 없이 기존 OTel 운영을 그대로 두고 Statsig 를 sink(수신처) 로 붙이면 돼요.

OpenTelemetry 의 의미

OpenTelemetry (OTel) = 모니터링 데이터의 표준. CNCF(클라우드 네이티브 컴퓨팅 재단) 의 graduated project 예요.

3 신호 = Metrics · Traces · Logs.

Application
   ↓ OpenTelemetry SDK
   ↓ (표준 wire format)
[OTel Collector]
   ↓ (분배)
   ├─ Datadog
   ├─ Jaeger
   ├─ Grafana
   └─ Statsig            ← 4 축 통합

SDK 는 한 번 설치하고, destination 은 여러 개로 나눠요. 벤더 lock-in 을 피하는 구조예요.

데이터 모델

Metric — 수치 시계열 (CPU · 메모리 · 응답 시간 · 에러 율).

http.server.duration{
  http_method="GET",
  http_status_code=200,
  service="checkout"
} = 142ms (p99)

여기서 p99 는 응답 시간 중 상위 1% 만 빼고 본 가장 느린 값이에요.

Trace — 분산 시스템의 request 흐름.

[GET /checkout]   (span 1: API gateway, 5ms)
  └─ [DB query]   (span 2: PostgreSQL, 50ms)
  └─ [Payment]    (span 3: external API, 80ms)
  Total: 142ms

span(스팬) 은 trace 안의 개별 작업 단위예요.

Log — text 로그 (printf · structured).

2026-05-17T09:00:00Z INFO checkout completed user=user-123 amount=50000

Statsig Infra Analytics 의 도구

통합 가치 — Product + Infra 결합

이 자리가 Statsig 의 진짜 차별점이에요.

[전통 도구 분리]:
  - 제품 메트릭 (전환율) → Mixpanel
  - 인프라 메트릭 (응답시간) → Datadog
  - 결합 분석 = 사람이 두 dashboard 비교

[Statsig 4 축 통합]:
  Feature Flag "new_recommendation_algo" 켜는 순간
    ↓
  ✓ 제품: 결제 전환율 +5% (Product Analytics)
  ✗ 인프라: API p99 latency +200ms (Infra Analytics)
  → 동시 확인 가능
  → trade-off 결정: ship vs 더 최적화

의도하지 않은 인프라 영향까지 자동으로 잡혀요. 실험의 진짜 효과를 그제야 측정할 수 있어요.

OTel 도입 예제

# OpenTelemetry Collector config
receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:
  attributes:
    actions:
      - key: environment
        value: production
        action: upsert

exporters:
  otlphttp/statsig:
    endpoint: https://otel.statsig.com
    headers:
      "STATSIG-API-KEY": "${STATSIG_OTEL_KEY}"
  datadog:
    api:
      key: ${DD_API_KEY}

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch, attributes]
      exporters: [otlphttp/statsig, datadog]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp/statsig, datadog]

OTel Collector 가 Statsig 와 Datadog 으로 동시에 보내요. 기존 monitoring 을 유지하면서 Statsig 를 얹는 구조예요.

Application 측 (Java 예제)

import io.opentelemetry.api.OpenTelemetry;
import io.opentelemetry.api.metrics.Meter;
import io.opentelemetry.api.metrics.LongCounter;

public class CheckoutService {
    private final LongCounter checkoutCounter;

    public CheckoutService(OpenTelemetry otel) {
        Meter meter = otel.getMeter("com.example.checkout");
        this.checkoutCounter = meter
            .counterBuilder("checkout.requests")
            .setDescription("Number of checkout requests")
            .build();
    }

    public void processCheckout(...) {
        // 비즈니스 로직
        checkoutCounter.add(1, attributes);
    }
}

OTel 표준 API 라 Statsig 의 vendor-specific SDK 가 코드에 박히지 않아요. 나중에 벤더를 바꿔도 자유로워요.

Infra Alert 설정

alert: "API latency degraded"
condition:
  metric: http.server.duration.p99
  threshold: 500ms
  duration: 5min
notification:
  - slack: "#ops-alerts"
  - pagerduty: "checkout-team"

7편 모니터링 통합 에서 본 Datadog · PagerDuty 결합 그대로예요.

부수 기능 통합 view — 4 축 + 3 부수

1편의 4 축 + [3 부수] = 종합 분석 능력:

case 1: 실험 결과의 multi-dimensional 분석

실험: "새 결제 flow"
  ↓ Statsig Experiment (4편)
  결과: 결제율 +5%, p < 0.01
  ↓ Product Analytics (5편)
  단계별 funnel: cart → checkout 의 drop ↓
  ↓ Session Replay (8편)
  20% sample 영상: 새 UI 가 명확
  ↓ Infra Analytics (8편)
  API latency 변화 없음
  ↓ Web Analytics (8편)
  전반적 traffic 영향 없음
  ↓
종합 결정: SHIP (모든 축 안전)

case 2: 사고 분석

metric alert: "checkout error rate spike"
  ↓ Infra Analytics (8편)
  Log Explorer: 특정 endpoint 의 500 에러
  ↓ Audit Log (7편)
  최근 변경: Feature Gate "new_db_query" 50% rollout
  ↓ Session Replay (8편)
  영향 사용자 영상: 결제 버튼 hang
  ↓ Statsig (3편)
  즉시 Gate OFF
  ↓ Product Analytics (5편)
  복구 후 funnel 정상 확인

한 플랫폼에서 발견 → 진단 → 수정 → 검증의 전 흐름이 끊기지 않고 이어져요.

도입 우선순위 — 3 부수 기능

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

단계 1: 메인 4 축 + 핵심 통합 (1~6편)

여기까지가 대부분 회사가 정착하는 자리예요. 추가 도입을 안 해도 무리가 없어요.

단계 2: Infra Analytics (백엔드 회사)

환경: 백엔드 서비스 운영
기존 도구: Datadog · New Relic · Grafana
도입 가치: 제품 + 인프라 통합 (실험의 infra 영향 자동)
도입 비용: OTel collector 기존 운영 시 낮음
권장: 백엔드 회사는 도입 권장

단계 3: Session Replay (UX 중심 + privacy 인프라 갖춤)

환경: 웹/모바일 사용자 경험 중요한 회사
기존: 사용자 행동 분석 부족
도입 가치: 실제 사용 영상으로 funnel · 실험 디버그
도입 비용: storage + privacy 인프라 + 법무 review
권장: PRD/UX 팀 강력한 가치 — 단 privacy 충분 검토

단계 4: Web Analytics (선택)

환경: 마케팅 분석 중요 + GA 와 분리 부담
도입 가치: 통합 view (실험 + traffic)
도입 비용: 낮음 (자동 추적)
권장: GA 와 병행 시작 → 6개월 평가 후 결정

전부 다 도입하는 게 정답은 아니에요. 우리 회사 우선순위에 맞춰 골라 넣는 방식이 맞아요.

자주 만나는 사고

사고 1: Session Replay privacy 위반

원인 — 마스킹 누락 → 비밀번호 · 카드번호 record.

해결 — maskInputs: true default + data-private 마킹 + 정기 audit(감사 점검).

사고 2: Session Replay 비용 폭증

원인 — 100% record → storage cost · network 폭증.

해결 — Sampling (5~10%) + 조건부 record (VIP · 실험 group · 에러).

사고 3: GDPR · KISA consent 누락

원인 — Session Replay 시작 시 명시 동의 없음 → 규제 위반.

해결 — consent banner 통합 (Cookiebot · OneTrust 등) + 거부 시 자동 OFF.

사고 4: Web Analytics 와 GA 의 수치 불일치

원인 — 두 도구의 수집 방식 차이 (sampling · bot 필터 · timezone).

해결 — 수치 자체보다 추세를 비교해요. 절대값을 맞추려고 하면 답이 안 나와요.

사고 5: OTel 의 cardinality 폭증

원인 — Metric label 에 user_id · request_id 같은 high cardinality(값 종류 수) 박음.

해결 — 5편 Cardinality 통제 와 같아요. label 은 분류 가능한 카테고리로만 잡아요.

사고 6: OTel collector 단일 실패점

원인 — Collector down → 모든 metric · trace 손실.

해결 — Collector HA(고가용성, 다중 인스턴스) · 또는 agent + central collector 패턴.

사고 7: Infra alert 노이즈

원인 — 너무 민감한 threshold → 매일 수십 alert.

해결 — threshold 조정 + anomaly detection(이상치 감지) + suppression(억제) 시간.

사고 8: Session Replay 검색 어려움

원인 — 영상 수십만 개 중 특정 사용자 · 특정 이벤트 찾기 어려움.

해결 — event 와 영상을 link 해요. 5편에서 event 박을 때 session ID 를 같이 넣어두면 영상으로 jump 돼요.

운영 권장 패턴

Pattern 1: 점진 Session Replay 도입

Week 1-2: 5% sample 시작 (development · staging 우선)
Week 3: privacy 마스킹 audit
Week 4: production 5% sample + consent 통합
Month 2-3: 조건부 record (VIP · 에러 · 실험)
Month 4+: 사용 case 별 확장 + 비용 모니터링

안전하게 시작해서 천천히 넓혀가는 방식이에요.

Pattern 2: OTel collector 표준 셋업

[Application]
   ↓ OpenTelemetry SDK (vendor-neutral)
[OTel Collector]
   ↓ batch + attributes processor
[Multi destination]
   ├─ Statsig (4 축 통합)
   ├─ Datadog (기존)
   └─ Grafana Cloud (백업)

벤더 lock-in 을 피하면서 Statsig 를 점진 도입할 수 있는 자리예요.

Pattern 3: 결제 사고 대응 playbook

1. Infra Alert (latency · error rate)
   ↓
2. Statsig audit log 확인 (최근 gate · experiment 변경)
   ↓
3. 의심 gate 즉시 OFF (3편)
   ↓
4. Session Replay 의 영향 사용자 영상 확인
   ↓
5. Log Explorer 의 에러 detail
   ↓
6. 수정 PR + 다음 실험 재시작

부수 기능이 사고 대응의 핵심 도구가 되는 흐름이에요.

Pattern 4: Experiment + Multi-dim 검증

실험 종료 시 확인 dashboard:
  - Primary metric (4편) — 통계 유의?
  - 6 차트 (5편) — funnel · retention 영향?
  - Session Replay sample — 의도 행동?
  - Infra metric — latency · error 부작용?
  - Web Analytics — traffic 분포 정상?

5 축이 모두 GREEN 이어야 안전하게 SHIP 해요.

Pattern 5: 비용 modulating

초기: Session Replay 5% sample · 30일 retention
운영: 데이터 양 모니터링
조정:
  - 비용 < 예산 → sample 늘림 (10%)
  - 비용 > 예산 → retention 단축 (14일)
  - 가치 = 비용 trade-off 정기 검토

부수 기능은 비용 통제가 운영의 핵심이에요.

시험 직전 한 번 더 — 부수 기능 종합 함정 압축 노트

• 3 부수 기능 = Session Replay · Web Analytics · Infra Analytics
• 메인 4 축 (1편) 의 보완, 모든 회사가 즉시 필요는 X
• Session Replay:
• rrweb 기반, DOM event sequence 저장 (영상 X)
• 영상 대비 크기 1/100, 검색 가능
• 답 = "왜 사용자가 funnel 에서 빠지는가", "실험 결과 원인", "사용자 신고 reproduce"
• Privacy 마스킹 필수 — maskInputs: true default, data-private, .sensitive
• GDPR · KISA = consent + 마스킹 + 법무 review
• storage 비용 = sample 5~10% 필수
• 조건부 record — VIP · 실험 group · 에러 발생
• Web Analytics:
• GA · Adobe 의 Statsig 버전
• 자동 추적 = Page Views · Sessions · Traffic Source · Geo · Device · Outbound · Forms
• Statsig 가치 = 실험 + traffic 통합 view
• 대부분 = GA 와 병행 시작 → 6개월 평가
• Infra Analytics:
• OpenTelemetry (OTel) 호환 핵심
• OTel = CNCF 표준, vendor-neutral
• 3 신호 = Metrics · Traces · Logs
• 도구 = Log Explorer · Alerts · Metrics Explorer
• 통합 가치 = 제품 + 인프라 한 dashboard
• OTel collector = multi-destination (Statsig + Datadog 동시)
• OTel SDK = Application 측 표준 (vendor lock-in 회피)
• 4 축 + 3 부수 통합 분석:
• 실험 multi-dim 검증 (Primary metric + 6 차트 + Session Replay + Infra)
• 사고 분석 (Alert → Audit → Gate OFF → Replay → Log)
• 도입 우선순위:
• 단계 1 = 메인 4 축 + 핵심 통합 (1~7편)
• 단계 2 = Infra Analytics (백엔드 회사)
• 단계 3 = Session Replay (UX 중심 + privacy 갖춤)
• 단계 4 = Web Analytics (선택)
• 함정 — Session Replay privacy 위반 (마스킹 누락)
• 함정 — Session Replay 비용 폭증 (Sampling 필수)
• 함정 — GDPR consent 누락
• 함정 — Web Analytics vs GA 수치 불일치 (수치보단 추세)
• 함정 — OTel cardinality 폭증 (label 통제)
• 함정 — OTel collector 단일 실패점 (HA)
• 함정 — Infra alert 노이즈 (threshold 조정 · anomaly · suppression)
• 함정 — Session Replay 검색 어려움 (event 와 session ID link)
• 패턴 — 점진 Session Replay (5% → 조건부 → 확장)
• 패턴 — OTel collector multi-destination
• 패턴 — 결제 사고 대응 playbook (Alert → Audit → Gate OFF → Replay → Log)
• 패턴 — Experiment 5 축 검증 dashboard
• 패턴 — 비용 modulating 정기 검토

공식 문서: Session Replay · Infra Analytics 에서 원문을 확인할 수 있어요.

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

이전 글:

• 3편 — Feature Flags 깊이 · Targeting · Rollout · Holdout
• 4편 — Experiments 깊이 · RCT · Allocation · 통계 함정
• 5편 — Product Analytics 깊이 · 6 차트 · Funnel · Retention
• 6편 — Warehouse Native 깊이 · Snowflake · BigQuery · dbt 결합
• 7편 — CDP · Slack · MCP · Webhook 운영 통합

다음 글:

• 9편 — 시리즈 마무리 · 도입 결정 · 경쟁 도구 · 학습 경로