모노레포에 관련하여

FE컨퍼런스, 기업 우대사항 등을 보면 모노 레포가 굉장히 핫하다는 걸 알 수 있다.

어떤 장점이 있고 어떻게 빌드해야하는지 알아봐야겠다.

 

모노 레포란?  monolithic + repository 단단히 하나로 되어있는 저장소이다.

서비스가 5개 이상, 프론트엔드가 10명 이상인 기업에서 사용하면 좋다.

 

멀티레포

- 각각의 프로젝트를 각 저장소 별로 따로따로 관리함

- 강한 오너쉽, 코드베이스 분리로 conflict 위험이 적음

- 레포지의 크기가 작아 동작하는 도구의 속도가 빠르다.

단점으로 코드의 재사용이 쉽지않아 중복코드가 많이 생길수밖에 없다.

하나의 개발에 여러 레포지에 pr을 보내야한다, 버전 연동이 어렵다

안정적이지만 이 때문에 업데이트 부분에서 힘든 부분이 있는거 같다.

 

모놀리식 애플리케이션

- 크고 거대한 하나의 대규모 구조

사소한 수정에 기나긴 빌드, 배포 시간

패키지 설치 시 다른 서비스에도 영향을 줌.

 

를 해결하기 위한 마이크로 서비스 아키텍처

- 공통으로 사용하는 최소한의 패키지를 두고 쪼개 자유롭게 의존성을 선택할 수 있게 함

- 빨리지는 배포 시간, 다른 서비스에 영향이 없음

- 서비스별 배포 가능

단점은 높은 자율성으로 인한 공통 코드 관리의 어려움

라이브러리의 파편화, 서비스 관리가 복잡해짐

 

을 해결하기 위한 모노 레포

- 하나의 git 레포지토리, 여러 패키지

- 하나의 의존성 패키지를 가지게 해서 프로젝트 간에 호환성호환성 걱정이 없다. (파편화 해결)

- 설정의 간편한 공유 (eslint, tsconfig 등)

- 코드가 트리 구조로 처음 보는 사람도 명확히 이해하기 쉽다

 

모노레포도 완벽한 아키텍처는 아니다.

- 무분별한 의존성 연결 가능

- 레포지의 크기가 커진다 (속도 저하)

 

때문에 서비스를 기준으로 모노레포와 멀티레포를 적절하게 선택하는것이 좋다.

개발에 정답은 없고 모노레포도 레포지토리를 어떻게 나눌것이냐에 대한 방법론중 하나이기 때문이다

 

 

 

 

 

 

참조

https://speakerdeck.com/raon0211/toseuyi-maikeuropeuronteuendeu-akitegceo-geurigo-jadonghwa?slide=29 

토스의 마이크로프론트엔드 아키텍처, 그리고 자동화

https://spookyjelly.tistory.com/80

[모던 프론트엔드 구성 ] 0. 모노레포의 개념과 구현 방법

https://tech.buzzvil.com/handbook/multirepo-vs-monorepo/

멀티리포 vs 모노리포