[Monorepo] 모노레포 그것이 답인가?

개발을 하다 보면 가끔 "모노레포"라는 단어를 들어본 적이 있을 것이다.

프로젝트를 관리할 때 모노레포로 구성하면 관리하기 편하다고 하지만, 경험상 모노레포 구조를 가진 프로젝트들은 결국 확장됨에 따라 분리하는 절차를 밟게 되었었다.

오늘은 모노레포가 탄생한 배경, 그리고 어떨 때 적용하라고 만든 구조인지 알아보도록 하겠다.

---

Monorepo와 Polyrepo

Monorepo는 말 그대로 Mono(하나의) + Repo(Repository), 즉 여러 애플리케이션이나 라이브러리를 하나의 저장소에서 관리하는 구조이다.

그럼 지금까지 사용해 왔던 Polyrepo의 어떤 점을 보완하고자 나온 구조일까?

우선 Polyrepo의 장단점에 대해 알아보자.

Polyrepo는 다중 저장소를 이용하는 구조로, 프로젝트마다 별도의 저장소를 이용하는 구조이다.

---

Polyrepo의 장점

• 각 프로젝트별 독립적인 모듈화가 가능하다.
• 배포에 유연하다.
• 서비스 수가 많아질수록 관리가 용이하다.

즉, 프로젝트들이 물리적으로 분리되어 있어 연관되지 않는 Merge 충돌과 같은 상황을 방지할 수 있는 등 물리적인 분리에서 오는 장점들이 존재한다.

---

Polyrepo의 단점

반대로 이러한 특징은 단점으로 적용되기도 한다.

• 공통 라이브러리의 버전 반영이 번거롭다.
• 프로젝트 간 동기화 및 호환성 유지가 어렵다.
• 코드 리뷰 및 CI/CD 구성이 분산되어 있어 설정 비용이 증가한다.

이런 단점들을 개선하고자 등장한 구조가 바로 Monorepo다.

---

Monorepo의 장점

Monorepo는 여러 프로젝트를 하나의 저장소에서 관리한다.
이는 특히 다음과 같은 상황에서 큰 장점을 가진다.

1. 공통 코드의 관리가 용이하다
   • 여러 서비스가 공통으로 사용하는 utils나 domain 모듈을 하나의 저장소에서 직접 수정 및 반영 가능
2. 원자적 변경(Atomic Change)이 가능하다
   • 여러 프로젝트에 걸친 인터페이스 변경도 하나의 커밋으로 처리 가능
3. 일관된 CI/CD 구성
   • 통합적인 CI 파이프라인 구성 가능, 디렉터리 기반 변경 감지 등 최적화 가능
4. 코드 가시성과 협업에 유리하다
   • 전체 구조를 한눈에 파악할 수 있어 신규 입사자나 타 팀원 간 협업 시 유리

---

Monorepo의 단점

물론 Monorepo도 단점이 있다.
가장 대표적인 문제는 스케일에 따른 복잡성 증가다.

1. 빌드 시간 증가
   • 빌드 시간이 오래 걸리며, 이를 해결하려면 Bazel, Nx, Turborepo 등의 도구 필요
2. 접근 제어의 어려움
   • 디렉터리 단위 접근 권한 설정이 어렵다
3. Git 성능 저하
   • 파일 수가 많아질수록 Git 자체가 느려질 수 있음
4. 심리적 복잡성
   • 전체 코드량이 많아지며 구조 파악에 부담을 줄 수 있음

---

Monorepo를 적용하기 좋은 상황

다음과 같은 경우에 Monorepo 구조는 적합하다.

• 여러 서비스가 같은 주기로 배포되고, 공통된 라이브러리를 사용하는 경우
• 초기 스타트업 환경처럼 팀 규모가 작고 변경이 잦은 경우
• 기능 단위의 동시 변경이 자주 필요한 경우
• 전체 시스템을 하나의 흐름에서 통합 관리하고 싶은 경우

반면, 대규모 서비스나 팀에서는 신중한 검토가 필요하다.
Google도 Monorepo를 사용하고 있지만, 이를 위해 독자적인 빌드 시스템과 버전 관리 시스템을 따로 구축한 사례다.

---

MultiModule 구조와의 비교

MultiModule은 주로 하나의 프로젝트 안에서 여러 기능을 모듈화해 관리하는 방식이다.
Java 기반의 프로젝트(Spring 등)에서 자주 볼 수 있다.
이 구조는 물리적으로는 Monorepo, 논리적으로는 Polyrepo와 유사한 형태를 갖는다.

MultiModule의 특징

• 하나의 Git 저장소 안에 여러 모듈 존재
• core, common, domain 같은 공통 모듈을 다른 모듈들이 참조
• 하나의 빌드 스크립트(Gradle 등)로 통합 관리

Monorepo vs MultiModule

항목	Monorepo	MultiModule
저장소 구조	여러 프로젝트를 하나의 저장소에서 관리	하나의 프로젝트 안에서 모듈로 분리
독립성	높은 유연성 (서비스 단위 프로젝트 존재 가능)	하나의 애플리케이션 중심 (빌드 및 배포 단위가 동일)
공통 코드 관리	공통 라이브러리를 독립 패키지로도 구성 가능	대부분 동일한 버전을 공유
빌드 관리	고급 도구 필요 (Bazel, Nx 등)	Gradle, Maven 기반 관리

즉, MultiModule은 단일 서비스 또는 애플리케이션의 모듈화를 위한 설계,
Monorepo는 복수의 애플리케이션 또는 서비스 단위까지 고려한 구조라는 차이가 있다.

---

마무리

정리하자면, Monorepo는 통합성과 효율성에서 큰 장점을 가지지만, 이를 유지하려면 명확한 설계 기준과 도구의 도움이 필요하다.
처음에는 편리하지만, 규모가 커지면 관리 비용도 함께 커진다는 점을 명심해야 한다.

 

Monorepo의 경우 Bazel과 같은 고급 도구가 필요한 만큼 팀과 프로젝트의 성격에 따라 Polyrepo, Monorepo, MultiModule 중 어떤 구조를 적용할지 신중하게 고민하여 적용하는 것이 필요하다 본다.