세 번 포기하고 나서야 깨달은 게 있습니다. 사이드 프로젝트가 죽는 건 실력 때문이 아니라는 점입니다. 저도 처음엔 "이번엔 다르다"며 노션에 기능 목록을 20개씩 채워 넣었습니다. 그리고 어김없이 3주를 넘기지 못했습니다. 실패한 세 번의 이유는 전부 같았고, 네 번째에서야 처음으로 배포 버튼을 눌렀습니다.
MVP로 시작하지 않으면 대부분 여기서 끝납니다
일반적으로 사이드 프로젝트 실패의 원인을 "의지 부족"으로 보는 시각도 있는데, 제 경험상 이건 좀 다릅니다. 진짜 원인은 범위 설정 실패, 즉 Scope Creep입니다. Scope Creep이란 처음에 설정한 프로젝트 범위가 개발 도중 계속 늘어나는 현상을 말합니다. 로그인 기능을 만들다가 "소셜 로그인도 넣자", "프로필 편집도 있어야지"로 번지는 식입니다. 기능이 하나 늘어날 때마다 완성까지의 거리는 두 배씩 멀어집니다.
실제로 사이드 프로젝트의 70% 이상이 미완성으로 끝난다는 조사 결과도 있습니다. 이 수치를 처음 접했을 때 저는 "그 70%에 세 번이나 들어있었구나"라는 생각이 먼저 들었습니다.
네 번째 프로젝트에서 제가 가장 먼저 한 일은 기능 목록을 절반으로 지우는 것이었습니다. 그리고 완성 기준을 딱 하나로 정했습니다. "실제 사용자 한 명이 쓸 수 있는 상태." 이게 바로 MVP(Minimum Viable Product)의 핵심입니다. MVP란 핵심 기능만 갖춘 최소 단위의 제품으로, 완벽한 서비스가 아니라 "쓸 수 있는 무언가"를 가장 빠르게 세상에 내놓는 개념입니다. 처음에는 이 기준이 너무 낮은 것 같아서 불안했습니다. 그런데 막상 해보니, 그 낮은 기준조차 맞추는 게 생각보다 쉽지 않았습니다.
솔직히 이건 예상 밖이었습니다. "기능을 줄이면 쉬워지겠지"라고 생각했는데, 기능을 줄여도 집중해야 할 것들이 여전히 남아 있었습니다. 차이는 "끝이 보인다"는 감각이었습니다. 그 감각이 실제로 완성까지 가게 해줬습니다.
1인 개발에서 MVP를 지키기 위해 제가 실천한 방식은 다음과 같습니다.
- 기능 목록 작성 후 반드시 절반 삭제
- 완성 기준을 "실제 사용자 1명이 쓸 수 있는 상태"로 고정
- 추가 기능은 배포 후 v2로 미루는 규칙 적용
- 트위터에 개발 과정을 공개해 작은 책임감 만들기
마지막 항목이 의외로 효과가 컸습니다. 피드백을 받으려던 게 아니라, 중간에 그냥 멈추기 민망한 상황을 스스로 만든 것입니다. 아무도 강요하지 않았지만, 공개된 기록이 있으니 포기하기가 어려워졌습니다.
기술 스택 선택이 완성 확률을 결정합니다
일반적으로 "사이드 프로젝트는 새로운 기술을 배울 기회"라고 알려져 있지만, 제 경험상 이건 완성을 목표로 할 때는 맞지 않는 말입니다. 새로운 기술을 배우면서 동시에 서비스를 완성하려는 시도가 대부분의 사이드 프로젝트를 중간에 무너뜨립니다. 모르는 기술의 문서를 읽다가 에너지가 다 빠지고, 결국 흥미도 잃게 됩니다.
제가 네 번째 프로젝트에서 선택한 원칙은 단순했습니다. "내가 이미 아는 기술만 쓴다." 프론트엔드는 Next.js로 정했습니다. Next.js는 React 기반의 풀스택 프레임워크로, 서버사이드 렌더링(SSR)과 정적 사이트 생성(SSG)을 모두 지원해 1인 개발자가 프론트엔드와 API를 한 곳에서 관리할 수 있습니다. 여기서 SSR이란 페이지를 서버에서 미리 렌더링해 클라이언트에 전달하는 방식으로, 초기 로딩 속도와 SEO에 유리합니다.
백엔드는 Supabase를 선택했습니다. Supabase는 PostgreSQL 기반의 BaaS(Backend as a Service)입니다. BaaS란 데이터베이스, 인증, 스토리지 등 백엔드 기능을 서비스 형태로 제공해, 개발자가 직접 서버를 구축하고 운영할 필요 없이 API 호출만으로 사용할 수 있게 해주는 플랫폼입니다. DB 스키마 설계부터 REST API 작성까지 직접 하면 보통 며칠이 걸리는 작업을, Supabase를 쓰면 몇 시간 안에 끝낼 수 있었습니다. 제가 직접 써봤는데, 이 차이가 생각보다 훨씬 크게 체감됐습니다.
배포는 Vercel을 사용했습니다. Vercel은 Next.js 프로젝트와 궁합이 잘 맞는 클라우드 배포 플랫폼으로, GitHub 리포지토리와 연동하면 코드를 푸시할 때마다 자동으로 빌드와 배포가 이뤄집니다. CI/CD(지속적 통합·지속적 배포) 파이프라인을 별도로 구성할 필요가 없습니다. 여기서 CI/CD란 코드 변경 사항을 자동으로 테스트하고 배포하는 자동화 프로세스를 말하며, 일반적으로는 설정에 상당한 시간이 필요합니다. Vercel은 이 과정을 버튼 한 번으로 대신해줍니다.
혼자 개발하면 의사결정이 빠른 대신 피드백 루프가 없습니다. 방향이 맞는지 틀린지 알 수가 없습니다. 그래서 저는 기술 선택에서 최대한 보수적으로 굴고, 아끼는 에너지를 제품의 방향성을 잡는 데 썼습니다. Stack Overflow의 2023년 개발자 설문조사에 따르면 Next.js는 웹 프레임워크 부문에서 선호도 상위권을 유지하고 있으며, 특히 풀스택 개발 환경에서 활용도가 높은 것으로 나타났습니다(출처: Stack Overflow Developer Survey).
또한 Vercel 공식 자료에 따르면 Vercel을 통한 배포는 평균 설정 시간이 10분 이내로, 기존 클라우드 인프라 직접 구성 대비 DevOps 작업 부담을 대폭 줄일 수 있습니다(출처: Vercel).
결국 사이드 프로젝트를 완성한다는 건 기술력의 문제가 아니라 판단의 문제입니다. 어디서 욕심을 줄이고, 어디서 멈출지를 아는 것. 제가 세 번의 실패를 거친 뒤 얻은 결론은 이것입니다. 다음 프로젝트를 시작하려는 분이라면, 기능 목록을 다 쓴 뒤 지우는 것부터 시작해 보시길 권합니다. 그게 생각보다 훨씬 효과적이었습니다.
'IT적응기' 카테고리의 다른 글
| 개발자가 기술 블로그로 월 수익 내기까지 현실적인 수치와 실패담 포함 (0) | 2026.05.29 |
|---|---|
| 개발자가 노코드 툴을 쓸 때와 쓰지 말아야 할 때 (0) | 2026.05.28 |
| API 문서 읽는 시간을 절반으로 줄이는 법 AI를 번역기로 쓰는 개발자의 루틴 (0) | 2026.05.25 |
| 레거시 코드 리팩토링: AI와 함께 코드를 살린 실전 경험 (0) | 2026.05.24 |
| 로컬 LLM (Ollama, 데이터 주권, 클라우드 병행) (0) | 2026.05.23 |
