[122일차] 모노레포와 멀티레포

 

 

보통 처음 프로젝트를 시작할 때, 레포지토리를 분리할지 혹은 하나의 레포지토리 내에서 프로젝트를 관리할지 선택하게 된다.

 

프로젝트 규모가 작을 때는 크게 고민하지 않을 수 있지만, 프로젝트가 커지고 서비스가 여러 개로 분리되기 시작하면 코드 관리 방식이 협업 효율과 유지보수에 큰 영향을 미치게 된다.

 

이때 사용되는 대표적인 개념이 모노레포(Monorepo)와 멀티레포(Multi Repo)이다.
또한 최근에는 모노레포 환경에서 효율적인 개발을 돕는 Turborepo와 같은 도구도 함께 사용된다.

 

 

멀티레포 (Multi Repo, Poly Repo)

멀티레포는 각 프로젝트를 독립적인 저장소에서 관리되는 구조이다. 독립적으로 관리하기 때문에 프로젝트 간의 의존성을 줄일 수 있다.

보통 전통적으로 사용되는 레포 구조이기도 하다. 

https://velog.io/@miso1489/%EB%AA%A8%EB%85%B8%EB%A0%88%ED%8F%AC%EC%99%80-%EB%A9%80%ED%8B%B0%EB%A0%88%ED%8F%AC

멀티레포 장점

1️⃣ 프로젝트 별 독립적 개발 가능, 각 프로젝트 특성에 맞게 최적화 가능

2️⃣ 소규모 프로젝트나 독립적인 개발이 필요한 경우 적합

3️⃣ CI/CD 파이프라인 단순: 빌드, 테스트, 배포 파이프라인을 프로젝트 단위로 구성하기 때문

 

멀티레포 단점

1️⃣ 코드 재사용 및 공유 어려움: 공통으로 사용되는 코드를 각 저장소에 복사해서 사용해야 함

2️⃣ 의존성 관리 복잡성: 동일한 라이브러리를 사용할 때 버전 관리를 동일하게 맞춰야 되므로 개발 비용이 늘어남

3️⃣ 협업의 불편함: 코드 컨벤션 통일 어려움

 

이를 보완하기 위해 나온 개념이 모노레포이다.

 

 

 

모노레포 (Mono Repo)

모노레포는 여러 프로젝트를 하나의 Git 저장소에서 관리하는 구조이다. 즉, 하나의 저장소 안에 여러 애플리케이션과 패키지를 함께 포함하는 방식이다. 

최근에는 대규모 서비스에서 코드 공유와 협업 효율을 높이기 위해 모노레포를 사용하는 경우가 점점 늘어나고 있다.

repo
 ├ apps
 │   ├ web
 │   ├ admin
 │   └ mobile
 │
 ├ packages
 │   ├ ui
 │   ├ utils
 │   └ config

https://velog.io/@miso1489/%EB%AA%A8%EB%85%B8%EB%A0%88%ED%8F%AC%EC%99%80-%EB%A9%80%ED%8B%B0%EB%A0%88%ED%8F%AC

 

모노레포 장점

1️⃣ 코드 공유 및 재사용성 향상: 공통 코드를 한 곳에서 관리하기 때문

2️⃣ 일관된 버전 관리: 프로젝트 전체의 의존성을 하나의 레포에서 관리하기 때문에 동일한 버전의 라이브러리를 사용하게 됨

3️⃣ 개발 환경 통일: 동일한 lint 규칙 적용

4️⃣ 리팩토링과 변경 관리 용이

5️⃣ 협업 효율성 증가: 일관된 코딩 스타일과 패턴 유지 가능

 

모노레포 단점

1️⃣ 초기 설정 복잡

2️⃣ 높은 러닝커브

3️⃣ 코드 충돌 위험

4️⃣ 코드 관리 복잡성

5️⃣ 배포 복잡성

 

 

 

터보레포 (Turbo Repo)

터보레포는 모노레포 환경에서 효율적인 개발을 지원하는 고성능 빌드 시스템이다. 

모노레포에서는 여러 프로젝트가 하나의 저장소에 존재하기 때문에 모든 프로젝트를 매번 빌드하게 되면 시간이 오래 걸릴 수 있다.

터보레포는 이러한 문제를 해결하기 위해 작업 캐싱과 병렬 실행 기능을 제공한다.

최근에는 여러 애플리케이션이 공통 코드와 디자인 시스템을 공유하는 경우가 많아지면서, 모노레포와 Turborepo 같은 도구를 활용하는 방식이 점점 더 많이 사용되고 있다.

https://turborepo.dev/

 

터보레포 장점

1️⃣ 효율적인 빌드 시스템: 작업 결과를 캐싱하여 이미 실행된 작업을 다시 실행하지 않음

2️⃣ 병렬 실행: 여러 작업을 동시 실행하므로 작업 시간 단축

3️⃣ 변경된 프로젝트만 빌드: 변경된 패키지에 영향을 받는 프로젝트만 빌드하도록 관리

 

 

---

회고

기존에는 frontend 레포에서 서비스, 백오피스를 단순하게 도메인 분리를 통해서 구분하고 있었다. 멘토링에서 받았던 피드백인 레포 구조에 대해서 다시 생각해 보면서 레포 구조를 바꾸자는 의견이 나왔다. 우리 프로젝트가 이미 UI는 완성된 상태이며, 마감 기한까지 얼마 안 남은 상황이었기 때문에 비용과 시간이 그나마 덜한 멀티 레포 구조로 변경하게 되었다. 

멀티레포!

 

사실 계속 해왔던 방식만 생각해 왔어서 모노레포는 굳이 생각해보지 않았다. 처음부터 고민해 보고 결정했어야 되는 사항이었는데, 이를 간과했던 것 같아서 아쉽긴 하다.

그래도 이번을 계기로 모노레포에 대해서 학습했으니, 추후 팀프로젝트에서는 모노레포를 사용해봐도 좋을 것 같다는 생각이 들었다.

 

이제 어느덧 공채시즌이다.. 취뽀합시다

 

 

---

참고자료

https://velog.io/@miso1489/%EB%AA%A8%EB%85%B8%EB%A0%88%ED%8F%AC%EC%99%80-%EB%A9%80%ED%8B%B0%EB%A0%88%ED%8F%AC

모노레포 vs 멀티레포