정산 시스템 개발, 결제 연동보다 어려운 진짜 이유 (2026 가이드)
플랫폼이나 쇼핑몰 개발을 맡길 때 대표님들이 가장 먼저 묻는 건 "결제 되나요?"입니다. 그런데 정작 오픈 후에 회사를 멈추게 만드는 건 결제가 아니라 정산인 경우가 많습니다. 돈은 잘 들어왔는데 그 돈을 판매자나 지점에 정확히 나눠주는 과정에서 숫자가 어긋나기 시작하면, 회계 마감이 막히고 문의 전화가 몰립니다.
결제 연동 자체는 요즘 크게 어렵지 않습니다. 진짜 일은 그다음부터입니다. 이 글은 정기결제(구독 결제)와 정산 시스템을 외주로 만들 때, 견적서를 받기 전에 대표가 미리 알아두면 좋은 것들을 정리했습니다. 위시켓이나 크몽에서 개발자를 구하든 제작 업체에 맡기든, 판단 기준은 크게 다르지 않습니다.
결제 연동과 정산은 다른 문제다, 대부분 여기서 오해한다
결제는 고객에게 돈을 받는 일이고, 정산은 받은 돈을 판매자, 지점, 파트너에게 나눠주는 일입니다. 두 작업은 난이도가 완전히 다릅니다.
판매자가 한 명뿐인 자사몰이라면 정산이라는 개념이 거의 없습니다. 들어온 돈이 곧 내 돈이기 때문입니다. 하지만 여러 판매자가 입점하는 플랫폼, 여러 지점이 매출을 나누는 프랜차이즈, 인플루언서에게 대가를 지급하는 중개 서비스라면 이야기가 달라집니다. 누가 얼마를 언제 어떤 근거로 받는지를 시스템이 1원 단위로 계산하고 증명할 수 있어야 합니다.
견적서에 "결제 연동"이라고만 적혀 있고 정산에 대한 언급이 없다면, 그 프로젝트는 오픈 후에 정산을 사람이 엑셀로 계산하게 될 가능성이 높습니다.
정기결제(구독 결제)는 일반 결제와 무엇이 다를까?
정기결제는 카드 정보를 그대로 저장하는 게 아니라 빌링키를 발급받아 두고, 정해진 주기마다 서버가 자동으로 결제를 요청하는 방식입니다. 한 번 승인받고 끝나는 일반 결제와 달리 매달 성공과 실패가 반복되는 흐름을 관리해야 합니다.
여기서 놓치기 쉬운 지점이 세 가지 있습니다.
- 결제 실패 처리: 카드 한도 초과, 유효기간 만료, 정지된 카드로 결제가 실패했을 때 언제 다시 시도할지, 몇 번 실패하면 서비스를 멈출지 정책이 필요합니다.
- 중도 해지와 일할 계산: 월 중간에 해지하면 남은 기간을 어떻게 환불할지 규칙이 있어야 합니다.
- 정기결제 심사: 자동결제는 결제대행사와 별도 계약이나 심사가 필요한 경우가 많아 일정에 미리 반영해야 합니다.
구독형 창고대여 플랫폼을 만들 때도 구독 결제 자체보다, 결제와 자동 정산을 연결하고 운영 데이터를 무중단으로 옮기는 쪽이 훨씬 무거운 작업이었습니다.
정산에서 사고가 나는 지점 네 가지
정산 오류는 대부분 아래 네 곳에서 나옵니다.
- 취소와 환불이 정산 뒤에 들어올 때. 이미 판매자에게 지급한 뒤 고객이 환불하면, 그 금액을 다음 정산에서 어떻게 회수하고 차감할지 설계돼 있지 않으면 숫자가 어긋납니다.
- 쿠폰과 할인의 부담 주체. 만원짜리 쿠폰을 플랫폼이 부담하는지 판매자가 부담하는지에 따라 판매자 지급액이 완전히 달라집니다. 이 규칙이 시스템에 없으면 매번 손으로 조정하게 됩니다.
- 세금. 개인 판매자나 인플루언서에게 대가를 지급하면 사업소득 원천징수 3.3%가 발생하고, 사업자와는 세금계산서가 오갑니다. 체험단 매칭 플랫폼처럼 개인에게 정산하는 서비스라면 이 부분이 특히 중요합니다.
- 대사. 결제대행사에서 실제로 입금된 금액과 우리 시스템이 계산한 금액이 1원까지 맞아야 회계가 넘어갑니다. 입금 주기와 판매자 지급 주기가 다르기 때문에, 둘을 맞추는 대사 화면이 없으면 매달 마감이 힘들어집니다. 카드사 멤버십과 쿠폰 시스템처럼 대용량 거래에서 금액이 조금도 어긋나면 안 되는 작업을 해보면, 대사는 나중에 붙이는 기능이 아니라 처음부터 설계에 넣어야 하는 뼈대라는 걸 알게 됩니다.
카페24, 아임웹 같은 솔루션으로 정산이 안 되는 경우
결론부터 말하면 단일 판매자 쇼핑몰은 솔루션으로 충분하지만, 다중 판매자 정산은 솔루션 기본 기능만으로는 거의 불가능합니다.
| 구분 | 단일 판매자 솔루션(카페24, 아임웹) | 다중 판매자 자체 정산 |
|---|---|---|
| 판매자 수 | 한 곳(내 매장) | 여러 판매자, 지점, 파트너 |
| 정산 개념 | 사실상 없음(매출이 곧 내 돈) | 판매자별 계산과 지급이 필수 |
| 수수료와 쿠폰 부담 | 단순함 | 거래 건별로 규칙이 다름 |
| 세금 처리 | 내 사업자 기준 | 개인과 사업자 혼재(원천징수 포함) |
| 정산 명세서 | 필요 없음 | 판매자가 직접 확인 가능해야 함 |
15개 지점을 운영하는 타이어 프랜차이즈 프로젝트가 딱 이 경우였습니다. 기성 솔루션 ERP의 한계 때문에 정산, 재고, 매출이 따로 놀던 것을, 운영팀이 직접 조정하는 통합 ERP로 옮기고 나서야 한 화면에서 정산이 맞물려 돌아갔습니다.
정산 시스템 외주, 맡기기 전 확인할 체크리스트
견적을 받기 전에 아래를 업체에 물어보면 경험의 깊이가 드러납니다.
- 취소와 환불이 정산 확정 후에 들어오면 어떻게 처리하나요?
- 쿠폰과 할인 비용의 부담 주체를 거래 건별로 설정할 수 있나요?
- 개인 판매자 원천징수와 사업자 세금계산서를 모두 처리하나요?
- 판매자가 자기 정산 내역을 스스로 확인하는 명세서 화면이 있나요?
- 입금 내역과 시스템 계산을 맞추는 대사 기능이 있나요?
- 정산 담당자와 일반 운영자의 권한을 나눌 수 있나요?
정산 명세서 화면이 왜 중요하냐면, 판매자가 "왜 이 금액인지"를 스스로 확인하지 못하면 그 질문이 전부 전화로 오기 때문입니다. 123타이어 쇼핑몰을 만들 때도 같은 원칙이었습니다. 고객이 스스로 답을 찾게 만들지 않으면 그 일은 전부 직원 전화 업무로 돌아옵니다.
개발 방식과 비용은 어떻게 접근할까
정산은 한 번 만들고 끝나는 기능이 아닙니다. 수수료 정책이 바뀌고, 판매자 유형이 늘고, 세금 규정이 달라질 때마다 손이 갑니다. 그래서 정산 규칙을 코드 밖에서 바꿀 수 있게 처음부터 설계해 두는 편이 길게 보면 비용을 아낍니다.
크게 새로 만드는 신규 제작이 맞는 회사가 있고, 이미 돌아가는 시스템에 정산을 얹거나 이후 문구와 정책 수정을 이어가는 유지보수(월 150만원)가 맞는 회사가 있습니다. 어느 쪽이든 오픈 첫 달 정산 마감을 함께 넘겨줄 수 있는 파트너인지가 핵심입니다. 정산은 오픈하고 한 달이 지나야 진짜 문제가 보이기 때문입니다.
자주 묻는 질문
정기결제 연동만 하면 구독 서비스를 시작할 수 있나요?
결제만으로는 부족합니다. 결제 실패 재시도, 중도 해지 환불, 그리고 그 매출을 판매자나 파트너에게 나눠주는 정산까지 있어야 실제 운영이 돌아갑니다. 결제는 시작일 뿐입니다.
정산 시스템은 꼭 처음부터 만들어야 하나요?
서비스가 단일 판매자라면 당장은 필요 없을 수 있습니다. 다만 입점 판매자나 지점, 파트너가 생기는 순간 정산이 필요해지므로, 그 계획이 있다면 처음 설계 때 정산 구조를 염두에 두는 편이 나중에 갈아엎는 비용을 줄입니다.
정산 오류는 왜 오픈 후에야 발견되나요?
취소, 환불, 쿠폰, 세금 같은 예외는 실제 거래가 쌓여야 나타나기 때문입니다. 그래서 오픈 첫 정산 마감을 함께 넘길 수 있는 업체인지가 중요합니다.
무료로 한번 점검받아 보세요
정산까지 고려한 결제 구조를 어떻게 잡아야 할지 감이 잘 오지 않는다면, 지금 그리고 있는 서비스 구조를 놓고 한번 점검받아 보셔도 좋습니다. 어니스트패밀리는 정기결제와 자동 정산, 다지점 정산 ERP를 실제로 만들어 온 회사이고, 풀스택 개발자 출신 대표가 직접 상담합니다. 어떤 방식이 맞을지 부담 없이 무료로 상담받아 보세요.
진행 중인 프로젝트나 지금 고민되는 문제를 편하게 들려주세요. 무엇을 만들지 아직 정해지지 않았어도 괜찮습니다.