-
데이터 옵저버빌리티란?공부/데이터 2026. 4. 26. 16:28
1. 개요
데이터 옵저버빌리티란 무엇인가
데이터 옵저버빌리티(Data Observability)란 조직이 자신의 데이터 시스템 전반에 걸쳐 데이터의 건강 상태를 완전히 파악하고 이해할 수 있는 능력을 의미합니다. 자동화된 모니터링·알림·트리아지(triage)를 통해 데이터 품질 및 발견 가능성(discoverability) 문제를 사전에 식별하고 평가함으로써 이른바 "데이터 다운타임(Data Downtime)"을 제거하는 일련의 실천 방법론입니다. 즉, 데이터가 잘못되었을 때 조직이 가장 먼저 그 사실을 인지하고, 무엇이 깨졌는지, 어떻게 고쳐야 하는지를 파악할 수 있도록 데이터 파이프라인 전체에 완전한 가시성을 제공하는 개념입니다.
용어의 탄생과 역사
데이터 옵저버빌리티라는 용어는 2019년 Monte Carlo Data의 공동창업자이자 CEO인 Barr Moses가 처음 창안하였습니다. Moses는 이전에 Gainsight에서 근무하면서 매주 데이터 파이프라인이 깨지고 팀원들이 사후에 수동으로 복구 작업을 반복해야 하는 상황을 직접 경험하였습니다. 소프트웨어 엔지니어들이 오랫동안 누려왔던 인프라 가시성을 데이터 팀에도 동일하게 제공해야 한다는 문제의식에서 이 개념이 탄생하였으며, 사이트 신뢰성 엔지니어링(SRE)과 DevOps의 모범 사례를 데이터 운영(DataOps)에 접목하는 방식으로 발전시켰습니다.
소프트웨어 옵저버빌리티에서의 기원
데이터 옵저버빌리티는 소프트웨어 엔지니어링 분야의 옵저버빌리티 개념을 데이터 파이프라인에 적용한 것입니다. 소프트웨어 옵저버빌리티의 세 가지 기둥은 다음과 같습니다.
- 로그(Logs): 시스템 내에서 발생한 개별 이벤트를 기록한 것으로, 문제의 "왜(why)"를 이해하는 데 활용됩니다.
- 메트릭(Metrics): 시스템 성능과 자원 활용에 관한 정량적 데이터로, 추세 분석 및 이상 탐지에 사용됩니다.
- 트레이스(Traces): 분산 시스템에서 요청이 흐르는 경로를 추적한 것으로, 지연(latency)과 의존 관계를 파악하는 데 활용됩니다.
데이터 옵저버빌리티의 5대 기둥
Monte Carlo가 정의하고 업계 표준으로 자리잡은 5대 기둥은 다음과 같습니다.
기둥 설명 신선도(Freshness) 데이터가 최신 상태인지, 기대하는 주기대로 갱신되고 있는지를 확인합니다. 볼륨(Volume) 생성·수집·변환·이동되는 데이터의 양을 추적하여 완결성(completeness)을 측정합니다. 분포(Distribution) 데이터 값이 허용 범위 내에 있는지, 결측값·이상값 비율을 지속 모니터링합니다. 스키마(Schema) 컬럼 추가·삭제·타입 변경 등 예상치 못한 구조 변경을 자동으로 감지합니다. 리니지(Lineage) 데이터가 어디서 시작하여 어떤 경로로 흘러가는지, 어떤 업·다운스트림이 영향받는지 추적합니다. 시장 성장과 현황
2023년 기준 데이터 옵저버빌리티 시장 규모는 약 21억 4,000만 달러에 달하였으며, 연평균 성장률(CAGR) 12% 이상으로 확대되고 있습니다. 2026년 Gartner는 이 기술이 "있으면 좋은(nice-to-have)" 수준을 넘어 "전략적 필수(tactical necessity)" 역량으로 전환되었다고 명시하였습니다.
2. 데이터 옵저버빌리티가 필요한 이유
데이터 파이프라인의 복잡성 폭발적 증가
현대 기업의 데이터 환경은 과거와 비교할 수 없을 만큼 복잡해졌습니다. 조직들은 7년 전과 비교하여 약 5
6배에 달하는 데이터를 보유하고 있으며, 데이터 소스는 최소 34배 이상 늘어났습니다. AI·실시간 분석·고객 대면 애플리케이션 등 데이터에 의존하는 시스템이 급증하면서, 수많은 시스템이 서로 깊게 의존하는 구조가 되었습니다. 단 하나의 이상이 연쇄적인 장애로 번지기 매우 쉬운 환경입니다.
데이터 다운타임 문제
"데이터 다운타임"이란 데이터가 부분적으로 누락되거나 오류가 있거나 최신 상태가 아닌 기간을 의미합니다. Splunk의 2023년 보고서에 따르면, 전체 조직의 약 66%가 한 시간의 다운타임이 15만 달러(한화 약 2억 원) 이상의 비용을 초래한다고 보고하였습니다. 잘못된 데이터 하나가 비즈니스 의사결정, 고객 경험, 규제 준수 등 여러 영역에 동시다발적으로 영향을 미치기 때문에 그 비용은 단순한 IT 장애를 크게 상회합니다.
침묵하는 데이터 장애(Silent Data Failures)
데이터 장애의 가장 위험한 특성 중 하나는 명시적인 오류 메시지 없이 조용히 발생한다는 점입니다. 파이프라인은 정상적으로 실행 완료되었다는 신호를 보내면서도 실제로는 잘못된 값이나 결측 레코드를 하위 시스템에 전달하고 있을 수 있습니다. 이러한 침묵하는 장애는 며칠에서 몇 주 동안 발견되지 않을 수 있으며, 그 사이에 비즈니스 의사결정에 심각한 오류를 유발합니다.
데이터 품질 비용의 규모
- Gartner 추정: 데이터 품질 저하로 인한 평균 손실이 조직당 연간 1,290만~1,500만 달러
- 미국 기업 전체: 연간 손실 합산 3조 1,000억 달러
- Forrester(2023): "2023년 데이터 품질 저하로 수백만 달러가 손실되었으며, AI가 개입하지 않으면 향후 수십억 달러 규모의 손실로 확대될 잠재성이 있다"
- AI 프로젝트 미배포 비율: 87% (주요 원인: 데이터 품질 문제)
실제 사고 사례
기업 사고 내용 피해 규모 Unity Technologies (2022) 잘못된 데이터가 ML 학습 세트에 유입되어 광고 타겟팅 모델 성능 저하 약 1억 1,000만 달러 손실 Citibank (2020) 데이터 거버넌스 실패로 미국 OCC 규제 위반 4억 달러 벌금 Charles Schwab (2024) 잔액 불일치·부정확한 주식 데이터로 규제 보고 미흡 1억 3,600만 달러 벌금 Equifax 신용 점수 핵심 속성 값 오기록으로 부정확한 신용 점수 제공 집단 소송 Uber (2017) 수수료 계산 데이터 오류를 2년 반 동안 미발견 드라이버 전원 환불 (인당 약 900달러)
3. 데이터 퀄리티, 데이터 카탈로그와의 차이점
세 개념 비교
비교 항목 데이터 퀄리티 데이터 카탈로그 데이터 옵저버빌리티 핵심 질문 "이 데이터는 좋은가?" "이 데이터는 무엇이며 어디에 있는가?" "데이터 시스템이 지금 건강한가?" 범위 개별 데이터셋·필드 수준 조직 전체 데이터 자산 인벤토리 전체 파이프라인 및 시스템 시점 배치 검증 (사전 또는 사후) 정적 메타데이터 + 주기적 갱신 실시간 지속 모니터링 접근 방식 규칙 기반 (반응적 중심) 탐색·문서화 중심 자동 이상 탐지 (능동적 중심) 주요 사용자 데이터 엔지니어, 분석가 거버넌스팀, 비즈니스 사용자 데이터 엔지니어, SRE 대표 도구 Great Expectations, dbt Tests, Soda Core Apache Atlas, DataHub, Alation, Collibra Monte Carlo, Anomalo, Sifflet 데이터 퀄리티(Data Quality)
데이터 퀄리티는 특정 데이터 자산이 목적에 얼마나 적합한지를 측정하고 개선하는 활동입니다. 정확성(Accuracy), 완전성(Completeness), 일관성(Consistency), 적시성(Timeliness), 유일성(Uniqueness), 유효성(Validity) 등 여섯 가지 차원으로 정의됩니다. 명확히 정의된 규칙을 배치 검증하는 데 강점이 있으며, 데이터 계약(Data Contract) 기반으로 소스와 소비처 간 품질 기준을 합의할 때 핵심적인 역할을 합니다.
대표 도구: Great Expectations (Python 기반 검증 프레임워크), dbt Tests (SQL 변환 내 선언적 테스트), Soda Core (SodaCL YAML 문법 기반 검증)
데이터 카탈로그(Data Catalog)
데이터 카탈로그는 조직 내 모든 데이터 자산에 대한 메타데이터를 중앙화하여 관리하고, 데이터 탐색(discovery), 거버넌스(governance), 리니지(lineage) 추적을 가능하게 하는 인벤토리 시스템입니다. "이 데이터는 어디에 있는가, 무엇을 의미하는가, 누가 소유하는가, 어디서 흘러왔는가"라는 질문에 답합니다.
대표 도구: Apache Atlas, DataHub, Amundsen, Alation, Collibra, Atlan (2025년 Gartner MQ Leader)
세 개념의 상호 보완 관계
세 개념은 경쟁 관계가 아니라 계층적 상호 보완 관계에 있습니다. 성숙한 데이터 조직일수록 세 영역을 함께 운영하는 것이 일반적입니다.
- 데이터 카탈로그 → 데이터 퀄리티: 카탈로그가 제공하는 메타데이터(소유자, 중요도, 사용 빈도)를 바탕으로 품질 규칙 적용 우선순위를 결정합니다.
- 데이터 퀄리티 → 데이터 옵저버빌리티: 이미 정의된 품질 규칙과 임계값이 옵저버빌리티 시스템의 이상 탐지 기준선으로 활용됩니다.
- 데이터 옵저버빌리티 → 데이터 카탈로그: 옵저버빌리티가 탐지한 이상 신호(스키마 변경, 볼륨 급감)를 리니지 정보와 결합하여 영향받는 하위 데이터셋을 즉시 식별합니다.
- 데이터 옵저버빌리티 → 데이터 퀄리티: 이상 감지 후 데이터 퀄리티 도구의 세밀한 규칙 검증으로 정확히 어떤 품질 차원에서 문제가 발생했는지 확인합니다.
4. 데이터 옵저버빌리티 오픈소스 & 매니지드 서비스
오픈소스 도구
도구 주요 역할 가격 Great Expectations Python 기반 룰 검증, Data Docs 자동 생성 무료 (GX Core) dbt SQL 변환 + 테스트·문서화·컬럼 레벨 리니지 Core 무료 OpenLineage + Marquez 벤더 중립적 리니지 표준 및 수집 백엔드 완전 무료 Elementary Data dbt 네이티브 이상 탐지 + Slack 알림 OSS 무료 Evidently AI ML/LLM 데이터 드리프트·모델 성능 모니터링 Apache 2.0 무료 WhyLogs (WhyLabs) 100ms 이하 실시간 드리프트 탐지 2025년 오픈소스화 Apache Atlas Hadoop 생태계 메타데이터·거버넌스·리니지 완전 무료 SQLMesh dbt 대안 SQL 변환 + 강력한 내장 Audit 시스템 Core 무료 (Linux Foundation) Great Expectations(GX Core): 2024년 8월 v1.0 출시. 300개 이상의 내장 Expectation, Snowflake·Databricks·Spark 등 광범위한 소스 지원, Data Docs로 품질 결과를 HTML 문서로 자동 렌더링합니다.
dbt: SQL 변환의 사실상 표준.
not_null,unique,accepted_values등 내장 테스트와 자동 문서화, 컬럼 레벨 리니지를 단일 워크플로우에서 제공합니다. dbt Core는 완전 무료입니다.OpenLineage + Marquez: Linux Foundation 산하 오픈 스탠다드. Airflow, Spark, Flink, dbt 등 이기종 도구의 리니지 이벤트를 공통 스펙으로 수집하고 Marquez UI로 시각화합니다.
Elementary Data: dbt 패키지로 설치되어 별도 인프라 없이 행 수 이상·신선도·Null 비율 변화를 Z-스코어 기반으로 감지합니다. Slack/Teams/PagerDuty 알림을 지원합니다.
SQLMesh: Tobiko Data가 개발한 dbt의 대안적 SQL 변환 프레임워크로, 가상 개발 환경(Virtual Dev Environments)과 z_score·kl_divergence·chi_square를 포함한 통계 기반 내장 Audit이 특징입니다. 2025년 9월 Fivetran 인수 후 2026년 3월 Linux Foundation에 기부되어 현재 커뮤니티 거버넌스로 전환 중입니다.
매니지드/상용 서비스
서비스 포지셔닝 가격 Monte Carlo 데이터 신뢰성 플랫폼 선구자, ML 기반 자동 탐지 연간 $100K+ Acceldata 데이터 품질 + 비용 최적화 통합 옵저버빌리티 커스텀 견적 Bigeye 코드형 모니터링(Bigconfig), AI Trust Platform 커스텀 견적 Metaplane by Datadog 2025.04 Datadog 인수, 인프라+데이터 통합 옵저버빌리티 Datadog 플랜 Sifflet 비즈니스 임팩트 기반 통합 플랫폼, 자산 수 티어제 자산 수 기반 Anomalo 비감독 ML 자동 이상 탐지, 규제 산업 특화 테이블 수 기반 Monte Carlo: 2019년 창업, 시장을 사실상 정의한 선구자입니다. ML 기반 이상 탐지로 룰 작성 없이 이상 패턴을 자동 감지하며, 2025년에는 Observability Agents(자율 모니터링 + 근본 원인 자동 조사)를 출시하였습니다.
Anomalo: 비감독 ML로 사전 정의된 룰 없이 데이터 패턴을 학습하여 이상을 감지합니다. UBS 등 금융 기관이 주요 고객이며, Snowflake Native App으로 원본 데이터가 환경 밖으로 유출되지 않아 보안성이 높습니다.
Metaplane by Datadog: 2025년 4월 23일 Datadog에 인수되었습니다. Datadog의 APM·인프라 모니터링과 통합하여 소프트웨어+데이터 통합 옵저버빌리티 단일 플랫폼을 목표로 합니다.
Sifflet: 비즈니스 임팩트 기반으로 인시던트 우선순위를 지정하는 통합 플랫폼입니다. 하이브리드·셀프호스팅 배포 옵션을 제공하여 규제 산업에 적합합니다.
5. 도구 조합으로 옵저버빌리티를 구현할 수 있는 방안
데이터 옵저버빌리티는 단일 도구로 완성되지 않습니다. 데이터 품질, 리니지, 카탈로그, 알림 역할을 담당하는 도구들을 조합하여 통합 관측 체계를 구성하는 것이 현재의 모범 사례입니다.
스택 전체 비교
스택 데이터 품질 리니지·카탈로그 이상 탐지 난이도 비용 적합 대상 A: dbt + GE + DataHub Great Expectations DataHub 수동 규칙 높음 무료 풀스택 오픈소스 선호 팀 B: dbt + Elementary dbt Tests + Elementary dbt 리니지 Z-스코어 자동 탐지 낮음 무료 dbt 중심 소규모~중간 팀 C: Airflow + OpenLineage + Marquez 별도 도구 필요 Marquez (리니지) 없음 중간 무료 이기종 파이프라인 리니지 통합 D: Cloud-Native 클라우드 내장 클라우드 내장 제한적 낮음 종량제 특정 클라우드 단일 환경 E: SQLMesh 내장 Audit SQLMesh Audit (SQL) 미지원 (로드맵) 통계 Audit (z_score 등) 낮음 무료 안전 배포 우선, 카탈로그 불필요 팀
Stack A: dbt + Great Expectations + DataHub (오픈소스 풀스택)
가장 널리 채택된 오픈소스 데이터 옵저버빌리티 풀스택입니다. 세 도구가 각각 변환·검증·카탈로그 역할을 담당하고 공식 통합으로 연결됩니다.
도구 역할 dbt SQL 변환 및 내장 스키마 테스트 Great Expectations 심층 통계 기반 데이터 검증 및 Expectation Suite 관리 DataHub 메타데이터 카탈로그, 컬럼 레벨 리니지, GE 검증 결과 수집 DataHub는
DataHubValidationAction으로 Great Expectations 실행 결과를 수집하고, dbtmanifest.json을 파싱하여 컬럼 수준 리니지를 자동으로 구성합니다.- 강점: 스키마 변경 감지, 컬럼 레벨 리니지, 자동 품질 문서화, 공식 통합 안정적
- 약점: 세 도구의 설정이 분리되어 초기 통합 비용이 높으며, ML 기반 이상 탐지는 Elementary 등 보완 필요
Stack B: dbt + Elementary (dbt 네이티브 경량)
dbt 생태계 안에서 모든 옵저버빌리티 기능을 처리하는 가장 낮은 복잡도의 조합입니다. 별도 인프라 없이 빠르게 시작할 수 있어 소규모~중간 규모 팀에 적합합니다.
도구 역할 dbt SQL 변환, 내장 테스트, 컬럼 레벨 리니지 시각화 Elementary dbt 아티팩트 기반 이상 탐지, HTML 리포트, Slack/PagerDuty 알림 Elementary는 dbt 패키지로 설치되어 dbt 런 완료 후 행 수 이상, 신선도, Null 비율 변화를 Z-스코어 기반으로 자동 감지합니다.
edr report로 HTML 리포트를,edr monitor로 Slack 알림을 발송합니다.- 강점: 설정이 단순하고 dbt 워크플로우와 완전히 통합되어 추가 인프라 불필요
- 약점: dbt 이외의 파이프라인(Spark, Flink 등) 지원 불가, 별도 카탈로그 기능 없음
Stack C: Airflow + OpenLineage + Marquez (리니지 중심)
파이프라인 오케스트레이션과 크로스 플랫폼 리니지 추적에 특화된 조합입니다. Airflow, Spark, dbt, Dagster 등 이기종 도구가 혼재하는 환경에서 단일 리니지 뷰를 제공합니다.
도구 역할 Apache Airflow 파이프라인 스케줄링 및 DAG 실행 OpenLineage 실행 시점 메타데이터·리니지 수집 표준 (Linux Foundation 오픈 스펙) Marquez OpenLineage 이벤트 저장 및 리니지 UI 시각화 OpenLineage Airflow Provider 설치만으로
AIRFLOW__OPENLINEAGE__TRANSPORT환경변수를 통해 Marquez에 자동으로 리니지 이벤트가 전송됩니다. DAG 실패 시 다운스트림 영향 범위(Blast Radius)를 즉시 파악할 수 있습니다.- 강점: 이기종 도구 간 리니지 표준화, 벤더 종속 없음, 완전 무료
- 약점: 데이터 품질 검증(Quality Checks)은 별도 도구(dbt Tests, GE 등)로 보완 필요
Stack D: Cloud-Native (AWS / GCP / Azure)
특정 클라우드 환경에서 운영하는 조직이 벤더 관리형 서비스만으로 옵저버빌리티를 구성하는 방안입니다.
클라우드 데이터 품질 카탈로그 리니지 알림 AWS Glue Data Quality (DQDL) Glue Data Catalog Glue DataBrew CloudWatch + EventBridge GCP Dataplex 품질 규칙 Dataplex Universal Catalog Dataplex Lineage API Cloud Monitoring Azure Purview Data Quality Microsoft Purview Purview + OpenLineage Azure Monitor - AWS: Glue Data Quality는 DQDL 문법으로 규칙을 정의하고 검증 결과 메트릭을 CloudWatch로 발행합니다. EventBridge 규칙으로 품질 임계치 위반 시 SNS → Slack/PagerDuty 알림을 연결합니다. - GCP: Dataform은 BigQuery 기반 SQL 변환 도구로, 저장소 메타데이터가 Dataplex Universal Catalog에 자동 동기화됩니다. Dataplex는 BigQuery 테이블에 대한 자동 프로파일링과 품질 규칙 실행을 지원합니다. - Azure: ADF 파이프라인을 Microsoft Purview에 연결하면 소스·출력 데이터셋 메타데이터와 리니지 정보가 자동으로 수집됩니다. OpenLineage API를 통해 Databricks 등 이기종 환경의 리니지도 통합됩니다. - 강점: 단일 클라우드 환경에서 설정이 단순하고 관리 부담이 낮음 - 약점: 멀티 클라우드·이기종 환경에서 리니지 단절, 클라우드 벤더 종속
Stack E: SQLMesh 기반 스택 (실험적)
SQLMesh는 dbt의 대안적 SQL 변환 프레임워크로, 강력한 내장 Audit 시스템이 특징입니다. 그러나 2026년 4월 현재 Great Expectations·OpenMetadata와의 공식 통합이 존재하지 않아 완전한 옵저버빌리티 스택 구성에는 제약이 있습니다.
SQLMesh 내장 Audit (GX 대체 가능 범위)
SQLMesh는 별도 도구 없이 SQL 기반으로 다양한 데이터 품질 검사를 선언할 수 있습니다.
카테고리 내장 Audit NULL·행 수 not_null,at_least_one,not_null_proportion,number_of_rows고유성 unique_values,unique_combination_of_columns허용 값 accepted_values,not_accepted_values수치 범위 accepted_range,sequential_values통계적 mean_in_range,stddev_in_range,z_score,kl_divergence,chi_square문자열 not_empty_string,valid_uuid,valid_email,valid_url,match_regex_pattern_list모든 Audit에는
_non_blocking변형이 있어 파이프라인을 중단하지 않고 경고만 발생시킬 수 있습니다.-- SQLMesh 모델 파일 내 Audit 선언 예시 MODEL ( name analytics.fct_daily_sales, audits ( not_null(columns := [sales_date, total_revenue]), accepted_range(column := total_revenue, min_v := 0), z_score(column := order_count, threshold := 3.0), number_of_rows(threshold := 1) ) );Great Expectations 연동 현황
SQLMesh 공식 통합 목록에 Great Expectations는 포함되어 있지 않습니다. 기술적으로는 SQLMesh Python 모델 안에서 GX Checkpoint를 수동 호출할 수 있으나, 공식 문서·커뮤니티 사례가 없어 유지 관리 부담이 큽니다. SQLMesh의
pre_statements/post_statements는 SQL 명령만 실행 가능하여 Python 기반 GX를 직접 연결하기 어렵습니다.OpenMetadata 연동 현황
OpenMetadata에 SQLMesh 커넥터가 존재하지 않습니다. 2024년 12월 양측 모두에서 Feature Request가 제출되었으나 구현 진행 중인 증거가 없습니다. SQLMesh는 OpenLineage 이벤트를 방출하지 않으므로, OpenMetadata의 OpenLineage 커넥터를 통한 우회 경로도 현재 차단되어 있습니다.
- OpenMetadata GitHub Issue #19176 "SQLMesh Lineage Support" → Closed (구현 없이 종료)
- SQLMesh GitHub Issue #3565 "SQLMesh Lineage Integration with Data Catalog" → Open (담당자·마일스톤·PR 없음)
권고사항
상황 권고 카탈로그·리니지가 불필요하고 배포 안전성이 최우선 SQLMesh 내장 Audit으로 시작. 통계 Audit(z_score 등)이 GX 상당 부분 대체 가능 카탈로그·리니지·GE 통합이 모두 필요 dbt + GE + DataHub(또는 OpenMetadata) 스택 권장 SQLMesh + 외부 카탈로그 연동 검토 중 공식 커넥터 릴리즈 시점 모니터링 후 도입 결정
성숙도 기반 도입 가이드
데이터 옵저버빌리티는 하루아침에 완성하려 하지 않는 것이 중요합니다. 단계적으로 역량을 확장하는 접근법이 현실적이고 효과적입니다.
단계 기간 핵심 역량 권장 도구 목표 지표 Level 1 0~3개월 기본 품질 테스트 dbt Core (또는 SQLMesh Audit) 테스트 통과율, 신선도 SLA 준수율 Level 2 3~6개월 리니지 추적 • OpenLineage + Marquez (또는 DataHub) 평균 근본 원인 탐지 시간(MTTD) Level 3 6~12개월 이상 탐지·자동 알림 • Elementary (또는 Great Expectations) + Slack/PagerDuty 오탐율, 선제 감지율 Level 4 12개월+ SLA 관리·데이터 계약 전체 스택 + SLO 프레임워크 데이터 가용성, SLA 준수율, MTTR
6. 구현 예시
시나리오: 일별 매출 리포트 파이프라인
매일 오전 6시 주문 이벤트를 수집하여 일별 매출 집계 테이블을 생성하고 BI 대시보드에 제공하는 파이프라인을 가정합니다.
보장해야 할 품질 기준:
- 신선도: 원천 데이터가 오전 5시 이전에 적재되어야 합니다.
- 볼륨: 일별 주문 건수가 전일 대비 50% 이상 감소하면 이상으로 판단합니다.
- 스키마:
order_id,amount,customer_id컬럼 누락 불가입니다. - 품질:
amount는 0 초과,order_status는 정의된 값만 허용합니다.
예시 1: dbt + Elementary (Stack B 기준)
# models/staging/sources.yml — 신선도·스키마·품질 검사 version: 2 sources: - name: raw tables: - name: orders loaded_at_field: event_timestamp freshness: warn_after: {count: 6, period: hour} error_after: {count: 12, period: hour} columns: - name: order_id tests: - unique - not_null - name: amount tests: - not_null - dbt_utils.accepted_range: min_value: 0 inclusive: false - name: order_status tests: - accepted_values: values: ['pending', 'confirmed', 'shipped', 'delivered', 'cancelled'] # Elementary 이상 탐지 (schema.yml) models: - name: fct_daily_sales tests: - elementary.table_anomalies: table_anomalies: - row_count # 볼륨 이상 - freshness # 신선도 이상 timestamp_column: sales_date sensitivity: 3 # Z-스코어 임계값 columns: - name: total_revenue tests: - elementary.column_anomalies: column_anomalies: - sum - average - null_count예시 2: Great Expectations Suite (Stack A 기준)
import great_expectations as gx context = gx.get_context() validator = context.get_validator( batch_request=batch_request, expectation_suite_name="daily_sales.critical" ) # 완전성(Completeness) validator.expect_column_values_to_not_be_null("sales_date") validator.expect_column_values_to_not_be_null("total_revenue") # 유효성(Validity) validator.expect_column_values_to_be_between( column="total_revenue", min_value=0, max_value=10_000_000, mostly=0.999 ) # 고유성(Uniqueness) validator.expect_column_values_to_be_unique("sales_date") # 볼륨(Volume) validator.expect_table_row_count_to_be_between(min_value=1, max_value=3650) validator.save_expectation_suite()예시 3: SQLMesh 내장 Audit (Stack E 기준)
-- SQLMesh 모델 파일 내 Audit 선언 (별도 도구 불필요) MODEL ( name analytics.fct_daily_sales, audits ( not_null(columns := [sales_date, total_revenue, order_id]), unique_values(columns := [sales_date]), accepted_range(column := total_revenue, min_v := 0), z_score(column := order_count, threshold := 3.0), -- 볼륨 이상 탐지 number_of_rows(threshold := 1) ) );예시 4: Airflow + OpenLineage 파이프라인 (Stack C 기준)
# AIRFLOW__OPENLINEAGE__TRANSPORT 환경변수로 Marquez에 자동 전송됩니다. from airflow import DAG from airflow.operators.bash import BashOperator from datetime import datetime with DAG(dag_id="daily_sales_report", schedule_interval="0 6 * * *", start_date=datetime(2024, 1, 1)) as dag: check_freshness = BashOperator( task_id="check_freshness", bash_command="dbt source freshness --select source:raw.orders", ) run_staging = BashOperator( task_id="run_staging", bash_command="dbt run --select staging", ) run_tests = BashOperator( task_id="run_tests", bash_command="dbt test --select staging", ) run_marts = BashOperator( task_id="run_marts", bash_command="dbt run --select marts.sales", ) run_monitor = BashOperator( task_id="run_monitor", bash_command="edr monitor --slack-webhook $SLACK_WEBHOOK_URL", ) check_freshness >> run_staging >> run_tests >> run_marts >> run_monitor예시 5: Slack/PagerDuty 알림 라우팅 패턴
def route_alert(alert: dict) -> None: """ 심각도·SLA 위반 여부에 따른 알림 채널 분기: - critical + SLA 위반 → PagerDuty (온콜 담당자 즉시 호출) - critical → #data-critical Slack 채널 - warning → #data-quality-monitoring Slack 채널 - info → Data Docs에만 기록 """ if alert["severity"] == "critical" and alert.get("sla_breach"): trigger_pagerduty_incident(routing_key=PAGERDUTY_KEY, alert=alert) elif alert["severity"] == "critical": send_slack_alert(SLACK_CRITICAL_WEBHOOK, alert) elif alert["severity"] == "warning": send_slack_alert(SLACK_MONITORING_WEBHOOK, alert)
7. 요약
데이터 옵저버빌리티는 2019년 Barr Moses가 소프트웨어 옵저버빌리티 개념을 데이터 파이프라인에 적용하면서 탄생한 개념으로, 이제 데이터 중심 조직의 핵심 인프라 역량으로 자리매김하였습니다.
핵심 요점 정리
왜 필요한가
데이터 파이프라인의 복잡성이 폭발적으로 증가하면서 침묵하는 데이터 장애(Silent Data Failures)가 비즈니스 의사결정, AI/ML 모델 성능, 규제 준수에 심각한 영향을 미치고 있습니다. Gartner는 데이터 품질 저하로 인한 평균 손실이 조직당 연간 1,290만 달러 이상이라고 추정하였으며, AI 프로젝트의 87%가 데이터 품질 문제로 배포에 실패하고 있습니다.
무엇이 다른가
개념 핵심 역할 데이터 퀄리티 "이 데이터가 좋은가"를 정의하고 검증합니다. 데이터 카탈로그 "이 데이터가 어디에 있고 무엇인가"를 관리합니다. 데이터 옵저버빌리티 "전체 시스템이 지금 건강한가"를 실시간으로 감시합니다. 세 개념은 경쟁 관계가 아닌 계층적 상호 보완 관계입니다. 성숙한 데이터 조직은 세 영역을 통합적으로 운영합니다.
무엇을 써야 하나
상황 권장 스택 dbt 중심 소규모~중간 팀 Stack B: dbt + Elementary 풀스택 오픈소스 + 카탈로그 필요 Stack A: dbt + GE + DataHub 이기종 파이프라인 리니지 통합 Stack C: Airflow + OpenLineage + Marquez 특정 클라우드 단일 환경 Stack D: Cloud-Native 배포 안전성 최우선, 카탈로그 불필요 Stack E: SQLMesh 내장 Audit 엔터프라이즈 자동화 + 넓은 통합 상용: Monte Carlo 또는 Anomalo Datadog 기반 인프라 운영 중 상용: Metaplane by Datadog 어떻게 시작하나
Level 1(기본 품질 테스트)에서 시작하여 리니지 추적, 이상 탐지, SLA 관리로 점진적으로 역량을 확장하는 성숙도 모델이 현실적이고 효과적입니다. 전체 스택을 한 번에 도입하려 하지 않고, 각 단계에서 가치를 확인하며 진행하는 것이 중요합니다.
데이터 옵저버빌리티의 미래
AI·생성형 AI 애플리케이션이 확산될수록 데이터 신뢰성은 더욱 중요해지고 있습니다. 2025년 기준 주요 벤더들은 자율 에이전트(Monte Carlo Observability Agents, Anomalo Data Insights Agent, Sifflet Sentinel)를 출시하면서 수동 설정 없이 스스로 모니터링하고 근본 원인을 분석하는 방향으로 진화하고 있습니다. 데이터 옵저버빌리티는 단순한 운영 도구를 넘어, 신뢰할 수 있는 AI 시스템 구축의 핵심 전제 조건이 되고 있습니다.