멀티레포? 모노레포!

안녕하세요, Just do IT블로그에 새로 합류하게 된 여립입니다.

 

신입 개발자로써 요즘 디자인 패턴과 아키텍쳐를 공부하면서, 멀티레포와 모노레포에 대해 찾아보게 되었습니다. 이번 포스팅에서는 기본적인 레포지토리의 정의부터, 모노레포의 이론적인 내용들을 작성해 보려고 합니다.

 

레포지토리 (Repository) 란?

대부분의 개발 프로젝트에서 소스코드 관리를 위해 Git을 사용합니다. Git은 2005년에 개발된 분산 버전관리 시스템으로, 레포지토리(줄여서 레포)라는 저장소에 각 소스코드의 분기점 (branch)에 따라 버전을 저장하고 모든 히스토리 및 관련 수정사항을 추적할 수 있도록 합니다. Github는 Git의 웹서비스 형태로, 로컬이 아닌 온라인 상에서 원격 저장소를 사용해 코드관리가 가능하도록 합니다.

 

소프트웨어 아키텍쳐의 발전

프로젝트의 규모가 커지고 복잡해지면서, 프로젝트 형태에 대한 소프트웨어 아키텍쳐는 꾸준히 발전해왔습니다.

기본적으로는 한 레포지토리에 하나의 서비스 혹은 프로젝트를 담고 있습니다. 이 방식을 모노리스(Monolith) 아키텍쳐라고 합니다. 서비스의 규모가 점점 커지며, 관리 포인트를 줄이기 위해 하나의 앱을 점점 쪼개기 시작합니다.

 

단순한 하나의 앱에서 프론트엔드와 백엔드를 분리하고, 각 기능에 맞게 백엔드를 나누어 마이크로서비스 (microservices) 형태로 발전합니다. 각 기능에 프론트엔드를 구성하는 마이크로 프론트엔드와 각 기능별로 별도의 앱을 구성하는 end-to-end 형태까지, 소프트웨어의 구조는 다양하게 바뀌었습니다.

 

이러한 소프트웨어 형태가 발전해감에 따라, 기존의 한 프로젝트를 한 레포에 저장하는 방식과 어긋나는 점이 생기게 됩니다. 그래서 이 복잡한 형태의 구조를 레포에서 효율적으로 관리하고자 나온 방안이 모노레포(Mono-Repo)입니다.

 

멀티레포와 모노레포

멀티레포 (Multi-Repo 혹은 Poly-Repo)는 기존의 한 프로젝트를 하나의 레포에서 관리하던 방식으로 여러 개의 프로젝트를 각각의 레포에서 관리하게 됩니다.

모노레포는 여러 개의 프로젝트를 하나의 레포지토리에서 관리하는 방식으로 주로 각 기능별로 쪼개져있는 마이크로서비스 혹은 마이크로 프론트엔드 형태의 개발 구조 프로젝트에 도입되며, 나누어져 있는 서비스를 통합해 관리한다는 점에서 모노레포가 장점을 발휘하게 되었습니다.

 

멀티레포 vs. 모노레포, 어느 쪽이 맞나요?

각각의 방안에는 장단점이 있고, 사실 어느 한 쪽이 맞다는 정답은 없습니다.

 

기본적으로 레포지토리는 한 프로젝트를 담는다는 틀에 적합하기 되어있습니다. 그럼에도 불구하고, 구글부터 시작해 국내의 무신사 등의 여러 기업들이 모노레포를 도입했습니다. 과연 모노레포의 매력 포인트는 무엇일까요?

 

대표적인 모노레포의 장점으로는 공통항목을 단일화하고, 버전 및 패키지 관리를 손쉽게 할 수 있다는 점입니다.

단일 형태의 앱과 다르게, 마이크로서비스 형태부터는 한가지 기능 혹은 한 팀이 한개의 앱를 담당합니다. 그리고 규모가 커질수록, 기능이 많아질수록, 앱의 갯수가 증가합니다. 문제는 그 다음 발생합니다.

예를 들어, A 기능은 업데이트가 활발하고, B 기능은 사용자가 많지 않아 업데이트가 늦습니다. A기능은 기능 수정과 더불어 사용하는 기술의 버전도 업데이트했습니다. 그런데, A기능과 B기능을 통합시켜야 된다고 가정해봅시다. 버전과 구성방식이 완전히 다른 두가지 기능을 합치기는 쉽지 않습니다.

실제 서비스에서는 훨씬 더 복잡한 형태로 기능들이 동작하고 연결됩니다. 그렇기에 공통된 버전 유지와 사용된 패키지 (개발에 사용된 추가 기능들의 집합) 공유는 매력적인 포인트가 됩니다. 이외에도 공통된 설정과 의존성 관리는 새로운 기능을 개발할 때, 시간을 단축시킬 수 있다는 장점이 있습니다.

 

다른 장점으로는 다른 팀 혹은 서비스 간의 협업이 용이해집니다. 모든 프로젝트의 코드가 한 곳에 있기 때문에, 코드의 재사용성이 높아지고 관련된 모든 프로젝트를 찾아 수정할 수 있습니다. 해당 프로젝트 소속이 아니여도 다른 프로젝트 내에 연결되어 있는 기능과 코드 변경사항을 확인 가능해 개발할 때 빠른 적용이 가능합니다.

 

여러 장점을 가지고 있는 만큼 단점도 존재합니다.

 

레포가 커지며 분산되어 존재하던 CI/CD의 규모가 합쳐지며 파이프라인의 복잡성이 증가합니다.  

CI/CD는 레포에 저장된 코드를 자동적으로 빌드, 테스트, 업데이트 및 프로덕션까지 이어지게 하는 방법입니다. 각 레포에는 해당 서비스를 테스트 및 배포하기 위한 CI/CD가 존재하는데, 한 레포로 모든 기능이 합쳐지며, CI/CD 또한 통합시켜야 하는 어려움이 있습니다. 특히, 서로 다른 프로젝트에 대한 다양한 배포 요구 사항과 환경을 효과적으로 관리하는 것은 쉽지 않기 때문에 모노레포의 단점으로 꼽힙니다.

 

다른 단점으로는, 코드의 보안 레벨에 따른 권한 관리가 어렵습니다. 모노레포에서는 모든 개발자가 전체 코드에 접근할 수 있기 때문에, 민감한 코드나 데이터에 대한 접근 제어가 어렵습니다. 이는 특정 부분의 코드에 대한 접근을 제한하거나, 특정 팀 내에서만 공유되어야 하는 정보의 보안을 유지하기 어렵게 합니다.

 

이렇게 다양한 장단점들에도 불구하고 빅테크 기업들인 구글, 마이크로소프트, 메타 등은 모노레포를 도입해 사용하고 있다고 합니다.

 

과연 어떻게 모노레포를 도입해 사용하는지, 다음 포스팅에서는 국내 기업 적용 사례에 대해 알아보도록 하겠습니다.

 

좋은 하루 되세요!