analysis-methodologylisted

# 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) 운영은 `data-analysis` 워크로드의 MCP 서버. ## 분석 워크플로 (프레이밍 → 접근 → 검증 → 결정) 도구를 열기 전에 이 4단계를 먼저 밟는다. 대부분의 나쁜 분석은 1단계를 건너뛴다. ### 1. 프레이밍 — 질문을 분석 가능하게 만든다 - **모호한 요청 → 구체 질문**: "매출 봐줘" → "지난 분기 대비 이번 분기 매출이 변한 게 세그먼트 때문인가, 단가 때문인가, 물량 때문인가?" - **의사결정을 먼저 묻는다**: "이 분석으로 무슨 결정을 내릴 건가?" 결정과 무관한 분석은 하지 않는다(YAGNI). 결정이 없으면 분석 범위가 무한 발산한다. - **성공 기준·지표를 정의**: 무엇이 "올랐다/개선됐다"인지 숫자로. 방향(↑좋음/↓좋음)도. ### 2. 분석 유형 결정 — 무슨 기법인가 질문의 성격이 기법을 정한다. 상세 결정 트리는 [references/analysis-type-decision.md](references/analysis-type-decision.md). | 질문 유형 | 예 | 접근 | |-----------|-----|------| | 기술(descriptive) | "지금 상태가 어떤가" | 요약통계·분포·시계열 추세 | | 진단(diagnostic) | "왜 이렇게 됐나" | 세그먼트 분해·드릴다운·기여도 분석 | | 추론(inferential) | "이 차이가 진짜인가" | 가설검정·신뢰구간·효과크기 | | 예측(predictive) | "앞으로 어떻게 될까" | 시계열 예측·회귀·분류 (→ mle-workflow) | | 인과(causal) | "X 가 Y 를 일으켰나" | 실험·준실험 (→ experiment-design.md) | ### 3. 검증 — 결과를 믿기 전에 함정 체크리스트(상세는 아래 "함정" + references): - 상관 ≠ 인과. 교란변수(confounder)를 배제했나? -