카테고리
게시일
Jan 2, 2026
모노레포 vs 멀티레포(폴리레포)
- 연관된 서비스나 프로젝트를 각각 따로 Repository를 만들고 관리하는 것을 멀티레포라고 한다.
- 연관된 서비스나 프로젝트를 전부 한 Repository로 관리하는 것을 모노레포라고 한다.
많은 오픈소스 프로젝트들이 멀티레포를 사용하다 모노레포로 옮겨가는 추세이다.
왜 모노레포를 쓰는가?
CI/CD 관점에서, 즉 통합과 배포하는 관점에서 모노레포는 굉장히 불편할 것 같다. 왜냐하면 쓸데없이 개발자마다 필요한 레포지토리만 받는 것이 아니라 전부 받아야 하며, Github Actions라던지 Jenkins같은 tool code도 각기 다른 프로젝트 것들이 전부 들어가는데, 각자 프로젝트마다 꼬이지 않도록 잘 설정해줘야 하기 때문이다.
모노레포를 쓰는 이유는 통합된 버전 관리를 배포 단위로 하기 용이하기 때문이다.
즉, 여러 프로젝트를 하나의 저장소에서 관리함으로써 하나의 Integration & Deploy 프로세스를 모든 프로젝트가 동시에 공유하고 진행할 수 있다.
따라서 모노레포의 가장 큰 목적은 단순히 코드를 한 레포에 두는 것에 있는것이 아니라, Integration & Deploy 프로세스를 통합하는 데 있으며, 이게 충족되지 않는다면 모노레포를 사용하는 실질적인 효과는 크지 않다.
말로만 해서는 잘 이해가 가지 않을 것이다. Multirepo와 비교해서 왜 Monorepo가 CI/CD 통합에 효과적인지 살펴보자.
멀티레포에서 버전관리
서비스 A와 B가 각각의 레포지토리에서 관리되고, 각자 Deploy 프로세스를 가지는 멀티레포를 가정하자. 각자 서비스를 개발하는 두 팀이 배포를 할 때, 두 서비스의 배포 시점이 달라 호환성 문제가 발생할 수 있다.
이걸 방지하기 위해 서비스 A와 B를 함께 사용하는 자동화된 배포를 하려면
- 별도의 Deploy 전용 레포를 새로 만들거나
- A 쪽에서 B를 제어하는 구조를 추가해야 한다.
그럼에도 불구하고 두 레포의 커밋 히스토리는 완전히 분리되어 쌓이기 때문에, 이후 이전 배포 시점의 버전을 비교하려면 GitHub Milestone, Release 등의 기능을 사용해 개발자가 수동으로 히스토리를 맞춰봐야 한다.
모노레포에서 버전관리
모노레포를 사용하면 두 서비스의 히스토리가 배포 단위로 자연스럽게 합쳐진다.
- 각 서비스는 독립적으로 개발되고, 단위 테스트를 수행한다.
- 이후 각 서비스의 변경 사항이 하나의 milestone을 향해 병합된다.
main브랜치로 push가 발생하면,
모노레포에 정의된 통합 Deploy 프로세스가 실행되어 모든 서비스가 동시에 배포된다.
- 나중에 커밋 히스토리를 살펴볼 때도,
레포 여러 개를 뒤져 커밋 시점을 맞출 필요 없이
하나의 커밋만으로 모든 서비스가 서로 호환되는 동일 버전을 확인할 수 있다.
비교 정리
- 멀티레포는 설정은 비교적 간편하지만 통합, 배포할 때 애로사항이 있음
- 모노레포는 초기 설정이 조금 힘들 수 있지만, 통합, 배포시 편하고 히스토리 비교도 편함
- 근데 모노레포 쓸 때 통합된 CI/CD가 제대로 돌아가지 않는다면 안쓰느니만 못할 수 있다.
- 그리고 프로젝트가 너무 거대하다면 모노레포 대신 멀티레포를 써야할 수도 있다.