사이드 프로젝트2 사이드 프로젝트 완성법-완성의 정의, MVP, 외부 압박 10년 동안 열두 개의 사이드 프로젝트를 시작하고 단 한 개도 완성하지 못했습니다. 직접 손가락으로 세어봤을 때 저도 순간 멍했습니다. 왜 이렇게 많은 프로젝트가 README.md만 남긴 채 깃허브 어딘가에 잠들어 있는지, 그 이유를 찾는 데 생각보다 오래 걸렸습니다. 원인은 의지력이나 시간이 아니었습니다. '완성의 정의'가 없었던 것이었습니다.솔직히 이 사실이 처음엔 받아들이기 어려웠습니다. 나름 10년간 개발자로 살아왔고, 스스로 꽤 실용적이라고 믿어왔으니까요. 그런데 열두 개의 잔해를 하나씩 들여다보니, 전부 같은 방식으로 죽어 있었습니다. 잘 쓴 README, 세심하게 설계한 DB 스키마, 아무도 쓰지 않을 기능 목록들. 완성되지 않은 것들이 공통적으로 가진 건 '시작의 흔적'뿐이었고, '끝의 정.. 2026. 6. 4. 솔로 풀스택 완성법 (완성 기준, 기술 스택, AI 협업) 사이드 프로젝트 공동묘지라는 말이 있습니다. GitHub 레포를 열어보면 마지막 커밋이 "initial commit"인 레포가 줄지어 있는 그곳입니다. 저도 그 묘지에 묻힌 프로젝트가 몇 개인지 세는 게 민망할 정도입니다. 그런데 어느 시점에 처음으로 배포까지 마치고, 유료 사용자까지 얻었습니다. 달라진 건 기술이 아니라, 딱 두 가지였습니다.완성 기준을 바꾸면 프로젝트 범위가 80% 줄어듭니다솔직히 이건 예상 밖이었습니다. 제가 오래 붙잡고 있던 가장 큰 문제는 기술 부채나 시간 부족이 아니었습니다. '완성'이 무엇인지에 대한 정의가 잘못돼 있었습니다.예전에 저는 완성을 기획서에 적힌 모든 기능이 구현된 상태로 봤습니다. 그러니 끝이 없었습니다. 기능 하나를 만들면 두 개가 더 떠올랐고, 데이터 모델링.. 2026. 5. 26. 이전 1 다음
