[FE] 모노레포(Monorepo) 전략에 대해 알아보자

지난 포스팅.. 패키지 매니저에 대해 공부하면서 많이 보이던 단어 "모노레포"..

많은 기업에서 yarn berry를 도입한 이유의 큰 이유 중에 하나가 모노레포를 구축하면서 선택했던 도구였다고 합니다.

 

그렇다면 과연 모노레포는 무엇이며, 어떤 특징이 있는지 알아봅시다!

 

1. 모노레포의 등장 배경

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

 

초창기 서비스의 시작, 모놀리식 구조

모노레포는 고전적 소프트웨어 개발 방식인 모놀리식 애플리케이션(monolithic application)의 한계에 대해 비판해서 출판합니다.

여기서 모놀리식 애플리케이션이란 모듈화 없이 설계된 소프트웨어 애플리케이션을 말합니다.

 

대부분의 초창기 프로젝트들은 모놀리식 시스템으로 서비스를 구현하게 됩니다.

프로젝트의 크기가 크지 않고, 개발자의 수도 적기 때문에 모든 것을 한 곳에서 처리하는 것이 효율적이기 때문이죠!

이 경우 시스템 자체가 쪼개어지지 않고 하나이기 때문에 레포지토리 역시 하나로 관리하게 됩니다.

 

프로젝트 거대화에 따른 마이크로 서비스 구성

프로젝트가 커짐에 따라 모듈화를 시키지 않은 소스 코드로 구성된 하나의 프로젝트는 엄청난 문제점들을 야기시킵니다.

코드가 서로 직접적으로 의존하며 단 하나의 버전으로 관리되면서 설계, 리팩토링, 배포 등의 작업을 매번 거대한 단위로 처리해야 하므로 개발상 많은 제약과 비효율이 이따릅니다.

 

이를 해결하기 위해 개발 조직은 시스템의 각 부분을 도메인 별로 분리해서 마이크로 서비스로 구성하기 시작합니다.

이때, 개발 조직은 쪼개진 각 서비스를 하나의 레파지토리에서 관리할지, 각자 다른 레파지토리에서 관리할지 고민하게 됩니다.

 

멀티레포 vs 모노레포

각각의 개념은 간단하다.

시스템의 각 모듈을 나눠서 관리하면 멀티레포, 하나로 관리하면 모노레포라 정의합니다.

 

멀티레포는 분리된 모듈을 고유한 저장소가 있는 독자적인 프로젝트로 관리합니다.

그렇기 때문에, 각 프로젝트는 자율성이 높으며 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인이 존재합니다.

멀티레포 방식에서는 소스코드를 모듈화한 뒤 각 모듈에 독자적인 영역을 부여하고, 버전 관리를 통해 관심을 분리해서 기능 변경이 다른 레포지토리에 직접 영향을 미치지 않도록 개선했습니다.

하지만 각 모듈이 서로 독립된 영역에 존재하기 때문에 코드 단계에서의 재사용이 어려워졌고, 빌드와 배포 과정이 복잡해졌습니다.

또한, 프로젝트를 매번 생성하는 것이므로 패키지의 중복 코드가 증가하며, 자연스럽게 관리 포인트가 늘어납니다.

 

모노레포는 이와 같은 모놀리식 레포지토리와 멀티레포의 장점을 모두 취하고자 등장했습니다.

모노레포는 두 개 이상의 프로젝트를 동일한 저장소에 저장합니다.

 

분리된 모듈들은 모노레포에서 여전히 독자적인 프로젝트로 존재하지만, 저장소는 같은 곳을 사용합니다.

 

2. 모노레포가 해결하는 문제

모노레포는 프로젝트 간의 관계를 효율적으로 관리해주는 도구라고 할 수 있습니다.

모노레포가 해결하는 멀티레포의 문제

1. 쉬운 프로젝트 생성

멀티레포에서 공유 패키지를 만들 때 다음과 같은 과정을 거칩니다.

 

저장소 생성 > 커미터 추가 > 개발환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 publish

 

하지만 모노레포에서는 저장소 생성 및 커미터 추가 과정이 필요 없습니다!

개발환경, CI/CD 구축, 빌드 게시 등의 과정은 기존 DevOps를 이용합니다!

따라서 새로운 프로젝트 생성에 대한 오버헤드가 없습니다.

 

2. 더 쉬운 의존성 관리

