'폴리리포주의자'가 모노리포를 반대하는 3가지 이유

모노리포(monorepo)와 폴리리포(polyrepo)가 무엇이냐는 질문에 답하려면 먼저 일반적인 애플리케이션을 구성하는 모듈을 살펴보아야 한다. 하나의 애플리케이션에는 여러 가지 구성요소가 있다. 즉, 몇 가지 모바일 클라이언트 앱, 웹 애플리케이션 프론트엔드, 하나 이상의 백엔드 서비스, 데이터베이스 및 데이터 관리 계층, (보고 및 관리와 같은)전문 서비스 등이다. 

각 구성 요소에 연결된 소스 코드도 있다. 구성 요소를 담당하는 모든 개발자가 액세스하는 소스 코드는 코드 리포지토리에 저장된다. 코드 리포지토리와 저장소 관리 방법은 매우 다양하다. 리포지토리 대다수는 깃(Git)이라고 알려진 오픈소스 시스템에 기반한다.
 

각 구성 요소에는 코드 리포지토리가 있다. 자, 여기서 문제가 생긴다. 애플리케이션의 모든 구성 요소에 대한 모든 코드를 회사 전체나 애플리케이션 전체의 코드 리포지토리에 저장해야 하는가? 아니면 각 구성 요소마다 고유한 개별 코드 리포지토리가 있어야 하는가? 최근까지 애플리케이션 각 구성 요소에는 일반적으로 고유한 리포지토리가 있었다. 이 모델은 여러 개의 독립적인 코드 리포지토리를 가진 애플리케이션과 관련이 있으므로 폴리리포라고 한다. 

그러나 최근 몇 년 동안, 특히 구글을 비롯한 일부 업체는 모든 애플리케이션 구성 요소의 모든 코드를 하나의 큰 리포지토리에 집어넣는 쪽에 찬성했다. 이러한 코드 관리 모델을 모노리포라고 한다. 

폴리리포와 모노리포 방법론은 각기 장단점이 있으며, 분석 기사도 많았다. 과연 둘 중 어떤 방식을 사용해야 하는 것일까?

개인적으로는 전통적인 폴리리포 모델이 훨씬 우수하다고 생각한다. 모노리포 모델은 잘못된 습관이나 건전하지 않은 프로세스를 조장하고, 개발 조직의 확장 가능성과 애플리케이션 자체의 복잡성 등으로 애플리케이션 확장이 실질적으로 더 어려워진다. 이 주장을 뒷받침하는 3가지 이유를 면밀히 살펴보자.
 

이유 #1 : 모노리포는 단일 팀 소유 원칙에 위배된다

필자는 단일팀 서비스 소유권을 굳게 지지한다. 서비스, 시스템, 모듈 또는 구성요소의 소유권은 단일 개발팀에 속해야 한다고 생각한다. 팀은 설계, 작성, 테스트, 배치, 운영, 지원 및 수정 등 구성 요소의 모든 측면에 책임을 져야 한다.

이 모델에는 해당 구성 요소의 소스 코드에 대한 모든 변경 내용을 소유하는 것도 포함된다. 팀 구성원만 그 구성 요소의 소스 코드를 변경할 수 있다는 의미가 아니라, 구성 요소에 대한 모든 변경은 소유한 팀의 책임이라는 의미다. 소유 팀은 모든 변경 사항을 검토하고 승인할 권리를 가지고 있어야 한다. 궁극적으로는 구성 요소에 대한 책임을 지기 때문에 구성 요소의 코드를 관리할 수 있어야 한다.

모든 구성 요소의 모든 소스 코드가 동일한 리포지토리에 포함되어 있으면 믿기 어려울 만큼 시행이 어렵다. 액세스 권한, 체크인 절차 및 승인 기능이 동일한 상태에서 우리 팀의 소스 코드와 옆 팀의 소스 코드가 모두 동일한 리포지토리에 있으면, 구성 요소 소스 코드의 소유권과 무결성을 유지하기도 매우 어렵다. 

