[TIL] 모노레포 개념편

모노레포 정의

모노레포란 버전 관리 시스템에서 두 개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략

전략이다. 전략

모노레포 등장 배경

모놀리식 애플리케이션의 한계 때문에 나왔다.

모놀리식이란 모듈화 없이 설계된 소프트웨어 애플리케이션을 말한다.

모놀리식 구조의 한계는 모듈화를 통해 해결이 가능한데 이것이 멀티레포.

멀티레포 구조 = 폴리레포 구조 동일한 말이다. 분리된 각 모듈은 멀티레포 구조에서 고유한 저장소가 있는 독자적인 프로젝트가 되는데 각 프로젝트는 자율성이 높고 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인이 존재한다.

이러한 멀티레포의 문제점은 번거로운 프로젝트 생성임.

프로젝트를 새로 진행할 때마다 매번 똑같은 비슷한 코드 뿐만 아니라 다음과 같은 번거로운 과정을 거쳐야한다.

저장소 생성 > 커미터 추가 > 개발 환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 퍼블리시

• 패키지 중복 코드 가능성 증가
• 관리 포인트 증가
• 일관성 없는 개발자 경험
• 다른 패키지의 변경 사항 파악 문제
• 교차 저장소의 리팩터링 비용

이러한 것들을 해결하려는 노력의 결실이 모노레포가 나타난 배경이다.

하지만 단순히 여러 프로젝트가 하나의 저장소를 사용한다고 해서 모노레포 구조라고 부르기에는 부족함.

흔히 모노레포에서는 프로젝트 사이에 의존성이 존재하거나 같은 제품군이거나 하는 정의된 관계가 존재한다.

모노레포 구축을 도와주는 툴

• Lerna
• Yarn
• npm
• pnpm
• Nx

만족도는 pnpm이 가장 높았다.

모노레포를 구축하려고 할 때 관리 용이성, 속도 그리고 프로젝트 구조 관리 측면에서 고려해야한다.

1. 관리 측면

• 코드 공유: 서로 다른 프로젝트 간에 쉽게 소스 코드를 공유한다.
• 일관성 있는 도구: 서로 다른 프로젝트들에서 일관된 개발 경험을 제공한다.
• 스케폴딩: 새로운 프로젝트를 생성할 때 초기 코드를 쉽게 생성한다.
• 프로젝트 제약 및 가시성: 저장소 내에서 의존 관계를 제한하는 규칙 정의 지원. 예를 들어 일부 프로젝트를 팀 전용으로 표시하거나 특정 프레임워크를 사용 중임을 기술한다.

2. 속도 측면

• 로컬 캐싱: 같은 머신에서 같은 것을 두 번 빌드하거나 테스트하지 않는다.
• 분산 캐싱: 다양한 환경에서 캐시 아티팩트를 공유한다. 즉, 조직 단위로 여러 CI 환경에 걸쳐 같은 것을 두 번 빌드, 테스트하지 않는다.
• 로컬 작업 오케스트레이션: 빌드 및 테스트 등의 작업을 순서에 맞게 병렬로 실행한다.
• 변화에 영향을 받는 프로젝트 감지: 변경의 영향을 받을 수 있는 항목을 결정하여 영향을 받는 프로젝트만 빌드/테스트

3. 구조 파악 측면

• 워크스페이스 분석: 추가 구성 없이 주워진 워크 스페이스의 의존성 관계를 분석한다.
• 의존성 그래프 시각화: 프로젝트 및 작업 간의 종속 관계를 시각화한다.

모노레포의 오해

• 다른 팀이 내가 모르는 사이에 내 코드를 변경한다면?

깃 헙에는 codeowners와 같은 기능을 사용해 폴더 기반으로 소유권을 구성할 수 있다.

@global-owner1 @global-owner2 ## 이 저장소에 대한 모든 PR을 소유자에게 리뷰받아야 머지할 수 있다. 
packages/todo-api @john @jane ## todo-api 경로는 john과 jane에게 리뷰받아야한다. 
packages/i18n/* @michael ## i18n은 michael에게 리뷰받아야 한다.