지금까지 나는 단 한 번도
꾸준히 오래가는 사이드 프로젝트를 해 본 적 없다.
일회성으로 개발하고 끝나거나
개발하는 도중에 흐지부지 되면서
깃허브에 어정쩡하게 아카이브 될 확률이 100%이다.
그나마 완성도 있게 마무리 한 거라곤
혼자서 개발한 “타타타(타임타이머 웹버전)”, “오또(로또 자동구매 앱)”
그리고 과제, 외주로 개발한 것들 뿐이다.
이번에 시작하는 사이드프로젝트 팀 역시 그대로 놔두면
디지털 쓰레기(노션, 단톡방)를 만들 수 있기 때문에
지금까지 팀으로서 진행한 프로젝트가
왜 성공하지 못했는지, 제대로 하려면 어떤 마인드로 해야하는지
자기 전에 잠깐 고민한 결과를 기록하려고 한다.
사이드 프로젝트를 하는 이유
굳이 학업, 본업이 있는 사람들이 왜 굳이 사이드 프로젝트를 하려고 할까?
“포트폴리오를 쌓기 위해서” 같은 것도 물론 이유가 될 수 있지만,
이러한 소모적인 이유가 아닌
오랫동안 유지할 수 있는 동기를 가지고 있어야 한다.
사이드 프로젝트에 대한 동기는 “흥미”, “이익” 두 가지로 요약 가능하다.
나의 내면적인 동기는 다음과 같다.
- (흥미) 개인적인 불편한 점을 해결하는 도구들을 직접 만들고 사용한다.
- (이익) 같은 불편함을 겪는 사람이 있다면 사업으로 만든다.
- (이익) 사업이 되든 말든, 그 과정을 기록해서 포트폴리오로 내 몸값을 높이는 데 쓴다.
위의 동기는 전부 한 순간에 충동적으로 생각한 것이 아니라
살아오면서 만들어진 내 가치관이 반영된 것이다.
나는 이런 동기로 사이드 프로젝트에 임했을 때
마무리까지 지을 수 있었고 열정이 더 오래간다고 생각한다.
사이드 프로젝트가 실패하는 이유 & 해결책
1. (팀의 경우) 내 아이디어가 아니면 흥미가 떨어진다.
사람이 원래 그렇다.
회사라면 재미없어도 돈 때문에 하지만
사이드 프로젝트는 흥미가 가장 중요한 연료이다.
그래서 아이디어를 정할 때,
흥미가 없을 거 같으면 과감하게 쳐내야 한다.
사이드 프로젝트에선 흥미가 1순위다.
본업만 해도 피곤한데 시간까지 투자하려면 흥미는 필수다.
물론 모두가 흥미를 가질만 한 주제가 쉽게 나타날 리 없다.
하지만 내 아이디어가 정말 매력적이라고 스스로 생각한다면
팀원들에게 '한 번 해볼까?' 정도의 인상을 남겨야 한다.
나는 그러기 위해서 이것을 왜 만들고 싶어졌고
어떤 결과를 기대하길래 내가 이 아이디어에 설레는지 느껴지도록 글을 하나 써서 공유했다.
그리고 혼자 가능한 수준으로 아이디어를 가시화했다.
이 아이디어가 잘 완성되면 이런 모습일거라는 걸 최대한 보여줘서
나 혼자서 역부족이라고 생각하는 부분에 참여해달라는 식으로 호소했고 사이드 프로젝트 인원을 구할 수 있었다.
이렇게 참여한 친구들은 프로젝트를 위해 밤낮으로 고민하는 좋은 팀원이 되어 주었다.
2. 개발이 오래 걸린다.
사이드 프로젝트 단골 주제가 있다.
“플랫폼”
플랫폼을 주제로 한 프로젝트는 대개 이렇게 진행된다.
- 기술 스택 공부 한 달
- 구현 두 달
- 런칭
어림없지!
개발을 떠나 플랫폼은 비즈니스 중에서도 어려운 편에 속한다.
가장 먼저 떠오르는 이유는 참여자가 최소한 ‘소비자 - 생산자’ 두 종류 이상이기 때문이다.
생각보다 만들어야 하는 화면도 더 많을 뿐더러
예비 소비자/생산자들이 봤을 때 사업성이 없으면
커뮤니티에 백날 홍보해도 아무도 가입하지 않을 것이다.
쪼렙들이 레벨업 하겠다고 고인물 던전에서 사냥한다는 꼴이다.
개발적인 측면에서도 좋을 게 없다.
몇 달 동안 하나의 스펙을 구현하는 건 성장에 별 도움이 안된다.
돌아가는 서비스에서 기능을 개선/추가하는 것처럼
달리는 자동차의 바퀴를 교체하는 작업들이 실무에 훨씬 가까운 작업이다.
(리팩토링 글에서도 언급했으니 참고)
누가 쓸지 안쓸지 확신 없는 서비스를 몇 달에 걸쳐서 만들기보단
적어도 팀원들만이라도 생활에서 계속 쓰게 되는 걸
짧은 시간 안에 MVP로 만들고
스스로 사용자가 되어 피드백하고 개선해보자.
쓸 수 있는 기술스택 100가지보다
서비스 하나를 계속 발전시키는 고민들을
꾸준하게 블로그에 남기는게 더 취업에도, 성장에도 도움될 것이다.
(내가 블로그를 하고 있는 이유와도 같다)
3. 굳이 같이 할 이유가 없다.
여러 명이 사이드 프로젝트를 하는 경우를 보면
대부분 프론트, 백, DB, 디자인, …
이렇게 역할분담 하려고 진행하는 경우가 많다.
그러면 왜 역할분담이 필요할까?
‘플랫폼’ 같은 거창한 아이디어를 감당하려면
나 혼자 공부해서는 역부족이기 때문이다.
이런 이유라면 100% 사이드 프로젝트는 망한다.
‘내 분야’라는 두꺼운 벽을 세우고,
주제에 대한 고민이 아닌 기술을 배우려고만 한다.
요즘은 개발자 혼자 어떤 서비스도 못 만들 이유가 전혀 없다.
내가 프론트엔드라면 파이어베이스를 쓰면 백엔드가 해결되고,
백엔드라면 HTML만 몇 시간 공부하면 못생겼지만 쓸만한 웹사이트는 충분히 나온다.
(참고: 프론트 개발자도 디자인 감각은 거기서 거기다)
내가 생각하는 팀으로서 진행하는 프로젝트의 의미는
‘하나의 문제’를 두고 ‘각기 다른 능력을 가진 사람들’이
‘문제에 대한 우아한 해결책’을 공유하는 것이다.
만약 <로딩이 오래 걸린다>라는 문제가 있다고 하자.
- 디자이너는 로딩 중 움직이는 일러스트를 활용해 지루함을 덜어주는 방법을 제시한다.
- 프론트엔드 개발자는 이미지를 지연(Lazy) 로딩하여 딜레이를 줄이는 시도를 한다.
- 백엔드 개발자는 커넥션 풀을 도입하여 DB와의 연결 설정 시간을 단축한다.
이런 식으로 같은 문제에 대한 다른 해결책들이 모여
완성도 있는 서비스를 만드는 것.
그리고 그 방식을 공유하여 서로의 시야를 넓히는 것이
진정한 팀 프로젝트라고 생각한다.
내 의지대로 사이드 프로젝트를 운영한다면,
팀 블로그를 운영해서 자신만의 노하우를 풀어놓으면 좋을 것 같다.
“~~ 문제를 ~~로 해결한 과정” 같은 주제로 풀어놓는다면
분야를 막론하고 도움이 될 인사이트가 공유된다고 확신한다.
물론 포트폴리오로도 엄청난 위력을 발산할 것이다.
결론
- 모두가 흥미있는 주제를 잡자
⇒ 공통점이 없다면 팀을 쪼개는 것도 방법이다 - 생활 밀착형(필요해서 만드는) 서비스를 만들자
⇒ 최소한의 단위(MVP) 구현 → 쓰면서 피드백 & 업데이트 - 문제를 해결하기 위한 고민을 팀 블로그로 공유하자
⇒ 노션, 미디움 등 모든 사람이 글을 작성할 수 있는 플랫폼 이용