AI로 정산 시스템을 만들기 전 정해야 할 7가지 정책

정산은 단순한 뺄셈 기능이 아니다. 주문별 권리와 의무를 확정하고, 플랫폼이 보관하거나 지급해야 할 자금을 분리하며, 환불·분쟁·세금·송금 실패까지 추적하는 장부 시스템이다.

생성형 AI는 코드와 테스트 작성을 도울 수 있지만 정산 정책의 책임 주체가 될 수는 없다. 정책이 비어 있으면 AI는 그럴듯한 기본값을 만들거나 예외를 누락할 수 있으며, 그 결과는 과지급, 중복 지급, 세금 오류 또는 유동성 사고로 이어질 수 있다.

2024년 티몬·위메프 사태에서 확인할 원칙

2024년 티몬과 위메프의 대규모 판매대금 미정산은 정산 지연이 판매자와 소비자에게 얼마나 큰 연쇄 피해를 줄 수 있는지 보여줬다. 다만 사태의 원인을 긴 정산 주기 하나로만 단정해서는 안 된다. 자금 운용, 유동성, 지배구조와 내부 통제 등 여러 요인이 함께 검토돼야 한다.

운영자가 얻어야 할 핵심 교훈은 명확하다.

• 아직 지급하지 않은 판매대금을 자유롭게 쓸 수 있는 회사 현금으로 간주하지 않는다.
• 정산 주기가 길수록 한 번의 장애나 유동성 부족에 노출되는 미지급 잔액이 커진다.
• 판매대금 잔액과 실제 보관 자금을 매일 대사한다.
• 정산 조건과 지연 사유를 판매자에게 투명하게 공개한다.
• 관련 법령, 계약 구조와 PG 서비스 범위를 따로 확인한다.

판매대금의 법적 귀속과 보호 방식은 거래 구조에 따라 달라질 수 있다. 따라서 일상적으로는 ‘남의 돈’이라는 경계심을 유지하되, 실제 회계·법률 처리는 계약과 현행 법령에 따라 판단해야 한다.

구현 전에 정해야 할 7가지 정산 정책

1. 정산 기준일과 지급 주기

먼저 주문이 언제 정산 가능한 상태가 되는지 정의한다. 주문일이나 결제일만 기준으로 삼으면 배송 전 취소와 반품 가능 금액이 지급 대상에 들어갈 수 있다.

일반적인 상품 거래에서는 다음과 같은 흐름을 설계할 수 있다.

1. 결제 승인
2. 배송 완료
3. 구매 확정 또는 약정된 기간 경과에 따른 자동 확정
4. 반품·분쟁·이상 거래 여부 검사
5. 정산 대상 확정
6. 지급 배치 편입
7. 송금 및 대사 완료

반드시 결정할 항목은 다음과 같다.

• 상품, 디지털 콘텐츠, 서비스 등 거래 유형별 정산 기준 사건
• 자동 구매 확정까지의 기간과 기산 시점
• 매일, 매주 또는 월 단위의 지급 주기
• 주말과 공휴일 처리 방식
• 정산 마감 시각과 마감 이후 거래의 귀속 배치
• 최소 지급액과 소액 잔액 이월 여부
• 판매자 등급별로 다른 주기를 허용할지 여부
• 법령이나 계약상 지급 기한을 초과하지 않는지 확인하는 절차

정산 가능일과 실제 지급일은 구분해야 한다. 예를 들어 eligible_at은 지급 조건을 충족한 시각이고, scheduled_payout_at은 지급 배치에 편입된 시각이며, paid_at은 송금 성공이 확인된 시각이다.

2. 수수료 계산과 정산 명세서

판매자에게 최종 지급액만 보여주면 검산이 어렵고 문의와 분쟁이 늘어난다. 주문 단위 명세와 기간별 합계가 모두 필요하다.

수수료 정책에는 계산 기준도 명시해야 한다. 할인 전 판매가와 할인 후 결제액 중 무엇을 기준으로 하는지, 배송비와 부가가치세를 포함하는지, 부분 환불 시 수수료를 어떻게 되돌리는지 정해야 한다.

금액은 부동소수점 자료형으로 계산하지 않는 것이 안전하다. 원화처럼 최소 화폐 단위가 정수인 경우 정수로 저장하고, 외화나 소수 계산이 필요하면 고정소수점 자료형과 통화별 반올림 규칙을 사용한다.

3. 환불과 마이너스 정산

이미 판매자에게 지급한 주문이 나중에 환불될 수 있다. 이 경우 환불액과 환급할 수수료를 조정 원장에 기록하고 다음 지급액에서 차감해야 한다.

예를 들어 이번 정산 예정액이 30만 원이고 이전 주문의 환불 관련 차감액이 40만 원이라면 다음과 같이 처리할 수 있다.

• 이번 지급액: 0원
• 미회수 잔액: 마이너스 10만 원
• 다음 정산으로 넘길 금액: 10만 원 차감

정책에는 다음 항목이 필요하다.

