모노레포는 여러 프로젝트·패키지를 하나의 저장소에 폴더로 나눠 함께 관리하는 방식이다. 프로젝트마다 저장소를 따로 두는 방식은 멀티레포(폴리레포)라고 부른다. 모노레포가 곧 하나의 거대한 앱(모놀리스, monolith)이라는 뜻은 아니다. 배포 단위는 여전히 따로일 수 있다.
repo/
├── apps/
│ ├── web/
│ └── admin/
├── packages/
│ ├── ui/ 공통 컴포넌트
│ └── utils/
└── package.json 워크스페이스 루트얻는 것
- 코드 공유: 공통 UI·유틸·타입을 패키지로 두고 여러 앱이 쓴다. 고치면 모든 사용처에 바로 반영된다
- 원자적 변경(atomic change): "API 타입과 그걸 쓰는 화면을 같이 고치는" 작업을 커밋·PR 하나로 끝낸다
- 일관된 도구: 린터·포맷터·테스트·CI 설정을 한 번 맞추면 전체에 적용된다
내는 것 (monorepo tax)
- 저장소가 커질수록 클론·설치·빌드·CI가 느려진다
- 프로젝트별 권한을 세밀하게 나누기 어렵다
- 한 패키지 변경이 어디에 영향을 주는지 알아야 해서 의존성 그래프(dependency graph) 관리가 필요하다
도구
- 패키지 매니저의 워크스페이스(workspace)로 시작한다(pnpm 워크스페이스, npm과 pnpm)
- 빌드가 느려지면 바뀐 부분만 빌드하고 결과를 캐시하는 도구를 얹는다: 가볍게는 Turborepo, 코드 생성·아키텍처 규칙·다중 언어까지 필요하면 Nx
- 기존 저장소를 히스토리째 옮기는 방법은 여러 저장소 합치기
공통 코드를 쉽게 공유할 수 있는 만큼, 패키지 사이의 경계가 흐려지지 않게 결합도를 의식해야 한다. 런타임 아키텍처인 마이크로 프론트엔드와는 별개라 함께 쓸 수 있다. 배럴 파일(barrel file)로 패키지 공개 API를 정리하는 습관은 배럴 파일과 re-export을 본다.