매칭 플랫폼 오픈 전 정해야 할 5가지 정책: 수수료 누수와 품질 붕괴를 막는 운영 규칙

핵심 요약

펫시터, 과외, 인테리어, 청소, 레슨, 돌봄처럼 사람과 사람을 연결하는 매칭 플랫폼은 기능만으로 운영되지 않습니다. 예약, 결제, 프로필, 채팅, 후기 기능을 AI로 빠르게 만들 수는 있지만, 플랫폼의 수익과 신뢰를 지키는 것은 코드가 아니라 정책입니다.

특히 매칭 플랫폼의 매출은 대부분 거래 수수료에서 나옵니다. 공급자와 수요자가 플랫폼을 통해 처음 만난 뒤 외부 연락처를 교환하고 직거래를 시작하면, 플랫폼은 고객 획득 비용과 운영 비용만 부담하고 매출은 잃게 됩니다. 따라서 오픈 전에 장터의 규칙을 먼저 정하고, 그 규칙을 기능 요구사항으로 바꿔 AI와 개발팀에 전달해야 합니다.

매칭 플랫폼은 왜 일반 웹사이트와 다른가

양면 시장의 구조

매칭 플랫폼은 한쪽만 만족시키면 되는 서비스가 아닙니다. 수요자와 공급자 모두가 고객입니다.

이 구조에서는 기능보다 규칙이 중요해지는 순간이 많습니다. 예를 들어 “시터 목록을 보여준다”는 기능은 간단하지만, 누구를 먼저 보여줄지는 사업의 핵심입니다. 응답률이 높고 후기가 좋은 시터를 올릴 것인지, 신규 시터에게도 기회를 줄 것인지, 광고 상품을 넣을 것인지에 따라 장터의 신뢰와 수익 구조가 달라집니다.

기능만 있는 플랫폼이 실패하는 3가지 방식

1. 노출 순서가 없으면 좋은 공급자가 떠난다

등록된 순서대로만 공급자를 보여주면 열심히 일한 사람과 방치된 계정이 같은 취급을 받습니다. 평점 4.9점, 후기 47개, 빠른 응답률을 가진 시터가 아래로 밀리고, 후기가 없는 계정이 상단에 노출될 수 있습니다.

이런 구조에서는 공급자가 좋은 후기를 쌓고 빠르게 응답할 이유가 약해집니다. 수요자도 “왜 이 사람이 먼저 보이지?”라는 불신을 갖게 됩니다. 노출 정책은 검색 품질, 공급자 동기, 고객 신뢰를 동시에 좌우합니다.

2. 연락처가 너무 빨리 공개되면 수수료가 샌다

채팅이 자유롭고 결제 전 연락처가 노출되면 “앱 말고 직접 연락하면 더 싸게 해드릴게요”라는 대화가 쉽게 발생합니다. 이때 플랫폼은 탐색, 추천, 신뢰 형성, 고객 지원 비용을 부담했지만 실제 매출은 얻지 못합니다.

직거래는 단순한 수수료 손실만 만들지 않습니다. 외부에서 거래가 이루어지면 환불, 안전사고, 노쇼, 서비스 품질 문제를 플랫폼이 확인하거나 중재하기 어렵습니다. 결국 수요자와 공급자 모두가 보호 장치 밖으로 나가게 됩니다.

3. 취소 정책이 없으면 한쪽이 일방적으로 손해 본다

당일 취소에도 전액 환불이 된다면 공급자는 하루 일정을 비워두고도 보상을 받지 못할 수 있습니다. 반대로 공급자가 갑자기 취소했는데 아무 페널티가 없다면 수요자는 중요한 일정을 망칠 수 있습니다.

취소 정책은 고객 친화와 공급자 보호 사이의 균형입니다. 기준이 없으면 매번 운영자가 감정적으로 판단해야 하고, 같은 사건에 다른 결론이 나와 불공정 논란이 생깁니다.

오픈 전에 정해야 할 5가지 필수 정책

1. 노출 순서: 누가 상단에 보이는가

노출 순서는 플랫폼의 보상 체계입니다. 상단 노출을 어떤 행동의 결과로 줄 것인지 먼저 정해야 합니다.

권장 기준

