원티드 프론트엔드 챌린지로 이번엔 React 프로젝트 설계를 Monorepo 시스템을 사용하여 해보는 시간을 가지게 되었다. 배우는 시간에 앞서 Monorepo란 무엇이고, 왜 사용하며, 장단점은 무엇이 있는지 알아보자.
✅ 여러개의 개발 프로젝트를, 잘 정의된 관계를 통해서 하나의 Repo에 담은것
Monolithic
은 project 끼리 분리가 안되있고 거대하지만 Monorepo
는 repo만 하나 일 뿐 project끼린 분리가 잘 되어 있다.
페이지를 구분 없이 섞어서 구성하고 마구잡이로 참조해 독립이라는 느낌이 안드는 모듈화 없는방식이 Monolitic Repository
라고 한다면, Monorepo
는 페이지가 같은 리포지토리에 있지만 확실히 구분을 짓는다. 서로 패키지처럼 참조하도록하고 코드 내부에는 참견하지 않도록 구성한다.
✅ 이렇듯 Monoropo의 핵심은 모듈화이다.
모듈화 자체는 PolyRepo로도 잘 구축할 수 있지만, MonoRepo의 각 패키지를 넘나드는 작업이나 서로 참조하기가 쉽다는 특징과 모듈화가 잘 합쳐지면 그 시너지가 크다.
💡 Polyrepo
✅ Polyrepo는 애플리케이션을 개발하는 현재 표준 방식이다.
Monorepo와 달리 일반적으로는 하나의 리포지토리에 하나의 프로젝트가 들어가게 된다. 각 프로젝트는 자율성이 높으며 독립적인 개발, 린트, 테스트, 빌드, 게시, 배포 파이프라인이 존재한다.
팀의 자율성이라는 큰 이유로 이 방식을 선호하지만 단점 또한 존재한다.
- 번거로운 프로젝트 생성
- 새로운 공유 패키지를 생성할 때마다 다음과 같이 번거로운 과정을 거친다.
- 저장소 생성 > 커미터 추가 > 개발 환경 구축 > CI/CD 구축 > 빌드 > 패키지 저장소에 publish
- 패키지의 중복 코드 가능성
- 위의 번거로움을 피하기 위해 각 프로젝트에서 공통 구성 요소를 자체적으로 작성한다면, 초기 시간을 아낄 수 있지만 시간이 지날수록 보안 및 품질 관리 부담을 증가시킨다.
- 관리 포인트 증가
- 늘어난 프로젝트 저장소의 수만큼 관리 포인트가 늘어난다. 린트, 테스트, 개발 모드 실행, 빌드, 게시, 배포 등의 과정을 저장소의 수만큼 반복해야 한다.
- 일관성 없는 개발자 경험(DX)
- 각 프로젝트는 테스트 실행, 빌드, 테스트, 린트, 배포 등을 위해 고유한 명령 집합을 사용한다. 이러한 불일치는 여러 프로젝트에서 사용할 명령을 기억해야 하는 정신적 오버헤드를 만든다.
- 다른 패키지의 변경 사항 파악
- 관련 패키지의 변화를 지켜보거나 통지받지 않으면 문제가 발생할 수 있다.
- 교차 저장소의 리팩터링 비용
- 관련 패키지의 변화가 있을 때 여러 저장소에 걸쳐 변화를 반영하는 것은 쉬운 일이 아닐 것이다.
참고하자! 👉 멀티리포 vs 모노리포
✅ Unified Versioning
✅ Extensive Code Sharing & Reuse
✅ Simplified Dependency Management
✅ Atomic Changes
변경 사항을 보다 Atomic하게 관리할 수 있다.
(원자적이라는 말은 더 쪼개지지 않는, 그 중간 과정을 확인할 수 없다는 의미로 받아들이면 된다.)
만약 어떤 라이브러리 코드를 바꿔서, 이를 이용하고 있는 다른 PolyRepo 레포지토리들을 돌아다니면서 하나 바꾸고 커밋 찍고, 또 하나 바꾸고 커밋 찍고… 이런 과정이 연속적으로 이뤄지게 된다. 이런게 변화하는 중간 과정이 보인다고 생각할 수 있다. 만약 각 커밋마다 테스트가 돌아간다면 각 레포에서 커밋을 찍을 때마다 테스트가 터져서 마음이 아프기도 할 것이다.
하지만 MonoRepo로 하면 어떤 변경 사항을 여러 독립된 프로젝트에서 적용해야 하면 한번에 고쳐서 하나의 커밋으로 관리할 수 있다. 이걸 변화 과정이 원자적이라고 말할 수 있을 것이다.
✅ Large Scale Refactoring
✅ Flexible Team Boundaries and Code Ownership
✅ Dependency 충돌 문제
✅ 단일 리포지토리 문제
✅ 긴 초기 프로젝트 설정시간
누군가에게는 장점, 누군가에게는 단점으로 작용할 수 있는 Monorepo는 팀규모, 프로덕트 규모에 따라서 정하는 것이 적절하다.
대규모 회사 또는 프로덕트를 가진 경우에는 어려 프로젝트를 한 개발팀이 담당할 경우가 많기 때문에 PolyRepo보다는 MonoRepo로 코드에 대한 유연성을 챙기는 것이 좋은 것 같다.
👉 PolyRepo를 사용하던 콴다팀의 MonoRepo 변경 일지
👉 모던 프론트엔드 프로젝트 구성 기법 - 모노레포 개념 편
출처 및 참고하기 좋은 사이트