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 를 명시적으로 안 본 채로 모노레포를 시작하면 대부분 후회.
모노레포냐 폴리레포냐를 지금 결정 직전인 엔지니어링 리드라면, 5 변수 점수를 직접 매겨 보는 게 시작. 점수가 -2 ~ +4 의 분기점이면 현재 결정을 6개월 미루는 옵션도 검토 — 팀 수, 언어 수 같은 변수가 그 사이에 변할 수 있음.
비슷한 글
기획자가 코드를 배포하면, 장애는 누가 책임질까
AI로 제품 담당자가 직접 코드를 만들고 여러 에이전트가 동시에 작업하는 조직에서, 운영에 나가는 변경을 누가 무엇으로 확인해야 하는지. NIST SSDF, SLSA provenance, Google SRE 포스트모템 문화를 근거로 작성자와 분리된 검증·승인·복구의 역할 설계를 정리했다.
백재민
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백