전체 서비스의 의존 관계를 한 레포지토리에서 확인 및 설정할 수 있기에 더욱 쉽게 의존성 관리를 할 수 있습니다.

 

3. 단일화된 관리 포인트

개발환경 및 DevOps에 대한 업데이트를 한 번에 반영할 수 있습니다.

 

4. 일관된 개발자 경험 제공

어플리케이션을 일관되게 구축하고 테스트할 수 있습니다.

개발자는 다른 팀의 어플리케이션에 자신 있게 기여하고, 변경 사항이 안전한지 확인할 수 있습니다.

 

5. 프로젝트들에 걸친 원자적 커밋

커밋할 때마다 모든 것이 함께 작동합니다.

따라서 변셩 사항의 영향을 받는 조직에서 쉽게 변화를 확인할 수 있습니다.

 

6. 서로 의존하는 저장소들의 리팩토링 비용 감소

모노레포는 대규모 변경을 훨씬 더 간단하게 만듭니다.

100개의 라이브러리로 만든 10개의 앱을 리팩토링하고 변경을 커밋하기 전에 모두 작동하는지 확인할 수 있습니다.

 

7. 테스트 및 빌드 범위 최소화

소스 변경 시 모든 프로젝트를 다시 빌드하거나 다시 테스트하지 않습니다.

대신 변경 사항의 영향을 받는 프로젝트만 다시 테스트 하고 빌드합니다.

 

다음과 같은 상황일 때 모노레포를 사용해보세요!

• 유사한 제품의 집합
• 여러 프로젝트의 변화를 한눈에 파악해야 할 때
• 호스트 애플리케이션을 플러그인 등으로 확장할 때
• 공통 기능을 재사용하는 관련된 프로젝트의 집합
• 유사한 DevOps로 구성된 프로젝트의 집합
•  

 

3. 모노레포는 어떻게 사용되고 있는가?

현재 다양한 기업에서 모노레포 전략을 사용하여 프로젝트를 운영하고 있습니다.

Google, Facebook, Microsoft, Uber, Airbnb, Twitter와 같은 글로벌 기업부터

라인, 배달의민족, 토스, 콴다, 화해, 마이리얼트립 등 국내 다양한 기업에서도 모노레포를 도입 및 변경을 시도하고 있습니다.

 

대체적인 후기들을 종합해보자면 다음과 같은 장점들을 꼽을 수 있었습니다.

• 코드의 일관성 (eslint, prettier, typescript 환경 통일로 모든 팀에서 일관되게 사용 가능)
• 코드 리뷰 향상 (각 프로젝트의 작업 사항을 하나의 레포에서 관리하므로 적극적으로 코드 리뷰에 임함)
• 모든 웹 프로젝트의 최신화 상태 유지 (오래 건드리지 않았던 프로젝트들도 함께 관리할 수 있는 환경 구성)
• 지속적인 소스의 무결성 보장 (레포지토리는 항상 모든 서비스가 연동된 올바른 상태를 유지)
• 의존성 그래프 시각화 (전체 코드가 트리 구조로 명확히 보임)
• 여러 프로젝트 팀 간의 쉬운 협업 (하나의 레포지토리에서 함께 작업하며, 여러 서비스에 손쉽게 접근 가능)

이 이외에도 모노레포의 다양한 장점들이 존재합니다.

 

4. yarn berry와 모노레포의 상관관계?

결론부터 말하자면, yarn berry는 모노레포를 구축하기 위한 "도구"입니다.

 

다양한 툴을 이용해서 모노레포를 많이 구축합니다.

대표적으로는 Lerna, Yarn, npm, pnpm, Nx, Turborepo 등을 많이 사용합니다.

 

다양한 상황에 따라 맞는 도구를 사용하시면 됩니다.

 

5. 마무리

지금까지는 모노리식 어플리케이션으로 개발을 해왔던터라.. (당연함 소규모임)

멀티레포도 경험해보지 못하였지만, 이러한 차이점을 알았기에 추후 실제 개발환경에 뛰어 들어 잘 적응하고 싶은 마음이(?) 있습니다.

 

하지만 eslint-config, tsconfig 등 새로운 프로젝트에 들어갈 때마다 환경설정하는 것이 매번 번거로웠는데,

모노레포와 같이 개발 환경을 잘 구축해두면 효율적으로 개발에 임할 수 있을 것만 같습니다.

 

대규모 프로젝트로 갈수록 모노레포의 장점이 뚜렷해진다는데, 언젠가 한 번 경험해보고 싶네요!