“한 저장소에 다 넣자”와 “레포는 나누자” 사이에서 흔들리는 팀이 많다. 2026년 기준으로 Turborepo, Nx 같은 도구는 성숙했고, 반대로 GitHub/GitLab의 멀티레포 + 패키지 레지스트리 조합도 익숙해졌다. 중요한 것은 도구 이름이 아니라 우리 조직에 맞는 경계를 정하는 일이다.
이 글은 모노레포가 유리한 조건과 멀티레포가 유리한 조건을 나란히 놓고, Turborepo vs Nx를 고를 때의 실무 감각을 정리한 것이다.
모노레포가 이득인 경우
다음에 해당하면 한 저장소(모노레포) 쪽을 진지하게 검토할 만하다.
1. 공유 코드가 “계속” 바뀐다
- 공용 UI 컴포넌트, 공용 유틸, 프로토콜 버퍼·OpenAPI 스키마, 내부 SDK처럼 여러 앱이 같은 코드를 자주 끌어다 쓴다.
- 멀티레포에서 버전 맞추기·동시 PR이 반복되고, “어느 레포를 먼저 머지해야 하지?”가 일상이 된다.
→ 모노레포는 한 커밋으로 여러 패키지를 함께 올리기 쉽다. CI에서 영향 범위만 빌드·테스트하도록 묶는 것도 Turborepo/Nx가 잘하는 영역이다.
2. 배포 단위는 다르지만, 변경은 한 흐름으로 보고 싶다
- 예:
web,api,worker가 따로 배포되지만, 기능 하나를 낼 때 세 레포를 동시에 건드리는 경우가 많다.
→ 모노레포 + 태스크 그래프(의존 관계에 따른 빌드 순서)로 **“이번 배포에 포함된 변경”**을 한 저장소에서 추적하기 쉽다.
3. 팀이 여럿이지만, “같은 제품” 안에서 움직인다
- 조직이 커도 하나의 제품/플랫폼에 속한 팀들이면, 코드 경계를 패키지 경계로 나누는 편이 소유권을 명확히 하기 좋다. (디렉터리/패키지 단위 CODEOWNERS)
4. 표준화와 자동화를 한 번에 밀고 싶다
- ESLint/Prettier/tsconfig, CI 파이프라인, 버전 정책을 한 곳에서 강제하고 싶다.
→ Nx는 코드 생성·제약·모듈 경계 규칙에 강하고, Turborepo는 캐시·원격 캐시·파이프라인 단순화에 강한 편이다. 둘 다 “한 번 설정해 두고 팀 전체에 퍼뜨리기”에 유리하다.
멀티레포가 나은 경우
아래에 가깝다면 굳이 모노레포로 합치지 않는 편이 덜 아프다.
1. 팀·권한·릴리스가 완전히 분리된다
- 다른 회사에 넘길 코드, 오픈소스로만 공개할 코드, 규제/보안 때문에 저장소 접근을 나눠야 하는 코드가 섞인다.
→ 저장소 자체를 나누는 것이 접근 제어에 직관적이다.
2. 라이프사이클이 다르다
- 한쪽은 월 단위 릴리스, 다른 쪽은 하루에도 여러 번 배포. 또는 한쪽은 레거시 동결, 다른 쪽만 활발하다.
→ 한 저장소에 묶으면 브랜치 전략·태그·릴리스 노이즈가 커질 수 있다.
3. 저장소 크기·히스토리 부담이 크다
- 거대한 바이너리, 미디어, 실험 브랜치가 한곳에 쌓이면 clone 시간이 병목이 된다. (LFS·서브모듈 이슈까지 생긴다.)
→ 경계를 나누거나, 저장소 분리 + 패키지로만 소비가 나을 수 있다.
4. “공유”가 거의 없다
- 앱끼리 코드 공유가 거의 없고, API 문서만 맞추면 되는 수준이라면 멀티레포가 단순하다.
Turborepo vs Nx: 고를 때 보는 것
둘 다 모노레포를 잘 돕지만, 강점의 무게가 다르다.
| 관점 | Turborepo에 가깝다 | Nx에 가깝다 |
|---|---|---|
| 빌드 캐시·CI 속도 | 원격 캐시·태스크 캐시에 집중하기 쉬움 | 캐시 + 그래프 기반 실행이 강력 |
| 규모가 커질 때 규칙 | 가볍게 시작하기 좋음 | 모듈 경계·제약으로 구조 지키기 |
| 풀스택 모노레포 | JS/TS 중심 프로젝트에 흔함 | 플러그인으로 여러 스택 확장 |
| 학습 곡선 | 상대적으로 단순 | 기능이 많아 설정·개념이 많음 |
실무 팁:
- 이미 레포가 단순하고 “빌드만 빠르게”가 목표면 Turborepo부터.
- 여러 앱·라이브러리·도메인 규칙을 장기적으로 강제하려면 Nx를 더 깊게 본다.
도입 전에 팀이 합의해야 할 것
- 패키지 경계: 무엇을 앱, 무엇을 라이브러리로 둘지.
- 버전 정책: 내부 패키지를 항상 최신으로 맞출지, semver로 갈지.
- CI 정책: PR마다 무엇을 빌드할지(영향 분석).
- 소유권: 디렉터리/CODEOWNERS로 팀 매핑.
정리
- 공유 코드·동시 변경·한 제품 안의 여러 팀이면 모노레포가 유리한 경우가 많다.
- 접근 분리·완전히 다른 릴리스·공유 거의 없음이면 멀티레포가 단순하다.
- Turborepo와 Nx는 “빌드 파이프라인과 캐시” vs “구조 규칙과 확장” 쪽 무게를 보고 고르면 된다.
모노레포는 만능이 아니고, 멀티레포도 나쁜 것이 아니다. 팀의 경계와 배포 리듬에 맞추는 것이 2026년에도 가장 비싼 수업료를 줄이는 방법이다.