지난 3년간 사이드 프로젝트만 7개를 시작했는데요. 그중에 실제로 완성한 건 2개뿐이에요. 나머지는 다 중도 포기했죠. 솔직히 말하면 실패가 성공보다 훨씬 많았습니다. 근데 그 실패들이 지금 생각해보면 진짜 소중한 경험이었더라고요.
사이드 프로젝트 하면 다들 성공 스토리만 떠올리잖아요. ‘수익화했다’, ‘인수됐다’, ‘직장 그만두고 창업했다’ 이런 거요. 근데 현실은 완성도 못 하고 구글 드라이브 어딘가에서 잠자고 있는 코드들이 훨씬 많거든요. 저만 그런 거 아니죠?
처음 시작했을 때의 자만심
2023년 초, 사이드 프로젝트를 처음 시작했을 때가 기억나요. ‘간단한 투두 앱이면 2주면 충분하겠네’ 하고 시작했는데, 2주가 아니라 2개월이 걸렸어요. 그것도 완성 못 하고요.
문제는 기능을 계속 추가한 거예요. ‘이것만 있으면 더 좋을 것 같은데?’ 하면서요. 다크모드 추가, 알림 기능, 위젯, 클라우드 동기화… 결국 너무 복잡해져서 포기했어요. 이걸 스코프 크리프라고 하더라고요. 나중에 알았습니다.
출처: Unsplash
이때 배운 건 MVP(최소 기능 제품)의 중요성이에요. 진짜 핵심 기능 하나만 먼저 완성하고, 그다음에 추가해야 한다는 거요. 프리랜서 라이프 글에서도 비슷한 이야기를 한 적 있는데, 작게 시작하는 게 의외로 중요하더라고요. 지금 생각하면 너무 당연한데, 그땐 몰랐죠.
2번째 실패: 기술 스택 선택의 함정
두 번째 프로젝트는 블로그 자동화 도구였어요. 이때는 기술 스택을 완전히 새로운 걸로 선택했는데요. 러스트를 쓰기로 한 거죠. ‘성능이 좋으니까’라는 이유로요.
결과부터 말하면? 3주 만에 포기했어요. 러스트 문법을 배우는 데만 2주가 걸렸고, 막상 코드를 짜는데 빌더려워서 진도가 안 나가더라고요. 만들고 싶은 건 많은데 언어가 발목을 잡는 느낌? 이걸 학습 곡선이라고 하던데, 저한테는 학습 낭벽이었어요.
이 경험으로 배운 건, 사이드 프로젝트는 익숙한 도구로 시작해야 한다는 거예요. 새로운 걸 배우는 건 프로젝트가 아니라 따로 공부할 때 하고, 프로젝트는 이미 아는 걸로 빠르게 완성하는 게 맞아요.
성공한 2개의 공통점
그럼 완성한 2개는 뭐가 달랸냐고요? veltokeep.com 블로그에도 정리한 적 있는데, 공통점이 있었어요.
첫째, 스케줄이 정해져 있었다는 거예요. ‘매주 토요일 오전 2시간만 작업한다’고 딱 정해둔 거죠. 그러니까 오히려 진도가 잘 나가더라고요. 정해진 시간에만 하니까 집중도 되고, 회피도 안 하고요.
- 시간 블록: 매주 토요일 오전 9시~11시
- 기간: 8주 (총 16시간)
- 목표: 핵심 기능 1개 완성
둘째, 누군가에게 공개한다고 선언했어요. 제 경우엔 디스코드 친구들한테 ‘이번 주에 이거 완성할게’ 하고 말해둔 거죠. 그러니까 못해도 해야 되잖아요. 사회적 압력이 진짜 강력하더라고요.
셋째, 기능을 하나만 정하고 시작했어요. 정말 딱 하나요. ‘마크다운을 HTML로 변환한다’ 이것만요. 나머지는 다 뺐어요. 그러니까 8주 만에 완성할 수 있었죠.
사이드 프로젝트의 장단점
장점부터 말하면:
- 새로운 기술을 실전에서 익힐 수 있다 – 튜토리얼만큼 따라 하는 것보다 훨씬 깊이 배워요
- 포트폴리오가 된다 – 면접에서 ‘이 프로젝트 해봤어요’ 하고 코드 보여주면 진짜 강점이에요
- 문제 해결 능력이 는다 – 혼자서 기획부터 배포까지 하다 보니 전체 그림을 보는 눈이 생겨요
- 자신감이 생긴다 – 완성한 경험이 있으니까 ‘나도 할 수 있다’는 믿음이 들어요
단점도 분명히 있어요:
- 시간이 많이 든다 – 주말, 휴가 다 반납해야 할 수도 있어요
- 번아웃 위험이 있다 – 본업이 바쁜데 사이드까지 하려니 진이 빠질 때가 있어요
- 완성 못 하면 스트레스 – 시작만 하고 안 끝내면 ‘또 실패했나’ 싶어서 자존심 상해요
- 수익은 보장 안 된다 – 7개 중 수익화한 건 0개예요. 돈 버려고 시작하면 비추천
현실적인 조언 몇 가지
3년 동안 시행착오 끝에 깨달은 걸 정리해볼게요.
첫째, ‘재미’로 시작하세요. 수익, 포트폴리오, 이런 거 생각하면 금방 지쳐요. 진짜 내가 만들고 싶은 걸 만드는 게 중요해요. 저는 마케팅 블로그 운영하면서 겪는 불편함을 해결하는 도구를 만들었는데, 그게 재밌어서 끝까지 했거든요.
둘째, 파트너를 구하세요. 혼자 하면 흐지부지될 확률이 높아요. 같이 하면 서로 끌어주잖아요. 저도 혼자 할 때보다 친구랑 같이 할 때 완성률이 3배는 높더라고요.
셋째, 완성보다 출시가 중요해요. 완벽하게 만들려고 하지 마세요. 핵심 기능만 되면 일단 내놓는 게 낫습니다. 출시 후 개선이 완벽한 미출시보다 백배 나아요.
제가 좋아하는 말이 있어요. ‘완벽한 계획보다 불완전한 실행이 낫다’ 처음엔 반박하고 싶었는데, 지금은 백번 공감합니다.
실패해도 괜찮아
결론적으로 말하고 싶은 건, 사이드 프로젝트 실패해도 괜찮다는 거예요. 저도 7개 중 5개를 실패했는데, 그 실패들이 지금의 저를 만들었어요.
실패한 프로젝트에서 배운 게 성공한 프로젝트보다 많았거든요. 스코프 크리프가 뭔지, 왜 기술 스택이 중요한지, 어떻게 일정을 관리해야 하는지… 다 실패하면서 배웠어요.
그러니까 망설이지 말고 일단 시작해보세요. 작게요. 아주 작게요. 이번 주말에 2시간만 투자해보는 건 어떨까요? 어차피 실패해도 배우는 건 본인 몫이니까요.
여러분은 어떤 사이드 프로젝트 해보셨나요? 성공했는지 실패했는지, 댓글로 공유해주시면 좋겠어요. 저도 실패담 털어놨으니까 부담 갖지 마시고요.
다음엔 제가 완성한 2개 프로젝트 중 하나를 자세히 소개해볼게요. 어떤 걸 먼저 들으시고 싶으신가요? 댓글로 알려주세요.