사이드프로젝트 Archives

이것만은 알아두세요

직장인이 본업 외에 시작하는 사이드프로젝트 가운데 6개월 이상 살아남는 비율은 10명 중 1명꼴입니다. 깃허브에 올라온 1만 개 이상 개인 프로젝트를 분석한 자료(GitHub Octoverse, 2023)에서도 마지막 커밋이 30일 이상 끊긴 비율이 전체의 73%로 보고됐습니다. 즉 시작한 사람의 대다수는 "기술이 부족해서"가 아니라 순서가 꼬여서 멈춥니다.

가장 흔한 실패 패턴은 세 가지입니다.

만드는 것부터 시작합니다. 누가 쓸지 검증하기 전에 코드를 짭니다. 3주 뒤 "이걸 누가 쓰지?"라는 회의감에 동력이 죽습니다.
본업 처리 시간을 과소평가합니다. 평일 야근·주말 가족 일정·체력 회복을 다 빼고 나면, 실제로 손을 댈 수 있는 시간은 주 5〜7시간입니다. 그런데 머릿속에선 "주 20시간씩 6개월"이 기본값입니다.
피드백 루프 없이 혼자 6개월을 갑니다. 첫 사용자 5명을 만나는 시점이 늦어질수록 방향 수정 비용은 기하급수로 늘어납니다.

이 글은 위 세 함정을 피하기 위한 순서를 다룹니다. "어떤 기술을 쓸까", "어떤 디자인이 좋을까"가 아니라 무엇을 → 누구에게 → 어떻게 검증하며 → 언제까지 만들지를 정하는 단계별 의사결정 흐름입니다. 직장인 기준 12〜16주 안에 "이걸 계속할지 말지"를 책임 있게 결정하는 데 필요한 최소 절차로 추렸습니다.

이 글에서 다루는 7단계는 다음과 같습니다.

단계	기간	출력물	핵심 판단
1. 문제 선정	1주	문제 후보 3개	내 관심·시간·시장의 교집합
2. 아이디어 검증	2주	인터뷰 5건 + 랜딩페이지	진짜 돈/시간을 쓸 사람이 있나
3. 범위 축소 (MVP 정의)	1주	1줄 가치 제안 + 기능 3개	빼도 죽지 않는 것 다 빼기
4. 기술 스택 결정	3일	스택 문서 + 환경 세팅	익숙 80% / 새 시도 20%
5. MVP 빌드	4〜6주	배포 가능한 첫 버전	2주 스프린트 × 3회
6. 배포·첫 사용자 5명 확보	2주	실사용자 + 사용 로그	칭찬이 아니라 재방문
7. 6주 운영 후 판단	6주	지표 리뷰 + 결정	계속·피벗·중단

총 16〜18주, 본업 외 주 8시간을 가정한 일정입니다. 시간이 더 적다면 단계별 기간을 1.5배로 늘리되, 순서는 절대 건너뛰지 않는 것이 핵심입니다. 만들기부터 시작해 검증을 뒤에 붙이면, 매몰비용 때문에 객관적 판단이 불가능해집니다.

Step 1: 문제 선정 — 관심·시간·시장의 교집합 찾기

사이드프로젝트를 시작하는 첫 일주일에 해야 할 단 하나는 "무엇을 만들지가 아니라, 어떤 문제를 풀지" 정하는 것입니다. 둘은 다릅니다. "노션 같은 협업 툴을 만들고 싶다"는 만들 것이고, "원격 근무팀이 회의록을 검색하지 못해 매주 같은 결론을 반복한다"는 문제입니다.

1-1. 문제 후보를 3개로 좁히는 3원 교집합

다음 세 원이 겹치는 지점에서 후보를 뽑으세요.

관심 (Interest): 6개월간 지치지 않고 이야기할 수 있는 영역
시간 (Time): 본업 도메인과 가까워 학습비용이 작은 영역 (반대로 일과 너무 똑같으면 번아웃 위험)
시장 (Market): 같은 문제로 검색·질문하는 사람이 한 달에 100명 이상은 있는 영역

