Angular 및 모듈 시스템

NgModule은 Angular 애플리케이션을 구성하는 기본적인 빌딩 블록이다. 이는 관련된 구성 요소, 지시자, 파이프, 서비스 등을 하나의 응집된 기능 단위로 묶는 컨테이너 역할을 한다. 모든 Angular 애플리케이션은 최소한 하나의 루트 모듈(AppModule)을 가지며, 이 모듈이 애플리케이션의 진입점이 된다. NgModule은 TypeScript 클래스에 @NgModule() 데코레이터를 적용하여 정의하며, 이 데코레이터는 모듈의 동작 방식을 결정하는 메타데이터 객체를 받는다.

NgModule의 구조는 주로 메타데이터 객체의 속성들로 정의된다. 주요 속성으로는 declarations, imports, providers, bootstrap 등이 있다. declarations 배열에는 해당 모듈에 속한 컴포넌트, 디렉티브, 파이프를 등록한다. imports 배열에는 이 모듈이 정상적으로 동작하기 위해 필요한 다른 모듈(예: Angular의 기본 BrowserModule이나 기능 모듈, 서드파티 라이브러리 모듈)을 나열한다. providers 배열에는 모듈 전체에서 사용 가능하게 할 서비스나 의존성 주입 토큰을 등록하며, bootstrap 속성은 루트 모듈에서만 사용되어 애플리케이션을 시작할 최상위 컴포넌트를 지정한다.

이러한 구조는 애플리케이션을 논리적 단위로 분리하는 데 핵심적이다. 모듈은 자신이 declarations에 등록한 구성 요소들을 캡슐화하여, 다른 모듈에서 선언적으로 사용하려면 명시적으로 exports 배열을 통해 내보내야 한다. 예를 들어, SharedModule은 공용 버튼이나 입력 필드 컴포넌트를 declarations에 추가하고, 이를 다른 모듈에서 사용할 수 있도록 exports 배열에도 동일하게 추가한다. 이는 코드의 명확한 경계를 만들고 재사용성을 높인다.

NgModule 데코레이터에 전달되는 메타데이터 객체는 애플리케이션의 컴파일러와 실행기에게 모듈의 구성 방식을 알려준다. 주요 속성으로는 declarations, imports, providers, exports, bootstrap 등이 있다.

declarations 배열은 해당 모듈에 속한 컴포넌트, 디렉티브, 파이프를 등록한다. 모든 사용자 정의 요소는 정확히 하나의 모듈에 선언되어야 한다. imports 배열은 현재 모듈이 기능을 사용하기 위해 의존하는 다른 모듈을 나열한다. 예를 들어 라우터 기능을 사용하려면 RouterModule을, 양방향 데이터 바인딩을 사용하려면 FormsModule을 임포트해야 한다. providers 배열은 해당 모듈의 의존성 주입기에 등록될 서비스 프로바이더를 정의하며, 이 모듈 내에서 생성된 컴포넌트들이 주입받을 수 있는 서비스의 범위를 결정한다.

exports 배열은 이 모듈의 공개 API를 정의한다. 여기에 선언된 컴포넌트, 디렉티브, 파이프, 또는 다른 모듈은 이 모듈을 임포트하는 다른 모듈에서 사용할 수 있다. 마지막으로, bootstrap 속성은 주로 루트 모듈에서 사용되며, 애플리케이션을 시작할 때 최초로 로드할 루트 컴포넌트를 지정한다.

이러한 메타데이터 속성들을 조합하여 모듈의 캡슐화와 재사용성을 관리하며, 애플리케이션의 구조를 명확하게 정의한다.

루트 모듈은 애플리케이션의 진입점을 정의하는 최상위 모듈이다. 이 모듈은 @NgModule 데코레이터로 장식되며, 일반적으로 AppModule이라는 이름을 가진다. 루트 모듈의 주요 역할은 애플리케이션을 부트스트랩하는 것이며, bootstrap 속성에 최상위 컴포넌트를 지정한다. 또한 애플리케이션 전반에서 필요한 서비스의 프로바이더를 등록하거나, 다른 기능 모듈들을 임포트하는 작업을 수행한다.

