# 모노레포 vs 폴리레포: 팀에 맞는 선택 가이드

URL: https://formula.dog/ko/journal/monorepo-vs-polyrepo-ko
Type: blog
Locale: ko
Published: 2026-08-29
Updated: 2026-09-02

---

> 엔지니어링 팀의 규모와 코드 결합도에 따라 모노레포와 폴리레포 중 올바른 선택을 하는 방법을 배웁니다. 대규모 기업들의 사례와 현대적 빌드 도구를 활용한 실용 가이드.

## 모노레포 vs 폴리레포: 팀 규모별 선택 가이드

엔지니어링 팀이 성장하는 속도가 빌드 타임보다 빠를 때마다 모노레포 vs 폴리레포 논쟁이 떠올라요. 간단한 답변: 팀들이 정기적으로 코드를 공유하고 공통 기반에서 변경사항을 조율할 필요가 있으면 모노레포가 이기고, 팀들이 진정으로 독립적이어서 서로 기다릴 필요 없이 배포한다면 폴리레포가 맞습니다. 그 중간은 모두 실제로 서비스가 얼마나 강하게 결합되어 있는지, 그리고 어느 정도의 조율 오버헤드를 감수할 의사가 있는지에 달렸습니다. 이 글은 실제 트레이드오프, 각각을 가리키는 신호들, 그리고 의사결정을 위한 실용적인 프레임워크를 다룹니다.

## 정말 중요한 건 저장소 개수가 아니라 결합도입니다

대부분의 모노레포 vs 폴리레포 논쟁은 잘못된 질문에서 시작해요. 저장소 개수는 문제가 아닙니다. 문제는 팀들이 함께 움직여야 하는가입니다.

팀 A의 변경사항이 같은 릴리스 사이클에서 팀 B가 뭔가를 업데이트하게 만든다면, 여러분은 강한 결합 작업을 하고 있는 거예요. 그런 경우 한 개의 저장소가 거의 항상 더 깔끔합니다. 팀 A와 팀 B가 자신들의 일정에 배포하고, 다른 부분에 손을 댈 때 서로 기다릴 필요가 없다면 저장소를 나누는 게 정말 타당합니다.

최악의 시나리오: 여전히 함께 배포해야 하는 코드를 두 개의 저장소로 나누는 거예요. 모노레포의 조율 비용을 모두 떠안으면서 장점은 하나도 얻지 못합니다. 팀들은 레포 A와 레포 B에서 동시에 PR을 열게 되고, 둘 다 CI를 통과하기를 바라요. 폴리레포를 일찍 선택한 후 서비스들이 예상보다 더 서로 의존하게 된 조직에서 이 패턴이 의외로 많이 나타나요.

첫 번째 단계는 간단한 의존성 맵을 그리는 거예요. 여러분이 소유한 모든 서비스나 패키지를 나열하고, 하나가 다른 하나에 의존하는 곳에 화살표를 그으세요. 화살표들이 밀집한 클러스터를 형성한다면, 그 클러스터는 한 개의 저장소 안에 속합니다.

![소프트웨어 개발 팀이 화이트보드 주변에 모여 코드 아키텍처 다이어그램을 검토하는 모습](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/be767c-img-1-inline.webp)

## Google, Meta, Microsoft도 대규모에서 모노레포를 선택한 이유

Google은 대부분의 코드를 80TB가 넘는 데이터와 20억 줄 이상의 코드로 추정되는 단일 저장소에 보관하고 있습니다. Meta와 Microsoft도 핵심 제품 기반에 대해 같은 방식을 사용해요. 이건 큰 회사들이 복잡성을 좋아해서가 아니라, 대규모에서는 수백 개의 저장소에 걸쳐 의존성을 동기화하는 것이 풀타임 엔지니어링 문제가 되기 때문입니다.

공유 라이브러리의 API 변경 하나가 40개의 다른 저장소에 걸쳐 조율된 업데이트를 필요로 할 수 있어요. 모노레포에서는 그것이 하나의 PR입니다. 한 번의 검토. 한 번의 병합. 뭔가 잘못되면 한 번의 롤백.

