B2C 사업은 정말 긴 시간이 필요하다.

최초 업로드 2023-11-18 / 마지막 수정 2024-05-21

개발자 분들 중에 사업에 관심이 생긴 분들에게 도움이 되면 좋겠습니다. 해당 포스트는 제가 1.5년 동안 사업 관련 서적들을 읽고 시작한 3개월 짜리 프로젝트가 실패하는 과정을 담았습니다.

스타트업에는 원래 관심이 크게 없었지만, 산업기능요원을 준비하며 거쳐간 두 회사에서의 경험 때문에 자연스레 사업 쪽에 많은 관심을 갖게 되었다. 군대에서 알고리즘 공부를 한 시기도 있었지만, 그것 보다는 사업쪽으로 여러가지 조사를 한 기간이 더 길었다. My First Million이나 태용 등의 스타트업 채널들을 보고, Bootstrap SaaS를 운영한 사람들의 이나 블로그들을 탐독했었다.

정말 오만하게도, 군대에서 1년 가까이 사업 성공에 관련된 책을 십수권 읽고난 후에 자신감이 과해져 몇 년간 사업을 하면 잘 되겠지라고 쉽게 생각했었다. 하지만, 하나의 플랫폼을 기획부터 배포까지 모두 혼자 해 본 결과, 여기에는 두 가지 큰 맹점이 있었다.

  1. B2C product-market fit은 사막에서 바늘찾기 정도로 어렵다.
  2. 사업의 기존 프로젝트를 폐기하는 것은 정말로 어려운 일이다. (실패를 확정하는 타이밍이 너무나도 어렵다.)

B2C는 검증이 어렵다.

내가 2년 가까이 구글 doc에 모아둔 아이디어들과 기획들은 90%이상이 B2C관련이었다. B2B는 처음 피드백을 지속적으로 줄 사업체를 찾기만 한다면 그 다음부터는 점진적인 발전 사이클을 가져갈 수 있다. 반대로 B2C는 유저 풀 확보부터 큰 문제이기 때문에, 지속적으로 피드백을 받기 위해서는

  • 장기간의 컨텐츠 마케팅 => 시간이 많이 듬.
  • 자기가 가지고 있는 플랫폼에서의 크로스 셀링 => 이미 성공한 사업이 있어야함.
  • 단기간의 SNS 마케팅 => 돈이 많이 듬.

이 세 가지 큰 장벽이 앞을 가로막고 있다. 1번이 무자본으로 할 법 하지만, 1번을 성공 시키기 위해서는 두터운 도메인 지식과 기나긴 컨텐츠 제작 시간을 거쳐야한다. 나는 그 어떠한 분야에도 깊은 도메인 지식이 없었다. 대신 이 말은 배워가면서 글을 계속 쓸 수 있다는 것인데, 이렇게 무리하게 시간을 몇 개월씩 무직으로 투자하며 할 용기가 서지 않았다. 개발은 뒷전으로 하고 오로지 컨텐츠에만 몇 년을 쓰게 될 수도 있는 것이다.


기존 프로젝트의 폐기는 어렵다.

첫 사업 시작 전에는, “그냥 실패하면 검증에 실패한 것이고, 다음 프로젝트로 넘어가면 된다.” 라는 생각으로 접근했다. 하지만 그것은 크나큰 오산이었다. 현실은 이것 보다 복잡했다. 나는 VHUB에 300명 정도의 비로그인 유저와 60명 정도의 로그인 유저들을 대상으로 테스팅했다. 그런데 그들 중 90%이상이 몇 번 탐색 후 이탈했고, 많이 사용한 유저들도 3~4일 사용 후 다시는 방문하지 않았다. 그렇다면 이건 실패인가? 10만명의 유저가 사용해서 100명의 열렬한 유저가 생길 수 있다면 10만명 가입까지 가야하는 것인가? 초기 B2C는 소수의 유저로부터 테스팅을 받기에 어디서부터 어떻게 실패했는지 적은 양의 데이터로 밖에 볼 수가 없고, 그마저도 추측의 추측일 뿐이었다. 실패라는 것을 규명하기가 어려웠다.

  • 어떤 기능이 얼마나 실패인가? 나머지 기능은 포기하고 A기능만 더 살려야하나?
  • 얼마나의 유저수로 테스팅해야 실패인 것을 확정할 수 있는가?
  • 프로젝트의 타이밍이 적기인가? 더 기다리면 되나?
  • 폐기한다면 어떻게 웹사이트를 만든 노고를 저장하여 어떻게 미래에 어필할 것인가?

