0. Nest.js 란

공식 홈페이지 docs :

Documentation | NestJS - A progressive Node.js framework Documentation | NestJS - A progressive Node.js framework

Nest.js를 아주 쉽게 설명하자면 아래와 같습니다.

• “Node.js에 ‘뼈대’와 ‘규칙’을 입혀서, 서버(백엔드) 코드를 깔끔하고 체계적으로 짤 수 있게 만들어주는 도구

자 여기서 조금 더 풀어서 알기쉽게 설명해보자면,

• Node.js
  • 자바스크립트로 웹 서버(백엔드)를 만들 수 있게 해주는 기술, 런타임 환경(Run-time Environment)
  • 원래 자율성이 높아서 자유롭게 코드를 짤 수 있지만, 규모가 커질수록 코드가 복잡해질 수 있습니다.
• NestJS
  • 바로 이 Node.js 위에 “집을 짓는 도면” 같은 설계도를 제공해주는 프레임워크(Framework)
  • “어떤 폴더에 어떤 코드가 들어가야 하고, 어떻게 함수들을 연결해야 하며, 데이터를 주고받을 땐 어떻게 처리해야 하는지” 같은 규칙과 도구를 한꺼번에 제공합니다.
  • 덕분에 여러 사람이 큰 프로젝트를 할 때도 코드 구조가 한결같고 깔끔해집니다.
• 장점
  • TypeScript(타입스크립트)를 기본으로 사용해, 오타나 실수를 줄여줍니다.
  • 웹 서버, 데이터베이스 연결, 인증/로그인 기능, 마이크로서비스 연동 등등 필요한 기능을 다 모듈로 갖추고 있습니다.
  • “안정된 틀” 위에 코드를 쌓아 올리기만 하면 되니까, 처음부터 일일이 설정할 필요가 줄어듭니다.
• 예시
  • 만약 Express(기존 Node.js 라이브러리)로 프로젝트를 만든다고 치면, app.js, routes, controllers 폴더 등을 직접 만들어서 구조를 잡아야 함. Fastify 로도 가능합니다.
  • NestJS로 만들면, “이렇게 짜면 좋아요!” 라고 제안하는 기본 폴더 구조와 코드 작성 방법이 있어서, 짧은 시간에 안정적인 서버를 세울 수 있습니다.

쉽게 생각하면 위와 같겠지만 실제로 사용해보면 굉장히 무거운 내용을 다루고 있다는 것을 느끼실 수 있을겁니다.

Nest.js 가 가진 단점들

1. 비교적 큰 “오버헤드(Overhead)”
   • 무겁고 복잡한 구조
     • NestJS는 모듈/의존성 주입/데코레이터 등 다양한 기능을 내장하고 있어, 프로젝트 파일 구조도 많고 초기 설정이 다소 복잡합니다.
     • 작은 규모나 프로토타이핑 용도로는, “NestJS = 너무 많은 보일러플레이트(boilerplate)”라고 느낄 수 있습니다.
   • 런타임 성능
     • 일반적으로 Express 단독 사용 대비, NestJS는 DI(의존성 주입)와 데코레이터 처리 등 추가 로직이 들어가므로 성능 오버헤드가 조금은 있습니다.
     • 물론 Fastify 어댑터 등을 쓰면 크게 문제되지 않을 수도 있지만, 미니멀 프레임워크(예: Koa)보다는 무겁게 느껴질 수 있습니다.
2. 학습 곡선(Learning Curve)
   • Opinionated(의견이 강한) 구조
     • NestJS는 Angular, Spring Boot처럼 “어떻게 코드를 작성해야 하는지”를 꽤 구체적으로 정해놓았습니다.
     • 처음 접하는 사람 입장에선 “Controller, Service, Module, Decorator, DI” 등 개념이 한꺼번에 몰려오다 보니, Express나 Koa 대비 공부할 게 많다고 느낄 수 있습니다.
   • TypeScript 필수
     • NestJS는 TypeScript를 기본으로 사용하기 때문에, JS만 익숙한 개발자라면 TS 문법부터 학습해야 할 수 있습니다.
3. 소규모 / 간단 프로젝트엔 오버스펙
   • 보일러플레이트 코드(Boilerplate Code) 증가
     • 작은 API 서버나 간단한 PoC(Proof of Concept) 단계라면, NestJS가 제공하는 많은 기능들을 쓸 일이 거의 없을 수 있습니다.
     • 이럴 때 경량 프레임워크(Express/Koa/Fastify) + 필요한 라이브러리 몇 개 조합이 더 빠르고 간단할 수도 있습니다.
   • 가장 중요한 건 ‘필요한 기능만큼’
     • NestJS는 확장성과 구조화를 중시하지만, 프로젝트가 아주 작으면 ‘과투자’가 될 수도 있습니다.
