부업 1년 실패기 — 6개 프로젝트에서 배운 5가지

이 글을 1년 동안 미뤘다. 부끄러워서다.

지금 App Store에 라이브로 돌고 있는 GentleDo와 블로그 2개를 만들기 전, 나는 1년 동안 6개의 사이드 프로젝트를 완벽하게 실패했다. 가입자 13명, 유료 결제 0건, 매출 ₩14,000. 그 시기는 새벽 1시까지 코드를 짜고 다음 날 회사에서 졸았던, 나만 아는 1년이다.

오늘은 그 6개의 시체를 꺼낸다. 이 글이 가장 부끄러운 글이 되길 바라며, 다음 시도의 원칙 5가지를 함께 적었다.

6개 프로젝트 — 시작·종료·투입시간·지출

먼저 그대로의 숫자다. 이름은 일부 바꿨지만 시간과 돈은 노트에서 옮겨 적었다.

#	프로젝트	유형	기간	투입 시간	지출	결과
1	TaskFlow	SaaS 할일관리	2024-02 ~ 05	240h	₩88,000	가입 13 · 유료 0
2	ReadStock	영문 책 요약 뉴스레터	2024-06 ~ 08	90h	₩0	구독 47 · 매출 0
3	PromptShop	Notion·프롬프트 묶음	2024-09 ~ 10	60h	₩22,000	판매 2건 ₩14,000
4	DevWeekly KR	한국어 개발자 뉴스레터	2024-11 ~ 12	70h	₩0	구독 88 · 광고 0
5	MoodLog	감정일기 iOS 앱	2025-01 ~ 02	110h	₩110,000	다운 142 · 구독 1
6	InboxZero AI	Gmail 분류 확장	2025-03 ~ 04	50h	₩0	설치 12 · 유료 0
합계			14개월	620h	₩220,000	매출 ₩14,000

시급으로 환산하면 약 ₩22. 2,200원이 아니라 22원이다. 그 1년 동안 가족과의 저녁 식사를 미룬 횟수, 새벽에 깬 아내가 침묵으로 보낸 신호의 횟수는 이 표에 없다.

그런데도 이 표를 다시 보면 그때의 내가 어떤 자세로 앉아 있었는지가 보인다. 끄적이던 노트, 켜진 모니터 두 대, 자정의 커피. 그 자세가 지금의 자세로 이어진 게 사실이라, 이 글은 후회 글이 아니라 정산 글이다.

공통 실패 패턴 5가지

6개를 나란히 펼쳐놓고 1주일 동안 노트에 적었다. 같은 글자가 반복돼서 나왔다.

1. ICP가 너무 넓었다. 6개 중 5개는 "직장인을 위한 ~"으로 시작했다. 직장인은 ICP가 아니라 인구 통계다. TaskFlow는 "직장인 할일관리"였는데, 실제 가입한 13명은 디자이너·번역가·박사과정생으로 직군이 전부 달랐다. 누구의 본업 시간을 구체적으로 줄여주는지 말하지 못했다.

2. 출시일 강박, 검증 없이 빌드. 모든 프로젝트가 "2주 안에 베타"였다. 사용자 5명에게 보여줄 종이 프로토타입 단계 없이 바로 코드부터 짰다. ReadStock은 90시간을 쓴 뒤 첫 구독자가 메일을 열지 않는 걸 보고 "내가 안 읽을 글을 보내고 있었구나"를 깨달았다. 6주 전에 5분 만에 알 수 있었던 사실이다.

3. 가족 시간을 그대로 갈아넣었다. 주 80시간 (본업 50 + 사이드 30). 2024년 봄, 아내가 두 번 신호를 줬다. 한 번은 부드럽게, 두 번째는 단호하게. 나는 두 번 다 "이번 주말까지만"이라고 답했다. 번아웃은 보통 2개월 뒤에 따라왔다.

4. "내가 쓰고 싶은 것" ≠ 돈 내는 것. PromptShop은 내가 쓰던 프롬프트가 정말 좋아서 시작했다. 6주 후 판매 2건, ₩14,000. 좋은 것과 돈을 내는 것은 다른 곡선이다. 내 결핍이 시장의 결핍과 일치하는지 묻지 않았다.

5. 인프라 0, 매번 처음부터. 6개 프로젝트가 6개의 별개 코드베이스였다. 인증, 결제, 배포, 이메일 발송 — 매번 처음부터. 그 사이에서 제품을 만든 시간은 30%도 안 됐다. 나머지 70%는 인프라 재구축이었다.

