Monorepo와 Polyrepo란 무엇인가
여러 프로젝트를 관리하는 방식은 크게 두 가지로 나뉩니다. Monorepo는 하나의 저장소(repository) 안에 여러 서비스나 모듈의 코드를 모두 담는 방식이고, Polyrepo는 서비스나 모듈마다 별도의 저장소를 만들어 독립적으로 관리하는 방식입니다. 예를 들어 프론트엔드, 백엔드, 공용 라이브러리를 각각 다른 깃 저장소로 관리한다면 Polyrepo, 이 세 가지를 하나의 저장소 안에 폴더로 나눠 관리한다면 Monorepo라고 할 수 있습니다.
구조와 동작 방식으로 보는 차이
Monorepo는 아파트 한 동에 여러 세대가 모여 사는 구조와 비슷합니다. 같은 건물(저장소)을 쓰기 때문에 관리사무소(빌드/CI 설정)를 한 번만 두면 되고, 이웃(다른 모듈)과 자원을 쉽게 공유할 수 있습니다. 반면 Polyrepo는 각자 독립된 단독주택에 사는 것과 같아서, 자기 집 안에서는 자유롭지만 이웃과 무언가를 공유하려면 별도의 이동과 절차가 필요합니다.
실제로 Monorepo에서는 한 번의 커밋으로 여러 모듈을 동시에 수정할 수 있고, lerna나 nx, turborepo 같은 도구로 변경된 패키지만 골라 빌드하거나 테스트합니다. Polyrepo에서는 각 저장소가 독립된 버전과 배포 파이프라인을 가지며, 공용 코드는 별도의 패키지로 배포해 npm install처럼 가져다 씁니다.
실무에서는 무엇을 기준으로 선택할까
선택 기준은 팀의 규모와 코드 간 의존성에 달려 있습니다.
- 여러 서비스가 공통 코드를 자주 공유하고, 한 번에 여러 모듈을 함께 수정해야 한다면 Monorepo가 협업과 리팩터링에 유리합니다.
- 팀별로 배포 주기와 기술 스택이 완전히 다르고, 서로의 코드에 거의 관여하지 않는다면 Polyrepo가 권한 관리와 독립 배포에 유리합니다.
- 저장소 크기가 커질수록 Monorepo는 빌드 속도와 CI 최적화 전략이 중요해지므로, 이를 지원하는 도구 도입을 함께 고려해야 합니다.
정답은 하나로 정해져 있지 않습니다. 구글이나 메타처럼 거대한 Monorepo를 운영하는 조직도 있고, 마이크로서비스 단위로 철저히 Polyrepo를 고수하는 조직도 있습니다. 팀의 협업 방식과 배포 전략을 먼저 정리한 뒤, 그에 맞는 저장소 전략을 고르는 것이 가장 안전한 접근입니다.