4. 데코레이터 & OOP 기반에 대한 호불호
   • 데코레이터 문법(예: @Controller, @Get(), @Injectable() 등)을 적극 활용하고, 클래스/OOP 패턴 위주로 구성하기 때문에, 함수형 스타일이나 매우 자유로운 방식을 선호하는 팀에는 안 맞을 수 있어요.
   • Node.js는 원래 “함수형, 미니멀리즘”에 익숙한 생태계여서, “NestJS가 지나치게 자바/스프링스럽다”라는 반감을 갖는 경우도 있습니다.
5. 생태계의 성숙도(특정 라이브러리 사용 시)
   • NestJS는 빠르게 성장하는 커뮤니티를 가지고 있지만, 여전히 특정 서드 파티(3rd party) 라이브러리와의 연동 예시가 부족할 때가 있습니다.
     • 예: “NestJS 버전에 맞춰 제대로 문서가 정리된 공식/비공식 모듈”이 Express에 비해 상대적으로 적을 수 있습니다.
   • 다만, Express나 Koa 기반 라이브러리를 NestJS와 함께 사용할 수 있긴 하지만, **“NestJS 방식으로 래핑(Wrapping)”**해야 해서 약간의 추가 작업이 필요할 때도 있습니다.
6. 팀의 자유도 감소
   • Opinionated = 장점이자 단점
     • 장점 : NestJS는 프로젝트 구조와 패턴을 상당히 강제하므로, 팀원들이 비교적 일관된 방법으로 코딩할 수 있습니다.
     • 단점 : 하지만 “원하는 대로 자유롭게 아키텍처를 설계하고 싶다”는 입장이라면, NestJS의 고정된 규칙이 답답할 수 있습니다.
   • Express 같은 미니멀 프레임워크라면 아키텍처를 직접 정의할 수 있지만, NestJS에서는 이미 큰 뼈대가 정해져 있어서 수정이나 확장이 어려운 부분이 있을 수 있습니다.

그럼에도 불구하고 Nest.js 를 선택하는 기업들은 ?

이거 외에도 다양한 단점들이 존재한다고 보여집니다. 이럼에도 불구하고 어떠한 장점을 가지고 있기에 어떤 기업에서 왜 채택하여 사용할까요 ?

1. Node.js + TypeScript로 대규모 프로젝트를 운영하는 기업
   • 스타트업부터 엔터프라이즈까지
     • 예전엔 Express.js를 쓰던 회사들이 “TypeScript로 마이그레이션” 하면서, 좀 더 체계적인 아키텍처가 필요해 NestJS로 갈아타는 경우가 많습니다.
   • 팀 협업이 중요한 곳
     • 개발자가 여러 명 이상이 되고, 장기간 유지보수가 필요한 프로젝트에서는, NestJS가 제공하는 모듈/DI/레이어 구조가 큰 도움이 됩니다.
   장점
   • 구조화된 코딩 패턴
     • NestJS는 “어떻게 코드를 짜야 할지”를 프레임워크가 제시해주므로, 팀원이 달라져도 일관된 코드 스타일을 유지하기 쉽습니다.
   • TypeScript 지원
     • 대규모 코드베이스에서 타입 안전성은 상당히 중요합니다. NestJS는 TS를 공식적으로 내장해 개발 효율을 높여줍니다.
   • 테스트와 유지보수 용이
     • 의존성 주입(Dependency Injection)과 모듈 구조 덕분에, 테스트를 만들기 쉽고 수정 시 파급효과를 최소화할 수 있습니다.
2. 마이크로서비스 아키텍처(MSA)를 운영하거나 계획하는 기업
   • NestJS는 Microservices 모듈로 gRPC, Kafka, RabbitMQ, NATS 등 다양한 통신 방식을 공식 지원합니다.
   • 여러 서비스가 분산되어 있는 환경에서, 동일한 패턴으로 코드를 짜고 모듈화/테스트를 할 수 있어 관리가 수월합니다.
   장점
   • 공식 지원되는 마이크로서비스 기능
     • 별도의 라이브러리를 찾지 않고도, NestJS 패키지만으로 다양한 메시지 브로커나 RPC 시스템과 연동 가능합니다.
   • 일관된 개발 경험
     • HTTP 서버, 마이크로서비스, WebSocket 등 서로 다른 프로토콜을 동일한 구조로 개발할 수 있어 팀 전체가 편리합니다.
3. 클라우드/서버리스 환경(AWS, GCP 등)에서 Node.js 애플리케이션을 개발하는 기업
   • NestJS로 작성한 코드를 AWS Lambda, Google Cloud Functions 등 서버리스 환경에 배포하거나, 컨테이너(ECS, Kubernetes 등)로 띄우는 사례가 늘고 있습니다.
   • 왜냐하면, 서버리스 환경에서도 어플리케이션 레벨에선 여전히 체계적인 코드 구조가 필요하기 때문입니다.
   장점
   • 서버리스와도 쉽게 결합
     • NestJS는 Express/Fastify 기반이므로, AWS API Gateway + Lambda 핸들러로 맞추기 수월합니다.
   • 클라우드 서비스 연동 모듈
     • 예: @nestjs/axios, @nestjs/config 등을 통해, 외부 API나 설정 관리도 효율적으로 할 수 있습니다.
