My GitHub Graveyard has 27 dead projects. Here is the brutal truth about why.
I recently opened my GitHub account and filtered by private repositories. I actually counted them:...
최근 GitHub 계정을 열고 비공개 저장소를 필터링해봤다. 실제로 세어보니 정확히 27개의 방치된 사이드 프로젝트가 있었다. 지난 3년간 만들어진 것들이다.
머신러닝 기반 습관 트래커가 있었다. 강아지용 Twitter 클론도 있었다. 포기하기까지 4주를 꼬박 설정에 쏟아부은 복잡한 SaaS 보일러플레이트도 있었다. 몇 주씩 시간을 쏟은 것들도 있고, 심지어 도메인까지 산 프로젝트도 하나 있었다.
수백 시간이 허공에 사라졌다. 왜 전부 세상의 빛을 보지 못하고 죽었을까? 시간 부족 때문이 아니었다. 의욕 부족 때문도 아니었다.
좀 불편할 수 있는 진실을 말하겠다.
대부분의 개발자는 실력 부족으로 실패하지 않는다. 새 프로젝트를 시작하는 도파민 rush가 프로젝트를 완성하는 고된 과정보다 더 달콤하다는 사실을 스스로 인정하지 못해서 실패한다.
27개의 프로젝트를 죽인 정확한 패턴과, 마침내 그 사이클을 끊어준 법칙을 소개한다.
1. "완벽한 스택" 함정 (The "Perfect Stack" Trap) #
개발자는 반짝이는 새 도구를 사랑한다. 프로젝트를 시작할 때 첫 번째 본능은 Twitter에서 모두가 이야기하는 새 데이터베이스나 프레임워크의 최신 베타 버전을 써보는 것이다.
한번은 tRPC, Prisma, 커스텀 Tailwind 디자인 시스템을 조합한 Next.js 앱을 설정하는 데 주말 전체를 쏟았다. 일요일 밤, 인프라는 완벽 그 자체였다. 그러나 비즈니스 로직은 한 줄도 작성되지 않았다. 다음 날, 흥미가 완전히 사라졌다.
프로젝트를 실제로 끝내고 싶다면 지루한 기술을 써야 한다. 설령 낡아 보이더라도, 자신이 가장 잘 아는 스택을 선택해라.
2. 유령 사용자를 위한 최적화 (Optimizing for Phantom Users) #
강아지용 Twitter 클론 프로젝트에서는 복잡한 Redis 캐싱 레이어를 구축하는 데 3일을 썼다. 첫날 백만 마리의 강아지가 가입하면 서버가 다운될까봐 두려웠던 것이다.
과도한 엔지니어링의 유혹은 늘 있다. 데이터베이스가 대규모 트래픽을 감당할 수 있을지 걱정하며 복잡한 마이크로서비스를 설계한다. 하지만 현실은 냉정하다.
가장 큰 위협은 서버 다운이 아니다. 아무도 사이트를 방문하지 않는 것이 가장 큰 위협이다.
아직 존재하지 않는 문제를 위해 개발하는 것을 멈춰라. 단순한 데이터베이스 쿼리로 충분하다. 앱이 실제로 트랙션을 얻으면 그때 최적화하면 된다.
3. 기능 크리프는 병이다 (Feature Creep is a Disease) #
처음엔 무해하게 시작된다. 단순한 할 일 목록을 만들다가 "사용자가 프로필 사진을 업로드할 수 있으면 멋지겠다"고 생각한다. 그 순간 핵심 태스크 로직을 완성하는 대신 5시간 동안 AWS S3 문서를 읽고 있는 자신을 발견하게 된다.
기능은 꿈꾸기엔 즐겁지만 만들기엔 무겁다. 추가하는 버튼 하나하나가 런칭을 늦춘다. 프로젝트를 끝내는 가장 좋은 방법은 절대적인 최소 기능 제품(MVP)만 남을 때까지 무자비하게 기능을 잘라내는 것이다. 핵심 문제를 해결하지 않으면 삭제한다.
4. 출시에 대한 두려움 (The Fear of Shipping) #
코드를 작성하는 것은 안전하다. VS Code 에디터는 당신을 심판하지 않는다. 그러나 프로젝트를 런칭한다는 것은 실제 사람들이 그것을 보고, 버그를 발견하거나, 더 나쁘게는 완전히 무시할 수 있다는 의미다.
많은 사이드 프로젝트가 90% 완성 시점에서 방치된다. 배포 버튼을 누르는 것을 은근히 두려워하기 때문이다. "조금만 더 다듬으면 돼"라는 핑계 뒤에 숨는다.
인터넷에 살아있는 버그 많고 못생긴 앱은, localhost에 앉아 있는 완벽한 앱보다 무한히 더 가치 있다.
48시간 규칙 (The 48-Hour Rule) #
이 저주를 깨기 위해 스스로에게 엄격한 규칙을 만들었다. 48시간 안에 작동하는, 못생긴 프로토타입을 런칭해야 한다.
주말 하나로 핵심 기능을 라이브 상태로 올릴 수 없다면, 범위가 너무 큰 것이다. 이 단순한 사고방식의 전환이 묘지만 키우는 대신 실제 앱을 출시하기 시작한 가장 큰 이유 중 하나다.
Photo by Meruyert Gonullu on Pexels
독자에게 (Over to you) #
GitHub에 죽은 아이디어들의 묘지를 가진 사람이 나뿐만은 아닐 것이다.
솔직하게 말해보자. 지금까지 시작한 가장 이상한 방치 프로젝트는 무엇인가? 그리고 작업을 멈춘 진짜 이유는 무엇인가?
당신의 묘지엔 무엇이 잠들어 있는가?
이 글은 위 출처의 내용을 바탕으로 작성된 초안입니다. 원문의 의견과 정보를 그대로 전달하며, 별도의 견해를 포함하지 않습니다.