모노레포로 시작하는 셀프 브랜딩
오랜만에 찾아오는 글쓰기, 이번엔 개발 관련 이야기와 함께
최근에 개인 사이드프로젝트, 커뮤니티 사업인 메타피어를 시작하기로 마음먹었는데, 해당 프로젝트를 모노레포 방식으로 진행하기로 결심했다.
모노레포란?
모노레포는 여러 프로젝트를 하나의 저장소에서 구현하는 방식이다.
여러 서비스를 만들어도 공통 디자인 시스템이나 의존 모듈들을 활용할 수 있다는 점에서 편리함을 가져갈 수 있으며, 각 서비스별로 다른 기술스택을 사용할 수 있는 마이크로 서비스 아키텍처와의 궁합이 굉장히 좋다는 장점이 있다.
그러나 백엔드 같은 경우에는 각각의 Endpoint들을 다양한 언어로 구현해도 큰 문제가 없지만, 다양한 프런트엔드 프레임워크를 사용하여 흔히 마이크로 프런트엔드라고 불리는 방식을 모노레포식으로 관리를 하게 된다면, 서로 다른 프레임워크의 모듈들을 사용할 수 없기 때문에, 같은 디자인 시스템, 공통 모듈을 이용할 수 있다는 장점은 사라지게 된다.
사이드 프로젝트에 모노레포를 적용하는 이유
사이드 프로젝트는 보통 한 개에서 끝나지 않는다. 여러 가지 시도를 할 수 있으며, 그중 몇 개는 수익화를 시킬 수 있으면 좋겠다는 생각을 하고 있다. 여러 가지 도전이 있을 수 있으며, 그 도전에는 다양한 기술스택 역시 적용된다. 가령 같은 프로젝트에 포함될 기능이라도 다른 언어로 구현할 수 있다는 것은, 하나의 사이드 프로젝트에 여러 가지 경험을 녹여낼 수 있다는 뜻이 된다. 회사에서 모노레포 방식을 적용할 때에는 유지 관리 측면에서 다양한 기술스택을 적용할지 고려를 해야 하지만, 개인의 관점에서는 하나의 새로운 도전으로 좋은 양분이 될 뿐이다.
또, 나는 새로운 사업을 론칭하여 그것을 브랜딩 하는 것이 아닌 이상, 모든 사이드 프로젝트는 '나'라는 해시태그를 통해서 브랜딩 됐으면 한다. 내가 하나의 브랜드가 되어 다양한 사이드 프로젝트를 론칭하고 관리하기에는 모노레포 방식이 매력적이라고 생각했다.
또한 프로젝트 세팅에 드는 비용도 절감될 수 있다고 생각한다. 나중에 베포 할 것까지 생각한다면, github actions의 workflow들을 한 개의 프로젝트에서 관리하는 편이 더욱 편할 거라고 생각했다.
또한 나중에 생길 사이드 프로젝트들이, 기존의 사이드 프로젝트에서 사용됐거나 수집된 데이터들을 이용할 수 있으면 더욱 좋을 거라고 생각했다. '나'라는 해시태그를 만들어나가는 과정에 걸맞게, 내가 만든 새로운 사이드 프로젝트에서도 기존 프로젝트의 정보들을 활용하여 느슨하게라도 결합되어있으면 하나의 거대한 프로젝트처럼 보일 것 같았다.
셀프 브랜딩
결국 이 모든 장점들이 셀프 브랜딩과 연관이 있다. 다양한 도전도 결국 나를 브랜딩 하고 성장시키기 위한 양분이 될 것이고, 프로젝트들이 느슨하게 결합되어 있는 모습도 하나의 나를 그리고 있을 것이다.
아주 단순하게도, 멀티레포로 저장된 프로젝트들은 각각의 프로젝트를 소개하고 브랜딩 하는 느낌이 강하게 들었고, 나를 브랜딩 하는듯한 느낌을 못 받았다. 물론 그 프로젝트가 사업성이 훌륭해서 따로 사업으로서의 브랜딩이 될 수도 있겠지만, 개인 프로젝트에서 그만한 사업성을 갖기도 힘들 거고, 설령 갖게 된다 하더라도 그때부터는 하나의 사업으로서 브랜딩을 시작할 수 있을 거라고 생각한다. 결국 여러 가지 도전으로 이어가기 쉬운 구조와, 각 프로젝트가 아닌 '나'자체를 브랜딩 하는 툴로서 모노레포 방식이 제격이라고 생각했다.
