정산 대사 — 설명되지 않는 잔액이 없어야 끝난다

한 줄 요약

정산은 우리 기록과 결제대행사 기록을 맞춰 보는 대사에서 시작하고, 어긋남은 몇 가지 정해진 모양으로만 나타나므로 모양별로 갈라내야 각각 다음에 할 일이 정해진다.

왜 이게 필요했나

정산은 "우리가 받을 돈" 과 "판매자에게 줄 돈" 을 확정하는 일입니다. 그런데 우리 주문 시스템과 결제대행사의 기록은 저절로 일치하지 않습니다. 서로 다른 회사의 서로 다른 시스템이 서로 다른 시각에 서로 다른 사건을 적기 때문입니다. 그래서 매일 두 파일을 맞춰 보고 어긋난 것만 사람이 봅니다. 이 일이 대사(reconciliation)이고, 커머스 백엔드에서 가장 오래 살아남는 배치가 대체로 이것입니다.

대사를 하지 않으면 어떻게 될까요. 틀린 금액이 그대로 판매자에게 나갑니다. 한 번 나간 돈은 회수가 대단히 어렵고, 몇 달 뒤에 발견되면 이미 정산이 여러 회차 쌓여 있어 어느 회차가 틀렸는지조차 찾기 어렵습니다. 그래서 대사의 목표는 "차이를 0으로 만드는 것" 이 아니라 남은 차이를 전부 설명할 수 있게 만드는 것 입니다. 설명되지 않는 잔액이 없으면 대사가 끝난 것입니다.

어떻게 동작하나

대사의 뼈대는 단순합니다. 양쪽 기록에 공통된 열쇠로 짝을 짓고, 짝이 없거나 값이 다른 것을 모읍니다. 열쇠는 승인번호 하나로는 부족합니다 — 같은 승인번호로 결제와 취소가 각각 오기 때문에, 거래 종류까지 함께 열쇠로 삼아야 결제는 결제끼리, 취소는 취소끼리 짝을 찾습니다.

양쪽에 있고 금액도 같다     맞았다양쪽에 있는데 금액이 다르다   한쪽에만 부분 취소가 반영됐다우리에만 있다              우리가 잘못 올렸거나, 상대 파일이 아직 안 왔다상대에만 있다              통지를 놓쳤거나, 같은 주문이 두 번 처리됐다

"우리에만 있다" 는 한 번 더 갈라야 합니다. 자정을 걸친 거래는 우리 쪽 날짜와 상대 쪽 날짜가 하루 다르므로, 하루치만 놓고 보면 누락처럼 보이지만 다음 날 파일을 함께 보면 짝이 맞습니다. 진짜 없는 것과 하루 늦게 오는 것을 구별하지 못하면 매일 같은 건을 다시 조사하게 됩니다. 정산 파일은 대개 쉼표로 구분된 평문으로 오는데, 따옴표와 줄바꿈 처리 같은 세부는 [RFC 4180](https://datatracker.ietf.org/doc/html/rfc4180) 이 정리해 둔 규칙을 기준으로 삼고 파서를 직접 만들지 않는 편이 안전합니다.

대사가 끝나면 돈의 방향을 정합니다. 우리가 플랫폼이면 고객이 낸 돈 전부가 우리 것이 아닙니다. 판매 수수료와 결제 수수료를 빼고 나머지가 판매자에게 갑니다. 수수료율은 계약마다 다르므로 코드에 숫자를 박지 말고 표로 두어야 하고, 비율 계산은 1,000분율 정수로 해야 마지막 1원이 어긋나지 않습니다. 그리고 대사에서 어긋난 주문은 지급에서 빼 두어야 합니다 — 확정되지 않은 돈을 내보내는 것이 가장 비싼 실수입니다.

현장에서 만나는 모습

대사 배치를 처음 만드는 사람이 가장 많이 놀라는 것은 "맞는 날이 하루도 없다" 는 사실입니다. 정상적으로 돌아가는 서비스에서도 매일 몇 건은 어긋나고, 그것이 고장이 아닙니다. 시스템이 여럿이고 시각이 다르면 어긋남은 상수입니다. 그래서 목표를 "어긋남 0건" 으로 잡으면 팀이 지치고, "설명되지 않는 어긋남 0건" 으로 잡아야 일이 끝납니다.

"거래액" 과 "매출" 이 다른 숫자라는 사실이 회의에서 자주 부딪힙니다. 중개만 하는 플랫폼은 상품 판매액 전체가 아니라 받은 수수료를 자기 매출로 보는 것이 보통이지만, 총액으로 볼지 순액으로 볼지는 회계 기준과 계약 내용이 정합니다. 개발자가 판단할 문제가 아니고, 시스템이 할 일은 두 숫자를 모두 남겨 두는 것 입니다. 거래액만 저장하고 수수료를 저장하지 않으면 나중에 어느 쪽으로도 다시 계산할 수 없습니다. 세금계산서를 누가 누구에게 발행하는지도 이 구분을 따라가므로, 발행 대상과 금액 기준은 [부가가치세법](https://www.law.go.kr/%EB%B2%95%EB%A0%B9/%EB%B6%80%EA%B0%80%EA%B0%80%EC%B9%98%EC%84%B8%EB%B2%95) 원문과 세무 검토로 확정하고, 전자세금계산서 발행 절차는 [국세청 홈택스](https://www.hometax.go.kr/) 안내를 근거로 삼아야 합니다.

지급 주기와 보류도 늘 분쟁거리입니다. 언제 지급하는지, 어떤 경우에 얼마나 보류하는지는 판매자와의 계약이 정하는 것이라 회사마다 다릅니다. 엔지니어가 할 일은 그 규칙을 코드가 아니라 데이터로 두고, 보류된 건마다 사유를 남겨 목록으로 보여 주는 것입니다. "왜 이번 회차에 이 금액이 빠졌습니까" 라는 질문에 화면으로 답할 수 있으면 정산 담당자의 하루가 통째로 바뀝니다.

마지막으로, 대사 결과는 사람이 읽을 수 있어야 합니다. "불일치 12건" 이라고만 적힌 보고서는 아무에게도 다음에 할 일을 주지 못합니다. 취소 누락은 재고와 매출을 되돌려야 하고, 중복 승인은 고객에게 환불해야 하고, 금액 차이는 상대 쪽 부분 취소를 우리 기록에 반영해야 하고, 날짜 차이는 아무것도 하지 않고 다음 회차로 넘기면 됩니다. 같은 12건인데 처방이 네 가지입니다.

다음 실습에서 할 것

우리 매출 기록과 결제대행사의 이틀치 정산 파일을 맞춰 보고, 어긋난 건을 취소 누락·중복 승인·금액 차이·날짜 차이 네 가지 모양으로 갈라냅니다. 그다음 판매 수수료와 결제 수수료를 빼고 판매자별 지급 예정액을 내고, 지급을 멈춰야 할 돈과 다음 회차로 넘길 돈을 따로 세웁니다.