내 GitHub에는 private repo가 12개 있다. 완성한 건 2개다. 나머지 10개는 README.md에 거창한 기능 목록만 남긴 채 마지막 커밋이 6개월 전이다.

이게 나만의 이야기는 아닐 거다. 개발자 커뮤니티에서 "사이드 프로젝트 시작했다"는 글은 넘쳐나는데, "완성했다"는 글은 거의 없다. 시작은 쉽다. npx create-next-app을 치는 순간에는 누구나 의욕이 넘친다. 문제는 그 다음이다.

나는 왜 10개를 버렸고, 2개는 어떻게 끝냈는지 돌아봤다. 거기서 찾은 패턴이 있다.

죽은 프로젝트들의 공통점#

작년 여름, "개발자를 위한 독서 기록 앱"을 만들겠다고 했다. 아이디어가 좋다고 생각했다. Notion이 너무 무겁고, 기존 독서 앱들은 개발 서적에 특화되지 않았으니까. 이틀 만에 피그마를 열고 화면 7개를 디자인했다. 책 검색, 독서 노트, 하이라이트, 태그 시스템, 통계 대시보드, 소셜 공유, 알림 설정. 그리고 기술 스택을 고르기 시작했다.

Next.js로 할까, Remix로 할까. DB는 Supabase? PlanetScale? 아니면 이참에 Drizzle ORM을 배워볼까. 상태 관리는 Zustand가 요즘 핫하다는데. 인증은 NextAuth vs Clerk...

일주일이 지났다. 코드는 한 줄도 없었다.

그 다음 주에는 회사에서 큰 기능 출시가 있어서 바빴고, 그 다음 주에는 피로가 쌓여서 쉬었고, 한 달 뒤에 "아 그거 만들고 있었지" 하면서 폴더를 열어봤다. 피그마 파일과 빈 프로젝트 스캐폴딩만 있었다. 다시 시작하기엔 관성이 사라진 뒤였다.

이 패턴이 10개 중 7개에서 반복됐다. 나머지 3개는 좀 달랐는데, 실제로 코딩은 시작했지만 "좀 더 다듬으면 되겠지" 하다가 소리 없이 사라졌다.

범위를 극단적으로 줄이기#

살아남은 프로젝트 중 하나는 "오늘 뭐 먹지 결정기"였다. 이름부터 유치하다. 하지만 이게 완성된 이유가 있다.

처음에는 이것도 거창했다. 위치 기반 맛집 추천, 메뉴 사진, 리뷰, 찜하기 기능까지 생각했다. 근데 전에 몇 번 실패한 경험이 있으니까 이번에는 스스로에게 물어봤다. "이 중에서 진짜 핵심이 뭐야?"

답은 간단했다. 점심시간에 메뉴 고르기가 귀찮은 거. 그래서 MVP를 이렇게 정했다.

• 카테고리 몇 개 중에서 랜덤으로 하나 골라주는 것
• 끝

위치 기반? v2. 맛집 DB? v2. 리뷰? v2. 사실 v2는 영원히 오지 않았지만 상관없다. 핵심은 v1이 완성됐다는 것이다. 버튼 하나 누르면 "오늘은 국밥 어때요?" 하고 알려주는 웹앱. 웃기지만 실제로 팀원들이 점심마다 쓰기 시작했다. 사용자가 생기니까 v2에 대한 동기도 자연스럽게 생겼다.

"v2에서 하겠다"는 말은 "안 하겠다"가 아니라 "지금은 안 하겠다"는 뜻이다. 근데 대부분의 사이드 프로젝트에서 "지금 안 하면 영원히 안 하는" 유일한 것은 완성 그 자체다. 기능은 나중에 붙일 수 있다. 하지만 "이걸 끝까지 만들어본 경험"은 지금 아니면 안 생긴다.

데드라인이 없으면 끝이 없다#

회사 업무는 왜 끝이 나는가? 마감이 있으니까. 사이드 프로젝트는 왜 끝이 안 나는가? 마감이 없으니까.

