Data Observability

상위: Data Engineering

요약

Data Observability는 데이터의 전체 생명주기(수집 → 처리 → 저장 → 소비)에 걸쳐 건강 상태와 신뢰성을 종합적으로 모니터링하고 이해하는 실천 방법이다. 소프트웨어 관측성(APM)이 애플리케이션 가동 시간과 성능을 추적하는 것처럼, Data Observability는 데이터 자체의 정확성·완전성·적시성을 지속적으로 감시한다.

왜 필요한가

Data Downtime 문제

Data Downtime이란 데이터가 불완전하거나, 잘못되었거나, 누락되었거나, 부정확한 기간을 말한다. 데이터 시스템이 복잡해질수록 소스와 소비자의 생태계가 확장되면서 Data Downtime은 기하급수적으로 증가한다.

핵심 문제는 **Silent Failure(조용한 실패)**이다. 파이프라인 작업이 성공적으로 완료되었지만 데이터 자체는 잘못된 경우, 기존 모니터링(시스템이 돌아가는지만 확인)으로는 감지할 수 없다. 예를 들어:

• ETL 작업은 성공했지만 소스 테이블에서 스키마가 변경되어 특정 컬럼이 전부 NULL로 적재됨
• 업스트림 시스템의 장애로 데이터 수집이 중단되었지만, 파이프라인 자체는 에러 없이 빈 데이터를 처리
• 중복 데이터가 적재되어 집계 결과가 2배로 부풀려졌지만 대시보드에서는 "정상 실행"으로 표시

실제 비용

• Gartner 조사: 낮은 데이터 품질로 인한 연평균 손실 $12.9M
• 데이터 품질 담당자의 **40%**가 비효율적인 품질 관리 작업에 시간을 소모
• Unity Software(2022): 대형 고객의 잘못된 데이터 수집 → 주가 30% 급락, $110M 매출 손실

실제 개선 사례

• BlaBlaCar: Data Observability 도입 후 장애 해결 시간 50% 단축
• Choozle: 전체 Data Downtime 80% 감소
• Resident: 데이터 인시던트를 1년 전 대비 10% 수준으로 감소

Monitoring vs Observability

자주 혼동되는 개념이다. "Observability는 그냥 모니터링 이름 바꾼 거 아냐?"라는 질문이 많지만, 근본적으로 다른 문제를 해결한다.

Monitoring은 상위 레이어(Alerting, Overview)에 집중하고, Observability는 하위 레이어(Profiling, Dependency Analysis, Anticipating the future)까지 포함하는 더 넓은 개념이다.

핵심 차이: Known Unknowns vs Unknown Unknowns

• Known Unknowns (모니터링 영역): 미리 예상할 수 있는 장애. "CPU가 90% 넘으면 위험하다"처럼 무엇을 감시할지 이미 알고 있는 상태.
• Unknown Unknowns (관측성 영역): 예측할 수 없는 장애. "왜 화요일 오후 3시에만 특정 고객의 데이터가 누락되는가?"처럼 어떤 질문을 해야 할지조차 모르는 상태.

모니터링은 사전에 정의한 규칙으로 Known Unknowns를 감시한다. 관측성은 텔레메트리 데이터를 자유롭게 탐색하여 Unknown Unknowns를 발견한다.

비교표

시스템이 Lift & Shift → Cloud-Native로 복잡해질수록, 단순 Monitoring만으로는 부족하고 Observability가 필수가 된다. Monitoring은 Observability의 부분집합이다.

Observability의 3 Pillars (소프트웨어 관측성 기준)

Observability는 세 가지 텔레메트리 데이터를 결합하여 시스템 상태를 이해한다.

1. Metrics (메트릭): 시스템 성능의 수치 측정값. CPU 사용률, 응답 시간, 에러율 등. 시간에 따른 추세와 패턴 파악에 유용하다. "정상 상태의 베이스라인"을 정의할 수 있다.

