오늘은 사이드 프로젝트에 대해서 이야기를 해보려고 한다.

요즘엔 정말 많은 분들이 사이드 프로젝트를 하고 계신다. 실제로 필요한 것을 만드는 것 부터 다른 서비스를 따라 만들어보는 클론 코딩까지 정말 다양하다.
지난 회사에서 나는 면접관으로 참여하게 되면서 이력서를 검토했는데 많은 분이 사이드 프로젝트를 작성해주셨다.

검토를 하다 보면 좋은 사이드 프로젝트도 있지만 평가하기 어려운 프로젝트도 많이 봤다.
평가하기 어려운 프로젝트는 주로 부트캠프에서 진행한 팀 프로젝트와 클론 코딩이 많았다.
부트캠프에서 진행한 팀 프로젝트로 진행한 경우에는 부트캠프에서 어느정도 가이드를 줬는지, 또 개인이 얼마나 기여했는지가 알기 어렵고, 클론 코딩의 경우에는 특별한 기획 역량을 판단하기 쉽지 않다.

평가하기만 어려운 것이 아니라, 이력서를 작성하는 입장에서도 설명하기 쉽지 않다보니 대부분 어떤 기술을 사용했고 어떤 걸 했다 라고만 작성된 경우가 많다.

하지만 내 기준에는 어떤 기술로 무엇을 했는가도 중요하지만 왜 만들려고 했는지, 그걸 만들면서 어떤 문제에 직면했고 어떻게 해결해나갔는지가 더 중요하다고 생각한다.

이미 있는 서비스를 그저 따라만들기 보다는 내가 필요로 하거나, 누군가의 문제를 해결하는 가치를 찾아서 진행하는 프로젝트가 좋은 방향이라고 생각한다.
따라 만드는 프로젝트가 나쁘다는 뜻은 아니지만, 이미 만들어진 제품을 따라 만드는 경우 제품을 만들면서 겪었던 고민에 대해서는 무임승차하는 것이라 아쉬움이 있는 것도 분명하다.

물론 학습을 위해서 클론 코딩이 나쁘다는 것은 아니다. 기술스택에 능숙해지기 위해서 할 수 있는 괜찮은 학습 방식이라고 생각한다.
내 경우에는 그렇게 늘 가치만 생각하다 선뜻 사이드 프로젝트를 시작도 못했기 때문에 클론 코딩에 대해 나쁘게 생각할 이유는 없다. 적법한 선 안에서라면 모방에서 또 새로운 아이디어를 얻을 수 있을테니..

쓰고 보니 사이드 프로젝트 자체보다 포트폴리오용 클론 코딩에 대한 이야기가 더 많은 것 같다.
어떤 분들은 클론 코딩은 학습 방식이지 사이드 프로젝트는 아니라고 하실 수도 있겠다. 음.. 그럼 포트폴리오라고 부르는게 더 적당한가 싶기도 하다.

결론은 내가 사이드 프로젝트를 하지 못했던 것에 대한 변명문이다. (엥)