• 최근 응답률
• 평균 응답 시간
• 후기 평점
• 후기 수
• 최근 활동일
• 예약 완료율
• 취소율
• 신고 또는 분쟁 이력
• 신규 공급자 여부

예시 정책

중요한 원칙

노출 기준은 완전히 공개하지 않더라도 주요 요소는 화면에 설명하는 것이 좋습니다. 예를 들어 “응답률, 후기, 최근 활동, 예약 완료율을 종합해 추천 순서가 정해집니다”라고 안내하면 공급자가 어떤 행동을 해야 하는지 이해할 수 있습니다.

2. 매칭 방식: 자동 배정인가, 지원과 선택인가

매칭 방식은 고객 경험과 책임 구조를 결정합니다.

신뢰가 중요한 서비스라면 “지원과 선택” 방식이 유리합니다. 보호자나 학부모가 프로필, 후기, 경력, 가능 시간, 가격을 직접 비교하고 선택하면 심리적 안정감이 커집니다. 반면 자동 배정은 빠르지만, 결과가 마음에 들지 않을 때 “플랫폼이 잘못 배정했다”는 불만이 커질 수 있습니다.

3. 취소 정책: 언제, 얼마를 환불하는가

취소 정책은 반드시 결제 전에 보여주고 동의를 받아야 합니다. 결제 후에야 환불 제한을 알게 되면 분쟁 가능성이 커집니다.

예시 취소·환불 기준

위 숫자는 예시이며, 실제 비율은 서비스 특성, 지역 규정, 결제대행사 정책, 고객 기대 수준에 맞춰 정해야 합니다.

공급자 취소 페널티

공급자에게 무조건 금전 벌칙을 부과하는 방식은 법적·운영상 부담이 생길 수 있습니다. 초기에는 다음과 같은 비금전적 페널티가 더 실용적일 수 있습니다.

• 추천 점수 감점
• 일정 기간 상단 노출 제외
• 반복 취소 시 신규 예약 제한
• 고객에게 자동 사과 쿠폰 제공 여부 검토
• 운영자 검토 후 계정 경고 또는 정지

4. 수수료와 직거래 방지: 막는 것보다 보호 이익을 설계해야 한다

수수료율은 사업 모델에 따라 다릅니다. 예를 들어 10%, 15%, 20% 중 무엇을 선택할지는 고객 획득 비용, 결제 수수료, 고객 지원 비용, 보험 또는 보증 비용, 공급자 마진을 고려해 정해야 합니다.

문제는 수수료율 자체보다 직거래입니다. 직거래 방지는 단순히 전화번호를 숨기는 기능이 아니라 “플랫폼 안에서 거래하는 것이 더 안전하고 유리하다”는 구조를 만드는 일입니다.

필요한 기능과 정책

경고 문구 예시

“안전을 위해 결제 전 연락처와 계좌번호 공유는 제한됩니다. 플랫폼 밖에서 거래하면 환불, 분쟁 중재, 거래 기록 보호를 받을 수 없습니다.”

이 문구의 핵심은 “하지 마세요”가 아니라 “앱 안에서 결제해야 보호받습니다”입니다. 수요자와 공급자가 플랫폼 내부 거래의 이익을 이해해야 직거래 유혹이 줄어듭니다.

5. 분쟁과 정산: 돈을 언제 지급할 것인가

분쟁 중재의 실질적 힘은 정산 구조에서 나옵니다. 결제 금액이 서비스 완료 즉시 공급자에게 전액 지급되면, 문제가 발생했을 때 플랫폼이 환불이나 부분 환불을 집행하기 어렵습니다.

따라서 많은 매칭 플랫폼은 결제 후 일정 기간 금액을 보관하거나 지급을 보류하는 구조를 둡니다. 흔히 에스크로와 유사한 개념으로 설명되지만, 실제로 어떤 방식이 가능한지는 결제대행사 약관과 각 지역의 금융·전자상거래 규제를 확인해야 합니다.

예시 정산 정책

48시간은 예시입니다. 서비스 특성에 따라 24시간, 72시간, 7일 등으로 달라질 수 있습니다. 반려동물 돌봄이나 인테리어처럼 문제가 뒤늦게 발견될 수 있는 서비스는 더 긴 확인 기간이 필요할 수 있습니다.

운영자 화면에 반드시 있어야 할 분쟁 데이터