Sourcegraph가 발행한 연구에 따르면, 현재 50명 이상의 개발자를 둔 기업의 63%가 코드베이스의 적어도 일부에 대해 모노레포를 사용하고 있으며, 이는 3년 전 수치에서 급격히 증가했습니다.

정말 중요한 구체적 이점: 원자적 커밋입니다. API의 breaking 변경사항이 프론트엔드와 백엔드 업데이트를 함께 요구할 때, 모노레포는 세 변경사항을 모두 한 PR에 반영하고, 함께 테스트하고, 뭔가 잘못되면 세 가지를 모두 한 번에 롤백할 수 있게 해요. 폴리레포에서는 세 개의 PR을 따로 열고, 세 번의 검토 사이클을 기다리고, 서비스들이 버전이 맞지 않은 상태로 실행 중인 윈도우를 관리해야 합니다.

한 엔지니어링 팀은 프론트엔드 패키지를 Nx 모노레포로 마이그레이션한 후 가끔씩의 배포에서 주당 40회 이상의 앱 릴리스로 이동했습니다. 이전에 몇 개월이 걸렸던 Angular 업그레이드는 팀이 다른 작업을 멈추지 않고 처리할 수 있는 루틴 작업이 되었습니다.

## 폴리레포의 숨겨진 조율 비용

폴리레포는 진지하게 생각해볼 가치가 있는 실제 이점들이 있습니다. 각 팀은 자신의 CI/CD 파이프라인, 자신의 릴리스 사이클, 자신의 접근 제어를 제어합니다. 보안과 컴플라이언스 팀은 보통 이를 선호해요: 코드 접근은 저장소별로 명명된 인원으로 제한될 수 있어서, 규제된 산업에서 중요합니다. 오픈소스 구성요소는 내부 코드를 드러내지 않으면서 자신의 공개 저장소에 더 깔끔하게 살 수 있어요.

진정으로 독립적인 팀의 경우, 이 이점들은 실제입니다. 자신의 일정에 실행되고 공유 코드를 전혀 건드리지 않는 데이터 파이프라인을 소유한 작은 서비스 팀은 더 큰 모노레포 안에 앉아 있을 이유가 거의 없습니다.

하지만 폴리레포 조직은 조용히 비용을 축적하는데, 이것들은 원래 결정에서 나타나지 않았어요. 저장소 간 의존성 버전 관리는 자체적인 분야가 됩니다. 공유 유틸리티 라이브러리는 어떤 저장소에서는 오래되고 다른 저장소에서는 최신 상태로 유지됩니다. 어떤 버전의 어떤 라이브러리가 어떤 버전의 어떤 서비스와 맞는지 알기 위해서는 누군가 호환성 매트릭스를 유지해야 해요.

알아둘 만한 한 가지 측정값: 모노레포의 중간 PR 사이클 시간은 약 19시간인 반면, 폴리레포에서는 약 2시간입니다. 모노레포의 PR은 더 많은 표면을 건드리기 때문에 검토가 느려지는 경향이 있어요. 하지만 폴리레포 변경사항이 한 가지 기능을 착지시키기 위해 세 개의 저장소에 걸쳐 세 개의 조율된 PR을 필요로 할 때, 집계된 사이클 시간은 종종 모노레포 수치를 초과해요 - 부분적 병합이 서비스를 불일치 상태로 남겨놓을 추가 위험과 함께.

팀들이 놀라는 패턴: "독립성을 위해 별도 저장소를 시작했는데, 이제 모든 릴리스는 네 곳에서 PR을 열어야 해요." 그 시점에 여러분은 둘 다의 최악을 가지고 있는 거예요.

## 2024년에 빌드 시간은 더 이상 결정 요인이 아닙니다

모노레포에 대한 전형적인 반대는 빌드 시간이었어요. 저장소에 200개의 패키지가 있고 한 파일을 변경하면, 정말 모든 200개를 다시 빌드하고 싶으세요?

이 주장은 2022년에서 2024년 어딘가에서, 스택에 따라 만료되었습니다.