프로젝트 폐기는 복잡했다. 여기까지가 내가 실패하며 중요하게 느꼈던 부분들이었다. 아래는 실제 과정이 어땠는지 설명되어있다.


VHUB의 시작과 실패

개발은 빨랐다. 하지만 기생하는 플랫폼은 존립이 불가능했다.

내가 첫 사업으로 택한 것은 버튜버 산업이었다. 이유는 두 가지였다.

  1. 사업은 타이밍이 가장 중요하기에, 지금 떠오르는 시장을 선택
  2. 나는 도메인 지식이 없기에, 가장 가까이서 피드백을 받을 수 있는 동생이 항시 챙겨보는 버튜버 분야가 그나마 product-founder fit에 가까워질 수 있다고 판단했다.

동생이 말하길 가장 큰 페인 포인트는 각 버튜버 마다 키고 끄는 시간이 제각각인데, 이를 여러 플랫폼에서 따로 방송하고 있기에 모두 트래킹하기 어렵다는 것이었다. 그리하여 다음과 같은 기능들을 기획하였다.

  1. 본인이 트위치와 유튜브에서 팔로우하는 버튜버들의 온라인 상태를 한 눈에 볼 수 있도록 하기
  2. 버튜버 평점 기능과 리뷰 기능
  3. 버튜버 스케쥴 한 눈에 보는 기능

3번은 버튜버들의 직접적인 참여가 필요했다. 보통 버튜버들은 트위터에 스케쥴을 올리는데, 이걸 모두 파싱하려니 새로운 트위터 API 정책들과 비용이 앞을 막았다. 그래서 1, 2번을 우선적으로 구현하고 유저수가 충당되면 3번을 따라오게하려고 한 것이 첫 계획이었는데, 지금 보면 큰 실수이다. 3번이 마켓의 페인 포인트였는데, 관련 없는 1, 2번을 필두로 자신감있게 구현한 것이 가장 큰 문제 중 하나였다.

그리하여 8주간의 구현을 마쳤지만, 중간중간 문제들이 속속 드러났다. 가장 큰 것은 유튜브 API 였다. 트위치 API는 관대해서 API 요청 Rate Limit이 분당 수백회에 달하지만, 유튜브는 진짜 하루에 몇백 번도 못날리도록 설계해놓았다. 그리고 라이브 스트리밍 PubSubHubbub API가 제대로 사용할 수 없는 상태였다. 그래서 개인적으로 크롤링 서버를 달고 Terms of Service에 반하는 형식으로 구현할 수 밖에 없었다. 이미 너무많이 진행된 프로젝트였기에, 밴을 당해도 어쩔 수 없는 심정으로 자체 크롤링을 시행했다. 물론 유튜브에 거의 부하를 주지 않기 위해 하루에 수백번 이하의 요청밖에 보내지는 않지만, 공식 API를 안쓴 다는 것에서 부터 서비스가 불안해보였다.

유튜브 API문제는 여기서 끝나지 않았다. 유저 가입시 버튜버로 가입하면 본인 채널 인증이 되어야해서 유튜브 인증정보를 가져와야하는데, 이걸 승인받는게 구글 마음이라 승인 요청을 보낸지 3개월이 된 2023년 11월 중순 아직도 아무런 이메일 조차 없어 제대로된 운영이 불가능했다.

