/validate-data - 공유 전 분석 검증
익숙하지 않은 플레이스홀더가 보이거나 연결된 도구를 확인해야 하는 경우 CONNECTORS.md를 참조하세요.
이해관계자와 공유하기 전에 분석의 정확성, 방법론, 잠재적 편향을 검토합니다. 신뢰도 평가와 개선 제안을 생성합니다.
사용법
/validate-data <검토할 분석>
분석은 다음과 같을 수 있습니다:
- 대화 내용의 문서 또는 보고서
- 파일 (마크다운, 노트북, 스프레드시트)
- SQL 쿼리 및 그 결과
- 차트 및 그 기본 데이터
- 방법론과 결과에 대한 설명
워크플로우
1. 방법론 및 가정 검토
다음을 검토합니다:
- 질문 구성: 분석이 올바른 질문에 답하고 있나요? 질문이 다르게 해석될 수 있나요?
- 데이터 선택: 올바른 테이블/데이터셋이 사용되고 있나요? 시간 범위가 적절한가요?
- 모집단 정의: 분석 모집단이 올바르게 정의되었나요? 의도하지 않은 제외는 없나요?
- 지표 정의: 지표가 명확하고 일관되게 정의되었나요? 이해관계자가 이해하는 방식과 일치하나요?
- 기준선 및 비교: 비교가 공정한가요? 기간, 코호트 크기, 컨텍스트가 비교 가능한가요?
2. 배포 전 QA 체크리스트 실행
아래 체크리스트를 실행합니다 — 데이터 품질, 계산, 합리성, 프레젠테이션 검사.
3. 일반적인 분석 함정 확인
아래 상세 함정 카탈로그(조인 폭발, 생존 편향, 불완전 기간 비교, 분모 이동, 평균의 평균, 시간대 불일치, 선택 편향)를 체계적으로 검토합니다.
4. 계산 및 집계 검증
가능한 경우, 다음을 점검합니다:
- 주요 숫자 몇 개를 독립적으로 다시 계산
- 소계가 합계와 일치하는지 확인
- 예상되는 경우 백분율이 100%에 합산되는지 확인(또는 근사값)
- YoY/MoM 비교가 올바른 기준 기간을 사용하는지 확인
- 모든 지표에 걸쳐 필터가 일관되게 적용되었는지 확인
아래 결과 타당성 검사 기법(규모 확인, 교차 검증, 위험 신호 감지)을 적용합니다.
5. 시각화 평가
분석에 차트가 포함된 경우:
- 축이 적절한 값에서 시작하는가 (막대 차트의 경우 0)?
- 비교 차트 간에 척도가 일관적인가?
- 차트 제목이 표시된 내용을 정확히 설명하는가?
- 시각화가 빠른 독자를 오도할 수 있는가?
- 축 절단, 불일치 간격, 또는 인식을 왜곡하는 3D 효과가 있는가?
6. 내러티브 및 결론 평가
다음 사항을 검토합니다:
- 결론이 제시된 데이터에 의해 뒷받침되는가?
- 대안적 설명이 인정되는가?
- 불확실성이 적절히 전달되는가?
- 권장사항이 결과에서 논리적으로 도출되는가?
- 신뢰 수준이 증거의 강도와 일치하는가?
7. 개선 사항 제안
구체적이고 실행 가능한 제안을 제공합니다:
- 결론을 강화할 추가 분석
- 언급해야 할 주의사항 또는 한계
- 핵심 사항에 대한 더 나은 시각화 또는 구성
- 이해관계자가 원할 누락된 컨텍스트
8. 신뢰도 평가 생성
3단계 척도로 분석을 평가합니다:
공유 준비 완료 -- 분석이 방법론적으로 건전하고, 계산이 검증되었으며, 주의사항이 기록됨. 개선을 위한 사소한 제안이 있으나 차단 요인은 없음.
명시된 주의사항과 함께 공유 -- 분석은 대체로 정확하지만 이해관계자에게 반드시 전달해야 할 특정 한계나 가정이 있음. 필수 주의사항을 나열합니다.
수정 필요 -- 구체적인 오류, 방법론적 문제, 또는 공유 전에 해결해야 할 누락된 분석이 발견됨. 우선순위와 함께 필요한 변경사항을 나열합니다.
출력 형식
## 검증 보고서
### 종합 평가: [공유 준비 완료 | 주의사항과 함께 공유 | 수정 필요]
### 방법론 검토
[접근 방식, 데이터 선택, 정의에 대한 결과]
### 발견된 문제
1. [심각도: 높음/중간/낮음] [문제 설명 및 영향]
2. ...
### 계산 점검
- [지표]: [확인됨 / 불일치 발견]
- ...
### 시각화 검토
[차트 또는 시각적 표현의 문제]
### 제안된 개선 사항
1. [개선 사항 및 그 중요성]
2. ...
### 이해관계자를 위한 필수 주의사항
- [반드시 전달해야 할 주의사항]
- ...
배포 전 QA 체크리스트
이해관계자와 분석을 공유하기 전에 이 체크리스트를 실행합니다.
데이터 품질 검사
- 소스 확인: 사용된 테이블/데이터 소스를 확인했습니다. 이 질문에 올바른 것들인가요?
- 최신성: 데이터가 분석에 충분히 최신입니다. "기준" 날짜를 기록했습니다.
- 완전성: 시계열이나 누락된 세그먼트에 예상치 못한 공백이 없습니다.
- Null 처리: 주요 열의 null 비율을 확인했습니다. Null이 적절히 처리되었습니다(제외, 대체, 또는 플래그 지정).
- 중복 제거: 잘못된 조인이나 중복 소스 레코드로 인한 이중 집계가 없음을 확인했습니다.
- 필터 확인: 모든 WHERE 절과 필터가 정확합니다. 의도하지 않은 제외가 없습니다.
계산 검사
- 집계 로직: GROUP BY에 모든 비집계 열이 포함됩니다. 집계 수준이 분석 세분화와 일치합니다.
- 분모 정확성: 비율 및 백분율 계산이 올바른 분모를 사용합니다. 분모가 0이 아닙니다.
- 날짜 정렬: 비교가 동일한 기간 길이를 사용합니다. 부분 기간은 제외되거나 명시됩니다.
- 조인 정확성: JOIN 유형이 적절합니다(INNER vs LEFT). 다대다 조인이 카운트를 부풀리지 않았습니다.
- 지표 정의: 지표가 이해관계자가 정의하는 방식과 일치합니다. 모든 편차가 명시됩니다.
- 소계 합계: 예상되는 경우 부분이 전체에 합산됩니다. 그렇지 않은 경우 이유를 설명합니다(예: 중복).
합리성 검사
- 규모: 숫자가 그럴듯한 범위 내에 있습니다. 수익이 음수가 아닙니다. 백분율이 0-100% 사이입니다.
- 추세 연속성: 시계열에 설명할 수 없는 급증이나 급락이 없습니다.
- 교차 참조: 주요 숫자가 다른 알려진 소스(대시보드, 이전 보고서, 재무 데이터)와 일치합니다.
- 규모 크기: 총 수익이 대략적인 범위에 있습니다. 사용자 수가 알려진 수치와 일치합니다.
- 경계 사례: 경계에서 무슨 일이 발생합니까? 빈 세그먼트, 활동 제로 기간, 새 엔티티.
프레젠테이션 검사
- 차트 정확성: 막대 차트가 0에서 시작합니다. 축에 레이블이 있습니다. 패널 간에 척도가 일관됩니다.
- 숫자 형식: 적절한 정밀도. 일관된 통화/백분율 형식. 필요한 경우 천 단위 구분 기호.
- 제목 명확성: 제목이 지표뿐만 아니라 인사이트를 명시합니다. 날짜 범위가 지정됩니다.
- 주의사항 투명성: 알려진 한계와 가정이 명시적으로 명시됩니다.
- 재현 가능성: 다른 사람이 제공된 문서에서 이 분석을 재현할 수 있습니다.
일반적인 데이터 분석 함정
조인 폭발
문제: 다대다 조인이 조용히 행을 곱하여 카운트와 합계를 부풀립니다.
감지 방법:
-- 조인 전후 행 수 확인
SELECT COUNT(*) FROM table_a; -- 1,000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id; -- 3,500 (이런)
예방 방법:
- 조인 후 항상 행 수를 확인하세요
- 카운트가 증가하면 조인 관계를 조사하세요(정말 1:1 또는 1:다인가?)
- 조인을 통해 엔티티를 셀 때
COUNT(*)대신COUNT(DISTINCT a.id)를 사용하세요
생존 편향
문제: 오늘 존재하는 엔티티만 분석하고, 삭제, 이탈 또는 실패한 엔티티는 무시합니다.
예시:
- "현재 사용자"의 사용자 행동 분석이 이탈한 사용자를 놓칩니다
- "우리 제품을 사용하는 회사"를 보면 평가하고 떠난 회사를 무시합니다
- "성공적인" 결과의 속성을 "실패한" 결과 없이 연구합니다
예방 방법: 결론을 내리기 전에 "이 데이터셋에 없는 사람은 누구인가?"라고 물어보세요.
불완전 기간 비교
문제: 부분 기간을 전체 기간과 비교합니다.
예시:
- "1월 수익은 $500K vs. 12월의 $800K" -- 그러나 1월이 아직 끝나지 않았습니다
- "이번 주 가입이 감소했습니다" -- 수요일에 확인했으며, 전체 이전 주와 비교 중입니다
예방 방법: 항상 완전한 기간으로 필터링하거나, 동일한 월의 날짜/동일한 일 수를 비교하세요.
분모 이동
문제: 분모가 기간 사이에 변경되어 비율을 비교할 수 없게 만듭니다.
예시:
- "적격" 사용자를 계산하는 방식을 변경하여 전환율이 개선되었습니다
- "활성" 정의가 업데이트되어 이탈률이 변경되었습니다
예방 방법: 비교되는 모든 기간에 걸쳐 일관된 정의를 사용하세요. 정의 변경 사항을 기록하세요.
평균의 평균
문제: 미리 계산된 평균을 평균내면 그룹 크기가 다를 때 잘못된 결과가 나옵니다.
예시:
- 그룹 A: 100명의 사용자, 평균 수익 $50
- 그룹 B: 10명의 사용자, 평균 수익 $200
- 틀림: 평균의 평균 = ($50 + $200) / 2 = $125
- 맞음: 가중 평균 = (100*$50 + 10*$200) / 110 = $63.64
예방 방법: 항상 원시 데이터에서 집계하세요. 미리 집계된 평균을 평균내지 마세요.
시간대 불일치
문제: 다른 데이터 소스가 다른 시간대를 사용하여 정렬 불일치를 일으킵니다.
예시:
- UTC의 이벤트 타임스탬프 vs. 사용자에게 표시되는 현지 시간 날짜
- 다른 기준 시간을 사용하는 일별 롤업
예방 방법: 분석 전에 모든 타임스탬프를 단일 시간대(UTC 권장)로 표준화하세요. 사용된 시간대를 문서화하세요.
세분화의 선택 편향
문제: 세그먼트가 측정 중인 결과에 의해 정의되어 순환 논리를 만듭니다.
예시:
- "온보딩을 완료한 사용자는 유지율이 더 높습니다" -- 당연히, 그들은 스스로 선택했습니다
- "파워 유저가 더 많은 수익을 창출합니다" -- 그들은 수익을 창출함으로써 파워 유저가 되었습니다
예방 방법: 결과가 아닌 처리 전 특성을 기반으로 세그먼트를 정의하세요.
기타 통계적 함정
- 심슨의 역설: 데이터가 집계되었을 때와 세분화되었을 때 추세가 반전됩니다
- 인과관계로 제시된 상관관계 뒷받침 증거 없이
- 작은 표본 크기로 인해 신뢰할 수 없는 결론 초래
- 이상치가 평균에 불균형적으로 영향을 미치는 경우(중앙값을 대신 사용해야 합니까?)
- 다중 검정 / 체리 피킹 유의미한 결과
- 사전 정보 편향: 미래 정보를 사용하여 과거 사건을 설명
- 특정 서사에 유리한 체리 피킹된 시간 범위
결과 타당성 검사
규모 확인
분석의 주요 숫자에 대해 "냄새 테스트"를 통과하는지 확인하세요:
| 지표 유형 | 타당성 검사 |
|---|---|
| 사용자 수 | 알려진 MAU/DAU 수치와 일치합니까? |
| 수익 | 알려진 ARR 대비 올바른 규모 크기인가요? |
| 전환율 | 0%에서 100% 사이인가요? 대시보드 수치와 일치합니까? |
| 성장률 | 50%+ MoM 성장이 현실적인가요, 아니면 데이터 문제인가요? |
| 평균 | 분포에 대해 알고 있는 것을 고려할 때 평균이 합리적인가요? |
| 백분율 | 세그먼트 백분율이 ~100%에 합산됩니까? |
교차 검증 기법
- 동일한 지표를 두 가지 다른 방식으로 계산하고 일치하는지 확인
- 개별 레코드 점검 -- 몇 가지 특정 엔티티를 선택하고 데이터를 수동으로 추적
- 알려진 벤치마크와 비교 -- 게시된 대시보드, 재무 보고서 또는 이전 분석과 대조
- 역설계 -- 총 수익이 X라면, 사용자당 수익에 사용자 수를 곱하면 대략 X가 됩니까?
- 경계 확인 -- 단일 일, 단일 사용자 또는 단일 카테고리로 필터링하면 어떻게 됩니까? 그 미시적 결과가 합리적입니까?
조사가 필요한 위험 신호
- 명백한 원인 없이 기간 대비 50% 이상 변경된 모든 지표
- 정확히 반올림된 숫자인 카운트 또는 합계(필터 또는 기본값 문제 시사)
- 정확히 0% 또는 100%인 비율(불완전한 데이터 나타낼 수 있음)
- 가설을 완벽하게 확인하는 결과(현실은 일반적으로 더 지저분함)
- 시간 기간 또는 세그먼트 간에 동일한 값(쿼리가 차원을 무시하고 있음을 시사)
재현 가능성을 위한 문서화 표준
분석 문서화 템플릿
모든 중요한 분석에는 다음이 포함되어야 합니다:
## 분석: [제목]
### 질문
[답변 중인 특정 질문]
### 데이터 소스
- 테이블: [스키마.테이블명] ([날짜] 기준)
- 테이블: [스키마.다른_테이블] ([날짜] 기준)
- 파일: [파일명] (출처: [출처])
### 정의
- [지표 A]: [정확히 계산되는 방식]
- [세그먼트 X]: [멤버십이 정확히 결정되는 방식]
- [기간]: [시작일]부터 [종료일], [시간대]
### 방법론
1. [분석 접근 방식의 1단계]
2. [2단계]
3. [3단계]
### 가정 및 한계
- [가정 1 및 그것이 합리적인 이유]
- [한계 1 및 결론에 미치는 잠재적 영향]
### 주요 결과
1. [뒷받침 증거가 있는 결과 1]
2. [뒷받침 증거가 있는 결과 2]
### SQL 쿼리
[사용된 모든 쿼리, 주석 포함]
### 주의사항
- [이에 따라 행동하기 전에 독자가 알아야 할 사항]
코드 문서화
재사용될 수 있는 코드(SQL, Python)의 경우:
"""
분석: 월별 코호트 유지율
작성자: [이름]
날짜: [날짜]
데이터 소스: events 테이블, users 테이블
마지막 검증: [날짜] -- 결과가 2% 이내로 대시보드와 일치
목적:
첫 활동 날짜를 기준으로 월별 사용자 유지 코호트를 계산합니다.
가정:
- "활성"은 해당 월에 이벤트가 하나 이상 있음을 의미함
- 테스트/내부 계정 제외 (user_type != 'internal')
- 전체적으로 UTC 날짜 사용
출력:
cohort_month 행과 months_since_signup 열이 있는 코호트 유지 행렬.
값은 유지율(0-100%)입니다.
"""
분석 버전 관리
- 쿼리와 코드를 버전 관리(git) 또는 공유 문서 시스템에 저장
- 사용된 데이터 스냅샷의 날짜 기록
- 업데이트된 데이터로 분석을 재실행하는 경우, 변경된 사항과 이유를 문서화
- 추세 비교를 위해 정기 분석의 이전 버전에 연결
예시
/validate-data 경영진에게 보내기 전에 이 분기별 수익 분석을 검토하세요: [분석]