05. 데이터 품질 회고와 재발 방지 상세

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

• 데이터 품질 장애 회고는 사람의 실수보다 어떤 시스템 결함을 찾아야 하는가?
• 회고에서 source, pipeline, rule, alert, runbook 중 어디가 비어 있었는지 어떻게 분리하는가?
• 재발 방지 액션을 문서가 아니라 rule, test, owner, runbook 변경으로 연결하려면 무엇이 필요한가?
• 백엔드 변경이 품질 장애를 만들었을 때 다음 배포에서 무엇을 바꿔야 하는가?

개요

데이터 품질 회고는 누가 실수했는지 찾는 자리가 아니다.

왜 늦게 발견됐는지, 왜 영향 범위를 바로 알 수 없었는지, 왜 같은 문제가 다시 생길 수 있는지를 확인하는 절차다.

좋은 회고는 “다음에는 조심하자”로 끝나지 않는다. rule 추가, schema 계약 수정, alert routing 변경, runbook 보강, 배포 체크리스트 수정 같은 실행 가능한 변화로 끝난다.

회고의 입력

회고는 감상으로 시작하면 길어지고 흐려진다.

먼저 사실을 모은다.

• 어떤 dataset, partition, metric이 잘못됐는가?
• 최초 실패 시각과 최초 감지 시각은 언제인가?
• 누가 먼저 발견했는가? 사용자, 데이터 팀, 자동 rule 중 무엇인가?
• source 데이터는 정상인가?
• pipeline은 성공으로 기록됐는가?
• quality rule은 있었는가?
• alert는 올바른 owner에게 갔는가?
• 재처리 범위와 완료 검증 쿼리는 있었는가?

이 질문에 답하지 못하면 원인보다 관측 체계부터 보강해야 한다.

회고 타임라인

02:00 batch started
02:18 source extract finished
02:21 transform failed on new enum value
02:23 Airflow task retry started
03:05 DAG marked failed
08:40 analyst noticed dashboard value drop
09:05 data-platform acknowledged
09:30 order-service confirmed enum deployment
10:20 mart backfilled
10:35 quality rule passed

타임라인은 비난을 위한 기록이 아니다.

감지 지연, escalation 지연, 복구 지연 중 어디가 컸는지 보기 위한 자료다.

결함 분류

품질 장애 원인을 하나로 압축하면 재발 방지가 약해진다.

다음 축으로 나누어 기록한다.

결함 위치	예시	재발 방지
source contract	새 상태값이 문서 없이 추가됨	schema review, enum compatibility rule
pipeline logic	transform이 새 값을 누락함	contract test, invalid row quarantine
quality rule	금액 합계 rule만 있고 상태 분포 rule이 없음	rule coverage 확대
alert routing	실패가 담당 팀에 전달되지 않음	owner metadata, escalation policy
runbook	재처리 범위와 검증 쿼리가 없음	runbook template 보강
release process	백엔드 PR에서 downstream 영향이 빠짐	배포 체크리스트 수정

한 사건이 여러 결함을 동시에 가질 수 있다.

회고 기록 예시

incident_id: dq-2026-06-30-001
dataset: mart_order_daily
dimension: accuracy
impact: finance dashboard exposed wrong net revenue for 2026-06-30
detection: analyst report, not automated rule
root_cause:
  source_contract: refund event added reason=PARTIAL_CANCEL
  pipeline_logic: transform mapped only FULL_CANCEL
  alerting: amount mismatch rule existed but P3 channel only
recovery:
  replay_range: 2026-06-30
  validation: source_sum and mart_sum diff_ratio < 0.001
actions:
  - add enum compatibility test in order-service
  - add reason distribution rule
  - move amount accuracy failure to P1 on settlement day
  - update feature release checklist

좋은 회고 기록은 다음 장애 때 바로 검색할 수 있어야 한다.

백엔드 관점의 재발 방지

백엔드 개발자는 데이터 품질 회고에서 다음 항목을 책임 있게 확인해야 한다.

• API transaction이 어떤 event를 만들었는가?
• 새 enum, nullable field, soft delete가 downstream에 어떤 의미인가?
• domain event와 integration event 중 어떤 계약이 바뀌었는가?
• outbox, CDC, Kafka publish가 정상이어도 consumer가 해석할 수 있는가?
• 기존 backfill이 새 로직으로 재실행되어도 같은 결과를 내는가?

데이터 팀이 SQL을 고치는 것으로 끝나면 같은 변경이 다음 배포에서 다시 장애가 된다.

Action Item의 품질

나쁜 action item은 의지가 필요하다.

좋은 action item은 시스템이 확인한다.

나쁨: 다음부터 상태값 추가 시 데이터 팀에 공유한다.
좋음: order-service PR template에 "new enum affects integration event?" 체크를 추가하고, CI에서 schema registry compatibility를 검사한다.
 
나쁨: 대시보드를 더 자주 확인한다.
좋음: mart_order_daily에 amount accuracy rule을 추가하고 P1 채널로 라우팅한다.
 
나쁨: runbook을 잘 따른다.
좋음: runbook에 replay command, dry-run query, 완료 검증 SQL을 추가한다.

회고 문서는 읽는 사람이 아니라 시스템이 바뀌어야 효과가 있다.

재발 방지 저장소

작은 팀에서는 별도 incident 도구 없이 table 하나로 시작해도 된다.

CREATE TABLE data_quality_incidents (
  incident_id text PRIMARY KEY,
  dataset_name text NOT NULL,
  quality_dimension text NOT NULL,
  detected_at timestamptz NOT NULL,
  resolved_at timestamptz,
  detected_by text NOT NULL,
  severity text NOT NULL,
  root_cause_summary text NOT NULL,
  replay_range text,
  validation_query text,
  status text NOT NULL
);
 
CREATE TABLE data_quality_actions (
  action_id bigserial PRIMARY KEY,
  incident_id text REFERENCES data_quality_incidents(incident_id),
  owner text NOT NULL,
  action_type text NOT NULL,
  description text NOT NULL,
  due_date date,
  status text NOT NULL
);

중요한 것은 회고가 닫혔는지가 아니라 action이 닫혔는지다.

운영 지표

• detected_by_rule_ratio: 자동 rule이 먼저 발견한 품질 장애 비율.
• repeat_root_cause_count: 같은 root cause가 반복된 횟수.
• action_item_overdue_count: 기한이 지난 재발 방지 액션 수.
• schema_change_without_rule_count: 품질 rule 검토 없이 배포된 schema 변경 수.
• incident_to_rule_days: 장애 발생 후 rule이 추가되기까지 걸린 시간.

이 지표는 품질 장애를 줄이는 조직 학습 속도를 보여준다.

위험 신호!

• 회고가 “담당자가 실수했다”로 끝난다.
• source contract 변경과 품질 rule 변경이 연결되지 않는다.
• action item owner와 due date가 없다.
• 같은 metric 장애가 반복되는데 rule이나 alert 등급이 바뀌지 않는다.
• 재처리 완료를 감으로 판단하고 검증 SQL을 남기지 않는다.

확인 질문

확인 질문

• 품질 장애 회고에서 detection gap과 recovery gap을 분리해야 하는 이유는 무엇인가?
• “다음부터 공유한다”보다 PR template과 compatibility check가 더 좋은 action인 이유는 무엇인가?
• 백엔드 enum 추가가 데이터 품질 회고의 source contract 항목이 되는 이유는 무엇인가?
• 회고가 닫혔는데 action item이 남아 있으면 어떤 리스크가 남는가?

참고 문서

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