GitHub 프로필 페이지에서 contributions 그래프를 보면, 간간이 초록색이 짙어지는 시기가 있다. 사이드 프로젝트를 시작한 시기다. 그리고 그 짙은 초록색은 대부분 2~3주 만에 다시 옅어진다. 프로젝트가 죽은 시기다.

나만 그런 줄 알았는데, 개발자 모임에서 이 얘기를 꺼내면 다들 고개를 끄덕인다. "나도 그래", "나도 private repo에 시체가 5개 있어." 사이드 프로젝트를 시작하는 개발자는 많은데, 끝까지 완성하는 개발자는 극소수다.

왜 그럴까. 보통 "시간이 없어서"라고 말한다. 근데 시간이 진짜 이유일까?

시간 부족은 핑계다#

불편한 말이지만, 대부분의 경우 시간이 없는 게 아니라 우선순위에서 밀리는 거다.

넷플릭스 볼 시간은 있다. 유튜브로 기술 영상 볼 시간도 있다. 트위터에서 개발자들 글을 읽을 시간도 있다. 주말에 늦잠 잘 시간도 있다. 이것들이 나쁘다는 게 아니다. 쉬는 건 필요하다. 근데 "시간이 없어서 사이드 프로젝트를 못 한다"는 정확한 표현이 아니다. "다른 것에 시간을 쓰고 싶어서 사이드 프로젝트를 안 한다"가 더 정확하다.

이렇게 말하면 약간 공격적으로 느껴질 수 있다. 근데 이걸 인정하는 게 첫 번째 단계다. 시간이 없다고 생각하면 해결책이 "시간을 더 확보하자"가 되는데, 이건 거의 불가능하다. 하루는 24시간이고 회사 일은 줄지 않는다. 반면 "우선순위에서 밀린다"고 인정하면 해결책이 달라진다. "어떻게 하면 사이드 프로젝트의 우선순위를 올릴 수 있을까?"가 된다.

그리고 솔직히, 정말로 시간이 없어서 못 하는 사람도 있다. 야근이 일상이거나, 육아를 하거나, 건강 문제가 있거나. 이런 상황이라면 사이드 프로젝트를 못 하는 게 당연하고 무리하면 안 된다. 이 글은 "시간이 있는데 왜 안 되지?"를 고민하는 사람을 위한 거다.

제약이 없으면 끝나지 않는다#

사이드 프로젝트가 실패하는 진짜 이유 중 하나는 제약의 부재다.

회사에서 일할 때를 생각해보자. 스프린트 기간이 정해져 있고, 기획서가 있고, 디자인이 나와 있고, 데드라인이 있다. 이 제약 안에서 일한다. 불편하지만 일이 된다. 스프린트 마지막 날에는 어떻게든 끝내서 PR을 올린다.

사이드 프로젝트에는 이런 제약이 없다. 데드라인이 없다. 기획서도 없다. 디자인도 내 맘대로다. 기능 범위도 내가 정한다. 이 자유가 독이 된다.

데드라인이 없으니까 "다음 주에 하지 뭐"가 된다. 기획이 없으니까 만들면서 "이 기능도 넣을까? 저 기능도 넣을까?" 범위가 끝없이 늘어난다. 디자인이 내 맘대로니까 "좀 더 예쁘게 만들고 나서 공개하자"가 된다. 이 "좀 더"가 끝나지 않는다.

Derek Sivers가 "Restrictions will set you free"라고 했다. 제약이 자유를 준다는 역설적인 말인데, 사이드 프로젝트에서 이게 정확히 들어맞는다. 제약이 있어야 결정을 내릴 수 있고, 결정을 내려야 진행이 된다.

내가 유일하게 완성한 사이드 프로젝트에서 했던 건, 인위적으로 제약을 건 거였다. "2주 안에 배포한다." "기능은 3개까지만." "디자인은 shadcn/ui 기본 스타일 그대로." 이 제약 덕분에 범위가 자연스럽게 좁아졌고, 2주 만에 실제로 배포했다.

사용자 없는 프로젝트는 피드백도 없다#

두 번째 이유. 혼자 만들고, 혼자 쓰고, 혼자 판단하는 구조.

사이드 프로젝트를 공개하지 않으면, 피드백 루프가 아예 없다. 내가 만든 게 좋은 건지 나쁜 건지, 방향이 맞는 건지 틀린 건지를 알 수 없다. 그러면 두 가지 중 하나가 일어난다. 자기 기준으로 "아직 부족하다"고 판단하고 계속 손을 대거나, 흥미를 잃고 손을 놓거나.

어느 쪽이든 결과는 같다. 프로젝트가 세상에 나오지 못한다.

Seth Godin이 강조하는 것 중 하나가 "문제를 정의하라"는 거다. 해결할 수 있는 문제인지, 그냥 상황인지를 구분하라고. 사이드 프로젝트에서 "완벽하지 않다"는 상황이지 문제가 아니다. 완벽한 소프트웨어는 존재하지 않으니까. 반면 "사용자가 이 기능을 이해하지 못한다"는 해결할 수 있는 문제다. 근데 이 문제를 발견하려면 사용자가 있어야 한다.

