중개 플랫폼 개발 체크리스트: 매칭·견적·예약·정산 구조 [2026]

중개 플랫폼 개발은 공급자와 수요자 화면을 연결하는 일이 아니라 거래의 상태와 책임을 운영 가능한 규칙으로 만드는 일입니다. 직접 판매와 중개의 역할, 계약·결제·이행·취소·환불·정산·분쟁 경계를 먼저 정하고 관리자와 수동 복구 절차까지 설계해야 거래가 늘어도 통제할 수 있습니다.

판매자·중개자·이용자의 역할부터 구분한다#

공정거래위원회의 전자상거래 소비자 보호 안내는 전자상거래, 통신판매와 통신판매중개를 구분합니다. 플랫폼이 실제로 수행하는 상품 결정·계약·결제·이행·CS 역할을 기준으로 사업 구조를 그리고, 적용 의무와 표시·약관·분쟁 책임은 최신 법령과 법률 자문으로 확인하세요.

수익 모델보다 거래가 끝나는 지점을 먼저 정한다#

리드 전달형은 문의가 전달되면 플랫폼의 핵심 흐름이 끝날 수 있지만, 견적·예약·거래 중개형은 제안 수락, 일정 확정, 이행 확인과 취소·분쟁까지 상태가 이어집니다. 수수료는 어떤 가치를 제공한 어느 시점에 발생하는지, 거래가 실패하면 어떻게 조정되는지와 함께 정의하세요.

거래를 상태 기계와 원장으로 표현한다#

등록, 요청, 제안, 수락, 예약, 승인, 이행, 취소, 환불, 정산 완료를 한 개의 상태값으로 덮어쓰면 부분 이행과 분쟁을 표현하기 어렵습니다. 거래·결제· 이행·정산 상태를 연결하되 분리하고, 누가 어떤 조건에서 다음 상태로 바꿀 수 있는지와 모든 변경 이력을 남기세요.

실무 시나리오: 서비스가 절반만 이행되고 분쟁이 생긴다#

두 회차 서비스 중 첫 회차만 제공된 뒤 구매자가 나머지를 취소했다고 가정하겠습니다. 주문 전체를 완료나 취소로만 표시하면 공급자 대가, 플랫폼 수수료, 결제 환불과 리뷰 권한이 서로 어긋납니다. 회차별 이행 증거와 부분 취소 사유를 남기고 분쟁 동안 정산 대상을 보류한 뒤 승인된 조정 이벤트로만 원장을 바꾸세요.

관리자 기능은 거래 복구 도구로 설계한다#

관리자에게 모든 값을 직접 수정할 권한을 주기보다 공급자 심사, 거래 보류, 증거 열람, 승인된 취소·조정, 재처리와 접근 회수 같은 명시적 행동을 제공하세요. 고위험 조정은 이중 승인과 사유·전후값을 남기고 개인·결제 정보는 역할별로 마스킹합니다. 정산 구조는 플랫폼 수수료·정산 설계에서 더 깊게 확인할 수 있습니다. 생활 서비스 사례는 매칭 플랫폼 구조, 개발 계약의 인수 기준은 외주 계약 체크리스트를 함께 참고하세요.

MVP는 거래 한 종류를 끝까지 닫는 범위로 만든다#

공급자 한 유형과 수요자 한 유형, 핵심 요청·제안·수락·이행 흐름, 운영자 예외 처리와 측정 이벤트를 1차 범위로 잡으세요. 추천·포인트·복잡한 등급을 줄이는 대신 신고, 접근 통제, 거래 이력, 백업과 수동 복구는 생략하지 않습니다. 출시 전에는 정상 거래뿐 아니라 공급자 거절·중복 요청·결제 타임아웃·부분 취소·분쟁·정산 차이를 테스트합니다.