결제 도메인 첫 설계와 웹훅 멱등성 문제 해결

5월에 결제 도메인에 처음으로 손을 댔다. slecs 전체 흐름에서 결제가 핵심인데, 가장 복잡하고 가장 민감한 부분이라 계속 미뤄왔었다. 더 이상 미루면 다른 도메인 설계가 결제를 모른 채로 굳어버릴 것 같았다.

결제를 처음 설계할 때의 두려움

결제는 실수가 돈으로 이어진다. 그래서 설계를 조심스럽게 했다. PG 연동은 나중이고, 먼저 내부 상태 관리와 트랜잭션 구조를 잡는 게 목표였다.

충전 → 잔액 → 사용 → 환불의 흐름. 각 단계마다 상태값이 필요하고, 실패 케이스에 대한 처리가 빠짐없어야 한다. 특히 중간에 서버가 죽었을 때 정합성이 깨지지 않도록 하는 방법이 핵심 고민이었다.

결제 설계 초안

• 결제 테이블 초안 작성
• 상태: PENDING → CONFIRMED, CANCELLED
• 트랜잭션 경계: 서비스 레이어 기준
• 가상계좌 vs 카드: 확정 타이밍 분리

회사에서도 마침 결제 관련 작업이 있었다. PG사 웹훅 처리를 손봤는데, 중복 처리 방지 로직이 허술하게 짜여 있었다. 같은 웹훅이 두 번 오면 두 번 처리되는 구조였다. 고쳤다. 이게 사이드 설계에도 바로 반영됐다. 멱등성 처리가 얼마나 중요한지 업무에서 직접 확인한 셈이었다.

이론으로만 알던 걸 실전에서 체감하는 게 완전히 달랐다.

결제 도메인을 처음 설계하는 게 두려웠지만, 결국 해냈다. 모르는 게 있으면 찾으면 되고, 틀린 게 있으면 고치면 된다. 완벽한 설계보다 동작하는 설계가 먼저다. 5월에 그 첫 발을 뗐다.