2. Logs (로그): 시스템 이벤트의 타임스탬프 기록. 구조화된 형태(JSON 등)를 권장하며, 개별 이벤트의 상세 맥락을 제공한다. 평균이나 백분위에서 드러나지 않는 롱테일 이벤트를 발견할 수 있다.

3. Traces (추적): 분산 시스템에서 요청이 여러 서비스를 거치는 전체 경로를 추적한다. 병목, 의존성, 장애 근본 원인을 식별할 수 있다. Logs와 Metrics만으로는 분산 시스템에서 요청의 전체 생명주기를 파악하기 어렵다.

세 가지를 결합하면: Metrics가 "무언가 비정상"을 알리고 → Logs가 "어떤 이벤트가 발생했는지" 보여주고 → Traces가 "요청이 어디서 실패했는지" 경로를 추적한다.

모니터링의 한계: Alert Fatigue

모니터링의 핵심 한계는 사전에 예측한 문제만 감지할 수 있다는 것이다. 메트릭을 정의하고, 임계값을 설정하고, "무엇이 잘못될 수 있는지"를 미리 예상해야 한다.

이로 인해 발생하는 문제가 **Alert Fatigue(알림 피로)**이다:

• 정적 임계값 기반 → 일시적이지만 정상적인 스파이크에도 알림 발생
• 규칙이 많아질수록 노이즈 증가 → 팀이 알림을 무시하기 시작
• 정작 중요한 알림이 노이즈에 묻혀 놓침

Observability 도구는 이 문제를 해결한다:

• 베이스라인 학습으로 일시적 스파이크 vs 실제 이상을 구분
• 고카디널리티 데이터로 알림에 맥락(context) 추가
• 중요도 기반 알림 분류로 노이즈 감소

고카디널리티(High Cardinality)의 중요성

관측성에서 카디널리티란 데이터 속성의 고유한 값의 수를 말한다.

• 저카디널리티: status_code (200, 404, 500 등 몇 개 안 됨) → 모니터링에 적합
• 고카디널리티: request_id, user_id, commit_sha (수백만 개의 고유 값) → 관측성에 필수

고카디널리티 데이터가 중요한 이유: 디버깅할 때 "전체 에러율 5%"보다 "user_id=12345의 요청이 commit_sha=abc123 이후 100% 실패"라는 정보가 훨씬 유용하다. 이런 세밀한 슬라이싱은 고카디널리티 데이터 없이는 불가능하다.

전통적인 시계열 DB는 카디널리티가 높아지면 "조합 폭발(combinatorial explosion)"로 성능이 급락한다. 이것이 관측성 전용 백엔드(Honeycomb, ClickHouse 등)가 등장한 이유이다.

데이터 파이프라인 맥락의 예시

Monitoring만 있을 때:

[Alert] orders 테이블 행 수가 임계값 1000 이하 (현재: 47)
→ 담당자: "뭔가 잘못됐네. 어디서부터 봐야 하지?"
→ 수동으로 소스 확인 → ETL 로그 확인 → 스키마 비교 → 원인 파악에 수 시간

Observability가 있을 때:

[Alert] orders 테이블 행 수 이상 감지 (평소 대비 95% 감소)
→ 자동 리니지 추적: Source API → ETL Job → orders 테이블
→ 근본 원인: 업스트림 API의 스키마 변경 (order_date 컬럼 타입 변경)
→ 영향 범위: 대시보드 3개, 하류 테이블 7개
→ 담당자에게 원인 + 영향 + 관련 팀 정보까지 한 번에 전달
→ 해결 시간: 수 분

또 다른 예시 — Silent Failure:

[모니터링 시나리오]
ETL 작업: ✅ 성공 (에러 없음)
행 수: 10,000 (임계값 1,000 이상이므로 알림 없음)
→ 하지만 실제로는 중복 적재로 5,000건이 2번 들어간 것
→ 매출 대시보드가 2배로 부풀려져 경영진이 잘못된 의사결정
→ 모니터링은 "작업 성공 + 행 수 정상"이라 아무 알림 없음

