---
category: Architecture
tags: [auto-wikified]
title: NestJS
description: "NestJS는 Angular의 아키텍처에서 영감을 받아 TypeScript로 구축된 효율적이고 확장 가능한 서버 사이드 Node."
last_updated: 2026-05-04
---

# NestJS

## 📌 Brief Summary
NestJS는 Angular의 아키텍처에서 영감을 받아 TypeScript로 구축된 효율적이고 확장 가능한 서버 사이드 Node.js 프레임워크입니다 [1]. 기본적으로 Express를 사용하며(Fastify로 변경 가능) 의존성 주입(DI), 데코레이터, 모듈 시스템과 같은 엔터프라이즈 패턴을 도입하여 Node.js 프로젝트에 체계적인 구조를 제공합니다 [2-4]. 대규모 팀, 복잡한 비즈니스 로직, 마이크로서비스 아키텍처를 요구하는 엔터프라이즈급 애플리케이션 구축에 주로 활용됩니다 [5, 6].

## 📖 Core Content
* **오피니언 기반의 모듈식 아키텍처 (Opinionated Modular Architecture)**
  NestJS의 모든 것은 컨트롤러(Controller), 모듈(Module), 프로바이더(Provider)를 중심으로 구성됩니다 [2, 7]. 대규모 코드베이스 확장을 위해 기술적 계층(Layer) 기준이 아닌 기능(Feature) 기반으로 폴더와 모듈을 구성하는 것이 권장되며, 각 기능 모듈은 컨트롤러, 서비스, DTO, 엔티티, 테스트를 한 폴더에 응집하여 관리합니다 [8, 9].
* **강력한 의존성 주입(DI) 시스템**
  생성자를 통해 필요한 의존성을 선언하면 프레임워크의 DI 컨테이너가 이를 자동으로 인스턴스화하고 주입합니다 [4, 10, 11]. 이 패턴은 구성 요소 간의 결합도를 낮춰주며, 단위 테스트 시 실제 서비스를 모의(Mock) 객체로 쉽게 교체할 수 있도록 하여 테스트 가능성을 극대화합니다 [10, 12].
* **구조화된 횡단 관심사(Cross-Cutting Concerns) 관리**
  NestJS는 단순한 미들웨어 이상의 구조화된 대안으로 가드(Guard), 인터셉터(Interceptor), 파이프(Pipe), 예외 필터(Exception Filter)를 제공합니다 [1, 13]. 예를 들어, `main.ts`에 전역 필터를 등록하여 모든 엔드포인트에 일관된 예외 처리 형식을 적용하고 [14], RxJS 스트림을 활용하여 비동기 흐름을 제어하고 로깅이나 유효성 검사를 삽입합니다 [15].
* **DTO와 엔티티(Entity)의 철저한 분리**
  데이터의 입출력 형태를 정의하는 DTO(Data Transfer Object)와 데이터베이스 모델인 엔티티는 시간이 지남에 따라 변하는 방향이 다르므로 별도로 분리해야 합니다 [16, 17]. `class-validator`를 이용해 DTO 수준에서 입력값을 검증하며, 컨트롤러가 엔티티를 직접 노출하는 것을 피하여 API 스펙의 결합도와 데이터 유출 위험을 줄입니다 [18, 19].
* **엔터프라이즈 및 마이크로서비스 생태계 지원**
  TCP, Redis, NATS, Kafka, RabbitMQ, gRPC 등 다양한 전송 계층을 지원하는 마이크로서비스 통신 모듈을 기본으로 제공하여 분산 모놀리스를 해체하기 쉽습니다 [13, 20, 21]. 또한 데코레이터를 이용한 코드 퍼스트 및 스키마 퍼스트 접근법을 모두 지원하는 강력한 GraphQL 통합 모듈(`@nestjs/graphql`)을 제공합니다 [20, 22, 23].

## ⚖️ Trade-offs & Caveats
* **가파른 학습 곡선과 보일러플레이트 부담**
  NestJS는 Express의 단순한 미들웨어 패턴과 달리 DI, 데코레이터, 모듈, 가드, 파이프 등의 개념을 익히는 데 더 많은 시간이 소요됩니다 [20, 24]. 특히 2~5명 규모의 소규모 팀이나 단순한 MVP, 서버리스 함수 개발 시에는 비즈니스 가치보다 프레임워크 설정 및 배선(Wiring) 코드(모듈 등록, 프로바이더 주입, DTO 정의 등)를 작성하는 데 비용이 더 많이 드는 오버엔지니어링이 될 수 있습니다 [5, 25, 26].
* **추상화 계층으로 인한 성능 오버헤드**
  데코레이터와 DI 컨테이너 계층이 추가됨에 따라 순수 Express에 비해 초당 요청 처리량(req/s)이 약 10~15% 감소할 수 있습니다 [27]. 다만 이는 Fastify를 기본 HTTP 어댑터로 전환하여 극복할 수 있으며, 실제 병목은 프레임워크 오버헤드보다 데이터베이스 쿼리나 네트워크 지연에서 발생하는 경우가 많습니다 [27, 28].
* **단일 스레드 한계와 이벤트 루프 차단**
  Node.js 환경 위에서 구동되므로 I/O 집약적 작업에는 강하지만, CPU 집약적인 연산을 수행할 경우 단일 스레드 이벤트 루프가 차단되어 전체 동시 요청의 응답 시간이 저하됩니다 [29, 30]. 무거운 연산은 워커 스레드나 별도의 서비스로 오프로드(Offload)해야 합니다 [30].
* **마이크로서비스 공유 자원 관리의 복잡성**
  모노레포 환경에서 여러 마이크로서비스 간에 엔티티를 직접 공유하거나 임포트할 경우 구조가 분산 모놀리스(Distributed Monolith)로 변질될 위험이 있습니다 [31]. 여러 서비스 간 공유 라이브러리(Shared libs)를 동기화하고 버전을 관리하는 작업은 마이크로서비스 확장에 따라 점차 고통스러워질 수 있습니다 [31, 32].
* **순환 참조(Circular Dependencies) 발생 가능성**
  설계 단계에서 모듈 간 책임을 잘못 분리하면 서로를 참조하는 순환 참조 에러가 빈번하게 발생합니다 [31]. 프레임워크가 제공하는 `forwardRef()`를 사용하여 경고를 우회할 수 있지만, 장기적인 유지보수를 위해서는 아키텍처 구조 자체를 재설계하는 것이 권장됩니다 [12, 31].

---
*Last updated: 2026-05-03*