[개념 정리] 모노레포 / 멀티레포

최종 수정 : 24.12.22

모노레포

모노레포(Monorepo)는 여러 프로젝트를 하나의 Git 저장소에서 관리하는 방식을 말한다. 이 방식이 등장한 배경에는 현대 웹 개발의 복잡성이 한몫했다. 예를 들어, 하나의 서비스를 만들 때 웹 프론트엔드, 모바일 앱, 관리자 대시보드, 백엔드 API 서버 등 여러 프로젝트가 필요한데, 이들이 서로 밀접하게 연관되어 있음에도 각각 다른 저장소에서 관리되면서 발생하는 여러 문제들을 해결하기 위해 등장했다.

 

전통적인 멀티레포(Multirepo) 방식의 문제점

멀티레포는 "Multiple Repository"의 줄임말로, 프로젝트나 서비스별로 각각 독립된 저장소를 만들어 관리하는 방식이다. 전통적으로 많이 사용되어 온 방식이며, 프로젝트 간의 명확한 경계를 두고 독립적으로 관리할 수 있다는 장점이 있다.

 

1. 코드 재사용&공유의 어려움

• 공통으로 사용되는 코드를 각 저장소에 복사해서 사용해야 함
• 한 곳에서 버그를 수정하면 다른 모든 저장소에도 같은 수정을 반복해야 함
• 공통 컴포넌트를 npm 패키지로 배포해야 하는 번거로움

 

2. 의존성 관리의 복잡성

• 각 프로젝트마다 별도의 package.json을 관리해야 함
• 동일한 라이브러리를 사용해도 버전이 다를 수 있어 일관성 유지가 어려움
• 한 라이브러리의 버전을 업데이트할 때 모든 프로젝트를 각각 수정해야 함

 

3. 개발 환경 불일치

• 프로젝트마다 다른 lint 규칙 사용
• 서로 다른 빌드 설정과 배포 프로세스
• 테스트 환경의 불일치로 인한 품질 관리의 어려움

 

4. 협업의 어려움

• 여러 프로젝트에 걸친 변경 사항을 한 번에 적용하기 어려움
• 프로젝트 간 의존성이 있는 경우 버전 관리가 복잡해짐
• 코드 리뷰가 여러 저장소에 분산되어 진행됨

 

모노레포의 구체적인 장점

1. 코드 공유와 재사용성 향상

• 공통 코드를 한 곳에서 관리하고 즉시 다른 프로젝트에서 사용 가능
• 버그 수정이 모든 프로젝트에 즉시 적용됨
• 컴포넌트와 유틸리티의 버전 관리가 용이

 

2. 의존성 관리 효율화

• 프로젝트 전체의 의존성을 중앙에서 관리
• 모든 프로젝트가 동일한 버전의 라이브러리 사용
• 의존성 업데이트가 한 번에 모든 프로젝트에 적용

 

3. 개발 환경 통일

• 모든 프로젝트가 동일한 lint 규칙 적용
• 일관된 빌드 프로세스와 배포 파이프라인
• 통일된 테스트 환경으로 품질 관리 용이

 

4. 리팩토링과 변경 관리 용이

• 전체 코드베이스에 대한 변경을 한 번에 적용 가능
• 프로젝트 간 의존성 있는 변경도 단일 PR로 관리
• 코드 변경의 영향도를 쉽게 파악 가능

 

5. 협업 효율성 증가

• 모든 코드를 한 곳에서 찾고 수정 가능
• 프로젝트 간 지식 공유가 쉬움
• 일관된 코딩 스타일과 패턴 유지 가능

 

특히 다음과 같은 상황에서 큰 효과를 발휘한다.

1. 여러 프로젝트가 공통 컴포넌트나 비즈니스 로직을 공유하는 경우

my-company/
  ├── packages/
  │   ├── design-system/    # 공통 UI 컴포넌트
  │   │   ├── Button/
  │   │   ├── Input/
  │   │   └── Modal/
  │   ├── web-service/      # 웹 서비스
  │   └── admin-dashboard/  # 관리자 페이지

• 컴포넌트 수정 시 모든 프로젝트에 즉시 반영 가능
• 버그 수정이나 기능 개선이 한 번에 모든 프로젝트에 적용
• 일관된 사용자 경험 유지 가능

2. 프론트엔드와 백엔드가 긴밀하게 연계되어 있는 경우

my-service/
├── packages/
│ ├── frontend/
│ │ └── src/
│ │ ├── types/ # 백엔드와 공유하는 타입 정의
│ │ └── api/ # API 통신 로직
│ ├── backend/
│ │ └── src/
│ │ ├── types/ # 프론트엔드와 공유하는 타입 정의
│ │ └── controllers/
│ └── shared/ # 공통 유틸리티와 상수

