Monorepo
버전 관리 시스템에서 모노레포는 많은 프로젝트의 코드가 동일한 리포지토리에 저장되는 소프트웨어 개발 전략입니다. 2017년을 기준으로 이 소프트웨어 엔지니어링 방식은 20년이 넘었으며 '공유 코드베이스'라고도 합니다.
Monorepo Projects
다양한 솔루션들이 있지만, 각자 목표가 다름.
- Monorepo
- Bazel (by Google) - A fast, scalable, multi-language and extensible build system.
- Gradle (by Gradle, Inc) - A fast, flexible polyglot build system designed for multi-project builds.
- Lage (by Microsoft) - Task runner in JS monorepos
- Lerna - A tool for managing JavaScript projects with multiple packages.
- Nx (by Nrwl) - Next generation build system with first class monorepo support and powerful integrations.
- Rush (by microsoft) - Geared for large monorepos with lots of teams and projects. Part of the Rush Stack family of projects.
- Turborepo (by Vercel) - The high-performance build system for JavaScript & TypeScript codebases.
- Pants
- Earthly
Monorepo 빌드 도구 선택
- [원본] Monorepo Explained
Monorepo란 무엇인가
여러 개의 개별 프로젝트를, 잘 정의된 관계를 통해서 하나의 Repo에 담은 것
Monorepo != Monolith
왜 해야할까?
기존의 Polyrepo(여러개의 Repo를 사용하던 방식)를 선택한 이유는 "팀 자율성(team autonomy)" 때문이었음
팀들이 각자 원하는 라이브러리를 선택하고, 누가 코드에 기여하고 사용하는 지를 결정하는게 가능
- PolyRepo는
- 코드 공유가 번거로움
- 코드 중복이 많음
- 공유 라이브러리의 크리티컬 버그 및 큰 변경시 비용이 많이 듬
- 프로젝트별 일관되지 않은 개발도구 사용
- 새로운 프로젝트를 생성하는 오버헤드가 없음
- 전체 프로젝트에 걸침 아토믹 커밋
- 모든 것을 버전 번호 하나로 관리
- 개발자 모빌리티(프로젝트간 이동)
Monorepo 툴들이 제공하는 기능들과 각 도구간 비교
Bazel, Gradle, Lage, Lerna, Nx, Rush, Turborepo
- 로컬 캐슁
- 로컬 태스크 오케스트레이션
- 분산 캐슁
- 분산 태스크 실행
- 투명한 리모트 실행
- 영향받는 프로젝트/패키지 감지
- 워크스페이스 분석
- 종속성 그래프 시각화
- 코드 공유
- 일관적인 툴링
- 코드 생성
- 프로젝트 제약 및 가시성
인식의 전환
모노레포는 여러분의 "조직과 코드에 대해 생각하는 방식"을 바꿉니다
- 일관성을 추가하고,
- 새 프로젝트 생성할 때나 대규모 리팩토링을 수행할 때 마찰을 줄이며,
- 코드 공유 및 팀간 협업을 촉진함으로써
- 조직이 보다 효율적으로 작업할 수 있음
See also
Favorite site
- Wikipedia (en) Monorepo
- Monorepo? Yarn Workspace!. 🌸 모노레포. Lerna? Yarn Worksapce! | by 이봉 | Medium
- (디자인 패턴) 👆 Monorepo란?
- 생산적인 모노레포를 만들기 위한 필수 요소 | GeekNews
- [원문] The Ingredients of a Productive Monorepo
- 모노레포 도입은 조직의 일관성, 코드 공유, 공동 툴링 환경 강화 등 장점이 있으나, 빅테크 사례를 그대로 따라가면 새로운 문제와 도전에 직면하게 됨
- 성공적인 모노레포를 위해서는 모든 주요 작업을 O(repo)가 아닌 O(change) 로 만드는 원칙을 지켜야 하며, 빌드·테스트·CI/CD 각 단계에서 이에 맞는 도구와 전략이 필요함
- 소스 컨트롤은 git을 시작으로 규모가 커질수록 sparse checkout, 가상 파일시스템 등 점진적 확장 고려 필요
- 빌드 시스템은 가능한 한 단일 언어 유지, 각 언어의 기본 빌드 툴로 최대한 버티고, 꼭 필요할 때 Bazel/Buck2 등으로 점진적 전환 권장
- 테스트·CI/CD는 변화 영향 범위만 빠르게 감지하여 빌드·테스트·배포해야 하며, 대규모 모노레포에서는 테스트 자동 재시도, flaky test 격리 등 신뢰성 확보 전략도 필수