[형상 관리] 모노리포 vs 멀티리포 / Monorepo vs Multirepo

저장소 관리 전략의 필요성

프로젝트 초기에는 모노리딕 시스템으로 서비스를 구현하게 된다. 다만 프로젝트가 거대화되면서 모노리딕 시스템은 높은 결합도와 낮은 응집력을 가지고 있기에 이를 해결하기 위해서 개발 조직은 시스템의 각 부분을 도메인 별로 분리해서 마이크로 서비스로 구성하기 시작하게되며 이때 개발 조직은 쪼개진 각 서비스를 하나의 리포지토리에서 관리할지, 각자 다른 리포지토리에서 관리할지 고민하게 된다.

 

모노리포, 멀티리포

저장소 관리 방식은 프로젝트의 규모, 개발 환경, 팀 구성 등 다양한 요소에 따라 선택되며, 이 중에서 가장 일반적인 방식으로는 모노레포와 멀티레포가 있다.

리포지토리를 관리하는 방법은 시스템의 각 모듈을 개별 리포지토리에서 관리할 것인지, 하나의 리포지토리에서 관리할 것인지에 따라서 달라지는데, 이때 나눠서 관리하는 것을 멀티리포, 하나로 관리하는 것을 모노리포라 정의한다.

 

 

멀티레포

멀티 레포는 각 프로젝트가 고유의 저장소를 가지게 됨으로써, 다른 프로젝트와의 의존성을 가지고 있지 않는 구조입니다.시스템의 서비스별로 리포지토리를 각자 만들어서 관리하고 서비스 간의 연동이 소스 단위로 이루어지지 않으며 각 서비스가 별도의 폴더로 구성됩니다.

장점

• 강한 오너쉽 확보
  • 리포지토리 별로 오너를 지정
• 마스터의 코드가 깨질 여지가 적음
  • 코드 베이스가 아예 나뉘어 있음
  • 서로 간의 작업 충돌로 마스터 코드가 깨질 가능성이 적음
• 형상 관리, CI 속도가 빠름
  • 리포지토리의 크기가 작기 때문에, 리파지토리 훅을 기반으로 동작하는 도구들의 속도가 빨라짐

 

멀티 레포 방식은 팀 개별로 관리하기 때문에 강한 오너쉽을 가지고 운영할 수 있으며 형상 관리 툴의 작업 시간이 적은 편이기에 편리하고 빠른 퍼포먼스를 보일 수 있다는 장점이 있다. 그러나 장기적인 팀 차원에서 보았을 때는 프로젝트가 많아지고 팀원이 빠르게 늘어나면서 컨텍스트 공유의 문제점이 팀 전체적인 업무 퍼포먼스를 크게 악화시킬 것이라는 의견도 있다.

 

그렇다면 멀티레포 대신 모노레포?

멀티레포의 운영은 관리하는 프로젝트가 많아질수록 아래와 같은 문제점이 발생할 수 있다.

• 각 프로젝트의 코드 컨벤션이 통일하기가 어려워질 수 있습니다.
• 각 프로젝트별로 사용하는 모듈 및 버전 스택이 달라질 수 있습니다.
• 시간이 지날수록 오래된 프로젝트의 Legacy 파악이 어려워질 수 있습니다.
• 팀원별 컨텍스트 공유가 서로 원활하지 않을 수 있습니다.

팀이 커지면서 많은 팀원과 많은 프로젝트가 컨벤션을 다 같이 맞추어 나가기란 쉽지 않다. 그렇기에 하나의 팀이 장기적으로 협업 능률과 팀 퍼포먼스를 유지할 수 있는 환경을 만들어 가는 것은 팀과 기업 관점에서 매우 중요한 사항이며 이러한 문제들을 해결하기 위해 모노레포 시스템을 고려해볼 수 있다.

 

모노레포

모노레포는 시스템의 각 서비스를 모두 하나의 리포지토리에서 일괄 관리하며 서비스 간의 연동이 소스 단위로 이루어집니다. 최상위 폴더부터 트리 구조로 서비스 폴더가 구성됩니다.