세 원이 동시에 겹치는 후보를 3개만 뽑습니다. 더 많이 뽑으면 다음 단계 검증이 분산돼 결국 한 개도 끝내지 못합니다. 3개 후보의 형식은 반드시 한 문장으로 적습니다.

"[누가]가 [언제] [어떤 상황]에서 [어떤 일]을 못 해서 [어떤 손해]가 난다."

좋은 예: "1인 개발자가 출시 첫 주 마케팅 채널을 고를 때 어디부터 시작할지 몰라서 첫 사용자 확보까지 평균 6주가 걸린다."

나쁜 예: "개발자를 위한 도구가 필요할 것 같다." (누가·언제·왜·손해가 빠져 검증 불가)

1-2. "내가 아는 사람의 진짜 불만" 우선 원칙

좋은 사이드프로젝트의 80%는 본인이 직접 겪었거나, 가까운 동료의 반복적 불만에서 출발합니다. 모르는 시장의 모르는 문제를 풀려고 하면 인터뷰 단계에서 질문 자체가 표면적이 됩니다. 어떤 산업이든 "10년 묵은 작은 짜증"이 있고, 그 짜증은 검색해도 잘 안 나옵니다. 본업·취미 동아리·가족·이전 직장 동료의 "왜 이게 아직도 이래?"를 메모하세요.

1-3. 첫 주 체크리스트

문제 후보 3개를 한 문장 포맷으로 적었다
각 후보에 대해 내가 직접 겪은 일화 1개씩을 기록했다
후보별 1주일 동안 관련 키워드를 구글 검색해 결과 페이지를 캡처했다
후보 3개를 친한 동료 2명에게 보여주고 "어느 것이 더 와닿냐"고 물었다
가장 많이 끄덕이는 1개를 골라 다음 단계로 넘긴다

Step 2: 아이디어 검증 — 인터뷰 5건 + 랜딩페이지로 사전 수요 확인

검증 단계의 핵심 명제는 단순합니다. "코드를 짜기 전에, 사람을 5명 만나라." Y Combinator가 십 수년간 반복해서 강조한 원칙이고, 한국 스타트업·1인 개발자 인터뷰 사례에서도 동일하게 확인됩니다. 5명을 만나는 데 드는 시간은 길어야 2주, 잘못된 방향으로 6개월을 가는 비용보다 훨씬 쌉니다.

2-1. 인터뷰 대상은 "친구의 친구" 까지만

지인 직접 인터뷰는 편향이 큽니다. 친구는 당신을 응원하느라 "좋다"고 답하기 쉽습니다. 그래서 "친구의 친구" 또는 "동료의 동료", 즉 한 다리 건너 만나는 사람이 가장 좋습니다. 5명 중 최소 3명은 이 범위에서 섭외하세요. 슬랙·디스코드 커뮤니티, 링크드인, 동호회에서 연락을 돌리면 한 주 안에 5명은 모입니다.

2-2. 인터뷰 질문지: "기능이 아니라 행동"을 묻는다

"마지막으로 [그 문제]를 겪은 게 언제였나요?" (구체적 시점)
"그때 어떻게 해결하려고 시도했나요?" (현재 해결책)
"지금까지 그 문제 해결을 위해 쓰는 도구·돈·시간이 얼마인가요?" (대체재 비용)
"그 문제 때문에 가장 손해 본 일이 있다면?" (절박함의 크기)
"비슷한 도구가 있다면 한 달 얼마까지 낼 의향이 있나요?" (지불 의사)

피해야 할 질문: "이런 게 있으면 쓸 거 같으세요?" → 응답자는 거의 다 "네"라고 답합니다. "썼었나요?"가 정답입니다.

2-3. 랜딩페이지로 "0원 사전 수요" 측정

