모노레포와 멀티레포

김진효·2026년 6월 15일

[CS] 면접 대비

목록 보기

7/11

MonoRepo_MultiRepo

프로젝트를 새롭게 진행하면서 레포지토리 전략을 어떻게 해야할지 의견이 나왔다.
사실 그 이전까지는 한 서비스를 파트 별로 진행하고 흩어지면서 매번 모노레포로 진행했기에, 멀티레포를 취하지 않는 이유가 뭐냐라는 말에 대답을 할수 없었다 사실 개념조차 스쳐지나가듯이 들어봤다 크아악..
따라서 이번에 모노레포와 멀티레포가 무엇인지 제대로 알고, 다음번에는 당당하게 말하는 것을 목표로 하고자 한다 (ദ്ദി˙ᗜ˙)

모노레포 (Mono-repo)

여러 프로젝트를 하나의 Repository에서 관리하는 방식

➕ 장점

코드 재사용성 향상 및 설정 공유
- 공통 코드를 한 곳에서 관리하고 즉시 다른 프로젝트 적용 가능
의존성 관리 효율적
- 프로젝트 전체 의존성을 한번에 관리
- 모든 프로젝트가 동일한 버전의 라이브러리를 사용하고, 업데이트도 한 번에 적용
개발 환경 통일
- 통일된 테스트 환경과 컨벤션 적용 가능
리팩토링과 변경 관리 용이
- 여러 프로젝트에 걸친 변경사항도 단일 PR로 관리

➖ 단점

초기 개발 환경 구성이 까다로울 수도
- 여러 프로젝트의 의존성을 고려해 설계해야 하므로 초기 세팅이 쉽지 않을 수도 있음
저장소 크기가 커질수록 초기 클론 느림
CI/CD 파이프라인 설계가 복잡
- 모든 패키지가 하나의 레포에 묶이기 때문에, 초기 설정을 잘 하지 않으면 변경이 없는 서비스까지 빌드 범위에 포함될 수 있음
권한 분리가 상대적으로 복잡
- 특정 서비스만 담당하는 팀은 해당 코드만 접근하도록 하면서, 동시에 전체를 통합적으로 관리해야 하는 팀도 고려한 구조가 필요

☑️ 언제 사용하면 좋을까?

여러 프로젝트가 공통 컴포넌트나 비즈니스 로직을 공유하는 경우
팀 규모가 작고 전체 흐름을 한눈에 파악해야 하는 경우

멀티레포 (Multi-repo)

폴리레포(polyrepo) 라고도 불린다!
각 도메인 및 기능 단위로 Repository를 생성하여 독립적으로 운영하는 방식
보통은 서비스별로 레포지토리를 분리하여 독립적으로 관리한다

➕ 장점

서비스별 배포/권한 관리 쉬움
클론 및 빌드 속도 빠름
- 저장소 크기가 작기 때문에 상대적으로 클론이 빠르고, 해당 서비스만 빌드하면 되므로 CI 도 간편하고 유리
기술 스택 자유도 높음
- 서비스마다 다른 기술스택 자유롭게 가져갈 수 있음
팀이 커질수록 유리
- 팀마다 독립적인 개발 문화 및 컨벤션, 프로세스를 가져갈 수 있다

➖ 단점

코드 재사용 및 설정 공유 번거로움
- 공통으로 사용되는 코드를 각 저장소에 복사해서 사용해야한다
  
  예를 들어 API 타입이나 유틸 함수를 아래처럼 모든 저장소에 똑같이 붙여 넣어야 하고, 수정이 생기면 모든 저장소를 다 고쳐야 한다
```
// 공통 API 타입 정의
type ApiResponse<T> = {
  data: T;
  message: string;
  status: number;
}
```
  컴포넌트도 마찬가지
  한 곳만 수정하면 되는 게 아니라, 모든 저장소를 일일이 업데이트해야 함
```
 project1/src/components/Button.tsx
 project2/src/components/Button.tsx
 project3/src/components/Button.tsx
```
의존성 관리 복잡
- 저장소 수가 많아질수록 각각에 대한 관리가 필요해 복잡하며 추가적인 노력과 시간 필요
- 동일한 라이브러리 사용해도 버전이 달라질 수 있어 일관성 유지 어려움
개발 환경 불일치
- 저장소마다 린팅 규칙, 코드 스타일 등이 달라질 수 있음