기능 모듈은 특정 기능이나 도메인 영역을 캡슐화한 모듈이다. 예를 들어, 사용자 인증을 담당하는 AuthModule, 상품 관리를 담당하는 ProductModule 등이 있다. 기능 모듈은 관련된 컴포넌트, 디렉티브, 파이프, 서비스를 하나의 단위로 묶어 응집도를 높이고, 다른 모듈과의 결합도를 낮춘다. 이는 코드의 조직화와 재사용성을 크게 향상시킨다.

루트 모듈과 기능 모듈의 관계는 다음과 같이 구성된다.

기능 모듈은 루트 모듈의 imports 배열에 추가되어 통합된다. 이 설계는 애플리케이션을 논리적인 블록으로 나누어 개발과 테스트를 용이하게 하며, 대규모 팀에서의 협업을 효율적으로 만든다. 또한, 지연 로딩을 통해 특정 기능 모듈을 필요할 때만 로드할 수 있는 기반을 제공한다.

공유 모듈은 애플리케이션 전반에서 재사용 가능한 구성 요소, 지시자, 파이프 등을 하나의 모듈로 묶어 제공하는 데 사용된다. 이 모듈은 주로 SharedModule 또는 CommonModule과 같은 이름으로 생성되며, 다른 기능 모듈들이 필요로 하는 공통 자원을 내보낸다. 공유 모듈은 일반적으로 Angular의 CommonModule, FormsModule, ReactiveFormsModule 등을 임포트하고, 자체적으로 생성한 재사용 가능한 UI 컴포넌트들을 익스포트한다. 이를 통해 여러 모듈에서 동일한 컴포넌트를 반복적으로 선언하지 않고도 사용할 수 있어 코드 중복을 방지하고 일관성을 유지한다.

코어 모듈은 애플리케이션에서 단일 인스턴스로 존재해야 하는 서비스, 가드, 인터셉터 등 싱글턴 서비스를 제공하는 데 특화되어 있다. 이 모듈은 주로 CoreModule으로 명명되며, 애플리케이션의 루트 모듈에 한 번만 임포트된다. 코어 모듈의 주요 목적은 의존성 주입 시스템에 전역적으로 필요한 프로바이더를 등록하는 것이다. 예를 들어, 인증 서비스, 로깅 서비스, HTTP 인터셉터 등은 코어 모듈에 선언하여 애플리케이션 전역에서 일관된 인스턴스를 사용하도록 한다. 이는 서비스 인스턴스의 중복 생성을 방지하고 상태 관리를 효율적으로 만든다.

두 모듈의 설계와 사용 패턴은 다음과 같이 구분된다.

이러한 분리는 애플리케이션의 구조를 명확하게 하고, 관심사를 분리하여 유지보수성을 높이는 데 기여한다. 공유 모듈은 UI 레이어의 재사용성을 담당하고, 코어 모듈은 애플리케이션의 핵심 비즈니스 로직과 인프라를 담당하는 패턴으로 정립되었다.

지연 로딩 모듈은 애플리케이션의 초기 번들 크기를 줄이고, 사용자가 특정 기능이나 경로에 처음 접근할 때만 해당 코드를 불러오는 방식이다. 이는 특히 대규모 단일 페이지 애플리케이션에서 초기 로딩 시간을 단축하고 성능을 향상시키는 핵심 기법이다. Angular 라우터는 loadChildren 속성을 통해 모듈을 비동기적으로 로드하는 구문을 지원한다.

지연 로딩을 구현하려면, 먼저 독립적인 기능 모듈을 생성하고 해당 모듈의 라우팅 구성을 정의해야 한다. 이후 루트 라우팅 모듈에서는 path와 loadChildren을 조합하여, 해당 경로로 이동 시 어떤 모듈을 로드할지 지정한다. 일반적으로 아래와 같은 형식을 사용한다.

```typescript

// app-routing.module.ts (루트 라우팅 설정)

{

path: 'dashboard',

loadChildren: () => import('./dashboard/dashboard.module').then(m => m.DashboardModule)

}

```

