모노레포 -Monorepo

모노레포 - Monorepo

일단 모노레포가 무엇인지 정의를 두자면 위키에선
** 모노레포란 버전 관리 시스템에서 두 개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략**
이라고 기재되어 있다

이전 개발 전략은 모놀리식 애플리케이션으로
모놀리식 애플리케이션은 모듈화 없이 설걔된 소프트웨어 애플리케이션 이라 되어있다

즉, 어떤 하나의 서비스를 개발할 때 모듈화 없이 개발된다면 코드가 서로 직접적으로 의존되며 하나의 버전으로 관리되면서 분리가 어려워지고 새로운 설계 리팩터링 등의 작업들을 진행할 때마다 작업 단위가 거대해진다.

리액트를 배우고 프로그래밍을 배울 수록 딱 봐도 비효율적인 부분을 찾아볼 수 있는데 그렇기에 우리는 모듈화와 재사용성을 신경쓴다

모듈과 재사용성

모듈(module)이란 다른 프로그램에 링크되어 특정한 기능을 수행할 수 있도록 작성된 독립적인 프로그램의 단위로 우리가 프로젝트를 진행하며 모듈식 프로그래밍을 할 경우 반복되는 로직을 모듈화하여 재사용할 수 있고 애플리케이션의 일부를 교체해야 할 때도 해당 모듈인 일부만 수정하거나 교체하면 되니 유지 관리가 용이해진다

그럼 이런 모듈들을 다른 애플리케이션에 사용되게 하고 싶다면 소스를 어디에 위치 시킬까?
해당 모듈을 독자적인 저장소에 관리하고 싶다면 해당 구조가 멀티레포가 된다

멀티레포

폴리레포 구조라고도 불리며 앞서 분리된 각 모듈을 먼티레포 구조에서 고유한 저장소가 있는 독자적인 프로젝트가 되는 것이다.
이러면 각 프로젝트는 자율성이 높으며 독립적인 개발이 가능하게 된다
마치 todoApp 하나 calendarapp하나 todoApi 하나 등 여러 저장소를 가지고 되게 각자 팀의 자율성으로 개발이 가능해진다.

그런데 왜 모노레포란게 생겼을까?

멀티레포의 문제

• 계속되는 프로젝트 생성
  새로운 공유 패키지를 생성할 때마다 npm에 들어간 패키지를 각각 다시 다운받고 환경 구축하고 CI/CD구축하는 등 번거로운 작업이 반복된다
• 패키지의 중복 코드 가능성
  프로젝트에서 공통 구성요소를 자체적으로 작성한다면 초기에 시간을 아낄 수 잇겠지만 시간이 지날수록 보안 및 품질 관리 부담이 증가된다
• 관리 포인트 증가
  프로젝트가 늘어나면서 당연시 관리해야할 포인트도 늘어난다.
• 일관성이 사라지는 개발자 경험
  각 프로젝트는 고유한 명령 집합을 사용할 수 있고 이런 불일치는 프로젝트가 늘어날수록 명령어를 기억해야하는 불편함이 생긴다
• 다른 패키지의 변경사항 파악
  사용되는 관련 패키지의 변화를 지켜보거나 통지받지 못하면 예상치 못한 문제가 발생할 수 있다
• 교차 저장소의 리팩터링 비용
  관련 패키지 변화가 있을 때 여러 저장소에 걸쳐 변화를 반영해야 하는 게 쉬운 것이 아님!

그럼 모듈도 적절히 분리하고 동시에 분리된 모듈을 쉽게 참조하고 테스트 빌드 배포 등도 한번에 되는 게 없을까? 했을 때 등장된게 모노레포이다

모노레포의 특징

모노레포 구조는 2개 이상의 프로젝트가 동일한 저장소에 저장되는 소프트웨어 개발 전략으로 앞에서 말한 TODOAPP이나 CALENDER등이 독자 프로젝트로 존재하지만 저장소는 같은 그런 개념이다

중요한 특징 중 하나는 프로젝트 간의 관계로 단순히 여러 프로젝트가 하나의 저장소를 사용한다 해서 모노레포 구조가 아니라 프로젝트 사이에 의존성이 존재하거나 같은 제품군이거나 하는 정의된 관계가 존재한다.
그런 관계를 효율적으로 관리해주는 도구들이 있다

오해

• 다른 팀이 내가 모르는 사이에 내 코드를 변경할 수 있지 않나?
  GitHub에는 CODEOWNERS와 같은 기능을 사용해서 폴더 기반으로 소유권을 구성할 수 있다
  따라서 해당 저장소에 대한 모든 PR을 소유자에게 리뷰 받아야 머지할 수 있는 것이다
• 모노레포가 멀티레포보다 항상 나은 방법인가?
  멀티레포의 단점이 모노레포의 장점이고 장단점이 각각 교차하기 때문에 적절한 상황에서 사용해야 한다
  모노레포의 핵심은 프로젝트 사이의 관계로
  • 유사한 제품의 집합
  • 여러 프로젝트의 변화를 한 눈에 파악해야 할 때
  • 호스트 애플리케이션을 플러그인 등으로 확장할 때
  • 공통 기능을 재사용하는 관련된 프로젝트의 집합
  • 유사한 DevOps로 구성된 프로젝트의 집합

모노레포 구축할 때 고려할 것

관리

• 코드 공유
  서로 다른 프로젝트 간에 쉽게 소스코드 공유
• 일관성 있는 도구
  서로 다른 프로젝트들 (다른 프레임워크를 사용하더라도)에서 일관된 개발 경험 제공
• 스케폴딩
  새로운 프로젝트를 생성할 때 초기 코드를 쉽게 생성
• 프로젝트 제약 및 가시성
  저장소 내에서 의존 관계를 제한하는 규칙 정의 지원속도
• 로컬 캐싱
  같은 머신에서 같은것을 두 번 빌드,테스트 하지 않음
• 분산 캐싱
  다양한 환경에서 캐시 아티팩트 공유. 즉, 조직단위로 여러 CI환경에 걸쳐 같은 것을 두 번 빌드,테스트하지 않음
• 로컬 작업 오케스트레이션
  빌드 및 테스트 등의 작업을 순서에 맞게 병렬로 실행
• 분산 작업 실행
  단일 시스템에서 실행되어 여러 시스템에 명령을 전달
• 변화에 영향을 받는 프로젝트 감지
  변경 영향을 받을 수 있는 항목을 결정해서 영향을 받는 프로젝트만 빌드/테스트구조파악
• 워크 스페이스 분석
  추가 구성 없이 주어진 워크 스페이스의 의존성 관계를 분석
• 의존성 그래프 시각화
  프로젝트 및 작업 간의 종속 관계를 시각화

---

글 참조 : https://d2.naver.com/helloworld/0923884