analysis-methodology

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.