정산 수수료 4종 차감 시점 분리로 회계 혼선 해소

정산 모듈에 수수료 항목을 추가하는 작업은 얼핏 간단해 보인다. 기존 차감 컬럼에 새 항목을 꽂아 넣으면 되는 것 아닌가 싶은데, 막상 결제대행사 명세를 뜯어보면 얘기가 달라진다. 이번 스프린트에서 카드 PG, 브랜드페이, 핀테크 입출금, 선불 가상계좌 수수료 4종을 정산 모듈에 반영했는데, 반나절짜리로 보이던 작업이 며칠짜리가 된 이유가 바로 청구 시점 때문이었다.

기존 구조는 카드 PG 수수료 한 줄로 전부 뭉뚱그려 차감하는 방식이었다. 항목이 하나뿐이니 시점 구분이 필요 없었다. 수수료 = 이번 달 차감, 끝. 그런데 4종을 펼쳐보니 같은 "수수료"라는 이름 아래 청구 사이클이 전혀 다른 항목들이 섞여 있었다.

차감 시점이 왜 이렇게 중요한가

결제대행사가 청구하는 수수료 4종을 정리하면 아래와 같다.

처음 작업 착수할 때 4종을 전부 정산 차감 컬럼에 넣어버렸다. 논리적으로 자연스럽게 느껴졌다 - 수수료니까 차감에 넣어야지. 그런데 피드백이 왔다. 익월 청구 항목은 이번 정산에서 실제로 머천트 통장에서 빠지지 않는데 차감 표기를 해버리면 회계팀이 장부를 맞출 수가 없다는 것.

머천트 입장에서 생각해보면 당연한 얘기다. 정산서에 100만 원이 차감됐다고 나왔는데 통장에서 70만 원만 빠졌으면, 나머지 30만 원이 어디 갔는지 회계팀은 추적해야 한다. "이건 익월에 나가요"라는 설명이 없으면 매달 같은 컴플레인이 반복된다. 그리고 실제로 반복되고 있었다.

정산 도메인에서 "언제 빠지는가"는 금액만큼이나 중요한 정보다. 같은 100원짜리 수수료라도 이번 달 차감이냐 익월 청구냐에 따라 머천트의 가용 잔액이 달라지고, 회계 전표 날짜가 달라지고, 세금계산서 발행 타이밍도 달라진다. 이걸 하나의 차감 컬럼에 뭉뚱그리는 순간 정산서가 회계 증빙으로서의 기능을 잃는다.

배치와 어드민을 어떻게 쪼갰나

리팩터링 포인트는 두 곳이었다. 출금 신청 화면과 정산 배치.

출금 어드민 화면에서는 익월 청구 항목을 "예정 금액"으로 구분해 별도 라벨을 붙이고, "익월 후정산" 문구를 명시했다. 머천트가 출금 신청 전에 이번 달 실제 차감액과 익월 예정액을 한눈에 구분할 수 있어야 한다.

배치 쪽 분리 로직은 아래처럼 정리했다.

이번 정산 차감 = 카드 PG + 브랜드페이
익월 별도 청구 = 핀테크(건당) + 선불 VA(건당)

배치에서 잔액 계산할 때 익월 청구분을 선제 차감해야 하나 한참 고민했다. 머천트가 익월 청구분 모르고 출금 신청해버리면 나중에 잔액 부족이 생길 수 있으니까. 하지만 결론은 빼지 않음이었다. 청구 예정인 금액을 미리 동결하면 머천트 입장에서 실제로 쓸 수 있는 돈이 줄어드는 효과가 생기고, 이 동결이 정당한지 계약 조건을 다시 확인해야 하는 별도 문제가 된다. 결국 대시보드에 "예상 차감액"으로 노출하는 것으로 합의했다 - 정보는 주되 잔액에서 미리 빼지 않는 방식.

이런 판단이 맞는지 확인할 방법은 실제 계약서 단가와 청구 사이클 확인뿐이다. 추정으로 짜면 다음 정산에서 반드시 깨진다.

같은 "수수료"지만 다른 레이어

정산 작업하다 보면 자꾸 빠지는 함정이 하나 있다. 결제대행사가 이커머스 본체에 청구하는 수수료와, 이커머스가 파트너에 부과하는 수수료를 같은 레이어에서 다루고 싶어지는 것.

• 결제대행사 → 이커머스 본체: 이번 작업 범위, 계약 단가 기반
• 이커머스 → 파트너: 별도 모듈, PENDING/CONFIRMED 상태 흐름

이 두 레이어가 섞이면 마진 계산이 뒤집힌다. 비용 항목이 수익 차감처럼 잡히거나, 파트너 부과 수수료가 대행사 청구분과 합산돼서 정작 마진이 얼마인지 알 수 없게 된다. 코드에서도 그렇지만 문서에서 더 심각하다. 같은 단어 "수수료"를 쓰니까 prefix를 명확히 붙여야 다음 사람이 안 헤맨다. pg_fee, partner_fee 식으로 컬럼 이름부터 구분해두는 게 나중에 디버깅 시간을 줄인다. 이번에도 중간에 "그 수수료가 대행사 수수료예요 파트너 수수료예요?"라는 질문이 오가며 시간을 썼다.

정산 도메인은 도메인 용어집을 먼저 맞추고 들어가는 게 결국 빠른 길이다. 용어가 흔들리면 스펙도 흔들리고 코드도 흔들린다.

작업 끝내고 굳어진 것들을 정리해두면:

• 단가는 절대 추정 금지. 계약서 단가가 없으면 코드 머지 보류. 추정 단가로 배치 돌리면 다음 정산에서 차이가 나고, 그 차이 소명이 훨씬 더 큰 일이 된다.
• "익월 후정산" 라벨 한 줄이 회계 컴플레인 절반을 줄인다. 코드보다 UI 문구가 먼저일 때도 있다.
• 가용 잔액에서 미래 청구분을 미리 빼는 건 계약 검토 없이 해선 안 되는 판단이다. 기술적으로 가능해도 비즈니스 판단이 선행돼야 한다.
• 정산 배치에서 "이번 차감"과 "익월 청구"를 처음부터 다른 컬럼/테이블로 분리해두면, 이후 리포트 뽑을 때 훨씬 수월하다. 나중에 쪼개려 하면 히스토리가 뒤섞여 마이그레이션 비용이 생긴다.

정산 도메인은 개발보다 회계 로직 이해가 병목이 되는 경우가 많다. 코드는 빠르게 짤 수 있는데 "이 금액이 언제 어디서 왜 빠지는가"를 정확히 모르면 짠 코드가 맞는지 검증을 못 한다. 그래서 이 도메인에선 회계팀이나 정산 담당자와 용어부터 맞추는 시간이 아깝지 않다.