사이드 프로젝트를 끝까지 완성하는 법

Prologue: 내 GitHub 묘지

솔직히 내 GitHub에는 완성된 프로젝트보다 abandoned 프로젝트가 훨씬 많아.

habit-tracker-v2, my-blog-v3, productivity-app, korean-vocab-flashcard... 각각 커밋이 3-15개 사이야. 아이디어가 반짝이던 어느 주말에 불을 지폈다가, 2주 후엔 "언젠가는 돌아와야지" 상태가 된 것들.

그러다가 처음으로 사이드 프로젝트를 제대로 끝냈어. 별거 아닌 것 같은 작은 도구였는데, 처음으로 실제로 배포하고 다른 사람들이 쓰는 걸 봤을 때 기분이 완전히 달랐어.

그때 뭐가 달랐는지 돌아봤어. 그게 이 글이야.

90%가 죽는 이유

이상과 현실의 갭

사이드 프로젝트가 죽는 가장 큰 이유는 시작할 때의 기대와 실제 작업의 갭이야.

아이디어가 떠오를 때 머릿속엔 이런 게 보여:

깔끔하고 완성도 높은 UI
유용한 기능들이 다 들어간 앱
사람들이 와서 쓰고 좋아하는 것

실제로 만들다 보면 이런 것들을 만나:

인증 구현에 2일이 날아감
"간단한 기능"인데 edge case가 수십 개
완성되어도 아무도 모름
계속 다듬고 싶어서 배포를 못 함

이상적인 모습과 현실 작업의 갭이 클수록, 동기 부여가 빨리 소진돼.

구체적인 사망 패턴들

완벽주의 사망:

아이디어 → 기술 스택 고민 3일 → 아키텍처 설계 1주일 → 
DB 스키마 최적화 → 컴포넌트 구조 리팩토링 → 
어, 이미 흥미 식었다

스코프 크립 사망:

"할 일 앱 만들자" → "카테고리도 있어야지" → "반복 일정도" →
"달력 뷰도" → "팀 협업 기능도" → "알림도" →
[포기]

완성 불안 사망:

기능 구현 완료 → "아직 이것도 없잖아" → 더 만들기 →
"이것도 없으면 부끄럽잖아" → 배포 못 함 →
흥미 소진 → 포기

기술 삽질 사망:

"최신 기술 써봐야지" → 새 프레임워크 학습 2주 →
버그와 씨름 1주 → 진척 없음 → 동기 소진

MVP 마인드셋: 최소한이 아니라 최초로 쓸 수 있는 것

MVP(Minimum Viable Product)를 "최소한으로 만든 것"으로 이해하면 틀려.

올바른 MVP의 정의:

"코어 문제 하나를 해결하는, 실제로 사람이 쓸 수 있는 가장 단순한 버전"

MVP 스코프를 정하는 방법

내가 쓰는 방법이야. 아이디어가 생기면 이 질문들에 답해:

1. 이 앱이 해결하는 핵심 문제 한 줄로:
   "_____이 힘든 사람들이 _____하기 쉽게"

2. 이 앱 없이 지금 사람들은 어떻게 하나?
   → 그 방법보다 10% 이상 나으면 충분

3. 핵심 기능 딱 하나만 남긴다면?
   → 그게 MVP의 전부

4. 이것만 있어도 누군가 쓰겠는가?
   → YES면 시작

실제 예시

나쁜 MVP 계획:

v1.0 기능 목록:
- 사용자 인증 (소셜 로그인 3가지)
- 할 일 CRUD
- 카테고리 태그
- 우선순위 정렬
- 날짜/시간 설정
- 반복 일정
- 알림
- 협업/공유
- 모바일 앱
- 다크 모드

좋은 MVP 계획:

v0.1 기능 (배포 가능):
- 로컬 스토리지로 할 일 저장/완료 체크
- 끝

v0.2 (만약 계속 쓴다면):
- 간단한 카테고리

v1.0 (실제 사람들이 원한다면):
- 클라우드 동기화

스코프 관리: 피처 크립과 싸우는 법

"나중에 기능" 리스트

아이디어가 떠오를 때마다 구현하면 끝이 없어. 대신 "나중에 기능" 리스트를 따로 만들어.

# my-app TODO

## MVP (지금 해야 할 것)
- [x] 기본 레이아웃
- [ ] 할 일 추가
- [ ] 할 일 완료 체크
- [ ] 로컬 저장

## Backlog (MVP 배포 후)
- 카테고리
- 검색
- 정렬
- 통계

