모노레포 개념 , 얕고 넓게 알아보기

 

모노레포..?

 

🙂모노레포

yarn berry를 사용해보려고 많이 노력을 쏟았는데 막상 yarn berry를 도입하는 분들의 포스팅을 보면

모노레포를 구성하기 위해서라는 근거가 같이 따라오는 경우가 많았습니다.

yarn berry를 이용하면 모노레포라는 것을 구성하기 쉽구나.. 정도로 이해하고 넘어갔는데

모노레포라는 개념이 어떤 점이 좋아서 다들 열심히 도입해보는지 궁금해졌습니다.

git과 같은 형상관리툴에 친하지 않은 탓에 이게 뭐가 좋은지 잘... 안 와닿더라구요

 

https://en.wikipedia.org/wiki/Monorepo

Monorepo - Wikipedia

 

뭔지 모를땐 일단 Wikipedia를 켜 보곤 합니다.

Wikipedia에서는 모노레포를 version-control system에서 여러 프로젝트의 코드를 동일한 저장소에 저장하는 소프트웨어 개발 전략이라고 소개합니다. 여러 프로젝트의 코드를 동일한 저장소에 저장하는 구조..

그림으로 표현해보면 이런 느낌으로 볼 수 있을 것 같아요

하나의 레포지토리에 여러가지의 프로젝트를 담아두고 관리하는거죠!

이러한 모노레포 전략은 Google, Meta, Microsoft, Uber, AirBnB, Twitter 등 여러가지 대기업에서도 다양한 전략을 가지고 매우 커다란 mono repo를 운용하고 있다고 합니다.

 

근데 이렇게 프로젝트를 관리하면 뭐가 좋은걸까요?

 

역시 이런 개념은 기존 방식의 비효율성을 해결하고자하는 움직임에서 파생되었습니다. 기존에 일반적으로 사용되던 개발 방식 중 하나인 모놀리식 애플리케이션은 모듈화 없이 설계된 소프트웨어 애플리케이션을 말한다고 합니다. 이러한 모놀리 애플리케이션 전략은 모든 코드가 단일 버전으로 서로 직접 의존하기 때문에 코드를 재사용하기도 편하고 빌드, 배포하는 것도 단순하다는 장점이 있지만...

 

서비스가 커지게되면 자연스레 관심사 분리를 하지 않으면 문제가 발생하기 쉬운 구조가 됩니다. 서로의 의존성이 깊은 상태에서는 문제가 발생해도 어디에서 문제가 발생하는지 알아내기가 어려울테니까요

 

따라서 이런 비효율적인 문제점은 당연하게도 모듈화를 도입하는 것을 통해 해결할 수 있습니다. 이것을 Modular Programming 이라고 부릅니다. 모듈 프로그래밍은 애플리케이션 로직의 일부를 재사용할 수 있도록 지원해줄 수 있고 애플리케이션의 일부만 수정하거나 교체할 수 있게 만들어줍니다.

 

서로에게 직접적으로 의존하지않고 독립적으로 존재하는 모듈은 기능을 추가하거나 수정하는 등의 행동에서 큰 편의성을 얻을 수 있을 것입니다.

그런데 생각해보면 이렇게 모듈로 나눠놓는다고 쳤을때... 나눠 놓은걸 어떻게 저장하지..? 라는 의문이 들 수 있습니다.

모듈화는 했는데 이거.. 어디다가 저장해둬야 편할까?

 

 

출처 : 라인 기술블로그

https://engineering.linecorp.com/ko/blog/monorepo-with-turborepo

Turborepo로 모노레포 개발 경험 향상하기

라인 기술 블로그에 너무 잘 표현된 그림이 있어서 위 그림으로 대체할 수 있을 것 같습니다.

열심히 만들어둔 모듈이 다른 애플리케이션에서도 재사용될 수 있도록 하려면 각각의 모듈들을 하나의 저장소에 저장시켜두고 그 모듈이 필요할 때 그 모듈이 저장되어 있는 저장소를 통해 그 모듈에 접근하는 것이 효율적이어보입니다.