Derek Sivers의 "Version 0.1" 철학이 여기서 중요하다. Sivers는 "That's version infinity. First launch version 0.1"이라고 말한다. 완벽한 버전은 version infinity다. 영원히 도달할 수 없다. 대신 version 0.1을 먼저 출시하라. 엉성하고 부족하더라도.

이걸 실천하기가 왜 어려운지도 안다. 개발자는 자기 코드에 자존심이 있다. 깨진 레이아웃, 부족한 에러 처리, 모바일에서 안 예쁜 화면. 이런 걸 다른 사람한테 보여주기가 싫다. "이게 내 실력이라고 생각하면 어떡하지?"

근데 현실은, 아무도 그렇게 생각 안 한다. 대부분의 사람들은 "이 프로젝트의 기술적 완성도"를 평가하지 않는다. "이게 내 문제를 해결해주나?"만 본다. 그리고 해결해주면 CSS가 좀 깨져 있어도 쓴다.

기능이 너무 많으면 끝나지 않는다#

세 번째 이유는 범위 관리 실패다.

사이드 프로젝트를 시작할 때 노션에 기능 목록을 적어본 적이 있을 거다. 대부분 10개가 넘는다. "이건 있어야 하고, 저것도 있어야 하고, 이건 나중에 넣더라도 일단 구조는 잡아놔야 하고..." 이렇게 되면 완성까지의 거리가 너무 멀어진다. 그리고 거리가 멀어지면 동기가 떨어진다.

내 프로젝트 무덤을 발굴해보면, 기능 목록이 긴 프로젝트일수록 빨리 죽었다. 기능 3개짜리 프로젝트는 완성됐고, 기능 15개짜리 프로젝트는 기능 4개를 구현한 시점에서 멈춰있다.

Sivers가 "Version 0.1 = Start lo-fi"라고 한 것도 이 맥락이다. 최소한의 기능으로, 최소한의 품질로 시작한다. 고해상도는 나중에. 처음부터 고해상도를 목표로 하면 시작도 못 한다.

구체적인 방법이 있다. 기능 목록을 적은 후에, 각 기능에 대해 물어본다. "이 기능이 없으면 프로젝트가 아예 성립하지 않는가?" 이 질문에 "예"인 것만 남기고 나머지는 전부 v2로 미룬다. v2는 v1이 출시된 후에 생각한다. 대부분의 v2 기능은 v1을 출시한 후에 보면 필요 없었다는 걸 알게 된다.

계획을 발표하는 함정#

Sivers가 쓴 글 중에 "Announcing your plans makes you less motivated to accomplish them"이라는 게 있다. 계획을 발표하면 실행 동기가 줄어든다는 거다.

이게 심리학 연구로도 뒷받침된다. 목표를 다른 사람한테 말하면, 뇌가 이미 일정 부분 성취감을 느낀다고 한다. "나 이런 거 만들 거야"라고 말했을 때 주변에서 "오 대박 기대된다"라고 반응하면, 그 칭찬이 일종의 보상으로 작용한다. 아직 아무것도 안 만들었는데.

트위터에 "이번 주말에 SaaS 하나 만들겠습니다"라고 올리고 좋아요를 받으면, 만들어야 할 동기가 줄어든다. 이미 사회적 보상을 받았으니까. 반대로 아무 말 없이 조용히 만들어서 완성된 걸 올리면, 그때 진짜 보상이 온다.

물론 Build in Public 문화가 있고, 과정을 공유하는 게 도움이 되는 사람도 있다. 근데 그건 "이미 시작한 프로젝트의 진행 상황을 공유하는 것"이지, "아직 시작도 안 한 프로젝트의 계획을 선언하는 것"과는 다르다.

내 경험상, 프로젝트가 어느 정도 형태를 갖춘 후에 공유하는 게 낫다. 최소한 동작하는 프로토타입이 있을 때. 그 전에는 조용히 하는 게 완성 확률을 높인다.

새로움의 함정#

네 번째 이유. 새 프로젝트의 유혹.

사이드 프로젝트를 하다 보면 어느 순간 재미가 줄어드는 시점이 온다. 초반의 빠른 진전이 사라지고, 지루한 작업이 남는 시기. 에러 처리, 엣지 케이스, 반응형 대응, 로딩 상태. 이런 것들은 재미가 없다. 근데 제품을 완성하려면 반드시 해야 한다.

이 시점에서 새로운 아이디어가 떠오른다. "이건 좀 지루한데, 저 아이디어가 더 재밌겠다." 그리고 기존 프로젝트를 버리고 새 프로젝트를 시작한다. 새 프로젝트의 초반은 또 재밌다. 기술 스택 고르고, 프로젝트 세팅하고, 핵심 기능의 프로토타입을 빠르게 만드는 단계. 그러다가 또 지루해지고, 또 새 아이디어가 떠오르고.

