\(@^0^@)/
[12월] 멀티 레포(MultiRepo) 와 모노 레포(MonoRepo) 본문
먼저 모노 레포(MonoRepo)의 반대 개념인 멀티 레포(MultiRepo)의 장단점을 알아보고,
모노 레포(MonoRepo)가 멀티 레포(MultiRepo)보다 무엇이 더 나은지에 대해 알아보자!
멀티 레포(MultiRepo) 또는 폴리 레포(PolyRepo)
멀티 레포의 장점은 각 프로젝트가 고유의 저장소를 가지게 됨으로써,
다른 프로젝트와의 의존성을 가지고 있지 않아 독립적으로 빠르게 개발이 가능하며
비교적 크기가 가벼워 프로젝트 관리 면으로 수월합니다.
그러나 이러한 멀티 레포의 운영은 관리하는 프로젝트가 많아질수록 아래와 같은 문제점이 발생하게 됩니다.
- 각 프로젝트의 코드 컨벤션이 통일하기가 어려워질 수 있습니다.
- 각 프로젝트별로 사용하는 모듈 및 버전 스택이 달라질 수 있습니다.
- 오랫동안 건드리지 않은 프로젝트의 관리가 힘들어지며, 시간이 지날수록 해당 프로젝트의 Legacy 파악이 어려워질 수 있습니다.
- 팀원별 콘텍스트 공유가 서로 원활하지 않을 수 있습니다.
따라서, 멀티 레포 방식은 지금 당장은 편리하고 빠른 퍼포먼스를 선보일 수 있지만,
새로운 서비스 기능을 추가하기 위해 Repo를 생성할 때마다, 서비스의 환경과 린트(Lint) 환경을 반복적으로 세팅해야 한다.
장기적인 팀 차원에서 보았을 때는 프로젝트가 많아지고 팀원들이 늘어나면서 여러 문제점이 더욱 크게 도드라지게 되고, 언젠간 팀 전체적인 업무 퍼포먼스를 크게 악화시킬 것이라는 의견이 많았다.
[ 출처 : https://blog.mathpresso.com/%ED%8C%80%EC%9B%8C%ED%81%AC-%ED%96%A5%EC%83%81%EC%9D%84-%EC%9C%84%ED%95%9C-%EB%AA%A8%EB%85%B8%EB%A0%88%ED%8F%AC-monorepo-%EC%8B%9C%EC%8A%A4%ED%85%9C-%EA%B5%AC%EC%B6%95-3ae1b0112f1b ]
멀티 레포는 현재 대부분의 애플리케이션을 개발하는 표준적인 방법이다.
업계는 팀의 자율성이라는 큰 이유 때문에 이 방식을 선호한다.
팀은 애플리케이션 개발의 라이프사이클을 스스로 결정하기를 원한다.
좋은 일인데 무엇이 문제일까? 양날의 검처럼 이 자율성은 고립(isolation)에 의해 제공되고 고립은 협업을 방해한다
멀티 레포를 통해 모놀리식 구조의 문제를 해결했지만 다음과 같은 새로운 문제가 생긴다.
- 번거로운 프로젝트 생성 : 새로운 공유 패키지를 생성할 때마다 다음과 같이 번거로운 과정을 거쳐야 한다.
저장소 생성 > 커미터 추가 > 개발 환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 publish
- 패키지의 중복 코드 가능성 : 위의 번거로움을 피하기 위해 각 프로젝트에서 공통 구성 요소를 자체적으로 작성한다면, 초기 시간을 아낄 수 있지만 시간이 지날수록 보안 및 품질 관리 부담을 증가시킨다.
- 관리 포인트 증가 : 늘어난 프로젝트 저장소의 수만큼 관리 포인트가 늘어난다. 린트, 테스트, 개발 모드 실행, 빌드, 게시, 배포 등의 과정을 저장소의 수만큼 반복해야 한다.
- 일관성 없는 개발자 경험(DX) : 각 프로젝트는 테스트 실행, 빌드, 테스트, 린트, 배포 등을 위해 고유한 명령 집합을 사용한다. 이러한 불일치는 여러 프로젝트에서 사용할 명령을 기억해야 하는 정신적 오버헤드를 만든다.
- 다른 패키지의 변경 사항 파악 : 관련 패키지의 변화를 지켜보거나 통지받지 않으면 문제가 발생할 수 있다.
- 교차 저장소의 리팩터링 비용 : 관련 패키지의 변화가 있을 때 여러 저장소에 걸쳐 변화를 반영하는 것은 쉬운 일이 아닐 것이다.
[ 출처 : https://d2.naver.com/helloworld/0923884 ]
모노 레포(Mono Repo)의 특징
Google, Facebook, Microsoft, Uber, Airbnb, 그리고 Twitter 등 글로벌 테크 회사들은 이미 각자 자신들의 운영 전략 아래 대규모 모노 레포를 운영하고 있습니다.
모노 레포(monorepo) 구조는 두 개 이상의 프로젝트가 동일한 저장소에 저장되는 소프트웨어 개발 전략이다.
모노 레포의 또 다른 중요한 특징 중 하나는 프로젝트 간의 관계다.
단순히 여러 프로젝트가 하나의 저장소를 사용한다고 해서 모노 레포 구조라고 부르기에는 부족하다.
흔히 모노 레포에서는 프로젝트 사이에 의존성이 존재하거나 같은 제품군이거나 하는 정의된 관계가 존재한다.
아래에서 소개할 모노 레포 관리 도구는 모두 이러한 관계를 효율적으로 관리해 주는 도구라고 할 수 있다.
- 더 쉬운 프로젝트 생성 : 멀티 레포에서 공유 패키지를 만들 때 다음과 같은 과정을 거친다.
저장소 생성 > 커미터 추가 > 개발환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 publish
모노 레포에서는 저장소 생성 및 커미터 추가 과정이 필요 없고, 개발 환경, CI/CD, 빌드, 게시 등의 과정에 기존 DevOps를 이용하므로 새 프로젝트 생성에 대한 오버헤드가 없다.
- 더 쉬운 의존성 관리 : 의존성 패키지가 같은 저장소에 있으므로 버전이 지정된 패키지를 npm registry와 같은 곳에 publish 할 필요가 없다.
- 단일화된 관리 포인트 : 개발환경 및 DevOps에 대한 업데이트를 한 번에 반영할 수 있다.
- 일관된 개발자 경험 제공 : 애플리케이션을 일관되게 구축하고 테스트할 수 있다. 개발자는 다른 팀의 애플리케이션에 자신 있게 기여하고 변경 사항이 안전한지 확인할 수 있다.
- 프로젝트들에 걸친 원자적 커밋 : 커밋할 때마다 모든 것이 함께 작동한다. 변경 사항의 영향을 받는 조직에서 쉽게 변화를 확인할 수 있다.
- 서로 의존하는 저장소들의 리팩터링 비용 감소 : 모노 레포는 대규모 변경을 훨씬 더 간단하게 만든다. 100개의 라이브러리로 만든 10개의 앱을 리팩터링 하고 변경을 커밋하기 전에 모두 작동하는지 확인할 수 있다.
그 밖의 모노 레포의 특징
- 테스트 및 빌드 범위 최소화 : 소스 변경 시 모든 프로젝트를 다시 빌드하거나 다시 테스트하지 않는다. 대신 변경 사항의 영향을 받는 프로젝트만 다시 테스트하고 빌드한다.
모노 레포에 대한 오해
- 다른 팀이 내가 모르는 사이에 내 코드를 변경한다면?
- GitHub에는 CODEOWNERS와 같은 기능을 사용하여 폴더 기반으로 소유권을 구성할 수 있다.
- 모노 레포가 멀티 레포보다 항상 나은 방법인가?
- 그렇지 않다. 멀티 레포의 단점이 모노 레포의 장점이고 장단점이 교차하기 때문에 적절한 상황에서 사용해야 한다. 모노 레포의 핵심적 특징은 프로젝트 사이의 관계이고, 모노 레포가 적절한 상황은 다음과 같다.
- 유사한 제품의 집합
- 여러 프로젝트의 변화를 한눈에 파악해야 할 때
- 호스트 애플리케이션을 플러그인 등으로 확장할 때
- 공통 기능을 재사용하는 관련된 프로젝트의 집합
- 유사한 DevOps로 구성된 프로젝트의 집합
- 그렇지 않다. 멀티 레포의 단점이 모노 레포의 장점이고 장단점이 교차하기 때문에 적절한 상황에서 사용해야 한다. 모노 레포의 핵심적 특징은 프로젝트 사이의 관계이고, 모노 레포가 적절한 상황은 다음과 같다.
모노 레포를 구축할 때 고려할 측면
관리 측면
- 코드 공유: 서로 다른 프로젝트 간에 쉽게 소스 코드를 공유
- 일관성 있는 도구: 서로 다른 프로젝트들(심지어 서로 다른 프레임워크를 사용하더라도)에서 일관된 개발 경험을 제공
- 스케폴딩: 새로운 프로젝트를 생성할 때 초기 코드를 쉽게 생성
- 프로젝트 제약 및 가시성(visibility): 저장소 내에서 의존 관계를 제한하는 규칙 정의 지원. 예를 들어, 일부 프로젝트를 팀 전용으로 표시하거나 특정 프레임워크를 사용 중임을 기술.
속도 측면
- 로컬 캐싱: 같은 머신에서 같은 것을 두 번 빌드하거나 테스트하지 않음
- 분산 캐싱: 다양한 환경에서 캐시 아티팩트를 공유. 즉, 조직 단위로 여러 CI 환경에 걸쳐 같은 것을 두 번 빌드, 테스트하지 않음
- 로컬 작업 오케스트레이션: 빌드 및 테스트 등의 작업을 순서에 맞게 병렬로 실행
- 분산 작업 실행: 단일 시스템에서 실행되어 여러 시스템에 명령을 전달
- 변화에 영향을 받는 프로젝트 감지: 변경의 영향을 받을 수 있는 항목을 결정하여 영향을 받는 프로젝트만 빌드/테스트
구조 파악 측면
- 워크스페이스 분석: 추가 구성 없이 주어진 워크 스페이스의 의존성 관계를 분석
- 의존성 그래프 시각화: 프로젝트 및 작업 간의 종속 관계를 시각화
[ 모노 레포 개념 출처 : https://d2.naver.com/helloworld/0923884 ]
[ 모노 레포 분류 기준 참고 : https://monorepo.tools/#monorepo-features ]
모노 레포 구축을 도와주는 도구
Lerna, Yarn, npm, pnpm, Nx 등이 많이 사용되었다.
프리 온보딩 챌린지에서는 yarn Workspaces와 Turborepo에 관해 다룰 것 같다.
[ Monorepo tools 참조 : https://d2.naver.com/helloworld/7553804 ]
모노 레포에 대해 전혀 아는 것이 없어서 다른 분들의 글을 내가 알아보기 쉽도록 짜깁기를 하였다. (출처 참고)
이번 챌린지를 통해 모노 레포에 대해 알게 되어, 모노 레포와 멀티 레포의 장단점을 비교 분석할 수 있고,
나의 의견을 덧붙일 수 있도록 인사이트가 넓어졌으면 하는 바람이다.
'프로젝트&웨비나 회고 > 프리온보딩 FE challenge' 카테고리의 다른 글
| [12월] TBD(Trunk-Based Development) & Feature Flag (0) | 2022.12.14 |
|---|---|
| [12월] yarn berry를 이용하여 모노레포 구축해보기 (0) | 2022.12.07 |
