등장과 배경

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

이러한 개발전략은 고전적인 개발방식인 모놀리식 애플리케이션의 한계에대한 비판에서 시작한다

소스코드가 모듈화 없이 하나의 프로젝트로 관리된다는것이 모놀리식 애플리케이션이다. 코드가 서로 직접 의존하며 단 하나의 버전으로 관리되며 관심사의 분리또한 어려워지며, 설계, 리팩토링, 배포 등등 하나의 작업을 하기위해 거대한 단위로 다가오기때문에 심적 불안감과 많은 제약사항이 존재하게된다.

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

모듈화를 했지만 다른 프로젝트에서도 재사용이 가능할 수 도 있는 소스라면 어디에 위치시켜야하는지 고민을 하게된다. 아마 독자적인 저장서고 있으면 관리하기가 용이했을것이고, 재직중인 회사에서 좋은 예시로 hul(hutom ui library)가 있었다.

멀티레포

폴리레포 구조라고도 불리는 멀티레포는 앞선 예시가 된다.

각 프로젝트는 자율성이 높아 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인이 존재한다.

하지만 멀티레포에도 단점이 존재하는데 각 모듈들이 독자적인 개발을 진행하기때문에 자율성이 너무 높다는점이다.

Untitled

자율성이 높음에따라 고립이 생기고 고립에 의해 협업이 방해된다는 단점이 존재한다.