정산/포인트/쿠폰 같은 상태 기반 도메인에서는 “완벽한 실시간 정합성"보다 빠른 탐지 + 안전한 복구가 더 현실적인 목표입니다. 문제는 많은 팀이 장애가 난 뒤에만 수작업으로 맞추다 보니, 같은 이슈가 월 단위로 반복된다는 점입니다.

Reconciliation 파이프라인은 이 반복을 끊는 장치입니다. 핵심은 단순 비교가 아니라, 불일치의 유형을 분류하고(누락/중복/순서역전), 자동 복구 가능한 건 즉시 처리하고, 위험 건은 사람 승인으로 전환하는 운영 체계를 갖추는 것입니다.

이 글에서 얻는 것

  • 결제·주문·포인트처럼 다중 저장소를 쓰는 서비스에서 Reconciliation이 왜 필수인지 판단할 수 있습니다.
  • “하루 1회 배치” 수준을 넘어, 탐지 주기·복구 우선순위·승인 경계를 수치 기준으로 설계할 수 있습니다.
  • 장애 대응을 개인 역량에 의존하지 않고, 런북과 자동화 파이프라인으로 전환하는 방법을 가져갈 수 있습니다.

핵심 개념/이슈

1) 정합성 문제는 보통 3가지 패턴으로 발생한다

  1. 누락(Missing): 주문은 생성됐는데 결제/포인트 이벤트가 반영되지 않음
  2. 중복(Duplicate): 재시도/중복 소비로 같은 이벤트가 2번 이상 반영됨
  3. 순서 역전(Reorder): 취소가 선반영되고 승인 이벤트가 늦게 도착해 상태가 뒤집힘

이 세 가지는 대부분 Idempotency 설계, Kafka 재시도·DLQ 운영, Transactional Outbox + CDC와 연결됩니다. 즉, Reconciliation은 “나중에 붙이는 보조 기능"이 아니라, 비동기 아키텍처의 기본 안전장치입니다.

2) 기준 데이터(Source of Truth)를 먼저 고정해야 한다

실무에서 자주 실패하는 지점은 “무엇을 정답으로 볼지"를 합의하지 않은 상태로 비교 배치를 짜는 것입니다. 예를 들어:

  • 금액 정산: 결제 승인 원장(ledger)을 기준
  • 주문 상태: 주문 서비스 이벤트 로그를 기준
  • 포인트 잔액: 포인트 원장 합계를 기준

기준 데이터가 없으면 불일치가 나와도 어느 쪽을 수정할지 못 정합니다. 이때 상태 스냅샷만 비교하면 오탐이 많아지므로, 가능하면 이벤트 원장 + 스냅샷 병행이 안정적입니다.

3) 탐지는 배치만으로 끝나지 않는다

“매일 새벽 한 번"으로는 사용자 체감 장애를 막기 어렵습니다. 권장 패턴은 아래처럼 2단계입니다.

  • 근실시간 탐지(5~15분 간격): 고위험 도메인(결제, 환불, 포인트 차감)
  • 일 배치 정산(1일 1회): 전체 계정 재계산, 누적 오차 교정

지연 허용시간(SLO) 기준으로 주기를 나눠야 하며, 관련 지표는 SLO/SLI/Error Budget 프레임으로 관리하는 게 좋습니다.

4) 복구 액션은 위험도별로 분리해야 한다

모든 불일치를 자동 고치면 더 큰 사고가 납니다. 보통 아래 우선순위가 안전합니다.

  • P1(즉시 자동 복구): 중복 반영 취소, 누락 이벤트 재처리(멱등 키 확인)
  • P2(조건부 자동 복구): 금액 차이 임계치 이하(예: 1,000원 미만) 건
  • P3(수동 승인): 환불/현금성 포인트/회계 마감 구간 관련 건

핵심은 “자동화 비율"이 아니라 잘못 자동화했을 때의 손실 상한을 먼저 계산하는 것입니다.

실무 적용

1) 4주 도입 로드맵(중소 규모 팀 기준)

  • 1주차: 불일치 유형 사전 정의(누락/중복/순서역전) + 기준 데이터 합의
  • 2주차: 비교 쿼리/검증 로직 구현, 결과를 “조치 없음” 모드로 수집
  • 3주차: P1 자동 복구만 활성화, 재처리 횟수 상한(예: 3회) 적용
  • 4주차: P2 조건부 복구 + 운영 대시보드 + 온콜 알림 기준 고정

