깃허브 무덤에 묻힌 27개 프로젝트, 제가 깨달은 개발의 '잔혹한 진실'

최근 제 깃허브 계정을 열어 비공개 레포지토리만 걸러내 보니, 지난 3년간 만든 사이드 프로젝트들이 정확히 27개나 되더군요. 그 모든 프로젝트들이 말 그대로 '버려진' 상태였습니다. 한참을 스크롤 내리며 과거의 열정을 회상했지만, 동시에 밀려오는 씁쓸함도 지울 수 없었습니다.

머신러닝 기반의 습관 추적 앱도 있었고, 강아지용 트위터 클론도 만들었었죠. 심지어 4주 내내 설정만 붙잡고 씨름하다 결국 포기해버린 복잡한 SaaS 보일러플레이트도 있었습니다. 어떤 프로젝트에는 정말 몇 주씩 시간을 쏟아부었고, 심지어 특정 프로젝트를 위해 도메인까지 구매했던 기억이 납니다.

수백 시간에 달하는 제 노력이 그렇게 허공으로 사라진 겁니다. 왜 이 프로젝트들은 단 하나도 세상의 빛을 보지 못하고 죽어버렸을까요? 시간 부족 때문은 아니었습니다. 의욕이 없어서도 아니었죠.

여기, 개발자들이 쉽사리 인정하지 않으려는 논란의 여지가 있는 진실이 있습니다.

대부분의 개발자가 실패하는 이유는 실력 부족 때문이 아닙니다. 이들은 '완성'이라는 지루한 과정을 겪기보다, '시작'이라는 새로운 프로젝트에서 오는 도파민 러시를 은밀히 더 즐기기 때문입니다.

제 27개 프로젝트를 죽음으로 몰아넣은 치명적인 패턴과, 그 지긋지긋한 악순환을 마침내 끊어낼 수 있게 도와준 한 가지 규칙을 지금부터 이야기해드리겠습니다.

1. '완벽한 스택' 함정

개발자라면 누구나 반짝이는 새 툴에 대한 갈증이 있습니다. 새로운 프로젝트를 시작할 때, 트위터에서 뜨거운 감자로 떠오른 최신 데이터베이스나 이제 막 베타 버전을 공개한 프레임워크를 시험해보고 싶은 충동을 느끼는 건 어쩌면 당연한 일이죠.

저도 한때 Next.js 앱에 tRPC, Prisma, 그리고 커스텀 Tailwind 디자인 시스템까지 엮어서 주말 내내 설정만 붙잡고 있었던 적이 있습니다. 일요일 밤이 되자 인프라는 그야말로 완벽 그 자체였죠. 하지만 정작 비즈니스 로직은 단 한 줄도 작성하지 못했습니다. 그리고 다음 날, 그 프로젝트에 대한 흥미를 완전히 잃어버렸습니다. 제가 실무에서 이 부분을 테스트해 봤을 때, 익숙하고 안정적인 기술 스택을 고집하는 것이 결국 프로젝트 완성도를 높이는 데 훨씬 효과적이라는 걸 깨달았습니다.

프로젝트를 정말 끝내고 싶다면, '지루한' 기술을 사용해야 합니다. 아무리 구식처럼 느껴져도, 가장 잘 알고 있는 스택을 선택하세요. 새로운 기술 학습은 그 다음입니다.

2. 환상의 사용자에게 최적화하기

강아지용 트위터 클론을 만들 때, 저는 무려 사흘 동안 복잡한 Redis 캐싱 레이어를 구축하는 데 시간을 보냈습니다. 만약 첫날에 백만 마리의 강아지가 한꺼번에 가입해서 서버가 터질까 봐 지레 겁먹었던 거죠.

우리 개발자들은 과도한 설계를 좋아하는 경향이 있습니다. 데이터베이스가 대규모 트래픽을 어떻게 처리할지 걱정하며 복잡한 마이크로서비스 아키텍처를 설계하곤 하죠. 하지만 잔혹한 현실은 이렇습니다. 저 역시 초기에는 '혹시나 대박 나면 어쩌지?' 하는 걱정에 불필요한 고도화를 시도한 적이 많았지만, 결국 그 시간이 코어 기능 개발을 지연시키는 독이 되더군요.

