Monorepo vs Polyrepo: 무엇이 더 나을까?

소프트웨어 개발에서 코드 저장소(Repository)를 어떻게 관리할 것인가는 매우 중요한 결정인데요. 일반적으로 Monorepo(모노레포)와 Polyrepo(폴리레포) 두 가지 방식이 있습니다.

• Monorepo: 하나의 리포지토리에 모든 프로젝트 코드를 관리하는 방식
• Polyrepo: 서비스 또는 모듈별로 개별 리포지토리를 운영하는 방식

이 글에서는 각 방식의 장단점, 문제점 및 해결 방안, 그리고 실제 사례를 통해 어떤 경우에 Monorepo가 좋고, 어떤 경우에 Polyrepo가 더 나은지 알아보겠습니다.

---

Monorepo란?

Monorepo의 장점

1. 코드 일관성과 재사용성

• Google은 모든 프로젝트를 하나의 Monorepo에서 운영하며, 공통 모듈을 쉽게 공유하고 유지보수합니다. Google은 내부적으로 Piper라는 분산 버전 관리 시스템을 활용하여 Monorepo 환경을 유지하며, 이에 대한 자세한 내용은 여기서 확인할 수 있습니다.
• 스타트업 A는 Auth, Logging, Monitoring 등의 공통 기능을 하나의 리포지토리에서 관리하여 중복 코드를 줄였습니다.

2. 단일 CI/CD 파이프라인으로 운영 가능

• Facebook (Meta)에서는 WhatsApp, Instagram 등이 하나의 Monorepo에서 관리되며, Bazel과 Buck을 활용해 변경된 코드만 빌드하는 방식을 적용했습니다. Facebook은 자체적으로 개발한 빌드 시스템 Buck을 활용하여 Monorepo 환경에서 빌드를 최적화합니다. 

3. 협업 및 개발 환경 통일

• Tesla는 차량 소프트웨어를 Monorepo로 관리하여 모든 팀이 동일한 환경에서 협업할 수 있도록 운영합니다.
  Tesla는 OTA(Over-the-Air) 업데이트 시스템을 활요하여 모든 차량 모델이 공통된 코드베이스에서 업데이트될 수 있도록 유지하고 있으며, 이로 유추하여 볼때, 같은 코드베이스를 사용하는 Monorepo 라고 예측해볼 수 있습니다.

4. 공통 라이브러리 관리 용이

• Microsoft는 Office Suite (Word, Excel, PowerPoint)의 공통 모듈을 하나의 리포지토리에서 유지보수하여 업데이트 비용을 절감합니다. 모노리포에 대한 내용은 여기서 확인할 수 있습니다.

Monorepo의 문제점 및 해결 방안

리포지토리 크기가 커질수록 관리가 어려움	Sparse Checkout, Git LFS, Partial Clone 활용
CI/CD가 무겁고 배포 속도가 느려질 가능성 있음	nx, Bazel, Turborepo로 변경된 코드만 빌드하는 방식 적용
기술 스택의 유연성이 떨어질 수 있음	workspace 개념을 활용하여 모듈별 독립적인 실행 환경 구성

---

Polyrepo란?

Polyrepo의 장점

1. 서비스별 독립적인 운영 가능

• Netflix는 account-service, streaming-service, recommendation-engine을 각각 독립적인 리포지토리로 운영하여 장애가 발생해도 다른 서비스에 영향을 주지 않습니다. Netflix는 Polyrepo 방식을 통해 개별 서비스가 독립적으로 배포 및 운영될 수 있도록 설계했으며, 이에 대한 자세한 내용은 Netflix Tech Blog와 Netflix Open Source GitHub에서 확인할 수 있습니다.

2. 각 서비스별 독립적인 기술 스택 운영 가능

• Uber는 ride-service, eats-service, freight-service를 개별적으로 운영하며, 각 서비스에서 다른 언어를 사용할 수 있습니다.
  Uber는 Polyrepo 방식을 통해 각 마이크로서비스가 독립적으로 배포 및 운영될 수 있도록 설계했으며, 이에 대한 내용은 여기서 그리고 Uber Github 에서 확인할 수 있습니다. 

3. 배포 속도와 확장성이 높음

• Amazon AWS는 S3, EC2, Lambda 등 독립적인 서비스로 운영하여, 특정 서비스만 개별적으로 배포할 수 있습니다.

Polyrepo의 문제점 및 해결 방안

문제점	해결 방안
공통 모듈 관리가 어렵고 코드 중복 발생 가능	Private npm registry, Shared Git Submodules 활용
CI/CD 파이프라인이 개별적으로 운영되어 관리 부담 증가	IaC(Infrastructure as Code) 활용하여 통일된 배포 전략 유지
의존성 드리프트 발생 가능	Semantic Versioning, API Gateway, GraphQL Federation 활용

---

Monorepo vs Polyrepo: 어떤 것이 더 나을까?

Monorepo가 적합한 경우

• Google, Facebook, Tesla, Microsoft 같은 기업
• 코드 일관성이 중요하고, 공통 모듈이 많을 때
• CI/CD를 통합적으로 운영하고 싶을 때
• 스타트업 초기 단계에서 빠르게 개발하고 협업하고 싶을 때
• 프론트엔드, 백엔드, 모바일이 하나의 프로젝트처럼 운영될 때

Polyrepo가 적합한 경우

• Netflix, Uber, Amazon AWS 같은 기업
• 팀별로 독립적인 운영이 필요할 때
• 긴급 배포가 빈번하게 이루어지고, 서비스별 배포 속도가 중요한 경우
• 다양한 기술 스택을 자유롭게 사용하고 싶을 때
• 대규모 MSA(마이크로서비스 아키텍처)를 운영하는 경우

---

결론

Monorepo vs Polyrepo의 정답은 없습니다.

• 초기 스타트업이나 공통 모듈이 많은 팀 → Monorepo가 유리
• 대규모 서비스나 팀별 독립성이 중요한 경우 → Polyrepo가 유리
• 정답은 없으며, 조직의 목표와 운영 방식에 따라 선택해야 함

모든 기업이 완전히 Monorepo 또는 Polyrepo만을 고집하는 것은 아닙니다. 실무에서는 특정 서비스나 프로젝트에 따라 Monorepo와 Polyrepo 방식을 혼합하여 사용하는 경우가 많습니다. 예를 들어:

• 공통 라이브러리나 코어 기능은 Monorepo에서 관리하고, 독립적으로 운영할 서비스는 Polyrepo에서 분리하여 관리하는 방식
• 초기에는 Monorepo를 사용하다가 프로젝트가 확장됨에 따라 Polyrepo로 전환하는 방식
• 팀별로 선호하는 방식이 다를 경우, 각 팀의 요구에 맞춰 서로 다른 코드 저장소 구조를 채택

따라서, Monorepo와 Polyrepo의 장단점을 이해하고 기업 환경과 개발 목표에 맞는 최적의 전략을 선택하는 것이 중요합니다. 댓글로 의견을 공유해주세요.