Monorepo 정리

단순히 한 레포에 여러 프로젝트가 존재한다고 모노레포가 아니다.

독립된 여러 프로젝트를 하나의 저장소, 하나의 코드 베이스로 관리하는 것

이 정의이며, "독립된"이 중요하다. 각각의 프로젝트나 패키지의 참조가 난무한다면, 모놀리식과 다를 바 없다.

여러 패키지 사이의 참조 관계나 관리 용이성을 살리기 위해, 독립된 프로젝트이지만 하나의 레포지토리로 묶었다.

• 합치된 버전
  • 한 레포에서 전체 버저닝이 가능
• 광범위한 코드 공유와 재사용
  • 모듀로하된 패키지들을 공유하고 재사용 가능
• 원자단의 변경
  • 한 레포에 있다보니 한 커밋으로 변경 관리 가능
• 대규모 리팩토링에 용이
• 코드에대한 오너십과 협업 유연성

구글만 봤을 땐, 대규모 개발 집단에대한 특성이 대부분이다. 그래서 모듈러 개념에만 집중하여 프로젝트 생성 방식여부를 정하는게 좋을 것 같다.

현재 우리팀 인력에서 관리, 모듈화 두가지에 집중이 필요하다.

프론트 개발자가 적지도 않지만 프로젝트에 비해 많지도 않다. 공통 세팅이나 패키지의 경우 독립적으로 잘 가져다 사용할 수 있도록 구성한다. 그리고 작지만 앱은 앞으로 여러개가 될 수 있다. 최근 SRE팀에서 만든 내부 팀 작업용으로 만든 어드민 페이지 또한 앞으로 오픈소스를 종료했기 때문에 내부 organization에 들어올 수 있으며, 반복되는 개발 세팅 설정값들이나 DS를 사용한다. 이를 중점으로 독립적으로 사용될 수 있는 모듈화를 진행한다.

모노레포라서 패키지를 쪼갠다 (X) 팀 내부에서 독립적으로 사용될 고유한 패키지 또는 앱 (O) 개념적으로 확실히 분리가 필요한 패키지(O) -> e.g.) 디자이너와의 협업을 위해 Design System 개념이나 기반 데이터는 storybook 앱에서 분리한다.