모노레포

모노레포란 버전 관리 시스템에서 두개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략.

2024년 프론트엔드 생태계에 유행한 개발 전략중에 Monorepo 라는 전략이 되게 유행을 했었다. 전통적으로 각 프로젝트나 라이브러리마다 별도의 저장소를 생성하여 관리하던 멀티레포 방식에서 하나의 저장소만 이용하여 여러개의 프로젝트를 관리하는 방식이 테크 기업들 사이에서 코드 재사용성 , 버전 관리 , 종속성 관리 등의 장점이 있다는 이유로 많은 채택을 받았었는데

모던 프론트엔드 개발 환경상 여러개의 프로젝트와 라이버리리에 의존성을 맺고 동작을 하는 경우가 되게 많은데 이걸 하나의 저장소에서 운영하여 코드의 일관성을 유지시키고 , 각 팀간의 규칙을 통일하여 협업을 강화하는등 리팩토링 측면에서도 효과적으로 처리할수도 있다.

단 저장소의 크기가 증가되면서 어느정도 깃에 대한 숙련도를 요구하게 되며 CI/CD 파이프라인관리라던지 모노 레포 관리 도구의 학습도 어느정도 필요하다는 단점이 있다.

그렇다면 모노레포는 그냥 무작정 같은 저장소에 여러개의 프로젝트를 넣어도될까? 그래도 되긴하겠지만 모노레포를 위한 편리한 도구들도 존재한다.

Lerna : 패키지 게시 , 버전 관리 의존성 관리 기능을 제공해주는 도구
Nx : Angular 팀에서 개발한 의존성 그래프 분석 , 캐싱 및 영향 분석으로 빌드 성능 최적화 기능을 제공해주는 도구
Turborepo : Vercel 에서 개발한 캐싱전략으로 빌드 성능 최적화 , 간편한 설정등을 제공하는 도구
Yarn Workspaces : Yarn 패키지 매니저의 내장기능 , 여러 패키지 간의 의존성 관리 단순화 기능을 제공해주는 도구

등등 여러개의 인기 모노레포 프레임워크들이 존재한다.

모던 웹 개발에서는 하나의 서비스만을 제공하던 과거에서 여러개의 서비스를 제공해주는 미래로 온 만큼 마이크로서비스 아키텍처의 인기 상승으로 여러 서비스 간의 코드 공유와 일관성이 중요해졌습니다 그리고 여러 패키지, 설정 파일을 관리성도 중요해진 만큼 동일한 밑작업을 반복하기보단 하나의 모노레포안에서 밑작업을 끝낸후 여러 팀들의 통일성을 높히는 전략이 엄청난 인기를 끌면서 2024년 트랜드로 자리잡은것 같습니다.

모노레포를 사용할땐 그만큼 아 이게 팀간의 협업과 코드 통일성의 이유로 만들어진 만큼 공통적으로 사용하는 모듈의 분리와 코드 규칙의 준수등을 잘 지켜야 된다고 생각합니다.