• 부분 환불 시 상품가, 배송비와 수수료의 배분 방식
• 마이너스 잔액의 이월 기간과 상계 순서
• 장기간 판매가 없는 판매자에게 회수하는 방법
• 보증금이나 지급준비금을 둘 수 있는 계약상 근거
• 판매자 탈퇴 전에 미결제 의무를 확인하는 절차
• 환불 취소나 분쟁 결과 변경 시 반대 분개하는 방식

기존 거래 기록을 덮어쓰지 말고 원거래와 조정 거래를 연결해야 한다. 그래야 어느 환불이 어떤 정산을 변경했는지 재현할 수 있다.

4. 지급 보류와 해제

전체 판매자 계정의 지급을 무조건 중단하기보다 주문, 금액 또는 사유별로 보류할 수 있어야 한다. 대표적인 보류 사유는 다음과 같다.

• 소비자 분쟁이나 반품 진행
• 자전거래, 계정 탈취 또는 비정상 결제 의심
• 판매자 본인·사업자·계좌 인증 실패
• 법원, 수사기관 또는 관계 기관의 적법한 요청
• 계약상 정산 서류 미제출

각 보류 기록에는 대상 금액, 사유 코드, 근거 자료, 시작 시각, 검토 기한, 담당자와 해제 조건을 저장한다. 판매자 화면에는 공개 가능한 범위에서 보류 금액과 이유, 필요한 조치, 문의 경로를 표시한다.

운영자가 임의로 보류를 반복하지 못하도록 생성과 해제 권한을 분리하고, 큰 금액의 보류 해제에는 이중 승인을 적용하는 것이 좋다.

5. 판매대금 분리 관리와 PG·에스크로 구조

미지급 판매대금과 회사 운영비를 같은 가용 현금처럼 관리하면 유동성 부족이 곧 미정산으로 번질 수 있다. 최소한 내부 장부와 계좌 운영에서 판매대금 관련 자금과 운영자금을 명확히 구분하고 매일 잔액을 대사해야 한다.

다만 별도 계좌를 만들었다는 사실만으로 법적 도산격리나 완전한 자금 보호가 자동으로 성립하는 것은 아니다. 신탁, 예치, 지급보증 등 보호 방식의 효력과 의무는 적용 법령 및 계약 구조를 검토해야 한다.

플랫폼이 결제와 지급 과정에서 어떤 역할을 수행하는지에 따라 전자지급결제대행업 등 전자금융거래법상 등록 문제가 발생할 수 있다. 모든 플랫폼이 동일하게 PG 등록 대상인 것도 아니고, 단순히 정산 데이터를 계산했다는 이유만으로 항상 등록 대상이 되는 것도 아니다. 실제 자금 수취·보관·전달 방식과 계약관계로 판단해야 한다.

초기 플랫폼은 등록 PG가 제공하는 결제, 에스크로 또는 판매자별 분할 정산 서비스를 검토할 수 있다. 그러나 PG를 이용해도 다음 책임은 사라지지 않는다.

• 어떤 주문을 언제 지급 대상으로 전달할지 결정
• 수수료와 조정액 계산
• 환불과 마이너스 이월 관리
• 판매자 정보와 계좌 검증
• PG 결과와 내부 원장 대사
• 장애와 지급 실패 대응

에스크로 의무와 예외도 거래 유형과 결제수단 등에 따라 다르므로 전자상거래법과 하위 규정을 확인해야 한다.

6. 원천징수, 부가가치세와 증빙

‘개인 판매자는 무조건 3.3%를 뗀다’는 규칙은 정확하지 않다. 3.3%는 일반적으로 사업소득에 대한 소득세 3%와 개인지방소득세 0.3%를 합쳐 부르는 표현이다. 실제 원천징수 여부는 판매자의 사업자등록 유무만이 아니라 소득의 성격, 계약관계, 지급 항목과 예외 규정에 따라 달라진다.

가입과 계약 단계에서 다음 정보를 받아야 한다.

• 개인, 개인사업자, 법인 등 판매자 유형
• 국내외 거주자 또는 법인 여부
• 과세, 면세, 간이과세 등 세무상 상태
• 사업자등록번호와 주민등록번호 등 법정 신고에 필요한 정보
• 소득의 성격과 지급 사유
• 세금계산서, 계산서 또는 원천징수영수증 등 필요한 증빙

사업자 판매자에게도 ‘항상 아무 세금도 공제하지 않고 100% 지급한다’고 일반화하면 안 된다. 플랫폼 수수료를 차감하는 계약이라면 거래 총액, 수수료, 부가가치세와 실제 송금액을 구분해야 한다. 플랫폼이 제공한 중개 서비스의 수수료에 대한 세금계산서 발급 주체와 시점도 계약 및 세법상 공급관계에 맞춰 정한다.

원천세는 통상 지급일이 속하는 달의 다음 달 10일까지 신고·납부하는 구조가 적용되지만, 예외나 기한 변경 가능성이 있으므로 실제 신고 시점의 규정을 확인해야 한다. 세무 규칙을 코드에 고정하기보다 적용 시작일과 종료일이 있는 버전형 정책으로 관리하는 편이 안전하다.