• API 변경 시 프론트엔드 코드도 함께 수정 가능
• 타입 정의를 공유하여 타입 안정성 확보
• 백엔드 변경이 프론트엔드에 미치는 영향을 즉시 확인 가능

3. 지속적인 리팩토링과 코드 개선이 필요한 경우

my-project/
  ├── packages/
  │   ├── legacy-app/      # 기존 애플리케이션
  │   ├── new-app/        # 새로운 버전
  │   └── shared/         # 공통 코드
  └── tools/
      └── migration/      # 마이그레이션 도구

• 점진적인 마이그레이션 용이
• 기존 코드와 새 코드의 동시 관리 가능
• 리팩토링의 영향도를 쉽게 파악 가능
• 전체 코드베이스에 대한 일관된 개선 적용

4. 팀 간 협업이 빈번한 경우

company-platform/
  ├── packages/
  │   ├── team-a/          # A팀 프로젝트
  │   ├── team-b/          # B팀 프로젝트
  │   └── shared/          # 공통 모듈
  ├── tools/               # 개발 도구
  └── docs/                # 공통 문서

• API 변경이 필요한 경우
  - 백엔드 팀이 API 변경
  - 프론트엔드 팀이 같은 PR에서 관련 변경 적용
  - 한 번의 리뷰로 전체 변경 사항 확인 가능
  
  
• 공통 컴포넌트 수정 시
  - 디자인 시스템 팀이 컴포넌트 수정
  - 다른 팀들이 즉시 변경사항 테스트 가능
  - 문제 발생 시 빠른 피드백과 수정 가능
  
  
• 크로스 팀 기능 개발
  - 여러 팀이 관련된 기능을 하나의 PR로 관리
  - 전체 기능의 진행 상황을 한눈에 파악
  - 통합테스트를 즉시 진행 가능

---

Q. 그렇다면, 멀티레포(Multirepo)를 사용할 이유가 없지 않을까?

아니다. 여전히 멀티레포가 효과적인 상황들이 존재한다.

 

1. 완전히 독립적인 프로젝트들

서로 다른 비즈니스 도메인을 가진 프로젝트들을 관리할 때 멀티레포는 효과적이다. 예를 들어, 회사의 메인 서비스와 내부 직원용 도구, 일회성 이벤트 페이지처럼 서로 관련이 없는 프로젝트들은 독립적으로 관리하는 것이 더 효율적이다. 또한 React로 만든 웹 서비스, Flutter로 개발한 모바일 앱, Python으로 작성된 데이터 분석 도구처럼 기술 스택이 완전히 다른 프로젝트들의 경우, 공유할 수 있는 코드나 설정이 거의 없기 때문에 분리해서 관리하는 것이 더 깔끔하다.

 

2. 보안과 접근 권한 관리가 중요한 경우

프로젝트별로 다른 보안 레벨이 필요한 상황에서 멀티레포는 큰 장점을 갖는다. 일반 고객용 서비스 코드, 중요한 금융 정보를 다루는 코드, 내부 관리자용 도구 코드처럼 접근 권한을 철저히 분리해야 하는 경우가 이에 해당한다. 또한 공개된 오픈소스 프로젝트와 회사의 비공개 핵심 코드, 특정 클라이언트를 위한 커스텀 코드처럼 외부 공개 여부에 따라 코드를 분리해야 할 때도 멀티레포가 적합하다.

 

3. 빌드와 배포의 단순화

서로 다른 배포 주기를 가진 프로젝트들을 관리할 때 멀티레포는 유용하다. 예를 들어 매일 여러 번 배포가 필요한 프로젝트, 월 1회 정기 배포하는 프로젝트, 분기별로 대규모 업데이트를 하는 프로젝트가 있다면, 각각의 배포 주기에 최적화된 독립적인 CI/CD 파이프라인을 구성할 수 있습니다. 또한 웹 서비스는 브라우저 최적화가 필요하고, 서버는 노드 버전별로 다른 빌드가 필요하며, 데스크톱 앱은 OS별로 다른 빌드 설정이 필요한 것처럼 빌드 요구사항이 크게 다른 경우에도 멀티레포가 효과적이다.

 

4. 팀 구조와 관리 측면

지리적으로 분산된 팀들이 각자의 프로젝트를 독립적으로 관리해야 할 때 멀티레포는 좋은 선택이라 말할 수 있다. 예를 들어 서울 오피스의 웹 개발팀, 부산 오피스의 모바일 개발팀, 해외 지사의 API 개발팀처럼 물리적으로 떨어져 있는 팀들이 각자의 방식대로 효율적으로 작업할 수있다. 또한 애자일 방식을 사용하는 팀, 워터폴 방식의 팀, 자체 개발 프로세스를 가진 팀처럼 서로 다른 개발 문화와 프로세를 가진 팀들이 독립적으로 일할 수 있는 장점도 있다.