분쟁을 제대로 처리하려면 운영자가 한 화면에서 사건의 맥락을 볼 수 있어야 합니다.

운영자 결정 사유를 기록하는 것은 매우 중요합니다. “왜 전액 환불했는가”, “왜 부분 환불했는가”, “왜 공급자 책임으로 판단했는가”가 남아야 일관된 운영 기준이 생깁니다.

AI 개발 프롬프트에 넣어야 할 정책 요구사항

AI에게 “예약, 결제, 채팅 기능을 만들어줘”라고만 지시하면 장터의 핵심 규칙이 빠질 가능성이 큽니다. 아래처럼 정책을 명시해야 합니다.

프롬프트 예시

펫시터 매칭 플랫폼을 만든다. 단순 기능 구현이 아니라 아래 운영 정책을 반영해 설계해 달라.

1. 시터 목록은 응답률, 후기 평점, 후기 수, 최근 활동일, 예약 완료율을 종합해 기본 정렬한다.
2. 신규 시터는 후기 부족으로 완전히 밀리지 않도록 별도 신규 시터 영역에 노출한다.
3. 매칭은 보호자가 요청을 올리면 시터가 지원하고, 보호자가 프로필과 후기를 보고 선택하는 방식으로 한다.
4. 결제 전 취소·환불 정책을 화면에 표시하고 동의를 받는다.
5. 결제 전에는 전화번호, 이메일, 계좌번호, 외부 메신저 ID 공유를 제한한다.
6. 채팅에서 연락처 또는 계좌번호로 보이는 패턴이 감지되면 직거래 경고 문구를 보여준다.
7. 서비스 완료 후 48시간 동안 정산을 보류하고, 이 기간에 분쟁이 접수되면 정산을 멈춘다.
8. 운영자는 예약 정보, 결제 상태, 채팅 기록, 증빙 파일, 결정 사유를 한 화면에서 볼 수 있어야 한다.

구현하기 전에 내가 정하지 않은 정책 중에 결정이 필요한 게 있으면 먼저 질문해 달라.

마지막 문장은 중요합니다. AI가 누락된 정책을 질문하도록 만들어야 개발 결과물이 단순한 화면 묶음이 아니라 운영 가능한 플랫폼에 가까워집니다.

데이터 모델로 바꿔 생각하기

정책은 결국 데이터로 남아야 합니다. 아래 항목은 Ruby on Rails 같은 웹 프레임워크에서도 기본 테이블과 상태값으로 구현할 수 있는 구조입니다.

이렇게 설계하면 운영 정책이 코드 곳곳에 흩어지지 않고, 상태와 기록으로 관리됩니다.

오픈 전 체크리스트

• 기본 정렬 기준을 정했는가?
• 신규 공급자에게 노출 기회를 줄 방법이 있는가?
• 자동 매칭, 지원과 선택, 혼합형 중 어떤 방식인지 정했는가?
• 고객 취소와 공급자 취소를 구분했는가?
• 환불 비율과 시점을 결제 전 고지하는가?
• 결제 전 연락처와 계좌번호 공유를 제한하는가?
• 직거래 경고 문구가 처벌보다 보호 이익을 설명하는가?
• 플랫폼 수수료율과 정산 금액 계산식이 명확한가?
• 서비스 완료 후 정산 보류 기간이 있는가?
• 분쟁 접수 시 정산을 자동으로 멈출 수 있는가?
• 운영자가 증빙과 채팅 기록을 한 화면에서 볼 수 있는가?
• 운영자 결정 사유가 기록되는가?
• AI 또는 개발팀에 “정하지 않은 정책은 먼저 질문하라”고 요구했는가?

결론

매칭 플랫폼의 초기 개발에서 가장 위험한 착각은 “기능이 있으면 장터가 돌아간다”는 생각입니다. 실제로 장터를 움직이는 것은 노출, 매칭, 취소, 수수료, 정산, 분쟁 처리 같은 규칙입니다.

AI는 코드를 빠르게 만들 수 있지만, 어떤 행동을 보상하고 어떤 위험을 막을지는 창업자가 정해야 합니다. 오픈 전에 5가지 정책을 문서화하고, 이를 화면·상태값·관리자 기능·고객 안내 문구로 연결해야 수수료가 새지 않고 서비스 품질도 유지됩니다.