이 사이클을 반복하면 시작만 10개 하고 완성은 0개가 된다.

Seth Godin이 말하는 "진보에 의한 안정성" 개념이 여기에 해당한다. 앞으로 나아가고 있다는 느낌이 안정감을 주고, 그 안정감이 계속 나아가게 만든다. 근데 새 프로젝트로 넘어가면 이 진보가 리셋된다. 매번 0에서 시작하니까 축적이 안 된다.

해결책은 의외로 단순하다. 한 번에 하나만 한다. 현재 프로젝트를 완성하거나 명시적으로 폐기하기 전에는 새 프로젝트를 시작하지 않는다. 새 아이디어가 떠오르면 노션에 적어두고 잊는다. 지금 하는 걸 끝내고 나서 그 노트를 다시 보면, 절반 이상의 아이디어가 별로라는 걸 알게 된다. 시간이 필터 역할을 한다.

완벽주의라는 적#

다섯 번째 이유. 이건 개발자한테 특히 심하다.

"좀 더 다듬으면 좋을 텐데." "이 부분 리팩토링하고 나서 배포하자." "테스트를 좀 더 추가하고." 이 "좀 더"의 연쇄가 프로젝트를 영원히 배포 못 하게 만든다.

완벽주의가 나쁜 건 아니다. 프로덕션 코드에서 완벽을 추구하는 건 프로페셔널리즘이다. 근데 사이드 프로젝트에서의 완벽주의는 프로페셔널리즘이 아니라 회피다. 공개하는 게 무서우니까, "아직 부족하다"를 이유로 숨는 거다.

이걸 구분하는 방법이 있다. "이 수정이 사용자 경험을 실질적으로 바꾸는가?" 버튼 색깔을 조금 바꾸는 건 사용자 경험을 안 바꾼다. 에러 메시지를 더 친절하게 쓰는 건 바꿀 수 있다. 근데 사용자가 없는 상태에서는 둘 다 의미 없다. 사용자가 있어야 뭐가 중요한지를 알 수 있다.

Sivers의 "Never wait"라는 원칙이 있다. 기다리지 마라. 완벽할 때까지 기다리면 영원히 시작 못 한다. 지금 가진 것으로 지금 할 수 있는 것을 한다. 이게 전부다.

내 프로젝트 무덤에서 발견한 패턴#

지금까지 시작하고 끝내지 못한 프로젝트들을 돌아보면 공통된 패턴이 보인다.

데드라인이 없었다. 기능이 너무 많았다. 사용자한테 보여주기 전에 완성도를 높이려 했다. 새로운 아이디어가 떠오르면 쉽게 갈아탔다. 시작할 때 SNS에 선언했다.

반대로 완성한 프로젝트에는 다른 패턴이 있었다. 2주라는 데드라인을 걸었다. 기능을 3개로 제한했다. 부끄러운 상태에서 친구한테 보여줬다. 그 프로젝트에만 집중했다. 완성될 때까지 아무한테도 말하지 않았다.

결국 사이드 프로젝트의 성패는 기술적 능력이나 시간보다, 자기 관리의 문제에 가깝다. 범위를 줄이는 능력, 완벽주의를 내려놓는 용기, 하나에 집중하는 인내심.

다음 프로젝트를 위한 규칙#

이건 나한테 하는 말이기도 하다. 다음 사이드 프로젝트를 시작할 때 따를 규칙.

2주 룰. 시작부터 첫 배포까지 최대 2주. 2주 안에 배포 못 할 범위면 범위를 줄인다.

3기능 룰. 핵심 기능 3개. 나머지는 전부 "나중에" 목록으로.

1주일 이내 공개. 만들기 시작하고 1주일 안에 누군가한테 보여준다. 완성 전이어도. 스크린샷이라도.

침묵 룰. 완성되기 전에는 SNS에 올리지 않는다. 노션에만 기록한다.

1프로젝트 룰. 동시에 하나만. 새 아이디어는 적어두기만 한다.

이 규칙들이 모든 사람한테 맞지는 않을 거다. 근데 나처럼 시작만 잘하고 끝을 못 맺는 사람한테는 이 정도의 강제성이 필요하다고 느낀다. 자유는 좋지만, 프레임이 없는 자유는 혼란이 될 수 있다.

Sivers가 "Start now. No funding needed"라고 했다. 지금 시작하라. 자금이 필요 없다. 여기에 한마디만 더 붙이고 싶다. 그리고 끝내라. 시작하는 건 누구나 한다. 끝내는 사람이 드문 거다.

내 GitHub에 잠들어 있는 프로젝트들은 아이디어가 나빠서 죽은 게 아니다. 끝내지 못해서 죽은 거다. 다음 프로젝트는 끝내보려 한다. 완벽하지 않아도, 작아도, 부끄러워도. 완성된 작은 것이 미완성된 큰 것보다 낫다는 걸, 경험으로 안다.