VHUB을 각종 커뮤니티 사이트와 관련있는 지인들에게 홍보하며 피드백을 구하고 겨우 60명의 가입자를 만들었지만, 마켓핏의 부재 + 기생 플랫폼의 한계에 부딪혀 프로젝트 폐기 상태이다. 아마 취업을 하게되면 디자인이나 기획만 아카이빙을 하고 서버는 모두 내릴 것 같다.

배운점은 정말로 말도 안되게 많지만, 내가 앞으로 다시 순수 개발자의 길로 돌아가면서 내세울 것들이 줄어들기만 한 것 같아 안타깝다. 과거의 나에게 조언을 할 수 있다면 VHUB에 실패하는 것은 상관 없지만, 개발은 오픈소스화 시켜서 커리어적으로 성장을 도모하라고 말해주고 싶다(혹은 적어도 오픈소스라고 생각하면서 개발하면 퀄리티가 높아지고 단기적으로도 코드 유지보수가 편리할 것이다.). 오픈소스로 안하고 빠른 MVP 배포에 온힘을 쏟으니 포폴에 코드베이스를 추가하기도 어려운 상태이다. (입사 포폴에 넣기에는 리팩토링을 거의 2주 이상 해야될 것 같은 수준이다.)


마치며

VHUB을 만들며 배운 것들을 추가적으로 정리해보겠다.

  1. 이미 경쟁업체가 있는데도 product-market fit이 생각보다 미약할 수 있다.

  2. 프로젝트 폐기를 어떻게 할지 처음부터 계획해야한다. (아카이빙 할 수 있는 수단을 처음부터 만들어라.)

  3. 프로젝트 코드를 쓸 때 오픈소스로 쓴다고 생각하고 예쁘게 개발해야된다. Scaling툴/유료 서비스들을 쓰되, 개발적으로도 깊이 있는 진화를 거듭해야한다. 툴 사용으로 아낀 시간을 개발 공부하는 시간에 써야한다. 그렇지 않으면 인생의 한 페이지가 통으로 날아갈 수 있다.

  4. 빠르게 개발한다고 리팩토링을 게을리하면 오히려 단기간 개발인데도 프로젝트 관리가 어려워질 수 있다. VHUB의 경우 폼의 종류가 조금씩 달라서 복붙하다보니 나중에 리팩토링할 부분이 산더미처럼 쌓였다.

  5. 쉽게 피벗할 수 있을 것이라 생각하지 말라. 피벗의 방향을 정하는 것이 폐기보다 더 어려운 주제이다.

  6. 다른 플랫폼에 기생하는 플랫폼일 경우, 너무 쉽게 사업이 빼앗기거나 본 플랫폼의 주인이 마음대로 서비스 정지를 요할 수 있다. 수 많은 예시중 일례로 Abi Noda의 Pull Reminder가 그렇게 사라졌다. 그렇기에 오리지널한 SaaS가 유리하다.

  7. 글로벌로 할지 로컬로할지 하나만 정해서 시작하는 것이 유리하다고 느꼈다. 모두를 챙기려다보니 처음부터 너무 많은 일이 부과되었다.

  8. 만약 B2C 프로젝트를 다시한다면, 안정적인 사이드 수입원이 있는 상태에서 컨텐츠 마케팅을 중점적으로 시도해 볼 것 같다.

  9. 도메인 지식이 있다면 B2B로 시도하는 것이 안정적일 것이라고 생각한다. Rob Walling의 Tiny Seed등 온라인에는 B2B 자료가 양과 질이 좋다.

앞서 언급했던 주요 핵심들을 요약하자면, B2C가 긴 시간이 필요한 이유는 무자본으로 트래픽을 만드는 유일한 방법이 컨텐츠 마케팅에 있고, market fit을 찾기까지 시간이 오래걸리기 때문이다.

B2C 사업은 정말 긴 시간이 필요하다.

최초 업로드 2023-11-18 / 마지막 수정 2024-05-21

