| name | analysis-methodology |
| description | Data analysis methodology — how to frame a question, pick the right technique, avoid statistical traps, and connect results to decisions. NOT a tool tutorial (pandas/polars/duckdb live in python-data-analysis) — this is the judgment layer: problem framing, analysis-type decision tree, experiment/causal design, and domain playbooks (churn, cohort, funnel, anomaly). Trigger: "왜 늘었/줄었지", 이탈 분석, 코호트, 퍼널, A/B 테스트, 인과추론, 상관 vs 인과, 유의성, 세그먼트, 이상 탐지, "이 데이터로 뭘 봐야", 지표 설계, exploratory analysis.
|
| origin | custom |
| workloads | ["python-data"] |
Data Analysis Methodology
분석의 어려움은 pandas 문법이 아니라 **"무엇을·왜 보고, 결과를 어떻게 믿고,
의사결정에 어떻게 연결하나"**다. 이 스킬은 그 판단 층을 다룬다. 실제 코드(pandas·
polars·duckdb·plotting)는 python-data-analysis 로 위임한다 — 여기서 중복하지 않는다.
When to Activate
- "왜 늘었/줄었지" 류의 원인 규명, 이탈·코호트·퍼널·세그먼트 분석
- A/B 테스트 설계·해석, 인과추론(상관과 인과 구분)
- "이 데이터로 뭘 봐야 하나" — 문제 정의가 아직 흐릴 때
- 통계적 유의성 해석, 다중비교·표본편향 같은 함정 회피
- 지표(metric) 설계, 분석 결과를 의사결정으로 연결
순수 도구 사용법(groupby·join·parquet·차트 코드)은 python-data-analysis.
프로덕션 ML 모델링은 mle-workflow·pytorch-patterns. AWS 분석 엔진(Glue·
Athena·Redshift) 운영은 aws-lakehouse·aws-etl-cdc 스킬과 cloud 워크로드 MCP.
분석 워크플로 (프레이밍 → 접근 → 검증 → 결정)
도구를 열기 전에 이 4단계를 먼저 밟는다. 대부분의 나쁜 분석은 1단계를 건너뛴다.
1. 프레이밍 — 질문을 분석 가능하게 만든다
- 모호한 요청 → 구체 질문: "매출 봐줘" → "지난 분기 대비 이번 분기 매출이
변한 게 세그먼트 때문인가, 단가 때문인가, 물량 때문인가?"
- 의사결정을 먼저 묻는다: "이 분석으로 무슨 결정을 내릴 건가?" 결정과 무관한
분석은 하지 않는다(YAGNI). 결정이 없으면 분석 범위가 무한 발산한다.
- 성공 기준·지표를 정의: 무엇이 "올랐다/개선됐다"인지 숫자로. 방향(↑좋음/↓좋음)도.
2. 분석 유형 결정 — 무슨 기법인가
질문의 성격이 기법을 정한다. 상세 결정 트리는
references/analysis-type-decision.md.
| 질문 유형 | 예 | 접근 |
|---|
| 기술(descriptive) | "지금 상태가 어떤가" | 요약통계·분포·시계열 추세 |
| 진단(diagnostic) | "왜 이렇게 됐나" | 세그먼트 분해·드릴다운·기여도 분석 |
| 추론(inferential) | "이 차이가 진짜인가" | 가설검정·신뢰구간·효과크기 |
| 예측(predictive) | "앞으로 어떻게 될까" | 시계열 예측·회귀·분류 (→ mle-workflow) |
| 인과(causal) | "X 가 Y 를 일으켰나" | 실험·준실험 (→ experiment-design.md) |
3. 검증 — 결과를 믿기 전에
함정 체크리스트(상세는 아래 "함정" + references):
- 상관 ≠ 인과. 교란변수(confounder)를 배제했나?
- 표본이 대표성이 있나? 생존편향·선택편향은?
- 다중비교: 20개 지표를 보면 하나는 우연히 "유의"하다.
- 통계적 유의 ≠ 실질적 유의. p<0.05 라도 효과크기가 무의미하면 소용없다.
- Simpson's paradox: 전체 추세와 세그먼트별 추세가 반대일 수 있다.
4. 의사결정 연결 — so what
- 결과를 "그래서 무엇을 할 것인가"로 번역. 숫자만 던지지 않는다.
- 불확실성을 함께 전한다(신뢰구간·가정·한계). 과신은 나쁜 결정을 부른다.
- 재현 가능하게 남긴다(노트북·쿼리·가정) —
python-data-analysis 의 재현성 규약.
도메인 플레이북 (상황별 접근)
자주 나오는 분석 상황의 표준 접근. 상세는
references/domain-playbooks.md.
- 이탈(churn): 이탈 정의(언제부터 이탈?)가 먼저. 코호트별 생존곡선, 이탈 선행지표.
- 코호트(cohort): 가입 시점별로 묶어 시간에 따른 행동 변화. 리텐션 커브.
- 퍼널(funnel): 단계별 전환율·이탈 지점. 세그먼트별 퍼널 비교.
- 이상 탐지(anomaly): 무엇이 "정상"인가 기준선 먼저. 계절성·추세 분리(STL).
- 원인 규명("왜 늘었지"): 기여도 분해 — 물량×단가×믹스. 세그먼트 드릴다운.
실험·인과 설계
"진짜 X 때문인가"는 관측 데이터만으론 대개 답 못 한다. 상세는
references/experiment-design.md.
- A/B 테스트: 무작위 배정이 인과의 gold standard. 검정력 분석으로 표본 크기 먼저.
- 준실험(관측 데이터): 무작위가 불가능할 때 — DiD(이중차분)·회귀불연속·성향점수매칭.
각각 성립 가정이 있고, 가정이 깨지면 결론도 깨진다.
- 관측 분석의 겸손: 인과를 주장하기 전에 "이건 상관이고, 인과 가설은 실험으로
검증 필요"라고 명시.
함정 (analysis-specific anti-patterns)
- 데이터부터 열기 — 질문·결정 없이 groupby 부터 하면 방향 없는 탐색에 빠진다(1단계 먼저).
- p-hacking — 유의할 때까지 자르고 나누기. 가설은 데이터 보기 전에.
- 평균의 함정 — 평균만 보고 분포·꼬리·세그먼트 무시. 항상 분포를 본다.
- 차트로 결론 강요 — 축 조작·체리피킹. 정직한 시각화(→ python-data-analysis 플로팅).
- 1회성 분석 — 반복될 질문은 재현 가능한 파이프라인으로.
Related
python-data-analysis — 도구·문법·재현성(pandas/polars/duckdb/plotting). 코드는 여기로.mle-workflow · pytorch-patterns — 예측 모델링.duckdb-patterns — 큰 데이터 SQL 분석.- AWS 분석/레이크하우스는
aws-lakehouse·aws-etl-cdc 스킬과 cloud 워크로드 MCP.
