플랫폼 이용수수료를 정산 도메인에서 분리해 월 청구 구조로 개편

왜 분리했나

수수료 항목이 한 테이블에 다 섞여있었음. 결제대행사 청구분, 파트너 마진, 플랫폼 자체 이용료가 같은 컬럼에 적재됐고, 정산 보고서 뽑을 때마다 분기문이 늘어나서 도저히 못 봐주겠더라.

특히 플랫폼 이용수수료는 성격이 완전히 다름:
- 결제대행사 수수료: 거래마다 외부로 빠져나감
- 파트너 마진: 상위 계층 수익으로 내부 이동
- 플랫폼 이용료: 우리 매출, 회계상 별도 인식 필요

세 개를 같은 흐름에 묶어두면 손익 분석이 의미가 없어짐.

분리 전후

정산 로직 손본 부분

기존엔 결제 확정 시 모든 수수료를 한 번에 차감했는데, 플랫폼 이용료를 월 청구 모델로 빼면서 트랜잭션 경계가 달라짐.

기존: 결제확정 → [대행수수료 + 파트너마진 + 플랫폼이용료] 한방 차감
개편: 결제확정 → [대행수수료 + 파트너마진] 차감
       월말배치 → [플랫폼이용료] 별도 청구서 발행

상태 머신도 손봤음. 홀딩 → 확정 → 월배치 단계가 추가되면서, 중간에 환불 들어오면 청구 발행 여부에 따라 분기 태움. 발행 전이면 그냥 안 만들면 끝, 발행 후면 차감 청구로 처리.

4개 화면 동시 수정한 이유

수수료 계산, 파트너 어드민 조회, 충전 어드민 조회, 정산 어드민이 전부 같은 데이터 구조를 참조하고 있었음. 한 군데만 고치면 다른 화면이 깨짐. 그래서 한 PR에서 다 같이 처리.

피곤했던 건 화면별로 보여줘야 하는 단가 시점이 달랐다는 점. 어드민에서는 차감 시점 기준, 정산에서는 청구 시점 기준. 같은 숫자인데 라벨이 달라야 했음. 결국 표시용 DTO에 "차감일", "청구예정일", "청구확정일" 세 필드를 다 넣고 화면별로 골라 쓰게 만듦.

회고

분리 자체는 어렵지 않았는데 마이그레이션이 진짜 문제. 기존 데이터를 어떤 기준으로 재분류할지 정하는 데 며칠 썼음. 결국 "이전 데이터는 통합 수수료로 두고 신규부터 분리" 로 끊었음. 깔끔하지 않지만 회계가 이미 닫은 월을 다시 흔드는 것보다는 안전하다고 봤음.

다음