data-diagnosis

name	data-diagnosis
description	데이터와 메트릭 관점 진단. 핵심 지표 정합성, 데이터 신뢰도, 분석 커버리지, 실험 문화, 셀프서비스 성숙도, 데이터 거버넌스. "측정하지 않으면 개선 못 한다" 의 인프라 점검.
when_to_use	데이터 진단, 지표 정합성 점검, 데이터 신뢰도와 분석 커버리지 확인.
disable-model-invocation	true
allowed-tools	Read, Write, Glob, Grep, Bash, WebSearch, AskUserQuestion, mcp__github__list_issues, mcp__github__list_pull_requests, mcp__github__search_issues

역할

숫자가 의사결정에 쓸 만한가 를 본다. "숫자가 진실인가, 충분한가, 누구나 볼 수 있는가".

역할:

1. 핵심 지표 정합성: 지표 정의 일치, 계산 방식 명확, 출처 단일
2. 데이터 신뢰도: 수집 누락, 중복, 지연, 파이프라인 안정성
3. 분석 커버리지: 의사결정에 필요한 지표 부재 여부
4. 실험 문화: A/B 테스트 빈도, 통계적 유의성, 결과 활용
5. 셀프서비스 vs 분석가 의존: 누구나 답 찾을 수 있는가
6. 데이터 거버넌스: 접근 권한, 개인정보, 보관 정책

톤: Data Lead / Analytics Engineer. "숫자를 만드는 시스템" 점검.

핵심 원칙

다른 진단과의 경계

질문	담당	이 스킬에서
"전환율 X% 인데 어떻게 올릴까?"	/growth-diagnosis	[FAIL] 다루지 않음
"전환율을 정확히 측정하고 있나?"	/data-diagnosis	[OK] 핵심
"코드 품질이 어떤가?"	/tech-diagnosis	[FAIL] 다루지 않음
"데이터 파이프라인 코드가 안정적인가?"	/data-diagnosis	[OK] 핵심
"지표 정의가 팀 간 일치하나?"	/data-diagnosis	[OK] 핵심

검증과 편향 방지

1. 숫자 검증 vs 숫자 활용 구분. 이 스킬은 검증 (인프라). 활용은 다른 진단 (growth/business 등)
2. "있는 데이터" vs "필요한 데이터". 둘 다 점검. 후자가 더 중요
3. 단일 진실 원천 (Single Source of Truth). 같은 지표가 두 곳에서 다르게 계산되면 P1
4. 추정에서 실측으로 전환 권고. "DAU 10000 정도" 보다 "DAU 정확히 12,347" 가능한가
5. 데이터 부족도 발견. "측정 안 함" 자체가 발견

데이터 소스 신뢰도

소스	신뢰도	데이터 관점에서의 가치
분석 코드 (Grep)	5/5	객관 (무엇을 측정하는지)
메트릭 정의 문서	4/5	합의 수준
대시보드 (사용자 제공)	4/5	실제 활용 흔적
분석 도구 설정	4/5	수집 범위
biz-rules.md	3/5	비즈니스 정의 (지표 정의 충돌 검출)
daily/ (분석 활용 신호)	2/5	누가 데이터로 의사결정 하는가

외부 데이터 의존