폴리리포 모델에서는 각 시스템 구성 요소 또는 서비스에는 고유한 자체 리포지토리가 있다. 구성 요소의 소유자는 리포지토리를 소유하고 관리한다. 변경할 수 있는 사람과 변경할 수 없는 사람을 소유자가 정한다. 코드 검토를 수락하고 승인할 수 있는 사람과 그렇게 할 수 없는 사람도 소유자가 결정한다. 리포지토리 소유권은 단일 팀 서비스 소유권 모델에 필요한 전체 소유권의 중요한 부분이다. 
 

이유 #2 : 모노리포는 잘못된 대규모 리팩토링 관행을 조장한다

모노리포의 장점으로 변경 요청 시 코드의 아주 큰 섹션 리팩토링이 쉬워지는 것이 있다. 그래서 내부 API 진입점 변경 같은 큰 작업도 훨씬 쉬워진다. 그 이유는 엔드포인트와 엔드포인트에 대한 모든 호출을 하나의 거대한 요청으로 업데이트할 수 있기 때문이다.

하지만 이런 엄청난 변경은 나쁜 관행이라고 생각한다. 거대한 단일 업데이트에서 팀 경계를 넘나드는 대규모 리팩토링을 수행해서는 안 된다. 대형 프로젝트의 경우 이러한 요청은 대개 여러 개발 팀 간 대규모 조율을 필요로 한다. 변경 사항을 적용하려면 여러 팀이 출시 및 배포 일정을 조정하여 한 번에 모두 처리해야 하는 경우가 많다. 그러면 개별적인 서비스 배치는 거의 관리가 불가능하다. 

대신 내부 API 진입점의 정의를 변경하는 것 같은 전체적인 변경에는 다단계 프로세스를 사용해야 한다. 예를 들면 다음과 같은 방식이 있다.
 

• 새 진입점에 대한 지원을 추가하고 이전 진입점과 새 진입점을 함께 지원하라. 변경 사항을 반영하도록 API 버전을 변경하라. 새 버전의 진입점을 배치하고 당분간 두 진입점을 모두 운용하라.
• 영향을 받는 모든 팀에 새로운 진입점이 게시되었으며 이제부터 이 진입점을 사용해야 한다는 사실을 알려라. 이전 진입점을 ‘구식’으로 표시하고 이전 진입점이 제거되는 예정된 날짜를 알려라. 
• 영향을 받는 팀과 협력하여 원하는 일정 내에서 새로운 진입 지점을 지원할 때 필요한 변경 사항을 확실히 이행하라. 모든 팀이 변경 사항을 배치하여 새 진입점을 사용하도록 하라. 각 팀은 독립적으로 지원을 배치해야 한다.
• 일단 모든 팀이 업데이트된 지원을 배치하고 아무도 이전 진입점을 사용하지 않으면 서비스에서 이전 진입점을 제거해도 된다.

분명 한 리포지토리에 단일한 큰 변경을 가하는 것보다 더 길고 복잡한 프로세스다. 하지만 원래 성취하려던 목적을 생각해 보라. 내부 진입점이 작동하는 방식을 바꾸고, 그 변화의 영향은 전체 조직의 여러 팀에서 체감할 수 있다. 이러한 종류의 변화는 빠르지 않고 구현하기도 쉽지 않아야 한다. 다만 주의하면서 천천히 진행되어야 한다.

