RootrRootr

// Published 8/14/2026

소개팅앱 기획안 - 다리(가칭)

소개팅 앱 기획안 — 「다리」(가칭)

한 줄 정의 — 친구가 골라주고, 날짜부터 잡는 소개팅 앱.

프로필은 본인이 아니라 주선자가 쓰고, 매칭은 사람이 아니라 약속 슬롯에서 시작한다.

항목내용
문서 상태Draft v0.1
작성일2026-08-14
대상 시장국내 20대 후반~30대 중반 미혼
핵심 가설매칭 정확도가 아니라 만남 전환율이 진짜 병목이다

1. 문제 정의

기존 데이팅 앱의 실패는 "안 맞는 사람을 붙여줘서"가 아니다. 매칭 이후가 없어서다.

1.1 세 개의 구조적 결함

① 자기소개의 인센티브 왜곡

본인이 본인 프로필을 쓰는 순간 그건 이력서가 된다. 과장이 기본값이 되고, 읽는 쪽은 전부 할인해서 읽는다. 결과적으로 프로필의 정보량이 0에 수렴하고, 남는 판단 근거는 사진뿐이다.

② 대화 단계에서의 대량 이탈

매칭 → 대화 → 만남으로 가는 깔때기에서 가장 크게 새는 구간은 대화다. 매칭은 됐지만 "언제 볼까요"를 꺼내는 비용이 높고, 며칠 지나면 자연 소멸한다. 앱 안의 대화가 길어질수록 만남 확률은 오히려 떨어진다.

③ 신뢰의 부재

상대가 실존 인물인지, 미혼인지, 프로필이 사실인지 검증할 방법이 없다. 인증 배지는 신분만 증명할 뿐 사람됨을 증명하지 못한다.

1.2 한국 시장의 특수 맥락

한국에서 실제로 가장 많은 커플을 만들어낸 채널은 앱이 아니라 지인 소개다. 그런데 국내 데이팅 앱은 이 방식을 전부 걷어내고 서구식 스와이프 모델을 그대로 이식했다. 주선자라는 검증 레이어를 버린 것이다.

오프라인 소개팅이 작동하는 이유는 알고리즘이 좋아서가 아니라, 평판을 건 제3자가 중간에 있고 날짜가 먼저 잡히기 때문이다.

이 기획안은 그 두 가지를 그대로 앱으로 옮긴다.


2. 타겟

2.1 1차 타겟 — 주선자 (Supply)

구분내용
프로필25~38세, 친구 무리에서 "발이 넓은 사람" 포지션
상태본인은 연애 중이거나 기혼인 경우도 다수
동기오지랖, 친구에 대한 애정, 성사 시 사회적 인정
기존 행동이미 카톡으로 사진 돌리며 소개팅을 주선하고 있음

핵심 통찰: 주선자는 본인이 만나고 싶어서 가입하는 게 아니다. 이 때문에 데이팅 앱 특유의 가입 심리 장벽(자존심, 인정 욕구)이 없다. 획득 비용이 근본적으로 낮다.

2.2 2차 타겟 — 후보 (Demand)

구분내용
프로필27~35세 미혼
페인 포인트앱은 피곤하고, 소개팅은 주선자에게 부탁하기가 민망함
특징가입은 하지만 능동적으로 탐색하지 않는 층
진입 경로친구의 초대 링크. 자발적 가입이 아님

이 층은 기존 앱들이 절대 못 잡는다. 스스로는 앱을 안 깔기 때문이다. 주선자 모델은 이들을 친구가 대신 끌어온다.


3. 솔루션 개요

두 개의 축이 서로를 보완한다.

[축 1] 주선자 레이어  →  누가 신뢰할 만한가를 해결
[축 2] 슬롯 매칭      →  어떻게 실제로 만나게 할 것인가를 해결

축 1이 없으면 슬롯은 그냥 블라인드 데이트 예약 서비스가 되어 신뢰가 붕괴한다.

