2026년 시점의 모노레포 결정 가이드 — 5가지 변수
모노레포 vs 폴리레포 논쟁은 *답이 없는* 게 아니라 *조건부 답이 있는* 문제. 5가지 변수가 결정을 가른다. 우리가 7 케이스에서 본 패턴.
"모노레포가 좋다 / 폴리레포가 좋다" 는 답이 없는 논쟁 으로 보이지만, 그렇지 않다. 조건부 답 이 있다. 5가지 변수가 결정을 가른다.
이 글은 7 고객사·자체 프로젝트에서 본 패턴의 정리.
변수 1 — 팀 수
1~3 팀: 모노레포가 거의 항상 답
4~10 팀: 분기점 — 다른 변수가 결정
11+ 팀: 폴리레포가 거의 항상 답 (단, Google/Meta 처럼 *고도로 투자된 모노레포 도구* 가 있으면 예외)이 변수만으로 50% 의 결정이 끝난다. 작은 팀이 폴리레포를 쓰면 통합 비용 이 모듈 격리 가치 보다 항상 크다.
변수 2 — 빌드 인프라 투자 가능성
모노레포의 치명적 약점 은 빌드 시간 이다. 코드베이스가 커지면 작은 변경에 전체 빌드 가 트리거된다. 이걸 풀려면 증분 빌드 + 캐시 + 분산 빌드 인프라가 필요.
Bazel / Buck / Nx / Turborepo 같은 도구가 있지만, 도입·유지에 전담 1~2명 의 시간이 필요하다. 이 투자가 불가능 하면 모노레포의 처음 6개월 은 좋고 그 이후 는 빌드 시간이 지수 증가.
변수 3 — 언어 다양성
1~2 언어: 모노레포 OK
3~5 언어: 분기점 — 빌드 도구가 다 지원하는지 확인
6+ 언어: 폴리레포 권장 (각 언어가 자기 ecosystem)언어가 늘면 공통 빌드 도구 의 적합성이 떨어진다. Rust + Go + Python + TypeScript 까지는 Bazel 이 OK, 그 이상 가면 비용 급등.
변수 4 — 배포 단위의 분리도
서비스가 함께 배포 되는가, 각자 배포 되는가?
함께 배포 = 모노레포 자연스러움. 각자 배포 = 폴리레포가 자연스러움. 섞여 있는 경우 — 일부는 함께, 일부는 따로 — 가장 어려움. 이게 해체 가능한 모노레포 또는 조정된 폴리레포 의 영역.
변수 5 — 외부 협업 계획
repo 가 외부 기여 (오픈소스, 파트너 기업) 를 받을 계획이면, 그 부분만 폴리레포로 떼는 게 정답. 모노레포 안에 내부 코드와 오픈소스 코드가 섞이면 라이선스·기여·릴리스 정책이 지옥 이 된다.
5 변수의 결합 — 결정 매트릭스
변수 | 모노 우세 점수
───────────────┼──────────────
팀 1~3개 | +3
팀 4~10개 | 0
팀 11+개 | -3
빌드 투자 가능 | +2
빌드 투자 불가 | -3
언어 1~2종 | +2
언어 3~5종 | 0
언어 6+종 | -2
함께 배포 | +2
각자 배포 | -2
섞임 | 0
외부 협업 X | +1
외부 협업 O | -1총점:
- +5 이상 → 모노레포
- -2 부터 +4 → 분기점, 다른 조직 문화 변수가 결정
- -3 이하 → 폴리레포
7 사례 점수
케이스 | 점수 | 결정 | 결과 (1~2년 후)
──────┼─────┼─────────┼────────────────
A | +8 | 모노 | 만족
B | +6 | 모노 | 만족
C | +3 | 모노 | 1년 후 일부 분리 시작
D | +1 | 폴리 | 만족
E | -2 | 모노 | *후회* (빌드 시간)
F | -4 | 폴리 | 만족
G | -6 | 폴리 | 만족E 케이스가 흥미롭다. 팀 6개 + 빌드 투자 불가 + 언어 4종 + 섞임 + 외부 협업 X 였는데, 처음에 모노레포 결정. 1년 후 빌드 시간이 15분 → 47분 으로 늘어 반-폴리레포 마이그레이션 시작. 처음에 매트릭스를 봤다면 폴리레포 시작이 더 쌌다.
가장 자주 잘못되는 결정
위 변수 중 빌드 투자 가능 을 모든 사람이 과대평가 한다. "우리가 잘 짜면 Bazel 도입 어렵지 않다" 라는 가정. 실제로는 전담 시간 이 최소 1명 6개월 이고, 그 시간을 제품에서 빼야 한다. 이 trade-off 를 명시적으로 안 본 채로 모노레포를 시작하면 대부분 후회.
누가 이 글을 읽으면 좋은가
지금 새 repo 를 만들지 vs 기존 repo 를 합칠지 결정 직전의 엔지니어링 리드. 5 변수 점수를 직접 매겨 보기. 점수가 -2 ~ +4 의 분기점이면, 현재 결정을 6개월 미루는 옵션도 검토 — 변수가 그 사이에 변할 수 있음.
비슷한 글
에이전틱 DevOps 12개월 후 — 첫 가설 중 무엇이 *맞았고* 무엇이 *틀렸나*
12개월 전 다음 10년의 DevOps는 에이전틱이다 의 가설들. 12개월의 데이터로 어느 가설이 맞고 어느 게 틀렸는지의 정직한 평가.
백재민
3 pillars 그 후 — 4 추가 신호의 *6개월 후* 운영 노트
3 pillars 가 더 이상 충분하지 않은 이유 발행 후 6개월. 4 추가 신호 (events / user journeys / deploy correlation / similarity) 가 운영에서 어떻게 작동했는지의 후속.
백재민
GitHub Actions vs 자체 호스팅 — *진짜 비용* 비교 (12개월 데이터)
GitHub Actions 가 *비싸 보임* 은 표면. 12개월 자체 호스팅 vs SaaS 비교 — 단순 *분당 비용* 이 아니라 *총 운영 비용* 으로.
백재민