테이블 신뢰성 검증 여정
"이 테이블, 분석에 써도 되나?" — 분석가가 처음 만나는 테이블의 신뢰성을 GenD 화면 4개로 검증하는 통합 여정입니다. 카탈로그에서 테이블을 발견하고, 데이터 품질로 품질 점수를 확인하고, 데이터 리니지로 출처를 추적하고, 타임 트래블로 과거 시점 데이터까지 검증합니다.
사전 준비
- GenD에 로그인 (조회 권한이면 충분 — 품질 규칙 생성만 관리자 권한 필요)
- 샘플 데이터가 적재되어 있어야 합니다 (
make seed-demo, 의도적 DQ 결함 포함)
전체 여정
1. 카탈로그 → 테이블 발견: 스키마·샘플·메타데이터 확인
2. 데이터 품질 → 4축 품질 점수 + 규칙 검사 결과
3. 데이터 리니지 → 어디서 와서 어디로 흘러가는지 추적
4. 타임 트래블 → 과거 스냅샷과 비교해 데이터 변화 검증
1단계: 카탈로그에서 테이블 발견
사이드바 → 카탈로그 를 클릭하고, 트리에서 대상 테이블을 찾습니다 (예: iceberg → card → transactions).
테이블 상세에서 1차 신뢰성 단서를 확인합니다:
| 확인 항목 | 위치 | 왜 중요한가 |
|---|---|---|
| 컬럼 목록·타입 | Columns 탭 | 기대하는 스키마인지, Nullable 여부 |
| 샘플 데이터 | Sample Data 탭 | 실제 값 형태 (SELECT * LIMIT 10) |
| Medallion 배지 | About this table | Bronze(원본)/Silver(정제)/Gold(마트) — 정제 수준 |
| PII 태그 | 컬럼 메타데이터 | 민감 컬럼 포함 여부 (마스킹 대상) |
Medallion 계층의 의미는 Medallion 데이터 레이어를 참조하세요. Bronze 테이블은 원본 그대로라 결함이 남아 있을 수 있습니다.
2단계: 데이터 품질 점수 확인
사이드바 → 거버넌스 → 데이터 품질 (/governance/quality) 을 클릭합니다. 화면은 개요(overview) / 규칙(rules) / 이력(history) 탭으로 구성됩니다.
2-1. 개요 탭 — 4축 종합 점수
GenD는 4가지 축으로 품질을 측정해 composite score(A~F 등급)를 산출합니다:
| 축 | 설명 | 측정 예시 |
|---|---|---|
| Completeness | 필수 필드의 NULL 비율 | customers.email NULL 2% |
| Validity | unique·range·regex 규칙 통과율 | 전화번호 형식 오류 |
| Freshness | 데이터의 최신성 | 마지막 갱신 시점, 미래 날짜 레코드 |
| Consistency | 논리적 일관성 | row_count·FK 불일치 |
대상 테이블을 선택해 축별 상세 점수를 확인합니다. 점수가 낮은 축이 있으면 어떤 규칙이 실패했는지 다음 단계에서 파고듭니다.
2-2. 규칙 탭 — 검사 기준과 결과
규칙 탭(?tab=rules)에서 테이블에 적용된 품질 규칙(NULL 검사, 범위, 패턴, 참조 무결성)과 최근 검사 결과를 확인합니다. 규칙이 하나도 없다면 점수의 근거가 약한 것이므로, 관리자에게 규칙 추가를 요청하거나 (admin이라면) 직접 생성합니다:
- 규칙명: "customers email completeness"
- 테이블: sourcedb.public.customers
- 축: completeness
- 임계값: NULL 비율 5% 이하
검사 이력 추이는 이력 탭에서 확인합니다 — 점수가 최근에 급락했다면 업스트림 변화를 의심하고 3단계로 넘어갑니다.
2-3. SQL로 직접 재검증 (선택)
SQL 에디터에서 점수의 근거를 직접 확인할 수 있습니다:
-- Consistency 검증: 고아 FK
SELECT COUNT(*) AS orphan_count
FROM iceberg.card.transactions t
LEFT JOIN sourcedb.public.customers c ON t.customer_id = c.customer_id
WHERE c.customer_id IS NULL;
3단계: 데이터 리니지로 출처 추적
사이드바 → 데이터 관측 → 데이터 리니지 를 클릭합니다. 테이블 간 데이터 흐름이 그래프로 시각화됩니다.
대상 테이블을 선택하고 다음을 확인합니다:
- 업스트림 (출처) — 이 테이블이 어떤 원본에서 파생됐는가. 업스트림이 신뢰할 수 있는 소스(운영 DB, 검증된 파이프라인)인지 확인합니다.
- 다운스트림 (소비처) — 이 테이블을 누가 쓰는가. 소비처가 많을수록 이미 검증된 테이블일 가능성이 높습니다.
- 영향 분석 — 품질 문제가 발견됐다면, 영향 분석으로 어떤 다운스트림(마트·쿼리·대시보드)까지 오염이 전파되는지 파악합니다.
2단계에서 품질 점수가 낮았다면, 업스트림 테이블의 품질 점수도 확인하세요 — 결함의 근원이 업스트림에 있는 경우가 많습니다.
스키마가 최근 바뀌었는지도 함께 봅니다: 사이드바 → 데이터 관측 → 스키마 변경 에서 컬럼 추가/삭제/타입 변경 이력을 확인할 수 있습니다.
4단계: 타임 트래블로 과거 시점 검증
사이드바 → 데이터 관측 → 타임 트래블 (/governance/time-travel) 을 클릭합니다. Iceberg 테이블의 스냅샷 이력으로 "언제부터 데이터가 이상해졌는지"를 좁힙니다.
- 스냅샷 이력 — 테이블(
catalog.schema.table)을 지정하면 스냅샷 목록이 표시됩니다. 각 스냅샷은snapshot_id, 커밋 시각, 연산 배지(append초록 ·overwrite노랑 ·delete빨강)로 구분됩니다.overwrite/delete가 예상 밖 시점에 있다면 주의 신호입니다. - 시점 조회 — 특정 스냅샷 ID 또는 타임스탬프(ISO 8601)를 선택해 그 시점의 데이터를 조회하고, 현재 데이터와 비교합니다.
SQL 에디터로도 스냅샷 이력을 직접 확인할 수 있습니다:
-- Iceberg 스냅샷 이력 조회
SELECT * FROM iceberg.card."transactions$snapshots"
ORDER BY committed_at DESC
LIMIT 10;
Iceberg 테이블만 타임 트래블을 지원합니다. 외부 카탈로그(예:
sourcedb.*) 테이블은 1~3단계까지로 검증합니다.
판정 체크리스트
| 질문 | 확인 화면 | 통과 기준 (예시) |
|---|---|---|
| 스키마·샘플이 기대와 일치하는가 | 카탈로그 | 필수 컬럼 존재, 타입 일치 |
| 품질 점수가 충분한가 | 데이터 품질 (개요) | composite B(85) 이상 |
| 점수의 근거 규칙이 있는가 | 데이터 품질 (규칙) | 핵심 컬럼에 규칙 1개 이상 |
| 출처가 신뢰할 수 있는가 | 데이터 리니지 | 업스트림이 검증된 소스 |
| 최근 이상 변경이 없는가 | 스키마 변경 + 타임 트래블 | 예상 밖 overwrite/delete 없음 |
다섯 항목이 모두 통과하면 분석에 사용하고, 하나라도 걸리면 테이블 소유자/관리자에게 문의하거나 데이터 액세스 요청·품질 규칙 추가를 진행합니다.
다음 단계
- 데이터 품질 — 4축 점수·규칙 심화
- 데이터 계보 — 리니지·영향 분석 심화
- Medallion 워크스루 — Bronze → Silver → Gold 정제 흐름 체험
- 데이터 거버넌스 — PII 탐지 + 접근 제어