포지셔닝
Weple 은 오늘의 기분과 대화 가능 시간을 먼저 맞춘 사람과 짧고 가볍게 연결되도록 설계한 온라인 소셜 라운지입니다. 만남이 목적이 아니라 연결 자체가 목적 — 같은 무드를 공유하는 사람과 잠깐 시간을 보내는 행위가 라운지 안에서 완결됩니다.
시장과 문제 정의
기존 소셜 서비스는 프로필 관리, 팔로우 관계, 끊임없는 피드 운영처럼 유지 비용이 큰 구조를 전제로 합니다. 그러나 많은 사용자는 깊은 관계보다 “지금 이 순간 잠깐 연결되고 싶다” 는 욕구를 더 자주 가집니다. 데이팅 앱은 너무 무겁고, 익명 채팅은 너무 가볍고 위험합니다.
Weple 은 그 사이 — 대화의 맥락은 충분히 제공하되 관계의 부담은 최소화하는 — 지점을 차지합니다. 체크인과 채팅이 일정 시간 후 자연스럽게 종료되는 임시성 구조가 핵심입니다.
핵심 타깃과 페르소나
- 가벼운 연결을 원하는 사용자 — 깊은 관계보다 짧은 정서적 교류가 필요한 사람
- 현재의 기분에 맞는 대화를 원하는 사용자 — 프로필 / 외모 / 학력 매칭보다 “지금 이 무드에 같이 있을 사람” 을 먼저 찾음
- 소셜 피로도가 높은 사용자 — 공개 피드와 관계 유지 부담을 피하고 싶지만 익명 채팅의 무책임함도 원치 않는 그룹
가치 제안과 차별점
- 무드 우선 매칭 — “어떤 사람” 보다 “어떤 기분 / 어떤 톤의 대화” 가 먼저 노출. 매칭의 1차 키가 인적 정보가 아니라 현재 상태
- 시간 제한 자동 종료 — 체크인과 채팅방이 일정 시간 후 자동 종료. 관계 유지 부담을 시스템 차원에서 제거. “끝나야 한다” 가 아니라 “끝나도 된다” 라는 심리적 안전감
- 응답별 개별 채팅방 — 하나의 체크인에 여러 응답이 와도 1:1 으로 분리된 방에서 대화. 단톡방의 충돌·산만함 회피
- 비공개 체크인 (private flow) — 링크를 가진 사람만 참여 가능한 모드 — 같은 그룹의 친구·동료와의 가벼운 라운지로도 활용
핵심 사용자 흐름
- 프로필 최소 설정: 닉네임 + 기본 선호 정도만. 자기소개 강요 없음
- 체크인 생성: 라운지(분위기 카테고리), 무드, 연결 방식, 대화 가능 시간, 공개 범위를 정해 1-2 줄 게시
- 응답 수신 + 매칭: 다른 사용자가 무드/시간이 맞으면 응답 → 알림
- 개별 대화방: 응답별 1:1 채팅방, 사전 설정한 시간 한도 내 대화
- 자연 종료: 시간 만료 시 방이 자동 닫힘. 원하면 외부 연락처를 교환해 관계 지속, 원치 않으면 자연 소멸
체크인 → 매칭 → 시간 제한 대화 흐름
flowchart TD
User1["사용자 A
체크인 생성
(무드 · 시간 · 라운지)"]
User2["사용자 B
피드에서 발견
응답"]
Match["응답 = 매칭 성립
전용 방 생성"]
Chat["1:1 대화
사전 설정된 시간 한도"]
End["시간 만료
방 자동 종료"]
Keep["원하면 외부 연락처 교환
(시스템 밖에서 관계 지속)"]
Forget["원치 않으면 자연 소멸
(부담 없음)"]
User1 --> Match
User2 --> Match
Match --> Chat
Chat --> End
End --> Keep
End --> Forget임시성이 시스템의 디폴트 — 관계를 지속하지 않는 것 이 자연스러운 결말이라는 사회적 신호.
비즈니스 모델 가설
수익화는 단계적으로 검증할 계획입니다.
- Pro 라운지 (가설) — 체크인 가용 시간 / 응답 우선순위 / 비공개 라운지 무제한 운영 등을 묶은 유료 티어
- 그룹 / 기업 라운지 — 회사·동아리·커뮤니티가 자기 멤버 전용 비공개 라운지를 임대해 사내 캐주얼 소셜로 활용
- 이벤트 연계 — 오프라인 이벤트(밋업·공연·콘퍼런스) 와 연동된 한시적 라운지. 같은 자리에 있는 사람과의 연결을 라운지로 유도
시스템 아키텍처 (기획 결정을 시스템으로)
기획적 결정 두 가지가 시스템 구조를 결정.
1. “임시성은 시스템이 보장해야 한다.” → 체크인 / 채팅방 / 응답 모두 만료 시간이 메타데이터로 박혀 있고, Firestore TTL + 클라이언트 필터로 만료 후 즉시 비노출. 운영자 개입 없이 라운지가 항상 “지금 살아 있는 대화” 만 보임.
2. “가벼운 연결은 인증·관리 비용도 가벼워야 한다.” → 워크스페이스 표준이 자체 백엔드(Hono + MySQL) 지만, weple 은 Firebase 를 그대로 사용 (Auth + Firestore + Storage). 실시간 채팅·만료 처리·인증을 한 플랫폼으로 묶어 운영 비용을 낮춤. 단일 운영자가 다른 8개 서비스와 분리된 라이프사이클을 짧게 가져갈 수 있는 선택.
flowchart LR
Web["Vite + React 19
web app"]
Auth["Firebase Auth
(Google sign-in)"]
FS[("Firestore
users · checkins
rooms · messages")]
Storage["Firebase Storage
(avatars 등)"]
CDN["CloudFront → S3
weple.com/web"]
Web --> Auth
Web --> FS
Web --> Storage
CDN --> Web워크스페이스 다른 서비스의 공용 Hono API 와 분리. api.weple.com/v1/* 는 향후 확장용으로 health stub 만 운영.
기술 결정과 트레이드오프
- Frontend: Vite + React 19 + TypeScript. 다른 서비스와 동일한 빌드 스택 유지로 도구 학습 비용 공유
- Backend / Realtime: Firebase Auth + Firestore + Storage (예외). 실시간 채팅·소셜 그래프·만료 TTL 을 한 플랫폼으로 묶어 운영 단순화. 다른 8개 서비스가 공용 Hono 코어를 쓰는 것과 의도적으로 다른 선택 — “임시성 + 실시간” 워크로드는 Firebase 의 강점이 명확
- 호스팅: 빌드 산출물은 워크스페이스 표준대로 S3(
weple.oos.kr/web/) + CloudFront. 서비스 일관성 유지 - 포기한 것: 자체 채팅 인프라 구축 (Firebase 가 충분히 빠르고 저렴), 영구 관계망 (지속 그래프는 다른 SNS 가 잘 함 — 우린 임시성에 집중), 추천 알고리즘 (체크인 수가 적은 초기엔 단순 시간순/무드 필터가 더 정직)
운영 자동화
- 만료 자동 정리 — 만료된 체크인 / 닫힌 채팅방의 메시지는 일정 보관 기간 후 자동 삭제. Firestore 보관 비용 + 사용자 프라이버시 동시 관리
- OG 자동 생성 — 라운지 단위 공유 시 무드 컬러 + 라운지명을 합성한 정적 OG 미리 생성
- 빌드 가드 — tsc + theme-lint 로 토큰 외 컬러 / 타이포 사용 차단. 신규 컴포넌트가 자동으로 디자인 일관성 유지
현재 상태와 운영 신호
- 상태: 운영 중. 체크인 / 매칭 / 시간 제한 대화 / 비공개 라운지 작동
- 시작: 2026-03 (Vite + React + Firebase 로 첫 출시)
- 인프라: Firebase (Auth + Firestore + Storage) + S3 (
weple.oos.kr/web/) + CloudFront - 검증 신호: 단발 체크인이 아니라 같은 사용자의 재방문 패턴 형성 모니터링 중. 평균 대화 지속 시간 / 만료 후 외부 연락처 교환률 추적
회고와 다음 가설
- 잘 작동한 것: 임시성을 시스템 디폴트로 박은 결정 — 사용자가 “관계를 끝내야 한다” 는 죄책감을 느끼지 않음. 무드 우선 매칭이 데이팅 앱과 명확히 다른 톤을 만듦
- 다시 한다면: 초기에 너무 많은 라운지 카테고리를 열어둔 것은 사용자에게 “어디 들어가야 할지 모름” 의 마찰. 3-5 개로 좁혀 시작하고 사용 패턴 보고 확장하는 것이 더 자연스러웠을 것
- 다음 가설: (1) Pro 라운지 (시간 / 응답 우선순위), (2) 그룹·기업 비공개 라운지 임대, (3) 오프라인 이벤트 연계 한시적 라운지, (4) 무드 임베딩 기반 추천 (체크인 누적 후)
비슷한 결의 작업 의뢰
Weple 을 단독으로 기획·구현·운영하면서 만들어낸 핵심 역량은 다른 도메인에도 적용 가능합니다.
- 임시성·종료가 디폴트인 소셜 / 협업 제품 — 단톡방·이벤트 라운지·임시 협업 공간 등 “관계가 끝나는 것이 자연스러운” 도메인
- Firebase 기반 실시간 채팅·매칭 시스템 — Auth + Firestore TTL + Storage 를 묶어 1인 운영 가능한 실시간 소셜 백엔드 설계
- 무드 / 컨텍스트 우선 매칭 UX — 인적 정보(프로필·사진) 보다 현재 상태(기분·시간·의도) 가 1차 키인 매칭 흐름 설계
- 다중 서비스 운영 환경에서 예외 스택 결정 — 표준 스택을 가지면서도 특정 워크로드(실시간 채팅)에만 다른 플랫폼을 정당하게 채택하는 의사결정
- 저운영 비용으로 빠르게 검증하는 소셜 MVP — 인프라 구축에 시간을 쓰지 않고 가설 검증에 집중하는 launch-fast 패턴
기획부터 시스템 구축, 운영 자동화까지 한 사람이 끝까지 들고 가는 형태의 작업을 선호합니다. 의뢰는 /work-with-me 또는 /contact 로 연락주세요.