장점

• 지속적인 소스의 무결성 보장
  • 리포지토리는 항상 모든 서비스가 연동된 올바른 상태를 유지함
• 통합된 버전 관리
  • 모든 서비스가 연동된 상태에서 손쉽게 하나의 버전으로 관리 가능
• 코드의 공유와 재사용이 용이
  • 소스 단위의 연동이 이루어진 상태
• 의존성 관리가 쉬움
  • 전체 서비스의 의존 관계가 한 리포지토리에서 확인 및 설정 가능
• 원자 단위 변화
  • 변화가 여러 스텝이 아니라 한 리포지토리에서 한 스텝으로 이루어짐
• 여러 프로젝트팀 간의 협업이 쉬움
  • 하나의 리포지토리에서 함께 작업하며, 여러 서비스에 손쉽게 접근 가능
• 유연한 팀 바운더리 설정과 코드 오너쉽을 가져갈 수 있음
  • 하나의 리포지토리, 하나의 서비스에 제한된 코드 오너쉽을 유지하지 않아도 됨
• 통합 CI 및 테스트
  • 모든 소스가 연동된 상태. CI 및 테스트 구성이 손쉬움
• 전체 코드가 트리 구조로 명확히 보임
• 한 번의 코드 리뷰에 모든 변화가 요약

 

구글도 쓰는 모노레포

구글에서도 모노레포를 사용하고 있다. 그것도 몇몇 프로젝트(Chromium, Android 등)를 제외하면 대부분의 코드가 하나의 레포지토리에서 관리되고 있다.

 

관련 아티클: 

Why Google Stores Billions of Lines of Code in a Single Repository

 

구글에서는 모노레포의 장단점을 어떻게 생각하고 있을까? 우선 장점이다.

• Unified Versioning

하나의 레포지토리는 버전 관리를 한 번에 할 수 있다. 여러 레포지토리로 굴러갈 때는 각자 버전을 관리하다보니 누락되거나 다른 레포지토리와 연결할 때 버전을 계속 확인 및 맞춰줘야 하는 귀찮음이 있다. 하지만 한 레포지토리로 관리하면 아예 버전을 하나로 관리하거나, 여러 모듈의 버전을 관리하기 수월해진다.

• Extensive Code Sharing & Reuse

가끔은 다른 팀이 만든 코드에 있는걸 사용해야 할 때가 있다. 예를 들면 재사용되는 디자인 컴포넌트들이나, 구글이 가지고 있는 풍부한 내부 라이브러리가 있을 것이다. 이를 적절히 공유하고 재사용할 수 있으므로 업무 효율을 높일 수 있다.

• Simplified Dependency Management

외부 라이브러리를 사용하는 경우도 분명히 있을텐데, 그런 외부 디펜던시의 버전을 맞추기 용이해진다. 모노레포를 잘 사용하면 베이스 라이브러리만 변경되더라도 Final Product 단까지 잘 적용할 수 있다.

• Atomic Changes

변경 사항을 보다 Atomic하게 관리할 수 있다. 원자적이라는 말은 더 쪼개지지 않는, 그 중간 과정을 확인할 수 없다는 의미로 받아들이면 된다.

만약 어떤 라이브러리 코드를 바꿔서, 이를 이용하고 있는 다른 멀티레포 저장소들을 돌아다니면서 하나 바꾸고 커밋 찍고, 또 하나 바꾸고 커밋 찍고… 이런 과정이 연속적으로 이뤄지게 된다. 이런게 변화하는 중간 과정이 보인다고 생각할 수 있다. 만약 각 커밋마다 테스트가 돌아간다면 각 레포에서 커밋을 찍을 때마다 테스트가 터져서 마음이 아프기도 할 것이다.

하지만 모노레포로 하면 어떤 변경 사항을 여러 독립된 프로젝트에서 적용해야 하면 한번에 고쳐서 하나의 커밋으로 관리할 수 있다. 이걸 변화 과정이 원자적이라고 말할 수 있을 것이다.