현대적 빌드 도구는 콘텐츠 인식 캐싱을 사용해요. 오직 변경된 것만 다시 빌드하고, 입력이 동일한 모든 것은 건너뜁니다. `payments` 패키지로의 변경은 `design-system`의 아무것도 변경되지 않았다면 `design-system`의 재빌드를 트리거하지 않습니다. GitHub Actions는 유료 원격 캐시 솔루션이 필요하기 전에 10GB의 무료 캐시 저장소를 제공해요.

Turborepo는 약 20개 패키지까지 대부분의 JavaScript와 TypeScript 팀을 잘 처리합니다. 구성은 단일 `turbo.json`, 원격 캐싱은 Vercel에서 무료로 작동하거나 자체 호스팅되고, 학습 곡선이 낮아서 팀은 하루 내에 생산성이 있을 수 있어요.

20개 패키지를 넘거나 빌드가 여러 언어에 걸쳐 있을 때, Nx의 더 구조화된 접근은 더 큰 학습 곡선을 정당화하는 경향이 있어요. Nx는 코드 생성, 자동 CI 분산, 그리고 저장소가 커지면서 점점 더 가치 있는 세밀한 의존성 추적을 추가합니다.

수천 개의 패키지를 여러 언어에 걸쳐 실행 중인 매우 큰 조직의 경우, Bazel(Google의 오픈소스 빌드 시스템)은 그 규모를 위해 설계된 유일한 도구입니다. 설정 비용은 상당하고 거의 항상 전담 플랫폼 엔지니어링 팀을 필요로 해요.

![중앙 코드베이스에서 흘러나오는 여러 병렬 배포 파이프라인, 추상적 DevOps 인프라 개념](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/6761f6-img-2-inline.webp)

## 팀의 선택을 정하는 네 가지 질문

일반적인 정답은 없지만, 신뢰할 수 있는 프레임워크가 있어요.

**1. 팀들이 자주 변경되는 코드를 공유하나요?**
그렇다면 - 공유 디자인 시스템, 공유 API 클라이언트 라이브러리, 공유 인증 로직 - 모노레포가 거의 항상 더 나은 선택입니다. 공유 라이브러리를 여러 저장소에 걸쳐 동기화 상태로 유지하려면 끊임없는 규율이 필요하고 거의 항상 드리프트합니다.

**2. 팀들이 독립적으로 배포하나요?**
팀 A의 서비스는 화요일에, 팀 B의 서비스는 목요일에 아무 조율 없이 배포된다면 폴리레포는 제 자리를 얻습니다. 한 서비스를 릴리스하는 데 다른 서비스의 동시 릴리스가 필요하다면, 그 결합 비용은 식에 포함되어야 해요.

**3. 이 코드베이스를 건드리는 엔지니어가 몇 명인가요?**
20명 이하면 저장소 구조는 생각할 것보다 덜 중요합니다. 50명 이상이면 폴리레포의 조율 비용이 눈에 띄게 축적되기 시작합니다. 200명 이상이면, 팀이 제품과 기술별로 정말 고립되지 않은 한 모노레포의 사례가 매우 강해져요.

**4. 팀별로 코드를 격리하는 보안이나 컴플라이언스 요구사항이 있나요?**
규제된 산업에서 - 금융, 의료, 일부 정부 환경 - 코드 접근은 명명된 인원에게로 제한될 필요가 있을 수 있어요. 그 제약이 다른 답변을 무효화할 수 있습니다. 단단한 코드 격리가 컴플라이언스 요구사항이라면 폴리레포는 선택이 아니라 제약입니다.

질문 1에 "예"라고 하고 질문 4에 "아니오"라고 답했다면, 모노레포가 거의 확실히 옳은 결정입니다. 질문 1에 "아니오"라고 하고 질문 2에 "예"라고 답했다면, 폴리레포는 방어할 수 있는 선택입니다. 그 외 모든 것은 판단 근거입니다.

## 대부분의 성장 중인 팀이 실제로 착지하는 곳

성숙한 엔지니어링 조직 중 극단의 한쪽에서 운영되는 곳은 거의 드물어요. 가장 자주 나타나는 패턴: 핵심 제품(프론트엔드, 공유 라이브러리, 서로 의존하는 백엔드 서비스)을 위한 모노레포, 그리고 진정으로 독립적인 구성요소를 위한 별도 저장소.

