반응형
프로젝트를 시작할 때, Git 저장소(Repository)를 어떻게 구성할지는 개발팀이 마주하는 첫 번째 중요한 결정 중 하나입니다. 프론트엔드 코드, 백엔드 코드, 공용 라이브러리 등을 하나의 거대한 저장소에 모두 담을까요? 아니면 각 프로젝트를 여러 개의 독립된 저장소로 분리할까요?
이것이 바로 구글, 페이스북 같은 거대 기업부터 작은 스타트업까지 모두가 고민하는 모노레포(Monorepo) 와 멀티레포(Multi-repo, 또는 Polyrepo) 의 대결입니다.
두 방식의 차이: 백과사전 vs 전문 서적
두 접근 방식의 차이는 도서관의 책을 관리하는 방법에 비유할 수 있습니다. 📚
- 모노레포 (Monorepo): "하나의 거대한 백과사전" 모든 프로젝트와 코드가 단 하나의 Git 저장소 안에 공존합니다. 프론트엔드 앱, 백엔드 API, 공용 디자인 시스템, 모바일 앱까지 모두 한곳에서 관리되죠. 마치 세상의 모든 지식이 담긴 거대한 백과사전 한 권과 같습니다.
- 멀티레포 (Multi-repo): "주제별로 나뉜 전문 서적" 가장 전통적이고 흔한 방식입니다. 각 프로젝트나 서비스가 자신만의 독립된 Git 저장소를 가집니다. frontend-app 저장소, backend-api 저장소, design-system 저장소가 각각 분리되어 있죠. 마치 도서관 서가에 프로그래밍, 역사, 과학 등 주제별로 전문 서적이 따로 꽂혀 있는 것과 같습니다.
모노레포(Monorepo)의 장단점
장점 (Pros) ✨
- 코드 가시성 및 재사용성: 모든 코드가 한곳에 있어 다른 팀의 코드를 쉽게 찾아보고 재사용하기 편리합니다. 공용 라이브러리나 컴포넌트를 만들고 공유하는 과정이 매우 간단해집니다.
- 원자적 커밋 (Atomic Commits): 프론트엔드와 백엔드에 걸친 큰 변경 사항을 단 하나의 커밋으로 관리할 수 있습니다. 예를 들어, API 명세를 바꾸고 그에 맞춰 프론트엔드 코드를 수정하는 작업을 하나의 단위로 묶을 수 있어 히스토리 추적이 명확해집니다.
- 간편한 의존성 관리: 외부 라이브러리 버전을 하나로 통일하기 쉬워 "의존성 지옥(Dependency Hell)"을 피하는 데 도움이 됩니다.
단점 (Cons) 🌪️
- 빌드/테스트 시간 증가: 코드가 조금만 변경되어도 전체 프로젝트에 대한 빌드 및 테스트가 트리거될 수 있어, CI/CD 파이프라인이 매우 느려질 수 있습니다. (물론 Lerna, Nx 같은 빌드 시스템으로 최적화할 수 있습니다.)
- 저장소 크기 문제: 수년에 걸친 커밋 히스토리가 쌓이면 Git 저장소 자체가 매우 무거워져 clone이나 pull에 오랜 시간이 걸릴 수 있습니다.
- 접근 제어의 어려움: 기본적으로 모든 개발자가 모든 코드에 접근할 수 있으므로, 특정 프로젝트에 대한 접근 권한을 세밀하게 제어하기가 까다롭습니다.
멀티레포(Multi-repo)의 장단점
장점 (Pros) ✅
- 명확한 소유권과 자율성: 각 저장소는 특정 팀이나 프로젝트에 의해 소유권이 명확히 구분됩니다. 팀은 다른 팀의 간섭 없이 자신들만의 개발, 빌드, 배포 주기를 자율적으로 가져갈 수 있습니다.
- 빠른 CI/CD: 각 저장소의 규모가 작기 때문에 빌드와 테스트가 매우 빠릅니다.
- 세분화된 접근 제어: 저장소별로 접근 권한을 부여하기 쉬워 코드 보안에 유리합니다.
단점 (Cons) 😵
- 코드 중복 및 발견의 어려움: 다른 팀에서 이미 만든 유용한 코드가 있는지 알기 어려워, 비슷한 코드를 중복해서 개발할 가능성이 높습니다.
- 복잡한 의존성 관리: 여러 프로젝트에 걸쳐있는 공용 라이브러리를 업데이트하려면, 해당 라이브러리를 사용하는 모든 저장소에 일일이 찾아가서 버전을 올리고 테스트하는 고된 작업을 해야 합니다.
- 프로젝트 간 연계 작업의 불편함: 모노레포의 '원자적 커밋'과 반대로, 여러 저장소에 걸친 변경 사항을 추적하고 관리하기가 매우 번거롭습니다.
마치며
모노레포와 멀티레포 중 어느 하나가 절대적으로 우월한 방식은 없습니다. 이는 팀의 규모, 프로젝트의 성격, 그리고 조직의 문화에 따라 결정되는 전략적 선택입니다.
- 멀티레포는 팀 간의 독립성과 자율성을 중시하는 소규모 팀이나 전통적인 마이크로서비스 조직에 적합합니다.
- 모노레포는 코드 공유와 협업을 극대화하고, 전사적인 표준을 유지하려는 구글, 메타와 같은 대규모 조직이나, 프론트엔드와 백엔드가 긴밀하게 연결된 프로젝트에 유리합니다.
"우리 코드를 어디에, 어떻게 담을 것인가?" 이 질문에 대한 고민은, 결국 "우리 팀이 어떻게 협업하고 성장할 것인가?" 라는 더 큰 질문과 맞닿아 있습니다. 🧐
반응형