[CS] 모노레포(monorepo)

✏️Monorepo

하나의 레포지토리에 여러 개의 프로젝트를 통합하여 관리하는 방식

 

모노레포의 등장배경

주로 대형 기업의 소프트웨어 개발 과정에서 발생하는 문제를 해결하기 위해 생기게 되었다.

대형 기업에서 수많은 개발자들이 수천, 수만 개의 프로젝트를 동시에 개발하고 관리해야 하는 상황이 발생하는데 이러한 상황에서 각각의 프로젝트를 독립된 레포지토리로 관리한다면 많은 문제가 발생할 수 있다.

 

1. 코드 재사용과 공유
동일한 기능이나 컴포넌트를 다른 프로젝트에서 사용하려면, 해당 코드를 복사하거나 공유 라이브러리를 만들어야 했다.  이는 코드 중복과 관리 비용의 증가를 초래하였다.

 

2. 의존성 관리
다수의 프로젝트 간에 의존성이 존재할 경우, 각각의 프로젝트를 독립적으로 관리하다 보면 의존성 버전 충돌이 발생할 수 있다.

 

3. 빌드와 배포의 어려움

 

기존의 모놀리식 구조의 한계는 모듈화를 통해 해결할 수 있다. 애플리케이션 로직의 일부를 재사용할 수 있도록 지원하고 전체 교체 없이 애플리케이션의 일부를 수정 또는 교체할 수 있게 하여 유지관리를 용이하게 한다.

이렇게 만든 모듈들을 위한 독자적인 저장소의 필요성을 느끼고 멀티레포라는 구조가 생기게 되었다. 분리된 각 모듈은 멀티레포 구조에서 고유한 저장소가 있는 독자적 프로젝트가 된다. 각 프로젝트는 자율성이 높으며 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인이 존재한다.

 

멀티레포의 문제

1. 번거로운 프로젝트 생성
새로운 공유 패키지를 생성할 때마다 저장소 생성 > 커미터 추가 > 개발 환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 Publish

 

2. 패키지의 중복 코드 가능성

위의 번거로움을 피하기 위해 각 프로젝트에서 공통 구성 요소를 자체적으로 작성한다면, 초기 시간을 아낄 수 있지만 시간이 지날수록 보안 및 품질 관리 부담을 증가시킨다.

 

3. 관리 포인트 증가

늘어난 프로젝트의 저장소 수만큼 관리 포인트가 늘어난다.

 

4.교차 저장소의 리팩토링 비용

 

모노레포의 특징

분리된 모듈들은 모노레포에서 여전히 독자 프로젝트로 존재하지만 저장소는 같은 곳을 사용한다.

 

1. 더 쉬운 프로젝트 생성

모노레포에서는 저장소 생성 및 커미터 추가 과정이 필요 없고, 개발 환경, CI/CD, 빌드, 게시 등의 과정에 기존 DevOps를 이용하므로 새 프로젝트 생성에 대한 오버헤드가 없다.

 

2. 더 쉬운 의존성 관리의존성 패키지가 같은 저장소에 있다.

 

3. 단일화된 관리 포인트개발환경 및 DevOps에 대한 업데이트를 한 번에 반영할 수 있다.

 

4. 일관된 개발자 경험 제공애플리케이션을 일관되게 구축하고 테스트할 수 있어 변경 사항이 안전 한지 확인할 수 있다.

 

5. 서로 의존하는 저장소들의 리팩터링 비용 감소

 

---

모노레포를 구축할 때 고려할 측면

1.프로젝트의 크기와 복잡도

프로젝트의 크기와 복잡도가 클수록, 모노레포에서의 관리가 더 복잡해질 수 있다. 

 

2. 팀의 구조와 커뮤니케이션

모노레포는 팀간의 협업을 촉진한다. 그러나 이는 팀원들 간의 충분한 커뮤니케이션과 합의가 필요하다.

 

3. 빌드 및 테스트 시간

전체 코드 베이스에 대한 빌드와 테스트가 필요하므로, 이 과정이 오래 걸릴 수 있어 효율적인 빌드와 테스트 전략이 필요하다.

 

4. 버전 관리와 의존성 관리

모노레포는 하나의 저장소에서 여러 프로젝트를 관리하므로, 각 프로젝트의 버전 관리와 의존성 관리가 중요하다.

 

5. 보안과 접근 제어

적절한 접근 제어와 보안 관리가 필요