이번 과제를 통해 monorepo에 대해 공부하게 되었다.
이번 글에서는 학습 과정에서 이해하게 된 monorepo의 개념과,
멀티레포와의 비교를 통해 monorepo가 어떤 상황에서 적합한지 정리해보고자 한다.
monorepo란?
monorepo란 여러 개의 독립적인 프로젝트, 라이브러리, 디자인 시스템 등을
하나의 통합된 저장소(Repository)에서 관리하는 개발 방식이다.
왜 monorepo를 사용할까?
monorepo의 장단점을 이해하기 위해,
monorepo와 상반되는 구조인 멀티레포(Multi-Repository) 방식과 비교해보자.
모노레포와 멀티레포 비교
멀티레포란?
멀티레포란 Repository를 각 도메인 또는 기능 단위로 분리하여
각각 독립적으로 생성하고 운영하는 방식을 말한다.
모노레포(Monorepo)의 장단점
장점
- 공통 코드 재사용이 쉽다
- 공통 UI 컴포넌트, 유틸 함수 등을 하나의 패키지로 관리할 수 있다
- 여러 프로젝트를 동시에 수정하기 좋다
- 하나의 커밋 또는 PR로 여러 앱에 변경 사항을 반영할 수 있다
- 팀 협업에 유리하다
- 코드 공유와 개발 규칙을 통일하기 쉽다
단점
- 초기 설정이 복잡하다
- 레포지토리가 커질수록 관리가 어려워질 수 있다
- 프로젝트별 권한 분리가 어렵다
- 설정에 따라 빌드 및 테스트 시간이 길어질 수 있다
멀티레포(Multi-Repo)의 장단점
장점
- 구조가 단순하고 이해하기 쉽다
- 레포 간 영향이 적어 안정적이다
- 프로젝트별 권한 관리가 쉽다
- CI/CD 설정이 비교적 단순하다
단점
- 공통 코드 관리가 어렵다
- 의존성 버전 불일치 문제가 발생할 수 있다
- 여러 레포를 동시에 수정해야 하는 작업이 번거롭다
- 전체 서비스 구조를 한눈에 파악하기 어렵다
모노레포가 적합한 상황
- 여러 프로젝트에서 공통 코드 사용 비중이 높은 경우
- 공통 UI 컴포넌트나 유틸 함수를 하나의 패키지로 관리해야 할 때
- 여러 프로젝트를 동시에 수정해야 하는 작업이 잦은 경우
- 하나의 커밋 또는 PR로 여러 앱에 변경 사항을 반영하고 싶은 경우
Hello, GSM에서 왜 사용했을까?
우선 Hello, GSM은 admin 과 client 가 각각 작동한다.
하지만 Hello, GSM 이라는 하나의 서비스이기 때문에 공통 UI등 공유하는 코드가 많다. 따라서 코드를 효율적으로 사용하고 관리하기 위하여 모노레포를 사용했다고 생각한다.
Hello, GSM 구조분석
Hello, GSM 프로젝트는 루트에 apps와 packages로 구성되어있습니다.
apps 폴더에는 client 와 admin 으로 구성되어 있고, 사용자가 명확하게 나누어져있기 때문에 각 앱 단위로 나눈 것 같습니다.
packages 폴더에는 api, type 등 client 와 admin 모두 사용하는 공통 코드들이 들어있습니다.
루트에 있는 pnpm-workspace.yaml 파일에
packages:
- "apps/*"
- "packages/*"로 명시되어있는걸로 보아 모노레포로 공유하고 있습니다.
