“이번엔 꼭 성공하자”라고 다짐하며 시작한 사이드 프로젝트였다. 하지만 3개월 후, 나는 프로젝트를 포기했다. 기술 스택 선택의 실수, 시간 관리 실패, 동기 부족까지. 이 글은 그 실패의 기록이다.
시작: 새로운 프로젝트의 설렘
프로젝트 아이디어
2025년 9월, “개인 일정 관리 앱”을 만들기로 했다. Notion과 Todoist를 합친 것 같은 앱이었다. 마크다운으로 노트를 작성하고, 할 일을 관리하고, 캘린더와 연동하는 기능을 생각했다.
“이런 앱이 있으면 좋을 것 같은데?”라는 생각으로 시작했다.
초기 기대감
프로젝트를 시작할 때는 항상 설렌다. 이번엔 다를 거라고 생각한다. 이전 프로젝트들의 실패를 교훈으로 삼아 더 잘할 수 있을 거라고.
기술 스택도 신중하게 선택했다:
- 프론트엔드: Next.js 15 (최신 버전)
- 백엔드: Node.js + Express
- 데이터베이스: PostgreSQL
- 배포: Vercel + Railway
“이번엔 확실해!”라고 생각했다.
첫 번째 실수: 기술 스택 선택
최신 기술에 대한 집착
프로젝트를 시작하면서 “최신 기술을 사용해야 한다”는 생각에 사로잡혔다. Next.js 15의 최신 기능들을 모두 사용하려고 했다.
Server Components, App Router, React Server Actions… 모든 최신 기능을 사용하려고 했다. 하지만 문제는 내가 이 기능들을 제대로 이해하지 못했다는 것이다.
학습 곡선의 벽
최신 기술을 사용하려다 보니 학습 시간이 너무 오래 걸렸다. 간단한 기능 하나를 구현하는데도 문서를 읽고, 예제를 찾고, 시행착오를 거쳐야 했다.
예상:
- 프로젝트 시작: 1주
- 기본 기능 구현: 2주
- 배포: 1주
- 총: 1개월
현실:
- 프로젝트 시작: 1주
- 기본 기능 구현: 6주 (계속 막힘)
- 배포: 아직 못 함
기술 부채의 누적
제대로 이해하지 못한 채로 코드를 작성하다 보니 기술 부채가 쌓였다. 나중에 수정하려고 하니 더 복잡해졌다.
“이전에는 React만 알면 됐는데, 지금은 Server Components, App Router, Server Actions까지 알아야 해.”
복잡도가 너무 높아졌다.
두 번째 실수: 시간 관리 실패
현실적인 시간 계획의 부재
사이드 프로젝트는 업무 후, 주말에 진행했다. 하지만 현실적인 시간 계획을 세우지 않았다.
계획:
- 평일: 매일 2시간
- 주말: 하루 4시간
- 주당: 18시간
현실:
- 평일: 피곤해서 못 함
- 주말: 다른 일로 바쁨
- 주당: 실제로는 5시간도 안 됨
우선순위의 혼란
업무, 개인 생활, 사이드 프로젝트 사이에서 우선순위가 혼란스러웠다. 업무가 바쁘면 프로젝트를 포기했고, 개인 생활이 바쁘면 프로젝트를 미뤘다.
결국 프로젝트는 항상 마지막 순위였다.
지속성의 부족
처음 한 달은 열정적으로 진행했다. 하지만 두 번째 달부터는 지속성이 떨어졌다. 며칠씩 프로젝트를 건드리지 않았다.
“내일 하지 뭐”라는 생각이 계속 들었다.
세 번째 실수: 동기 부족
명확한 목표의 부재
프로젝트를 시작할 때 명확한 목표가 없었다. “좋은 앱을 만들자”는 모호한 목표만 있었다.
명확하지 않은 목표:
- 좋은 앱 만들기
- 사용자에게 도움이 되는 앱
- 포트폴리오용 프로젝트
명확한 목표 예시:
- 100명의 사용자 확보
- 월 $100 수익 창출
- 특정 문제 해결
목표가 명확하지 않아서 동기가 떨어졌다.
사용자 피드백의 부재
혼자서 개발하다 보니 사용자 피드백을 받을 수 없었다. 내가 만든 것이 정말 필요한지, 사용자들이 원하는 것인지 알 수 없었다.
“이 기능이 정말 필요한가?”라는 의문이 계속 들었다.
성과의 부재
3개월 동안 개발했지만, 실제로 사용할 수 있는 것은 없었다. 배포도 못 했고, 사용자도 없었다.
성과가 없으니 동기가 떨어졌다.
네 번째 실수: 완벽주의
MVP를 만들지 않음
처음부터 완벽한 앱을 만들려고 했다. 모든 기능을 구현하려고 했다.
계획한 기능:
- 마크다운 에디터
- 할 일 관리
- 캘린더 연동
- 태그 시스템
- 검색 기능
- 다크 모드
- 모바일 앱
- …
너무 많은 기능을 한 번에 구현하려고 했다.
MVP가 있었다면
MVP (Minimum Viable Product)를 만들었다면:
- 마크다운 에디터
- 할 일 관리
- 기본 배포
이 정도만 있어도 사용자에게 보여줄 수 있었을 것이다.
다섯 번째 실수: 혼자서 모든 것을 하려고 함
풀스택의 함정
프론트엔드, 백엔드, 데이터베이스, 디자인, 배포까지 모든 것을 혼자서 하려고 했다. 각 분야의 전문가가 아니었기 때문에 모든 것이 서툴렀다.
프론트엔드:
- 디자인이 어색함
- UX가 좋지 않음
백엔드:
- API 설계가 비효율적
- 보안 고려 부족
데이터베이스:
- 스키마 설계가 최적이 아님
- 쿼리 최적화 부족
모든 것을 혼자서 하려다 보니 아무것도 제대로 되지 않았다.
결국 포기
포기 결정
2025년 12월, 프로젝트를 포기하기로 결정했다. 3개월 동안 개발했지만, 실제로 사용할 수 있는 것은 없었다.
포기 이유:
- 기술 스택이 너무 복잡함
- 시간이 부족함
- 동기가 떨어짐
- 성과가 없음
- 완벽주의에 빠짐
포기 후 느낀 점
포기하는 것이 쉽지 않았다. 3개월 동안의 시간과 노력이 아깝게 느껴졌다. 하지만 계속 진행하는 것보다 포기하는 것이 나았다.
“이렇게 하면 안 되겠다”는 것을 깨달았다.
배운 점들
1. 기술 스택은 신중하게 선택하라
최신 기술이 항상 좋은 것은 아니다. 자신이 잘 아는 기술을 사용하는 것이 더 빠르고 안정적이다. 새로운 기술을 사용하려면 충분한 학습 시간을 확보해야 한다.
2. 현실적인 시간 계획을 세우라
사이드 프로젝트는 업무와 개인 생활 사이에서 진행된다. 현실적인 시간 계획을 세우고, 지속 가능한 속도로 진행해야 한다.
3. 명확한 목표를 설정하라
모호한 목표는 동기를 떨어뜨린다. 명확하고 측정 가능한 목표를 설정해야 한다.
4. MVP를 먼저 만들라
완벽한 앱을 만들려고 하지 말고, MVP를 먼저 만들라. 사용자에게 보여주고 피드백을 받는 것이 중요하다.
5. 혼자서 모든 것을 하지 말라
혼자서 모든 것을 하려고 하지 말고, 필요한 부분은 도움을 받거나 외주를 주는 것도 고려하라.
6. 포기하는 것도 용기다
계속 진행하는 것만이 용기가 아니다. 때로는 포기하는 것도 용기다. 실패를 인정하고 다음으로 나아가는 것이 중요하다.
다음 프로젝트를 위한 계획
개선할 점들
다음 프로젝트를 시작한다면:
- 기술 스택: 잘 아는 기술 사용
- 시간 계획: 현실적인 계획 수립
- 목표 설정: 명확하고 측정 가능한 목표
- MVP 우선: 완벽하지 않아도 먼저 배포
- 협업: 필요한 부분은 도움 받기
- 지속성: 매일 조금씩이라도 진행
작은 프로젝트부터
다음에는 작은 프로젝트부터 시작하겠다. 1주일 안에 완성할 수 있는 작은 프로젝트부터 시작해서 성공 경험을 쌓아가겠다.
다른 개발자들에게
사이드 프로젝트를 시작한다면
사이드 프로젝트를 시작하려는 개발자들에게 조언한다:
- 작은 것부터 시작하라: 큰 프로젝트보다 작은 프로젝트부터
- MVP를 만들라: 완벽하지 않아도 먼저 배포하라
- 현실적인 계획: 시간과 목표를 현실적으로 설정하라
- 명확한 목표: 왜 이 프로젝트를 하는지 명확히 하라
- 지속성: 매일 조금씩이라도 진행하라
실패를 두려워하지 말라
실패는 배움의 기회다. 실패를 통해 무엇이 잘못되었는지 배울 수 있다. 다음 프로젝트에서 실수를 반복하지 않으면 된다.
결론: 실패에서 배운 것
3개월 동안의 프로젝트는 실패로 끝났다. 하지만 그 실패를 통해 많은 것을 배웠다. 기술 선택의 중요성, 시간 관리의 필요성, 명확한 목표의 중요성까지.
지금은 다음 프로젝트를 준비하고 있다. 이번 경험을 바탕으로 더 나은 프로젝트를 만들 수 있을 것이다.
실패는 배움의 기회다. 이 경험이 다른 개발자들에게 도움이 되기를 바란다.
