raw events → staging → intermediate → mart로 grain과 metric contract를 분리
DecisionOps Lab
activation lift가 유의해도 D7 재방문·환불률·세션 활동 가드레일과 데이터 품질을 통과해야 Ship할 수 있는가?
synthetic 제품 이벤트를 DuckDB SQL mart, 23개 품질 gate, A/B evidence,
D7 재방문·환불률·세션 활동의 3개 가드레일과 7개 시나리오로 검토해
Ship·Retest·Hold·Investigate memo/report로 연결한 DecisionOps workflow입니다.
질문이 바뀐 순간
이 프로젝트가 단순 분석에서 의사결정 구조로 넘어간 핵심 장면입니다.
- Key Evidence
- 23 quality checks · activation +3.97pp / p=0.000011 · D7 +0.97pp · refund -0.02pp · sessions +1.93% · 7 scenarios
- Final Deliverable
- SQL mart, quality gate, multi-guardrail experiment result, 7-scenario matrix, decision memo와 public reviewer report
- What this proves
- 하나의 성공 지표를 복수의 위험 신호와 품질 조건 안에서 검토해 재현 가능한 의사결정 언어로 바꾸는 역량
근거 스냅샷
숫자가 있는 프로젝트는 검증 지표를 먼저, 데이터가 부족한 프로젝트는 확인 가능한 산출물 중심으로 정리했습니다.
row count, null, accepted values, relation, duplicate, experiment balance 등 23/23 checks PASS
Variant A 30.15% → B 34.12% · activation +3.97pp · p-value 0.000011
48.17% → 49.14% · delta +0.97pp · PASS
0.22% → 0.20% · delta -0.02pp · PASS
평균 세션 1.814 → 1.849 · relative delta +1.93% · PASS
strong_positive=Ship · 3 guardrail risks/weak_evidence=Retest · neutral=Hold · quality_failure=Investigate
one-command runner와 GitHub Actions가 quality, experiment, matrix, memo, reviewer report를 생성
synthetic workflow이며 실제 제품 성과·사용자 행동·production business impact를 주장하지 않음
Public reviewer report
Public repository
Multi-guardrail workflow verified · 2026-07-09
Synthetic · 3 guardrails · 7 scenarios
제품 데이터 분석 · Analytics Engineering · 실험·의사결정 분석
1개 지표가 아니라 3개 가드레일과 7개 시나리오로 결정하기
synthetic 제품 이벤트를 SQL mart와 23개 품질 gate로 정리한 뒤 activation evidence를 D7 revisit, refund rate, session activity의 세 가드레일과 함께 읽고, 일곱 시나리오에서 Ship·Retest·Hold·Investigate 결정을 재현하는 분석 의사결정 workflow입니다.
activation lift만 보고 Ship하지 않기
주요 지표가 개선되어도 데이터 품질, 재방문, 환불, 사용 활동이 흔들리면 제품 결정을 그대로 밀어붙일 수 없습니다.
- quality → primary metric → guardrails 순서
- 좋은 lift도 downstream risk가 있으면 Retest
raw event를 검토 가능한 SQL layer로 분리
raw users/events/sessions/payments/experiments를 DuckDB raw, staging, intermediate, mart layer로 나누고 reviewer artifact가 mart 결과를 읽도록 구성합니다.
- mart_experiment_result
- mart_decision_summary
- mart_segment_performance
- mart_retention_cohort
실험 해석 전에 23개 품질 검사를 실행
row count, null, accepted values, referential integrity, duplicate와 experiment balance를 먼저 확인하며 quality_failure는 결과 해석 전에 Investigate로 분기합니다.
- 23/23 PASS in default case
- quality_failure=Investigate
activation 개선과 통계 근거를 확인
strong_positive 기본 사례에서 Variant B activation은 30.15%에서 34.12%로 +3.97pp 개선되며 p-value는 0.000011입니다.
- A 30.15% → B 34.12%
- +3.97pp
- 95% CI +2.14pp~+5.80pp
재방문·환불·세션 활동을 함께 검토
D7 revisit, refund rate, average sessions를 독립 가드레일로 평가해 activation 개선이 이후 행동이나 비용 신호를 악화시키지 않는지 확인합니다.
- D7 revisit delta +0.97pp · PASS
- refund rate delta -0.02pp · PASS
- avg sessions +1.93% · PASS
가드레일별 실패와 약한 근거를 별도 재현
strong_positive, guardrail_risk, refund_risk, session_activity_risk, weak_evidence, neutral, quality_failure의 일곱 조건으로 결정 규칙이 한 결과에 고정되지 않았는지 검증합니다.
- Ship: strong_positive
- Retest: 3 guardrail risks + weak_evidence
- Hold: neutral
- Investigate: quality_failure
결과를 memo·matrix·public report로 남기기
quality report, experiment result, scenario matrix, decision memo와 GitHub Pages reviewer report를 같은 실행 경로에서 생성합니다.
- one-command verification
- machine-readable JSON + reviewer-facing artifacts
synthetic workflow의 주장 범위를 유지
DecisionOps는 분석·검증·의사결정 설계 역량을 보여주는 synthetic-data workflow이며 실제 사용자 행동, 제품 성과나 production business impact를 증명하지 않습니다.
- synthetic data only
- production warehouse or live experiment operation 아님
문제와 맥락
- 주요 도메인
- 제품 분석
- 역할
- raw/staging/intermediate/mart SQL 설계 / 23개 data quality gate / A/B test evidence / D7·refund·session 3개 guardrail review / 7개 scenario decision matrix
- 기간
- 2026
- 형태
- 개인 프로젝트
제품 실험은 주요 지표가 좋아졌다는 이유만으로 바로 Ship할 수 없습니다. DecisionOps Lab은 synthetic raw events를 검토 가능한 SQL layer로 정리하고 품질 gate를 먼저 통과시킨 뒤, activation evidence를 D7 revisit·refund rate·session activity와 함께 읽어 의사결정합니다.
제품 실험의 주요 지표가 개선되어도 데이터 품질이나 D7 재방문, 환불률, 세션 활동이 악화되면 신뢰 가능한 Ship 판단으로 이어질 수 없습니다.
리뷰 가능한 의사결정 workflow는 raw data부터 SQL metric layer, 품질 gate, 통계 근거, 복수 guardrail과 최종 memo가 같은 실행 경로로 연결되어야 하기 때문입니다.
데이터와 접근
- synthetic users / events / sessions / payments / experiments
- DuckDB raw / staging / intermediate / mart tables
- quality / experiment / scenario JSON reports
- decision memo와 reviewer HTML report
- fixed seed와 scenario mode로 synthetic raw CSV 생성
- DuckDB raw, staging, intermediate, mart SQL layer로 grain과 지표 정의 분리
- 23개 quality checks를 실험 해석보다 먼저 실행
- activation lift, p-value와 confidence interval 확인
- D7 revisit, refund rate, average sessions의 세 guardrail 평가
- 일곱 시나리오에서 Ship/Retest/Hold/Investigate 규칙 재현
- decision memo, scenario matrix와 public reviewer report 생성
- 23/23 quality PASS
- activation +3.97pp · p-value 0.000011
- D7 revisit delta +0.97pp
- refund rate delta -0.02pp
- average sessions relative delta +1.93%
- 7 scenarios · Ship/Retest/Hold/Investigate
결과물
raw CSV를 DuckDB raw·staging·intermediate·mart layer로 모델링하고 23개 quality checks를 실행했습니다. 기본 strong_positive 사례에서 activation은 +3.97pp, p-value 0.000011이며 D7 revisit·refund rate·session activity가 모두 PASS입니다. 같은 pipeline을 일곱 시나리오에 적용해 Ship 1개, Retest 4개, Hold 1개, Investigate 1개 결정을 memo와 public report로 생성합니다.
핵심 포인트
- raw product events를 DuckDB SQL mart와 명시적 metric layer로 재구성
- 23개 data quality gate를 실험 해석보다 먼저 실행
- activation evidence를 D7 revisit·refund rate·session activity와 함께 검토
한계와 검토 메모
검증 범위와 추가로 확인해야 할 조건을 숨기지 않고 함께 남겼습니다.
- synthetic dataset 기반이므로 실제 제품 성과, 실제 사용자 행동과 production business impact를 주장하지 않습니다.
- 실험 결과는 workflow 검증용이며 실제 production A/B test나 인과적 사업 성과 검증이 아닙니다.
- DuckDB 기반 portfolio workflow이며 production warehouse scale, orchestration이나 live data operation을 주장하지 않습니다.
- guardrail threshold는 데모용 metric contract이며 실제 조직에서는 제품 맥락과 비용 구조에 맞춰 재합의해야 합니다.
- 세그먼트 진단은 탐색 근거이며 다중 검정 보정이나 production rollout policy를 대체하지 않습니다.
확인 가능한 산출물
공개 reviewer report, scenario matrix와 GitHub 문서에서 23개 품질 gate, 3개 guardrail, 7개 scenario decision과 synthetic claim boundary를 확인할 수 있습니다.