바로 그러한 개념에서 각각의 모듈들에 개별적으로 레포지토리를 할당해주는 것을 멀티레포(multirepo) 라고 부릅니다.

희망적으로 출발한 멀티레포라는 개념은 분명한 장점이 존재했지만 이 역시도 은탄환은 아니었습니다. 

 

소스코드를 모듈화하고 개별적인 레포지토리를 부여해준 뒤 독립적으로 동작하게 만드는 멀티레포 방식은 한 모듈의 기능 변경, 수정이 다른 레포지토리에 있는 모듈들에 직접적인 영향을 미치지 않기에 유지보수가 용이해졌다는 장점이 있었지만 독립적으로 존재한다는 장점은 곧 단점이 되기도 했습니다.

 

바로 모놀리식 애플리케이션의 장점이던 코드 레벨에서의 재사용이 멀티레포에서는 각 모듈이 서로 독립적으로 존재하기에 어려워졌다는 것이고 또 추가적으로 실제 서비스는 각각의 모듈이 모듈만으로 동작하는 것이 아니라 모두 합쳐진 형태로 서비스가 되어야하다보니 빌드, 배포 과정의 복잡도가 올라갔습니다.

 

바로 이런 상황에서 모노레포는 모놀리와 멀티레포의 장점을 모두 가져가고자하는 움직임으로 만들어졌습니다. 

지금까지 정리한 두 방식의 큰 차이를 표로 정리하면 다음과 같을 것 같네요

모놀리식	멀티레포
코드레벨 재사용 용이	코드레벨 재사용 힘들어잉
빌드, 배포 편함	빌드 배포 너무 어려워잉
모듈화 안됨	모듈화 가능

모놀리와 멀티레포 둘 다 완벽하지는 않지만 확실히 장점이 있는 방식인 것 같습니다.

그럼 둘 다 취하면서 어떻게 어떻게 장점만 챙겨가는 방법이 없을까..? 고민하다가 나오는게 모노레포라는거겠네요!

 

또한 앞서 서술하지는 않았지만 멀티레포에도 다양한 문제점이 존재합니다. 간략하게 정리를 해보면 다음과 같은 문제점들을 생각해볼 수 있습니다.

1. 패키지 종속성 관리에 대한 부담

2. 늘어나는 레포지토리만큼 관리해야할 레포지토리도 늘어남

 

만약 공통적으로 사용하는 패키지가 있다면 멀티레포 방식에서는 공통적으로 사용하는 라이브러리임에도 불구하고 여러번 install을 하게 됩니다. 또한 그 과정에서 다른 레포지토리와 버전이 달라지는 등의 문제가 발생할 수 있으니 개발 환경을 어느정도 맞춰주어야 나중에 빌드, 배포할 때 문제가 덜 발생하게 될 것입니다. 그런데.. 이거 프로젝트가 커지면 커질수록 힘들어지지 않을까요?

 

🥰모노레포를 사용하면..

 

모노레포를 사용하게되면 위 멀티레포의 문제점들이 깔끔하게 해결됩니다. 하나의 레포지토리에서 종속성을 관리하기에 하나의 레포지토리만 개발환경을 관리하면 되고 의존성 관리 역시 모든 모듈들이 하나의 환경에 존재하므로 하나의 레포지토리에서만 의존성을 관리해주면 됩니다. 개발환경을 구축하는 것 또한 쉬워집니다. 저장소를 생성하고 커미터를 추가하는 등의 일련의 개발환경 구성을 하는 과정이 필요없어지기 때문입니다.

 

물론 장점만 있는 것은 아니라 하나의 레포지토리에 모든걸 때려박는 기법은 자연스레 레포지토리가 굉장히 거대해질 거라는 것을 의미하고 그에 따라서 여러가지 문제가 발생할 수 있습니다.

 

 

😥레퍼런스

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