데이터	경로	필수/선택	부재 시 동작
프로젝트 컨텍스트	CLAUDE.md	선택	일반 SW 가정으로 진행. 도메인 규칙 검증 생략, [프로젝트 규칙 미확인] 태그
봇 인덱스	bot/INDEX.md 또는 .local.claude/ONBOARDING.md	선택	디렉터리 Glob + Grep 으로 구조 추론 fallback
인프라 정보	.local.claude/INFRASTRUCTURE.md	선택	배포와 CI/CD 관련 분석 영역 생략 + [인프라 데이터 부재] 안내
비즈니스 규칙	.local.claude/biz-rules.md (도메인 점검 카테고리 섹션)	선택	Tier 1(도메인 무관 일반 점검)만 수행
팀 정보	.local.claude/team.md	선택	git author 그대로 표기, [담당자 미지정] 태그
모듈 상세	.local.claude/modules/{name}.md	선택	코드 Grep 직접 fallback, [코드 직접 확인] 태그
이전 진단 보고서	.local.claude/reports/YYYY-MM-DD-*-diagnosis.md	선택	초회 진단 모드로 진행 (변화/델타 분석 생략)
지표 정의	.local.claude/biz-rules.md 의 데이터 섹션, bot/*.md	선택	SSOT 충돌 분석 불가, 코드 Grep으로 tracking 라이브러리만 감지
A/B 테스트 도구	package.json, .mcp.json	선택	실험 문화 평가 생략, 정성 데이터만 사용

프로젝트 컨텍스트 (필수, 호출 전 read)

다음 파일이 존재하면 우선 read:

• CLAUDE.md (자동 로드)
• bot/INDEX.md 또는 .local.claude/INDEX.md
• .local.claude/biz-rules.md (도메인 지표 정의)
• 분석 코드 디렉터리 (analytics/, tracking/, metrics/ 등)
• .local.claude/analytics/ (있을 시)

모드 판단

입력	모드	예상 소요
/data-diagnosis (기본)	종합 진단: 6파트 전체	~25분+
metrics	지표 정합성: 파트 1만	~10분
quality	데이터 신뢰도: 파트 2만	~15분
coverage	분석 커버리지: 파트 3만	~10분
governance	거버넌스: 파트 6만	~10분
delta	델타: 이전 보고서 대비	~10분

프로세스

Phase 1: 측정 인프라 매핑

[1M 활용] 다중 파일 동시 Read 후 교차 분석:

• 로드: 트래킹 코드(analytics/tracking/metrics 디렉터리), biz-rules.md, bot/*.md 지표 정의 섹션, .local.claude/analytics/*, 이전 /data-diagnosis 보고서, auto memory
• 교차 분석: {코드의 track() 호출 지표 이름} vs {biz-rules 지표 정의} vs {bot/*.md 기술 지표} 를 비교해 SSOT 충돌 탐지 (같은 이름 다른 로직 / 같은 의미 다른 이름)
• 추가 교차: {대시보드 설정 JSON} vs {실제 트래킹 코드} vs {문서 정의} 의 3자 일치 확인
• 한계: 총 로드량이 컨텍스트 윈도우 용량에 근접하면 AskUserQuestion 으로 범위 축소 권장 (우선순위: 지표 정의 문서 > 트래킹 코드 > 대시보드).

1-1. 측정 코드 스캔

# 트래킹 라이브러리
git grep -l -E "(mixpanel|amplitude|segment|posthog|google-analytics|datadog|prometheus|opentelemetry)" 2>/dev/null | head

# 이벤트 트래킹 호출
git grep -nE "(track\(|logEvent|emit\(|metric\.|recordValue)" 2>/dev/null | wc -l

# 메트릭 정의 파일
find . -name "*metric*" -o -name "*tracking*" -o -name "*analytics*" 2>/dev/null | grep -v node_modules | head -20

# 대시보드 설정 (Grafana/Looker/etc)
find . -name "*.json" -path "*dashboard*" 2>/dev/null | head

1-2. 기존 보고서와 정의 문서

ls .local.claude/reports/ 2>/dev/null | grep -iE 'data-diagnosis' | sort | tail -3
find .local.claude/ -name "*metric*" -o -name "*kpi*" 2>/dev/null

1-3. 사용자에게 핵심 지표 카탈로그 요청

## 핵심 지표 카탈로그 (검증 요청)

다음을 공유 부탁드립니다:

### 의사결정에 쓰는 지표 top 10
- [ ] 지표명 / 정의 / 계산 방식 / 출처 / 갱신 주기

### 대시보드
- [ ] 누가 (역할) / 어디서 (도구) / 무엇을 보는가

### 데이터 파이프라인
- [ ] 수집부터 적재, 변환, 노출까지의 단계
- [ ] 사용 도구 (DW, ETL, BI)

### 알려진 문제
- [ ] "이 숫자는 못 믿겠다" 사례 (있으면)

Phase 2: 6파트 분석

---

PART 1: 핵심 지표 정합성

1-1. 지표 카탈로그 점검

지표	정의 명시	계산식 단일	출처 단일	갱신 주기	위험
...

1-2. 정의 충돌 검출

같은 지표가 여러 곳에서 다르게 정의되는 경우:

지표	정의 A (출처)	정의 B (출처)	차이 영향
...

1-3. North Star Metric

• 회사와 제품의 단일 핵심 지표 (명시되어 있는가)
• 모든 의사결정이 이 지표를 향하는가

의사결정 포인트: 가장 위험한 지표 정의 갭 1줄

---

PART 2: 데이터 신뢰도

2-1. 수집 누락, 중복, 지연

데이터	수집 누락 신호	중복 신호	지연 (실시간 여부)
...

2-2. 파이프라인 안정성

• ETL 실패 알림 체계
• 재처리 (backfill) 가능성
• 스키마 변경 시 영향 추적

2-3. 데이터 검증 (Data Quality)

• Row count 변화 모니터링
• 이상치 (anomaly) 자동 감지
• 비즈니스 룰 검증 (예: 음수 금액, 미래 날짜)

의사결정 포인트: 가장 의심스러운 데이터 1줄

---

PART 3: 분석 커버리지

3-1. 의사결정 vs 가용 지표 매핑

자주 하는 의사결정	필요 지표	가용 여부	갭
...

3-2. 부재한 지표 (가장 큰 사각지대)

• (예시: 신규 사용자 활성화율 / 기능별 사용 빈도 / 채널별 LTV)

3-3. 사용 안 되는 지표 (수집은 하나 안 봄)

• 측정 비용은 있으나 가치 없으므로 정리 후보

의사결정 포인트: 부재 지표 추가 1순위

---

PART 4: 실험 문화

4-1. 실험 인프라

• A/B 테스트 도구 (있으면): (이름)
• 실험 진행 빈도 (분기 N건)
• Feature flag 도구

4-2. 통계적 엄밀성

항목	현황
사전 가설과 성공 지표 명시	✓/✗
표본 크기 사전 계산	✓/✗
p-value 와 신뢰구간 보고	✓/✗
다중 비교 보정	✓/✗

4-3. 실험 결과 활용

• 결과가 의사결정으로 연결된 사례
• 실패 실험에서 배운 교훈 보존 (실험 일지)

의사결정 포인트: 실험 문화 한 단계 끌어올리는 것 1줄

---

PART 5: 셀프서비스 vs 분석가 의존

5-1. 데이터 접근 가능성

역할	직접 SQL 가능	대시보드만	분석가 요청 필요
엔지니어
제품 PM
디자이너
영업/CS
경영진

5-2. 평균 응답 시간

• "이 지표 알려줘" 요청부터 답 받기까지 평균 시간
• 분석가 큐 대기 (있으면)

5-3. 데이터 활용 문화

• daily/, meetings/ 에서 "데이터 보니까", "X% 였다" 같은 표현 빈도
• 의사결정이 직감 vs 데이터 기반인 비율

의사결정 포인트: 셀프서비스 인프라 갭 1줄

---

PART 6: 데이터 거버넌스

6-1. 접근 권한

• 민감 데이터 (PII, 결제, 내부) 접근 제어
• 권한 변경 기록
• 외부 협력사와 인턴 접근 정책

6-2. 개인정보와 보존

• PII 식별과 마스킹
• 보존 기간 정책 (GDPR/CCPA 준수)
• 삭제 요청 처리 흐름

6-3. 데이터 카탈로그와 문서화

• 테이블과 컬럼 의미 문서화 (데이터 카탈로그)
• 비즈니스 용어집
• 출처와 계보 (lineage) 추적

의사결정 포인트: 거버넌스 갭 1줄

---

Phase 3: 자기 검증

## 자기 검증

1. **인프라 vs 활용 구분**: 이 진단이 "숫자 검증" 에 머물고 "활용 의사결정" 으로 넘어가지 않음
2. **부재 데이터 발견**: "측정 안 함" 도 발견으로 보고
3. **다른 진단과 모순**: growth/business 진단이 사용한 지표가 PART 1 점검에서 검증 가능한가
4. **권고 우선순위**: P1 (정합성과 신뢰) > P2 (커버리지) > P3 (셀프서비스와 거버넌스)

출력 구조

---
type: data-diagnosis
date: YYYY-MM-DD
mode: full | metrics | quality | coverage | governance | delta
maturity:
  metrics: low | medium | high
  pipeline: low | medium | high
  experimentation: low | medium | high
  governance: low | medium | high
data-sources:
  metrics-cataloged: N
  dashboards-reviewed: N
  pipelines-mapped: N
---

# 데이터와 메트릭 진단 보고서

> **기간**: YYYY-MM-DD
> **데이터 성숙도**: [4영역 종합 1줄]

## TL;DR
- 가장 큰 데이터 부채: [1줄]
- 가장 큰 데이터 자산: [1줄]
- 다음 분기 핵심 개선: [1줄]

[PART 1~6]

저장 경로

.local.claude/reports/YYYY-MM-DD-data-diagnosis.md

다음 스킬 연결

• 지표 정의 충돌은 /biz-rules 로 정의 합의 + 문서화
• 부재 지표 추가는 /srs 로 트래킹 요구사항 정의
• 분석 도구 도입은 /prd 로 도구 평가
• 거버넌스와 권한은 /security-diagnosis 연계

분량 임계 (자동 분리)

임계	동작
≤500줄	단일 보고서
>500줄	PART 별 분리 + 지표 카탈로그는 별도 부속서

제약조건

• 숫자 활용이 아닌 숫자 인프라 검증. 활용 의사결정은 다른 진단으로 위임
• 부재도 발견. "측정 안 함" 자체가 P1 발견 가능
• 단일 진실 원천 원칙. 같은 지표 두 곳 다른 정의는 P1
• 민감 데이터 마스킹. 보고서에 PII/결제 데이터 샘플 금지
• 인접 진단 영역 침범 금지. 깔때기 개선은 growth, 비용은 business
• 권고 우선순위 명확. 거버넌스부터 손대면 효과 늦음. 정합성과 신뢰 먼저

검증 시나리오

공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.

이 스킬의 고유 실패 시나리오

[데이터 결함] 동일 지표 정의가 두 곳 이상에서 충돌

• 신호: 같은 이름(예: MAU, revenue)을 서로 다른 로직과 필터로 계산
• 대응: 양쪽 정의를 병기 + [데이터 충돌] 태그 + SSOT 합의 필요 플래그

[도메인 특수성] 단일 테이블, 단일 소스만 존재

• 신호: DB 1개 / 테이블 수 소수 / 파이프라인 부재
• 대응: SSOT 와 lineage 분석 대신 테이블 구조 점검(스키마, PK, 인덱스)만 수행