이 방식의 주요 이점은 초기 다운로드해야 하는 자바스크립트 파일의 크기가 감소한다는 점이다. 애플리케이션 시작 시에는 루트 모듈과 즉시 필요한 모듈만 로드되고, 사용자가 'dashboard' 경로로 이동하면 비로소 DashboardModule과 그 관련 컴포넌트, 서비스 코드가 별도의 청크(chunk) 파일로 다운로드되어 실행된다. 이는 애플리케이션을 기능 단위로 분할하여 관리하는 데도 유리하다.

지연 로딩 모듈은 자체적인 의존성 컨텍스트를 가진다. 즉, 지연 로딩된 모듈에 선언된 프로바이더는 해당 모듈 범위 내에서만 사용 가능하다. 이는 서비스의 인스턴스 범위를 제어할 수 있는 장점이 될 수 있지만, 루트 인젝터에 제공된 서비스와는 별개의 인스턴스가 생성될 수 있음을 의미하기도 한다. 따라서 서비스의 제공 범위를 신중하게 설계해야 한다.

Angular의 모듈 시스템은 애플리케이션 코드를 논리적 단위로 체계적으로 구성하는 데 핵심적인 역할을 한다. NgModule을 기준으로 컴포넌트, 디렉티브, 파이프, 서비스 등을 그룹화함으로써, 관련 기능을 하나의 응집된 블록으로 관리할 수 있다. 이는 특히 대규모 프로젝트에서 여러 개발자가 협업할 때 코드베이스의 구조를 명확히 정의하고, 특정 기능 영역을 담당하는 모듈을 독립적으로 개발 및 테스트할 수 있게 한다.

모듈화된 구조는 유지보수성을 크게 향상시킨다. 기능별로 분리된 모듈은 자체적인 네임스페이스를 제공하여, 컴포넌트나 서비스의 이름 충돌 가능성을 줄인다. 또한, 특정 기능을 수정하거나 제거해야 할 때 해당 변경의 영향 범위가 주로 하나의 모듈 내부로 국한되기 때문에, 변경 관리와 리팩토링이 훨씬 수월해진다. 예를 들어, '사용자 관리'와 '주문 처리'를 별도의 모듈로 분리하면, 주문 로직을 변경하는 작업이 사용자 인증 로직에 예기치 않게 영향을 미치는 위험을 최소화할 수 있다.

코드 재사용성 측면에서도 모듈 시스템은 이점을 제공한다. 공통적으로 사용되는 UI 컴포넌트나 유틸리티 서비스 등을 공유 모듈로 추출하면, 애플리케이션의 여러 부분에서 일관되게 재사용할 수 있다. 이는 DRY 원칙을 준수하고 코드 중복을 방지하여, 전체적인 코드 품질과 일관성을 높인다. 아래 표는 모듈화된 구성이 코드 관리에 미치는 긍정적 영향을 요약한다.

결론적으로, Angular의 모듈 시스템은 코드를 조직화하고 캡슐화하는 강력한 수단으로, 프로젝트의 규모가 커질수록 그 가치가 더욱 빛난다. 이는 장기적인 관점에서 애플리케이션의 확장성과 유지보수 비용을 관리하는 데 필수적인 기반을 마련해 준다.

Angular의 모듈 시스템은 애플리케이션의 초기 로딩 속도와 런타임 성능을 개선하는 데 핵심적인 역할을 한다. 핵심 전략은 지연 로딩이다. 애플리케이션을 여러 기능 모듈로 분리하고, 특정 라우트에 진입할 때만 해당 모듈의 코드를 비동기적으로 로드하면 초기 번들 크기를 크게 줄일 수 있다. 이는 사용자가 처음 방문할 때 불필요한 코드를 다운로드하지 않게 함으로써 첫 화면 렌더링 시간을 단축시킨다. 반면, 애플리케이션 시작에 필수적인 핵심 기능은 루트 모듈에 포함시켜 즉시 로드한다.

번들 크기 관리의 또 다른 중요한 도구는 트리 셰이킹이다. Angular의 AOT 컴파일과 함께 모듈 시스템은 사용되지 않는 코드를 최종 번들에서 제거하는 데 기여한다. 특히, 공유 모듈을 통해 컴포넌트나 서비스를 내보낼 때는 필요한 요소만 선택적으로 내보내는 것이 중요하다. 불필요하게 많은 요소를 하나의 모듈에 묶으면 트리 셰이킹이 제대로 작동하지 않아 번들 크기가 불필요하게 증가할 수 있다.