개발자 분들 중에 사업에 관심이 생긴 분들에게 도움이 되면 좋겠습니다. 해당 포스트는 제가 1.5년 동안 사업 관련 서적들을 읽고 시작한 3개월 짜리 프로젝트가 실패하는 과정을 담았습니다.

스타트업에는 원래 관심이 크게 없었지만, 산업기능요원을 준비하며 거쳐간 두 회사에서의 경험 때문에 자연스레 사업 쪽에 많은 관심을 갖게 되었다. 군대에서 알고리즘 공부를 한 시기도 있었지만, 그것 보다는 사업쪽으로 여러가지 조사를 한 기간이 더 길었다. My First Million이나 태용 등의 스타트업 채널들을 보고, Bootstrap SaaS를 운영한 사람들의 이나 블로그들을 탐독했었다.

정말 오만하게도, 군대에서 1년 가까이 사업 성공에 관련된 책을 십수권 읽고난 후에 자신감이 과해져 몇 년간 사업을 하면 잘 되겠지라고 쉽게 생각했었다. 하지만, 하나의 플랫폼을 기획부터 배포까지 모두 혼자 해 본 결과, 여기에는 두 가지 큰 맹점이 있었다.

  1. B2C product-market fit은 사막에서 바늘찾기 정도로 어렵다.
  2. 사업의 기존 프로젝트를 폐기하는 것은 정말로 어려운 일이다. (실패를 확정하는 타이밍이 너무나도 어렵다.)

B2C는 검증이 어렵다.

내가 2년 가까이 구글 doc에 모아둔 아이디어들과 기획들은 90%이상이 B2C관련이었다. B2B는 처음 피드백을 지속적으로 줄 사업체를 찾기만 한다면 그 다음부터는 점진적인 발전 사이클을 가져갈 수 있다. 반대로 B2C는 유저 풀 확보부터 큰 문제이기 때문에, 지속적으로 피드백을 받기 위해서는

  • 장기간의 컨텐츠 마케팅 => 시간이 많이 듬.
  • 자기가 가지고 있는 플랫폼에서의 크로스 셀링 => 이미 성공한 사업이 있어야함.
  • 단기간의 SNS 마케팅 => 돈이 많이 듬.

이 세 가지 큰 장벽이 앞을 가로막고 있다. 1번이 무자본으로 할 법 하지만, 1번을 성공 시키기 위해서는 두터운 도메인 지식과 기나긴 컨텐츠 제작 시간을 거쳐야한다. 나는 그 어떠한 분야에도 깊은 도메인 지식이 없었다. 대신 이 말은 배워가면서 글을 계속 쓸 수 있다는 것인데, 이렇게 무리하게 시간을 몇 개월씩 무직으로 투자하며 할 용기가 서지 않았다. 개발은 뒷전으로 하고 오로지 컨텐츠에만 몇 년을 쓰게 될 수도 있는 것이다.


기존 프로젝트의 폐기는 어렵다.

첫 사업 시작 전에는, “그냥 실패하면 검증에 실패한 것이고, 다음 프로젝트로 넘어가면 된다.” 라는 생각으로 접근했다. 하지만 그것은 크나큰 오산이었다. 현실은 이것 보다 복잡했다. 나는 VHUB에 300명 정도의 비로그인 유저와 60명 정도의 로그인 유저들을 대상으로 테스팅했다. 그런데 그들 중 90%이상이 몇 번 탐색 후 이탈했고, 많이 사용한 유저들도 3~4일 사용 후 다시는 방문하지 않았다. 그렇다면 이건 실패인가? 10만명의 유저가 사용해서 100명의 열렬한 유저가 생길 수 있다면 10만명 가입까지 가야하는 것인가? 초기 B2C는 소수의 유저로부터 테스팅을 받기에 어디서부터 어떻게 실패했는지 적은 양의 데이터로 밖에 볼 수가 없고, 그마저도 추측의 추측일 뿐이었다. 실패라는 것을 규명하기가 어려웠다.

  • 어떤 기능이 얼마나 실패인가? 나머지 기능은 포기하고 A기능만 더 살려야하나?
  • 얼마나의 유저수로 테스팅해야 실패인 것을 확정할 수 있는가?
  • 프로젝트의 타이밍이 적기인가? 더 기다리면 되나?
  • 폐기한다면 어떻게 웹사이트를 만든 노고를 저장하여 어떻게 미래에 어필할 것인가?

