사이드 프로젝트 완성법-완성의 정의, MVP, 외부 압박

10년 동안 열두 개의 사이드 프로젝트를 시작하고 단 한 개도 완성하지 못했습니다. 직접 손가락으로 세어봤을 때 저도 순간 멍했습니다. 왜 이렇게 많은 프로젝트가 README.md만 남긴 채 깃허브 어딘가에 잠들어 있는지, 그 이유를 찾는 데 생각보다 오래 걸렸습니다. 원인은 의지력이나 시간이 아니었습니다. '완성의 정의'가 없었던 것이었습니다.

솔직히 이 사실이 처음엔 받아들이기 어려웠습니다. 나름 10년간 개발자로 살아왔고, 스스로 꽤 실용적이라고 믿어왔으니까요. 그런데 열두 개의 잔해를 하나씩 들여다보니, 전부 같은 방식으로 죽어 있었습니다. 잘 쓴 README, 세심하게 설계한 DB 스키마, 아무도 쓰지 않을 기능 목록들. 완성되지 않은 것들이 공통적으로 가진 건 '시작의 흔적'뿐이었고, '끝의 정의'는 어디에도 없었습니다.

열두 번의 실패가 가르쳐준 것

실패한 프로젝트들에는 공통된 패턴이 있었습니다. 기술 스택 선정에만 2주를 쓰고, 데이터베이스 스키마 설계에 또 1주를 소비하다가 동력을 잃는 흐름이 반복됐습니다. 기술 스택이란 서비스를 구축할 때 사용하는 프로그래밍 언어, 프레임워크, 데이터베이스, 서버 환경 등 기술적 구성 요소의 조합을 말합니다. 아직 사용자 한 명도 없는 서비스의 기술 조합을 고르는 데 에너지를 쏟아붓고 있었던 셈입니다.

개발자 커뮤니티 플랫폼, 독서 기록 앱, 기술 면접 준비 서비스, 가계부 API까지 모두 같은 함정에 빠져 있었습니다. 기능 목록은 계속 늘어났고, 실제 배포 일정은 계속 뒤로 밀렸습니다. 사이드 프로젝트가 실패하는 이유를 분석한 설문에서 스코프 크리프 문제가 실패 원인 1위로 꼽혔다는 것도 지금 생각하면 당연합니다. 스코프 크리프란 프로젝트 초기 기획보다 범위가 점점 늘어나면서 결국 감당할 수 없는 크기가 되는 현상입니다. 기능을 하나 추가할 때마다 '이것도 있어야 해'라는 생각이 꼬리를 물고, 어느 순간 혼자 감당하기 어려운 규모가 되어 있는 것이죠.

제가 이 패턴을 가장 잘 보여주는 프로젝트가 하나 있습니다. 개발자 커뮤니티 플랫폼이었는데, 초기 아이디어는 단순했습니다. "개발자들이 질문을 올리고 답변을 받는 곳." 그런데 기획 단계에서 어느새 태그 기능, 팔로우 기능, 북마크, 추천 알고리즘, 다크모드까지 들어갔습니다. 코드 한 줄도 짜기 전에 스코프가 스택오버플로우 수준이 되어 있었습니다. 결국 DB 설계를 마친 뒤 단 한 번도 실행되지 않은 채 저장소에 남아 있습니다. 그 프로젝트를 보면 지금도 좀 씁쓸합니다.

실제 사용자가 원하는 것은 확인도 안 한 채, 아무도 쓰지 않을 서비스의 코드 품질을 끌어올리는 데 주말을 쏟아붓고 있었으니 말입니다. 지금 돌아보면 그 열두 개의 프로젝트가 가르쳐준 공통된 교훈은 하나입니다. 완성되지 않은 코드는 존재하지 않는 것과 같습니다. 아무리 정교하게 설계된 스키마도, 실행되지 않은 순간 그것은 그냥 텍스트 파일입니다.

MVP를 2주 안에 배포하는 것의 의미