7. 지급 실패, 정산 어드민과 감사 로그

정상적으로 생성된 지급도 계좌 오류, 예금주 불일치, 거래 제한, 은행 점검 또는 PG 장애로 실패할 수 있다. 실패를 단순히 ‘미지급’으로 표시하지 말고 상태와 재처리 규칙을 세분화한다.

권장 상태 예시는 다음과 같다.

• scheduled: 지급 예약
• submitted: 은행 또는 PG에 요청 전달
• processing: 외부 기관 처리 중
• paid: 성공 확인
• failed_retryable: 재시도 가능한 실패
• failed_final: 정보 수정 등이 필요한 최종 실패
• reversed: 성공 후 취소 또는 반환

재시도에는 동일 지급을 식별하는 멱등성 키를 사용해야 한다. 응답 지연을 실패로 오인해 다시 송금하면 중복 지급이 발생할 수 있으므로, 외부 거래번호를 조회해 기존 요청의 결과를 먼저 확인한다.

감사 로그에는 다음을 남긴다.

• 행위자와 사용한 운영자 계정
• 실행 시각과 접근 위치 등 보안 정보
• 변경 전후 값
• 보류·해제·수동 조정의 사유
• 승인자와 실행자
• 관련 주문, 정산 배치와 외부 거래번호
• 실패 코드와 재시도 이력

감사 로그는 일반 운영자가 수정하거나 삭제할 수 없도록 보호하고, 개인정보와 금융정보는 최소 수집, 접근 통제, 암호화와 보존기간 정책을 적용한다.

정산 데이터 모델의 최소 구성

AI에 화면부터 만들게 하기보다 다음 원장을 먼저 정의하는 것이 좋다.

각 원장에는 통화, 정책 버전, 생성 시각과 원거래 연결 키가 있어야 한다. 주문 상태를 바꾸는 것만으로 과거 정산 금액이 조용히 변경돼서는 안 된다.

반드시 유지해야 할 통제 규칙

정산 시스템은 다음과 같은 불변 조건을 자동 검사해야 한다.

• 하나의 정산 항목은 정확히 한 판매자와 한 원거래에 연결된다.
• 동일한 지급 키로 두 번 송금하지 않는다.
• 지급 완료액과 미지급액, 보류액, 조정액의 합계가 원장과 일치한다.
• 수동 조정에는 사유와 승인자가 존재한다.
• 이미 마감한 정산은 수정하지 않고 반대 분개와 새 조정으로 고친다.
• 내부 판매대금 관련 잔액과 PG·은행 잔액의 차이를 매일 조사한다.
• 세금과 수수료 계산에는 적용된 정책 버전을 기록한다.

AI에 전달할 정책 명세 예시

다음과 같이 요구사항을 구조화하면 누락을 줄일 수 있다.

주문 상태와 정산 상태를 분리해 설계한다. 거래 유형별 구매 확정 조건, 매주 수요일 지급 배치, 휴일 처리, 수수료 기준, 부분 환불 배분, 마이너스 이월, 건별 지급 보류, 원천징수 정책 버전, 지급 멱등성 키와 변경 불가능한 감사 로그를 구현한다. 금액은 정수 또는 고정소수점으로 처리한다. 모든 수동 조정에는 이중 승인과 사유가 필요하다. 구현하기 전에 최소 지급액, 자동 구매 확정 기간, 장기 마이너스 회수, 보류 기한, 재시도 횟수처럼 정해지지 않은 정책을 질문 목록으로 제시하라.

AI에는 코드만 요청하지 말고 다음 산출물도 함께 요구한다.

• 상태 전이도와 예외 목록
• 데이터베이스 스키마와 제약조건
• 권한·승인 체계
• 정상, 경계값, 장애와 중복 요청 테스트
• 일별 대사 보고서 형식
• 장애 복구와 수동 처리 절차
• 개인정보와 금융정보 보호 점검표

출시 전 점검표

• 거래 유형별 정산 기준일이 문서화돼 있다.
• 판매자가 정산 명세를 주문 단위로 검산할 수 있다.
• 부분 환불과 마이너스 이월 테스트를 통과했다.
• 보류 사유, 기한과 해제 권한이 정의돼 있다.
• 판매대금 관련 자금과 운영자금의 관리 기준이 구분돼 있다.
• PG·에스크로·전자금융업 해당 여부를 전문가와 확인했다.
• 판매자 및 소득 유형별 세무 처리를 검토했다.
• 중복 지급 방지와 실패 재시도 테스트를 완료했다.
• 은행·PG·내부 원장의 일별 대사가 가능하다.
• 운영자의 수동 변경이 감사 로그에 남는다.
• 정산 장애 시 판매자 공지와 문의 대응 절차가 있다.

결론

안전한 정산 시스템의 출발점은 AI 프롬프트가 아니라 명시적인 정책과 분리된 원장이다. AI는 확정된 규칙을 코드, 테스트와 문서로 옮기는 도구로 활용하고, 자금 보관 구조와 전자금융·세무 판단은 PG, 회계·세무 전문가 및 법률 전문가와 함께 검증해야 한다.