이커머스 결제·정산 데이터 불일치 조기 발견

20260417 1600 settlement 이커머스 PG 플랫폼 vs 쇼핑몰 플랫폼

2026-04-17 기준 시스템 현황 분석 보고서를 작성했음.

서비스가 복잡해질수록 데이터 간 불일치가 쌓임. 특히 결제/정산처럼 여러 단계를 거치는 흐름은 중간 어딘가에서 엣지케이스가 터지기 쉬움. 주기적으로 전체 데이터를 돌아보면서 이상 징후를 조기에 발견하는 게 목적이었음.

몇 가지 불일치 항목이 있었음. 특정 처리 경로에서 상태 전환이 누락되거나, 집계 쿼리에 과거 타입이 포함되어 실제 수치와 다르게 나오는 케이스가 있었음.

-- 이상 데이터 확인 예시
SELECT count(*), status
FROM 내부테이블
WHERE created_at < NOW() - INTERVAL 3 DAY
  AND status = 'PENDING'
GROUP BY status;

발견된 항목은 후속 커밋에서 수정 반영했음. 재현 조건을 문서화하고, 동일 패턴 재발을 막기 위해 쿼리에 방어 조건을 추가했음. 보고서는 HTML 파일로 생성해서 내부에서 공유했음.

데이터 감사는 버그를 찾는 게 목적이 아니라, 시스템 상태를 이해하는 게 목적임. 정기적으로 하면 문제가 커지기 전에 잡을 수 있음.

이번 작업에서 몇 가지 원칙을 확인했음.

단일 책임 원칙: 각 클래스/함수가 하나의 역할만 담당하도록 구분했음. 역할이 섞이면 수정할 때 예상치 못한 곳에 영향이 가기 쉬움.

방어적 프로그래밍: 외부 입력이나 외부 시스템 응답은 항상 의심하고 검증하는 코드를 넣었음. 특히 null 처리와 상태 검증은 빠뜨리기 쉬운 부분임.

로깅: 주요 처리 지점마다 로그를 남겼음. 운영 중 이슈가 생겼을 때 로그만 봐도 원인을 찾을 수 있어야 함.

log.info("처리 시작: id={}, type={}", id, type);
// ... 처리 ...
log.info("처리 완료: id={}, result={}", id, result);