☑️ 언제 사용하면 좋을까?

프로젝트들이 완전히 독립적일 경우
- 서로 다른 비즈니스 도메인이면서 공유할 코드도 거의 없는 경우
- 기술 스택이 완전히 다른 프로젝트일 경우
보안과 접근 권한 관리가 중요한 경우
- 저장소 단위로 접근 권한을 철저히 분리해야 할 때
서로 다른 빌드 및 배포 주기를 가진 프로젝트 관리시 유용
- 각 서비스마다 독립적인 CI/CD 파이프라인을 구성해야 하는 경우
팀 구조가 독립적일 경우
- 팀 각자의 방식대로 효율적으로 작업 가능

정리

🔥 예시를 들어보자

우리가 '뭐함파' 회사라고 하고, 배달 앱을 운영중이라고 하자
이 배달 앱에는 소비자가 주문하는 주문 서비스, 가맹점 사장님이 주문을 받는 사장님 서비스가 있다고 하면,
두 서비스는 다르지만, 회원 정보나 결제 조회 같이 비슷한 성격의 페이지나 타입이 존재할 수 있다.
예를 들어 주문 상태 값(주문접수 / 조리중 / 배달중 / 완료)이 정해져 있다고 했을 때 이걸 레포 2개로 나누어서 관리하면 타입 하나가 바뀔 때마다 각 레포에서 각각 수정해서 같은 값으로 맞춰야한다
이 작업을 한번만 해서 두 서비스에 동일하게 적용할 수도 있는데!
이런 문제에서 나온 고려로, 이전에는 멀티레포가 일반적이었지만, 현재는 모노레포 또한 많이 논의되고 쓰이고 있다

🤔 그렇다면 서비스 하나일 때도 멀티레포를 채택할까?

위에서는 여러 서비스를 운영할 때를 기준으로 비교했는데, 만약에 하나의 서비스만 있고 이를 파트나 기능 단위로 나누어서 작업하게 된다면 그때도 멀티레포를 쓰는 것을 고려할까? 고려한다면 어떤 이유에서 쓰일지도 궁금했다.

결론부터 말하면, 보통은 모노레포를 선택하는 경우가 많다
굳이 나눌 필요가 없는 경우가 많기 때문에

다만 배포 주기를 따로 가져가야 하거나, 보안/권한을 엄격히 분리해야 하거나, 기술 스택을 독립적으로 운영하는 상황이라면 멀티레포를 선택하기도 한다고 한다!

- 프론트엔드는 하루에 여러 번 배포하고 백엔드는 주 1회만 배포한다면, 한 레포로 묶여있을 때 프론트 코드를 살짝만 고쳐도 백엔드 빌드/테스트까지 같이 돌아가는 등 불필요한 CI가 함께 실행될 수도 (단 이것도 초기설정만 잘해두면 괜찮다)
- 프론트엔드는 오픈소스로 공개하고 백엔드는 비공개로 유지해야 한다면, 레포 자체를 나눠야 함
- 기능이나 파트별로 접근 권한을 엄격하게 나눠야 한다면, 레포 단위 분리가 더 명확

다만 여기서 짚고 넘어가야 할 부분이 있는데, fe/, be/, ai/ 이런 식으로 단순히 폴더로만 나눈다면 모노레포를 채택하는 가장 큰 이유인 '공통 부분 공유'를 위해서라고 보기는 어렵다

packages/shared 같은 워크스페이스 구조를 따로 설계하여 API 명세나 타입 공유 같은 게 이루어져야 모노레포가 빛을 발하기 때문이다

그럼에도 이슈와 PR을 한 곳에서 추적할 수 있고, 하나의 기능을 위한 여러 파트의 변경 사항을 연관 PR로 묶어서 리뷰할 수 있다는 점 등의 장점이 있다. 코드 레벨의 공유보다는 협업 흐름을 하나로 모아주는 느낌

정리

.git 저장소가 몇 개인지가 둘을 나누는 기준

	모노레포	멀티레포
팀 규모	소~중규모	중~대규모
서비스 결합도	높음 (공유 코드 많음)	낮음 (독립적)
권한 관리	상대적으로 복잡	용이
개발 환경	통일	자율
빌드/클론 속도	규모 커질수록 느려짐	상대적으로 빠름
핵심 가치	효율, 일관성	분리, 독립성