축 2가 없으면 주선자 모델은 그냥 프로필 대필 서비스가 되어 기존 앱과 같은 곳에서 새어나간다.

두 축은 선택지가 아니라 한 세트다.


4. 축 1 — 주선자 레이어

4.1 프로필 작성권의 이전

  • 본인은 자기소개를 쓸 수 없다. 사진, 나이, 직업군, 지역 등 사실 정보만 입력한다.
  • 서술형 소개는 주선자만 작성한다.
  • 주선자는 정해진 질문에 답하는 형식으로 작성한다. 자유 서술은 결국 미사여구가 되므로 구조를 강제한다.

주선자 작성 문항 (예시)

  1. 이 친구를 한 문장으로 소개한다면?
  2. 처음 만나면 어떤 인상인데, 알고 보면 어떤 사람인가?
  3. 이 친구랑 어떤 사람이 잘 맞을 것 같은가?
  4. 미리 알고 가면 좋을 점 하나 — 단점 필수 기재
  5. 함께한 가장 웃긴 기억

4번이 핵심이다. 단점을 안 쓰면 프로필이 게시되지 않는다. 이것이 이 앱의 신뢰 장치이자 정체성이다.

4.2 본인의 통제권

주선자가 쓴 프로필은 본인의 승인 후에만 공개된다. 본인은 수정을 요청할 수 있으나 직접 고쳐 쓸 수는 없다. 재작성 요청은 주선자에게 돌아간다.

4.3 주선자 평판 시스템

지표산정 방식
성사율주선 건수 대비 2회차 만남 성사 비율
정확도만남 후 "프로필과 실제가 일치했는가" 평가
활동성최근 90일 주선 건수

평판은 주선자 등급으로 노출된다. 등급이 높은 주선자가 소개한 사람의 프로필이 상단에 배치된다. 즉 주선자는 아무나 마구 소개할 유인이 없다. 자기 평판이 걸려 있다.

부정확한 프로필을 반복 작성한 주선자는 등급 하락 → 노출 감소 → 사실상 퇴출된다. 알고리즘이 아니라 평판 경제로 품질을 관리하는 구조다.

4.4 바이럴 구조

주선자 가입
   → 친구 A 초대 (프로필 작성)
   → 친구 B 초대 (프로필 작성)
   → A·B가 매칭 후 각각 본인 친구를 주선자로 초대
   → 반복

일반 데이팅 앱의 K-factor가 낮은 이유는 "내가 이 앱 쓴다"고 말하기 부끄럽기 때문이다. 반대로 "내가 너 소개시켜주려고"는 말하기 쉽다. 오히려 생색이 난다. 바이럴 계수가 구조적으로 다르다.


5. 축 2 — 슬롯 매칭

5.1 순서의 역전

기존 앱다리
1단계사람 고르기날짜·장소 확정
2단계매칭후보 지원
3단계대화 (수일~수주)주선자 확정
4단계만남 제안 ← 여기서 이탈만남
5단계만남 (드물게)대화 (만난 이후)

슬롯은 "8월 23일(토) 오후 2시, 성수동" 같은 확정된 만남 단위다. 사람이 아니라 슬롯을 먼저 연다.

5.2 슬롯 생성 플로우

  1. 본인이 슬롯을 연다 — "이번 주 토요일 오후, 성수/한남 쪽 가능"
  2. 해당 시간대에 열려 있는 이성 슬롯 중 조건이 맞는 후보들이 매칭 풀에 담긴다
  3. 주선자들이 후보를 검토하고 추천한다 — 여기가 축 1과 축 2가 만나는 지점
  4. 양쪽 본인이 최종 수락하면 슬롯 확정
  5. 확정 시점에 장소가 자동 배정된다 (제휴 카페 예약 포함)

