전통적인 모니터링은 잡이 성공했는지 실패했는지를 봅니다. 그런데 데이터 세계에는 더 교묘한 문제가 있습니다. 잡은 분명히 초록불로 성공했는데, 실제 데이터는 절반이 비어 있거나 어제보다 10분의 1로 줄어든 경우입니다. 이런 침묵의 장애를 잡으려면 잡 상태가 아니라 데이터 자체를 관측해야 합니다. 이것이 데이터 관측성입니다.
이 글에서는 데이터 관측성의 다섯 기둥, 구현 방법, 그리고 경보 피로를 피하는 운영 전략을 다룹니다.
왜 잡 성공만으로는 부족한가
파이프라인이 성공했다는 신호는 코드가 예외 없이 끝났다는 뜻일 뿐입니다. 원천 API가 빈 응답을 주거나, 업스트림 조인 키가 바뀌어 매칭이 0건이 되어도 코드는 멀쩡히 성공합니다. 비즈니스 대시보드의 숫자가 이상하다고 누군가 제보하기 전까지 아무도 모릅니다.
실제로 데이터 장애의 상당수는 코드 버그가 아니라 데이터 자체의 변화에서 옵니다. 그래서 관측 대상이 인프라에서 데이터로 확장되어야 합니다.
데이터 관측성의 다섯 기둥
업계에서 합의된 관측성의 다섯 축은 다음과 같습니다. 각각이 서로 다른 유형의 장애를 잡아냅니다.
- 신선도(Freshness): 데이터가 기대한 시점에 갱신됐는가
- 양(Volume): 행 수가 평소 범위 안에 있는가
- 분포(Distribution): 값의 범위와 null 비율이 정상인가
- 스키마(Schema): 컬럼과 타입이 바뀌지 않았는가
- 계보(Lineage): 어느 업스트림이 어느 다운스트림에 영향을 주는가
신선도와 양만 잘 잡아도 침묵의 장애 대부분을 조기에 발견할 수 있습니다. 계보는 장애 발생 시 영향 범위를 빠르게 파악하는 데 결정적입니다.
구현 방법
가장 단순한 시작점은 핵심 테이블에 품질 검사를 거는 것입니다. dbt test, Great Expectations, Soda 같은 도구로 행 수 임계, null 비율, 고유성, 값 범위를 선언적으로 검증합니다.
# Soda 체크 예시
checks for fct_orders:
- row_count between 9000 and 15000
- missing_percent(customer_id) < 1%
- freshness(created_at) < 6h
- duplicate_count(order_id) = 0한 단계 더 나아가면 과거 패턴을 학습해 동적 임계치를 만드는 이상 탐지를 도입할 수 있습니다. 요일별, 시간대별 패턴을 반영하면 고정 임계보다 오탐이 크게 줍니다.
경보 피로를 피하는 운영
관측성을 도입하면 처음엔 경보가 폭주합니다. 너무 많은 경보는 곧 무시되고, 무시되는 경보는 없는 것과 같습니다. 따라서 심각도를 계층화하세요. 비즈니스 핵심 테이블의 신선도 장애는 즉시 호출(page), 부차적 테이블의 분포 경고는 일일 다이제스트로 묶는 식입니다.
- SLA가 정의된 골드 테이블에만 강한 경보를 건다
- 경보마다 담당자(owner)와 런북을 명시한다
- 오탐이 잦은 검사는 임계를 조정하거나 제거한다
데이터 신뢰는 정확한 데이터에서 오는 것이 아니라, 틀렸을 때 가장 먼저 아는 데서 온다.
정리
데이터 관측성은 잡 성공을 넘어 데이터 자체의 신선도, 양, 분포, 스키마, 계보를 감시합니다. 핵심 테이블부터 선언적 품질 검사를 걸고, 동적 임계로 오탐을 줄이며, 심각도를 계층화해 경보 피로를 막으세요. 목표는 완벽한 데이터가 아니라, 문제가 생겼을 때 사용자보다 먼저 아는 것입니다.
