데이터 품질은 더 이상 사람이 눈으로 확인하는 운영 업무가 아니라, 코드로 정의하고 자동으로 검증하는 엔지니어링 영역입니다. Great Expectations, dbt test, SLA 기반 검증을 함께 쓰면 적재, 변환, 배포 전 과정을 일관된 품질 체계로 묶을 수 있습니다.
데이터가 한 번 깨지면 리포트 오류, 지표 왜곡, 의사결정 지연이 연쇄적으로 생깁니다. 그래서 품질을 문서가 아니라 실행 가능한 rule set으로 관리해야 합니다.
코드로 관리한다는 뜻
코드로 관리한다는 것은 “이 테이블은 null이 없어야 한다”, “주문 상태는 정해진 값만 허용한다”, “하루 안에 도착해야 한다” 같은 기준을 사람이 수작업으로 확인하지 않고, 저장소와 파이프라인 안에 넣어 자동 실행되게 만드는 방식입니다.
이 방식의 핵심은 세 가지입니다. 첫째, 기준이 명확해야 합니다. 둘째, 실행이 자동이어야 합니다. 셋째, 실패가 즉시 보이도록 해야 합니다.
Great Expectations 역할
Great Expectations는 데이터에 대한 기대값을 선언적으로 작성하고, 그 기대값에 맞는지 검증하는 프레임워크입니다. 공식 문서에서도 schema, uniqueness, missingness, freshness, volume, integrity 같은 여러 품질 차원을 지원한다고 설명합니다.
예를 들면 다음 같은 기준을 표현할 수 있습니다. 컬럼값이 허용 범위 안에 있어야 하고, 특정 기간 안에 도착해야 하며, 참조 관계가 깨지지 않아야 합니다.
운영 측면에서 Great Expectations의 강점은 검증 결과를 Data Docs로 남길 수 있다는 점입니다. 이 문서는 HTML 형태로 생성되어 누구나 결과를 쉽게 확인할 수 있고, 기대값과 검증 이력을 함께 볼 수 있습니다.
dbt test 역할
dbt test는 모델, source, snapshot, seed에 대해 선언형 검증을 수행합니다. 공식 문서 기준으로 data tests와 unit tests를 지원하며, select 옵션으로 범위를 세밀하게 제어할 수 있습니다.
기본적으로 많이 쓰는 테스트는 unique, not_null, accepted_values, relationships입니다. 이 네 가지는 분석계에서 가장 자주 부딪히는 무결성 문제를 빠르게 잡는 데 유용합니다.
dbt의 장점은 변환 로직과 테스트가 같은 프로젝트 안에서 같이 관리된다는 점입니다. 그래서 모델을 만들고 나서 별도 품질 시스템을 붙이는 대신, 변환 단계 자체에 품질을 내장할 수 있습니다.
두 도구의 차이
Great Expectations는 데이터 품질 프레임워크 자체에 가깝고, dbt test는 변환 파이프라인에 붙는 검증 기능에 가깝습니다. 그래서 둘은 경쟁 관계보다 역할 분담 관계로 보는 편이 맞습니다.
아래처럼 생각하면 쉽습니다. dbt는 “모델이 올바르게 만들어졌는지”를 검증하는 데 강하고, Great Expectations는 “데이터가 어떤 규칙을 만족해야 하는지”를 더 폭넓게 정의하는 데 강합니다.
역할 정리
| 항목 | Great Expectations | dbt test |
| 중심 개념 | Expectation | Test |
| 강점 | 다양한 품질 규칙, 문서화, 검증 이력 | 모델 중심 검증, SQL 기반 파이프라인 통합 |
| 잘 맞는 지점 | 원천 데이터 검증, 프로파일링, 품질 대시보드 | 변환 후 모델 검증, CI/CD, 분석계 품질 체크 |
| 대표 예시 | freshness, schema, volume, uniqueness | not_null, unique, relationships, accepted_values |
SLA 기반 검증
SLA 기반 검증은 단순히 테스트를 많이 돌리는 것이 아니라, 비즈니스가 허용하는 수준을 숫자로 정하고 그 기준을 지키는 방식입니다. 예를 들어 “매일 오전 9시까지 최신 데이터가 있어야 한다”, “null 비율이 0.5퍼센트 이하여야 한다”, “중요 테이블은 99퍼센트의 배치에서 제시간 도착해야 한다”처럼 말입니다.
여기서 구분이 중요합니다. SLA는 외부와의 약속이고, SLO는 그 약속을 지키기 위한 내부 목표입니다. SLI는 그 둘을 측정하는 지표입니다.
즉, 데이터 품질 테스트가 “통과 또는 실패”만 주는 수준에 머물면 부족할 수 있습니다. 운영 관점에서는 실패 횟수, 지연 시간, 오류율 같은 지표를 쌓아서 SLA 준수 여부를 추적해야 합니다.
실무 적용 흐름
실무에서는 보통 원천 구간, 변환 구간, 서비스 구간으로 나눠서 품질을 겹겹이 설계합니다. 원천 구간에서는 schema, freshness, volume 같은 기본 검증을 하고, 변환 구간에서는 unique, relationships, accepted_values를 확인하고, 서비스 구간에서는 SLA 지표를 봅니다.
이렇게 나누면 장애 원인도 빨리 찾을 수 있습니다. 원천에서 문제인지, 변환에서 생긴 문제인지, 아니면 배포 후 데이터 소비 단계에서 깨진 것인지 범위를 좁히기 쉽기 때문입니다.
예를 들어 SAP와 MSSQL에서 적재한 주문 데이터를 생각해볼 수 있습니다. SAP 원천 테이블에서 주문일이 비어 있지 않은지 확인하고, dbt에서는 주문 상태 코드가 허용 값인지 검증하며, 마지막으로 SLA에서는 “전일 데이터가 오전 7시까지 준비되어야 한다”를 측정합니다.
추천 운영 방식
가장 현실적인 방식은 “작게 시작해서 점점 넓히기”입니다. 모든 테이블에 복잡한 룰을 한 번에 넣기보다, 비즈니스 영향이 큰 핵심 테이블부터 시작하는 편이 효율적입니다.
운영 우선순위는 보통 다음 순서가 좋습니다. 첫째, not_null과 unique 같은 기본 무결성. 둘째, relationships와 accepted_values 같은 업무 규칙. 셋째, freshness와 volume 같은 운영 지표. 넷째, SLA와 SLO 기반의 경보 체계입니다.
또한 품질 규칙은 코드 저장소에서 버전 관리해야 합니다. 그래야 누가 어떤 기준을 언제 바꿨는지 추적할 수 있고, 배포 파이프라인에서 같은 기준을 반복 실행할 수 있습니다.
설계 포인트
데이터 품질 규칙을 만들 때는 기술적인 정합성보다 업무 의미를 먼저 잡아야 합니다. 예를 들어 “금액이 0보다 커야 한다”는 규칙은 단순한 검증이지만, 실제로는 “환불 거래는 예외로 허용할지” 같은 업무 맥락이 함께 들어가야 합니다.
또한 실패 시 동작도 정해야 합니다. 치명적인 품질 오류는 파이프라인을 중단하고, 경미한 오류는 경고만 남길 수도 있습니다. 이런 정책이 없으면 테스트는 많아도 운영 결정으로 이어지지 않습니다.
마지막으로 문서화가 중요합니다. Great Expectations의 Data Docs나 dbt의 문서 체계를 활용하면 품질 기준과 결과를 한곳에서 공유할 수 있어, 개발자와 분석가와 운영 담당자가 같은 화면을 보고 이야기할 수 있습니다.
코드로 관리할 때의 이점
가장 큰 이점은 재현성입니다. 사람이 매번 확인하는 품질 점검은 흔들리기 쉽지만, 코드화된 검증은 같은 입력에 같은 결과를 줍니다.
두 번째는 확장성입니다. 테이블이 수십 개에서 수백 개로 늘어나도 같은 패턴으로 테스트를 확장할 수 있습니다.
세 번째는 책임 분리가 쉬워진다는 점입니다. 데이터 엔지니어는 적재와 검증을, BI 엔지니어는 모델과 지표 해석을, 비즈니스 담당자는 SLA 기준을 공유하면서 각자의 역할을 명확히 할 수 있습니다.
데이터 품질을 코드로 관리한다는 것은 품질을 감각이 아니라 시스템으로 다루는 일입니다. Great Expectations로 원천과 구조를 넓게 검증하고, dbt test로 모델 품질을 촘촘히 잡고, SLA 기반 검증으로 비즈니스 약속까지 연결하면 분석계 신뢰도를 훨씬 높일 수 있습니다.
특히 Azure 환경에서 SAP, MSSQL, Power BI까지 이어지는 구조라면 품질 검증은 선택이 아니라 운영의 기본이 됩니다. 적재, 변환, 시각화가 모두 연결된 만큼, 품질도 하나의 파이프라인으로 관리하는 설계가 가장 안정적입니다.
놓치면 아쉬운 추천 글, 함께 읽어보세요!
- 추천 글을 불러오는 중입니다...