5.3 확정 후 규칙

  • 사전 대화 없음. 확정된 상대와는 만나기 전까지 채팅이 열리지 않는다.
  • 열리는 것은 오직 약속 정보와 상대 프로필뿐이다.
  • 만남 30분 전, 위치 공유 및 안전 확인 기능이 활성화된다.
  • 채팅은 만남 종료 후에 열린다. 후속 연락은 이때부터.

대화를 없애는 것이 아니라, 대화의 순서를 뒤로 미룬다. 앱 안의 대화가 만남을 대체하지 못하게 만드는 것이 목적이다.

5.4 노쇼 방지

장치내용
예약금슬롯 확정 시 소액 예치, 참석하면 전액 매장 결제에 사용
노쇼 페널티미참석 시 예치금 소멸 + 30일 슬롯 개설 제한
주선자 연동노쇼는 주선자 평판에도 반영 — 소개한 사람이 펑크내면 주선자가 손해

마지막 항목이 오프라인 소개팅과 동일한 사회적 압력을 재현한다.


6. 차별점 요약

일반 스와이프 앱결혼정보회사다리
프로필 신뢰낮음 (자기 서술)높음 (서류)높음 (지인 서술 + 단점 공개)
만남 전환율매우 낮음높음높음 (슬롯 선확정)
비용낮음매우 높음중간
진입 장벽낮음높음낮음 (친구 초대)
획득 채널유료 광고유료 광고바이럴

포지셔닝 문장:

"결혼정보회사의 신뢰를, 앱의 가격으로."


7. 수익 모델

7.1 후보 (Demand) — 슬롯 이용권

  • 슬롯 확정 1건당 과금. 매칭이 아니라 확정된 만남에 대해서만 과금한다.
  • 구독이 아닌 건별 과금 → "성사되지 않으면 돈을 안 낸다"는 메시지가 명확하다.
  • 예상 단가: 슬롯 1건 15,000~25,000원 (예치금 포함, 예치금은 매장에서 사용)

7.2 주선자 (Supply) — 리워드

  • 성사 시 포인트 지급. 현금성 리워드는 주선의 동기를 왜곡시키므로 지양한다.
  • 대신 등급, 배지, 누적 성사 기록 등 비금전적 보상 중심.
  • 커플 성사 시 양쪽으로부터 감사 메시지가 주선자에게 전달되는 구조 — 이것이 가장 강력한 리텐션 장치다.

7.3 제휴 매장 (B2B)

  • 슬롯 확정 시 자동 예약 → 매장 입장에서는 비수기 시간대 송객 채널
  • 평일 오후, 주말 이른 시간 등 유휴 슬롯을 앱이 채워준다
  • 수수료 또는 정액 제휴비. 중장기적으로 가장 마진이 좋은 라인

7.4 하지 않을 것

  • ❌ 좋아요 개수 과금 (탐색 피로 유발)
  • ❌ 노출 부스팅 (주선자 평판 시스템의 공정성 훼손)
  • ❌ 무제한 구독 (만남이 아닌 체류를 최적화하게 됨)

8. MVP 범위

8.1 포함 (In Scope)

  • 주선자 초대 및 프로필 대필 (5문항 고정, 단점 필수)
  • 본인 승인 플로우
  • 슬롯 개설 — 날짜/시간대/지역 3개 필드만
  • 주선자 추천 → 양측 수락 → 확정
  • 확정 후 만남 전 채팅 차단, 만남 후 채팅 개방
  • 만남 후 상호 평가 (프로필 일치도 포함)
  • 주선자 등급 v1 (성사율 단일 지표)

8.2 제외 (Out of Scope)

  • 추천 알고리즘 고도화 — MVP는 사람(주선자)이 알고리즘 역할을 한다
  • 제휴 매장 자동 예약 — 초기엔 지역만 제안하고 장소는 당사자가 정함
  • 결제/예치금 — 초기엔 무료 운영하며 노쇼율 데이터부터 확보
  • 영상/음성 기능 일체

8.3 초기 시장 진입 전략