[관측성 시나리오]
Distribution 모니터: order_id의 유니크 비율이 100% → 50%로 급락 감지
→ 자동 알림: "중복 데이터 의심"
→ 리니지로 원인 추적: ETL 재실행 시 idempotency 미적용

AIOps에서의 Observability 위치

Gartner AIOps 프레임워크. Observability는 왼쪽 Observe(Monitoring) 영역에 해당하며, Historical Analysis, Anomaly Detection, Performance Analysis, Correlation 등이 모두 Observability의 핵심 활동이다.

AIOps(AI for IT Operations)는 Observe → Engage → Act 세 단계가 순환하는 구조이다. Observability는 이 순환의 시작점이자 입력을 담당한다. Observe 단계에서 수집한 텔레메트리의 품질이 낮으면, 이후 Engage(인시던트 관리)와 Act(자동화)도 제대로 작동하지 않는다. 즉 Observability가 없으면 AIOps 전체가 무너진다.

데이터 엔지니어링 맥락에서도 동일하다. Data Observability가 파이프라인의 이상을 정확히 감지해야(Observe), 인시던트 대응(Engage)과 자동 복구(Act)가 가능해진다.

상호 보완 관계

둘은 경쟁이 아니라 함께 사용해야 한다:

Monitoring                    Observability
─────────                    ─────────────
"언제 문제가 생겼나"      +     "왜, 어디서, 어떻게 해결하나"
임계값 기반 알림          +     ML 기반 이상 탐지
사전 정의 대시보드        +     탐색적 분석 (ad-hoc 쿼리)
빠른 설정, 낮은 비용      +     깊은 인사이트, 높은 투자
─────────────────────────────────────────────
= 종합적인 데이터 신뢰성 확보

Monitoring은 "집에 화재 경보기를 설치하는 것"이고, Observability는 "왜 불이 났는지, 어디서 시작됐는지, 다른 방으로 번지고 있는지를 실시간으로 파악하는 것"이다.

Software Observability vs Data Observability

Software Observability(Datadog, New Relic 등)와 개념적 뿌리는 같지만 관측 대상이 다르다.

공통점: 두 영역 모두 다운타임이 발생하면 자가 치유되지 않으며, 시간이 지날수록 문제가 복합적으로 악화된다.

5가지 핵심 Pillars

Monte Carlo가 정의한 Data Observability의 5대 축이다. 이 프레임워크로 데이터 건강 상태를 체계적으로 평가할 수 있다.

1. Freshness (신선도)

데이터 테이블이 얼마나 최신인지, 업데이트 주기가 정상인지를 추적한다. 의사결정에서 오래된 데이터는 낭비된 시간과 비용과 동의어이다.

• 감지 예시: "매일 오전 6시에 갱신되는 테이블이 12시간째 업데이트 없음"
• 원인: 업스트림 소스 장애, ETL 작업 실패, 스케줄링 오류

2. Volume (볼륨)

데이터 테이블의 행 수나 크기에서 예기치 않은 변화를 감지한다. 누락이나 중복을 조기에 발견할 수 있다.

• 감지 예시: "어제 대비 90% 적은 데이터 적재", "갑자기 행 수가 2배로 증가"
• 원인: 소스 시스템 장애, 중복 적재, 필터 조건 변경

3. Distribution (분포)

데이터 값의 분포가 기대 범위 내에 있는지를 확인한다. NULL 비율, 유니크 값 비율, 값 범위 등을 추적한다.

• 감지 예시: "user_id 컬럼의 NULL 비율이 갑자기 40%로 증가", "price 컬럼에 음수 값 등장"
• 원인: 소스 데이터 변경, 매핑 오류, 비즈니스 로직 변경

4. Schema (스키마)

테이블 구조의 변경을 추적한다. 컬럼 추가, 삭제, 타입 변경은 데이터 장애의 가장 흔한 원인 중 하나이다.