5명 인터뷰와 동시에 랜딩페이지를 띄웁니다. 코드 없이도 Notion·Carrd·Framer·Webflow로 1〜2일이면 만듭니다. 핵심 요소는 다섯 가지뿐입니다.

제목 한 줄: "[누가]를 위한 [어떤 일을 더 빠르게/싸게/정확하게] 도구"
문제 설명 3줄: 인터뷰에서 들은 "10년 묵은 짜증"을 그대로 옮기기
해결 방법 3줄: 어떻게 그 짜증을 줄일지 1줄 가치 제안
신청 폼: 이메일·이름만. 가능하면 "사전 결제" 또는 "유료 베타 의향"까지
출시 일정: "8월 중순 비공개 베타" 같은 약한 약속

페이지를 만들었으면 레딧·트위터·디스코드 같은 작은 커뮤니티에 본인 사연을 곁들여 1번씩 노출합니다. 광고 없이 2주 동안 이메일 20개 이상이 모이면 다음 단계로, 5개 미만이면 후보 2번으로 돌아가서 1단계부터 다시 시작합니다.

2-4. 검증 통과 기준 (Go / No-Go)

다음 셋 중 2개 이상이 만족돼야 다음 단계로 갑니다.

인터뷰 5명 중 3명 이상이 현재 어떤 식으로든 돈·시간을 쓰고 있다
랜딩페이지 이메일 신청 20개 이상 (광고 없이)
"비슷한 도구가 있다면 월 X원까지 낼 수 있다"는 응답의 중앙값이 3,000원 이상

세 조건 중 1개 이하만 만족하면, 진짜로 1단계로 돌아가야 합니다. 아무리 아이디어가 마음에 들어도 사용자 수요 신호가 약하면, 만들지 않는 것이 가장 비싼 학습을 막아주는 결정입니다.

Step 3: 범위 축소 — MVP는 "한 가지 일만" 잘하는 것

검증이 끝났다면 이제 무엇을 만들지 정합니다. 가장 큰 함정은 "이왕 만드는 김에 다 넣자"입니다. 본업과 병행하는 환경에서 기능 5개짜리 첫 버전은 거의 100% 8개월 뒤에 완성되거나 영영 못 끝냅니다.

3-1. 1줄 가치 제안 (One-line Value Prop)

먼저 한 줄로 적습니다. 못 적으면 아직 좁히지 못한 것입니다.

"[누가]가 [어떤 일]을 [어떻게] 더 쉽게/빠르게/싸게 할 수 있게 돕는 도구."

예: "프리랜서 개발자가 견적서를 보낼 때 5분 안에 PDF로 출력할 수 있게 돕는 웹 도구."

3-2. 기능 후보 → 3개만 남기는 "MoSCoW" 압축

후보를 다 적은 다음 다음과 같이 분류합니다.

Must (있어야 가치 제안이 성립): 3〜5개
Should (있으면 좋지만 없어도 됨): 5〜10개
Could (먼 미래): 자유
Won't (이 버전엔 절대 안 함): 자유

여기서 MVP에 넣는 것은 Must 중에서도 가장 단순한 형태로 3개입니다. "회원가입·결제·관리자 페이지"는 거의 항상 첫 버전에선 뺄 수 있습니다. 회원가입 없이 로컬스토리지로 시작해도 됩니다. 결제는 토스 결제 링크 1줄로 대체 가능합니다.

3-3. "2주 안에 못 만들면 빼라" 원칙

각 Must 기능별로 직접 만들었을 때 걸리는 시간을 추정합니다. 단일 기능이 2주를 넘으면 다시 쪼개거나, 외부 서비스로 대체합니다.

검색 → 알골리아·Meilisearch 외부 서비스
인증 → Supabase Auth, Clerk, Firebase
결제 → 토스 결제 링크, Stripe Checkout
이메일 발송 → Resend, SendGrid