자신의 일정에 실행되고 주 제품과 코드를 공유하지 않는 데이터 파이프라인은 모노레포 밖에 속합니다. 한 명의 팀원이 유지하는 내부 도구는 밖에 속해요. 공개 가시성이 필요한 오픈소스 라이브러리는 밖에 속합니다.

이건 타협이 아닙니다. 깔끔한 이진 답변을 거의 가지지 않는 질문에 대한 올바른 답변입니다. 함께 움직여야 하는 것들을 함께 두세요. 진정으로 독립적인 것들을 분리하세요.

중요한 것은 의도적으로 결정하는 거예요, 기본값이 아니라. 폴리레포 확산으로 끝나는 대부분의 팀은 선택한 게 아니라, 한 서비스로 시작한 후 또 다른, 또 다른 한 다음 멈추는 것을 질문한 적이 없어요.

## 어느 접근이든 실제로 작동하게 하는 도구

**모노레포:**

- 
Nx: 가장 강한 기능 세트, 다국어 빌드와 20개 패키지를 넘는 팀에 좋습니다. 학습 곡선이 더 크지만 더 멀리 확장됩니다.

- 
Turborepo: 시작하기 더 간단하고, 20개 패키지 미만의 JS/TS 팀에 탁월합니다. Vercel 네이티브 캐싱 또는 자체 호스팅 옵션.

- 
Bazel: 엔터프라이즈 규모의 매우 큰 다국어 저장소용. 상당한 설정 투자 필요.

**폴리레포:**

- 
공유 라이브러리에 대한 버전 관리 규율은 선택이 아닙니다. 의미론적 버전 관리와 일관된 체인지로그 프로세스가 없으면 의존성 드리프트가 6개월 내에 표준이 됩니다.

- 
공유 의존성이 변경될 때 저장소 간 파이프라인을 트리거하는 CI/CD 도구입니다. GitHub Actions는 저장소 간 `workflow_dispatch` 및 `repository_dispatch` 이벤트를 통해 이를 지원해요.

- 
공유 패키지 분산을 관리하기 위한 의존성 레지스트리(npm 비공개 레지스트리, GitHub Packages, Artifactory).

Biscuit이 설정 파일을 가져올 수 있어요. 어느 것을 사용할지의 결정은 여전히 그 네 가지 질문에 달려 있습니다.

![어두운 홈 오피스에서 풀 리퀘스트를 검토하는 이중 모니터 설정에서 개발자가 일하고 있는 모습](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/accorata/2026-09/47a076-img-3-inline.webp)

## FAQ

### 모노레포가 항상 더 좋은가요?

아닙니다. 모노레포는 팀이 정기적으로 코드를 공유하고 동시 배포가 필요할 때 유리합니다. 팀이 완전히 독립적이고 별도의 릴리스 사이클을 가진다면 폴리레포가 더 나을 수 있습니다.

### 모노레포의 빌드 시간 문제는 어떻게 해결하나요?

Turborepo와 Nx 같은 현대적 빌드 도구는 콘텐츠 인식 캐싱을 사용합니다. 변경된 것만 다시 빌드하고 나머지는 건너뜁니다. 이것이 2024년 기준 빌드 시간을 더 이상 결정 요인이 아니게 만들었습니다.

### 팀 규모가 의사결정에 어떤 영향을 미칠까요?

20명 이하의 팀은 저장소 구조가 덜 중요합니다. 50명 이상이면 폴리레포의 조율 비용이 눈에 띄게 증가합니다. 200명 이상이면 팀이 완전히 독립적이지 않은 한 모노레포가 강력하게 권장됩니다.

### 규제된 산업에서는 어떻게 해야 할까요?

금융, 의료 같은 규제된 산업에서 코드 접근을 명명된 인원으로 제한해야 한다면 폴리레포가 더 적합합니다. 이 경우 팀 독립성보다 규정 준수가 우선입니다.

### 작은 팀도 모노레포로 시작해야 할까요?

20명 이하의 작은 팀에게는 저장소 구조가 큰 문제가 아닙니다. 그러나 팀이 정기적으로 코드를 공유한다면 모노레포가 여전히 편할 수 있습니다. 팀의 특정 요구사항에 따라 결정하세요.