4. 대규모 REST API 혹은 GraphQL API를 운영하는 기업
   • 예: 전자상거래, 핀테크, 소셜, 사내 업무 시스템 등 API 서버가 핵심인 도메인
   • NestJS는 Swagger 연동(@nestjs/swagger)부터 GraphQL 지원(@nestjs/graphql)까지 공식 모듈이 잘 갖춰져 있어, 엔드포인트 문서화와 API 설계, 스키마 관리가 편리합니다.
   장점
   • API 문서화(Swagger) 쉬움
     • 데코레이터를 이용해 엔드포인트와 DTO(데이터 전송 객체)를 정의하면, 자동으로 Swagger 문서가 생성됩니다.
   • GraphQL 서버 쉽게 구축
     • 스키마, 리졸버를 NestJS 스타일로 작성할 수 있어, REST ↔ GraphQL 병행 운영도 간편합니다.
5. “Node.js + Spring Boot 유사 경험”을 원하는 기업
   • Java/Spring에 익숙한 조직이지만, Node.js도 같이 쓰고 싶은 경우에, NestJS는 스프링 부트와 유사한 구조(모듈, DI, 데코레이터, 계층화)로 개발할 수 있어 선호됩니다.
   • 기존 스프링 개발자도 NestJS를 접하면, 비교적 빠르게 적응할 수 있다는 장점이 있습니다.

장점

• 학습 곡선 단축
  • 스프링에 익숙한 개발자가 Node.js 세상으로 넘어올 때 이질감을 덜 느낄 수 있습니다.
• 엔터프라이즈 문화와 잘 맞음
  • 아키텍처를 “큰 틀”에서 강제하는 부분이 엔터프라이즈 개발 문화(규모가 크고 규칙이 필요한 환경)와 잘 어울립니다.

인기는 어떠한가 ?

결론

정리하자면 NestJS를 사용하는 기업 유형은 아래와 같을 것입니다.

1. 중·대규모 팀에서 Node.js로 프로젝트를 운영하는 회사,
2. 마이크로서비스 도입 또는 서버리스 환경을 원하는 회사,
3. TypeScript 기반으로 안정적인 백엔드 아키텍처를 갖추려는 회사,
4. API(REST, GraphQL) 위주로 빠르게 문서화와 스키마 관리를 해야 하는 회사,
5. 스프링 부트처럼 일관된 구조로 Node.js를 활용하고 싶은 회사.

2024년 인기 그래프를 통해 예상 할 수 있듯 NestJS의 구조화, DI, 모듈성, TS 지원 등을 통해 개발·운영 효율과 코드 품질을 높일 수 있기 때문에, Express보단 NestJS를 선택하는 경우가 늘어나고 있다고 보여집니다.

클라우드를 활용한 마이크로서비스나 서버리스를 구성할 때 함수 호출(서버리스)마다 이미지(코드)가 로드되는 “콜드 스타트” 문제가 가장 중요합니다. NestJS는 초기 부팅 시 DI 컨테이너를 구성하는 등의 오버헤드가 있지만, 최신 AWS Lambda 등에서는 한 번 부팅된 환경을 재사용하는 방식(웜 스타트)도 많고, Fastify 어댑터를 사용하면 초기 부팅 성능이 더 좋아지는 등 최적화 할 방법이 있어서 nodejs 를 사용하는 기업 내 엔터프라즈 급 레벨 프로젝트 에서는 거의 필수로 여겨집니다. 앞서 무겁다는 표현을 썼지만 NestJS도 내부적으로 Express나 Fastify를 사용하고, Express보다 훨씬 가벼운 Fastify로 NestJS를 구동할 수도 있습니다. 이 경우, HTTP 요청 처리는 Fastify가 맡고, NestJS는 모듈/DI/컨트롤러 데코레이터 같은 “아키텍처” 부분을 담당하게 하고 실제로 초당 트래픽이 아주 높은 서비스도 NestJS + Fastify 조합으로 잘 운영하고 있다는 사례가 많고 실제로 제가 현업에서 잠깐 썼을때도 무겁고 느리단 느낌을 받진 못했기에 설계에 따른 운영에 많은 차이가 있을 것 입니다. 그래서 “가볍게 가자”라는 이유만으로 NestJS를 포기하기보다는, 어느 정도 체계가 필요한지, 얼마나 많은 서비스/개발자가 협업하는 지를 종합적으로 보고 결정하는 편이 좋을 것 같습니다.