33 lines
4.9 KiB
Markdown
33 lines
4.9 KiB
Markdown
---
|
|
category: Architecture
|
|
tags: [auto-wikified, technical-documentation, architecture]
|
|
title: Modular Architecture
|
|
description: "모듈러 아키텍처(Modular Architecture)는 시스템을 기능이나 도메인 단위의 독립적이고 응집력 있는 모듈로 분할하는 소프트웨어 설계 방식입니다 [1, 2]."
|
|
last_updated: 2026-05-04
|
|
---
|
|
|
|
# Modular Architecture
|
|
|
|
## 📌 Brief Summary
|
|
모듈러 아키텍처(Modular Architecture)는 시스템을 기능이나 도메인 단위의 독립적이고 응집력 있는 모듈로 분할하는 소프트웨어 설계 방식입니다 [1, 2]. NestJS나 Vue 3와 같은 현대적 프레임워크에서 이 패턴은 명확한 경계 설정을 통해 애플리케이션의 유지보수성과 확장성을 극대화합니다 [2-4]. 이를 통해 다수의 개발자가 협업하는 대규모 환경에서도 기술 부채를 줄이고 예측 가능한 코드베이스를 유지할 수 있습니다 [3, 5].
|
|
|
|
## 📖 Core Content
|
|
* **기능 기반(Feature-based) 모듈 구성**: NestJS 환경에서는 기술적 계층(Layered)이 아닌 기능(Feature)을 기준으로 모듈을 구성하는 것이 권장됩니다 [2]. 각 기능은 자체 폴더 내에 컨트롤러, 서비스, DTO, 엔티티 등을 모두 포함하는 하나의 모듈로 구현되어야 합니다 [2]. 이는 기능의 이동이나 삭제를 단일 폴더 조작으로 가능하게 하여 코드의 탐색과 관리를 매우 용이하게 만듭니다 [2].
|
|
* **모듈의 역할별 분리 전략 (NestJS)**:
|
|
* **Feature Module**: 다른 모듈에서 주입받아야 할 요소만 명시적으로 내보내며(export), 하나의 기능당 하나의 모듈을 설계하여 캡슐화를 유지합니다 [6].
|
|
* **Shared Module**: 여러 기능에서 공통으로 사용하는 필터, 인터셉터, 파이프 등의 횡단 관심사(Cross-cutting concerns)를 위해 사용되며, `@Global()` 데코레이터를 통해 재임포트 없이 전역적으로 제공될 수 있습니다 [6].
|
|
* **Core Module**: 데이터베이스 연결이나 로거 설정 등 애플리케이션 시작 시 단 한 번만 초기화되어야 하는 요소들을 분리하여 담당합니다 [6].
|
|
* **Lazy Modules**: 거대한 애플리케이션이나 서버리스 콜드 스타트 성능 향상을 위해 특정 모듈을 지연 로딩(Lazy loading)할 수 있도록 설계합니다 [6].
|
|
* **프론트엔드의 논리적 모듈화 (Vue 3)**: Vue 3의 Composition API는 데이터나 메서드 등의 기술적 옵션이 아닌 논리적 기능 단위로 코드를 그룹화하는 모듈화된 구조를 제공합니다 [4, 7]. 비즈니스 로직을 'Composables'라는 재사용 가능한 함수로 추출하여 캡슐화함으로써, 각 컴포넌트가 독립된 상태를 유지하고 코드베이스를 모듈식으로 깔끔하게 관리할 수 있게 합니다 [8-11].
|
|
* **도메인 지향 구조 (Domain-Oriented Structure)**: 대규모 프론트엔드 애플리케이션에서는 단순히 기술적 유형(예: 모든 버튼을 한 폴더에 모으는 식)으로 구성하는 것을 넘어, 결제(billing)나 사용자(user)와 같은 특정 도메인 모듈 단위로 구조를 나누는 하이브리드 접근 방식이 아키텍처 병목 현상을 막아줍니다 [12].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
* **학습 곡선과 보일러플레이트 증가**: NestJS와 같이 모듈식 아키텍처를 강제하는 프레임워크는 Express와 같은 미니멀한 도구에 비해 초기 설정 시 더 많은 보일러플레이트 코드(Boilerplate code)를 요구하며 학습 곡선이 상대적으로 가파릅니다 [3].
|
|
* **소규모 프로젝트에서의 오버엔지니어링**: 2~5명 규모의 소규모 팀이나 단순한 프로젝트에서는 모듈, 프로바이더, DTO 등을 촘촘히 설정하는 구조적 비용이 실제 비즈니스 가치보다 클 수 있으며, 결국 기능 구현보다 프레임워크 설정에 더 많은 시간을 쏟게 될 위험이 있습니다 [13].
|
|
* **잘못된 모듈 패턴의 부작용**:
|
|
* `@Global()` 데코레이터를 남용하면 모듈 시스템이 본래 해결하고자 했던 "모든 것이 어디서나 접근 가능한" 혼란스러운 상태를 다시 초래하게 되므로 제한적으로 사용해야 합니다 [6].
|
|
* 하나의 코어 앱에 모든 것을 담는 "메가 앱(Mega-Apps)" 패턴이나, 단일 모듈이 수십 개의 기능 모듈을 무분별하게 임포트하는 구조는 모듈 분리의 목적을 퇴색시키므로 도메인에 따라 적절히 분할해야 합니다 [14, 15].
|
|
* **순환 참조 (Circular Dependencies) 문제**: 모듈 간의 의존성이 잘못 설계되면 순환 참조 오류가 발생할 수 있습니다. 이때 `forwardRef()`와 같은 임시방편으로 경고를 회피하기보다는, 모듈 구조 자체를 근본적으로 수정하여 의존성을 바로잡는 것이 올바른 해결책입니다 [15].
|
|
|
|
---
|
|
*Last updated: 2026-05-03* |