🤓 시작하며
모든 B2B 회사가 다 그런지는 모르겠지만, 우리 회사는 특히 고객사의 피드백에 관대한 편이다. 그렇게 그들의 요구에 맞춰서 커스텀을 진행한지 어언 1년.. 고객사가 늘어난다는 것은 기쁜 일이지만 그에 비례해서 늘어나는 레포지토리, 잔뜩 쌓인 코드들 .. 이제는 정작 코드를 수정하는 시간보다 copy&paste 에 들이는 시간이 더 커지는 지경이다. 좋은 방법이 없을까 서치하던 와중에 눈에 들어온 모노레포. 현재 우리가 쓰고 있는 멀티레포와 비교해서 장단점을 분석해보기로 했다.
멀티레포 (multi-repo) vs 모노레포 (mono-repo)
멀티레포(폴리레포)
멀티레포란 말 그대로 Repository를 각 도메인 및 기능 시스템 단위로 생성하여 운영하는 것을 말한다. 즉, 프로젝트 별로 레포지터리를 생성하여 만든것으로, 현재 우리가 쓰고있는 방식이다.
👉 장점
1. 모듈화
- 각 저장소가 독립적으로 관리되기 때문에 개발자는 필요한 모듈만 가져와서 작업할 수 있다.
2. 배포
- 전체 프로젝트를 빌드할 필요 없이 일부분만 변경하거나 배포할 수 있다.
- 대규모 프로젝트에서 프로덕션 배포의 속도를 높이는데 도움이 된다.
3. 의존성 관리
- 각 저장소는 개별적으로 관리되기 때문에, 프로젝트의 의존성 관리가 더욱 쉬워진다.
👉 단점
1. 저장소가 많아질 수록 관리 부담 증가
- 저장소의 수가 많아질수록 관리가 복잡해진다.
- 각 저장소에 대한 버전 및 의존성 관리가 필요하여, 이는 추가적인 노력과 시간이 필요하다.
2. 중복 코드 발생
- 각각의 저장소에서 동일한 코드가 중복될 수 있다.
- 이는 코드의 수정이 필요할 때 수정해야 하는 저장소가 다수일수 있으므로 유지보수성이 낮아질 수 있다.
3. 각 프로젝트의 코드 컨벤션의 통일이 어려울 수 있다.
4. 프로젝트 별로 사용하는 모듈 및 버전 스택이 달라질 수 있다.
5. 오랫동안 건드리지 않은 프로젝트의 관리가 힘들어지며, 해당 프로젝트의 legacy 파악이 어려워질 수 있다.
6. 팀원별 컨텍스트 공유가 서로 원할하지 않은 경우 협업에 지장이 생긴다.
모노레포
프로젝트별로 레포지토리를 생성하여 만드는 멀티레포와는 반대되는 방식으로, 버전 관리 시스템에서 두개 이상의 프로젝트가 동일한 저장소에 저장되는 소프트웨어 개발 전략이다. 모노레포의 대표적인 예시로는 구글, 페이스북 등의 대규모 기업들이 있다. 한국에서는 토스가 대표적이다. 이들 기업은 대규모 프로젝트를 다루기 위해 코드를 단일 저장소에서 관리하고 있다.
👉 장점
1. 코드 리뷰 향상
- 각 프로젝트의 작업 사항을 하나의 repository에서 한눈에 확인할 수 있다.
- 자연스럽게 다른 프로젝트의 코드를 들여다보며 코드리뷰에 적극 참여할 수 있는 계기가 만들어진다.
2. 최신화 상태 유지
- 오랫동안 건드리지 않은 프로젝트도 신경 쓸수 있는 환경으로 개선시킬 수 있다.
3. 전체 코드의 일관성
- 하나의 저장소에서 모든 코드를 관리하기 때문에, 코드의 일관성을 유지하기 더욱 쉬워진다.
- 특히 모든 프로젝트에서 eslint와 prettier 등의 환경으로 모든 팀원이 동일한 코드 컨벤션을 가져갈 수 있게 된다.
4. 공유 라이브러리
- 여러 프로젝트에서 공유되는 라이브러리를 관리하는데 적합하다.
5. 단일 버전 관리
- 모든 코드가 하나의 버전 관리 체계에서 관리되기 때문에, 버전 충돌 문제를 최소화 시킬수 있다.
👉 단점
1. 개발환경 구성의 어려움
- 여러 프로젝트와 의존성을 모두 관리하는 것은 복잡성이 높기 때문에 처음 모노레포 구조를 만듦에 있어서 신중함이 필요하다.
2. 충돌 코드 위험
- 개발자가 동일한 코드를 변경하면 충돌이 발생할 수 있다.
- 따라서 적절한 의사소통과 조정이 없으면 개발 프로세스가 크게 지연될 수 있다.
3. 코드 관리 복잡성
- 모든 코드가 하나의 저장소에서 관리되기 때문에, 저장소의 크기가 커질수록 코드 관리 복잡성이 증가한다.
4. 배포 복잡성
- 배포 프로세스가 복잡해질 수 있다.
✏️ 마치며
개인적으로 뷰와 기능이 크게 다르지 않으면서 레포가 3개 이상일때 모노레포를 쓴다면 유지보수 관점에서 모노레포의 장점이 큰 매력으로 다가올 것 같다. 하지만 프로그램을 실 납품하는 입장에서 모노레포로 만든 프로젝트를 개별적으로 배포할수 있는지가 가장 중요한데, 이부분에 대해서는 문서도 부족할 뿐 더러 실제로 수행해보지 않았기 때문에 조금 두려움이 있는 상태다. 이 부분에 대해서는 팀원들과도 함께 얘기해보고 결정하는걸로 해보겠다.
참조 페이지
팀워크 향상을 위한 모노레포(Monorepo) 시스템 구축
콴다 프론트엔드 팀이 모노레포를 선택한 이유
blog.mathpresso.com
모노레포 vs 멀티레포
원티드 5월 프론트엔드 챌린지를 하면서 모노레포에 대해 알게 되었다. 모노레포란 무엇인지, 이와 반대되는 멀티레포는 무엇인지 알아보자.
velog.io
'개발 지식' 카테고리의 다른 글
| AWS amplify 배포해보기 (0) | 2024.07.04 |
|---|---|
| [FE] 웹뷰(WebView) 란? (1) | 2024.06.17 |
| [FE] 쿠키, 세션, 로컬 스토리지와 세션 스토리지 (0) | 2024.02.07 |
| [React] useEffect vs useMemo vs useCallback (0) | 2024.02.02 |
| [Vite] Vite 란? (0) | 2024.01.22 |
