"매 single repo, many projects — 매 build graph 의 일관성". 매 monorepo 의 핵심은 모든 코드를 하나의 VCS root 안에 두되, 매 build 시스템이 dependency graph 를 이해해서 affected projects 만 build/test 한다는 점. Google (Piper/Bazel), Meta (Buck2), Microsoft (Rush), 그리고 매 OSS 의 Nx/Turborepo 가 이 패러다임을 driving.
매 핵심
매 Monorepo 가치
Atomic cross-project changes: 매 API + caller 의 한 PR 안에서 변경.
Shared tooling: 매 lint, format, build, test 의 unified config.
Visibility: 매 모든 코드 의 grep-able.
Refactor confidence: 매 type-checker 가 모든 caller 를 검증.
매 도전 과제
Build time scaling: 매 naive build 의 N² growth — affected detection 필수.
VCS performance: 매 git 의 100GB+ repo 에서 sparse checkout / VFS 필요.
Permissions: 매 single repo + multiple teams = CODEOWNERS / branch protection.
CI cost: 매 모든 commit 의 모든 project rebuild 의 X — incremental + cache.
언제: refactoring across packages, generating new lib boilerplate (Nx generator), CODEOWNERS automation, dependency graph 분석.
언제 X: 매 build cache invalidation logic 의 직접 결정 — Nx/Bazel hash algorithm 신뢰.
❌ 안티패턴
Single CI job for entire repo: 매 affected detection 없이 매 commit 모든 build — 30분+ pipeline.
No remote cache: 매 each developer 가 cold rebuild — wasteful.
Mixing app-specific and lib code: 매 libs/ 와 apps/ 의 분리 안 함 — circular deps risk.
Implicit dependencies: 매 package.json 에 list 안 된 import — Bazel/Nx 가 catch.