티스토리 뷰

1. 데이터 관측가능성(Data Observability, 데이터 옵저버빌리티)은 데이터가 제때·제대로·정상적으로 흐르는지 파이프라인 전체를 지속적으로 지켜보는 활동입니다.
2. 핵심은 최신성·볼륨·분포·스키마·리니지 5가지이며, 목표는 현업보다 먼저 데이터 문제를 알아채는 것입니다.
3. 2026년 현재 흐름은 AI용 데이터 신뢰성, 앱·데이터 관측 통합, 개인정보 보호 설계로 넘어가고 있습니다.
데이터를 다루는 조직이라면 한 번쯤 이런 연락을 받습니다.
"오늘 매출 대시보드 숫자가 이상한데요? 어제의 3% 밖에 안 나와요."
확인해 보면 새벽 적재 작업은 "성공"으로 끝나 있습니다. 서버도, DB도, 배치 스케줄러도 전부 정상입니다. 그런데 원천 API 인증키가 만료되어 빈 데이터가 성공적으로 적재된 상태였습니다. 시스템은 멀쩡한데 데이터가 틀린 것이고, 이 사실을 가장 먼저 안 사람은 데이터팀이 아니라 현업이었습니다.
이런 "조용한 데이터 장애"를 잡기 위해 등장한 개념이 데이터 관측가능성입니다. 이 글에서는 정의와 목적, 구성요소와 5대 핵심요소, 도입 방법과 보안 관점, 그리고 최신 트렌드와 향후 방향까지 정리했습니다.
🎯 데이터 관측가능성이란?
데이터 관측가능성은 조직이 비즈니스에 영향을 미치기 전에 데이터 문제를 감지·진단·예방할 수 있도록, 수집 파이프라인에서 스토리지 계층, 다운스트림 분석에 이르기까지 데이터 시스템 전반의 상태·품질·안정성·성능을 지속적으로 모니터링하는 관행과 관련 프로세스를 말합니다.
Gartner는 데이터 관측가능성 도구를 데이터 생태계의 상태, 성능, 그리고 비용을 이해하게 해주는 플랫폼으로 정의합니다. 즉 "데이터가 맞는가"뿐 아니라 "파이프라인이 잘 도는가", "돈이 얼마나 드는가"까지 봅니다.
| 구분 | 내용 |
|---|---|
| 한 줄 정의 | 데이터 파이프라인의 건강검진 + 24시간 CCTV |
| 관찰 대상 | 데이터 자체(내용) · 파이프라인(흐름) · 인프라(성능) · 비용 |
| 핵심 질문 | 데이터가 제때 왔나? 충분히 왔나? 정상 값인가? 구조가 바뀌었나? 어디에 영향을 주나? |
| 목표 | 데이터 다운타임(데이터가 틀리거나 없는 시간) 최소화 |
| 영문·동의어 | Data Observability, 데이터 옵저버빌리티, 데이터 가시성 |
🧩 모니터링·데이터 품질·IT 관측가능성과 뭐가 다를까?
비슷한 용어가 많아서 가장 많이 헷갈리는 부분입니다.
| 구분 | IT 관측가능성 (APM 등) | 데이터 품질 테스트 | 데이터 관측가능성 |
|---|---|---|---|
| 관찰 대상 | 서버·앱·네트워크 | 정해 둔 테이블·컬럼 규칙 | 데이터 + 파이프라인 전체 |
| 주요 신호 | 메트릭·이벤트·로그·트레이스 | 규칙 통과/실패 | 최신성·볼륨·분포·스키마·리니지 |
| 잡는 문제 | 시스템 장애, 응답 지연 | 이미 알고 있는 문제 | 예상하지 못한 문제까지 |
| 방식 | 임계치·APM 에이전트 | 사람이 규칙을 직접 작성 | ML 기준선 학습 + 규칙 병행 |
| 질문 예시 | 서버가 살아 있나? | 금액이 음수인가? | 왜 오늘 건수가 평소의 3%지? |
🏗 구성도와 구성요소

