"매 코드가 아닌 사람의 scaling 문제". 100+ engineer / 10+ team 이 한 codebase 를 깨지 않고 동시에 ship 하려면 boundary 가 필요. 2026 답: monorepo (Turborepo/Nx) + design system + module federation 또는 vertical slice + RFC process.
매 핵심
매 무엇이 scaling 을 막는가
Build time: cold build 30분 → 매 PR review cycle 죽음.
Coupling: import graph 가 mesh → 한 파일 바꾸면 매 rebuild.
Ownership 모호: bug fix 가 누구 책임 인지 모름.
Inconsistent UX: team 마다 다른 button / spacing.
Dependency drift: 매 package version 제각각.
매 architecture 패턴
Monorepo: 모든 app/lib 을 한 repo — atomic refactor 쉬움. Turborepo, Nx, Bazel.
Polyrepo: 매 team 별 repo — 독립 deploy. 매 versioning 부담.
Micro-frontend: runtime composition — 매 다른 stack/team 통합. Module Federation, single-spa.
Vertical slice: feature 별 폴더 (UI + state + api 함께) — feature team ownership.
// packages/api-contract/src/index.ts
exportconstapiSpec={'/products/:id':{method:'GET',response: ProductSchema},}asconst;// generated client used by all apps — 매 single source of truth.