Idempotency in Data Engineering: The Quiet Property That Saves Your Pipelines

Author: Mohammed Benaissa | Source: Medium | Published: 2026-06-21

한 줄 요약

분산 시스템은 by design 재시도하므로 모든 write에 “키가 무엇이고, 두 번 실행되면 어떻게 되나?”를 물어 멱등성을 설계해야 하며, exactly-once를 강제하는 대신 write를 중복 적용에 관대하게 만드는 것이 더 싸고 정직한 해법.

사건: INSERT INTO fct_orders SELECT...가 S3 timeout 후 Airflow 재시도로 두 번 실행 → 주문 수 2배. SQL은 맞았고 버그는 “한 번만 실행된다”는 가정
멱등성 = 1번이든 100번이든 같은 최종 상태(SET balance=100은 멱등, balance=balance+50은 아님). exactly-once(전달 보장)와 혼동 말 것 — 멱등성이 더 싸고 정직
4계층이 중복 유발: 브로커(at-least-once), 컴퓨트(Spark speculative execution + 4회 재시도), 오케스트레이터(clear & retry, 백필), 스토리지(non-atomic write)
멱등 write 패턴: 결정론적 키(natural key 또는 immutable 필드 hash, 절대 now()/random UUID 아님) → append 대신 MERGE(소스 dedup 선행 필수) → 파티션 배치는 dynamic partition overwrite → 스트리밍은 watermark dedup → Kafka idempotent producer/transaction → receiver에 idempotency key
Medallion별 멱등성: Bronze(replay 안전 — offset/file path 키), Silver(완전 dedup — 결정론적 키·watermark·MERGE의 battleground), Gold(date/grain 단위 완전 overwrite, += 금지)
오케스트레이션 3규칙: logical date(ds)로 파티션(now() 금지), 입력을 immutable로, output path를 입력의 pure function으로
증명: run-twice 테스트(내용 hash 비교, row count 아님), volume anomaly check. 거버넌스·GDPR 삭제·관측성 모두 멱등성에 의존

Uber Hudi: append-only “blind directory” 문제 → 24시간 → 30분 미만 인제스천 지연(Hudi/Iceberg/Delta 모두 metadata layer + CoW/MoR로 해결)
트레이드오프: MERGE는 append보다 느림 → 비즈니스의 중복 비용 < 방지 엔지니어링 비용일 때만. 돈·재고·규제는 strict 멱등성