너무 당연한 소리 같지만 나는 이걸 한참 뒤에야 깨달았다. 두 번째로 완성한 프로젝트는 "개발 블로그 테마"였는데 (지금 이 블로그의 전신이다), 이게 완성된 결정적 이유가 있다. 회사 동기한테 "다음 주 금요일까지 블로그 올린다"고 말해버린 것이다.

그 동기는 그냥 "오 좋네" 하고 넘어갔을 수도 있다. 근데 나는 그 말을 한 순간부터 압박감이 생겼다. 금요일에 "블로그 됐어?" 하고 물을 게 뻔하니까. 약속을 안 지키면 체면이 깎이니까.

2주라는 시간은 기능을 막 붙일 수 있는 시간이 아니었다. 그래서 자연스럽게 "뭘 빼야 하지?"를 고민하게 됐다. 댓글 기능? 없어도 된다. 다크 모드? 나중에. SEO 최적화? 일단 기본만. 이렇게 빼고 나니까 만들어야 할 것이 확 줄었다. 그 데드라인이 범위 축소까지 강제한 셈이다.

인위적인 마감이라도 괜찮다. 아무한테나 말해라. 트위터에 써라. 커뮤니티에 올려라. "이번 달 안에 배포합니다." 그 한 마디가 만드는 압박감이 당신의 프로젝트를 살린다.

기술 스택 고민은 함정이다#

앞에서 독서 기록 앱이 기술 스택 고르다가 죽었다고 했다. 이건 사이드 프로젝트에서 정말 흔한 함정이다.

새로운 기술을 배우는 것과 프로젝트를 완성하는 것은 다른 목표다. 둘 다 가치 있지만, 동시에 하려고 하면 둘 다 실패한다. 새 기술을 배우면서 프로젝트를 만들면, 막히는 지점이 두 배로 늘어난다. 기술적 문제와 기획적 문제가 동시에 나타난다. 그러면 "이거 왜 안 되지?" 하면서 삽질하는 시간이 길어지고, 그 시간이 길어지면 흥미가 식는다.

내가 "오늘 뭐 먹지 결정기"를 만들 때 쓴 기술은 Next.js, Tailwind CSS, Vercel이었다. 전부 회사에서 매일 쓰던 것들이다. 새로 배운 건 하나도 없다. 덕분에 막히는 구간이 거의 없었다. 아이디어에서 배포까지 주말 이틀이면 됐다.

Rust로 CLI 도구를 만들어보고 싶다면 그건 "Rust를 배우겠다"는 목표로 따로 시간을 잡아라. "프로젝트를 완성하겠다"는 목표와 섞지 마라.

디자인에서 멈추지 않기#

개발자가 사이드 프로젝트에서 디자인을 신경 쓰기 시작하면 끝이 없다. 나도 그랬다. 버튼 radius를 4px로 할지 8px로 할지, 컬러 팔레트를 어떻게 잡을지, 폰트는 Pretendard가 나은지 Noto Sans KR이 나은지. 이런 걸로 반나절을 날린 적이 한두 번이 아니다.

shadcn/ui를 발견한 게 전환점이었다. 디자인 시스템을 통째로 가져다 쓸 수 있으니까 "디자인" 단계가 사라졌다. 그냥 컴포넌트를 조합하면 됐다. 못생기진 않고, 일관성 있고, 반응형까지 된다. 완벽하진 않지만 사용자가 불편하지 않을 정도면 충분하다.

사이드 프로젝트에서 디자인은 "나중에 개선하기 가장 쉬운 것" 중 하나다. 기능 구조를 나중에 바꾸는 건 어렵지만, 버튼 색깔을 바꾸는 건 5분이면 된다. 초기에 디자인에 시간을 쏟는 건 투자 대비 효율이 가장 낮은 행동이다.

배포를 먼저 해라#

이건 나한테 가장 효과가 컸던 방법이다.

프로젝트를 시작하면 대부분 이런 순서를 따른다. 기획 → 디자인 → 개발 → 테스트 → 배포. 배포가 맨 마지막에 있다. 그래서 "배포할 만큼 완성되면 올려야지" 하고 계속 미룬다. 그 "완성"은 절대 오지 않는다.