열세 번째 프로젝트에서 저는 방식을 완전히 바꿨습니다. 핵심은 MVP(Minimum Viable Product) 개념을 진지하게 적용한 것이었습니다. MVP란 최소한의 핵심 기능만 갖춰 실제 사용자에게 가장 빠르게 선보일 수 있는 제품을 의미합니다. '최소 기능 제품'이라고도 번역하지만, 핵심은 '완성된 것을 작게'가 아니라 '핵심 하나만 먼저'입니다.

많은 분들이 MVP를 만든다고 하면서도 결국 기능을 열 개 넣습니다. 저도 처음엔 그랬으니까요. 이번엔 달랐습니다. 기능을 딱 하나만 잡았고, 2주 안에 배포하겠다는 목표를 지인 다섯 명에게 미리 공표했습니다. 이것이 결정적인 차이였습니다.

여기서 한 가지 솔직한 비판을 덧붙이고 싶습니다. "MVP를 빠르게"라는 말은 이제 너무 흔해져서 오히려 공허하게 들리기 시작했습니다. 스타트업 씬에서는 MVP가 마치 마법 주문처럼 쓰이는데, 실제로 많은 팀이 MVP라는 이름을 붙인 반쯤 완성된 제품을 출시하고 "우리는 빠르게 움직였다"고 위안을 삼습니다. 그런데 제가 경험한 MVP의 핵심은 속도 자체가 아니라, '내가 틀릴 수 있다는 가능성을 빨리 확인하는 것'이었습니다. 이 마음가짐이 없으면 MVP도 그냥 작은 규모의 폭포수 개발에 불과합니다.

프로토타이핑의 중요성을 연구한 사례들을 보면, 완성도를 높이는 것보다 빠르게 실제 환경에 내놓는 것이 장기적으로 훨씬 나은 결과를 만든다는 점이 반복적으로 확인됩니다. 프로토타이핑이란 최종 제품을 만들기 전에 간단한 시제품을 만들어 빠르게 검증하는 과정을 뜻합니다. 코드가 엉성해도 배포된 서비스가 아무리 정교한 미완성 코드보다 훨씬 많은 것을 가르쳐준다는 말이 단순한 격언이 아니라는 것을 몸으로 알게 됐습니다.

2주 안에 배포를 끝내고 나서 저는 처음으로 실제 사용자의 피드백을 받았습니다. 제가 중요하다고 생각한 기능은 아무도 쓰지 않았고, 부가 기능으로 넣은 것이 오히려 가장 많이 쓰이는 기능이 됐습니다. 1년 넘게 혼자 상상 속에서 설계했다면 절대 알 수 없었을 정보였습니다. 이 경험이 꽤 강렬했습니다. '내가 중요하다고 생각한 것'과 '사용자가 실제로 원하는 것' 사이의 간격이 그렇게 크다는 사실을 숫자로 확인하는 건, 이론으로 아는 것과 완전히 다른 충격입니다.

개발자들이 사이드 프로젝트에서 특히 이 함정에 빠지기 쉬운 이유가 있다고 생각합니다. 우리는 직업상 "완성도"를 높이는 훈련을 받았습니다. 프로덕션에 버그를 올리면 안 되고, 코드리뷰를 통과해야 하고, 테스트를 써야 합니다. 그 기준이 사이드 프로젝트에도 그대로 적용되면 배포 자체가 영원히 미뤄집니다. 사이드 프로젝트에서만큼은 그 기준을 의식적으로 낮춰야 합니다. 버그가 있어도 배포되어야 배웁니다.

외부 압박이 없으면 혼자는 멈춘다

제 경험상 사이드 프로젝트 실패의 가장 조용하고 치명적인 원인은 '혼자 한다'는 구조 자체입니다. 혼자 하면 데드라인이 없습니다. 데드라인이란 프로젝트나 작업을 반드시 완료해야 하는 최종 기한을 뜻합니다. 이 기한이 없으면 슬럼프가 왔을 때 그냥 멈춰도 아무 일도 일어나지 않습니다. 저는 열두 번 그렇게 멈췄습니다.

