# [[Modular Monolith]]

## 📌 Brief Summary
모듈러 모놀리스(Modular Monolith)는 단일 배포 애플리케이션(모놀리스) 내부에 엄격한 경계를 가진 모듈을 결합하는 프론트엔드 아키텍처 접근법입니다 [1]. 마이크로 프론트엔드처럼 여러 개의 독립된 앱을 운영하는 대신, 하나의 React 셸(Shell) 앱을 유지하면서 주문이나 결제 같은 기능(Feature)별로 모듈을 분리합니다 [2]. 각 모듈은 고유한 UI, 상태 관리, 라우팅 및 API 계층을 독립적으로 소유하므로, 런타임 복잡성 없이도 명확한 관심사 분리와 기능 소유권을 제공합니다 [2, 3].

## 📖 Core Content
* **단일 셸 애플리케이션과 플러그인 구조:** 하나의 컨테이너 애플리케이션이 인증, 전역 라우팅, 레이아웃 등 핵심 공통 관심사만 처리합니다. 개별 기능은 이 셸 앱에 등록되는 모듈로서 작동하며, 각 모듈은 자체적인 내부 라우팅과 도메인 API 상호작용을 완전히 책임집니다 [3, 4].
* **수직적 슬라이스(Vertical Slice) 아키텍처 결합:** 각 모듈은 UI부터 데이터베이스 및 API 연결 계층까지 아우르는 수직적 슬라이스 형태로 구성됩니다. 이를 통해 각 도메인 기능 내의 응집도를 높이고 독립적인 개발을 가능하게 합니다 [1, 5].
* **엄격한 경계 및 의존성 관리:** 서로 다른 기능 모듈 간의 직접적인 교차 임포트(Cross-domain import)는 엄격히 금지됩니다 [1, 3]. 컴포넌트나 로직을 공유해야 할 경우, 모든 모듈이 소비할 수 있는 공통 패키지(예: core 또는 foundations 폴더)로 분리하여 관리해야 합니다 [3, 6].
* **도구와 모노레포(Monorepo) 활용:** 이러한 깨끗한 모듈 분리는 Turborepo, Nx, Vite 등과 같은 모노레포 구조 및 빌드 도구를 사용하여 구조적으로 강제할 수 있습니다 [2]. 특히 Nx 같은 도구를 활용하면 모듈 경계 규칙을 적용하여, 잘못된 교차 임포트 발생 시 이를 코드 리뷰 전에 빌드 타임 에러로 잡아낼 수 있습니다 [3].
* **마이크로 프론트엔드(Micro-frontends) 대비 이점:** 모듈러 모놀리스는 모듈 페더레이션(Module Federation), 중복된 React 인스턴스 로드, 분산된 E2E 테스트 및 배포 결합 등 마이크로 프론트엔드의 전형적인 오버헤드와 런타임 복잡성을 피하면서도 명확한 소유권 경계를 달성할 수 있게 해줍니다 [2, 7, 8].

## 🔗 Knowledge Connections
- **Related Topics:** [[Micro-frontends]], [[Vertical Slice Architecture]], [[Monorepo]], [[Feature-Sliced Design]]
- **Projects/Contexts:** [[Scalable React Architecture]], [[Turborepo/Nx Workspace]]
- **Contradictions/Notes:** 마이크로 프론트엔드 아키텍처는 가장 높은 수준의 결합도 분리(Decoupling)를 제공하지만 유지보수와 배포의 오버헤드가 매우 큰 반면, 모듈러 모놀리스는 완전한 독립성을 일부 포기하는 대신 단일 앱 환경에서 훨씬 적은 복잡성으로 유사한 확장성 및 격리 효과를 얻을 수 있다는 명확한 트레이드오프가 존재합니다 [2, 9].

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