성능 최적화를 위한 모듈 설계 시 고려할 사항은 다음과 같다.

모듈 경계를 명확히 정의하면 코드 스플리팅이 효과적으로 이루어진다. 이는 큰 단일 번들을 여러 작은 청크로 나누어, 사용자가 실제로 필요한 코드만 점진적으로 로드하도록 한다. 결과적으로 네트워크 대역폭 사용이 줄어들고, 특히 모바일 환경이나 느린 네트워크에서 사용자 경험이 개선된다.

의존성 주입은 Angular 애플리케이션에서 클래스가 필요한 의존 객체를 외부(주로 NgModule)로부터 받아 사용하는 디자인 패턴이다. 이 패턴의 핵심 구성 요소는 프로바이더이다. 프로바이더는 의존성 주입 시스템에 특정 토큰(일반적으로 클래스 타입)에 대한 인스턴스를 생성하고 제공하는 방법을 알려주는 레시피 역할을 한다. 프로바이더는 주로 @NgModule 데코레이터의 providers 배열이나 @Component 데코레이터의 providers 배열에 등록된다.

프로바이더는 여러 가지 방식으로 구성할 수 있다. 가장 일반적인 형태는 클래스 자체를 프로바이더 토큰으로 사용하는 것이다. 예를 들어, providers: [UserService]라고 선언하면, UserService 타입의 의존성을 요청할 때 Angular가 UserService 클래스의 새 인스턴스를 생성하여 주입한다. 또한 useClass, useValue, useFactory, useExisting과 같은 프로바이더 정의 객체를 사용하여 더 세밀한 제어가 가능하다. useValue는 고정된 값을, useFactory는 팩토리 함수를 통해 인스턴스를 생성하며, useExisting은 이미 존재하는 다른 토큰에 대한 별칭을 만드는 데 사용된다.

모듈의 계층 구조에 따라 프로바이더의 가시성과 수명 주기가 결정된다. 루트 모듈(AppModule)의 providers에 등록된 서비스는 애플리케이션 전역에서 단일 인스턴스(싱글톤)로 사용 가능하다. 반면, 특정 기능 모듈이나 컴포넌트의 providers에 등록하면, 해당 모듈이나 컴포넌트 및 그 자식 컴포넌트 범위로 제한된 별도의 인스턴스가 생성된다. 이는 의존성 주입 컨테이너의 계층적 특성 때문이다. 따라서 서비스의 공유 범위와 수명을 효과적으로 관리하려면 프로바이더를 등록하는 위치에 대한 신중한 설계가 필요하다.

NgModule은 imports와 exports 배열을 통해 다른 모듈과의 관계를 정의합니다. imports 배열은 현재 모듈이 의존하는 다른 모듈들을 선언하는 곳입니다. 여기에 추가된 모듈에 포함된 컴포넌트, 디렉티브, 파이프 및 서비스 프로바이더를 현재 모듈의 템플릿에서 사용할 수 있습니다. 예를 들어, 폼 관련 기능이 필요하면 FormsModule을, HTTP 통신이 필요하면 HttpClientModule을 imports 배열에 추가합니다.

반대로 exports 배열은 현재 모듈이 외부에 공개하는 선언 가능 클래스(컴포넌트, 디렉티브, 파이프)를 지정합니다. exports를 통해 공개된 요소만이 이 모듈을 임포트한 다른 모듈의 템플릿에서 사용할 수 있습니다. 이는 모듈의 캡슐화를 가능하게 하는 핵심 메커니즘입니다. 공유 모듈은 일반적으로 재사용 가능한 UI 구성 요소나 기능을 exports 배열에 넣어 다른 기능 모듈들이 임포트하여 사용할 수 있도록 합니다.

임포트와 익스포트의 관계는 아래 표를 통해 명확히 이해할 수 있습니다.