직접 구현하면 학습 가치는 있지만, "출시"라는 1차 목표를 죽입니다. 사이드프로젝트에서 직접 만들 영역과 외주 줄 영역의 비율은 30:70 정도가 적절합니다.

3-4. 범위 동결 (Scope Freeze)

기능 3개를 정한 그날, "이번 시즌 추가 기능 절대 안 한다" 라고 종이에 적어 모니터에 붙입니다. 빌드 중 새 아이디어가 떠오르면 별도 노트에 "Backlog" 폴더에 적기만 합니다. 추가하지 않습니다. 사이드프로젝트 사망의 1차 원인은 새 아이디어를 못 참는 것입니다.

Step 4: 기술 스택 결정 — 익숙 80% / 새 시도 20% 룰

사이드프로젝트는 새 기술을 배우기에 좋은 무대이긴 합니다. 그러나 "전부 처음 보는 스택"으로 가면 출시 자체가 늦어집니다. 직장에서 React를 쓰는 사람이 Solid·Svelte·Vue·Astro를 동시에 새로 시도하면 첫 화면 띄우는 데 2주가 갑니다.

4-1. 80:20 비율

전체 스택 중 80%는 본업에서 익숙한 것, 20%만 새로 시도하는 것으로 잡습니다.

영역	권장 (직장에서 React/TS 기준)
프론트엔드 프레임워크	익숙: Next.js / Astro
UI 라이브러리	익숙: Tailwind + shadcn
백엔드/DB	익숙: Supabase, Firebase, Prisma + PostgreSQL
배포	익숙: Vercel, Netlify, Cloudflare Pages
새 시도 (20%)	예: Bun, Hono, Drizzle, tRPC 중 1개

4-2. 첫 환경 세팅은 1일 안에 끝낸다

다음 체크리스트가 하루 안에 끝나야 본 작업으로 들어갈 자격이 있습니다.

git 저장소 생성, README에 한 줄 가치 제안 적기
도메인 결정 (사이드프로젝트 도메인은 .com이 아니라 .so, .app, .dev도 충분)
배포 파이프라인: 푸시 → 자동 배포 (Vercel/Netlify면 5분 안에 됨)
환경변수 1세트 (개발용 키만)
모니터링: Vercel Analytics, Plausible, Umami 중 하나

1일을 넘기면 스택 결정이 잘못된 것입니다. 익숙한 쪽으로 돌리세요.

4-3. 안티 패턴: "유튜브 튜토리얼 따라가기"

새 스택을 배우려고 첫 사이드프로젝트에서 튜토리얼을 따라가면, 튜토리얼 끝나는 지점에서 멈춥니다. 그 시점에 만든 것이 곧 출시 가능한 결과물이 되지 않기 때문입니다. 새 기술 학습은 별도의 "학습 프로젝트"로 분리하고, 본 사이드프로젝트는 익숙한 도구로 끌고 가세요. 학습 효과가 약해 보여도, "출시 경험" 자체가 다음 사이드프로젝트의 가장 큰 자산이 됩니다.

Step 5: MVP 빌드 — 2주 스프린트 × 3회

본격 빌드는 2주 단위 스프린트로 3회를 권장합니다. 총 6주, 본업 외 주 8시간 기준 약 48시간을 투입합니다. 한 번에 6주를 통으로 잡으면 일정이 무너집니다. 2주 단위로 끊으면 끝나는 시점마다 "남은 기능을 다시 볼" 자연스러운 기회가 옵니다.

5-1. 스프린트 구조

Sprint 1 (1〜2주): 핵심 기능 1번. 회원가입·랜딩·이메일 발송 같은 부수 기능은 0. "1 기능 + 데모 페이지"가 끝.
Sprint 2 (3〜4주): 핵심 기능 2번 + Sprint 1 리팩토링. 이 시점에 첫 외부 사용자 1〜2명에게 비공개 시연.
Sprint 3 (5〜6주): 핵심 기능 3번 + 배포 준비 (도메인 연결, 기본 SEO, 분석 도구).

