Green Light, Wrong Numbers

한국어 원문으로 표시합니다.

한 줄 요약

파이프라인의 성공/실패는 데이터의 맞음/틀림과 다른 축입니다. 품질을 재지 않으면, 조용히 비어 있는 테이블 위에서 대시보드가 초록불로 켜져 있습니다.

Concept map: 성공/실패 · 맞음/틀림 · 상류 시스템이 토요일에 파일을 안 보냈고 · 아무 일도 일어나지 않았다는 사실을 아무도 모른 것

왜 이게 필요했나

월요일 아침 회의에서 매출이 전주 대비 40% 떨어졌다는 보고가 나옵니다. 영업팀이 뒤집어집니다. 하루 종일 원인을 찾다가 오후에 밝혀집니다 — 상류 시스템이 토요일에 파일을 안 보냈고, 파이프라인은 빈 파일을 정상적으로 처리해서 0건을 적재했습니다.

파이프라인은 실패하지 않았습니다. 에러도 없고, 재시도도 없고, 알림도 없었습니다. 문제는 아무 일도 일어나지 않았다는 사실을 아무도 모른 것 입니다.

네 가지 품질 축

축	질문	측정
신선도 (freshness)	데이터가 언제 것인가	최신 레코드 시각과 현재의 차이
완전성 (completeness)	있어야 할 만큼 있는가	건수, 널 비율
유일성 (uniqueness)	중복이 없는가	키별 중복 건수
유효성 (validity)	값이 규칙을 지키는가	범위·형식·참조 무결성

각각을 쿼리 한 줄로 잴 수 있습니다.

-- 신선도: 마지막 데이터가 몇 분 전인가
SELECT extract(epoch from now() - max(event_at))/60 AS lag_min FROM events;

-- 완전성: 어제 건수가 지난 7일 평균 대비 얼마인가
WITH d AS (
  SELECT date_trunc('day', event_at) AS day, count(*) AS n
  FROM events WHERE event_at >= now() - interval '8 days' GROUP BY 1)
SELECT (SELECT n FROM d ORDER BY day DESC LIMIT 1)::float
     / NULLIF(avg(n), 0) AS ratio FROM d;

-- 유일성
SELECT count(*) FROM (
  SELECT order_id FROM orders GROUP BY 1 HAVING count(*) > 1) x;

-- 유효성
SELECT count(*) FROM orders WHERE amount < 0 OR status NOT IN ('NEW','PAID','CANCELLED');

임계값은 절대값이 아니라 비율로

"건수가 1000 미만이면 알림" 같은 규칙은 곧 무용지물이 됩니다. 서비스가 자라면 임계값을 계속 고쳐야 하고, 아무도 안 고칩니다.

대신 자기 자신과 비교합니다.

어제 건수 / 최근 7일 같은 요일 평균 → 0.5 미만이면 경고
널 비율이 지난주 대비 2배 이상 증가
신선도 지연이 평소 p95 의 3배 초과

요일 효과를 무시하면 월요일마다 오탐이 납니다. 주말에 트래픽이 적은 서비스에서 "어제 대비" 는 매주 월요일 오전에 거짓 경보를 냅니다. 같은 요일끼리 비교하세요.

데이터 계약

품질 검사는 사후 대응입니다. 근본은 상류와 합의하는 것입니다.

데이터 계약(data contract)은 생산자와 소비자 사이의 명시적 약속입니다.

dataset: orders
owner: order-team
schema:
  order_id:   { type: string, required: true, unique: true }
  amount:     { type: decimal, required: true, min: 0 }
  status:     { type: enum, values: [NEW, PAID, CANCELLED] }
  created_at: { type: timestamp, required: true }
sla:
  freshness: 30m          # 30분 이내 데이터가 있어야 함
  completeness: 0.99      # 널 비율 1% 미만
breaking_change: 30일 전 공지

계약이 있으면 두 가지가 달라집니다.

책임 소재가 분명해집니다. "스키마가 바뀌어서 깨졌다" 가 아니라 "계약을 위반했다" 가 됩니다.
자동 검증이 가능합니다. 계약 파일 자체가 검사 규칙이 됩니다.

검사를 어디에 두는가

추출 → [입력 검사] → 변환 → [출력 검사] → 적재 → [사후 검사]

입력 검사 — 상류가 준 것이 계약에 맞는가. 여기서 막으면 오염이 하류로 안 퍼집니다.
출력 검사 — 우리 변환이 만든 결과가 맞는가. 건수 보존, 합계 일치.
사후 검사 — 적재된 테이블의 신선도·완전성. 주기적으로 돕니다.

가장 흔한 실수는 사후 검사만 두는 것입니다. 그러면 이미 오염된 데이터가 대시보드와 다른 파이프라인으로 퍼진 뒤에 알게 됩니다.

실패를 어떻게 다룰 것인가

검사가 실패했을 때 선택지는 셋입니다.

대응	언제
중단 (fail)	하류가 틀린 데이터를 쓰면 안 될 때. 결제·정산
격리 (quarantine)	일부만 문제일 때. 나쁜 행만 따로 빼고 나머지 진행
경고 (warn)	품질이 낮아도 없는 것보다 나을 때. 탐색용 데이터

무조건 중단은 안 됩니다 — 사소한 문제로 전체가 멈추면 사람들이 검사를 꺼 버립니다. 무조건 경고도 안 됩니다 — 아무도 안 봅니다. 데이터셋마다 정해야 합니다.

현장에서 만나는 모습

상류가 파일을 안 보냈는데 0건 적재로 "성공" → 신선도·완전성 검사 부재.
스키마에 열이 추가되자 파싱이 밀려 값이 한 칸씩 어긋남 → 입력 검사 부재.
재처리 후 건수가 두 배 → 유일성 검사 부재.

다음 퀴즈에서 확인할 것

품질 축 네 가지를 쿼리로 구현해 실제 데이터셋에 적용하고, 요일을 고려한 상대 임계값으로 이상을 탐지합니다. 계약 위반을 만들어 검사가 잡아내는지 확인하고, 중단·격리·경고 세 가지 대응을 구분해 적용합니다.