프로젝트 폐기는 복잡했다. 여기까지가 내가 실패하며 중요하게 느꼈던 부분들이었다. 아래는 실제 과정이 어땠는지 설명되어있다.


VHUB의 시작과 실패

개발은 빨랐다. 하지만 기생하는 플랫폼은 존립이 불가능했다.

내가 첫 사업으로 택한 것은 버튜버 산업이었다. 이유는 두 가지였다.

  1. 사업은 타이밍이 가장 중요하기에, 지금 떠오르는 시장을 선택
  2. 나는 도메인 지식이 없기에, 가장 가까이서 피드백을 받을 수 있는 동생이 항시 챙겨보는 버튜버 분야가 그나마 product-founder fit에 가까워질 수 있다고 판단했다.

동생이 말하길 가장 큰 페인 포인트는 각 버튜버 마다 키고 끄는 시간이 제각각인데, 이를 여러 플랫폼에서 따로 방송하고 있기에 모두 트래킹하기 어렵다는 것이었다. 그리하여 다음과 같은 기능들을 기획하였다.

  1. 본인이 트위치와 유튜브에서 팔로우하는 버튜버들의 온라인 상태를 한 눈에 볼 수 있도록 하기
  2. 버튜버 평점 기능과 리뷰 기능
  3. 버튜버 스케쥴 한 눈에 보는 기능

3번은 버튜버들의 직접적인 참여가 필요했다. 보통 버튜버들은 트위터에 스케쥴을 올리는데, 이걸 모두 파싱하려니 새로운 트위터 API 정책들과 비용이 앞을 막았다. 그래서 1, 2번을 우선적으로 구현하고 유저수가 충당되면 3번을 따라오게하려고 한 것이 첫 계획이었는데, 지금 보면 큰 실수이다. 3번이 마켓의 페인 포인트였는데, 관련 없는 1, 2번을 필두로 자신감있게 구현한 것이 가장 큰 문제 중 하나였다.

그리하여 8주간의 구현을 마쳤지만, 중간중간 문제들이 속속 드러났다. 가장 큰 것은 유튜브 API 였다. 트위치 API는 관대해서 API 요청 Rate Limit이 분당 수백회에 달하지만, 유튜브는 진짜 하루에 몇백 번도 못날리도록 설계해놓았다. 그리고 라이브 스트리밍 PubSubHubbub API가 제대로 사용할 수 없는 상태였다. 그래서 개인적으로 크롤링 서버를 달고 Terms of Service에 반하는 형식으로 구현할 수 밖에 없었다. 이미 너무많이 진행된 프로젝트였기에, 밴을 당해도 어쩔 수 없는 심정으로 자체 크롤링을 시행했다. 물론 유튜브에 거의 부하를 주지 않기 위해 하루에 수백번 이하의 요청밖에 보내지는 않지만, 공식 API를 안쓴 다는 것에서 부터 서비스가 불안해보였다.

유튜브 API문제는 여기서 끝나지 않았다. 유저 가입시 버튜버로 가입하면 본인 채널 인증이 되어야해서 유튜브 인증정보를 가져와야하는데, 이걸 승인받는게 구글 마음이라 승인 요청을 보낸지 3개월이 된 2023년 11월 중순 아직도 아무런 이메일 조차 없어 제대로된 운영이 불가능했다.

