Data Eng Wiki

Data Reliability and Trust

11 min read

Data Reliability and Trust

파이프라인 전반에서 데이터의 정확성·일관성·신뢰를 확보하는 전략과 패턴

개요

데이터가 비즈니스 의사결정과 AI 시스템의 입력으로 쓰이면서, “데이터가 맞는가?”라는 질문이 가장 비용이 큰 장애의 원인이 되고 있다. 코드 배포와 동일한 수준의 엄밀함을 데이터 배포에도 적용하는 것이 핵심 트렌드다.

검증: 파이프라인 내재화

다계층 검증

단일 검증 포인트가 아닌, 인제스천 → 변환 → 서빙 각 단계에서 독립적으로 검증해야 한다.

계층무엇을 검증하나사례
소스 ↔ Lake카운트 일관성Halodoc Layer 1 (시간 바운드 비교)
변환 후구조적 완전성Halodoc Layer 2 (AI가 검증 쿼리 자동 생성)
서빙 직전비즈니스 규칙Halodoc Layer 3 (중복 키, 도메인 값)
프로덕션 트래픽고객 영향Netflix Data Canary (SPS 행동 메트릭)

데이터를 코드처럼 검증

Netflix의 핵심 교훈: 코드 변경 없이 데이터 손상만으로 프로덕션 장애가 발생할 수 있다.

  • Dedicated Orchestrator 패턴: Baseline/Canary 클러스터 분리
  • 행동 메트릭 우선: 기술적 메트릭(에러율, 레이턴시)보다 SPS(Starts Per Second) 같은 고객 영향 지표
  • Immediate Abort: 통계적 신뢰도 대신 속도를 선택 (2.5~4분 탐지)

계약: 생산자-소비자 합의

데이터 계약의 스펙트럼

수준포함 내용채택률
Schema-Only컬럼명, 타입, nullable60%
Quality-Focusednull 비율, 범위, 중복30%
SLA-Driven신선도, 가용성, 지연25%
Semantic필드의 비즈니스 의미15%
Full-Stack위 모든 항목10%

성공과 실패

  • 50개 중 12개 성공, 18개 부분 성공, 20개 실패
  • 최대 안티패턴: 강제되지 않는 계약 (실패 사례의 40%)
  • 성공 핵심: 경영진 후원 (채택률 3배), 소비자 중심, 자동 시행
  • 기술 문제가 아닌 조직 조정 문제

자동 복구: Self-Healing Pipelines

장애를 감지만 하는 것이 아니라 자동으로 복구하는 패턴이 성숙하고 있다.

  • Self-Healing Pipelines — Halodoc 6-레이어: CDC 자동 복구, 소스-레이크 일관성, 미니배치, 스마트 메모리 스케일링, 웨어하우스 락, 캐스케이딩 복구
  • 핵심 원칙: 범용 재시도가 아닌 장애 유형별 전용 복구 로직 분리

조용한 장애 방지

에러 로그 없이 데이터가 유실되는 “silent failure”가 가장 위험하다.

유형증상대응
비동기 플러시 실패데이터 누적 후 유실큐 깊이 모니터링
동시성 슬롯 고갈백그라운드 워커 기아동적 쿼터 + 재무 연계
Stale 커넥션경고 로그 폭발설계 동작 이해, 재시도 설정 확인

대규모 마이그레이션의 데이터 신뢰

Meta의 CDC 인제스천 시스템 마이그레이션에서 Shadow/Reverse-Shadow 패턴으로 데이터 무결성을 보장:

  • row count + checksum 지속 비교로 조기 불일치 탐지
  • CDC 특성상 잘못된 데이터가 전파 → 파티션 메타데이터 bad-data 마킹으로 빠른 차단
  • Large-Scale Data Migration — 상세 패턴

Netflix Data Projects — 내구적 접근 관리

