2nd/00_Raw/00_Processed/확장 가능한 프런트엔드를 위한 의존성 및 패키지 구조화.md

# [[확장 가능한 프런트엔드를 위한 의존성 및 패키지 구조화]]

## 📌 Brief Summary
확장 가능한 프런트엔드를 위한 의존성 및 패키지 구조화는 여러 애플리케이션과 공유 컴포넌트 간의 복잡한 의존성을 관리하고 유지보수성을 극대화하기 위한 아키텍처 접근법입니다. 최근에는 무질서하게 얽힌 코드를 방지하기 위해 단일 저장소 내에서 패키지 간의 명확한 경계와 공개 API를 강제하는 **모노레포(Monorepo)** 및 **모듈형 모놀리스(Modular Monolith)** 패턴이 주요하게 활용됩니다. 이를 통해 개발팀은 코드를 기능이나 도메인 단위로 분리하고 불필요한 결합을 줄이면서도, UI 라이브러리와 비즈니스 로직을 안전하게 재사용할 수 있습니다.

## 📖 Core Content
**1. 모노레포와 모듈형 모놀리스 아키텍처**
* 프런트엔드가 점점 독립된 SPA에서 여러 앱이 UI 원시 요소, 라우팅, API 클라이언트 등을 공유하는 "제품 플랫폼"으로 진화함에 따라, 패키지 간의 아토믹(atomic) 리팩토링을 지원하는 **모노레포(Monorepo) 구조가 필수적**으로 자리 잡았습니다 [1]. 모노레포는 단순히 여러 폴더를 모아둔 것이 아니라 **하나의 일관된 의존성 그래프를 강제하는 구조**입니다 [2].
* 분산된 마이크로 프런트엔드의 복잡성 없이 강력한 관심사 분리를 달성하기 위해, 단일 셸(Shell) 애플리케이션 내에 각 기능(도메인)이 고유한 UI, 상태 및 API를 소유하는 **모듈형 모놀리스(Modular Monolith)**나 **수직적 슬라이스(Vertical Slice)** 방식이 권장됩니다 [3-5]. 각 앱이나 기능은 고유한 책임 구역을 갖게 됩니다 [6].

**2. 엄격한 의존성 경계와 공개 API 관리**
* 대규모 프런트엔드 시스템에서 가장 위험한 것은 예측할 수 없는 강한 결합(Coupling)입니다. 패키지 내부 깊숙한 파일 경로를 직접 참조하는 **깊은 임포트(Deep imports)를 방지**해야 합니다 [7].
* 모든 재사용 가능한 패키지나 슬라이스는 진입점이 되는 명시적인 공개 API(`src/index.ts`)를 가져야 하며, `package.json`의 `exports` 필드나 ESLint, Nx 도구의 모듈 경계 규칙을 사용해 외부 접근을 제어해야 합니다 [7-10].
* 공유 패키지(예: `packages/ui` 또는 `packages/shared`)는 상위 레벨의 애플리케이션 코드나 특정 기능(Feature) 패키지를 절대 임포트해서는 안 되며, 의존성은 항상 한 방향으로만 흐르게 해야 합니다 [8, 11]. 프레임워크 관련 의존성(예: React)은 앱이 소유하고, 공유 패키지는 이를 peer dependency로 받는 것이 안전합니다 [12, 13].

**3. 대규모 의존성을 위한 최신 도구 생태계**
* **pnpm workspaces**: 로컬 패키지를 일등 시민(first-class citizens)으로 다루며, `workspace:*` 프로토콜을 사용해 내부 패키지 의존성을 엄격하게 관리하고 외부 레지스트리 패키지로 잘못 해석되는 것을 방지합니다 [14]. 
* **Turborepo 및 Nx**: 코드가 변경된 패키지만 판별하여 영향받는(affected) 작업만 실행하고 원격 캐싱을 적용하는 빌드 오케스트레이션 도구들입니다 [8, 15-17]. 이는 다수 패키지가 존재하는 모노레포 환경에서 CI/CD 빌드 시간을 획기적으로 줄여줍니다 [8, 18, 19].

**4. 기능 분할 설계 (Feature-Sliced Design, FSD)**
* 모노레포를 통해 패키지 간의 공유를 해결하더라도, 각 앱과 패키지 내부의 아키텍처가 무너지면 확장성을 잃게 됩니다. FSD는 코드를 **Shared, Entities, Features, Widgets, Pages, App**이라는 엄격한 계층 구조로 나누어 종속성의 방향을 통제합니다 [20, 21].
* Atomic Design이 UI 컴포넌트 시스템 구축에 강력한 언어를 제공한다면, FSD는 그 컴포넌트들을 비즈니스 로직 및 도메인 모델과 어떻게 결합하고 저장소 구조에 배치할지를 규정하여, 거대한 "전역 공유 폴더"가 무분별하게 팽창하는 것을 막아줍니다 [20-22].

## 🔗 Knowledge Connections
- **Related Topics:** [[Monorepo Architecture]], [[Modular Monolith]], [[Vertical Slice Architecture]], [[Feature-Sliced Design (FSD)]], [[Deep Imports Prevention]]
- **Projects/Contexts:** [[pnpm workspaces]], [[Turborepo]], [[Nx Workspaces]], [[React Component Library Architecture]]
- **Contradictions/Notes:** 소스 14의 논의에 따르면, 개발자들은 런타임 오버헤드와 복잡성이 큰 완전한 마이크로 프런트엔드(Micro-frontend) 환경보다, 빌드 도구와 모노레포 워크스페이스를 활용해 물리적 경계를 나누는 모듈형 모놀리스 아키텍처를 선호하는 경향을 보입니다 [3, 5, 23, 24].

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