그 위에서 만든 원칙 5가지

위 5가지를 뒤집어, 지금의 3개 제품(블로그·앱·자동화)에 적용한 원칙이다.

1. 검증 72시간 룰. 새 아이디어가 떠오르면 72시간 안에 5명 인터뷰 또는 랜딩 폼 100조회를 만든다. 못 만들면 그 아이디어를 폐기한다. 손이 못 닿는 사람을 위한 제품은 만들 자격이 없다는 자기 보호 장치다.

2. ICP는 한 문장. "누가 어떤 본업 시간을 몇 분 줄이는가" 한 문장으로 떨어지지 않으면 빌드 금지다. GentleDo는 "에너지 수준을 의식하는 직장인의 태스크 결정 5초 단축"이다. 좁아서 뭐가 좋냐고? 그래야 누가 쓰는지가 보인다.

3. 주 13시간 컷오프. 새벽 1시 컷, 토요일은 가족, 일요일 오전만 작업. 1인 빌더의 하루 — 3개 제품 운영기에 적은 분할 구조의 절반은 6개 시체가 가르쳐준 한계선이다. 80시간으로 만든 것 중 살아남은 게 없었다는 사실은 가볍지 않다.

4. 인프라 공통화 우선. 6개를 다 갈아 엎고 공통 모노레포 + 발행·OG·SNS 자동화에 먼저 6개월을 썼다. 그 인프라 위에서 블로그 2개를 한 코드베이스에서 운영하는 구조가 가능해졌다. 빌드 자체가 빌더의 자산이라는 걸 늦게 배웠다.

5. 역할이 다르면 브랜드를 쪼갠다. 한 브랜드에 6개 프로젝트를 다 묶으려 했던 게 1년의 실수다. 지금은 3-브랜드 전략에 적었듯 GentleLab(앱)·AIGrit(수익)·babipanote(저널)로 역할별로 분리했다. 한 채널의 정책 변동에 셋이 같이 흔들리지 않는다.

지금의 3개는 왜 다른가

위 5원칙을 정직하게 적용한 결과만이 살아남은 셋이다.

• 블로그 2개 — 검증은 첫 글 발행 후 GSC 노출 수치로 7일 안에 확인된다. ICP는 글마다 한 문장으로 정의(예: "AI 부업을 시작하려는 직장인의 첫 도구 결정 30분 단축"). 인프라는 모노레포 + 자동 발행 파이프라인 위에 있다.
• GentleDo — 72시간 안에 손으로 그린 화면을 다섯 명에게 보여주는 단계를 처음으로 거쳤다. 출시 2주 뒤 App Store 1등을 노리지 않는다. 한 달에 다운 30 늘면 충분하다.
• 자동화 스택 — 인프라 자체가 자산이다. OG 이미지·SNS 자산·MDX 발행이 자동이라 글 1편당 발행 시간이 5분이다. 이게 없었다면 블로그 두 개를 같이 굴리는 건 또 6번째 시체가 됐을 거다.

세 개의 공통점은 내가 즐겁게 만든 것이 아니라 내가 들인 시간이 사라지지 않게 설계한 것이다. 6번의 시체가 가르쳐준 가장 큰 차이다.

다음 시도에 나에게 하는 약속

이 5원칙을 지키는 게 영원한 보증이 아니라는 걸 안다. 7번째 시체는 분명히 또 생긴다. 다만 그 시체가 생기는 방식만큼은 지난 1년의 방식이 아니길 바란다.

그래서 새 아이디어가 떠오를 때마다 노트 첫 줄에 적기로 했다.

• ICP를 한 문장으로 못 적으면 시작하지 않는다
• 72시간 검증 통과 못 하면 코드 한 줄도 짜지 않는다
• 주 13시간을 넘기는 주는 다음 주에 빚으로 갚는다
• 새 인프라를 짜는 게 아니라 기존 인프라가 늘어나는 방향이어야 한다
• 한 브랜드에 두 톤을 욱여넣지 않는다 — 결정적이지 않은 결정은 한 번이면 충분하다

이 약속을 지킨 1년 뒤에 다시 회고를 쓰는 게 가장 좋은 보상이라고, 지금은 생각한다.

이 글이 6개의 시체와 비슷한 시체를 가진 누군가에게 그 시체들이 다음 시도의 자산이 될 수 있다는 1초의 여유가 되길 바란다. 부끄러운 표를 적어두면, 언젠가 같은 표를 다시 안 적어도 되는 사람이 된다.