Menú
데이터와 메트릭 관점 진단. 핵심 지표 정합성, 데이터 신뢰도, 분석 커버리지, 실험 문화, 셀프서비스 성숙도, 데이터 거버넌스. "측정하지 않으면 개선 못 한다" 의 인프라 점검.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
지정 디렉터리의 문서를 심층 분석하여 지식을 추출하고, 기존 문서 갱신 + 신규 문서 생성으로 프로젝트 지식 베이스에 반영합니다.
기술 의사결정 기록 (Architecture Decision Record). 중요한 기술적 결정의 맥락, 대안, 근거를 구조화하여 기록합니다.
현재 디렉터리의 내용을 분석하여 어떤 목적의 폴더인지 파악
슬랙/메일/메신저로 받은 업무 요청 메시지를 분석하여 의도, 핵심 내용, 판단, 액션 플랜, 대응 가이드를 정리합니다.
비즈니스 규칙, 도메인 규칙, 상태 전이 규칙을 하나의 문서로 관리합니다. 변경 이력이 누적됩니다.
열린 질문, 문제 해결, 기술 의사결정, 아이디어 발산을 구조화합니다. 회의록이나 메모 파일 경로를 인자로 전달하거나 직접 질문하세요.
| 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 |
숫자가 의사결정에 쓸 만한가 를 본다. "숫자가 진실인가, 충분한가, 누구나 볼 수 있는가".
역할:
톤: Data Lead / Analytics Engineer. "숫자를 만드는 시스템" 점검.
| 질문 | 담당 | 이 스킬에서 |
|---|---|---|
| "전환율 X% 인데 어떻게 올릴까?" | /growth-diagnosis | [FAIL] 다루지 않음 |
| "전환율을 정확히 측정하고 있나?" | /data-diagnosis | [OK] 핵심 |
| "코드 품질이 어떤가?" | /tech-diagnosis | [FAIL] 다루지 않음 |
| "데이터 파이프라인 코드가 안정적인가?" | /data-diagnosis | [OK] 핵심 |
| "지표 정의가 팀 간 일치하나?" | /data-diagnosis | [OK] 핵심 |
| 소스 | 신뢰도 | 데이터 관점에서의 가치 |
|---|---|---|
| 분석 코드 (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:
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분 |
[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)
### 알려진 문제
- [ ] "이 숫자는 못 믿겠다" 사례 (있으면)
| 지표 | 정의 명시 | 계산식 단일 | 출처 단일 | 갱신 주기 | 위험 |
|---|---|---|---|---|---|
| ... |
같은 지표가 여러 곳에서 다르게 정의되는 경우:
| 지표 | 정의 A (출처) | 정의 B (출처) | 차이 영향 |
|---|---|---|---|
| ... |
의사결정 포인트: 가장 위험한 지표 정의 갭 1줄
| 데이터 | 수집 누락 신호 | 중복 신호 | 지연 (실시간 여부) |
|---|---|---|---|
| ... |
의사결정 포인트: 가장 의심스러운 데이터 1줄
| 자주 하는 의사결정 | 필요 지표 | 가용 여부 | 갭 |
|---|---|---|---|
| ... |
의사결정 포인트: 부재 지표 추가 1순위
| 항목 | 현황 |
|---|---|
| 사전 가설과 성공 지표 명시 | ✓/✗ |
| 표본 크기 사전 계산 | ✓/✗ |
| p-value 와 신뢰구간 보고 | ✓/✗ |
| 다중 비교 보정 | ✓/✗ |
의사결정 포인트: 실험 문화 한 단계 끌어올리는 것 1줄
| 역할 | 직접 SQL 가능 | 대시보드만 | 분석가 요청 필요 |
|---|---|---|---|
| 엔지니어 | |||
| 제품 PM | |||
| 디자이너 | |||
| 영업/CS | |||
| 경영진 |
의사결정 포인트: 셀프서비스 인프라 갭 1줄
의사결정 포인트: 거버넌스 갭 1줄
## 자기 검증
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 별 분리 + 지표 카탈로그는 별도 부속서 |
공통 3블록(빈 / 부분 / 풀 데이터)은 CONTRACT 6-1절 참조.
[데이터 결함] 동일 지표 정의가 두 곳 이상에서 충돌
[데이터 충돌] 태그 + SSOT 합의 필요 플래그[도메인 특수성] 단일 테이블, 단일 소스만 존재