전면적인 변화가 가능하려면, 영향을 받는 각 팀과의 조정이 필요하다. 이렇게 방대하고 영향력이 큰 변화를 쉽게 만들어낼 수 있다면 좋은 관행이 아니다. 전체 변경 검토 프로세스를 단축하면 예상치 못한 문제가 발생할 수도 있고, 팀 간 커뮤니케이션과 신뢰도 저하될 수 있다. 
“더 편하잖아”라고 변명하지 말라. 영향력을 고려해 쉽지 않고 빠르지도 않게 만들어야 하는 것이 존재하기 마련이다. 다단계 변경 프로세스는 서두르지 말아야 할, 더 사려 깊고 대규모 평가를 수반하기 때문에 더 오래 걸릴 것이다. 폴리리포는 추가 관리와 평가 의무화에 도움이 되고, 모노리포는 조직 전체에 파괴적인 방식으로 이러한 고려 사항을 단축시켜 손쉽게 만들어준다. 
 

이유 #3 : 작은 리포지토리가 큰 것보다 낫다 

대형 애플리케이션에는 대규모 리포지토리가 있다. 대규모 애플리케이션에 수백 개의 구성 요소가 있고 이러한 구성 요소가 모두 같은 코드 리포지토리에 있다면, 그 리포지토리는 얼마나 거대해질까?

구글 모노리포도 거대하다. 단일 리포지토리는 1차적인 구글 코드를 모두 담고 있고 85 테라바이트가 넘는 20억 줄 이상의 코드가 들어있다. 마이크로소프트 윈도우 운영체제 전체를 합친 것의 40배 크기다.

리포지토리가 클수록 개별 엔지니어는 리포지토리에 넣을코드를 개발하려고 노력하는 작업과 리포지토리 관리를 병행하기가 어려워진다. 단일 리포지토리에서 작업하는 사람이 많고, 리포지토리에서 코드가 자주 변경될 수록 그 리포지토리를 사용하는 개인은 유지보수에 더 많은 공을 들여야 한다.

구글의 경우 매일 모노리포에 4만 5,000건 이상의 변경이 이뤄진다. 애플리케이션의 개발자 수가 증가하고 애플리케이션 내 구성 요소의 수가 확대됨에 따라 오버헤드에서 기하급수적인 문제가 된다.

폴리리포 애플리케이션이라면, 각 구성 요소에 자체 리포지토리가 있고 매일 리포 작업을 수행하는 사람의 수가 적어서 관리가 어렵지 않다. 수천 명의 개발자가 모노리포에서 매일 작업하면서 수천 건의 변경 사항을 관리하는 것이 아니라, 일반적인 폴리리포 팀 리포지토리의 잘 구성된 팀 아키텍처에서 하루에 100건 정도의 변경 사항을 관리하므로 관리 인원도 5명에서 10명 수준에 그칠 것이다.

구글의 경우, 모노리포를 확장해야 하는 도전과제가 너무 커진 나머지 새로운 리포지토리 관리 도구를 개발해야 했다. 전통적인 깃 기반 시스템에서 벗어나 파이퍼(Piper)라는 도구를 만들었다. 특별히 엄청나게 거대한 코드 베이스 처리를 목적으로 설계된 도구지만, 만약 구글이 폴리리포 모델을 사용했다면 필요하지 않았을 것이다. 폴리리포의 각 리포지토리는 깃을 포함한 전통적인 주류 코드 관리 도구로 충분할 만큼 작을 것이기 때문이다. 구태여 특수 도구가 필요하지 않을 만큼 말이다. 
 

모노리포 vs. 폴리리포 : 어떤 것을 선택할까?

사실 정답이 정해져 있지는 않다. 두 가지 관점 모두 강력한 옹호자가 있고, 장점과 단점이 뚜렷하다. 특히 구글은 자사의 모노리포 모델이 완벽하다고 믿고 있으며, 구글에 필요한 일련의 도구와 프로세스를 구축하는 데 많은 투자를 해왔다.

그러나 잘 구성된 개발 환경에서 모노리포의 단점은 장점을 훨씬 능가한다. 반면, 폴리리포는 확장 가능한 최신 애플리케이션 아키텍처에 훨씬 더 유익하고, 더 오래 지속할 수 있으며, 확장성이 뛰어난 환경을 제공한다. editor@itworld.co.kr