멀티레포 vs 모노레포 구조 비교
검토 배경
UI 개발팀에서 관리하는 프론트엔드 저장소가 7개 이상으로 분산되어 있어, 공통 코드의 중복 관리, 빌드 설정의 파편화, 신규 프로젝트 셋업 시 반복 작업 등의 비효율이 누적되어 있었습니다.
이를 모노레포 구조로 통합하면 어떤 이점이 있고, 어떤 과제가 따르는지를 기술적으로 검토했습니다.
검토 항목
도구 비교
| 항목 | 도구 A | 도구 B | 도구 C |
|---|---|---|---|
| 패키지 관리 | 워크스페이스 기본 지원 | 별도 설정 | 별도 설정 |
| 태스크 오케스트레이션 | 병렬 실행·캐싱 | 기본 직렬 | 의존성 기반 실행 |
| CI 빌드 캐싱 | 로컬+리모트 캐시 | 제한적 | 리모트 캐시 |
| 마이그레이션 난이도 | 중 | 하 | 상 |
예상 이점
- 공통 모듈 통합 — SCSS 변수·믹스인, 린트 설정, 빌드 스크립트 등을 단일 패키지로 관리
- 일관된 의존성 — 모든 프로젝트에서 동일한 버전의 도구 사용
- CI 빌드 최적화 — 변경된 패키지만 빌드하여 파이프라인 시간 단축
- 코드 리뷰 통합 — 공통 모듈 변경이 영향받는 프로젝트와 함께 리뷰 가능
예상 과제
- 기존 7개 저장소의 Git 히스토리 보존 전략 필요
- 각 저장소별 CI/CD 파이프라인을 모노레포용으로 재구성
- 팀원들의 모노레포 워크플로우 학습 비용
- 저장소 크기 증가에 따른 clone/checkout 시간 관리
전환 전략 제안
- 점진적 전환 — 한 번에 모든 저장소를 통합하지 않고, 공통 모듈부터 먼저 추출
- 파일럿 프로젝트 — 2~3개 저장소로 먼저 통합 테스트 후 전체 확대
- 빌드 캐싱 우선 — 모노레포 도구의 빌드 캐싱을 먼저 활용하여 성과를 입증