사이드 프로젝트가 완성되지 않는 이유를 의지력 부족이나 시간 부족으로 설명하는 경우가 많은데, 저는 그것이 표면적인 진단이라고 생각합니다. 진짜 문제는 책임 구조입니다. 직장 업무는 완성하지 않으면 동료와 상사에게 영향이 가기 때문에 어떻게든 끝냅니다. 사이드 프로젝트는 완성하지 않아도 아무도 모릅니다.

이 지점에서 저는 의지력 신화에 대해 꽤 비판적인 입장입니다. 자기계발 콘텐츠 상당수가 "루틴을 만들어라", "작은 습관을 쌓아라"를 외치는데, 이 조언들이 틀린 건 아니지만 혼자서 장기 프로젝트를 유지하는 문제를 개인의 의지 프레임으로 접근하는 건 처방이 틀린 경우가 많습니다. 사람은 관계 속에서, 사회적 맥락 속에서 동기를 유지합니다. 그것이 인간의 기본 설계에 가깝습니다. 의지력이 약한 게 아니라 구조가 잘못된 겁니다.

열세 번째 프로젝트에서 지인 다섯 명에게 공표한 행동은 단순한 선언이 아니었습니다. 사회적 책임(Accountability)을 인위적으로 만든 것이었습니다. 어카운터빌리티란 자신의 행동과 결과에 대해 타인에게 설명하고 책임질 의무를 지는 상태를 말합니다. 이 구조가 생기자 슬럼프가 와도 그냥 멈출 수가 없었습니다. 창피함이 동기를 대신해줬습니다.

딥 워크 개념을 연구한 결과에서도 인간은 외부 압박이 없는 환경에서 고도의 집중 작업을 지속하기 어렵다는 점이 지적됩니다. 혼자서 완성도 높은 작업을 지속하려면 그에 상응하는 구조적 장치가 필요한 것입니다. 저는 이 구조를 인공적으로라도 만드는 것이 의지력을 키우는 것보다 훨씬 현실적인 방법이라고 봅니다.

한 가지 더 덧붙이면, 공표의 대상이 중요합니다. 아무에게나 말하는 것보다, 내가 실망시키기 싫은 사람에게 말하는 게 압박이 훨씬 강합니다. 저는 평소에 제가 존경하는 개발자 커뮤니티 멤버들에게 공표했고, 그 사람들 앞에서 실패하고 싶지 않다는 감정이 실제로 작동했습니다. 이건 자존심의 문제가 아니라, 인간이 사회적 동물이라는 사실을 활용한 겁니다.

열세 번째 프로젝트가 이전 열두 개와 달랐던 핵심 차이는 간단합니다. 기능을 딱 하나로 제한하고 나머지는 배포 후로 미뤘습니다. 2주라는 구체적인 기한을 설정하고 공개적으로 선언했습니다. 코드 품질이 아닌 '누군가가 실제로 쓰는가'를 성공 기준으로 삼았습니다. 완성 후 실제 사용자 피드백을 기다렸고, 추측이 아닌 데이터로 방향을 수정했습니다.

사이드 프로젝트를 완성하고 싶다면, 지금 당장 기능 목록을 하나로 줄이고 배포 기한을 누군가에게 말해보시길 권합니다. 기술이 부족해서 실패하는 경우는 생각보다 많지 않습니다. 범위를 정의하지 않아서, 끝을 선언하지 않아서 실패하는 경우가 훨씬 많습니다. 저는 열두 번 실패한 후에야 그것을 알았지만, 이 글을 읽는 분은 조금 더 일찍 알아도 됩니다.

---

참고: Cal Newport, "Deep Work" / Jason Fried & DHH, "Rework" / Paul Graham, "Schlep Blindness" / Indie Hackers, "Why Do Side Projects Fail?" / Peter Skillman Marshmallow Challenge