Monorepo vs Polyrepo¶

소프트웨어 개발 프로젝트가 커짐에 따라 소스 코드를 관리하는 저장소(Repository)의 구조를 어떻게 가져갈 것인가는 중요한 기술적 의사결정 중 하나입니다. 크게 Monorepo(단일 저장소) 전략과 Polyrepo(다중 저장소, Multi-repo) 전략으로 나뉩니다.

1. Monorepo (단일 저장소)¶

Monorepo는 Monolithic Repository의 약자로, 두 개 이상의 프로젝트 코드가 동일한 저장소에 저장되는 소프트웨어 개발 전략입니다.
Google, Facebook(Meta), Microsoft, Twitter 등 대규모 테크 기업들이 채택하면서 널리 알려졌습니다.

✅ 장점¶

코드 공유 용이성 (Visibility & Sharing):
- 모든 코드가 한곳에 있어 공통 라이브러리나 모듈을 공유하기 매우 쉽습니다.
- 다른 팀의 코드를 참고하거나 재사용하기 편리합니다.
원자적 커밋 (Atomic Commits):
- 서로 의존성이 있는 여러 프로젝트를 수정해야 할 때, 한 번의 커밋으로 변경 사항을 적용할 수 있습니다.
- 프로젝트 간 버전 불일치 문제를 원천적으로 방지합니다.
단일화된 의존성 관리 (Dependency Management):
- 모든 프로젝트가 동일한 버전의 라이브러리를 사용하도록 강제하기 쉬워, 의존성 충돌을 줄일 수 있습니다.
리팩토링의 용이성:
- 대규모 리팩토링 시 영향 범위를 한 번에 파악하고 수정할 수 있습니다.

❌ 단점¶

저장소 성능 문제:
- 프로젝트가 거대해지면 git clone, pull, checkout 등의 속도가 느려질 수 있습니다. (VFS for Git 등으로 해결 시도)
빌드 및 CI 속도 저하:
- 변경 사항이 발생했을 때 전체를 빌드하거나 테스트해야 한다면 CI 시간이 기하급수적으로 늘어납니다. (스마트한 캐싱 및 영향도 분석 빌드 도구 필수)
권한 관리의 복잡성:
- 특정 디렉토리에 대해서만 읽기/쓰기 권한을 제어하기가 Git의 기본 기능만으로는 까다롭습니다.

🛠️ 대표적인 도구 (Build Systems)¶

단순히 폴더만 모아둔다고 Monorepo가 아닙니다. 효율적인 관리를 위한 도구가 필수적입니다.

JavaScript/TypeScript: Turborepo, Nx, Lerna, Yarn Workspaces
General: Bazel (Google), Buck (Facebook), Gradle (Java/Kotlin)

2. Polyrepo (다중 저장소 / Multi-repo)¶

Polyrepo는 프로젝트(또는 마이크로서비스)마다 별도의 저장소를 사용하는 전략입니다. 현재 대부분의 팀이 기본적으로 사용하는 방식입니다.

✅ 장점¶

팀의 자율성 보장:
- 팀마다 독립적인 개발 주기, 배포 프로세스, 코딩 컨벤션을 가질 수 있습니다.
가벼운 저장소:
- 각 저장소의 크기가 작아 클론 및 관리가 빠르고 간편합니다.
명확한 접근 제어:
- 저장소 단위로 권한을 부여하여 보안 관리가 수월합니다.
CI/CD 파이프라인 단순화:
- 해당 프로젝트만 빌드하고 배포하면 되므로 파이프라인 구성이 직관적입니다.

❌ 단점¶

코드 공유의 어려움:
- 공통 코드를 공유하려면 별도의 라이브러리로 패키징하고, 버전 업 때마다 각 저장소에서 버전을 올려줘야 하는 번거로움이 있습니다.
의존성 지옥 (Dependency Hell):
- 서비스 간에 서로 다른 버전의 라이브러리를 사용하거나, API 변경 시 호환성 문제가 발생하기 쉽습니다.
변경 사항 전파의 어려움:
- 여러 서비스에 걸친 기능을 수정해야 할 때, 여러 저장소에 각각 PR을 날리고 순서에 맞춰 배포해야 하는 복잡함이 있습니다.

3. 요약 및 선택 가이드¶

특징	Monorepo	Polyrepo
코드 가시성	높음 (한 곳에 모임)	낮음 (격리됨)
의존성 관리	중앙 집중형 (일관성 유지 유리)	개별 관리 (유연하지만 파편화 위험)
협업	팀 간 경계가 낮음	팀 간 경계가 명확함
CI/CD	복잡함 (영향도 분석 등 고도화 필요)	비교적 단순함
적합한 조직	강한 협업과 코드 공유가 필요한 조직	팀 간 독립성이 중요하고 느슨하게 결합된 조직

언제 Monorepo를 선택해야 할까요?

프로젝트 간 코드 공유가 빈번할 때 (예: 프론트엔드와 백엔드가 타입을 공유, 여러 앱이 UI 컴포넌트 공유)
대규모 리팩토링이 자주 발생할 때
팀 전체가 동일한 툴체인과 스타일을 유지하고 싶을 때

언제 Polyrepo를 선택해야 할까요?

서비스 간 결합도가 매우 낮고 완전히 독립적으로 배포될 때
팀별로 사용하는 기술 스택이 완전히 다를 때
강력한 보안 격리가 필요할 때