모노레포

1. 도입 배경

하나의 기업에서 여러 개의 서비스를 운영 중인 상황을 가정해보자.

원래는 하나의 레포에서 하나의 서비스만을 관리 하지만 작업을 하다보면 때때로 서로의 레포에서 작업을 해야하는 상황이 있다.

현대의 개발 환경에서는 여러 프로젝트와 라이브러리가 상호 의존하면서 동작하는 경우가 많다. 이런 복잡한 환경에서 모노레포를 이용하면 통합적인 관점에서 코드의 일관성을 유지하고, 팀 간의 협업을 강화할 수 있다. 또한, 하나의 저장소에서 전체 코드베이스를 관리함으로써 리팩토링이나 대규모 변경 사항을 더욱 효과적으로 처리할 수 있다. 이러한 장점들로 인해 모노레포는 현대 프론트엔드 개발 트렌드 중 하나로 자리 잡았다.

예시

1. 한 레포에서 유저가 직접 볼 수 있는 상품 페이지와, 상품에 대한 정보를 관리할 수 있는 어드민 페이지를 같이 묶고 있다.
2. 이 경우는 상품 페이지와 어드민 페이지가 같은 레포지토리에는 있지만, 확실히 구분짓는다. 만약 상품 페이지 쪽에서 만든 로직이 어드민 페이지에서도 필요하다면, 이를 서로 패키지처럼 참조하도록 하고 각자의 코드 내부에는 참견하지 않도록 구성할 수 있다.

프로젝트마다 다른 컨벤션 ( 코드, git/브랜치 )

• 프로젝트마다 서로 다른 린트 환경과 코드 패턴들 (eslint, prettier, stylelint, tsconfig)
• 프로젝트마다 다른 라이브러리/프레임 워크 사용

새로운 서비스를 구축하기 위한 비용

• 새로운 프로젝트를 생성할 때마다 발생하는 보일러 플레이팅
• 재사용할 수 있는 컴포넌트, UI 등

중복된 코드와, 프로젝트 관리와 버전 관리

• 각 서비스에서 사용하는 프로젝트의 라이브러리 버전이 통일되지 않음
• 공통 컴포넌트, 정책에 변경 사항이 생겼을 경우 모든 레포 담당자에게 수정 요청

❌ 물론 단점도 있다.

• 개발 및 실행에 필요한 환경을 구성하는데 투자를 해야 한다. - 초대형 프로젝트의 경우
• legacy dependency
• code ownership - 유연하지만 책임이 분산되기도 한다.

2. 도입

유지 보수와 최적화 작업 간소화

재사용되는 UI 컴포넌트나 유틸리티 함수가 있을 때, 모노레포를 사용해서 한 번에 관리할 수가 있다.

핵심 - 모듈화

위 이미지를 보면 Monolithic과 Modular의 차이를 단적으로 보여주고 있다. Modular App Repo에서는 라이브러리 코드, 재사용할 수 있는 컴포넌트, 그리고 이를 이용해서 페이지를 만들어내고 있다. 예로 상품 페이지와 어드민 페이지가 분리된다면 저 App Routable Components가 두 개가 된다고 생각하면 될 것이다.

여기서 App을 구성하는 페이지도 하나의 패키지로, 재사용할 컴포넌트들을 담은 것들을 또 하나의 패키지로, 라이브러리 코드들도 하나의 패키지로 구분해서 사용할 수 있다.

도입 과정

모노레포 구성기

• 참고 링크