IT

사이드프로젝트란 게 사실은 '남의 시간 도둑질'인 거 아냐? 회사에서 주어진 업무가 이미 최적화된 파이프라인인데, 그걸 깨고 나만의 미친 아이디어로 새 파이프라인을 구축하려는 건, 마치 이미 잘 돌아가는 지하철을 끊어서 '나만의 개인전철'을 만들려는 것과 똑같잖아? 대부분의 사이드프로젝트 실패 이유는 '기술적 난이도'가 아니라 '기존 시스템과의 통합 비용'을 과소평가해서야. 내가 본 사례들 보면, 3 개월 동안 신나게 개발해서 출시했는데, 오히려 기존 업무에 간섭해서 본업이 더 느려지는 경우가 80%야. 그거를 '혁신'이 아니라 '생산성 저하'로 봐야지. 진짜 사이드프로젝트 성공 사례는 보통 두 가지 경우야. 1. 완전히 다른 스택을 써서 본업과 단절된 '도구'를 만듦 (예: 자동화 스크립트, 내부용 유틸) 2. 본업의 부수적인 문제를 해결하는 '부품'을 만듦 그 외의 건은 그냥 '나를 위한 시간 낭비'일 뿐이야. 아무도 원하지 않는 기능, 아무도 쓰지 않을 것 같은 UI, 그리고 '내가 좋아서' 만든 기능들. 그거들이 쌓여가는 사이드프로젝트는 결국 '디지털 쓰레기통'이 될 뿐이지. 혹시 지금 개발 중인 사이드프로젝트가, 본업의 효율을 떨어뜨리지 않으면서도 진짜로 누군가에게 가치를 줄 수 있는 '도구'라면 좋겠지만, 대부분은 개발자의 '자존심'을 채우기 위한 '장식'에 불과한 거 같아. 그럼에도 불구하고, 만약 지금이라도 시작해야 한다면 최소한 '완성도'보다 '문제 해결'에 집중해. 그리고 그 프로젝트가 본업의 효율을 높여주지 않으면, 그냥 버려라. 사실은 사이드프로젝트보다 중요한 건, 본업에서 쌓은 '문제 해결 능력'이야. 그걸 못 배운 채로 외로운 개발자 길만 걷는 건, 자살과 뭐가 다를까?