Mono Repository(모노레포) vs Poly Repository(폴리레포)

태그
개발패러다임
Mono Repository (모노 레포)
레포지토리 하나에 대해 여러 서비스들을 모두 포함한다. 버전관리를 레포지토리 하나로 운영하는 방식이다.
참고로 구글, 우버, 넷플릭스도 모노레포를 적극적으로 잘 사용하고 있다고 한다. 특히 구글은 모노레포를 광신..하는 대표적인 조직이기도 한데, 아무래도 구글의 경우 개발하는 서비스들이 워낙 많다보니, 그것들을 통합적으로 관리하는데 있어 모노레포가 훨씬 더 많은 이점을 줘서 그렇지 않을까라는 추측이 든다.
관련된 대표적인 도구들로
  • Node - lerna, pnpm, yarn workspace
  • Jvm - Gradle Multimodule
정도 있겠다.
장점
  • 의존성 관리가 쉬워진다. 폴리레포의 경우 여러군데 훝어져있어서 의존성 그래프가 복잡해지면 그만큼 추적과 관리가 어려울 수 있는데, 이에 반해 모노레포방식은 하나의 레포지토리 내에서 모든 서비스의 의존성들을 파악하는게 가능하다.
  • Breaking Change의 추적이 쉽다. 빌드해서 에러가 뜨는 걸 확인할 수 있다.
단점
  • 모노레포가 커지면 CI가 커지고 무거워짐에 따라 오래걸린다.
 
Poly Repository (폴리 레포)
모노레포의 반대 방식으로 서비스별로 레포지토리를 하나씩 사용하도록 하는 버전관리 방식이다. 서비스 하나에 대해 레포지토리를 하나 할당하는 방식이므로 모노레포에 비하면 조금 더 직관적이다. 보통은 폴리레포 방식이 더 친숙하다고 느끼는 경우가 많은데, 도메인이 서로 다른 서비스를 한데 다 묶어서 관리한다는 패러다임 자체가 어떻게 보면 이해하기 힘들 수도 있다. 그래서 보통은 모노 레포 방식보다는 여전히 폴리 레포 방식을 더 많이 사용한다.
MSA를 운영하는 회사가 있다고 가정해보자. 잘게 나뉜 마이크로 서비스들의 코드베이스는 모두 서비스 단위로 분리된다. 서비스에 대한 코드 저장소도 마찬가지로 분리되어 저장된다. 이는 회사, 조직 마다 가져가는 정책에 따라 다르겠지만, 분리된 서비스니, 코드의 저장도 물리적으로 다른 곳에 위치하여 가져가는 것을 직관적으로 생각할 수 있다.
MSA가 아니더라도
장점
  • CI가 모노레포 방식보다 빠르다.
 
단점
  • 서비스가 너무 많아진다면, 그만큼 레포지토리도 늘어나니, 오히려 관리하기 어려울 수 있다.
  • 느슨한 결합으로 인해 서로 다른 서비스간의 관계에서 발생하는 업데이트를 서로 다른 서비스의 레포지토리에서 추적하기 어려울 수 있다.