정산 원장에 결제 발생 즉시 PENDING 미러링
목차
정산 원장에 PENDING 상태 미러 로직을 추가하고 취소 시 동기화를 구현했음.
배경
결제가 발생하는 시점과 정산이 확정되는 시점 사이에 시간 차이가 존재함 (가상계좌: 2시간, 카드: 3일). 이 기간 동안 원장에 상태가 반영되지 않으면 운영자가 실제 재무 상황을 실시간으로 파악하기 어려움.
PENDING → CONFIRMED 흐름
결제 발생
└→ PENDING 상태로 원장에 즉시 미러 (발생주의)
├→ hold 기간 경과 후 CONFIRMED
│ └→ 잔액 실제 반영
└→ hold 중 취소
└→ CANCELLED (잔액 변동 0원)
PENDING을 즉시 반영하면 "발생주의" 회계 원칙에 따라 거래 발생 시점의 재무 상태를 보여줄 수 있음. 현금주의(확정 시점만 반영)와는 다른 관점임.
취소 동기화
취소 시 관련된 모든 PENDING 레코드를 CANCELLED로 전환해야 잔액 이중 차감을 막을 수 있음.
| 시나리오 | 처리 |
|---|---|
| PENDING 중 취소 | → CANCELLED, 잔액 변동 없음 |
| CONFIRMED 후 취소 | → 환불 처리, 별도 정산 로직 |
멱등성 키를 활용해서 동일 거래가 중복으로 처리되지 않도록 방어했음.
다음
작업 후기
사내 서비스를 만들다 보면 기능 하나가 단순히 화면에 버튼 하나 추가하는 것으로 끝나지 않는다는 걸 계속 체감함. SQL 집계, 상태 머신, 예외 처리, 화면 렌더링, 권한 체크가 모두 엮여 있어서 어느 하나만 빠뜨려도 숫자가 맞지 않거나 특정 사용자에게 이상한 화면이 나타남.
특히 금융/결제 도메인은 숫자 하나가 틀리면 신뢰가 무너질 수 있어서 꼼꼼함이 기본값이어야 함. "대충 맞는 것 같다"로 넘어가면 나중에 반드시 다시 돌아옴.
개발 방식
- 변경 전 현재 동작 스크린샷이나 수치 메모
- 수정 후 같은 케이스로 확인
- 관련 화면이 있으면 숫자 cross-check
- 커밋 메시지는 "무엇을" 보다 "왜"를 담으려고 노력
작은 커밋을 자주 하면 문제가 생겼을 때 어느 변경에서 깨졌는지 찾기 훨씬 쉬움. 그래서 논리적으로 독립된 단위로 커밋을 쪼개는 습관을 유지 중.
다음
댓글 0
첫 댓글 달아줘.