🧩 NestJS와 모듈 시스템 이해하기

1. 모듈의 정의

소프트웨어 공학에서 모듈(Module)은 거대한 프로그램을 구성하는 독립적인 단위이자 기능적 부품을 의미한다.

레고로 집을 만든다고 상상해 보자. 창문, 벽, 문 블록을 따로 만든 뒤 조립한다. 이때 중요한 것은 각 블록이 서로 맞물리는 표준 규격(interface)을 가졌다는 점이다.

모듈화를 하는 이유는 크게 3가지다.

• 유지 보수의 효율성 (Manageability)
  특정 모듈이 문제가 생기면 해당 모듈만 점검하면 된다. 전체 시스템을 뜯어낼 필요가 없다.
• 재사용성 (Reusability)
  잘 설계된 모듈은 여러 프로젝트에서 그대로 가져다 쓸 수 있다.
• 병렬 개발 (Scalability)
  규격만 맞춰두면 여러 개발자가 각각의 모듈을 동시에 개발해 합칠 수 있다.

2. OOP 관점에서의 모듈 (캡슐화와 응집도)

객체 지향 프로그래밍(OOP)에서 모듈은 단순히 파일을 나누는 것이 아니라 논리적인 경계(Boundary)를 긋는 작업이다. 좋은 모듈은 외부와 철저히 격리되면서도 내부적으로는 단단하게 뭉쳐 있어야 한다.

1. 고 응집 (High Cohesion)
모듈 내부는 응집도가 높아야 한다. 예를 들어 UserModule 안에는 가입, 로그인처럼 유저와 관련된 로직만 뭉쳐 있어야 한다. 만약 이 안에 결제 로직이 섞여 있다면 유저 기능을 고칠 때 상관없는 결제 코드까지 건드려야 하는 위험이 생긴다.

2. 저 결합 (Low Coupling)
모듈 간의 의존성은 최소화되어야 한다. 결제 모듈을 수정했다고 유저 모듈이 고장 난다면 두 모듈은 너무 강하게 결합된 상태이다. 인터페이스(interface)라는 약속된 창구만을 통해 소통함으로써 한 쪽의 변화가 다른 쪽에 번지는 나비효과를 차단해야 한다.

3. 캡슐화 (Encapsulation)
모듈은 자신의 복잡한 내부 로직을 외부에 알리지 않는다. 꼭 필요한 기능만 밖으로 노출(Public) 하고 나머지는 숨김(Private)으로써 외부의 잘못된 접근으로부터 데이터를 보호하고 모듈의 독립성을 지킨다.

3. NestJS에서의 모듈

NestJS는 프레임워크 차원에서 모듈 개념을 강제한다. 모든 NestJS 앱은 최소 하나 이상의 루트 모듈(Root Module)을 가지며 모듈들이 트리 구조로 엮여 하나의 거대한 애플리케이션을 형성한다.

NestJS 모듈은 @Module() 데코레이터를 통해 다음 4가지 핵심 속성을 정의한다.

1. providers: 내부 서비스 레이어로 모듈의 목적을 달성하기 위한 구체적인 구현체들
2. controllers: 인터페이스 레이어로 사용자나 외부 시스템과의 상호작용을 관리하는 계층
3. imports: 이 모듈이 작동하기 위해 필요한 다른 모듈들의 목록
4. exports: 이 모듈의 기능 중 다른 모듈에서도 사용할 수 있게 허용할 명단

@Module({
  // 1. 외부 모듈 가져오기 (DB 기능 등)
  imports: [TypeOrmModule.forFeature([User])],
  
  // 2. 요청을 받을 컨트롤러
  controllers: [UserController],
  
  // 3. 내부에서 사용할 서비스 (DIP 원칙 적용)
  providers: [
    UserService,
    {
      provide: UserRepository, // 추상화된 규격(인터페이스)
      useClass: TypeOrmUserRepository, // 실제 구현체
    },
  ],
  
  // 4. 외부 모듈에서도 쓸 수 있게 공개할 서비스
  exports: [UserService, UserRepository],
})
export class UserModule {}​

4. 실전 Tip

모듈을 설계하다 보면 단순히 나누는 것 이상의 복잡한 상황을 마주하게 된다. 이때 고려해야 할 몇 가지 실전 포인트들이다.

• 순환 참조 (Circular Dependency)
  모듈 A가 B를 참조하고 B가 다시 A를 참조하는 상황이 생길 수 있다. 이는 대부분 설계를 재검토해야 한다는 신호이지만 구조상 어쩔 수 없는 경우 NestJS의 forwardRef()를 사용하여 해결할 수 있다.
• 글로벌 모듈 (Global Modules)
  DB 연결이나 설정 파일처럼 전역에서 쓰이는 기능은 @Global() 데코레이터를 사용하여 매번 imports 하는 번거로움을 줄일 수 있다. 하지만 너무 남발하면 모듈 간의 경계가 모호해지므로 꼭 필요한 곳에만 사용해야 한다.
• 테스트의 용이성 (Testability)
  모듈이 잘 나누어져 있으면 특정 기능을 검증할 때 다른 의존성을 가짜(Mock)로 대체하기 쉬워지며 이는 곧 코드의 안정성으로 이어진다.