VHUB을 각종 커뮤니티 사이트와 관련있는 지인들에게 홍보하며 피드백을 구하고 겨우 60명의 가입자를 만들었지만, 마켓핏의 부재 + 기생 플랫폼의 한계에 부딪혀 프로젝트 폐기 상태이다. 아마 취업을 하게되면 디자인이나 기획만 아카이빙을 하고 서버는 모두 내릴 것 같다.

배운점은 정말로 말도 안되게 많지만, 내가 앞으로 다시 순수 개발자의 길로 돌아가면서 내세울 것들이 줄어들기만 한 것 같아 안타깝다. 과거의 나에게 조언을 할 수 있다면 VHUB에 실패하는 것은 상관 없지만, 개발은 오픈소스화 시켜서 커리어적으로 성장을 도모하라고 말해주고 싶다(혹은 적어도 오픈소스라고 생각하면서 개발하면 퀄리티가 높아지고 단기적으로도 코드 유지보수가 편리할 것이다.). 오픈소스로 안하고 빠른 MVP 배포에 온힘을 쏟으니 포폴에 코드베이스를 추가하기도 어려운 상태이다. (입사 포폴에 넣기에는 리팩토링을 거의 2주 이상 해야될 것 같은 수준이다.)


마치며

VHUB을 만들며 배운 것들을 추가적으로 정리해보겠다.

  1. 이미 경쟁업체가 있는데도 product-market fit이 생각보다 미약할 수 있다.

  2. 프로젝트 폐기를 어떻게 할지 처음부터 계획해야한다. (아카이빙 할 수 있는 수단을 처음부터 만들어라.)

  3. 프로젝트 코드를 쓸 때 오픈소스로 쓴다고 생각하고 예쁘게 개발해야된다. Scaling툴/유료 서비스들을 쓰되, 개발적으로도 깊이 있는 진화를 거듭해야한다. 툴 사용으로 아낀 시간을 개발 공부하는 시간에 써야한다. 그렇지 않으면 인생의 한 페이지가 통으로 날아갈 수 있다.

  4. 빠르게 개발한다고 리팩토링을 게을리하면 오히려 단기간 개발인데도 프로젝트 관리가 어려워질 수 있다. VHUB의 경우 폼의 종류가 조금씩 달라서 복붙하다보니 나중에 리팩토링할 부분이 산더미처럼 쌓였다.

  5. 쉽게 피벗할 수 있을 것이라 생각하지 말라. 피벗의 방향을 정하는 것이 폐기보다 더 어려운 주제이다.

  6. 다른 플랫폼에 기생하는 플랫폼일 경우, 너무 쉽게 사업이 빼앗기거나 본 플랫폼의 주인이 마음대로 서비스 정지를 요할 수 있다. 수 많은 예시중 일례로 Abi Noda의 Pull Reminder가 그렇게 사라졌다. 그렇기에 오리지널한 SaaS가 유리하다.

  7. 글로벌로 할지 로컬로할지 하나만 정해서 시작하는 것이 유리하다고 느꼈다. 모두를 챙기려다보니 처음부터 너무 많은 일이 부과되었다.

  8. 만약 B2C 프로젝트를 다시한다면, 안정적인 사이드 수입원이 있는 상태에서 컨텐츠 마케팅을 중점적으로 시도해 볼 것 같다.

  9. 도메인 지식이 있다면 B2B로 시도하는 것이 안정적일 것이라고 생각한다. Rob Walling의 Tiny Seed등 온라인에는 B2B 자료가 양과 질이 좋다.

앞서 언급했던 주요 핵심들을 요약하자면, B2C가 긴 시간이 필요한 이유는 무자본으로 트래픽을 만드는 유일한 방법이 컨텐츠 마케팅에 있고, market fit을 찾기까지 시간이 오래걸리기 때문이다.

Copyright © 2023 Seho Lee All Rights Reserved.
</>
Latest Commit
d8c114a6-0bf3-5e24-9645-a55f1bd717ac
seho0808
2024-10-01T10:45:01Z