각 스프린트 끝에 30분 회고를 적습니다. "이번 2주에 한 일", "예상보다 오래 걸린 일", "다음 2주에 줄일 일". 종이 한 장이면 됩니다.

5-2. 시간 확보 루틴

사이드프로젝트가 무너지는 가장 흔한 시점은 본업이 바빠지는 주입니다. 이걸 견디는 두 가지 장치입니다.

고정 시간 블록: 매주 같은 요일·시간에 2시간씩 4번 = 8시간. 캘린더에 "사이드프로젝트"로 넣고 친구·가족에게 공유합니다. 약속을 거절할 명분이 됩니다.
15분 최소 단위 규칙: 피곤한 날에도 15분만 열어서 코드 한 줄·문서 한 줄을 적습니다. 0과 15분 사이엔 거대한 심리적 격차가 있어, 다음 날 다시 열 동력을 만듭니다.

5-3. 안티 패턴: 완벽한 디자인부터

피그마·UI 키트·아이콘 세트를 고르는 데 첫 주를 다 쓰는 분이 정말 많습니다. 사이드프로젝트 첫 버전은 흰 배경에 검은 글씨로도 출시할 수 있습니다. 디자인은 사용자 5명이 생긴 다음에 개선해도 늦지 않습니다. Tailwind 기본 클래스에 shadcn 기본 컴포넌트면 충분합니다.

5-4. 안티 패턴: 코드 품질 강박

테스트 커버리지·CI·CD·E2E 테스트는 매력적인 주제지만, 출시 전 사이드프로젝트엔 사치입니다. 핵심 로직에 단위 테스트 5〜10개, 수동 점검 체크리스트 1장이면 첫 버전엔 충분합니다. 코드 품질에 들이는 시간이 검증·사용자 확보 시간을 잡아먹기 시작하면, 1단계로 돌아갈 위험 신호입니다.

Step 6: 배포·첫 사용자 5명 확보 — "사용자 = 친구의 친구"

MVP가 떠 있다면 다음은 사용자 확보입니다. 사이드프로젝트 단계에선 "1만 명"이 목표가 아니라 "내가 모르는 사람 5명"이 1차 목표입니다. 친구 30명에게 부탁해서 가입시키는 건 의미 없는 숫자입니다.

6-1. 노출 채널 우선순위

본업과 병행 가능한 범위에서 다음 순서로 노출합니다.

랜딩페이지 사전 신청자에게 발송 (Day 1〜3): Step 2에서 모은 이메일에 "베타 오픈" 안내. 가장 전환율이 높은 채널이고 합법적입니다.
본인 분야 커뮤니티 (Day 4〜10): 페이스북·디스코드·슬랙·OKKY·인프런 등 이미 가입돼 있고 본인을 아는 사람이 있는 곳 1〜2곳. 새 채널을 동시에 5개 시도하지 마세요.
레딧·해커뉴스·트위터 (선택): 영어권 사용자가 타깃이라면. 한국어 사이드프로젝트라면 우선순위 낮음.
Product Hunt·디스콰이엇·긱뉴스 (선택): 출시일이 정해진 형태. 처음엔 부담이 크니 두 번째 사이드프로젝트부터 권장.

각 채널 노출 때마다 본인 사연 1〜2단락 + 사용 예시 1개 + 도움 요청 1줄을 함께 적습니다. 광고 톤은 거의 무시되고, 사연 톤은 살아남습니다.

6-2. "칭찬 5개"보다 "재방문 1개"가 중요하다

첫 사용자 피드백이 "예쁘다", "좋네요"로 도배되면 위험합니다. 그건 친구·동료의 사회적 응대입니다. 진짜 가치 신호는 두 가지입니다.

일주일 안에 다시 들어왔다 (재방문)
본인 친구를 데려왔다 (자발적 소개)

이 둘 중 하나도 없으면, 만족도 점수가 아무리 높아도 "있으면 좋지만 없어도 되는" 도구입니다. Step 7에서 피벗·중단 판단의 근거가 됩니다.

