출시 6개월 차, 아침 배치가 멈추고 대시보드가 비게 된다. 원인 분석을 열어보면 테이블 컬럼명이 바뀌었거나 null이 폭증했다. 모델은 멀쩡한데 입력이 달라졌다. 다들 ETL을 긴급 패치하고 회귀를 막느라 밤샘한다. 다음 분기에도 같은 일이 반복된다.
AI 파이프라인 고장의 1차 원인은 스키마다
운영 6개월 차에 파이프라인이 무너지는 이유는 대부분 상류 스키마 변경이다. 애플리케이션 팀은 비즈니스 요구로 필드를 추가·변경한다. 데이터 팀은 사후에 깨진 조인을 복구하고 결측 보정을 덧대며 버틴다. 이 구조에서는 실패가 필연이다.
Harvard D3는 AI 시스템 신뢰성의 근간이 모델이 아니라 입력 데이터의 계약 준수라고 지적한다. Gartner 역시 AI 프로젝트 실패의 상당수가 데이터 품질 문제(스키마 드리프트, 부정확, 결측)에서 출발한다고 본다. 문제의 시작점이 업스트림이라면, 해결도 업스트림에서 해야 한다.
데이터 계약은 API 같은 합의다
Chad Sanderson이 체계화한 데이터 계약(Data Contract)은 소프트웨어 엔지니어(생산자)와 데이터 소비자(ML/분석) 사이의 API-like 합의다. 핵심 요소는 세 가지다.
- Schema: 필드 이름·타입·필수 여부
- Semantics/Business logic: 필드의 의미, 값 도메인, 파생 규칙
- SLA: 신선도, 완전성, 가용성에 대한 약속과 알림
데이터는 “우연히 남긴 로그”가 아니라 “계약된 제품”이 된다. API가 깨지면 배포가 막히듯, 계약이 깨지면 데이터 배포가 막혀야 한다.
| 항목 | 로그 중심(암묵) | 데이터 계약(명시) |
|---|---|---|
| 데이터의 지위 | 부수적 로그 | 계약된 제품 |
| 소유자 | 불분명 | 생산자·소비자 명시 |
| 변경 절차 | 임의 변경 후 통지 | 디자인 리뷰+사전 알림 |
| 검증 위치 | 다운스트림에서 수습 | CI에서 위반 차단 |
| SLA/모니터링 | 단편적 체크 | 신선도·완전성 SLA와 경보 |
| 실패 모드 | 배치 침묵 실패 | 빌드/배포 단계에서 즉시 실패 |
Shift Left로 실패를 배포 전에 끝낸다
Shift Left는 데이터 품질 책임을 파이프라인 끝에서 시작점으로 옮긴다. 생산자는 스키마 변경의 영향을 리뷰·배포 전에 알게 되고, 위반이면 멈춘다. Gable.ai는 Glassdoor, Grab 등에서 이를 구현했다. 디자인 리뷰 단계에서 소비자가 알림을 받고, 위반 시 CI에서 실패시킨다.
모델이 아니라 계약이 AI 운영의 신뢰성을 만든다.
이 흐름은 단순하다.
- 생산자가 스키마/의미 변경을 제안하면, 소비자에게 자동 알림이 간다.
- 제안이 계약을 어기면, CI에서 즉시 실패하고 배포가 차단된다.
- 변경이 필요하다면, 마이그레이션 윈도우와 대체 필드를 계약서에 명시하고 합의한다.
- 운영 중에는 SLA 기반 모니터링으로 신선도·완전성 이탈을 감지하고 알린다.
이렇게 하면 “깨진 뒤 복구”가 아니라 “배포 전 차단”으로 모드가 전환된다. 파이프라인은 PoC의 취약한 실험이 아니라 운영급 시스템이 된다.
저항은 기술이 아니라 역할 재설계다
Sanderson이 강조하듯 Shift-left의 가장 큰 벽은 adoption이다. 지금까지 데이터는 ‘남는 로그’였고, 누가 무엇을 보장하는지 경계가 흐렸다. 계약을 도입하면 책임이 선명해진다. 생산자는 스키마·의미·SLA를 소유하고, 소비자는 요구사항과 수용 기준을 명시한다. 정치적 마찰이 생긴다. 그래서 절차가 필요하다.
현장에서 통하는 최소 도입 순서는 아래와 같다.
- 핵심 도메인의 상위 데이터셋부터 계약을 쓴다. 욕심내어 전면 일괄 도입하지 않는다.
- 계약 템플릿을 표준화한다: schema, semantics, SLA 세 블록으로 고정.
- 스키마 변경은 디자인 리뷰를 통과해야 하며, 소비자 확인 없이는 배포 금지.
- CI에 계약 검증을 넣고 위반 시 실패 처리한다. 예외는 명시적으로 기록한다.
- SLA 모니터링과 알림 채널을 운영으로 편입한다. 장애는 Incident로 관리한다.
결론은 명확하다. 6개월 뒤 무너질 파이프라인을 원치 않으면, 데이터 계약과 Shift Left를 AX Ops의 기본 규율로 깔아야 한다. 시작이 어렵다면 핵심 데이터셋 하나로 파일럿을 열고, 계약·리뷰·CI·모니터링의 루프를 팀 리추얼로 굳혀라. 더 구체적인 실행 프레임은 여기서 확인하라: AX Ops 방법론 →
참고
- Chad Sanderson — The Rise of Data Contracts — https://dataproducts.substack.com/p/the-rise-of-data-contracts
- Sanderson & Freeman & Schmidt — Data Contracts (O'Reilly) — https://www.oreilly.com/library/view/data-contracts/9781098157623/
- Harvard D3 — Data Contracts: Data Quality for AI — https://d3.harvard.edu/data-contracts-data-quality-for-ai/
- Shifting Left with Data DevOps (Shift Left Conference 2025) — https://www.gable.ai/blog/shifting-left-with-data-devops-chad-sanderson-shift-left-data-conference-2025