| 구성요소 | 역할 | 실무 예시 |
|---|---|---|
| 메타데이터 수집 | 행 수, 갱신 시각, 스키마, 쿼리 로그, 작업 이력을 수집 | DW의 information_schema, 쿼리 히스토리, 오케스트레이터 로그 |
| 이상탐지 | 과거 패턴을 학습해 정상 범위를 벗어나면 탐지 | 요일별 적재 건수 기준선, NULL 비율 급증 탐지 |
| 근본원인·영향 분석 | 리니지로 상류 원인과 하류 영향 범위 추적 | 원천 API 장애 → 영향받는 대시보드 12개 식별 |
| 알림·통지 | 담당자에게 즉시 전달, 중요도별 라우팅 | Slack·메일·PagerDuty, 소유자 자동 지정 |
| 대시보드 | 데이터 헬스 점수, SLA 준수율, 인시던트 현황 시각화 | 도메인별 데이터 신뢰도 점수판 |
| 자동화 | 모니터 자동 생성, 티켓 발행, 이상 시 파이프라인 차단 | 문제 데이터가 BI로 넘어가기 전 서킷브레이커 작동 |
| 데이터 거버넌스 (연계) | 카탈로그·소유자·데이터 계약·접근통제와 연결 | 관측 결과를 카탈로그의 신뢰도 표시에 반영 |
🔍 5대 핵심요소 (Five Pillars)

실제로 어떻게 측정하는지 간단한 SQL로 보면 개념이 훨씬 쉽게 잡힙니다.
| 핵심요소 | 보는 것 | 측정 예시 | 이상 신호 |
|---|---|---|---|
| 최신성 (Freshness) | 마지막 갱신 시각 | SELECT MAX(updated_at) FROM orders |
예정 시각이 지나도 갱신 없음 |
| 볼륨 (Volume) | 행 수·파일 크기 | SELECT COUNT(*) FROM orders WHERE dt = CURRENT_DATE |
평소 대비 급감·급증 |
| 분포 (Distribution) | NULL 비율, 값 범위, 고유값 | SELECT AVG(CASE WHEN email IS NULL THEN 1 ELSE 0 END) FROM users |
NULL 비율 급증, 범위 밖 값 |
| 스키마 (Schema) | 컬럼 추가·삭제·타입 | SELECT column_name, data_type FROM information_schema.columns |
예고 없는 구조 변경 |
| 리니지 (Lineage) | 테이블·컬럼 간 의존 관계 | 쿼리 로그 파싱, OpenLineage 이벤트 | 장애 시 영향 범위 산정 |
📈 이상탐지는 이렇게 동작합니다

"하루 10만 건 미만이면 경보" 같은 고정 임계치는 월말·주말·명절 패턴을 반영하지 못해 오탐이 많습니다. 최근 도구들은 과거 데이터를 학습해 그날 기대되는 범위를 계산하고, 그 범위를 벗어날 때만 알립니다.
📊 지표 체계
관측가능성은 "무엇을 숫자로 볼 것인가"가 정해져야 운영이 됩니다. 품질·성능 지표에 더해 운영 지표와 비용 지표까지 보는 것이 최근 추세입니다.
| 지표 분류 | 대표 지표 | 의미 |
|---|---|---|
| 데이터 품질 지표 | 완전성, 정확성, 유효성, 일관성, 유일성, 적시성 | 데이터 자체가 믿을 만한가 |
| 성능 지표 | 파이프라인 실행 시간, 적재 지연, 작업 실패율, 처리량 | 데이터가 제시간에 잘 흐르는가 |
| 운영 지표 | MTTD(탐지 시간), MTTR(복구 시간), 월간 인시던트 수, 데이터 SLA 준수율 | 문제를 얼마나 빨리 알고 고치는가 |
| 비용 지표 | 쿼리·스토리지 비용, 미사용 테이블, 중복 파이프라인 | 데이터 운영에 돈이 새고 있지 않은가 |
🔄 데이터 인시던트 대응 흐름

