모노레포란?
모노레포(Monorepo)를 간단히 말하면, 서버와 클라이언트 코드가 한 저장소(Repository)에 같이 있는 것을 뜻한다
각각의 코드베이스를 별도의 저장소로 관리하는 멀티레포(Multirepo)와는 달리, 하나의 저장소에서 모든 관련 프로젝트를 통합적으로 관리하는 방식이다
모노레포의 장점
- 코드 공유: 서버와 클라이언트가 같은 저장소에 있으므로, 공통된 코드를 쉽게 재사용
- 일관된 버전 관리: 한 저장소에서 관리되므로 의존성 버전 충돌을 줄임
- 일관된 개발 환경: 서버와 클라이언트 간의 개발 환경을 동일하게 유지
- 간편한 CI/CD: 한 저장소에서 빌드와 테스트 파이프라인 설정 과정 단순화
모노레포의 단점
- 저장소 크기 증가: 대규모 프로젝트에서 저장소 크기가 커지고 클론, 빌드, 테스트 시간이 증가
- 의존성 관리 복잡성: 하나의 프로젝트에서 특정 의존성을 업데이트시 다른 프로젝트에 영향을 미칠 수 있음
- 권한 관리 어려움: 모든 프로젝트가 한 저장소에 있으므로 프로젝트별 접근 권한 관리가 어려움
해결 방안
- Monorepo 도구 사용: Nx, Bazel 같은 도구를 사용해 필요한 부분만 빌드, 테스트
- 의존성 관리: Lerna, Yarn Workspaces 등을 통해 독립적인 의존성 관리 구현
- 권한 분리: GitHub CODEOWNERS 파일로 디렉토리별 권한 설정
멀티레포란?
멀티레포(Multirepo)는 각 프로젝트를 독립적으로 별도의 저장소에서 관리하는 방식을 뜻한다
서버와 클라이언트 코드, 공통 라이브러리 등이 각기 다른 저장소에 저장되며, 필요할 때만 의존성을 가져와 사용하는 형태이다
멀티레포의 장점
- 독립적인 배포 및 개발: 특정 프로젝트만 선택적으로 업데이트하거나 배포하기 쉬움 (각 팀이 다른 팀의 코드베이스에 의존하지 않고 빠르게 개발 및 배포 가능)
- 프로젝트 분리: 각 코드베이스가 독립적으로 관리되므로 프로젝트 간 영향도 낮아짐 하나의 저장소에서 발생한 문제가 다른 프로젝트에 영향을 주지 않음
- 다양한 기술 스택 관리: 서로 다른 언어나 빌드 도구를 사용하는 프로젝트 간 충돌을 방지
멀티레포의 단점
- 공통 코드 관리 어려움: 공통 라이브러리나 설정을 동기화하기 까다로움
- 의존성 관리 복잡: 공통으로 사용하는 라이브러리나 설정 파일을 여러 저장소에 중복 관리해야 할 때 버전 충돌 가능성 있음 (A와 B 프로젝트가 동일한 공통 라이브러리를 사용하는데, A는 라이브러리의 최신 버전을 요구하고 B는 이전 버전을 유지해야 할때)
해결방안
- 공통 코드 관리: 각 저장소에서 사용하는 공통 코드를 별도의 라이브러리로 추출하고, NPM 패키지나 PyPI 같은 패키지 관리 시스템에 배포하여 버전 관리를 체계적으로 수행
- 의존성 관리 자동화: Dependabot이나 Renovate 같은 도구를 사용해 각 저장소의 의존성을 자동으로 업데이트하고 충돌을 최소화
모노레포 vs 멀티레포
모노레포 | 멀티레포 | |
저장소 구조 | 하나의 저장소 | 여러 개의 저장소 |
공통 코드 관리 | 쉬움 | 어려움 |
프로젝트 독립성 | 낮음 | 높음 |
CI/CD 설정 | 간단 | 프로젝트별 설정 필요 |
모노레포를 사용하는 회사
- Google: 대규모 코드를 모노레포 방식으로 관리하며, Bazel 같은 빌드 도구를 사용
- Facebook: 모든 프로젝트를 모노레포 방식으로 관리하여 일관된 코드베이스 유지
- Uber: 여러 플랫폼에서 공통 코드를 효율적으로 관리하기 위해 모노레포를 채택
멀티레포를 사용하는 회사
- Amazon: 서비스가 분리된 독립적인 팀 구조(소위 "Two Pizza Team")를 기반으로 멀티레포를 사용
- Netflix: 독립된 마이크로서비스 아키텍처를 채택하여 각 서비스가 별도의 저장소에서 관리됨
- Microsoft: Windows, Office 등 여러 제품군을 개별적으로 관리하기 위해 멀티레포를 활용
모노레포와 멀티레포의 선택 기준
- 모노레포: 프로젝트 간 강한 연관성이 있거나, 공통 코드를 많이 공유해야 하는 경우
- 멀티레포: 각 프로젝트가 독립적이며, 팀별로 자유로운 기술 선택과 관리가 필요한 경우
장단점이 명확하기 때문에, 회사의 팀 구조와 프로젝트 요구 사항에 따라 선택하는것이 좋겠다!
(상세한 내용은 참고 자료 링크 모던 프론트엔드 프로젝트 구성 기법 - 모노레포 개념 편에 더 자세히 나와있다)
참고자료, 이미지 출처
'궁금한게 많은 백구스 > Git&GitHub' 카테고리의 다른 글
[Git&GitHub] branch 꼬임 방지, git pull 오류 해결법 (0) | 2022.12.27 |
---|---|
[Git&GitHub] fatal: not a git repository 에러 나는 이유, 해결 (0) | 2022.12.17 |
[Git&GitHub] 잘못 push 푸시한 파일 삭제하기ㅋㅋ, push 되돌리기 (0) | 2022.12.16 |
[Git&GitHub] git commit --amend 깃 커밋 어멘드 커밋 메세지 덮어쓰기 하는 법 (0) | 2022.12.12 |
[Git&GitHub]깃,깃허브 공부는 어떻게 해야할까?_Do it! 지옥에서 온 문서 관리자 깃&깃허브 입문[전면 개정판] (0) | 2022.10.28 |