6-3. 사용자와의 첫 대화 5가지 질문

이메일·디스코드 DM으로 1:1 대화를 시도합니다. 다음 다섯 질문을 반복합니다.

"어떻게 알게 됐어요?" (유입 채널)
"처음 들어왔을 때 가장 어렵거나 헷갈렸던 게 뭐예요?" (온보딩)
"오늘 어떤 일 때문에 들어오셨어요?" (사용 맥락)
"이 도구가 없으면 지금 같은 일을 어떻게 처리하시나요?" (대체재)
"혹시 비슷한 일로 고생하는 분 한 명 추천해주실 수 있나요?" (소개 부탁)

5명에게서 이 다섯 질문에 답을 받으면, 다음 6주 동안 무엇을 고치고 무엇을 버려야 할지 거의 답이 나옵니다.

Step 7: 6주 운영 후 판단 — 계속·피벗·중단

배포 후 6주를 운영하면 의사결정에 필요한 데이터가 모입니다. 본업과 병행하는 사이드프로젝트는 무한히 끌고 가지 않는 것이 중요합니다. 종료 기준이 없으면 동력이 떨어진 채로 1년을 끌게 됩니다.

7-1. 6주 차에 보는 지표 3개

WAU (Weekly Active Users): 일주일에 한 번 이상 들어온 사람 수. 사이드프로젝트 기준 6주 차에 30명 이상이면 신호 양호.
W4 잔존율: 4주 전에 가입한 사용자 중 지금도 들어오는 비율. 10% 이상이면 가치가 있다는 신호. 5% 미만이면 가치 제안이 약함.
자발적 소개 비율: 신규 사용자 중 "친구가 알려줘서" 들어온 비율. 20% 이상이면 입소문 신호 발생.

세 지표 중 2개 이상이 위 기준을 넘으면 계속, 1개만 넘으면 피벗, 하나도 못 넘으면 중단 또는 학습 정리 후 다음 프로젝트입니다.

7-2. 계속(Continue) 결정의 다음 단계

가격 정책 시도: 무료 사용자 일부에게 "10,000원 결제 의향이 있으신가요?" 인터뷰 5명
두 번째 핵심 기능 추가 (Should 후보 중 1개)
본업 외 투자 시간을 주 8 → 주 12시간으로 늘릴지 결정

7-3. 피벗(Pivot) 결정의 다음 단계

지표가 어중간하다면, "도구는 그대로 두되 타깃을 바꾼다" 또는 "타깃은 그대로 두되 기능을 바꾼다" 둘 중 하나만 바꿉니다. 둘 다 바꾸면 처음부터 다시 시작하는 것과 같습니다. 1단계로 돌아가 4〜6주 추가 검증.

7-4. 중단(Stop) 결정의 다음 단계

중단은 실패가 아니라 학습 정리입니다. 다음 세 가지를 기록하면 사이드프로젝트 1회 사이클이 완성됩니다.

회고 노트: 무엇이 잘됐고 무엇이 안 됐는지 1페이지
학습 항목: 새로 배운 기술·도구 목록
재사용 자산: 다음 프로젝트에 가져갈 컴포넌트·스크립트·인프라

저장소는 비공개 아카이브로 옮기고, 도메인은 만료 처리합니다. 머릿속에서 "끝남" 표시를 명확히 해야 다음 프로젝트가 가벼워집니다.

주의사항

본업 병행 사이드프로젝트에서 가장 자주 빠지는 함정 5가지입니다. 위 7단계에서 이미 일부 언급했지만, 자주 잊히는 부분만 다시 모았습니다.

1) 본업 자산을 무단으로 가져가지 마세요

본업에서 만든 코드·고객 리스트·내부 도구를 사이드프로젝트로 가져오면 근로계약·취업규칙·영업비밀 위반이 됩니다. 회사 PC·계정·시간을 쓰지 않는 것이 최소 안전선입니다. 회사가 "근무 외 활동 신고" 제도를 두고 있다면 미리 알리는 것이 안전합니다.

