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

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

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

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

솔직히 이건 예상 밖이었습니다. 저는 스스로 실용적인 사람이라고 생각했거든요. 그런데 막상 돌아보니 개발자 커뮤니티 플랫폼, 독서 기록 앱, 기술 면접 준비 서비스, 가계부 API까지 모두 같은 함정에 빠져 있었습니다. 기능 목록은 계속 늘어났고, 실제 배포 일정은 계속 뒤로 밀렸습니다.

사이드 프로젝트가 실패하는 이유를 분석한 설문에서도 비슷한 결과가 나왔습니다. 스코프 크리프(Scope Creep) 문제가 실패 원인 1위로 꼽혔습니다(출처: Indie Hackers). 스코프 크리프란 프로젝트 초기 기획보다 범위가 점점 늘어나면서 결국 감당할 수 없는 크기가 되는 현상을 말합니다. 기능을 하나 추가할 때마다 '이것도 있어야 해'라는 생각이 꼬리를 물고, 어느 순간 혼자 감당하기 어려운 규모가 되어 있는 것입니다. 제 열두 개 프로젝트가 정확히 이 경로를 밟았습니다.

그 시절 제가 얼마나 비효율적이었는지 생각하면 지금도 아찔합니다. 실제 사용자가 원하는 것은 확인도 안 한 채, 아무도 쓰지 않을 서비스의 코드 품질을 끌어올리는 데 주말을 쏟아붓고 있었으니까요.

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

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

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

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

2주 안에 배포를 끝내고 나서 저는 처음으로 실제 사용자의 피드백을 받았습니다. 제가 중요하다고 생각한 기능은 아무도 쓰지 않았고, 부가 기능으로 넣은 것이 오히려 가장 많이 쓰이는 기능이 됐습니다. 1년 넘게 혼자 상상 속에서 설계했다면 절대 알 수 없었을 정보였습니다.

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

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

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

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

딥 워크(Deep Work) 개념을 연구한 결과에서도 인간은 외부 압박이 없는 환경에서 고도의 집중 작업을 지속하기 어렵다는 점이 지적됩니다(출처: Cal Newport, "Deep Work" - calnewport.com). 혼자서 완성도 높은 작업을 지속하려면 그에 상응하는 구조적 장치가 필요한 것입니다.

열세 번째 프로젝트가 이전 열두 개와 달랐던 핵심 차이를 정리하면 다음과 같습니다.

• 기능을 딱 하나로 제한하고 나머지는 배포 후로 미룬 것
• 2주라는 구체적인 기한을 설정하고 공개적으로 선언한 것
• 코드 품질이 아닌 '누군가가 실제로 쓰는가'를 성공 기준으로 삼은 것
• 완성 후 실제 사용자 피드백을 기다린 것 (추측이 아닌 데이터로 방향을 수정)

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

---

참고:
Cal Newport, "Deep Work", calnewport.com
Jason Fried & DHH, "Rework", 37signals.com
Paul Graham, "Schlep Blindness", paulgraham.com/schlep.html
Indie Hackers, "Why Do Side Projects Fail?", indiehackers.com
Peter Skillman Marshmallow Challenge, tomwujec.com/marshmallowchallenge