## Maybe Someday
- 모바일 앱
- 협업
- AI 추천

"이거 없으면 안 되겠다!" 싶은 게 생기면, 일단 backlog에 넣어. 지금 있는 것들을 먼저 끝내.

72시간 룰

새 아이디어가 떠오르면 72시간 동안 기다려. 3일 후에도 여전히 "이거 꼭 해야 해"라고 생각하면 backlog에 추가. 그냥 순간의 충동이면 72시간이면 사라져.

기능 추가 전 질문

1. 이 기능이 없으면 MVP가 동작하지 않는가?
2. 내 첫 10명 사용자가 실제로 요청했는가?
3. 이걸 만드는 데 하루 이상 걸리는가?

3개 다 NO면 → 지금 하지 마라
1번이 YES면 → 지금 해야 한다
2번이 YES면 → backlog에 넣어

지루한 기술을 선택하라

신기술을 쓰고 싶은 욕구는 자연스러워. 근데 사이드 프로젝트를 완성하고 싶다면 그 욕구를 눌러야 할 때가 있어.

Boring Technology의 이점

새 기술을 쓰면:

학습 곡선 → 진척 없는 기간 → 동기 소진
버그가 생겨도 "내 코드 문제 vs 프레임워크 버그" 구분 불가
Stack Overflow 답변 없음, 커뮤니티 작음

이미 아는 기술을 쓰면:

빠르게 진척 → 도파민 → 동기 유지
문제 생기면 즉각 해결
생각이 "어떻게 만들까"가 아니라 "무엇을 만들까"에 집중

❌ "사이드 프로젝트에서 Rust + WASM 써볼까"
   (완성 확률 낮음)

✅ "Next.js + TypeScript로 2주 안에 배포하자"
   (이미 아는 스택, 완성에 집중)

예외: 기술 학습 자체가 목적인 경우. 이때는 학습을 목표로 설정하고 완성에 대한 기대를 낮춰. "배포"가 목표가 아니라 "이 기술 이해"가 목표.

스택 결정하기

내가 쓰는 기준:

이미 아는 스택으로 2주 안에 배포 가능한가?
├── YES → 그 스택으로 간다
└── NO → 왜 안 되는지 확인
    ├── 스택이 문제 → 이미 아는 것 중에서 고르기
    └── 2주가 너무 짧음 → 스코프 더 줄이기

공개 책임감 (Public Accountability)

혼자서 하면 미루기 쉬워. 다른 사람들에게 공표하면 달라져.

효과적인 공개 방법들

Twitter/X나 LinkedIn에 계획 공표:

"다음 주까지 [프로젝트 이름] MVP 배포할 거야.
기능: [딱 3개만]
주간 업데이트 올릴게"

Build in Public 형식:

매주 진척 상황 한 두 줄 포스팅
막힌 부분도 공유 (도움 받을 수 있음)
배포 소식 공유

Dev.to, 블로그에 만드는 과정 연재:

글을 써야 하니까 계속 만들게 됨
나중에 포트폴리오가 됨
독자들이 관심 가지면 완성 동기 강해짐

Discord, Slack 커뮤니티에 공유:

주변 개발자들이 기다리게 됨
막히면 도움 요청 가능
완성 후 첫 사용자가 될 수도 있음

나는 개인적으로 주간 트윗 방식이 제일 효과적이었어. 트윗 한 줄 쓰려면 뭔가 진척이 있어야 하니까 매주 조금씩이라도 하게 돼.

작은 승리를 축하하라

큰 목표("앱 완성")만 바라보면 중간 과정이 지루해. 작은 마일스톤을 정하고 각각을 완성했을 때 실제로 기분 좋게 여겨야 해.

마일스톤 예시

## 개발 마일스톤

### Week 1
- [ ] 레포 만들고 Hello World 배포
- [ ] 기본 레이아웃 완성
- [ ] 데이터 모델 설계

### Week 2
- [ ] 핵심 기능 1 완성
- [ ] 핵심 기능 2 완성

### Week 3
- [ ] 기본 UI 완성
- [ ] 배포 (Vercel/Railway)

### 배포 후
- [ ] 첫 5명에게 링크 공유
- [ ] 첫 실제 사용자 피드백

"레포 만들고 Hello World 배포"도 마일스톤으로 여겨. 실제로 URL이 생기면 뭔가 현실적이 돼.

완벽하지 않아도 배포한다

많은 사이드 프로젝트가 "아직 완성되지 않았다"는 이유로 배포를 미뤄. 근데 배포를 해야 진짜 피드백이 생기고, 그 피드백이 다음 개발의 동기가 돼.

