들어가며
요즘 비효율적인 태블로의 flow들을 dbt로 하나씩 전환하는 작업을 하고 있다. dbt는 모델에 대한 정의와 dbt test 간단한 명령어로 데이터 품질을 측정 할 수 있다.
다만 실제로 작업을 진행하다 보니 무엇을 어떤 기준으로 어디까지 테스트해야 하지? 라는 고민이 생겼다. 그러다 좋은 글을 찾게되서 해당 글을 정리하고, 어떤 식으로 데이터 품질을 유지할 수 있을지 정리해보았다.
데이터 품질(Data Quality)이란?
•
데이터가 사용자가 정의한 목적에 얼마나 적합한가(fit for purpose)를 의미
•
품질은 사용 목적/기대치에 따라 달라지는 상대적이고 주관적인 개념
•
예를 들어, 동일 데이터라도 회계팀은 정확한 데이터를 필요로 하지만 마케팅 팀은 대략적인 매출액만으로 매출 추세를 파악
데이터팀에서 말하는 데이터 품질은 여기서 한단계 더 나아간다.
파이프라인이 반복 실행되는 운영 환경에서도 일관되게 재현 가능해야하고, 누락/중복/지연/정합성 문제를 빠르게 탐지하고 복구할 수 있는 상태를 포함한다. 코드가 정상 종료돼도 데이터가 잘못 나올 수 있기 때문에 데이터 자체의 실패를 별도로 정의하고 검증해야한다.
데이터 품질 관리는 분석 신뢰도 + 파이프라인 운영 안정성을 위한 필수 작업
데이터 품질의 6차원 + 4가지 추가 차원
1.
Accuracy (정확성)
2.
Completeness (완전성)
3.
Consistency (일관성)
4.
Uniqueness (유일성)
5.
Timeliness (적시성)
6.
Validity (유효성)
++ 여기에 더해 4가지 추가 차원이 있음
1.
Currency(최신성)
2.
Conformity(형식/타입 준수)
3.
Integrity (무결성)
4.
Precision (정밀도)
1) Accuracy | 정확성
•
데이터가 현실(실세계) 또는 합의된 기준/참조 데이터(레퍼런스)를 얼마나 정확히 반영하는가
◦
예) 소비자물가지수(CPI) 같은 공신력 있는 기준값과 DB 값을 비교
•
실무 체크: 기준 소스(원장/마스터/외부 공인 데이터)와 샘플링/대조, 허용 오차(±) 정의
2) Completeness | 완전성
•
채워질 수 있는 100% 대비 실제로 값이 채워진 비율(누락 여부)
•
대표적인 누락 유형
◦
레코드 자체 누락
◦
필수 속성 값 누락(고객 이메일 null)
◦
참조(도메인) 값 누락(예: 특정 상태값이 레퍼런스 테이블에 없음)
◦
적재/변환 중 길이 잘림
•
실무 체크: 필수 컬럼 not null, 필수 이벤트/거래 누락 탐지, 길이 제한/스키마 변경 감시
3) Consistency | 일관성
•
여러 시스템/데이터셋/저장소에 존재하는 동일 개체/값이 서로 모순 없이 동일하게 유지되는가
•
특히 분산 시스템, 데이터 웨어하우스, 데이터 복제(replication) 환경에서 중요
•
상세 유형
◦
원본과 대상 간 레코드 수준 일관성
▪
소스 → 타겟 적재 시, 레코드가 빠지거나(누락) 더 생기거나(중복) 같은 행 단위 불일치가 없는지 확인 (레코드 카운트/키셋 비교, 소스-타겟 대조 쿼리)
◦
소스와 대상간 속성 수준
▪
코드는 양쪽에 존재하지만, 특정 컬럼 값이 다르거나 일부 컬럼이 비어있는 등 속성 단위 불일치가 없는지 확인
◦
두 주제 영역간 데이터 일관성
▪
서로 다른 도메인/데이터셋(예: 주문 vs 배송) 사이에 논리적으로 맞아야 하는 값이 일치하는지 확인
▪
cross-domain 합계 검증(주문수량=배송수량), 상태 전이 규칙과의 정합성
◦
트랜잭션 데이터 일관성
▪
트랜잭션(여러 read/write 작업 묶음)이 정상적으로 처리되지 않으면 데이터가 모순될 수 있음
◦
시간에 따른 일관성
▪
큰 비즈니스 변화가 없다면 값/볼륨은 대체로 완만하게 변동해야 하며, 급격한 스파이크/드랍은 오류 신호일 수 있음
▪
평소 500명/일 신규인데 갑자기 급증/0명 → 중복 적재/배치 실패 가능성
◦
시스템 간 데이터 표현 일관성
▪
같은 의미의 참조/코드 값이 여러 시스템에서 일관되게 저장/표현되어야 함
▪
대표 케이스
•
의미는 같지만 표현 방식이 다름(같은 개념인데 코드/라벨이 다름)
•
참조 데이터 값 누락(필요한 코드가 빠짐)
•
추가 참조값(예상보다 코드가 더 생김)
•
더욱 세밀한 세분화(코드가 더 촘촘하게 쪼개짐)
•
표현은 같지만 의미가 다름(값은 같은데 시스템마다 해석/사용이 다름 → 탐지가 어려움)
4) Uniqueness | 유일성
•
하나의 이벤트/엔티티가 중복 기록되지 않고 1번만 존재하는가
•
예시
◦
같은 사람을 서로 다른 ID/이름으로 2번 등록(Thomas vs Tom)
◦
동일 ID로 레코드가 여러 번 쌓이는 중복(키 비교로 탐지 쉬움)
•
실무 체크: PK/유니크 키 보장, 중복 이벤트(재전송/리트라이) 제거 규칙, dedup key 설계
5) Timeliness | 적시성
•
실제 이벤트 발생 시점 대비 데이터가 시스템에 캡처되어 사용 가능해지기까지의 지연이 얼마나 됐는지, 즉 마감 시간 내 도착했는가
•
데이터 자체는 여전히 유효하며 단지 지연될 뿐임
•
초저지연이 필요한 자동매매나 자율주행같은 도메인에서 데이터 지연은 치명적
•
실무 체크: 매일 09:00까지 적재 완료 같은 SLA 모니터링, 파이프라인 단계별 지연 추적
6) Validity | 유효성(규칙/정의 준수)
•
데이터 값이 사전에 정해진 규칙/범위/계산/이벤트 순서를 만족하는가
•
예시
◦
무게/나이/날짜 등 범위를 만족하는지
◦
사건 발생 순서 (주문일보다 배송일이 빠르면 비정상)
•
실무 체크: accepted_values, range 체크, 비즈니스 룰 기반 assert, 이벤트 시퀀스 제약
7) Currency | 최신성
•
데이터가 나타내는 상태가 실세계의 현재 상태를 얼마나 잘 반영하는지
•
데이터가 제때 도착해도 상태가 바뀌었는데 반영 못하면 outdated인 것
•
예시
◦
Changed Address: 고객이 이사했는데 주소가 갱신되지 않아 우편발송 리스트가 오래된 상태
◦
Expired/Outdated Coupon Targeting: 고객이 이미 결혼했는데 미혼으로 남아있어 웨딩쿠폰 타겟팅이 잘못됨
8) Conformity | 형식/타입 표준 준수
•
같은 속성의 값이 일관된 포맷으로 표현되고 올바른 데이터 타입을 지키는지
•
값 자체가 맞아도 포맷/타입이 다르면 컴퓨터가 깨짐
•
예시
◦
데이터 포맷: 주문일자가 ‘MM/DD/YYYY’여야 하는데 레코드마다 ‘YYYY/M/DD’ 또는 ‘YYYY/M/DD HH:MM:SS’처럼 섞여 있음
◦
데이터 타입: 주문금액이 numeric이어야 하는데 특정 레코드가 alphanumeric(문자+숫자)로 들어옴
9) Integrity | 무결성
•
두 데이터셋 간에 정의된 관계(제약/카디널리티)가 제대로 지켜지는지
•
예시
◦
외래키: 주문 테이블의 customer_number가 고객 테이블에 반드시 존재해야 함
◦
Relationship Cardinality: 관계 비율(1:1, 1:N 등)이 사전에 정의되어 있으면 이를 위반하는지 검사
10) Precision | 정밀도
•
데이터가 반올림되거나 집계되면서 필요한 수준의 세부 정보가 손실되지 않았는지
•
예시
◦
숫자 정밀도: GPS 소수점 자리수에 따라 위치 오차가 m~km까지 커짐
◦
시간 정밀도: 회계 업무는 일 단위면 되지만 카드 부정거래 탐지는 초 단위가 필요함
◦
Granularity: 집계 데이터는 원천의 세부값을 복원 못함
▪
영업사원별 커미션 지급엔 개인별 매출이 필요한데 월 총매출만 있으면 불가
마무리
데이터 품질은 무조건 많이 검사한다기보다 어느 단계에서 어떤 실패를 막을지 먼저 정해두는게 핵심이다. 위 글을 읽으며 현재 파이프라인에 최소로 적용할만한 단계별 체크리스트를 아래와 같이 만들어보았다.
수집 직후
•
누락/중복/복제 등 오류를 빠르게 차단
•
완전성 - 필수 컬럼 not null
•
유일성 - 중복 적재 여부
•
일관성 - 소스
타겟 row count
타겟 row count정제 레이어
•
타입/포맷 불일치 방지
•
표준 준수 - int/string, date/timestamp, timezone 포맷
가공/모델링 후
•
비즈니스 룰 위반 방지
•
유효성 - 주요 규칙 체크
◦
카운트/금액 >= 0, 올바른 날짜 범위, 허용된 상태 값
운영 모니터링
•
지연/이상징후 조기 탐지하기
•
적시성 - SLA 기준 시간 내 생성/적재 완료 여부
•
시간적 일관성 - 전일/전주 대비 급격한 집계값 변동에 대한 경고
데이터팀은 일반적인 제품 팀과 다르게 보통 자체적으로 데이터 QA를 하는 경우가 많다. ETL/ELT 파이프라인에서는 일반적인 유닛 테스트 만으로는 데이터 품질까지 챙기기는 어렵기 때문에, 데이터 자체의 품질 이슈를 별도로 고려해야한다. 그래야 추후 변경사항이 생기더라도 데이터가 깨지는 일을 방지할 수 있다. 적절한 품질 기준을 만들고 자동화해두는 것이 곧 운영 안정성으로 이어진다.