Monorepo란
⭐ 여러개의 개발 프로젝트를, 잘 정의된 관계를 통해서 하나의 Repo에 담은것
- 새 project를 만드는데 편리
- 쉽게 다른 project에 기여 가능
monorepo와 monolith repo는 다름.
Monolithic은 project 끼리 분리가 안되있고 거대하지만 Monorepo는 repo만 하나 일 뿐 project끼린 분리가 잘 되어 있다.
페이지를 구분 없이 섞어서 구성하고 마구잡이로 참조해 독립이라는 느낌이 안드는 모듈화 없는방식이 Monolitic Repository라고 한다면, Monorepo는 페이지가 같은 리포지토리에 있지만 확실히 구분을 짓는다. 서로 패키지처럼 참조하도록하고 코드 내부에는 참견하지 않도록 구성한다.
⭐ 핵심은 모듈화
- 각 기능을 모듈로 잘 분리함으로써 캡슐화를 이룰 수 있다
- 기능이 잘 분리되어있으므로 대규모 프로젝트에서 수많은 코드를 들춰봐야 하는 수고를 줄인다.
- 소프트웨어 확장이 쉬워진다.
- 테스트가 쉬워지고, 모듈의 대체성을 높일 수 있으므로 A/B 테스트도 쉬워진다.
모듈화 자체는 PolyRepo로도 잘 구축할 수 있지만, MonoRepo의 각 패키지를 넘나드는 작업이나 서로 참조하기가 쉽다는 특징과 모듈화가 잘 합쳐지면 그 시너지가 크다.
Polyrepo
일반적으로는 하나의 리포지토리에 하나의 프로젝트가 들어가게 된다. 각 프로젝트는 자율성이 높으며 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인이 존재한다. 팀의 자율성이라는 큰 이유로 이 방식을 선호하지만 단점 또한 존재한다.
- 번거로운 프로젝트 생성
- 새로운 공유 패키지를 생성할 때마다 다음과 같이 번거로운 과정을 거친다.
- 저장소 생성 > 커미터 추가 > 개발 환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 publish
- 패키지의 중복 코드 가능성
- 위의 번거로움을 피하기 위해 각 프로젝트에서 공통 구성 요소를 자체적으로 작성한다면, 초기 시간을 아낄 수 있지만 시간이 지날수록 보안 및 품질 관리 부담을 증가시킨다.
- 관리 포인트 증가
- 늘어난 프로젝트 저장소의 수만큼 관리 포인트가 늘어난다. 린트, 테스트, 개발 모드 실행, 빌드, 게시, 배포 등의 과정을 저장소의 수만큼 반복해야 한다.
- 일관성 없는 개발자 경험(DX)
- 각 프로젝트는 테스트 실행, 빌드, 테스트, 린트, 배포 등을 위해 고유한 명령 집합을 사용한다. 이러한 불일치는 여러 프로젝트에서 사용할 명령을 기억해야 하는 정신적 오버헤드를 만든다.
- 다른 패키지의 변경 사항 파악
- 관련 패키지의 변화를 지켜보거나 통지받지 않으면 문제가 발생할 수 있다.
- 교차 저장소의 리팩터링 비용
- 관련 패키지의 변화가 있을 때 여러 저장소에 걸쳐 변화를 반영하는 것은 쉬운 일이 아닐 것이다.
참고 멀티리포 vs 모노리포
장점
⭐Unified Versioning
- 하나의 레포지토리는 버전 관리를 한 번에 할 수 있다. 여러 레포지토리로 굴러갈 때는 각자 버전을 관리하다보니 누락되거나 다른 레포지토리와 연결할 때 버전을 계속 확인 및 맞춰줘야 하는 귀찮음이 있다.
- 하지만 한 레포지토리로 관리하면 아예 버전을 하나로 관리하거나, 여러 모듈의 버전을 관리하기 수월해진다.
⭐Extensive Code Sharing & Reuse
- 가끔은 다른 팀이 만든 코드에 있는걸 사용해야 할 때가 있다. 이를 적절히 공유하고 재사용할 수 있으므로 업무 효율을 높일 수 있다.
⭐ Simplified Dependency Management
- 외부 라이브러리를 사용하는 경우도 분명히 있을텐데, 그런 외부 디펜던시의 버전을 맞추기 용이해진다. MonoRepo를 잘 사용하면 베이스 라이브러리만 변경되더라도 Final Product 단까지 잘 적용할 수 있다.
⭐Atomic Changes
- 변경 사항을 보다 Atomic하게 관리할 수 있다. (원자적이라는 말은 더 쪼개지지 않는, 그 중간 과정을 확인할 수 없다는 의미로 받아들이면 된다.)
- 만약 어떤 라이브러리 코드를 바꿔서, 이를 이용하고 있는 다른 PolyRepo 레포지토리들을 돌아다니면서 하나 바꾸고 커밋 찍고, 또 하나 바꾸고 커밋 찍고… 이런 과정이 연속적으로 이뤄지게 된다. 이런게 변화하는 중간 과정이 보인다고 생각할 수 있다. 만약 각 커밋마다 테스트가 돌아간다면 각 레포에서 커밋을 찍을 때마다 테스트가 터져서 마음이 아프기도 할 것이다.
- 하지만 MonoRepo로 하면 어떤 변경 사항을 여러 독립된 프로젝트에서 적용해야 하면 한번에 고쳐서 하나의 커밋으로 관리할 수 있다. 이걸 변화 과정이 원자적이라고 말할 수 있을 것이다.
⭐ Large Scale Refactoring
- 여러 독립적인 프로젝트에 적용되어야 하는 변화사항의 경우 각각 돌아다니면서 고치는 것보다는 한 레포지토리에서 고치는게 훨씬 쉽다.
⭐ Flexible Team Boundaries and Code Ownership
- 팀 간 협업이 자유로워진다. 서로 같은 코드 베이스에서 일하고 있기 때문에 변경 사항이 있거나 협업할 일이 있으면 보다 유연하게 코드를 왔다갔다 할 수 있다. 동시에 코드에 대한 Ownership도 자유로워질 것이다.
단점
⭐Dependency 충돌 문제
- 특정 패키지가 특정 버전의 모듈을 필요로 하는 경우, 다른 버전의 모듈을 사용하는 패키지와 Dependency 충돌이 발생할 수 있다.
⭐ 단일 리포지토리 문제
- 여러 프로젝트를 하나의 리포지토리에서 관리하기 때문에 오히려 관리가 어려워 질 수 있다.MonoRepo 로 관리하는 패키지가 많지 않을 경우에는 해당되지 않지만, 관리하는 패키지가 증가함에 따라 오히려 가독성이나 여러가지 측면에서 비효율적이게 될 수 있습니다.
⭐ 긴 초기 프로젝트 설정시간
- MonoRepo 로 포함되는 모든 프로젝트를 사용한다면 상관없지만, 그 중 일부만 필요한 경우에도 node_module 설치가 이루어져야 한다.
참고
팀규모, 프로덕트 규모에 따라서 정하는 것이 적절하다.
대규모 회사 또는 프로덕트를 가진 경우에는 어려 프로젝트를 한 개발팀이 담당할 경우가 많기 때문에 이런 경우에 MonoRepo를 사용하는 것이 좋다.
