📊 데이터공학

데이터 계약

Data Contract

데이터 생산자-소비자 간 합의된 스키마 및 품질 약속.

상세 설명

데이터 계약(Data Contract)은 데이터 생산자와 소비자 사이의 공식적인 합의로, 데이터의 스키마, 품질 표준, SLA(서비스 수준 협약)를 명확하게 정의합니다. 마이크로서비스 아키텍처와 데이터 메시 환경에서 팀 간 데이터 교환의 신뢰성을 확보하는 핵심 메커니즘으로 자리 잡았습니다.

데이터 계약은 API 계약과 유사하게 버전 관리되며, 스키마 변경 시 하위 호환성을 유지하거나 사전 협의를 통해 Breaking Change를 체계적으로 관리합니다. JSON Schema, Protocol Buffers, Apache Avro 등의 형식으로 스키마를 정의하고, Great Expectations나 Soda Core 같은 도구로 품질 규칙을 자동 검증합니다.

핵심 구성 요소로는 스키마 정의(필드명, 데이터 타입, 필수 여부), 품질 규칙(null 허용 여부, 값 범위, 유일성 제약), SLA(데이터 전달 시간, 가용성, 신선도 보장), 그리고 소유권 정보(생산자 팀, 연락처, 책임 범위)가 포함됩니다.

CI/CD 파이프라인에 데이터 계약 검증을 통합하면 계약 위반을 조기에 발견하고 데이터 품질 문제가 하류 시스템으로 전파되는 것을 방지할 수 있습니다. 이는 데이터 거버넌스와 플랫폼 안정성의 토대가 됩니다.

코드 예제

YAML + Python
# data_contracts/orders_contract.yaml
# 주문 데이터 계약 정의

apiVersion: datacontract/v1.0
kind: DataContract
metadata:
  name: orders-events
  version: 2.1.0
  owner: order-service-team
  contact: order-team@company.com

info:
  title: 주문 이벤트 데이터 계약
  description: 주문 서비스에서 발행하는 주문 이벤트 스트림

schema:
  type: object
  properties:
    order_id:
      type: string
      format: uuid
      description: "주문 고유 식별자"
    customer_id:
      type: string
      pattern: "^CUS-[0-9]{10}$"
    order_date:
      type: string
      format: date-time
    status:
      type: string
      enum: [pending, confirmed, shipped, delivered, cancelled]
    total_amount:
      type: number
      minimum: 0
  required:
    - order_id
    - customer_id
    - order_date
    - status
    - total_amount

quality:
  - name: order_id_unique
    type: unique
    column: order_id
  - name: freshness
    type: freshness
    maxDelay: 5 minutes

sla:
  availability: 99.9%
  latency: p95 < 100ms

---
# Great Expectations 검증 (Python)
import great_expectations as gx

context = gx.get_context()
validator = context.get_validator(
    datasource_name="orders_stream",
    data_asset_name="orders"
)

# 데이터 계약 검증 규칙
validator.expect_column_values_to_not_be_null("order_id")
validator.expect_column_values_to_be_unique("order_id")
validator.expect_column_values_to_be_in_set(
    "status",
    ["pending", "confirmed", "shipped", "delivered", "cancelled"]
)
validator.expect_column_values_to_be_between(
    "total_amount", min_value=0
)

# 검증 결과 저장
validator.save_expectation_suite()
print("Data contract validation complete!")

실무 대화

매번 상류 팀 데이터가 바뀌어서 우리 파이프라인이 깨지는데, 어떻게 하면 좋을까요?
데이터 계약을 도입해야 합니다. 상류 팀과 스키마, 품질 규칙, 변경 통보 절차를 명문화하면 Breaking Change를 사전에 협의할 수 있어요. Great Expectations으로 CI에서 자동 검증하면 계약 위반을 즉시 알 수 있습니다.
데이터 메시 환경에서 데이터 품질을 보장하는 방법은?
각 도메인이 데이터 프로덕트를 제공할 때 데이터 계약을 함께 제공합니다. JSON Schema나 Avro로 스키마를 정의하고, SLA와 품질 규칙을 명시해요. 소비자는 계약을 기준으로 데이터를 신뢰할 수 있고, 생산자는 계약 준수에 책임을 집니다.
이 dbt 모델이 원천 테이블 스키마에 의존하는데, 스키마 변경 감지가 없네요.
데이터 계약 검증을 추가해야 합니다. CI 단계에서 source 테이블의 스키마가 계약과 일치하는지 확인하고, 불일치 시 파이프라인을 중단하도록 해주세요. dbt의 source freshness와 함께 Great Expectations 테스트를 추가하면 됩니다.

주의사항

  • 계약 관리 오버헤드가 발생하므로 핵심 데이터 자산부터 단계적으로 도입하세요.
  • 데이터 계약은 조직 문화 변화가 필요합니다. 생산자 팀의 책임 의식이 전제되어야 합니다.
  • 레거시 시스템은 스키마 추출이 어려울 수 있으므로 점진적 마이그레이션 전략이 필요합니다.
  • 도구 표준화가 미흡한 분야이므로 조직에 맞는 형식(YAML, JSON Schema, Protobuf)을 선정하세요.
  • 계약 버전 관리는 Semantic Versioning을 적용하고, Breaking Change는 major 버전 변경으로 명확히 표시하세요.

더 배우기