처음부터 모든 도메인에 적용하지 말고, 장애 비용이 큰 결제/포인트 1개에서 먼저 증명하는 것이 안전합니다.

2) 의사결정 기준(숫자/조건)

  • 불일치율 = 불일치 건수 / 검사 건수
    • 0.05% 미만: 관찰 유지
    • 0.05%~0.2%: 원인 분석 + 재발 방지 항목 등록
    • 0.2% 이상: 기능 릴리즈 게이트(배포 보류) 검토
  • 탐지 지연 p95
    • 30분 초과: 근실시간 잡 주기 단축 또는 스트림 검증 추가
  • 자동 복구 성공률
    • 95% 미만: 자동화 확대 금지, 실패 샘플 20건 수동 리뷰
  • 재처리 큐 지연
    • 10분 초과 지속 시: 컨슈머 증설보다 먼저 병목 쿼리/락 점검

성능 병목 점검 시에는 DB 락 경합 플레이북과 배치 멱등성 설계를 같이 보는 것이 효과적입니다.

3) 데이터 모델링 팁

  • 원장 테이블은 event_id, idempotency_key, occurred_at, source를 반드시 보존
  • 상태 테이블은 “현재값"만 두고, 정정 이력은 별도 audit 테이블에 분리
  • 정산 배치는 “한 번에 전체"보다 **기간 슬라이딩 윈도우(예: 최근 3일 + 전월 마감 구간)**로 분할

실무에서는 마감 구간(월말/프로모션 종료일)에 불일치가 집중되므로, 평시와 같은 주기로 돌리면 놓치기 쉽습니다.

4) 운영 대시보드 최소 항목

  • 도메인별 불일치율(5분/1시간/1일)
  • 불일치 유형 비중(누락/중복/순서역전)
  • 자동 복구 성공률 및 재시도 횟수 분포
  • 수동 승인 대기 건수와 평균 처리시간

관측 신호가 부족하면 “잡은 줄 알았는데 재발"이 반복됩니다. 기본 관측은 Observability Baseline처럼 지표·로그·트레이스를 함께 묶어야 합니다.

트레이드오프/주의점

  1. 비교 범위를 과도하게 넓히면 비용이 급증한다
    초기에 모든 필드를 비교하면 쿼리 비용과 배치 시간이 크게 늘어납니다. 금액, 상태, 타임스탬프처럼 사고 영향이 큰 필드부터 시작하세요.

  2. 자동 복구율 KPI만 올리면 위험해진다
    자동 복구를 늘리는 것보다 오복구를 줄이는 것이 우선입니다. 고위험 도메인은 승인 경계를 남겨야 합니다.

  3. 재처리 로직이 멱등하지 않으면 2차 장애가 생긴다
    복구 작업 자체가 중복 반영을 만들 수 있습니다. 재처리 API/컨슈머에도 동일한 멱등 키 규칙을 강제해야 합니다.

  4. 지연 탐지 허용치를 명시하지 않으면 알림 피로가 온다
    모든 불일치를 즉시 알리면 온콜이 마비됩니다. 금액·사용자 영향·지속 시간을 기준으로 경보 등급을 나눠야 합니다.

체크리스트 또는 연습

실무 체크리스트

  • 도메인별 Source of Truth를 문서로 고정했다.
  • 누락/중복/순서역전 3가지 유형을 구분해 지표화했다.
  • 불일치율 임계치(0.05%, 0.2% 등)와 배포 게이트 조건을 합의했다.
  • 자동 복구와 수동 승인 경계를 금액/도메인 기준으로 분리했다.
  • 재처리 API/컨슈머에 멱등 키 검증을 적용했다.

연습 과제

  1. 최근 2주 결제/포인트 이벤트 1만 건을 샘플링해서 누락·중복·순서역전 비율을 계산해보세요.
  2. 자동 복구 가능한 유형(P1)과 승인 필요 유형(P3)을 분리하고, 손실 상한을 숫자로 정의해보세요.
  3. 불일치율이 0.2%를 넘는 주간 시점에서 “배포 보류 vs 제한적 배포” 의사결정 문안을 작성해보세요.

관련 글