이번 프로젝트를 진행하다가 문득 문제점을 인지했다.
우리 서비스를 세분화하면 3가지 서비스로 나뉜다.
- 사용자용 웹 서비스
- 관리자용 웹 서비스
- 빌트인 서비스
세분화된 각 서비스의 크기가 작지 않기에 이번 기회에 프로젝트 구성 방식에 대해 알아봤고, 이를 통해 우리 프로젝트는 어떤 방식이 적절한지 판단했다.
Micro Frontend란?
마이크로 프론트엔드를 알기 위해 과거의 개발 흐름에 대해 이해하면 좋다.
이는 좋은 글이 있기에 소개한다.
마이크로 프론트엔드와 모노레포 & 제로빌드
마이크로 프론트엔드는 기존 모놀리식 방식과 다르게 세부 서비스의 개발 독립성과 자율성을 추구한다. 각 서비스를 개발하는 팀은 그들의 라이프 사이클, 개발 환경 등을 자율적으로 정하고 따를 수 있다. 이는 세부 서비스 1이 Vue를 쓰고, 세부 서비스 2가 React를 써도 전혀 상관없다는 의미이다.
멀티레포 vs 모노레포
이제 프로젝트 기법 중 멀티레포와 모노레포에 대해 알아보자.
멀티레포
멀티레포는 각 프로젝트가 독립적인 하나의 레포지토리를 가진다. 이에 따라 여러 개의 레포지토리가 생긴다. 멀티레포의 장단점을 알아보자.
멀티레포의 장점
- 각 프로젝트의 자율성이 높다.
- 각 프로젝트별로 빌드가 가능하다.
- 각 프로젝트별 독립적이기에 유연하다.
멀티레포의 단점
- 프로젝트를 새로 만들 때마다 개발 환경, 배포 환경을 구성해야 한다.
- 코드 중복이 생긴다.
- 프로젝트 개수가 늘어나면 점점 관리가 어려워질 수 있다.
모노레포
모노레포는 하나의 레포지토리 내에서 프로젝트 및 패키지를 관리한다. 모노레포의 장단점을 알아보자.
모노레포의 장점
- 프로젝트 공통 항목을 처리하기 쉽다.
프로젝트 생성 단계에서 eslint, prettier 등의 설정이 이미 다 되어있다. - 프로젝트의 패키지 관리를 통합해서 할 수 있다.
- 멀티레포보다 의존성 관리가 우수하다.
모노레포의 단점
- 레포지토리의 거대화
- 멀티레포보다 빌드가 느리다.
내 프로젝트에 도입하기
이제 실전이다.
아까 말했듯, 내 프로젝트는 세부 서비스가 3개이다.
이를 처리하기 위한 방식 중 모놀리식은 제외한다.
이유는 다음과 같다.
- 모놀리식으로 처리하려면 라우팅으로 각 서비스를 전부 처리해야 하는데, SPA이기 때문에 용량이 커지면 성능 이슈가 생길 수도 있다.
- 컴포넌트가 너무 많아져서 파일 구조가 복잡해질 수 있다.
이제 멀티레포와 모노레포 중 선택할 단계인데, 여기서 또 내 프로젝트의 특성을 고려할 필요가 있다.
- MVP 단계 이후에도 세부 서비스가 늘어날 가능성이 적다.
- 각 서비스는 비슷한 코드나 같은 코드가 많아서 이를 활용해야 한다.
- 앞으로 기간이 한 달 정도 남아있다.
결론 - 멀티레포를 도입하자
결론 도출 과정은 다음과 같다.
모노레포를 갔을 때, 공통 패키지를 더 설치할 필요가 없는 것은 좋다. eslint, prettier 등의 설치를 고려 안 해도 된다는 것은 확실히 매력적이다. 하지만 모노레포 환경을 만들기 위해 과제가 생긴다.
- 젠킨스를 어떻게 처리할 것인가?
현재 젠킨스를 통해 자동 배포를 처리하고 있는데, 젠킨스 설정에선 레포에 대해 브랜치만 설정할 수 있다. - 도구 선택
무지성 yarn workspace 쓰자고 선택해도 처음 하는 세팅이니만큼 생각보다 오래 걸릴 수 있다.
이에 반해 멀티레포 환경 조성은 어렵지 않다. 총 세부 서비스가 3개이기 때문에, 레포지토리 2개를 더 만들고, 젠킨스 파이프라인 생성, 그리고 추가된 빌드 파일을 도커 마운팅하고 nginx 설정만 해주면 된다.
따라서 이번 프로젝트에선 멀티레포를 도입하기로 결정했다. 하지만 다음 프로젝트에는 경험을 위해서라도 모노레포 방식을 도입해 보고 싶다.