| 단계 | 하는 일 | 사용하는 기능 |
|---|---|---|
| 1. 감지 | 모니터가 이상 징후 탐지 | 이상탐지, 알림 |
| 2. 진단 | 어디서부터 잘못됐는지 추적 | 리니지, 쿼리 로그, 작업 이력 |
| 3. 영향 분석 | 어떤 보고서·모델·사용자가 영향받는지 파악 | 하류 리니지, 소유자 정보 |
| 4. 해결 | 원인 조치, 재적재, 소비자 공지 | 티켓 연동, 자동화 |
| 5. 예방 | 재발 방지 모니터·규칙·계약 추가 | 데이터 계약, 모니터 자동 생성 |
🛠 도입 방법 (단계별)
| 순서 | 내용 | 팁 |
|---|---|---|
| 1 | 핵심 데이터 자산 선정 | 매출·결제·규제 보고 등 틀리면 바로 사고가 나는 테이블부터 |
| 2 | 소유자·SLA 정의 | "몇 시까지, 누가 책임지는가"가 없으면 알림이 갈 곳이 없음 |
| 3 | 기본 모니터 적용 | 최신성·볼륨·스키마 3가지는 메타데이터만으로 빠르게 시작 가능 |
| 4 | 리니지 연결 | 쿼리 로그·오케스트레이터 연동으로 영향 범위 자동화 |
| 5 | 알림 라우팅·튜닝 | 중요도별 채널 분리, 오탐 모니터는 과감히 정리 (알림 피로 방지) |
| 6 | 데이터 계약·자동 차단 | 생산자·소비자 간 스키마·품질 약속을 코드로 관리 |
| 7 | 운영 지표 관리 | MTTD·MTTR·인시던트 수를 월간 보고로 추적 |
대표 도구
| 구분 | 예시 |
|---|---|
| 상용 플랫폼 | Monte Carlo, Bigeye, Metaplane(Datadog), Acceldata, Sifflet, Anomalo 등 |
| 오픈소스 | Great Expectations, Soda Core, Elementary(dbt), OpenLineage + Marquez 등 |
| 플랫폼 내장 | Snowflake·Databricks 등 데이터 플랫폼의 품질 모니터링 기능 |
⚖️ 장단점
| 구분 | ✅ 장점 | ❌ 단점·과제 |
|---|---|---|
| 탐지 | 현업보다 먼저 문제 인지 (MTTD 단축) | 초기 학습 기간 동안 오탐 발생 |
| 진단 | 리니지로 원인·영향 범위 즉시 파악 | 리니지 수집 범위가 도구·연동에 따라 제한적 |
| 신뢰 | 의사결정·AI 모델의 입력 데이터 신뢰도 향상 | 도구 도입만으로는 조직 문화가 바뀌지 않음 |
| 효율 | 수작업 품질 점검 감소, 미사용 자산 정리 | 테이블 수가 많으면 비용이 크게 증가 |
| 보안 | 이상 대량 조회·삭제 등 이상 징후 포착 | 관측 도구 자체가 민감 데이터에 접근하는 위험 |
🔐 보안 담당자가 봐야 할 포인트
데이터 관측가능성은 데이터팀의 도구로 알려져 있지만, 보안 관점에서도 쓸모가 많고 동시에 새로운 위험도 만듭니다.
보안에 활용할 수 있는 신호
| 관측 신호 | 보안 관점 해석 | 활용 |
|---|---|---|
| 볼륨 급증 (조회·추출) | 대량 데이터 반출 징후 | DLP·DB 접근제어 로그와 교차 확인 |
| 볼륨 급감·테이블 삭제 | 랜섬웨어, 권한 오남용, 오삭제 | 백업 복구 판단, 변경 이력 추적 |
| 스키마 변경 | 새로운 개인정보 컬럼 추가 | 개인정보 식별·암호화 대상 갱신 |
| 리니지 | 개인정보가 어디서 어디로 흐르는지 | 개인정보 흐름도 현행화, 파기 대상 추적 |
| 쿼리 로그 | 평소와 다른 계정·시간대 접근 | 비정상 접근 탐지 룰에 반영 |
관측 도구 자체의 위험
| 점검 항목 | 확인 내용 | 체크 |
|---|---|---|
| 연동 계정 권한 | 메타데이터·쿼리 이력 읽기 전용, 데이터 본문 접근 최소화 | ☐ |
| 샘플 데이터 수집 | 샘플링 기능 비활성화 또는 민감 컬럼 마스킹 | ☐ |
| 외부 반출 | SaaS로 전송되는 정보 범위, 저장 위치(리전), 보관 기간 | ☐ |
| 알림 채널 | Slack·메일 알림에 실제 데이터 값(개인정보) 포함 여부 | ☐ |
| 접근통제 | 관측 대시보드 접근자 권한 분리, 접근 로그 보관 | ☐ |
| 공급망 | 벤더 보안 인증, 연동 키 관리·교체 주기 | ☐ |
✅ 제시 내용 검수 결과 (틀린 점·보완점)
처음 정리했던 정의와 키워드를 최신 자료 기준으로 다시 점검했습니다.
| 항목 | 기존 정리 | 검수 결과 | 보완 내용 |
|---|---|---|---|
| 정의 | 상태·품질·안정성·성능을 지속 모니터링 | ✅ 적절 | Gartner 정의 기준으로 비용(Cost) 관점 추가 |
| 구성요소: 데이터 거버넌스 | 구성요소로 분류 | ⚠️ 보완 | 관측가능성의 구성요소라기보다 연계 영역. 관측 결과가 거버넌스를 뒷받침하는 관계 |
| 구성요소 누락 | 메타데이터·이상탐지·알람·대시보드·자동화 | ⚠️ 보완 | 근본원인 분석(RCA)과 영향도 분석이 빠짐 (Gartner도 분석·문제 해결을 핵심 기능으로 봄) |
| 5대 핵심요소 | 최신성·볼륨·분포·스키마·리니지 | ✅ 대체로 적절 | 국제 표준이 아니라 업계(Monte Carlo)에서 제안해 사실상 표준처럼 쓰이는 프레임워크. 리니지는 '지표'가 아닌 '맥락' 성격 |
| 지표 | 품질 지표·성능 지표 | ⚠️ 보완 | 운영 지표(MTTD·MTTR)와 비용 지표 추가 필요 |
| 관찰 범위 | 수집~스토리지~분석 | ⚠️ 보완 | 스트리밍·비정형 데이터·AI 모델/에이전트 입출력까지 확장되는 추세 |
| 데이터 품질과의 관계 | 명시 없음 | ⚠️ 보완 | 품질 테스트는 알려진 문제, 관측가능성은 예상치 못한 문제까지 포함 → 상호 보완 관계 |
🔮 최신 트렌드와 향후 방향

