모노레포, 멀티레포란?

최근 모노레포라는 말을 여러 개발 커뮤니티에서 들을 수 있었다.

레포별로 다른 프로젝트를 운영하고 있으나,

새로운 서비스(프로젝트)를 구축하기 위한 비용이나 중복된 코드와, 프로젝트 관리에 대한 비효율 증가로 인해

모노레포로 돌리려는 것을 고안하고 있다 등의 내용이었다.

 

예전에는 백엔드 레포랑, 프론트엔드 레포를 따로 나눠서 별도의 리포지토리에서 관리하는 방식이 일반적이었다.

이렇게 각기 다른 레포에서 프로젝트를 관리하는 것을 멀티레포라고 하는데,

아무래도 프로젝트가 독립적으로 관리되므로, 프로젝트간의 의존성 문제가 줄어든다는 장점이 있다.

 

하지만 이제 그런 프로젝트들이 점점 대규모로 성장해가거나, 강력한 협업이 필요한 환경에서는 모노레포가 더 효율적일 수 있다.

그래서 모노레포와 멀티레포에 대해서 조사해봤다!

 

---

모노레포

=> 모든 프로젝트를 하나의 레포에서 관리하는 방식

장점

1. 코드 재사용성 : 여러 프로젝트에서 공통으로 사용하는 코드를 쉽게 재사용할 수 있다.

2. 일관된 코드 관리 : 하나의 레포에서 모든 코드를 관리함으로서, 코드 스타일과 품질을 일관되게 유지할 수 있다.

3. 간편한 의존성 관리 : 프로젝트 간 의존성을 명확히 하고, 업데이트를 쉽게 반영할 수 있다.

4. 단일 빌드 시스템 : 모든 프로젝트를 하나의 빌드 시스템으로 관리할 수 있어, 빌드 과정이 단순해진다.

5. 효율적인 코드 리뷰 : 코드 변경 사항을 전체적으로 파악하고 리뷰할 수 있어, 협업이 효율적이다.

 

단점

1. 복잡한 CI/CD 설정 : 여러 프로젝트를 하나의 레포에서 관리하다 보니, CI/CD 설정이 복잡해질 수 있다.

2. 빌드 시간 증가 : 레포 내 모든 프로젝트를 빌드해야 하므로 빌드 시간이 늘어날 수 있다.

3. 버전 관리의 어려움 : 프로젝트마다 버전이 다를 경우, 버전 관리를 체계적으로 해야한다.

4. 대규모 레포 관리 : 레포 크기가 커지면서 저장소의 성능 문제가 생길 수 있다.

---

멀티레포

=> 각 프로젝트를 별도의 리포지토리에서 관리하는 방식

장점

1. 프로젝트 독립성 : 각 프로젝트가 독립적으로 관리되므로 ,프로젝트 간의 의존성 문제가 줄어든다.

2. 단순한 접근 : 특정 프로젝트에만 접근해야 하는 팀원들에게는 접근 권한 관리가 더 단순하다.

3. 더 작은 레포 크기 : 각 레포가 작아서 관리가 용이하고, 클론과 빌드 속도가 빠르다.

4. 독립적인 배포 : 각 프로젝트를 독립적으로 배포할 수 있어 배포 주기가 더 짧고 유연하다.

5. 맞춤형 워크플로우 : 각 레포에 대해 독립적인 워크플로우와 도구를 사용할 수 있어 유연성이 높다.

단점

1. 의존성 관리의 복잡성: 프로젝트 간 의존성 관리가 복잡할 수 있다. 특히 공통 라이브러리를 사용하는 경우, 버전 관리와 업데이트가 번거로울 수 있다. / 공통 코드를 여러 리포지토리에서 중복 관리해야 하는 경우가 발생할 수 있다

2. 코드 공유의 어려움: 공통 코드나 모듈을 여러 리포지토리에서 공유하려면 별도의 패키지 관리 도구를 사용해야 한다. / 코드 변경 사항을 여러 리포지토리에 동기화해야 할 때, 추가 작업이 필요하다.

 

3. 일관성 유지의 어려움: 각 리포지토리마다 코드 스타일이나 품질을 일관되게 유지하기 어렵다. 팀 간 협업이 어려울 수 있으며, 프로젝트 간 통일된 코드 관리가 어렵다.

 

 

 

 

=> 각각의 방식마다 장단점이 있기 때문에 필요에 의해 개발 방향을 선택해야할 것 같다.

 

 

읽어본 글 : https://medium.com/musinsa-tech/journey-of-a-frontend-monorepo-8f5480b80661