사이드 프로젝트의 8할은 죽는다 — 살아남은 두 가지

솔직히 말하면 우리가 시작했다가 멈춘 사이드 프로젝트가 살아남은 것보다 훨씬 많다. 노션에 기획서까지 쓴 것도 있고, 도메인을 사둔 것도 있고, 첫 커밋을 올리고 멈춘 저장소도 있다. 좋은 아이디어였다고 생각했는데 왜 안 됐을까, 반대로 살아남은 두 개는 뭐가 달랐을까. 시간이 지나서 돌아보니 패턴이 보이기 시작했다.

죽은 프로젝트들의 공통점

대부분의 죽은 프로젝트는 “있으면 좋겠다”에서 시작했다. 이 서비스가 있으면 불편한 게 해결되지 않을까, 이런 도구를 만들면 사람들이 쓸 것 같다. 가설이 검증되지 않은 상태에서 구현을 시작했다.

또 하나의 공통점은 “완성되면 시작하자” 마인드였다. MVP를 만들면 오픈하고, 오픈하면 피드백을 받고, 피드백을 받으면 개선하는 흐름이 아니라 — 완성되었다고 느껴지는 시점까지 외부와 단절된 상태로 만들었다. 그 완성의 기준이 계속 높아지고, 결국 열지 못했다.

번아웃도 원인이었다. 본업이 바쁜 시기에 사이드 프로젝트까지 끌고 가는 것은 쉽지 않다. 잠깐 멈추면 다시 시작하기까지의 심리적 장벽이 생각보다 높다.

살아남은 두 가지의 공통점

살아남은 두 프로젝트는 처음부터 실사용자가 있었다. 하나는 팀 내부에서 실제로 쓰기 시작한 도구였고, 다른 하나는 아는 사람 몇 명이 실제로 써달라는 요청에서 시작했다. “있으면 좋겠다”가 아니라 “지금 당장 필요하다”에서 출발했다.

그리고 두 프로젝트 모두 처음 버전이 정말 작았다. 기능이 세 개 이하였다. 부족함이 많았지만 실제 사용자가 쓸 수 있는 상태로 일찍 배포했다. 피드백이 오면 그게 다음 작업의 우선순위가 됐다. 방향을 잃지 않았다.

규모의 문제

돌아보면 살아남은 프로젝트들은 작게 유지됐다. 기능을 계속 추가하지 않았다. 핵심 기능 몇 가지를 안정적으로 유지하는 것이 목표였다. 사이드 프로젝트에서 “확장”을 목표로 하면 본업과 동일한 부담이 생긴다. 작게 유지하면 관리 비용이 낮아지고, 바쁜 시기에도 최소한의 노력으로 유지할 수 있다.

8할이 죽는다는 것이 나쁜 것은 아니다. 시도 자체에서 배우는 것이 있고, 죽은 프로젝트에서 쓴 코드나 배운 것이 다른 곳에 쓰이기도 한다. 다만 처음부터 작게, 실제 사용자와 함께 시작하는 것이 살아남을 확률을 높인다는 것은 분명히 배웠다.

— by slecs