이러한 구조는 모듈 간의 명확한 계약을 형성합니다. 모듈 A가 모듈 B를 imports하고, 모듈 B가 특정 컴포넌트를 exports했을 때만 모듈 A는 그 컴포넌트를 사용할 수 있습니다. 서비스 프로바이더는 이 규칙의 예외이며, 모듈에 제공된 프로바이더는 일반적으로 애플리케이션 전역에 등록됩니다[3]. 올바른 임포트와 익스포트 설정은 의존성 주입 컨테이너의 구성을 돕고, 번들 크기를 최적화하며, 애플리케이션의 구조를 체계적으로 유지하는 데 기여합니다.

대규모 Angular 애플리케이션에서는 코드의 구조화와 관리를 위해 모듈을 체계적으로 구성하는 것이 필수적이다. 일반적으로 애플리케이션은 하나의 루트 모듈과 다수의 기능 모듈로 구성된다. 루트 모듈은 애플리케이션의 진입점을 담당하며, 핵심 라이브러리와 브라우저 모듈을 임포트한다. 이후 비즈니스 로직은 도메인별로 구분된 기능 모듈로 분리하여 개발한다. 예를 들어, 사용자 관리, 주문 처리, 리포트 생성과 같은 독립적인 기능 영역 각각을 별도의 모듈로 만드는 방식이다.

모듈 설계 시에는 코어 모듈과 공유 모듈 패턴을 활용하여 관심사를 분리한다. 코어 모듈은 애플리케이션 전반에서 단일 인스턴스로 존재해야 하는 서비스(예: 인증 서비스, 로깅 서비스)나 애플리케이션 시작 시 한 번만 로드되는 컴포넌트(예: 네비게이션 바, 푸터)를 포함한다. 이 모듈은 루트 모듈에서만 임포트하여 싱글톤 패턴을 보장한다. 반면, 공유 모듈은 여러 기능 모듈에서 공통으로 사용하는 파이프, 디렉티브, 컴포넌트, UI 위젯 등을 선언하고 익스포트한다. 이를 통해 UI 구성 요소의 일관성과 재사용성을 높일 수 있다.

성능 최적화를 위해 라우팅 경로를 기준으로 지연 로딩 모듈을 적극적으로 도입한다. 사용자가 특정 기능(예: 관리자 대시보드)을 방문할 때만 해당 모듈의 코드를 다운로드하도록 구성하면 초기 번들 크기를 크게 줄일 수 있다. 대규모 애플리케이션의 모듈 구성은 아래와 같은 계층 구조를 가질 수 있다.

이러한 구조화는 팀 기반 개발을 용이하게 한다. 각 기능 모듈은 독립적인 팀이 담당하여 병렬 개발을 진행할 수 있으며, 모듈 간의 명확한 경계는 의존성을 관리하고 결합도를 낮추는 데 도움을 준다. 최종적으로 모듈 시스템은 대규모 애플리케이션의 복잡성을 통제 가능한 단위로 분해하여 확장성과 유지보수성을 보장하는 핵심 설계 도구 역할을 한다.

Angular 모듈은 단일 애플리케이션 내부뿐만 아니라, 여러 프로젝트에서 재사용 가능한 라이브러리를 구성하는 핵심 단위이다. 재사용 가능한 기능 집합(예: 공통 UI 컴포넌트, HTTP 인터셉터, 인증 서비스, 유효성 검사 파이프 등)을 하나의 NgModule으로 묶어 독립적인 패키지로 배포할 수 있다. 이렇게 생성된 라이브러리 모듈은 다른 애플리케이션의 imports 배열에 추가함으로써 즉시 기능을 통합할 수 있다. 라이브러리 개발 시에는 모듈의 공개 API를 신중하게 설계해야 하며, 내부적으로만 사용되는 컴포넌트나 서비스는 모듈 메타데이터의 exports 배열에 포함시키지 않아 캡슐화를 유지한다.

라이브러리 개발을 위한 표준 워크플로우는 Angular CLI의 ng generate library 명령어를 사용하는 것이다. 이 명령어는 라이브러리 프로젝트를 위한 별도의 작업 공간과 구성을 생성하며, 주로 projects 폴더 하위에 라이브러리 코드가 위치한다. 라이브러리 모듈은 일반 애플리케이션 모듈과 동일한 구조를 가지지만, 의존성을 최소화하고 버전 호환성을 고려하여 설계하는 것이 중요하다. 배포는 npm 레지스트리를 통해 이루어지며, 패키지의 package.json 파일에 peerDependencies를 명시하여 호스트 애플리케이션이 특정 Angular 버전을 제공하도록 요구할 수 있다.

