기업에서 개인에 이르기까지 잉여 시간을 잘 활용하는 방법에 대한 고민은 끊이지 않는다. 그 중 하나로 사이드 프로젝트를 활용하는 사례가 늘고 있어 정리해 봤다.
생각에 그치지 않고 그것을 실현해가는 습관을 길러주는 사이드 프로젝트, 개인에게 사이드 프로젝트 하나쯤은 지속적으로 유지하면 더 성장한 자신을 발견할 수 있다고 생각한다.
왜 사이드 프로젝트가 좋은가?
사이드 프로젝트란 메인 잡은 그대로 유지하면서, 자기가 좋아하고 하고 싶은 아이디어나 기술을 통해 부가적으로 프로젝트를 만들어 시간이 날 때마다 실현하는 것을 말한다.
스타트업에서는 “Fail Fast”(빨리 실패하기), “MVP”(최소한의 핵심 가치를 투입)를 모토로, 빨리 시장에 내놓고 고객의 피드백으로 개선해 가는 방식을 중요한 비즈니스 사이클로 인식하고 있다. 이와 다른 관점에서 대두되고 있는 개념이 바로 Succeeding Slowly(느린 성공)이며, 이 느린 성공에 잘 어울리는 형태가 바로 사이드 프로젝트다.
Why Side Projects matter?라는 아티클에서 보듯이, 본업으로 살아가면 먹고는 살 수 있지만 사이드 프로젝트는 자신을 크게 성장시킬 수 있다. 가능성이 큰 아이디어를 실현하는 기쁨, 길게 보고 꾸준한 노력을 통해 나중에 큰 성공을 거둘 수 있다는 희망, 자신이 즐거워하는 일을 한다는 것은 개인적으로 커다란 동기부여이자 축복이다. 거기서 자신에게 보이지 않았던 창조성을 찾고 발휘할 수도 있다.
그래서 본업은 “Fail Fast(빠른 실패)“를, 사이드 프로젝트는 “Succeeding Slowly(느린 성공)“의 관점으로 지향하다 보면 본업과 사이드 프로젝트 중 하나에서 성공을 맛볼 기회가 커지지 않을까?
또한, 3M의 Jefferson도 사이드 프로젝트의 유용성에 대해 Success on the Side - The American, A Magazine Ideas라는 아티클을 썼다. 그 내용 중 키포인트만 요약하면 다음과 같다.
혁신은 천재가 고민한 끝에 나온 좋은 아이디어만으로 만들어지는 게 아니다:
- 아이디어는 예기치 않은 곳에서 나온다.
- 아이디어는 머리로 생각해서 발견되는 것이 아니라, 실제로 뭔가를 만들고 이행하는 중에 나오는 것이다.
- 중요한 것은 모든 직원의 전체적인 힘, 특히 고객에 가까운 직원의 힘이다.
이 말로 사이드 프로젝트의 타당성을 강조하고 있다.
사이드 프로젝트의 성공 사례
Start Something : The Power of Side Projects(사이드 프로젝트의 힘)에서 보면, Google의 20% 룰에 의해 Gmail, News, AdSense가 태어났고, Twitter, Instagram, Uber, StumbleUpon 등이 사이드 프로젝트에서 출발해 성공을 이룬 서비스들이다. 또한 셀로판 테이프(Scotch Tape)를 Richard Drew라는 직원이 개발한 것도 3M이 추구한 “15-percent-time rule”에 의해 이루어졌다고 한다.
모든 시간을 본업에 집중해도 경쟁력이 생길까 말까 하는 시각도 있겠지만, 잉여 관점의 프로젝트는 자율성과 다양성이 보장되는 환경에서 스치듯 지나가는 아이디어를 긴 시간 갈고 닦게 해준다. 또 다른 성공 사례의 가능성도 내포되어 있다는 점에서 설득력 있는 방법이다. 개발자의 경우 자기가 좋아하는 분야의 기술력을 높이는 도구도 될 수 있어, 꾸준히만 한다면 마이너스가 될 전략은 아니다.
개발자의 사이드 프로젝트 진행 사례 소개
jQuery를 만든 John Resig이 사이드 프로젝트를 통해 매일 코딩하는 습관의 중요성을 다룬 글 Write Code Every Day를 썼다.
그 중에서 자신이 습관화하는 데 따르고자 했던 룰과 코딩을 습관화하면서 얻은 흥미로운 것들을 소개한다.
John Resig이 사이드 프로젝트를 하면서 겪었던 문제는 다음과 같다. 주중엔 코딩을 많이 할 수 없어서 주말에 몰아서 하곤 했는데, 완성도나 업무 연결성에 문제가 있었고 주말에 약속이 없다는 것도 보장할 수 없었다. 기본적으로 해야 한다는 스트레스도 컸다. 그래서 Jennifer Dewalt의 사례를 보고 자신만의 코딩 습관화 룰을 만들었다.
- 매일 코드를 작성해야 한다. 문서나 블로그 기사 등은 코드를 작성하고 난 뒤 여유가 있을 때 작성한다.
- 작성한 코드는 유용해야 한다. 들여쓰기나 코드 외형 수정은 포함하지 않는다. 가능하면 리팩토링도 포함하지 않는다.
- 모든 코드는 자정 전에 써야 한다.
- 코드는 오픈 소스로 GitHub에 올려야 한다.
이 룰을 모두가 따라야 한다는 것은 아니지만, 이 룰을 통해 John Resig은 코드 습관화에 성공했고 20주 연속으로 진행하며 유지하고 있다고 한다.
그렇다면 이 룰을 통해 코드 습관화를 하면서 어떤 변화가 생겼는지 소개한다.
최소 실행가능한 코 드. 적어도 하루에 30분은 코딩에 투자했다. 주중에는 약간만 코딩했고, 주말에는 때때로 하루 종일 코드를 짤 수 있었다.
습관화된 코딩. GitHub에 나타나는 코딩 이력 차트를 신경 쓰지 않게 된다. 당신 자신을 위해, 당신 인생에서 무엇을 했는가가 중요한 변화이지, 남에게 인정받기 위한 것이 중요한 게 아니다. 자기 스스로를 개선하지 않으면 진정으로 성공할 수 없다.
불안과의 사투. 이 실험 전에는 완성도와 진척도에 관해 불안한 느낌을 종종 가졌다. 그런데 매일 지속적으로 작업을 진행하자(습관화하자) 불안은 사라지기 시작했다. 진척도를 느끼는 감각은 실제 진행하는 것만큼이나 중요하다는 것을 깨달았다.
주말 작업. 이전에는 주말에 일주일치 기대치를 쌓아 두다가 결국 실망감을 안겨주곤 했다. 매일 조금씩 하다 보니 주말에 몰아서 해야 한다는 압박이 사라졌다.
백그라운드 처리. 매일 사이드 프로젝트를 진행하면서 발생하는 흥미로운 부작용은, 현재 작업이 항상 머릿속 뒤편에서 돌아가고 있다는 것이다. 산책이나 샤워처럼 뇌를 적극적으로 사용하지 않는 활동 중에도 코딩할 내용을 생각하게 되어 문제 해결의 실마리가 발견되기도 한다.
컨텍스트 스위치(업무 전환). 일주일 내내 다른 프로젝트를 진행한 뒤 사이드 프로젝트로 돌아오면 컨텍스트 전환 비용이 크다. 매일 작업하면 기억 간격이 짧아져 어디까지 했는지 쉽게 기억할 수 있다.
업무 균형. 매일 사이드 프로젝트를 하면서 일/삶/프로젝트의 균형을 잡는 방법을 배우게 된다. 저녁에 외출할 경우 다음날 일찍 일어나 사이드 프로젝트 목표를 먼저 완료하는 식으로 시간 배분에 더 신경 쓰게 된다.
외부의 인식. 이러한 습관은 외부적으로 커뮤니케이션하는 데 도움이 되었다. 파트너가 매일 코드를 완료해야 하는 것을 이해해 주면서 일정을 배려해 주기도 했다.
John Resig의 코딩 습관화 경험담과 룰은 많은 것을 시사한다. 사이드 프로젝트가 모든 것을 해결해 주는 은총알은 아니다. 다만 잉여력을 성과로 만들어 내기 위한 좋은 방법 중 하나이며, 개발자의 전문성을 높이는 가장 효과적인 수단 중 하나가 업무 외 분야에서의 의도적인 수련임을 생각하면 사이드 프로젝트는 그 좋은 예다.
