모노레포에 대해 정리.

 

모놀리식 프로그램의 한계에 대해 비판으로 부터 시작된 방식.

하나의 싱글 워크스페이스에 여러 프로젝트들이 존재 하는 구조라고 볼 수 있음.

 

그렇다면 하나의 워크스페이스에 여러 프로젝트들이 존재하기만 하면 이것은 모노레포 일까?

각 프로젝트간의 유사성이 존재하고 이를 통해 프로젝트 관리의 유사성등 여러가지를 판단하여 

모노레포 라고 부르는듯 하다.

 

그렇다면 언제나 모노레포가 옳은 방식일까? 언제나 옳지 않을 수 있다. 일예로 모노레포의 장점은

결국 멀티레포의 단점을 말하고, 모노레포의 단점은 멀티레포의 장점이 되기 때문에 항상 옳은 방식이라고 할 수는 없다.

하지만. 워크스페이스 내의 프로젝트들이 유사성이 크게 존재하고 이때 프로젝트의 진행을 한번에 볼 수 있어야 하는 경우

 

모노레포를 이용해서 처리하는 것이 옳은 방식이다

위에서 적은 내용에서 조금 추가를 하면, 그렇다면 프로젝트는 각 프로젝트의 의존성을 가지게 될까? 아니면

저장소의 의존성을 받아서 동작하게 될까 저장소의 의존성을 가지고 있는다고 보면 될듯하다.

각각의 레포가 각기 다른 설정으로 동작하게 하여 관리를 안하다는 개념이 아닌것으로 보면 될 듯 하다.

 

 

https://d2.naver.com/helloworld/0923884

왼쪽과 같은 방식으로 워크스페이스 안에 여러 프로젝트들을 구성하며 

각 프로젝트들의 유사성이 존재하고 의존성등을 최상위 프로젝트에서 설정하여

레포에서의 의존성충돌등을 방지 할 수 있다. 

위와 같은 방식으로 동작을 처리하기 때문에 결국 

 

각 레포의 생성과 설정등이 쉽게 처리 되어야 하기 때문에 yarn, lerna, npm 등의 도구들을 이용해서 생산성의 효율을 높이는 추세 인듯 하다. 

 

 

 

 

스터디에서 배운 내용.

 

한프로젝트 같은 기능 -> 스타일 만 다름 (레포 분할이 되어있음)

앱 -> 웹 -> 회사 서비스 모두 같은 기능을 사용함.

기능 은 다르나 UI 공통적 모두 같은 컴포넌트를 사용함 

 

이와 같은 경우 모노레포를 사용하게 되면 생산성에서 많은 도움을 줄 수 있다.

 

하지만 모노레포를 사용하지 않아야할지 고민 해야 하는 경우가 존재 하고 이에 대해 기술 하도록 하겠다.

 

이미지를 말아서도 가능함. -> 일반적으로 서버에서 도커를 이용하여 작업하거나 

하는 방식을 이용한다고 함.

 

문제 1 :

 

서비스 < 마케팅 이 경우 레포를 만들때마다 비용이 발생함.

허나  공통의 UI 를 사용하고 이를 해결하기 위해서 추가적으로 사용 하는 경우가 발생함.

이 경우 새로운 레포를 사용하게 되면 레포를 지속적으로 파서 사용하게 되기 때문에 

 

같은 버전을 이용하는것이 확실하다면 npm 으로 모듈을 보내고 import.하는 방식의, 라이브러리화를

통해서 처리 할 수 있다. 허나 버전이 다를 수 있으며 다른 경우들이 발생한다면 

모노레포를 사용하는것이 옳은 선택이 될 수 도 있다.