모듈 재사용의 효과를 극대화하기 위한 설계 패턴으로는 Barrel 파일(인덱스 파일)을 활용하는 방법이 있다. 라이브러리의 최상위 디렉토리에 index.ts 파일을 생성하고, 공개하려는 모듈, 컴포넌트, 서비스, 상수 등을 다시 내보내면 사용자는 단일 임포트 경로로 모든 공개 기능에 접근할 수 있어 편의성이 크게 향상된다.

NgModule은 애플리케이션을 논리적 단위로 구성하는 강력한 도구이지만, 규모가 커지거나 복잡해질수록 몇 가지 문제점을 드러낸다. 가장 큰 문제는 설정의 복잡성이다. 개발자는 declarations, imports, exports, providers 등 여러 메타데이터 속성을 정확히 이해하고 구성해야 한다. 특히 의존성 주입을 위한 providers의 스코프(모듈 내에서만 제공되는지, 루트로 제공되는지)는 초보자에게 혼란을 줄 수 있는 영역이다. 이로 인해 설정 오류가 발생하거나, 의도치 않게 서비스 인스턴스가 중복 생성되는 등의 문제가 생길 수 있다.

또 다른 문제는 모듈 간의 명시적 의존성 관리 부담이다. 새로운 컴포넌트나 파이프를 사용하려면 반드시 해당 모듈의 declarations 배열에 추가하고, 다른 모듈에서 사용하려면 exports를 통해 내보낸 후 사용 측 모듈에서 다시 imports해야 한다. 이 과정은 작은 규모에서는 관리 가능하지만, 구성 요소가 많아지고 모듈이 세분화될수록 상당한 보일러플레이트 코드와 관리 오버헤드를 유발한다. 특히 재사용 가능한 UI 라이브러리를 개발할 때, 모든 구성 요소를 하나의 모듈로 묶어 내보내는 작업이 번거로울 수 있다.

이러한 복잡성은 학습 곡선을 가파르게 만들고, 애플리케이션의 초기 구성 비용을 증가시킨다. 또한, 모듈이 애플리케이션의 기본 구성 단위가 되면서, 때로는 단일 컴포넌트만을 위한 빈 모듈을 생성해야 하는 상황이 발생하기도 한다. 이는 필수적이지 않은 추상화 계층을 추가하여 코드베이스를 불필요하게 복잡하게 만드는 원인이 된다. 이러한 한계점들은 보다 간결한 대안인 Standalone Components 개념이 등장하는 배경이 되었다.

Angular의 전통적인 NgModule 시스템은 애플리케이션을 모듈 단위로 구성하는 강력한 방식을 제공했지만, 복잡한 설정과 상대적으로 높은 진입 장벽을 요구했다. 이에 대한 대응으로 Angular 버전 14부터 도입된 Standalone Components는 컴포넌트, 디렉티브, 파이프를 독립적인 단위로 만들 수 있는 새로운 패러다임을 제시한다. Standalone 컴포넌트는 @Component 데코레이터 내에 standalone: true를 설정함으로써 별도의 NgModule에 선언하지 않고도 직접 임포트하고 사용할 수 있다.

두 방식의 주요 차이점은 의존성 관리와 애플리케이션 구조에 있다. 다음 표는 핵심적인 차이를 비교한다.

Standalone Components는 소규모 애플리케이션이나 기존 NgModule 구조와 병행하여 점진적으로 도입하는 데 특히 유리하다. 이 방식은 번들 크기를 더 세밀하게 제어할 수 있는 잠재력을 제공하며, 학습 곡선을 낮추는 데 기여한다. 그러나 대규모 애플리케이션에서 모든 컴포넌트를 독립형으로 관리할 경우 의존성 선언이 중복될 수 있고, 기존에 NgModule을 통해 제공되던 글로벌 서비스나 설정의 공유 방식에 대한 새로운 접근법이 필요하다. 따라서 Angular는 두 시스템을 완전히 호환되도록 설계하여, 개발자가 프로젝트의 요구사항과 규모에 따라 적절히 혼용하거나 선택할 수 있도록 했다.