10년차 개발자의 깃허브 무덤에 잠든 27가지 사이드 프로젝트: 진짜 실패 이유는 따로 있었다

얼마 전 깃허브 계정을 열어 비공개 저장소 목록을 훑어봤습니다. 세어보니 정확히 27개더군요. 지난 3년간 만들어두고 결국 세상에 내놓지 못한 채 방치된 사이드 프로젝트들이었습니다.

기계 학습 기반의 습관 추적 앱도 있었고, 강아지 전용 트위터 클론도 있었죠. 어떤 건 복잡한 SaaS 보일러플레이트였는데, 4주 동안 환경 설정에만 매달리다 결국 완전히 포기해버렸습니다. 몇 주씩 공들인 프로젝트도 있었고, 심지어는 도메인까지 구매했던 것도 있었어요.

수백 시간을 허공에 날린 셈입니다. 도대체 왜 이 모든 프로젝트가 빛을 보지 못하고 죽어버렸을까요? 시간 부족 때문도 아니었고, 열정이 부족해서도 아니었습니다.

여기에 논쟁의 여지가 있는 가혹한 진실이 있습니다.

대부분의 개발자가 실패하는 이유는 기술 부족 때문이 아닙니다. 이들은 은밀하게 새로운 프로젝트를 시작할 때의 도파민 분출을 완성하는 고된 과정보다 더 즐기기 때문입니다.

이 부분은 제가 커리어를 시작하고 몇 년간 헤매며 뼈저리게 느꼈던 부분이기도 합니다. 새로운 기술에 대한 갈증과 아이디어에 대한 설렘이 끝까지 가는 끈기를 집어삼키는 경험을 숱하게 했죠.

바로 제가 27개 프로젝트를 죽음으로 몰고 간 정확한 패턴과, 마침내 이 악순환을 끊는 데 도움을 준 규칙을 공유합니다.

1. "완벽 스택" 함정

개발자로서 우리는 반짝이는 새 도구를 사랑합니다. 프로젝트를 시작할 때 가장 먼저 드는 생각은 트위터에서 모두가 떠들어대는 새로운 데이터베이스를 시도해보거나, 최신 베타 버전 프레임워크를 적용해보는 것이죠.

제가 실무에서 토이 프로젝트를 진행할 때도, 꼭 최신 프레임워크와 데이터베이스를 조합하려다가 정작 핵심 비즈니스 로직은 한 줄도 못 쓰는 경험을 여러 번 했습니다. 당시에는 새로운 기술을 익히는 재미가 컸지만, 돌이켜보면 '일단 완성'이라는 목표와는 정반대로 가는 길이었죠.

한번은 Next.js 앱에 tRPC, Prisma, 그리고 커스텀 Tailwind 디자인 시스템까지 조합하느라 주말 내내 매달린 적이 있습니다. 일요일 밤이 되자 인프라는 완벽 그 자체였죠. 하지만 비즈니스 로직은 단 한 줄도 쓰지 못했습니다. 다음 날, 저는 완전히 흥미를 잃어버렸습니다.

정말로 프로젝트를 완성하고 싶다면, "지루한" 기술을 사용해야 합니다. 구식처럼 느껴지더라도, 가장 잘 아는 스택을 선택하세요.

2. 허상 사용자를 위한 최적화

강아지 트위터 클론을 만들 때, 저는 복잡한 Redis 캐싱 레이어를 설정하는 데만 꼬박 3일을 보냈습니다. 첫날 백만 마리의 강아지가 가입하면 서버가 다운될까 봐 전전긍긍했죠.

우리는 과도하게 설계하는 것을 좋아합니다. 데이터베이스가 엄청난 트래픽을 어떻게 처리할지 걱정하며 복잡한 마이크로서비스를 설계하죠. 하지만 냉혹한 현실은 이렇습니다.

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

아직 존재하지 않는 문제에 대비하여 구축하는 것을 멈추세요. 간단한 데이터베이스 쿼리로도 충분합니다. 앱이 실제로 인기를 얻기 시작하면 언제든 최적화할 수 있습니다. 이 부분은 특히나 스타트업의 초기 단계나 MVP 개발 시 제가 팀원들에게 강조하는 내용입니다. '나중에 트래픽이 몰리면 어떡해요?'라는 질문에, '트래픽은 고마운 문제입니다. 일단 사용자가 존재하게 만드는 게 먼저죠.'라고 답하곤 합니다. 불필요한 아키텍처는 개발 속도만 늦출 뿐입니다.

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-17 01:50:32