Data Eng Wiki

Data Incident Operations

14 min read

Data Incident Operations

“인증은 어떤 데이터 제품을 신뢰해야 하는지 소비자에게 말해준다. DPI는 프로덕션에서 그 신뢰를 참으로 유지한다.”

핵심 개념

데이터 품질 프로그램은 대개 인증(certification) 에서 멈춘다 — 오너십, 문서, 리니지, 품질 통제를 갖춘 자산에 배지를 붙인다. 그것은 신뢰할 수 있는 데이터 마켓플레이스의 출발점이지 종점이 아니다.

인증이 런타임 실패를 제거하지 않는다. 인증된 테이블도 늦게 도착할 수 있고, 인증된 지표도 깨진 의존성에 영향받을 수 있고, 인증된 Kafka 스트림도 freshness 기대를 위반할 수 있다.

Data Incident Operations는 그 간극을 메운다 — contract 위반을 구조화된 프로덕션 이슈로 전환하고, 탐지 → triage → 진단 → 오너 할당 → 해결 → 자동 종료를 하나의 운영 워크플로로 만든다. Grab은 이것을 DPI (Data Production Issue) 라 부른다.

핵심 전환: 데이터 신뢰성이 반응적 소방에서 관리되는 프로덕션 워크플로가 된다.

라이프사이클 — 최소한의 human-in-the-loop

좋은 DPI의 두 조건: 행동할 수 있을 만큼 명확할 것, 그리고 기저 조건이 회복되면 자동으로 닫힐 것.

contract test unhealthy
      ↓
   [Triage]      알림 노이즈 → 진짜 contract breach 선별, 중복 제거·그룹화
      ↓
  [Diagnosis]    Data Health API로 실패 도메인 분류 → 오너 라우팅
      ↓
 [Resolution]    auto-healing 시도 → 검증 → 실패 시 인간 에스컬레이션
      ↓
   [Close]       기저 조건 회복 시 자동 종료

설계 결정 1 — 오케스트레이터를 플랫폼 내부와 분리한다

인시던트 오케스트레이터(Grab의 Kinabalu)는 각 플랫폼이 freshness·completeness를 어떻게 계산하는지 알 필요가 없다. 오직 “관련 contract test가 healthy한가?” 만 묻는다 (Test Health API).

왜 중요한가: 이 분리가 없으면 오케스트레이터가 모든 플랫폼의 내부를 알아야 하고, 새 플랫폼을 붙일 때마다 오케스트레이터를 고쳐야 한다. 안정적 API contract를 소비함으로써 이기종 시스템 간 워크플로가 상호운용된다.

설계 결정 2 — test run ≠ test health

개별 test run 결과와 test의 전체 health를 구분한다.

T-1 파티션 completeness test가 이틀 전 실패했고 어제·오늘 통과했다면, 이틀 전 파티션이 백필되어 완전함이 검증될 때까지 test는 여전히 unhealthy로 간주된다.

이 구분이 없으면 “오늘 통과했으니 괜찮다” 는 착각이 데이터 갭을 조용히 덮는다. → Silent Failures and Data Integrity

설계 결정 3 — triage가 노이즈에서 워크플로를 보호한다

데이터 플랫폼은 알림을 많이 낸다 — Airflow 스케줄 지연, DQ 테스트 실패, 파이프라인 잡 비정상 종료. 이 알림들은 유용하지만 자동으로 인시던트가 되지는 않는다.

  • 중복 제거 — 같은 breach로 열린 DPI가 있으면 새 신호는 병렬 이슈를 만들지 않고 기존 DPI에 컨텍스트를 추가
  • 그룹화 — 같은 근본 원인을 공유하는 DPI들을 묶는다
  • 컨텍스트 수집 — 영향받은 자산, 위반된 contract, unhealthy test, 데이터 interval, 상·하류 의존성

모든 알림이 DPI가 되지는 않는다. 대응자를 반복적 알림의 흐름을 쫓는 대신 기저 문제 해결에 집중하게 하는 것이 목적이다.

설계 결정 4 — 작은 에러 택소노미로 오너를 라우팅한다

모든 데이터 이슈를 자산 오너에게 할당하면 불필요한 handoff가 생기고 해결이 느려진다. 데이터 제품이 unhealthy한 것은 플랫폼 인시던트, 실패한 생산 잡, 지연된 상류 때문일 수 있다.

Data Health API가 “어떤 종류의 실패가 이 자산을 unhealthy하게 만들었나?” 에 답한다:

카테고리의미라우팅
UPSTREAM_ERROR상류 의존성이 늦거나 실패상류 DPI에 링크하고 그 오너를 상속
PLATFORM_ERROR플랫폼·인프라 손상플랫폼 팀
JOB_ERROR생산 잡·파이프라인 실패잡 오너
DATA_ERROR데이터가 품질 기대 위반자산 오너
{
  "assetId": "urn:li:dataset:(...,schema.table_A,PROD)",
  "healthStatus": "UNHEALTHY",
  "errorCategory": "UPSTREAM_ERROR",
  "context": {
    "upstreamAsset": "urn:li:dataset:(...,schema.table_B,PROD)",
    "reason": "upstream data has not arrived for the expected data interval."
  },
  "lastCheckedAt": "2026-06-15T08:30:00Z"
}