| 트렌드 | 내용 |
|---|---|
| 도입 확산 | Gartner는 분산 데이터 아키텍처를 도입한 기업의 50%가 2026년까지 데이터 관측 도구를 도입할 것으로 전망 (2024년 약 20%). 2026년 2월 Market Guide도 갱신됨 |
| 앱·데이터 관측 통합 | 2025년 4월 Datadog이 Metaplane을 인수하며 애플리케이션 관측과 데이터 관측의 통합이 본격화 |
| AI-ready 데이터 | 생성형·에이전트형 AI가 입력 데이터 품질에 전적으로 의존하면서, 데이터 관측이 AI 신뢰성의 전제 조건으로 부상 |
| 에이전트 관측 | "에이전트가 먹는 데이터"와 "에이전트의 출력"을 함께 관측하는 방향으로 벤더 제품 확장 |
| 비용 관측(FinOps) | 쿼리·스토리지 비용 이상 탐지, 비용 귀속까지 관측 범위에 포함 |
| 개인정보 보호 설계 | 금융·의료 등을 중심으로 수집 범위·마스킹·저장 위치 통제가 필수 요건화 |
| 컴플라이언스 활용 | 관측 데이터를 감사 증적·통제 효과성 입증에 활용하는 조직 증가 |
| 개방형 표준 | OpenTelemetry(시스템), OpenLineage(데이터 계보) 등 표준 기반 연동 확대 |
앞으로 3~5년, 이렇게 바뀔 가능성이 큽니다
| 현재 | → | 향후 |
|---|---|---|
| 사람이 알림을 보고 조치 | → | AI가 원인 분석과 복구안 제시, 단순 장애는 자율 복구 |
| 데이터 적재 후 탐지 | → | Shift-left: 데이터 계약으로 생산 단계에서 차단 |
| 정형 테이블 중심 | → | 문서·이미지 등 비정형 데이터와 RAG 파이프라인까지 관측 |
| 데이터팀 전용 도구 | → | 보안·컴플라이언스·현업이 함께 쓰는 공용 신뢰 지표 |
| 독립 도구 시장 | → | 대형 관측·데이터 플랫폼으로 통합·인수 가속 |
🚫 이런 판단은 하지 마세요
① "대시보드 만들었으니 관측가능성 확보"
대시보드는 결과를 보여줄 뿐입니다. 이상을 스스로 탐지하고 알려주고 원인까지 추적할 수 있어야 관측가능성입니다.
② "모든 테이블에 모니터를 건다"
수천 개 테이블에 알림을 걸면 하루 만에 알림 피로가 옵니다. 핵심 자산부터, 중요도별로 시작해야 오래 갑니다.
③ "품질 테스트가 있으니 충분하다"
테스트는 작성한 규칙만 확인합니다. 인증키 만료로 빈 데이터가 "성공 적재"되는 문제처럼 아무도 예상 못 한 장애는 테스트가 잡지 못합니다.
④ "데이터팀 도구니까 보안 검토는 생략"
관측 도구는 데이터 전반에 접근하는 고권한 연동입니다. 도입 전 보안성 검토 대상에 반드시 포함해야 합니다.
💬 자주 나오는 질문
Q. 데이터 관측가능성과 데이터 품질 관리는 같은 건가요?
목표(믿을 수 있는 데이터)는 같지만 방법이 다릅니다. 품질 관리는 기준과 규칙을 정하고 지키는 활동이고, 관측가능성은 그 과정 전체를 지속적으로 지켜보며 예상치 못한 이상까지 찾는 활동입니다.
Q. 소규모 조직도 필요한가요?
테이블이 수십 개 수준이라면 dbt 테스트나 오픈소스 도구로 최신성·볼륨·스키마만 봐도 효과가 큽니다. 상용 플랫폼은 데이터 자산과 소비자가 많아질 때 검토해도 늦지 않습니다.
Q. IT 관측가능성(APM) 도구로 대체할 수 없나요?
APM은 시스템이 살아 있는지를 봅니다. 작업이 "성공"했는데 데이터가 틀린 경우는 APM이 정상으로 봅니다. 다만 최근에는 두 영역을 하나의 플랫폼에서 제공하는 통합 흐름이 뚜렷합니다.
Q. 보안팀이 이 개념을 알아야 하는 이유는요?
데이터 볼륨·스키마·리니지 신호는 유출·삭제·개인정보 흐름 파악에 그대로 쓰입니다. 또한 도입 시 고권한 연동과 외부 반출 검토가 필요하므로 보안성 검토 단계에서 반드시 마주치게 됩니다.
🎉 정리
- 데이터 관측가능성은 데이터 파이프라인의 건강검진이다. 상태·품질·성능·비용을 지속적으로 본다.
- 목표는 현업보다 먼저 아는 것, 즉 MTTD를 줄이는 것이다.
- 최신성·볼륨·분포·스키마는 증상, 리니지는 원인과 영향 범위를 알려준다.
- 품질 테스트와 대체 관계가 아니라 보완 관계다.
- 핵심 데이터부터, 소유자와 SLA를 먼저 정해야 운영이 된다.
- 보안 관점에서도 유용한 신호지만, 관측 도구 자체는 고권한 연동이므로 보안성 검토가 필수다.
- 미래는 AI 데이터 신뢰성, 앱·데이터 관측 통합, 자율 복구 쪽으로 가고 있다.
"작업은 성공했는데 데이터가 틀렸다"는 장애는 로그만 봐서는 절대 보이지 않습니다. 시스템이 아니라 데이터를 봐야 보이는 문제입니다.
🔗 참고 자료
- Gartner — Market Guide for Data Observability Tools
- Bigeye — Gartner Market Guide for Data Observability Tools (2026)
- Monte Carlo — Interpreting The Gartner Data Observability Market Guide
- Datadog — Datadog acquires Metaplane
- Elastic — Observability trends for 2026
- APMdigest — 2026 Observability Predictions: Observability Data
'정보보안 > Infra' 카테고리의 다른 글
| IACS UR E26·E27이란? 2024년부터 의무화된 선박 사이버 보안 규격 총정리 (0) | 2026.10.07 |
|---|---|
| 업스트림 다운스트림 뜻, 분야별 의미 차이 한 번에 정리 (데이터·Git·네트워크·프록시) (0) | 2026.10.07 |
| Rocky Linux 8 SSH CBC 취약점, 설정 파일엔 없는데 Nessus는 왜 탐지할까? (crypto-policies·opt-out 정리) (0) | 2026.10.07 |
| 선박 사이버 보안 규제 총정리 — IMO·IACS·IEC·미국·EU 한눈에 보기 (0) | 2026.10.05 |
| IEC 62443이란? OT 보안 국제표준 구조·보안 수준(SL)·7대 요구사항 쉽게 정리 (0) | 2026.10.01 |
- Total
- Today
- Yesterday
- 개인정보유출
- 자율침투테스트
- 시큐어코딩
- 샤이니헌터스
- 공급망공격
- 정보보안
- 전자금융기반시설
- 선박사이버보안
- LLM에이전트
- IEC62443
- cve
- DevSecOps
- 개인정보보호
- AI보안
- 취약점
- AI모의해킹
- E27
- 보안상식
- 보안뉴스
- 금취분평
- 보안꿀팁
- 오픈소스보안
- IACS
- 해킹주의
- 악성코드
- 펜테스트
- 개발자보안
- 사이버보안
- 해킹예방
- 전자금융기반시설취약점분석평가
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