개인 ID 기반 워크플로가 조직 변동 시 연쇄 장애를 유발하는 문제를 합성 프로젝트 ID로 해결:

  • Data Project = 에셋 컨테이너 + 인간과 무관한 합성 ID → 조직 변화에 강건
  • Gravity: 프로젝트 ID로 생성된 에셋이 자동 귀속
  • Data Governance — Netflix Data Projects

거버넌스와 격리

데이터베이스 연합

모놀리식 DWH의 연쇄 장애와 과도한 권한 문제를 도메인별 분리로 해결.

  • Data Governance — Uber Hive Federation (16,000+ 데이터셋, 제로 다운타임 마이그레이션)

LLM 기반 PII 탐지

스키마 진화에 적응하는 자동 PII 분류.

소프트 삭제의 함정

“삭제된” 데이터가 테이블에 무기한 존재하면서 쿼리 복잡성, 운영 부담, 데이터 누출 위험을 야기한다.

  • 트리거 기반 아카이빙이 신규 프로젝트에 권장
  • Change Data Capture — WAL 기반 CDC는 소비자 지연 시 프라이머리 DB 안정성 위험

타임라인

시기이벤트
2023Google GA4에서 규칙 기반 어트리뷰션 제거 → 검증 불가능한 블랙박스
2024-25데이터 계약 도입 시도 50건 중 40% 실패 — 조직 조정 문제 재인식
2026-02Netflix Data Canary: 데이터 배포를 코드 배포와 동일 수준으로 검증
2026-02Halodoc: AI가 변환 SQL을 분석해 검증 쿼리 자동 생성

실험 품질: 설계 단계의 데이터 신뢰

Booking.com은 대규모 A/B 테스팅에서 설계 단계의 통계적 엄밀성이 전체 데이터 신뢰를 결정한다는 것을 증명:

  • Quality Tab으로 검정력 계산·사전 가설 등록을 기술적으로 강제
  • 도구 + 프로세스(피어 리뷰) + 사람(앰배서더)의 3각 접근이 가장 효과적
  • A-B Testing and Experimentation — 실험 품질 스케일링 체계

알림 피로: 품질 체크의 역설

데이터 품질 체크를 과도하게 적용하면 알림 피로가 발생하여 오히려 품질 대응이 약화된다. 핵심 원인은 무차별 체크, 미튜닝 임계치, 소유자 미지정, 잘못된 인센티브(생산 팀은 피처 출시 보상, 품질 수정 무보상). 비즈니스 크리티컬 테이블 중심의 티어링된 알림 체계가 해결책이다.

백필과 신뢰

백필은 불가피하지만 수행 방식이 데이터 신뢰에 직접 영향을 준다. 파티션 기반 대규모 테이블에서는 blue-green 스타일 테이블 스왑이 일관성 면에서 안전하고, 모든 파이프라인을 처음부터 파라미터화·재실행 가능하게 설계하는 것이 백필 빈도와 영향을 줄인다.

관련 위키

5대 조용한 파이프라인 실패

에러 없이 실행되면서 잘못된 데이터를 생산하는 패턴:

  • Schema Drift, Partial Data Load, Stale Data, Late-Arriving Dimensions, Outdated Logic
  • Silent Failures and Data Integrity — 비즈니스 변화에 미적응하는 하드코딩된 로직이 가장 위험

스키마 드리프트의 비용

Snowflake 파이프라인에서 스키마 드리프트의 숨겨진 비용:

  • 수동 관리: 연 480시간, $24K 직접 비용 (20 파이프라인 기준)
  • Schema Evolution — 자동 스키마 감지·버전 관리가 해결책

ML 피처 파이프라인 신뢰성

시간당 피처 파이프라인의 운영에서 얻은 교훈:

  • Feature Store — Whatnot: TTL 버퍼링으로 graceful degradation, GMV 기반 장애 티어링
  • “느려지는 것”은 알림이 발생하지 않는 장애 모드 — 갱신 주기와 E2E 레이턴시를 명시적으로 모니터링

관련 이슈: DEW #256, #257, #258, #259, #260, #265, #267, #268, #269, #270 | SeattleDataGuy 시리즈

그래프 뷰

백링크