지역을 좁힌다. 전국 서비스로 시작하면 슬롯 밀도가 안 나와 매칭이 성립하지 않는다.

1단계: 서울 성수/한남/연남 3개 상권 + 특정 직군 커뮤니티 1곳

2단계: 서울 전역

3단계: 수도권

양면 시장에서 밀도는 기능보다 중요하다.


9. 핵심 지표

단계지표초기 목표 (가설)
획득주선자 1인당 초대 성공 수1.5명 이상
활성프로필 완성률 (주선자 작성 완료)60%
전환슬롯 개설 → 확정 전환율30%
전환확정 → 실제 만남 (노쇼 반대)85%
성과만남 → 2회차 성사율25%
품질프로필 일치도 평가 4점 이상 비율80%

북극성 지표: 월간 성사된 2회차 만남 수

체류시간, DAU, 메시지 수는 의도적으로 추적하지 않는다. 이 지표들을 보기 시작하면 제품이 잘못된 방향으로 최적화된다.


10. 리스크 및 대응

#리스크심각도대응
1주선자 공급 부족 — 주선자가 없으면 서비스 자체가 성립 안 함치명적초기 시드 주선자 직접 모집·관리. 주선자 커뮤니티 별도 운영
2슬롯 밀도 부족 — 같은 시간대에 상대가 없음치명적지역·요일 극단적으로 좁혀 시작. 슬롯 개설을 특정 요일에 집중
3프로필 대필의 프라이버시 문제 — 당사자 동의 없는 정보 노출높음본인 승인 필수. 승인 전엔 어떤 형태로도 노출 금지
4사전 대화 차단에 대한 거부감 — "모르는 사람을 어떻게 만나나"높음주선자의 존재가 이 불안을 상쇄. 안전 기능 강조
5주선자의 무성의한 대필중간5문항 강제 + 단점 필수 + 일치도 평가의 평판 반영
6노쇼중간예치금(2차) + 주선자 평판 연동
7남녀 성비 불균형높음여성 슬롯 개설 시 우대. 주선자 초대도 성비 목표 기준 관리
8안전 사고치명적공개 장소 한정, 위치 공유, 신고 즉시 차단, 주선자 실명 추적

리스크 1·2는 사실 같은 문제다. 양면 시장의 콜드 스타트. MVP 성패의 90%가 여기서 결정된다.


11. 로드맵

시기마일스톤
M0~M2프로토타입 + 시드 주선자 30명 확보
M3성수/한남 한정 클로즈드 베타 (슬롯 100건 목표)
M4~M5노쇼율·성사율 데이터 확보, 슬롯 밀도 임계점 검증
M6예치금·제휴 매장 도입, 서울 전역 확대
M7~유료화 및 수도권 확대

12. 열린 질문

  1. 주선자와 후보가 동일 인물일 수 있는가? (내 친구를 소개하면서 나도 소개받기) — 바이럴에는 유리하나 역할 혼재로 신뢰가 흐려질 수 있음
  2. 슬롯의 최소 단위를 1:1로 할 것인가, 2:2로 할 것인가? 2:2는 심리적 부담이 낮고 주선자가 직접 동석할 수 있으나 매칭 난이도가 급상승
  3. 주선자가 만남에 동석하는 옵션을 제공할 것인가?
  4. 프로필의 "단점 필수" 원칙이 실제로 유지 가능한가 — 형식적 답변으로 무력화될 위험
  5. 사전 대화 완전 차단이 너무 급진적인가? 확정 후 정해진 질문 3개 교환 정도의 완충 장치를 둘 것인가?

13. 다음 액션

  • 2:2 vs 1:1 슬롯 구조 결정
  • 시드 주선자 인터뷰 10건 — 대필 의향 및 문항 검증
  • 성수 지역 제휴 가능 매장 리스트업
  • 프로필 대필 문항 초안 사용자 테스트
  • 경쟁사(국내 데이팅 앱) 만남 전환율 벤치마크 조사
RootrRootrMade with Rootr