이번 프로젝트를 진행하다가 문득 문제점을 인지했다.
우리 서비스를 세분화하면 3가지 서비스로 나뉜다.
세분화된 각 서비스의 크기가 작지 않기에 이번 기회에 프로젝트 구성 방식에 대해 알아봤고, 이를 통해 우리 프로젝트는 어떤 방식이 적절한지 판단했다.
마이크로 프론트엔드를 알기 위해 과거의 개발 흐름에 대해 이해하면 좋다.
이는 좋은 글이 있기에 소개한다.
마이크로 프론트엔드와 모노레포 & 제로빌드
마이크로 프론트엔드는 기존 모놀리식 방식과 다르게 세부 서비스의 개발 독립성과 자율성을 추구한다. 각 서비스를 개발하는 팀은 그들의 라이프 사이클, 개발 환경 등을 자율적으로 정하고 따를 수 있다. 이는 세부 서비스 1이 Vue를 쓰고, 세부 서비스 2가 React를 써도 전혀 상관없다는 의미이다.
이제 프로젝트 기법 중 멀티레포와 모노레포에 대해 알아보자.
멀티레포는 각 프로젝트가 독립적인 하나의 레포지토리를 가진다. 이에 따라 여러 개의 레포지토리가 생긴다. 멀티레포의 장단점을 알아보자.
멀티레포의 장점
멀티레포의 단점
모노레포는 하나의 레포지토리 내에서 프로젝트 및 패키지를 관리한다. 모노레포의 장단점을 알아보자.
모노레포의 장점
모노레포의 단점
이제 실전이다.
아까 말했듯, 내 프로젝트는 세부 서비스가 3개이다.
이를 처리하기 위한 방식 중 모놀리식은 제외한다.
이유는 다음과 같다.
이제 멀티레포와 모노레포 중 선택할 단계인데, 여기서 또 내 프로젝트의 특성을 고려할 필요가 있다.
결론 도출 과정은 다음과 같다.
모노레포를 갔을 때, 공통 패키지를 더 설치할 필요가 없는 것은 좋다. eslint, prettier 등의 설치를 고려 안 해도 된다는 것은 확실히 매력적이다. 하지만 모노레포 환경을 만들기 위해 과제가 생긴다.
이에 반해 멀티레포 환경 조성은 어렵지 않다. 총 세부 서비스가 3개이기 때문에, 레포지토리 2개를 더 만들고, 젠킨스 파이프라인 생성, 그리고 추가된 빌드 파일을 도커 마운팅하고 nginx 설정만 해주면 된다.
따라서 이번 프로젝트에선 멀티레포를 도입하기로 결정했다. 하지만 다음 프로젝트에는 경험을 위해서라도 모노레포 방식을 도입해 보고 싶다.