모노레포 (monorepo)

• 버전 관리 시스템에서 두 개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략
• 모노레포로 운영중인 회사들 : Google, Meta(Facebook), MicroSoft, Uber, Airbnb, Twitter 등..

👉 모노레포를 사용하는 이유

• 거대 서비스를 개발할 때, 소스 코드가 모듈화 없이 하나의 프로젝트로 구성된다면, 코드가 서로 직접적으로 의존하며 단 하나의 버전으로 관리되면서 관심 분리(separation of concerns)가 어려워지고, 설계, 리팩터링, 배포 등의 작업을 매번 거대한 단위로 처리해야 하므로 개발상 많은 제약과 비효율적이게 된다.
• 모노레포는 하나의 기때문에 더욱 효율적으로 관리할 수 있다.

👉 모노레포의 특징

1. 각 프로젝트는 자율성이 높으며 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인이 존재
2. 멀티레포에서처럼 분리된 모듈들은 모노레포안에서 여전히 독자 프로젝트로 존재하지만 저장소는 같은 곳을 사용한다.
3. 모듈을 적절히 분리하여 관심 분리를 이루면서, 동시에 분리된 모듈을 쉽게 참조하고 테스트, 빌드, 배포 과정도 쉽게 한 번에 할 수 있다.
4. 단순히 여러 프로젝트가 하나의 레포를 사용한다고 해서 모노레포인 것 아님!! -> 모노레포에서는 프로젝트 사이에 의존성이 존재하거나 같은 제품군이거나 하는 정의된 관계가 존재함.
5. 테스트 및 빌드 범위 최소화
   • 소스 변경 시 모든 프로젝트를 다시 빌드하거나 다시 테스트하지 않는다. 대신 변경 사항의 영향을 받는 프로젝트만 다시 테스트하고 빌드한다.

👉 모노레포가 해결하는 멀티레포의 문제

• 더 쉬운 프로젝트 생성
• 더 쉬운 의존성 관리
• 단일화된 관리 포인트 : 개발환경 및 DevOps에 대한 업데이트를 한 번에 반영할 수 있다.
• 일관된 개발자 경험 제공 : 애플리케이션을 일관되게 구축하고 테스트할 수 있다.
• 프로젝트들에 걸친 원자적 커밋 : 변경 사항의 영향을 받는 조직에서 쉽게 변화를 확인가능.
• 서로 의존하는 저장소들의 리팩터링 비용 감소

모노레포가 적절한 상황

🤷🏻‍♀️ 항상 모노레포가 훨씬 좋은 것은 아님!! 상황에 따라 플젝에 따라~

• 유사한 제품의 집합
• 여러 프로젝트의 변화를 한눈에 파악해야 할 때
• 호스트 애플리케이션을 플러그인 등으로 확장할 때
• 공통 기능을 재사용하는 관련된 프로젝트의 집합
• 유사한 DevOps로 구성된 프로젝트의 집합

• 모노레포 구축을 도와주는 도구
  - Lerna, Yarn, npm, pnpm, Nx 등이 많이 사용됨.

---

멀티레포(multirepo)

= 폴리레포(polyrepo)

• 현재 대부분의 애플리케이션을 개발하는 표준적인 방법
• 팀의 자율성이라는 큰 이유 때문에 이 방식을 선호하기도 한다.
• 그 팀의 자율성 때문에 협업하기에는 불편하다.

👉 멀티레포의 단점

• 번거로운 프로젝트 생성
  - 새로운 공유 패키지를 생성할 때마다 저장소 생성 > 커미터 추가 > 개발 환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 publish의 번거로운 과정을 거쳐야 한다.
• 중복 코드의 가능성
• 관리 포인트 증가
  - 늘어난 프로젝트 저장소의 수만큼 관리 포인트가 늘어난다. 린트, 테스트, 개발 모드 실행, 빌드, 게시, 배포 등의 과정을 저장소의 수만큼 반복
• 일관성 없는 개발자 경험(DX)
• 다른 패키지의 변경 사항 파악 : 매번 파악햐야 됨.
• 교차 저장소의 리팩터링 비용

---

모노레포 참고
사용량 참고