2026년 시점의 모노레포 결정 가이드 — 5가지 변수

모노레포 vs 폴리레포 논쟁은 *답이 없는* 게 아니라 *조건부 답이 있는* 문제. 5가지 변수가 결정을 가른다. 우리가 7 케이스에서 본 패턴.

백재민
백재민
CollabOps 창업자
2026년 시점의 모노레포 결정 가이드 — 5가지 변수

"모노레포가 좋다 / 폴리레포가 좋다" 는 답이 없는 논쟁 으로 보이지만, 그렇지 않다. 조건부 답 이 있다. 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개월 미루는 옵션도 검토 — 변수가 그 사이에 변할 수 있음.

태그#monorepo#polyrepo#infrastructure#devops#architecture