들어가며
사내에서 프로젝트를 하며 프로젝트간의 컴포넌트 공유가 필요한 상황이 생겨 처음으로 모노레포를 접하게 됐다.
당시에 있던 프론트 시니어분이 한번 알아보고 진행해보자는 말에 도입하게 되었다.
기존의 멀티레포에서 불편하게 이루어지던 DRY 원칙이나 관심사 분리 패턴에 더 효과적인것같아 사용하게 되었고, 그때는 레퍼런스도 너무 없었고 나 역시 정제된 모노레포를 사용하진 못했지만 지금의 내가 80%에 가깝게 활용할 수 있는 아키텍쳐라 판단해 글을 작성하게 됐다.
모노레포란?
두 개 이상의 프로젝트 코드를 하나의 버전 관리 저장소에서 관리하는 개발 전략이다.
아래 이미지에서는 2개의 메인이 되는 패키지(각 프로젝트)
- todoApp Package Project
- calendarApp Package Projec
2개의 하위 패키지로 나눠놨다.
- todoApi Package Project
- i18n Package Project
메인 패키지만 있어도 작동은 될 수 있지만 2개의 하위 패키지 역시 빠질 수 없는 유틸리티이다.
하위 패키지를 함께 참조할수는 있지만 비즈니스적으로 분리되어 있는 경우 모노레포의 진가가 드러난다고 생각한다.
위처럼 중복되는 코드나 프로젝트간의 의존이 생길때 모노레포가 최적의 문제 해결 방법이 될 것이다.
하지만 각 패키지가 같은 Dependency를 참조하고 있는 경우에는 중복 참조가 생겨 node_modules에같은 라이브러리지만 다른 버전이 여러개 생기는 경우가 발생 할 수 있다.
특징
장점
- 중복되지 않는 코드
- 서로 같은 패키지의 의존성
- 서로 의존하는 프로젝트들끼리의 리팩터링 비용 절감
- 여러 프로젝트팀 간의 협업 용이
단점
- 무분별한 의존성 연결 가능
- 다른 버전의 같은 dependency가 여러 곳에서 사용되어, 과도한 의존 관계가 나타날 수 있다. - 형상 관리 및 CI 속도 저하
- 레포의 크기가 크기 때문에, 훅을 기반으로 동작하는 도구들의 속도가 느려진다.
직접적인 사용 방법이나 생산성 높이기 등등..의 이야기는 모노레포 시리즈로 이어집니다!
Reference