• Large Scale Refactoring

여러 독립적인 프로젝트에 적용되어야 하는 변화사항의 경우 각각 돌아다니면서 고치는 것보다는 한 레포지토리에서 고치는게 훨씬 쉽다.

• Flexible Team Boundaries and Code Ownership

팀 간 협업이 자유로워진다. 서로 같은 코드 베이스에서 일하고 있기 때문에 변경 사항이 있거나 협업할 일이 있으면 보다 유연하게 코드를 왔다갔다 할 수 있다. 동시에 코드에 대한 Ownership도 자유로워질 것이다.

 

그러면 어떤 단점이 있을까? 일단 구글에서 제시한 단점이 몇가지 있긴 하다.

• Tooling Investments for Both Development and Execution

개발 및 실행에 필요한 환경을 구성하는데 투자를 해야 한다.

근데 사실 이건 설정을 여기저기서 할 필요 없이 모노레포에서 한 방에 할 수 있다는건 오히려 큰 장점이라고 생각된다. 하지만 단점인 이유는 바로 86TB의 구글 코드 베이스라서 그렇다.

코드가 너무 많아서 인덱싱 기능도 구글에서 직접 만들어야 하고, IDE도 구글 코드에 맞게 이클립스를 개조해야 했다. 그리고 코드가 계속 늘어나고 있으므로 이에 대해 꾸준히 추가적인 개발 코스트가 들어가는 상황이다.

근데 일반적인 회사에서는 단점이라고 볼 수는 없을 것 같다.

• Effort Invested in Code Health

모노레포에서는 디펜던시를 추가하는 것이 쉽다보니, 그냥 별 생각 없이 라이브러리를 다운받고 그냥 놔두거나, 옛날에 썼지만 어쩌다보니 안쓰게 된 디펜던시들이 많이 생기다고 한다. 또한, 구글에서는 내부에서 사용할 라이브러리 개발에 집중하는 개발자도 있는데, 그 개발자 입장에서는 사용하는 곳을 확인하고 싶을 때 불편한 점이 있다고 한다.

 

모노레포 단점에 대한 다른 의견

구글의 의견은 위와 같지만 모노레포의 단점에 대한 다른 커뮤니티의 의견도 찾아보았다.

• Code Ownership에 위배된다

서비스, 시스템, 모듈, 컴포넌트 등의 소유권은 단일 개발팀에 속해야 한다고 생각하는 개발자도 많다. 각 코드에 대한 소유권, 변경 사항에 대한 책임이 모두 소유자에게 있도록 하는 것이 코드 관리에 더 도움이 된다는 입장이다.

구글에선 장점이라고 했던 유연한 소유권이 코드 관리를 더 어렵게 할 수도 있다는 의견이다.

• 대규모 리팩토링이 쉬워지는 나쁜 관행이 생긴다

또 구글은 대규모 리팩토링이 쉬워지는게 장점이라고 했지만, 이게 치명적인 단점이라고 생각하는 사람도 있다.

거대한 프로젝트에서 팀 경계를 넘나드는 대규모 리팩토링을 하는 것은 굉장히 위험한 점이 있기 때문에, 여러 단계를 거치면서 각 레포지토리에 대한 Ownership을 가진 팀의 승인을 받아 진행하는 것이 좋다고 볼 수도 있다.

 

결론은?

모노레포의 특징을 누군가는 장점으로, 누군가는 단점으로 보고 있다. 같은걸 보고 다른 생각을 하니 서로의 입장이 첨예하게 대립할 수 밖에 없다.

 

뻔한 얘기일 수도 있지만, 팀 규모, 프로덕트 규모에 따라서 정하는 것이 적절해보인다.

 

다만 개인적인 의견은 복잡하지 않은 프로덕트를 가진 소규모 회사의 경우에는 모노레포로 하는 것이 좋아보인다. 이런 경우 여러 프로젝트를 한 개발팀이 담당해야 하는 경우가 많고, 그럴 때는 멀티레포보다는 모노레포로 한번에 관리할 수 있는 것이 장점일 것 같다.