• 감지 예시: "order_date 컬럼이 STRING에서 TIMESTAMP로 변경됨", "새 컬럼 3개 추가"
• 원인: 업스트림 팀의 스키마 마이그레이션, API 버전 변경

5. Lineage (리니지)

데이터가 소스에서 소비자까지 흐르는 전체 경로를 추적한다. 장애 발생 시 영향 범위를 파악하고 근본 원인을 역추적할 수 있다.

• 활용: "이 테이블에 문제가 생기면 어떤 대시보드가 영향받는가?"
• 가치: 장애 범위 파악, 영향도 분석, 데이터 소유권 관리

[Source A] ──▶ [ETL Job] ──▶ [Warehouse Table] ──▶ [BI Dashboard]
     │              │               │                    │
     └── Schema?    └── Freshness?  └── Volume?          └── 영향 범위
                                        Distribution?

구현 접근 방식

Data Observability는 메타데이터 모니터링, 통계 분석, 이상 탐지, 리니지, 알림, 근본 원인 분석, 워크플로우 통합을 결합한 시스템이다.

메타데이터 기반 모니터링

실제 데이터를 읽지 않고 메타데이터(행 수, 스키마 정보, 갱신 시각 등)를 ML로 분석하여 이상을 탐지한다. 이 접근법은 데이터 접근 권한 문제를 우회하고 성능 부하를 최소화한다.

자동 vs 규칙 기반

• 자동 (ML 기반): Monte Carlo처럼 히스토리 패턴을 학습하여 임계값 없이 이상 탐지. 설정 최소화, 커버리지 넓음
• 규칙 기반: Great Expectations처럼 팀이 명시적으로 검증 규칙 정의. 정밀도 높음, 비즈니스 로직 반영 가능

실무에서는 두 접근을 함께 사용한다. ML 기반으로 넓은 범위를 자동 감시하고, 핵심 테이블에는 규칙 기반 검증을 추가한다.

Data Quality vs Data Observability

두 개념은 상호 보완적이다. Quality가 목표(goal)라면, Observability는 수단(means)이다.

주요 도구 비교

Data Observability 도구는 크게 ML 자동 탐지, 규칙 기반 검증, dbt 네이티브 세 가지 접근으로 나뉜다.

접근 방식별 트레이드오프

• ML 자동 탐지 (Monte Carlo): 설정 최소, 커버리지 넓음. 하지만 비용이 높고 탐지 로직이 블랙박스
• 규칙 기반 (Great Expectations, Soda Core): 비즈니스 로직을 정확히 반영 가능. 하지만 규칙을 직접 작성·유지해야 하므로 확장이 어려움
• dbt 네이티브 (Elementary): dbt 워크플로우에 자연스럽게 통합. 하지만 dbt를 안 쓰면 의미 없음

실무에서는 ML 자동 탐지 + 규칙 기반을 함께 사용하는 것이 일반적이다. 넓은 범위는 ML로 커버하고, 핵심 테이블에는 명시적 규칙을 추가한다.

시장 동향 (2025-2026)

• Gartner 조사: 데이터/AI 리더의 53%가 이미 도입, 43%가 18개월 내 도입 예정
• 상용 시장 1위는 Monte Carlo (Gartner 2026 Market Guide 대표 벤더)
• 오픈소스 커뮤니티 최대는 Great Expectations
• dbt 생태계에서는 Elementary가 5,000+ 팀에서 사용

참고 자료

• What Is Data Observability? 5 Key Pillars To Know — Monte Carlo
• Incident Prevention: The 5 Pillars of Data Observability — Monte Carlo
• 61 Data Observability Use Cases From Real Data Teams — Monte Carlo
• Data Quality vs Data Observability — Metaplane
• Observability vs. Monitoring: What's the Difference? — IBM
• Data Observability vs Software Observability — Metaplane
• Three Pillars of Observability — IBM
• What is Data Observability? — Databricks

관련 개념

• Data Engineering: 상위 도메인
• Streaming Architecture: 실시간 데이터 파이프라인과 Observability의 관계