나는 이제 프로젝트를 시작하면 제일 먼저 Vercel에 올린다. npx create-next-app을 치고, GitHub repo 만들고, Vercel에 연결한다. 빈 화면이어도 상관없다. URL이 생긴다. 그 URL이 존재한다는 사실이 심리적으로 완전히 다르다.

"내 프로젝트가 인터넷에 살아 있다"는 감각. 빈 화면이라도 거기에 뭔가를 채워 넣고 싶어진다. git push 한 번이면 바로 반영되니까 "한 줄이라도 더 써서 올려볼까" 하는 마음이 생긴다. 반대로 로컬에서만 돌리고 있으면 "아직 보여줄 단계가 아니야" 하면서 계속 미루게 된다.

배포된 상태에서 시작하면 또 하나 좋은 점이 있다. 배포 관련 삽질을 미리 해결할 수 있다. 환경 변수, 빌드 설정, 도메인 연결 같은 걸 마지막에 하면 "거의 다 만들었는데 배포가 안 돼" 하면서 좌절하는 경우가 있다. 처음부터 배포 상태로 개발하면 이런 문제를 커밋할 때마다 잡을 수 있다.

"이걸 왜 만들고 있지?"#

죽은 프로젝트 중에 하나가 "개발자 북마크 매니저"였다. 브라우저 북마크가 너무 지저분해서 시작한 프로젝트였는데, 만들다 보니까 깨달았다. 나는 북마크를 잘 정리하고 싶은 게 아니라 그냥 브라우저 탭을 너무 많이 여는 게 문제였다. 북마크 매니저를 만든다고 해결되는 게 아니었다.

그 깨달음이 오는 순간 흥미가 뚝 떨어졌다. "이걸 내가 왜 만들고 있지?" 이 질문에 답을 못 하면 프로젝트는 죽는다.

완성한 2개의 프로젝트는 공통점이 있었다. 둘 다 내가 실제로 매일 쓰는 것이었다. 점심 메뉴 결정기는 진짜로 매일 점심에 썼다. 블로그 테마는 지금 이 글을 쓰고 있는 바로 이 사이트다. 내가 쓰니까 불편한 점이 보이고, 불편한 점이 보이니까 고치고 싶고, 고치면 바로 내 삶이 나아진다. 이 피드백 루프가 동기를 유지시킨다.

"포트폴리오에 넣을 프로젝트"를 만들겠다는 동기로 시작하면 높은 확률로 실패한다. 그건 동기가 외부에 있는 거다. 면접관이 볼까? 이력서에 한 줄 추가될까? 그런 불확실한 보상은 밤 11시에 코드를 열게 만들 만큼 강하지 않다. 반면 "이거 없으면 내가 불편하다"는 감각은 강하다. 단순하지만 진짜다.

그래서 지금은#

요즘 새로 만들고 있는 게 하나 있다. 회사 스탠드업 미팅 전에 "어제 뭐 했더라" 하고 git log를 뒤지는 게 귀찮아서, 매일 자동으로 내 커밋 요약을 만들어주는 작은 도구다. 범위는 딱 그것뿐이다. 예쁜 UI도 없다. 터미널에서 돌아가는 스크립트 하나. Vercel 배포 대상도 아니고 그냥 로컬에서 cron으로 돌린다.

근데 매일 아침 쓴다. 그러니까 매일 저녁에 "이 부분 좀 고치면 좋겠는데" 하는 생각이 든다. 그리고 실제로 고친다. 누가 시키지 않아도.

사이드 프로젝트를 완성하는 법은 결국 의지력이 아니다. 의지력으로 되는 건 아무것도 없다. 완성을 가능하게 만드는 환경을 세팅하는 거다. 범위를 줄이고, 마감을 만들고, 아는 기술을 쓰고, 디자인은 빌려오고, 배포를 먼저 하고, 내가 진짜 쓸 걸 만든다. 이 중 하나만 해도 확률이 올라간다. 다 하면 거의 확실하다.

GitHub에 잠들어 있는 repo가 있다면, 지금 열어서 기능 목록의 80%를 지워봐라. 남은 20%로 이번 주 안에 배포할 수 있는지 생각해봐라. 아마 될 거다.