"이 파이프라인, 리트라이하면 진짜 안전한가요? 내가 겪은 멱등성 실패와 그 교훈"

안녕하세요, Andrew입니다.

 

여러분은 데이터 파이프라인의 '리트라이(Retry)' 기능을 얼마나 믿으시나요? 혹시 실패 시 자동 재시도를 '엔지니어의 든든한 친구'라고 생각하고 계신가요? 올해 봄, 저의 굳건했던 믿음이 산산조각 나는 사건이 있었습니다.

1. 서비스 장애의 시작, 그리고 착각

데이터 레이크 구축 프로젝트 중 적재 파이프라인에서 사고가 터졌습니다. 특정 일자의 배치 작업이 실패했고, Airflow는 자동으로 태스크를 재시도(retry)했습니다. 그런데 이상하게도 고객이 다루는 Data Mart에서 "거래가 두 번 들어왔다"는 항의가 들어왔습니다. 확인해보니, 동일한 상품 리뷰 데이터가 두 번 적재되었더군요.

그때까지만 해도, 저는 리트라이는 안전하다고 생각했습니다. "자동 재시도는 엔지니어의 친구지! 실패 복구는 기본!"이라고 믿었죠. 하지만 그날, 그 믿음은 산산이 부서졌습니다. 리트라이가 실패 복구가 아닌, 오히려 새로운 문제를 야기할 수 있다는 뼈아픈 교훈을 얻게 된 날이었습니다.

2. 멱등성이 뭐길래 이렇게 중요한가요?

이후 팀에서 회고를 하며 알게 된 개념이 바로 멱등성 (Idempotency)입니다.

멱등성: "같은 작업을 여러 번 수행해도 결과가 달라지지 않는 성질"

HTTP 요청에선 종종 이런 식으로 설명하죠:

• GET: 멱등합니다. 여러 번 호출해도 똑같은 결과.
• POST: 멱등하지 않습니다. 요청할 때마다 새로운 리소스가 생성될 수 있습니다.

데이터 파이프라인도 마찬가지입니다.

• INSERT INTO table ...: 멱등하지 않습니다. 두 번 실행하면 데이터가 중복될 수 있습니다.
• MERGE INTO, INSERT OVERWRITE, UPSERT: 멱등하게 만들 수 있는 방법들입니다.

기능	INSERT	UPSERT (MERGE INTO)
데이터 추가	새로운 행만 추가	기존 데이터 업데이트 또는 새로운 행 추가
중복 데이터	중복 데이터 처리 안 함	중복 데이터 처리 (업데이트 또는 삽입)
사용 목적	단순히 데이터 추가	데이터 업데이트 또는 추가 (중복 데이터 처리 필요 시)

 

3. 그날 이후 내가 바꾼 처리 방식

그 사고 이후, 저는 다음과 같은 방식으로 파이프라인을 고쳤습니다:

• 고유 키 생성 (Idempotent Key)
  • 거래일자 + 카드사코드 + 거래ID를 묶어 해시 키 생성
  • 이 고유 키를 기반으로 중복 데이터 필터링 로직 추가
• INSERT → UPSERT로 전환
  • 데이터베이스에 이미 존재하는 데이터라면 업데이트하고, 없다면 새로 삽입하는 방식으로 전환했습니다.
• Job Task 설계 변경
  • 실패 시 단순 재시도 → 재처리 태스크는 따로 분리
    • 멱등성이 보장되지 않는 태스크는 자동 리트라이를 비활성화하거나, 리트라이 횟수를 최소한으로 제한했습니다.
    • 데이터 중복이 발생할 수 있는 구간은 수동 재처리 또는 별도의 정합성 검사/복구 로직을 포함한 태스크로 분리하여 관리합니다.
  • 리트라이 횟수 제한 및 Teams 알림 강화
    • 자동 리트라이는 최소한의 횟수(예: 1~2회)로 제한하고, 그 이후에는 즉시 담당자에게 Slack 알림이 가도록 설정하여 사람이 개입할 수 있도록 했습니다.

4. 현재 우리 팀의 기준

지금 우리 팀은 다음 기준으로 파이프라인의 멱등성을 검토합니다:

• 파티션 단위로 overwrite할 수 있는가? (전체를 덮어쓰는 방식은 멱등성 확보에 유리)
• 저장 전에 고유 키를 기반으로 중복 여부 체크가 가능한가?
• 외부 시스템 호출 시 idempotency token을 쓸 수 있는가? (API 호출 시 중복 처리 방지)

그리고 Airflow DAG에는 이런 주석을 남기죠:

python

# 이 태스크는 멱등성이 없습니다.
# 리트라이가 발생하면 중복 적재 위험이 있으니 주의하세요.

이 한 줄의 경고가 팀 전체의 데이터 품질을 지켜주는 날이 있습니다.

5. 정리하며: 주니어에게 전하는 조언

리트라이는 실패 복구가 아닙니다. 그건 새로운 책임입니다.

자동화된 재처리는 자칫하면 중복, 데이터 부정합, 재고 오류, 비용 낭비 등으로 이어질 수 있습니다. 특히 멱등성이 보장되지 않는 파이프라인에서는 더욱 그렇습니다.

그러니 꼭 기억하세요:

멱등하지 않은 파이프라인은, 리트라이가 아니라 "재앙"을 반복합니다.

지금 당장 여러분의 파이프라인에도 질문해보세요:

“이거… 몇 번 돌려도 정말 안전한가요?”