나는 왜 사이드 프로젝트를 실패하였나

 

부트캠프를 수료하고, 직장인이 된 이후로도 개발에 대한 흥미와 실력을 갖추고 싶다는 열망은 전혀 사라지지 않았다. 또한 IT서비스 회사에 다니지 않고 있기 때문에 남들보다 뒤쳐질 수 있다는 생각에 집에서도 공부가 필요하다는 생각을 자주 했었다. 고민의 결과, 사이드 프로젝트를 통해서 회사에서 사용해보지 못하는 기술들을 사용하고, 개발욕구를 충족시킬 수 있을 것 같다는 생각이 들었다.(회사에서는 내가 원하는 개발만을 할 수 없기에)

 

보통 3~4개월 주기로 이러한 개발 욕구가 샘솟았었는데, 항상 이 욕구들은 '사이드 프로젝트를 시작하자'라는 결과로 귀결되었다. 사이드 프로젝트를 하면 자연히 개발 공부도 될 것이고, 무언가 공부의 결과물을 남길 수 있을 것 같다는 생각을 항상 했었던 것 같다. 물론, 마치 갓생을 사는 것 같은 느낌을 받고 싶었던 것도 없지는 않았다.

 

하지만 야심차게 시작했던 많은 프로젝트들이 소리소문없이 private repository에서 사라져 갔다. 분명 프로젝트를 시작할 때는 의욕이 넘쳤고 심지어 새로운 걸 만든다는 느낌에 두근거리기 까지 했었는데, 완성까지 단 하나의 프로젝트도 가지 못하였다. 어제 또 하나의 프로젝트를 레포 무덤에 보내고는 극심한 현타가 밀려왔다.

 

이제는 이유가 궁금했다. 나는 무엇때문에 사이드 프로젝트에 실패했나. 나의 의지에 대한 실망, 여러가지 핑계 거리들을 뒤로 하고 정말 실패한 원인이 무엇인지에 대한 고찰이 필요하다고 생각했다. 

 

 

내가 생각한 실패 이유

 

 

 

내가 실패한 이유에 대해서 개발 외적, 개발 내적으로 나누어 정리해 보았다.

 

개발 외적

 

1. 시간이 부족하다.

2. 강제성이 없다.

3. 우선순위(체계)가 없다.

 

우선 직장인 개발자들의 단골 변명인 시간이 부족하다가 가장 먼저 떠올랐다. 기본적으로 하루 중 평균 9~11을 회사에 있어야 한다. 퇴근 후에는 운동, 여자친구와 데이트 두 가지 데일리 루틴만 하더라도 씻고 먹는 시간을 포함하고 나면 하루 여유시간이 채 2시간이 남지 않는다. 하루에 2시간만 작업하더라도 작은 시간은 아니지만, 2시간을 오롯이 사이드 프로젝트에 쓸 만큼의 집중을 하지 못했다. 

 

집중을 하지 못했던 이유가 바로 강제성이 없었기 때문이라고 생각된다. 사이드 프로젝트다 보니 내가 안하더라도 누가 뭐라하는 사람이 없고, 데드라인도 없다. 야근, 회식, 갑작스러운 약속이 잡히면 프로젝트 보다는 약속 일정이 우선시 되었다. 어쩔 수 없는 경우도 당연히 있지만, 이런 일이 반복되어 프로젝트 기간에 공백이 생겼을 때가 가장 개발 의욕이 감소했던 구간이었던 것 같다. 제대로 일정을 잡고 프로젝트를 진행하는 것이 아니다 보니 일정이 겹쳤을 때 자연스레 사이드 프로젝트가 우선순위에서 밀리게 되었다.

 

개발 내적

 

1. 계획의 부족

2. 목표의 부재

3. 프로젝트 크기의 부적절성

4. 우선순위(체계)가 없다.

 

결론적으로, 철학과 문서가 없다.

 

소프트웨어 개발 방법론 중 애자일(Agile) 방법론이 있다. 애자일 방법론은 문서화보다 프로젝트의 본질적인 목표를 우선시 하고, 빠르게 프로토타입을 만들어 내며 결과물을 만드는 것을 목표로 한다. 참여와 소통 등 상호협력이 굉장히 중요하여 팀 개발에도 적합하지만, 프로젝트의 목표를 최우선한다는 철학이 개인 사이드 프로젝트에 적용하기에 아주 적합하다고 생각했다. 어차피 혼자 하는 일이기 때문에 문서보다는 개발자체에 집중하면 된다고 해석한 것이다.

 

하지만 이런 생각 때문에 내 사이드 프로젝트는 시작도 전에 실패를 했던 것 같다. 문서화된 자료가 없기 때문에 언제든지 계획이나 목표가 변경되었고, 그때그때 하고싶은 개발을 하다가 잠들게 되었다.

 

지금 생각해보면 기능 명세서, API 문서, 프로젝트 계획서 를 자세하게 작성하는 것 까지는 아니더라도 프로젝트의 범위, 개발 하고자 하는 기능, 개발 순서, 아키텍쳐를 미리 문서화하여 개발 도중에 방향성이 바뀌는 것을 방지했어야 했다.

더불어 서비스를 만드는 이유, 유저가 필요로 할 것 같은 요구사항에 대해 확실히 분석하여 좋은 아이디어를 미리 도출하고 기능을 만들어내며 개발 동기를 잃지 않는 것도 중요한 포인트인 것 같다. 서비스에 개발자의 철학이 담기지 않고 '그냥 만들어 볼까'라는 생각으로 만들다 보니 내가 만들면서도 '이걸 진짜 쓸까?'라는 의문을 계속 가졌었다.

 

 

즉, 기술적으로도 상황적으로도 처음부터 똑바로 만들 환경을 구성해놓아야 프로젝트가 동력을 잃지 않는다고 요약할 수 있을 것 같다.

 

 

추후 목표

 

 

1. 나는 다시 한 번 사이드 프로젝트를 시작할 예정이다. 하지만 이제는 프로젝트를 위한 프로젝트를 만들지는 않겠다. 서비스로서의 가치가 있고, 시장의 요구가 있는 프로젝트를 하겠다.

 

2. 현업과 실패한 사이드 프로젝트를 통해서 개발보다 개발 이전까지의 과정이 더욱 중요하다는 것을 다시 한 번 깨달았다. 그저 코드를 치면서 개발하는 것이 기획하고, 문서화하는 것보다 재밌었기 때문에 필요한 일들을 등한시 했었던 것을 반성하고, 서비스를 만드는 재미를 느끼겠다.

 

3. 서비스를 만드는 과정을 기록해보자. 블로그에 주기적으로 프로젝트 진행을 포스팅하여 타인과 함께 프로젝트를 공유한다는 생각을 가지면 동기 부여와 강제성이 생길 것이다.