여러분의 가장 큰 위협은 서버가 다운되는 것이 아닙니다. 아무도 여러분의 사이트에 방문하지 않을 것이라는 현실이 가장 큰 위협입니다.

아직 발생하지 않은 문제에 대비해 코드를 짜는 일을 멈추세요. 간단한 데이터베이스 쿼리로도 충분합니다. 앱이 실제로 인기를 얻기 시작하면 그때 가서 얼마든지 최적화할 수 있습니다.

3. 기능 확장증은 질병입니다

이것은 아주 순진하게 시작됩니다. 간단한 투두 리스트를 만들고 있는데, '사용자가 커스텀 프로필 사진을 업로드할 수 있으면 멋질 텐데?'라는 생각이 듭니다. 순식간에 핵심 작업 로직을 끝내는 대신, AWS S3 문서를 5시간 동안 읽고 있는 자신을 발견하게 되죠.

기능은 꿈꾸기에는 즐겁지만, 실제로 구현하기에는 무겁습니다. 제가 실무에서 가장 많이 경험했던 함정이 바로 이 '그놈의 이것만 추가하면...'이라는 생각이었습니다. 모든 추가 버튼은 출시를 지연시킬 뿐입니다. 프로젝트를 끝내는 가장 좋은 방법은 기능을 잔혹하게 잘라내서 최소 기능 제품(MVP)만 남기는 것입니다. 핵심 문제를 해결하지 못한다면, 가차 없이 삭제해야 합니다.

4. 배포의 공포

코드를 작성하는 것은 안전합니다. VS Code 에디터는 당신을 비난하지 않으니까요. 하지만 프로젝트를 출시한다는 것은 실제 사람들이 그 앱을 보게 될 수도 있고, 버그를 찾아낼 수도 있고, 최악의 경우 완전히 무시해버릴 수도 있다는 것을 의미합니다.

수많은 사이드 프로젝트가 90% 완성 지점에서 버려집니다. 개발자들이 은밀하게 배포 버튼을 누르는 것을 두려워하기 때문이죠. 우리는 '조금만 더 다듬으면 돼'라는 핑계 뒤에 숨어버립니다. 솔직히 말씀드리면, 제가 처음으로 사이드 프로젝트를 배포할 때도 온갖 핑계를 대며 미뤘던 기억이 납니다. 완벽하지 않아도 일단 세상에 내놓는 용기가 정말 중요하더라고요.

버그투성이이고 못생겼더라도 인터넷에 공개된 앱은, 로컬호스트에 완벽하게 잠자고 있는 앱보다 무한히 더 가치가 있습니다.

48시간 규칙

이 저주를 깨기 위해 저는 스스로에게 엄격한 새 규칙을 만들었습니다. 바로 **"48시간 안에 작동하는, 못생긴 프로토타입을 출시해야 한다"**는 것입니다.

핵심 기능을 라이브로 만드는 데 주말 한 번 이상이 걸린다면, 그것은 너무 큰 범위의 프로젝트입니다. 이 간단한 사고방식의 전환은 제가 깃허브 무덤만 쌓는 대신, 실제로 앱을 출시하기 시작한 가장 큰 이유 중 하나입니다.

이제 여러분 차례입니다

저만 수많은 '죽은 아이디어'들로 가득 찬 깃허브 무덤을 가지고 있는 게 아니라는 걸 잘 알고 있습니다.

솔직하게 말씀해주세요. 여러분은 어떤 가장 이상한 사이드 프로젝트를 시작했다가 포기하셨나요? 그리고 그것을 중단한 '진짜' 이유는 무엇이었나요?

댓글로 여러분의 깃허브 무덤에 무엇이 잠들어 있는지 알려주세요.

원문: https://dev.to/tahosin/my-github-graveyard-has-27-dead-projects-here-is-the-brutal-truth-about-why-52d9 수집일: 2026-05-15 01:53:00