04. 알림과 장애 등급 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• 품질 rule 실패를 알림으로 보낼 때 severity는 무엇을 기준으로 나누는가?
• freshness, completeness, accuracy 실패는 각각 어떤 운영 조치로 이어지는가?
• 좋은 데이터 품질 알림에는 owner, 영향 범위, 재처리 범위가 어떻게 들어가야 하는가?
• 알림 피로를 줄이면서도 중요한 품질 장애를 놓치지 않으려면 무엇을 기록해야 하는가?

개요

품질 알림은 rule이 실패했다는 사실을 전달하는 것이 아니라, 지금 누가 무엇을 해야 하는지 결정하게 만드는 운영 신호다.

백엔드 API는 정상이어도 대시보드, 검색 색인, 추천 feature가 오래된 데이터를 보여줄 수 있다. 이때 모든 실패를 같은 채널로 보내면 중요한 장애는 묻히고, 모든 실패를 incident로 올리면 운영자가 알림을 무시하게 된다.

알림과 장애 등급 문서는 데이터 품질 실패를 severity, owner, runbook, 재처리 범위로 연결하는 기준을 정리한다.

알림과 로그의 차이

로그는 사후 분석을 위한 기록이다.

알림은 지금 행동해야 하는 신호다.

따라서 알림에는 다음 정보가 있어야 한다.

• 어떤 rule이 실패했는가?
• 어떤 데이터셋 또는 mart가 영향을 받는가?
• 사용자 또는 의사결정 영향이 있는가?
• 누가 확인해야 하는가?
• 자동 retry 후에도 실패했는가?
• 어디부터 재처리할 수 있는가?

이 중 하나라도 없으면 알림은 단순한 소음이 되기 쉽다.

장애 등급의 기준

품질 장애 등급은 rule 이름만으로 정하지 않는다.

같은 freshness 실패라도 내부 실험용 mart라면 낮은 등급일 수 있고, 매출 정산 mart라면 높은 등급일 수 있다.

P1: 외부 사용자, 정산, 결제, 법적 리포트에 잘못된 데이터가 노출됨
P2: 내부 핵심 의사결정 지표가 잘못되거나 오래됨
P3: 보조 지표, 실험용 데이터셋, 다음 배치에서 자동 복구 가능한 지연
Info: 운영자가 추세를 보려고 남기는 비긴급 신호

핵심은 기술적 실패가 아니라 데이터 사용자의 피해와 복구 긴급도다.

품질 차원별 알림 해석

품질 차원	대표 실패	먼저 볼 것	흔한 조치
freshness	최신 데이터가 늦음	upstream job, queue lag, DAG run	지연 공지, downstream 공개 보류, catchup
completeness	row 수나 key가 부족함	source count, filter 조건, join 누락	누락 범위 재처리, source 계약 확인
accuracy	금액, 상태, 집계 값이 다름	metric definition, currency, cancel/refund	계산식 수정, mart 재생성
validity	값 형식이 계약과 다름	enum, null, range, schema	producer 수정, invalid row 격리
consistency	서로 다른 mart가 다른 값을 말함	grain, 기준 시각, dimension version	지표 정의 정렬, backfill

freshness는 “늦다”이고 completeness는 “빠졌다”이며 accuracy는 “틀렸다”다.

이 세 가지를 같은 메시지로 보내면 대응자가 잘못된 runbook을 실행한다.

알림 정책 예시

dataset: mart_order_daily
owner: data-platform
business_owner: finance
rules:
  - name: order_daily_freshness
    dimension: freshness
    threshold: "max(event_time) >= now() - 90 minutes"
    severity:
      business_hours: P2
      settlement_day: P1
    runbook: runbooks/order-daily-freshness.md
  - name: order_daily_amount_accuracy
    dimension: accuracy
    threshold: "abs(source_sum - mart_sum) / source_sum < 0.001"
    severity:
      default: P1
    runbook: runbooks/order-daily-amount.md

정책은 코드 밖 문서에만 있으면 오래 유지되지 않는다.

가능하면 rule metadata, owner, severity, runbook URL을 table이나 설정 파일로 관리한다.

좋은 알림 메시지

[P1][Data Quality] mart_order_daily amount accuracy failed
 
rule: order_daily_amount_accuracy
dataset: mart_order_daily
partition: 2026-06-30
source_sum: 128,391,100
mart_sum: 124,021,700
diff_ratio: 3.4%
last_success: 2026-06-29 03:12 KST
suspected_area: refund event mapping changed
owner: data-platform, order-service
runbook: runbooks/order-daily-amount.md

이 메시지는 “틀렸다”에서 끝나지 않는다.

partition, 마지막 성공 시각, 의심 지점, owner, runbook을 함께 제공한다.

백엔드 개발자가 제공해야 할 정보

데이터 품질 알림은 데이터 팀만의 문제가 아니다.

백엔드 변경이 알림 등급을 바꿀 수 있다.

• 새 상태값이 추가되면 validity rule이 실패할 수 있다.
• 환불 로직이 바뀌면 accuracy rule이 실패할 수 있다.
• 이벤트 발행 시점이 바뀌면 freshness rule이 흔들릴 수 있다.
• soft delete가 추가되면 completeness rule이 오탐을 만들 수 있다.

그래서 기능 PR에는 “이 변경이 어떤 mart, quality rule, alert에 영향을 주는가”가 포함되어야 한다.

알림 피로를 줄이는 방법

알림 피로는 rule이 많아서만 생기지 않는다.

행동할 수 없는 알림이 반복될 때 생긴다.

• 같은 partition의 동일 rule 실패는 묶어서 보낸다.
• retry 중인 transient failure는 바로 P1로 올리지 않는다.
• 자동 복구된 실패는 incident가 아니라 trend로 기록한다.
• owner 없는 rule은 알림 대상에서 제외하거나 먼저 owner를 지정한다.
• 알림에는 mute 조건과 escalation 조건을 함께 둔다.

중요한 것은 알림을 줄이는 것이 아니라, 실제 행동이 필요한 알림을 남기는 것이다.

운영 지표

• alert_to_ack_minutes: 알림 후 담당자가 확인하기까지 걸린 시간.
• ack_to_resolve_minutes: 확인 후 품질 정상화까지 걸린 시간.
• false_positive_rate: 알림이 실제 조치로 이어지지 않은 비율.
• repeat_incident_count: 같은 rule과 dataset에서 반복된 장애 수.
• unowned_rule_count: owner가 없는 품질 rule 수.

이 지표는 품질 자체보다 품질 운영 체계가 작동하는지 보여준다.

위험 신호!

• 모든 rule 실패가 같은 Slack 채널로 간다.
• 알림에 dataset partition과 마지막 성공 시각이 없다.
• P1/P2/P3 기준이 사람마다 다르다.
• rule 실패가 자동 retry 중인지, 사람이 봐야 하는지 구분되지 않는다.
• 알림은 많지만 회고 후 rule, owner, runbook이 바뀌지 않는다.

확인 질문

확인 질문

• 같은 freshness 실패라도 settlement day에는 왜 더 높은 등급이 될 수 있는가?
• 좋은 품질 알림에 partition과 last success가 필요한 이유는 무엇인가?
• 백엔드의 상태값 추가가 validity alert를 만들 수 있는 이유는 무엇인가?
• false positive rate가 높으면 어떤 운영 문제가 생기는가?

참고 문서

• Apache Airflow Documentation
• PostgreSQL Documentation
• AWS Analytics Guidance
• Martin Kleppmann, Designing Data-Intensive Applications