이커머스 결제·정산 전반의 집계 불일치와 상태 누락 개선

한 번에 여러 영역을 만지면서 배운 것

이커머스 플랫폼 전반을 훑으면서 리포트 화면, 입금 정산 배치, 주문 흐름, 엑셀 다운로드 설정까지 한 번에 손을 댐. 처음엔 "검증만 좀 하면 되겠지" 했는데, 막상 들어가보니 영역마다 가정이 조금씩 어긋나 있어서 결국 개선까지 같이 가버림.

영역별로 본 문제와 처방

검증을 하다 결국 리팩터까지 간 이유

• 검증 시나리오를 만들면서 보니 같은 데이터를 화면마다 다르게 집계하고 있었음. 한쪽은 결제 확정 기준, 다른 쪽은 요청 시점 기준. 숫자가 다른 게 당연한 구조였음.
• 정산 배치는 파트너 잔액에 영향 주는 경로라 PENDING이 빠지면 그대로 회계가 어긋남. 결제대행사 통보 시점과 우리 배치 시점이 어긋나면 어떻게 되는지 케이스로 다 적어둠.
• 엑셀은 매번 컬럼 늘려달라는 요청이 들어오는데, 그때마다 컨트롤러/서비스/DTO/헤더 4군데를 만지고 있었음. 레지스트리 한 군데로 모음.

구조 한 줄 요약

요청 → 멱등키 검사 → 도메인 처리 → 상태 PENDING 기록
                                  ↓ (배치/이벤트)
                          홀딩 만료 → CONFIRMED / CANCELLED
                                  ↓
                          잔액 반영 + 리포트 집계

이 흐름이 모든 영역에서 동일하게 보이도록 맞추는 게 이번 작업의 진짜 목표였음. 화면 하나 고치는 게 아니라, 같은 데이터가 어디서 보든 같은 숫자로 보이게 하는 일.

회고

• "검증"이라고 시작했지만 실제로는 가정의 차이를 메우는 작업이었음. 코드 줄 수보다 머릿속 모델 정리에 시간이 더 들어감.
• 멱등성·상태머신·집계 단일소스 — 이 세 개는 결제·정산 도메인에서 진짜 안 빠지는 주제.
• 엑셀 같은 부수 기능도 변경 비용이 누적되는 지점이라 한 번 정리해두면 두고두고 편함.

다음