Data Contracts
데이터 생산자와 소비자 간의 구조·의미·품질·SLA를 명시하는 공식 합의
핵심 개념
데이터 계약(Data Contract)은 데이터의 스키마, 시맨틱, 품질, SLA, 소유권, 버저닝을 정의하는 공식 합의다. 50개 프로덕션 구현을 분석한 결과, 데이터 계약은 기술 문제가 아니라 조직 조정(organizational coordination) 문제이며, 도구보다 조직적 정렬에 투자한 조직이 성공했다.
5가지 계약 패턴
Pattern 1: Schema-Only (60%)
- 컬럼명, 타입, nullable 제약만 정의
- JSON Schema, Protobuf, Avro 등으로 구현
- 한계: 시맨틱 드리프트(revenue가 gross인지 net인지)를 방지하지 못함
Pattern 2: Quality-Focused (30%)
- 품질 규칙 추가: null 비율 ≤0.1%, 범위 검증, 중복 감지
- Great Expectations, dbt tests, Soda로 파이프라인에 내장
- 과제: 품질 임계값 정의에 깊은 도메인 지식 필요
Pattern 3: SLA-Driven (25%)
- 신선도(“15분 이내”), 가용성(99.9%), 지연(p99 <500ms) 보장
- 인시던트 대응 절차와 에스컬레이션 경로 포함
- 과제: SLA 정의는 쉽지만 일관된 충족이 어려움
Pattern 4: Semantic Contracts
- 필드의 비즈니스 의미를 명시: “revenue = gross revenue after refunds, before taxes”
- 에지 케이스와 비즈니스 로직을 계약에 포함
- Semantic Layer와 자연스럽게 연결
Pattern 5: Full-Stack Contracts
- 스키마 + 품질 + SLA + 시맨틱을 모두 포함
- 가장 높은 보호 수준, 가장 높은 도입·유지 비용
- 미션 크리티컬 데이터에 적합
5가지 안티패턴
| 안티패턴 | 문제 |
|---|---|
| 보일러플레이트 계약 | 모든 데이터셋에 동일 계약 → 실질적 보호 없음 |
| 소비자 없는 계약 | 소비자 요구 파악 없이 생산자가 일방적으로 정의 |
| 적용되지 않는 계약 | 문서만 존재하고 파이프라인에 시행되지 않음 |
| 과도하게 엄격한 계약 | 사소한 변경마다 차단 → 생산자 불만 → 우회 |
| 버전 관리 부재 | 파괴적 변경이 예고 없이 전파 |
성공 요인
- 점진적 도입: Schema-Only로 시작하여 필요에 따라 Quality → SLA → Semantic 순으로 확장
- 소비자 중심: 소비자의 실제 요구에서 계약 범위를 결정
- 자동 시행: 파이프라인에 내장된 검증으로 문서-실행 간 괴리 방지
- 조직적 정렬: 기술 도구보다 생산자-소비자 간 커뮤니케이션 프로세스가 핵심
- 실용적 범위: 모든 데이터가 아닌 비즈니스 임팩트가 큰 데이터부터 시작
연관 개념
- Data Quality and Validation — 계약의 품질 규칙 실행
- Data Governance — 거버넌스 프레임워크 내 계약 위치
- Semantic Layer — 시맨틱 계약과 비즈니스 의미 계층
Source: Data Contracts in Practice - What 50 Production Implementations Actually Look Like