언제 다중 저장소(Multirepo(멀티레포))를 쓰고 언제 단일 저장소(Monorepo(모노레포))를 써야 하는 지에 대해 설명합니다.


우리는 소스 코드를 관리하기 위해 깃(Git)이나 서브버전(Subversion; SVN)과 같은 버전 관리 시스템을 사용합니다. 이때 각 프로젝트 별로 하나 하나 저장소(Repository)를 만들어야 할까요, 아니면 하나의 저장소에서 모든 프로젝트를 관리해야 할까요?

여러 저장소를 만드는 다중 저장소(Multirepo) 방식과 하나의 저장소로 해결하는 단일 저장소(Monorepo) 방식 중 하나를 택해야 합니다.

결론 🔗

먼저 우리가 사용하는 것이 버전 관리 시스템이라는 사실에 주목해야 합니다. 버전 관리 시스템은 버전 관리의 주체로서 저장소를 사용합니다. 만약 저장소가 달라진다면 하나의 저장소에서 다른 저장소의 버전 기록(Version history)을 확인할 수가 없습니다. 이것이 핵심입니다. 하나의 프로젝트에 관련된 사람들이 다른 프로젝트의 버전 기록에 대해 신경 쓸 필요가 없을 때, 우리는 저장소를 분리해야 합니다.

물론 이외에도 권한 측면에서 저장소를 여러 개로 쪼개야 한다거나, 아니면 편의성으로 인해 여러 저장소를 하나로 통합할 수도 있습니다. 하지만 가장 먼저 고려해야 할 것은 버전 기록을 공유하는 것이 효과적이냐 아니냐에 있습니다.

다중 저장소(Multirepo)가 좋은 경우 🔗

모든 프로젝트의 버전 기록이 프로젝트와 관련된 모든 사람들에게 의미가 있다고 보기 어렵다면, 여러 저장소로 나누어 관리하세요.

사례 1. 오픈 소스 🔗

오픈 소스라면 특히 저장소를 여러 개로 나누는 것이 중요합니다. 만약 어떤 단체에서 여러 오픈 소스 프로젝트를 운영한다고 했을 때, 단체에 속한 개발자들은 단체의 오픈 소스 프로젝트 모두에 대해 관심이 있을 수 있습니다. 그러나 오픈 소스에 참여하는 사람들 전부가 그 단체의 모든 프로젝트에 대해 관심이 있는 것은 아닙니다.

오픈 소스를 사용하는 사람들이 누가 될지 알 수 없기 때문에, 프로젝트들 중 일부에만 관심을 가지려 하는 사람이 없다고 말할 수 없습니다. 그렇기에 설령 프로젝트 간에 의존성이 있더라도 분리하는 게 좋습니다. (물론 각 오픈 소스 프로젝트들이 서로 매우 밀접한 관계를 가진다면 하나의 저장소에서 관리할 수도 있습니다.)

단일 저장소(Monorepo)가 좋은 경우 🔗

모든 프로젝트의 버전 기록이 프로젝트와 관련된 모든 사람들에게 의미가 있다면, 하나의 저장소로 유지하는 게 좋습니다.

사례 2. 소규모 다중 프로젝트 🔗

완전히 독립적인 여러 서비스를 운영한다고 하더라도 경우에 따라 단일 저장소를 사용할 수 있습니다. 스타트업과 같이 규모가 작은 기업의 경우 서비스 별로 개발자들이 완벽하게 나뉘기가 어렵습니다. 한 개발자가 여러 서비스에 걸쳐 무언가를 개발할 수도 있고, 아니면 적어도 다른 서비스에 대한 진행 상황(즉 버전 기록)을 지속적으로 확인할 필요가 있습니다. 서로 다른 서비스에 대한 진행 상황을 확인할 필요가 없을 정도로 개발자들이 서비스 별로 완전히 분리되어 있다면, 그때는 저장소를 분리하는 것이 낫습니다.

사례 3. 대규모 단일 프로젝트 🔗

하나의 서비스가 매우 커지게 되는 경우 너무 규모가 커지기 때문에 저장소를 쪼개야 하지 않나 하는 생각이 들기도 합니다. 하지만 이런 경우에도 단일 저장소를 유지하는 게 좋을 수 있습니다. 물론 자신이 담당하는 부분만 자세히 알 뿐, 다른 사람의 코드는 제대로 알지 못할 수도 있습니다. 그럼에도 결국 모두가 만드는 서비스는 하나입니다. 서로의 개발 상황, 버전 기록에 대해 잘 알고 있어야 합니다.

프로젝트 별 버전 매기기 🔗

저장소를 통합한다고 해서 각 프로젝트의 버전을 따로따로 매기지 못한다는 말은 아닙니다. Node.JS(노드.js)의 Lerna(러나), 자바의 메이븐 다중 모듈같이 각 프로젝트 별로 버저닝을 할 수 있도록 도와주는 많은 도구가 있습니다.