택소노미를 작게 유지하는 것이 핵심이다. 이것은 플랫폼별 진단을 대체하려는 것이 아니다 — 오케스트레이터가 일관되게 할당하고 라이프사이클을 관리할 만큼의 구조만 준다. 인제스션·스트리밍·지표·ML 플랫폼은 여전히 상세한 내부 에러 카탈로그를 유지하고 내부를 자유롭게 진화시킨다.

하류 DPI가 상류 DPI의 오너를 상속하는 것이 특히 실용적이다 — 관련 실패들이 근본 원인을 해결할 최적 위치의 팀 아래 자동으로 묶인다.

설계 결정 5 — 진단 정확도가 forcing function이다

DPI 프로세스는 제기된 이슈가 할당되고 고쳐질 수 있을 때만 작동한다. DPI가 자주 시끄럽거나 중복되거나 행동하기 어려우면 사용자는 결국 무시하는 법을 배운다.

그리고 이것이 역방향 압력을 만든다: 각 데이터 생산 플랫폼이 자기 진단을 개선하도록 강제한다. 정확한 RCA를 내려면 플랫폼은 자기 로컬 실패 상태뿐 아니라 의존성과 주변 시스템의 신호를 통합해야 한다.

3단 진단 아키텍처 (Grab의 인제스션 플랫폼 Hugo):

  1. Signal collection — 여러 소스의 이벤트를 모아 데이터셋·파이프라인 health의 전체 view 구성. (현대 플랫폼은 여러 독립 시스템에서 알림을 내는데 개별적으로는 부분적 view만 보여준다)
  2. Alert diagnosis — 구조화된 alert context 생성 → 분류 → 적절한 diagnoser로 라우팅 → 특화 로직으로 근본 원인 식별
  3. Diagnosis result — 근본 원인·영향받은 데이터셋·권장 수정을 구조화해 영속화

신호 인제스션·진단·결과 관리를 분리한 것이 새 신호 소스와 특화 diagnoser 추가를 간단하게 만든다.

설계 결정 6 — auto-healing 먼저, 인간 판단은 필요할 때

DPI의 수명이 data downtime의 프록시다 — breach 탐지에서 시작해 데이터셋이 다시 healthy해질 때 끝난다.

많은 인시던트가 routine하고 복구 가능하다 — 일시적 컴퓨트 중단, DB 커넥션 타임아웃, S3 throttling, 영구히 깨진 게 아니라 지연된 상류.

  1. Resolution execution — 권장 전략 적용(재시도, 상류 대기, 커스텀 resolver). ⚠️ 조치 후 파이프라인 health 그리고 데이터 정확성을 둘 다 검증해야 완전 해결이다
  2. 에스컬레이션 경계 — 데이터 손상, 유효하지 않은 레코드, 애플리케이션 코드 결함처럼 자동화로 안전하게 해결할 수 없으면 인간 개입
  3. Notification and audit — 모든 해결 시도와 결과를 기록하고 팀에 통지. 그 기록이 운영 분석·감사·해결 정책 개선을 뒷받침

진단과 실행을 분리하면 새 진단 능력과 해결 전략이 전체 아키텍처 변경 없이 독립적으로 진화한다.

측정 — data downtime을 가시적·측정 가능·감소 가능하게

Grab 프로덕션 결과:

지표값
자동 해결된 DPI86.9%
자동 제기된 DPI (사람이 아니라)95% 이상
자동 DPI의 MTTR수동 대비 6배 빠름

가장 중요한 결과는 이슈가 더 빨리 탐지되는 것 자체가 아니라 data downtime이 가시적·측정 가능·감소 가능해지는 것이다. 모든 DPI를 탐지에서 복구까지 추적하면 시간이 어디에 쓰이는지, 어떤 실패 모드가 반복되는지, 자동화가 안전하게 운영 toil을 줄일 수 있는 곳이 어디인지 알 수 있다.

agentic 세계와의 접점

이 기반이 왜 AI 시대에 더 중요해지는가:

AI 에이전트가 인증된 자산을 검색하고, contract와 리니지 위에서 추론하고, 품질 신호를 신뢰하고, 프로덕션 이슈를 탐지하고, RCA 초안을 쓰고, 결국 안전한 remediation을 제안하거나 실행할 수 있다.

에이전트는 인간처럼 “이 숫자 이상한데” 하고 멈추지 않는다 → AI-Ready Data. contract test health가 에이전트에게는 유일한 smell test다.

Grab의 데이터 moat는 데이터의 양이 아니라 데이터를 신뢰할 수 있고 발견 가능하고 재사용 가능하고 지속적으로 신뢰성 있게 만드는 시스템이다. 그 세계에서 데이터 신뢰성은 복리로 쌓이는 이점이 된다.

도입 순서

  1. contract를 먼저 정의하라 — DPI는 contract 위반을 감지하는 것이므로 위반할 contract가 없으면 시작할 수 없다 → Data Contracts
  2. test run과 test health를 분리하라 — 백필 검증까지 포함해야 한다
  3. 오케스트레이터를 플랫폼 내부와 분리하라 — 안정적 health API
  4. 에러 택소노미를 작게 시작하라 (4개면 충분하다)
  5. triage의 중복 제거·그룹화를 먼저 만들어라 — 노이즈가 신뢰를 죽인다
  6. auto-healing은 잘 이해된 실패 패턴부터 — 재시도·상류 대기
  7. 모든 해결 시도를 감사하라 — 정책 개선의 입력

연관 개념

Source: Data Mesh at Grab Part III - Operationalizing Data Reliability with Automated DPIs

그래프 뷰

백링크