2) "8시간 자고 운동하는" 사람이 끝까지 갑니다

수면 5시간으로 6개월을 끌고 가면 4개월 차에 본업·관계·건강이 동시에 무너집니다. 수면 7〜8시간 + 주 2회 운동이 사이드프로젝트 완주의 가장 큰 변수입니다. 야근으로 시간을 만들지 말고, 평소 안 보던 SNS·유튜브 1시간을 잘라서 만드세요.

3) 새 아이디어가 떠올라도 추가하지 않는다

빌드 중에 떠오르는 새 기능 아이디어는 Backlog 폴더에 적기만 합니다. 그 자리에서 추가하면 출시일이 무한정 밀립니다. 사이드프로젝트의 1차 의무는 출시이지 완벽이 아닙니다.

4) 도메인·디자인·로고에 첫 주를 쓰지 않는다

이건 사용자 50명 이후에 결정해도 늦지 않습니다. 첫 주에 도메인을 고르느라 사흘을 쓴 분이 정말 많은데, 그 시간을 인터뷰 1명 추가에 쓰는 편이 100배 가치 있습니다.

5) 혼자 갈수록 빨리 죽는다

본업 외 시간에 혼자 코드를 짜면 외로움이 가장 큰 적이 됩니다. 사이드프로젝트 동료 1명 또는 같은 시기에 작업하는 비공식 모임 1개가 완주율을 2배 이상 올린다는 인디해커 커뮤니티 자체 설문(2023)도 있습니다. 디스코드의 IndieHackers, Build in Public, OKKY 사이드프로젝트 게시판 등을 활용하세요.

마무리

사이드프로젝트의 순서가 꼬이는 가장 큰 이유는 "무엇을 만들지" 부터 시작하기 때문입니다. 위 7단계는 그 함정을 막기 위한 최소 절차입니다. 16〜18주 안에 "이걸 계속할지 말지"를 책임 있게 결정하는 데 필요한 시간이고, 이 사이클 한 번을 끝까지 돌리면 다음 프로젝트의 속도는 2〜3배 빨라집니다.

16주 체크리스트 (요약)

1주차: 문제 후보 3개, 한 문장 포맷, 동료 2명 검토
2〜3주차: 인터뷰 5명, 랜딩페이지, 이메일 20개 모집
4주차: 1줄 가치 제안, 기능 3개 동결, 새 아이디어는 Backlog로
4주차: 기술 스택 80:20, 1일 안에 환경 세팅 완료
5〜10주차: 2주 스프린트 × 3회, 회고 1페이지씩
11〜12주차: 사전 신청자에게 베타 발송, 본인 분야 커뮤니티 2곳 노출
13〜18주차: 6주 운영 후 WAU·잔존율·소개 비율 측정 → 계속/피벗/중단 결정

오늘 당장 시작한다면 첫 1주의 행동은 단순합니다. 본인이 6개월 동안 지치지 않고 이야기할 수 있는 영역을 종이에 5개 적고, 그중에 "친한 동료의 진짜 짜증"과 겹치는 것을 표시하세요. 거기서 1개를 골라 한 문장 포맷으로 정리하면, 1단계 절반이 끝납니다.

본업과 병행하는 사이드프로젝트는 단거리가 아니라 마라톤입니다. 수면·운동·8시간 고정 시간 블록, 그리고 2주마다 끊는 의사결정 지점이 완주의 핵심입니다. 16주 뒤에 본인이 어떤 의사결정을 내리든, 그 사이클 1회를 마친 사람과 못 마친 사람의 격차는 다음 6개월 안에 분명히 드러납니다.

Tag: 사이드프로젝트

사이드프로젝트 순서 — 아이디어 검증부터 첫 사용자 확보까지 본업 병행 7단계 실전 로드맵 2026