[Froppy 개발기 8편] 피벗 — 1년간 만든 서비스를 접는 결정
3시간 전
▣Froppy1개 기록▲ 목록 접기
피벗 — 1년간 만든 서비스를 접는 결정
"좋은 기술로 만든 제품이 꼭 팔리는 건 아니다."
Froppy는 내가 처음으로 기획부터 배포까지 혼자 완성한 풀스택 서비스다.
https://froppy.kr -> 아직 서비스 중이지만 ㅠㅜ
Flutter로 모바일과 웹을 동시에 만들고, NestJS 백엔드를 Railway에 배포했으며,
Supabase와 Cloudflare로 인프라를 구성했다.
실시간 채팅, 소셜 로그인 3종 세트, 결제 시스템, 영상 스트리밍까지.
기술적으로는 그 어느 때보다 많이 배웠다.
그리고 나는 이 서비스를 접기로 했다.
Froppy가 무엇이었나
비인기종목 스포츠 선수를 위한 후원 플랫폼.
펜싱 선수가 훈련비가 없어 아르바이트를 하고,
클라이밍 선수가 장비 하나 사기 위해 SNS로 도움을 요청하는 현실을 보면서
"이들을 연결해줄 플랫폼이 있으면 어떨까"에서 시작했다.
팬이 선수를 직접 후원하고, 선수는 훈련 과정을 콘텐츠로 공유하는
양면시장(Two-sided Market) 구조의 서비스였다.
벽은 생각보다 일찍 나타났다
1. 양면시장의 닭과 달걀 문제
양면시장의 고전적인 문제다.
선수(공급자)가 없으면 후원자(사용자)가 오지 않는다.
후원자가 없으면 선수가 올 이유가 없다.
처음에는 "선수를 먼저 모으자"는 전략을 세웠다.
그런데 선수들에게 연락을 취하면서 생각지 못한 반응이 돌아왔다.
2. 공급자(선수)의 거부감
인터뷰를 진행하면서 가장 자주 들은 말이 있다.
"솔직히 후원을 대놓고 공개하는 건 좀 부담스러워요.
저도 인스타랑 유튜브 하고 있거든요. 거기서도 어느 정도 팬분들이랑 소통하고 있어서
굳이 새로운 플랫폼으로 이동할 이유를 모르겠어요."
이 짧은 문장에 Froppy의 문제가 전부 담겨 있었다.
첫 번째 — "후원을 대놓고 공개하는 건 부담스럽다"
비인기종목이기 때문에 생기는 역설이다.
종목 자체가 소수의 팬을 가진 만큼, 공개적으로 돈을 받는 행위가
오히려 부담감과 오해를 불러일으킬 수 있다고 느끼는 것이다.
내가 설계한 "투명하고 자랑스러운 후원" 구조가
당사자들에게는 원하지 않는 노출이었다.
두 번째 — "굳이 새로운 플랫폼으로 이동할 이유를 모르겠다"
이미 인스타그램, 유튜브, X(트위터)로 팬과 소통하고 있다.
팔로워도 있고, 콘텐츠도 올리고, 심지어 링크 하나로 후원도 받는다.
Froppy가 제공하는 기능 대부분이 기존 플랫폼에서 이미 해결되고 있었고,
비교할 수 없는 규모의 사용자 기반을 가진 플랫폼을 이길 직접적인 유인 효과가 없었다.
3. 기존 SNS와의 차별화 부재
Froppy가 제공할 수 있는 것들을 정리해보면:
| 기능 | Froppy | 인스타그램 | 유튜브 | X (트위터) |
|---|---|---|---|---|
| 콘텐츠 공유 | ✔ | ✔ | ✔ | ✔ |
| 팔로워 소통 | ✔ | ✔ | ✔ | ✔ |
| 후원/결제 | ✔ | △(링크인바이오) | ✔(멤버십) | ✔(팁) |
| 기존 팬층 | 0 | 수백만 | 수백만 | 수백만 |
스타트업이 이미 생태계가 형성된 플랫폼과 정면 경쟁하는 건
새 SNS를 만드는 것과 다를 바 없었다.
4. PG사 계약의 현실 — 가장 높았던 벽
결제 시스템까지 완성했을 때쯤이었다.
기술적으로는 가장 준비가 잘 된 순간이었는데,
가장 비기술적인 벽을 만났다.
KG 이니시스 — 복수 반려
KG 이니시스에 여러 차례 심사를 신청했다.
매번 반려됐다. 사유는 대동소이했다.
- 서비스 유형 불명확 (기부인지, 결제인지, 콘텐츠 구독인지)
- 환불 정책 및 분쟁 처리 기준 미비
- 선수(공급자) 신원 인증 절차 부재
- 수익 구조와 자금 흐름 증빙 불충분
반려를 받을 때마다 서류를 보완하고 재신청하는 과정을 반복했다.
그러다 최종 심사를 앞두고 피벗을 결정했다.
더 보완해봤자 근본적인 문제가 해결되지 않는다는 걸 알았기 때문이다.
NHN — "후원" 사유 최종 반려
NHN KCP도 시도했다. 결과는 더 명확했다.
반려 사유: 후원 플랫폼은 취급 불가.
서류나 절차의 문제가 아니었다.
"후원"이라는 비즈니스 모델 자체가 NHN의 취급 가능 카테고리에 해당하지 않았다.
PG사 입장에서 후원/기부 플랫폼은 고위험 카테고리다.
돈의 목적과 사용처가 불분명하고, 환불·분쟁 발생 시 책임 소재가 복잡하기 때문이다.
실제로 크라우드펀딩, 기부 플랫폼들이 별도의 전자금융업 등록이나 법인 설립 경로를
밟는 이유가 바로 여기에 있다.
개인 개발자, 혹은 소규모 팀이 이 요건을 충족하는 건 현실적으로 불가능에 가깝다.
5. 마케팅 진입점이 없었다
선수를 모으려면 어딘가에서 만나야 한다.
- 대한체육회? → 협조 요청 채널이 없음
- 종목별 협회? → 개인 개발자와의 협업에 소극적
- 대회 현장? → 오프라인 영업의 한계
- SNS 다이렉트 메시지? → 반응율이 매우 낮음
공급자를 유인할 소거점(Beachhead Market)을 끝내 찾지 못했다.
처음 공략할 수 있는 좁고 명확한 집단이 없다면,
아무리 좋은 제품도 텅 빈 광장에서 혼자 외치는 것과 다르지 않다.
피벗을 결정한 순간
위의 벽들은 하나씩 쌓인 게 아니었다. 거의 동시에 마주쳤다.
- 인터뷰에서 공급자의 거부감과 유인 부재를 확인했고
- PG사로부터 두 번의 반려 혹은 취급 불가 통보를 받았고
- 마케팅 진입점도 보이지 않았다
그 시점에서 "계속 만들면 뭔가 해결될 것"이라는 기대가 사라졌다.
기술적 완성도를 높이는 것과, 비즈니스가 작동하는 것은 완전히 다른 문제였다.
피벗은 포기가 아니라 현실을 직시하고 방향을 바꾸는 결정이라고 생각한다.
그래서 무엇이 잘못됐는가
기술적 문제가 아니었다.
코드는 동작했고, 배포도 됐고, 결제 시스템도 완성됐다.
문제는 "이 문제를 가진 사람이 충분히 존재하는가", 그리고
"그들이 이 방식으로 해결받기를 원하는가" 였다.
나는 문제를 내가 느끼는 방식으로 정의했고,
해결책도 내가 생각하는 방식으로 만들었다.
정작 당사자들은 이미 나름의 방식으로 살고 있었다.
개발자가 제품을 만들 때 흔히 빠지는 함정
1. 기술 검증과 시장 검증은 다르다
MVP를 배포했다고 해서 시장 검증이 된 게 아니다.
아무도 없는 공간에 아무리 좋은 제품을 올려봐야, 그것은 기술 데모일 뿐이다.
2. 공급자가 없는 양면시장은 설계 이전의 문제다
플랫폼 비즈니스는 공급자 확보 전략이 제품 개발보다 먼저여야 한다.
코드를 짜기 전에 선수 10명을 직접 설득할 수 있어야 했다.
3. 인터뷰는 개발 전에 해야 한다
나는 어느 정도 개발이 완료된 후에 인터뷰를 시작했다.
"만들어놨으니 써봐라"는 접근은 피드백이 아니라 설득이 된다.
진짜 인터뷰는 아무것도 없을 때, 가설만으로 진행해야 한다.
4. 결제/금융이 들어가는 서비스는 PG사 정책을 먼저 확인하라
"후원"이나 "기부" 성격의 결제는 일반 커머스와 심사 기준 자체가 다르다.
KG 이니시스, NHN KCP 모두 해당 카테고리에 엄격하다.
전자금융업 등록이나 크라우드펀딩 관련 법령을 초기에 체크했다면
훨씬 이른 시점에 방향을 바꿀 수 있었을 것이다.
그럼에도 얻은 것들
피벗은 실패가 아니다.
적어도 나는 그렇게 생각한다.
Froppy를 만들면서 나는:
- Flutter로 Web + Mobile 크로스플랫폼 개발을 처음부터 끝까지 경험했다
- NestJS로 15개 이상의 도메인 모듈을 가진 백엔드를 설계했다
- Google / Kakao / Naver OAuth를 모두 직접 연동했다
- Toss Payments + PortOne 결제 시스템을 실제로 붙였다
- Supabase + Cloudflare Stream + R2로 저비용 인프라를 구성했다
- 실시간 WebSocket 채팅을 구현했다
- PG사 심사를 직접 경험하며 결제 비즈니스의 현실을 배웠다
이것들은 다음 프로젝트에서 그대로 쓸 수 있는 자산이다.
마치며
Froppy를 닫으면서 아쉬움이 없다면 거짓말이다.
하지만 1년 동안 코드를 쓰면서 배운 것,
인터뷰하면서 들은 이야기들,
PG사 반려 메일을 받으며 배운 것들은
다음 아이템을 만들 때 분명히 다르게 작동할 것이다.
이 시리즈는 Froppy를 만들면서 겪은 기술적 경험들을 기록하기 위해 쓴다.
피벗을 결정한 지금이야말로, 가장 솔직하게 쓸 수 있는 시점이기 때문이다.
다음 편부터는 기술 이야기다.
이 시리즈는 총 8편으로 구성됩니다.
- [1편] 기획 & 아키텍처 — Flutter + NestJS + Cloudflare를 선택한 이유
- [2편] Flutter로 Web과 Mobile 동시 개발하기
- [3편] NestJS로 스타트업 백엔드 설계하기
- [4편] 소셜 로그인 3종 세트 — Google / Kakao / Naver OAuth 연동 실전
- [5편] 결제 시스템 구축 — Toss Payments & PortOne 이중 연동기
- [6편] Supabase + Cloudflare로 저비용 인프라 구성하기
- [7편] 실시간 채팅 — WebSocket Gateway + Cloudflare R2
- [8편] 피벗 — 1년간 만든 서비스를 접는 결정 ← 현재 글