"If you're not embarrassed by the first version of your product, you've launched too late." — Reid Hoffman

부끄러운 버전이라도 배포하는 게, 완벽하게 만들려다 포기하는 것보다 100배 낫다.

배포 vs 완성

사이드 프로젝트에서 "완성"이 뭔지 정의하는 게 중요해.

좋지 않은 완성 정의:

"모든 기능이 다 들어갔을 때"
"디자인이 완벽해졌을 때"
"버그가 하나도 없을 때"
"코드가 깔끔해졌을 때"

좋은 완성 정의:

"첫 번째 실제 사용자가 있을 때"
"내가 직접 매일 쓰고 있을 때"
"코어 문제가 해결됐을 때"

배포 가능한 최소 기준을 정해:

배포 기준 체크리스트:
- [ ] 핵심 기능 1개가 동작한다
- [ ] 치명적인 버그가 없다 (눈에 보이는 에러)
- [ ] README에 사용법이 있다
- [ ] 나 혼자 써봤을 때 유용하다

→ 위 4개 충족하면 배포한다

나의 완성된 프로젝트 vs 포기된 프로젝트

솔직하게 비교해봤어.

완성된 프로젝트들의 공통점

스코프가 작았다 (핵심 기능 1-2개)
이미 아는 스택을 썼다
실제로 내가 쓰고 싶어서 만들었다
"일단 배포하자"는 마인드였다
1-3주 안에 배포했다

포기된 프로젝트들의 공통점

기능이 너무 많았다 (10개 이상)
새 기술을 써보려고 했다
"이 정도면 사람들이 좋아하겠지"에서 시작했다
완벽해지길 기다렸다
1달이 넘어갔다

가장 크게 배운 것

"지금 쓸 수 있는 못난 버전 > 나중에 나올 완벽한 버전"

못난 버전이라도 실제 URL이 있으면:

친구한테 보낼 수 있어
실제 피드백을 받을 수 있어
이력서에 링크를 넣을 수 있어
"만들고 있어"에서 "만들었어"가 돼

포기해야 할 때와 계속해야 할 때

모든 사이드 프로젝트를 끝내야 하는 건 아니야. 때로는 그냥 놔두는 게 맞아.

포기해도 되는 경우:

배우고 싶던 기술을 충분히 배웠을 때
비슷한 더 좋은 제품이 이미 있다는 걸 알게 됐을 때
실제로 이 문제를 해결하고 싶지 않다는 걸 깨달았을 때
더 중요한 다른 것에 집중해야 할 때

계속해야 하는 경우:

내가 직접 이 문제로 힘들 때
비슷한 것을 찾았는데 내가 원하는 건 없을 때
실제 잠재 사용자가 기다리고 있을 때

"포기 = 실패"가 아니야. 잘못된 문제를 계속 파는 것보다, 빨리 포기하고 올바른 프로젝트에 집중하는 게 낫다.

실천 플랜: 지금 당장 시작하기

읽고 끝내면 소용없어. 지금 바로 해봐.

30분 액션

1. 지금 하고 싶은 사이드 프로젝트를 딱 하나 골라 (5분)
2. 한 줄로 핵심 기능 정의: "___ 하는 도구" (5분)
3. MVP 기능 최대 3개만 리스트 (10분)
4. 배포 날짜 정하기 (지금으로부터 2주 후) (1분)
5. 레포 만들기 (9분)

5번까지 하면 이미 시작한 거야.

주간 루틴

매주 금요일 20분:
- 이번 주 뭘 만들었나? (5분 정리)
- 다음 주 뭘 만들 것인가? (딱 3가지만)
- 진행 상황 트윗/포스팅 (5분)

막혔을 때

막힌 게 있을 때:
1. 타이머 30분 → 혼자 해결 시도
2. 안 되면 StackOverflow/Claude/GPT에 물어보기
3. 그래도 안 되면 → 이 기능 없이도 되는가?
   YES → 일단 스킵하고 다른 것 먼저
   NO → 더 심플한 방법은 없는가?

정리: 완성의 메타스킬

사이드 프로젝트를 완성하는 건 개발 능력과는 별개의 스킬이야.

아이디어를 좁히는 능력
완벽하지 않아도 출시하는 용기
흥미가 식어도 계속하는 지속력
새 아이디어의 유혹을 뿌리치는 집중력

이 스킬들은 연습을 통해 늘어. 작은 프로젝트를 많이 완성할수록, 다음 프로젝트가 더 쉬워져.

지금 당장 만들어. 나중에 고쳐.