2nd/00_Raw/Turborepo 및 Nx 빌드 시스템.md

# [[Turborepo 및 Nx 빌드 시스템]]

## 📌 Brief Summary
Turborepo와 Nx는 현대적인 프론트엔드 모노레포 아키텍처를 지원하는 강력한 작업 오케스트레이션 및 빌드 시스템입니다 [1, 2]. 이들은 패키지 간의 복잡한 의존성 그래프를 파악하고 모듈 간의 엄격한 경계를 강제하여 프론트엔드 코드베이스의 복잡성을 통제합니다 [2, 3]. 결과적으로 변경된 코드에 영향을 받는 영역만 효율적으로 다시 빌드하고 테스트하게 해 대규모 컴포넌트 라이브러리와 확장 가능한 프론트엔드 환경의 CI/CD 속도를 극대화합니다 [4, 5].

## 📖 Core Content
* **Turborepo의 특징 및 최적화**: 
  Turborepo는 가벼운 작업 오케스트레이터가 필요한 팀에게 적합한 도구입니다 [6]. 패키지 간 병렬 실행, 의존성에 기반한 직관적인 파이프라인 구성, 그리고 빌드 산출물을 재사용하는 로컬 및 원격 캐싱을 제공하여 로컬 개발과 CI/CD 속도를 비약적으로 향상시킵니다 [4, 6]. **CI 속도 개선과 점진적 빌드(incremental builds)에 특화**되어 있습니다 [6, 7].

* **Nx의 플랫폼 및 아키텍처 제어**: 
  Nx는 풍부한 프로젝트 그래프(project graph)를 중심으로 설계된 포괄적인 모노레포 플랫폼입니다 [8]. 새로운 앱이나 라이브러리를 위한 스캐폴딩 생성기(generators), 플러그인 생태계, 그리고 아키텍처 정책 강제 기능을 기본적으로 지원합니다 [8, 9]. 특히 PR(Pull Request)에서 변경 사항과 연관된 **'영향받는(affected)' 프로젝트만 선별하여 빌드, 테스트, 린트(lint)를 수행**하며, 모듈 경계 규칙(module boundary rules)을 적용해 도메인 간 잘못된 임포트를 빌드 타임 오류로 차단할 수 있습니다 [5, 10].

* **컴포넌트 라이브러리 및 확장성(Scalability) 확보**: 
  여러 React 애플리케이션이 공통 UI 원시 요소(primitives)나 디자인 시스템, API 클라이언트를 공유할 때 이러한 빌드 도구는 필수적입니다 [3, 11]. 이 도구들은 단순한 코드 공유를 넘어 컴포넌트 간 **명시적인 공개 API(Public API)와 의존성 방향을 강제**하여 코드가 얽히는 현상(spaghetti sharing)을 방지합니다 [1, 12]. 

* **프로젝트 환경에 따른 선택 기준**: 
  빌드가 중복 실행되어 CI 속도가 느린 것이 주요 문제라면 가벼운 파이프라인과 훌륭한 캐싱 기능을 제공하는 Turborepo가 좋은 선택이 될 수 있습니다 [7]. 반면, 다수의 팀이 참여하여 **강력한 워크플로우 통제, 아키텍처 가드레일, 그리고 그래프 기반의 의존성 관리**가 필요한 '제품 플랫폼' 환경이라면 Nx가 더 적합합니다 [7, 8].

## 🔗 Knowledge Connections
- **Related Topics:** [[Monorepo Architecture]], [[Scalable Frontend]], [[Component Library Architecture]]
- **Projects/Contexts:** [[공유 UI 컴포넌트 및 디자인 시스템의 다중 앱 배포 환경]], [[Feature-Sliced Design (FSD) 기반 프론트엔드 모듈화]]
- **Contradictions/Notes:** 소스에 따르면 두 빌드 시스템은 접근 방식에 차이가 있습니다. Turborepo는 심플한 캐싱과 파이프라인에 집중하여 정책 강제 및 스캐폴딩 기능은 개발자가 직접 구성("bring your own")해야 하지만, Nx는 강력한 경계 도구와 생성기를 내장하고 있어 활용도가 높은 대신 학습해야 할 개념이 더 많습니다 [9].

---
*Last updated: 2026-04-26*