핵심 요약
- 이 글을 읽으면 엑셀 대사의 한계 시점을 객관적으로 판단하고, 자동화 설계에 필요한 3가지 핵심 정책(기준 키, 주기, 불일치 처리)을 즉시 확정할 수 있어요.
- 정산 대사(Settlement Reconciliation) 자동화는 단순히 편리함을 넘어 데이터 정합성의 문제예요. 수동 대사는 월 거래 건수 300건 이하, 혹은 단일 PG사 운영 단계까지만 권장해요.
- 엑셀 대사의 한계가 오는 시점은 '거래액'보다 '부분 취소'와 '가상계좌 환불'의 빈도로 결정돼요. 취소 로직이 복잡해지는 순간부터는 인건비가 자동화 구축 비용을 추월해요.
- 기획자는 자동화 구축 전, 주문 데이터와 결제 데이터를 매칭할 기준 키(Reconciliation Key)와 상태 불일치 처리 정책을 먼저 확정해서 개발자에게 전달해야 해요.
1인건비보다 운영 리스크가 커지는 지점: 자동화 전환 의사결정 기준
월 거래 건수와 취소/환불의 복잡도를 객관적 지표로 삼아 자동화 도입 적기를 판단해요. 단순히 업무가 귀찮은 수준을 넘어 아래 마지노선을 넘었다면 개발 우선순위를 즉시 조정해야 해요.
자동화 전환 의사결정 분기표
| 구분 | 수동 대사(엑셀) 유지 권장 | 자동화 전환 검토 필수 |
|---|---|---|
| 거래 건수 | 월 300건 이하 | 월 500건 이상 |
| 연동 구조 | 단일 PG사 운영 | 2개 이상의 PG사 또는 간편결제 직접 연동 |
| 예외 케이스 | 전체 취소 위주 | 부분 취소, 가상계좌 환불, 휴대폰 익월 환불 빈번 |
| 운영 리스크 | 담당자 확인으로 커버 가능 | 데이터 불일치로 인한 정산 사고 우려 |
판단 기준 1: 부분 취소와 환불의 복잡성
카드는 기본적으로 '취소' 처리가 되어 전산상 데이터가 일치하기 쉬워요. 하지만 가상계좌 입금 후 '환불'이나 휴대폰 결제의 익월 환불처럼 돈의 흐름이 복잡해지면 엑셀로는 추적이 어려워져요. 특히 주문 상품 3개 중 1개만 부분 취소하는 건이 늘어나면, 주문 금액과 실제 정산 금액이 계속 어긋나는 현상이 발생해요.
판단 기준 2: 복수 PG사 확장
단일 PG사라면 해당 관리자 화면만 확인하면 돼요. 하지만 서비스가 커져서 카드사 직접 계약, 네이버페이/카카오페이 개별 연동을 추가하는 순간 대조해야 할 엑셀 파일이 N개로 늘어나요. 각 사마다 엑셀 양식이 다르기 때문에 이를 하나로 합치는 데만 상당한 시간이 소요돼요.
추천안
월 거래 300건 이하인 초기 팀은 엑셀 대사로 정책을 잡아가는 단계가 필요해요. 하지만 월 500건을 넘어서거나, 부분 취소 정책을 도입하는 시점에는 무조건 자동화 설계를 시작해요.
2개발 효율을 높이는 3가지 설계 기둥: 기준 키, 주기, 불일치 정책
자동화 시스템의 뼈대가 되는 핵심 정책을 기획 단계에서 먼저 정의해야 개발 재작업을 막고 운영 예외 상황에 대비할 수 있어요.
2-1. 정산 대사 기준 키(Reconciliation Key) 확정
주문 데이터와 결제 데이터를 매칭할 고유 식별자를 확정해요.
- 주문 번호(Order ID): 서비스 내부에서 생성한 번호.
- 결제 번호(Payment ID/TID): PG사에서 생성한 고유 번호.
가장 권장하는 방식은 서비스 주문 번호를 PG사 결제 요청 시 파라미터로 넘기고, 나중에 PG사 API로 데이터를 받아올 때 이 주문 번호를 기준으로 대조하는 거예요. 이를 통해 '결제는 있는데 주문이 없는 건'을 자동으로 식별해요.
2-2. 대사 주기와 시점 정책
데이터를 대조하는 시점과 주기를 운영 목적에 맞게 설계해요.
- 실시간 업데이트: 결제 완료 웹훅(Webhook) 수신 즉시 주문 상태를 업데이트해요.
- 일 단위 전수 조사(Batch): 매일 새벽, 전날의 PG사 결제 내역 API를 호출해 전체 주문 데이터와 전수 대조를 수행해요.
보통은 실시간 웹훅으로 처리하되, 네트워크 오류 등으로 웹훅을 놓치는 경우에 대비해 일 단위 배치 대사를 병행하는 구조를 설계해요.
2-3. 상태 불일치(Mismatch) 처리 프로세스
데이터가 일치하지 않는 예외 건 발생 시의 운영 정책을 확정해요. 불일치 건 발견 시 관리자 페이지에 알림을 띄우고, 담당자가 수동으로 '강제 성공' 처리를 할지 아니면 '자동 취소'를 할지에 대한 승인 프로세스를 정의해야 해요.
3데이터 정합성을 위협하는 3가지 복병: 수수료와 환불 로직
현실적인 정산 오차를 줄이기 위해 수수료 변동성과 결제 수단별 취소/환불 특성을 정확히 이해하고 로직에 반영해요.
정산 주기와 대사 시점의 차이
정산 주기(실제 입금일)와 정산 대사(데이터 정합성 확인)를 구분해요. 정산 대사는 '결제가 제대로 일어났는가'를 확인하는 작업이고, 정산 주기는 '그 돈이 언제 입금되는가'의 문제예요. 자동화는 '결제 데이터 대사'부터 시작하고, 이후에 입금액까지 맞추는 '입금 대사'로 확장하는 것이 현실적이에요.
PG 수수료 구조의 변동성
PG 수수료는 카드사 수수료 + PG 마진 + 부가세 구조예요. 우대수수료율이 적용되는 가맹점은 국세청 매출신고 기준에 따라 분기마다 수수료율이 바뀔 수 있어요. 수수료를 코드에 고정값으로 박아두면 실제 입금액과 차이가 발생하므로, 수수료 계산 로직은 관리자 화면에서 수정 가능하도록 설계해요.
취소와 환불의 전산 처리 구분
카드는 취소이고, 가상계좌 입금 후 처리는 환불이에요. 자동화 시스템에서 '환불' 건을 '취소' 로직으로 처리하면 API 오류가 발생해요. 특히 휴대폰 결제처럼 당월 취소와 익월 환불의 처리가 완전히 다른 수단은 기획 단계에서 예외 케이스로 반드시 정의해요.
자동화 전환 판단 체크리스트
우리 팀의 현재 상태를 점검해요. 3개 이상 해당한다면 더 늦기 전에 개발 우선순위에 반영해요.
정책 체크리스트
- 정산 대사 업무에 기획자 또는 재무 담당자가 월 4시간 이상을 쓰고 있어요.
- 결제는 성공했는데 주문이 누락된 건을 고객 문의(CS)를 통해서만 발견하고 있어요.
- 부분 취소, 취소 기간 경과 후 환불 등 예외 케이스가 월 10건 이상 발생해요.
- 2개 이상의 PG사 혹은 간편결제 수단을 직접 연동하여 운영 중이에요.
구현 체크리스트
- 결제 완료 웹훅(Webhook) 성공을 보장하는 재시도 로직이 구현되어 있어요.
- PG사 결제 내역 조회 API를 주기적으로 호출하여 데이터를 동기화하고 있어요.
- DB에 PG사 고유 번호(TID)와 주문 번호(Order ID)가 1:1로 매핑되어 있어요.
- 결제 데이터 정합성 오류 발생 시 담당자에게 즉시 알림을 보내는 시스템이 있어요.
다음 단계
대사 자동화 시점을 판단했다면, 다음은 정산 모델과 정산 주기를 보며 운영 구조를 확정할 차례예요.
추천 콘텐츠
플랫폼인데 셀러 정산을 엑셀로 하고 있다면 플랫폼 정산 모델별로 어떤 데이터 구조가 필요한지 정리해요.
정산 주기 결정 가이드: 익일 vs 구매확정 vs 월 정산, 우리 서비스에 맞는 3가지 기준 정산 주기를 어떻게 잡아야 대사 작업이 덜 꼬이는지 확인해요.
실제 연동할 때
자동화 기준을 잡았다면 실제 데이터 소스는 다음에서 가져와요.
바로 참고할 문서
- 더 복잡한 판단이 필요하다면: 부트페이 도입 문의