architecture · medium priority
모노레포 (Turborepo / Nx)
대규모 프론트엔드 코드베이스 관리 전략
advanced 난이도3시간토스카카오네이버라인
시작 전
이해도
매우 낮음
학습 개요
탄생 배경
쉬운 설명
복잡한 개념을 실생활 비유로 설명합니다.
“아파트 단지”
모노레포는 여러 아파트가 하나의 단지에 있는 것입니다. 각 팀(앱)은 자기 집(패키지)을 독립적으로 쓰지만, 공용 수영장(공유 UI)·주차장(공유 유틸리티)은 함께 사용합니다. Turborepo는 단지 관리인으로, 바뀐 집만 청소(빌드)하고 나머지는 건너뜁니다.
핵심 개념
전형적인 모노레포 구조text
1my-monorepo/2├── apps/3│ ├── web/ # Next.js 앱4│ ├── admin/ # Admin 대시보드5│ └── docs/ # 문서 사이트6├── packages/7│ ├── ui/ # 공유 컴포넌트 라이브러리8│ ├── config/ # 공유 ESLint, tsconfig9│ ├── utils/ # 공유 유틸리티 함수10│ └── types/ # 공유 TypeScript 타입11├── package.json # 루트 workspace 설정12└── turbo.json # Turborepo 파이프라인
pnpm workspace 설정json
1// pnpm-workspace.yaml2packages:3 - "apps/*"4 - "packages/*"56// packages/ui/package.json7{8 "name": "@my-org/ui",9 "main": "./src/index.ts",10 "exports": {11 ".": "./src/index.ts"12 }13}1415// apps/web/package.json — 공유 패키지 참조16{17 "dependencies": {18 "@my-org/ui": "workspace:*",19 "@my-org/utils": "workspace:*"20 }21}
실무 적용
어떤 상황에서 사용하는가
디자인 시스템과 여러 서비스 앱이 있어서 공유 컴포넌트를 일관되게 관리해야 할 때
어떻게 적용하는가
pnpm workspaces로 기본 구조 설정 후 Turborepo로 빌드 파이프라인 최적화. 공유 패키지는 packages/ui, packages/utils, packages/config로 분리. 공유 ESLint/tsconfig는 extends로 상속. 토스의 toss/slash, Vercel의 Next.js가 Turborepo 기반 모노레포.
흔한 실수와 안티패턴
- 패키지 간 순환 의존성 — 아키텍처 설계 단계에서 방지
- 빌드 캐시 무효화 범위 설정 오류로 캐시 효과 없어짐
- 공유 패키지 변경이 모든 앱에 영향 — 인터페이스 변경 시 영향 범위 파악 필수
면접 질문
심화토스카카오네이버
답변 방향 힌트
팀 규모, 공유 코드 비율
반드시 언급할 키워드
- 트레이드오프
- 팀 규모
- 공유 코드량
예상 꼬리 질문
- Nx와 Turborepo의 차이는?
- 모노레포에서 특정 앱만 배포하는 방법은?