출처 : https://www.kimballgroup.com/wp-content/uploads/2007/10/An-Architecture-for-Data-Quality1.pdf
아래는 원문 중에서 감사 테이블 에 대한 내용과 그 번역본이다.
Ralph Kimball은 이 문제를 단순히 "ETL에서 validation 체크 좀 넣자"는 수준으로 접근하지 않는다.
그는 데이터 품질 자체를 측정 가능하고, 추적 가능하며, 리포팅 가능한 시스템으로 설계해야 한다고 주장한다.
그 핵심에 있는 두 가지 구조물이 바로 Error Event Schema와 Audit Dimension이다.
1. Error Event Schema:
오류를 로그로 남기지 말고, 차원 모델(dimensional model)로 설계하라. (팩트 테이블의 레코드 하나 = 오류 하나)
(1) Date Dimension은 특이하게도 분·초 단위 타임스탬프가 아니라, 달력 기반의 집계용 날짜 차원이다.
"이번 달에 오류가 몇 건 이었나?", "회계 기간 마지막 날에 오류가 집중되나?" 같은 질문에 답하기 위함이다.
정확한 발생 시각은 별도의 time-of-day fact 컬럼(datetime 타입)으로 관리한다.
(2) Batch Dimension은 오류가 발생한 배치 잡의 맥락을 담는다.
배치 시작/종료 시각, 처리된 레코드 수, 수행된 스크린 테스트 수, 발생한 오류 수, 최대 심각도 점수 등이 포함된다.
(3) Screen Dimension은 어떤 품질 스크린이 오류를 발생시켰는지를 설명한다.
스크린 타입(컬럼 레벨 / 구조 레벨 / 비즈니스 룰 레벨), ETL 모듈 위치, 스크린 코드 정의,
그리고 핵심적으로 Exception Action 즉 오류 발생 시 어떻게 대응할지를 정의한다.
(4) 더 낮은 grain의 Error Event Detail 테이블도 있다.
하나의 오류 이벤트(예: 비즈니스 룰 위반)가 여러 필드, 여러 레코드에 걸쳐 발생할 수 있기 때문이다.
상위 팩트 테이블과 하위 디테일 테이블은 error event key로 1:N 관계로 연결된다.
이 구조는 복잡한 다중 필드, 다중 레코드 오류를 완전하게 추적할 수 있게 해준다.
(5) Severity Score --- 오류를 가중치로 평가하기
팩트 테이블에는 Severity Score(0.0~1.0)가 포함된다.
이 값은 단순히 오류 건수를 세는 것을 넘어, 오류의 심각성을 가중 합산할 수 있게 해준다.
Kimball은 이를 Six Sigma 방법론과 연결한다. Six Sigma의 목표는 백만 번의 기회 중 3.4건 이하의 오류다.
Batch Dimension의 정보와 Severity Score를 활용하면 데이터 품질 수준이 Six Sigma 기준에 얼마나 근접했는지를 수치로 측정할 수 있다.
데이터 품질을 "느낌"이 아닌 "숫자"로 말하게 해주는 대목이다.
2. Audit Dimension : 메타데이터를 데이터로 끌어올리기
Audit Dimension은 팩트 테이블의 각 레코드가 어떤 품질 상태로 생성되었는지를 기술하는 차원이다.
Kimball은 이를 두고 "메타데이터를 진짜 데이터로 격상시킨 것"이라고 표현한다.
Audit Dimension의 주요 속성들을 살펴보면:
- Overall Quality: "Zero Defects", "Minor", "Major" 같은 이산형 텍스트 값. 또는 1에서 결함 비율을 뺀 수치로도 표현 가능.
- Completeness: 레코드의 모든 팩트 값이 실제로 전달되었는가.
- Validation: 비즈니스 룰 위반이 있었는가 (컬럼/구조 위반과 구분).
- Out of Bounds: 어떤 값이 사전 정의된 범위를 벗어나는 가.
- Screens Failed: 이 레코드에 대해 오류를 던진 스크린의 수.
- Record Modified: 최초 생성 이후 수정된 적이 있는가.
이는 팩트 테이블의 grain 유형(트랜잭션 / 주기적 스냅샷 / 누적 스냅샷)에 따라 의미가 달라진다.
트랜잭션 grain 팩트 테이블에서 레코드가 수정되었다면, 그것은 매우 심각한 Type 1 덮어쓰기 문제일 수 있다.
- Extract / Clean / Conform Time Stamps: 배치 처리 단계별 완료 시각.
- Version Numbers (ETL / Allocation / Currency): 이 레코드가 생성될 때 어떤 버전의 처리 로직이 사용되었는지.
특히 회계 감사나 컴플라이언스 추적에서 강력한 힘을 발휘한다. 예컨대 회계연도 중간에 비용 배분 로직이 바뀌었다면,
allocation version number를 행 헤더로 사용해 구 버전과 신 버전의 수익성을 나란히 비교할 수 있다.
인사이트 1: 품질 스크린의 3계층 분류
Kimball은 스크린 타입을 컬럼(column), 구조(structure), 비즈니스 룰(business rule) 세 가지로 나눈다.
이것은 단순한 분류가 아니라, 오류의 원인을 소급하는 트리아지(triage) 시스템이다.
컬럼 레벨 오류(예: null 값, 잘못된 데이터 타입)는 소스 시스템 문제일 가능성이 높다. 구조 레벨 오류(예: 참조 무결성 위반)는 ETL 설계 문제일 수 있다.
비즈니스 룰 오류는 도메인 전문가와 협의가 필요한 더 복잡한 문제다. 스크린 타입을 명시적으로 관리하면, 오류 해결의 책임 소재가 자동으로 구분된다.
인사이트 2: 감사(Audit)와 운영(Operation)의 분리
Kimball이 대규모 엔터프라이즈 환경에서 단일 중앙화된 Error Event Schema를 구축하려 하지 말라고 조언하는 것은 매우 실용적이다.
각 ETL 환경이 자체 스키마를 갖고, 필요할 때 드릴 어크로스(drill across)로 엔터프라이즈 뷰를 만드는 것이 훨씬 현실적이다.
이는 마이크로서비스 아키텍처에서 서비스별 로컬 데이터베이스를 갖고 필요 시 이벤트 스트리밍으로 통합하는 현대적 패턴과도 맥이 닿아 있다.
인사이트 3: 실시간 vs 배치의 긴장
Error Event Schema는 ETL이 진행되는 동안 집중적인 insert가 발생하는 "준 트랜잭션 테이블"처럼 동작한다.
이 테이블에 복잡한 분석 쿼리가 동시에 날아오면 ETL 파이프라인 자체가 느려질 수 있다. Kimball은 스크린이 로그 파일에만 기록하고,
스키마 업데이트를 ETL 크리티컬 패스 밖에서 처리하는 하이브리드 아키텍처도 제안한다.
이것은 오늘날의 CDC(Change Data Capture)나 비동기 이벤트 버스 패턴과 개념적으로 동일하다.
인사이트 4: 데이터 품질의 민주화
Audit Dimension의 핵심 가치는 기술적인 것이 아니라 조직적인 것이다.
기존에는 데이터 품질을 확인하려면 데이터 엔지니어에게 별도로 요청해야 했다. Audit Dimension이 BI 레이어에 노출되면,
비즈니스 사용자 스스로가 리포트를 보면서 데이터의 신뢰도를 즉시 확인할 수 있다. 데이터 품질의 소비자가 곧 품질의 감시자가 되는 구조다.
이는 오늘날 Data Observability 운동의 원형적 아이디어라고 볼 수 있다.
인사이트 5: 현대적 관점에서 아키텍처
이 논문은 2007년에 쓰였지만, 논의되는 개념들은 2020년대의 데이터 스택에서도 여전히 살아 숨쉰다.
Great Expectations, dbt tests, Monte Carlo와 같은 현대 Data Quality 도구들이 하는 일
<테스트 결과를 메타데이터로 저장하고, 이상 징후를 추적하며, 비즈니스 맥락에서 데이터 신뢰도를 표시하는 것 > 이 모두 Kimball이 설계한 아이디어의 현대적 구현에 가깝다.
달라진 것은 도구와 스케일이지, 개념의 본질이 아니다.
'3. Data Engineering > ㅤ📙 데이터 아키텍처' 카테고리의 다른 글
| Data Quality 를 위한 툴 비교하기 (0) | 2026.07.20 |
|---|---|
| 시맨틱 레이어(Semantic Layer) (0) | 2026.04.22 |