1장 NestJS 시작하기 - 1.1. Introduction

최근에 express + typescript 프로젝트를 NestJS 프레임워크를 사용하는 일이 생겨서 문서를 통해서 배운 지식들을 오늘부터 기록하기로 결정했습니다.

NestJS란 무엇인가?

 

해당 공식문서를 찾아보면 다음과 같습니다.

> NestJS는 효율적이고 확장 가능한 Node.js 서버 측 애플리케이션을 구축하기 위한 프레임워크입니다.

 

그리고 해당 공식문서 사이트에서 소개하는 핵심 단어는 다음과 같습니다.

https://nestjs.com/

- EXTENSIBLE (확장성)

- VERSATILE (가시성)

- PROGRESSIVE (진보성)

 

왜냐하면 최근 자바스크립트 생태계는 Node.js라는 런타임 환경이 생겨나면서 프론트 및 백엔드 등 다양한 영역에서 생산성이 향상되며 여러 다양한 라이브러리가 생겨났습니다. 이러한 라이브러리의 다양화와 생산성 발전으로 프론트엔드에서는 Angular, React, Vue, 등 프로젝트가 탄생되었고 JS가 아닌 다른 언어에서 이미 존재했던 패러다임과 타입 안정성의 요구를 받아들이면서 Typescript 같은 언어 및 도구가 생겨나고 있습니다. 급속도로 발전하고 있는 JS 생태계에서 서버 측에서는 아키택쳐의 주요한 문제점을 해결하지 못했습니다.

 

물론 node.js 탄생 이후로 보안 및 여러 이유등을 위해 deno.js 탄생되어 있지만 npm에 있는 기존에 사용하고 있는 라이브러리를 사용할 수 없다는 점에 아쉬웠습니다. 물론 npm에 대한 보안에 취약점이 있다는 것을 이해할 수 있지만 deno.js로 받아들이기에는 부족한 환경이었습니다. 그리고 제일 큰 문제는 서버 측 js에서 가장 많이 사용하고 있는 프레임워크는 express입니다.

 

그래서 nest.js 탄생 이전에는 express 에 typescript 도구를 사용하여 어느 정도 타입의 안정성을 해결했지만 한편 프레임워크 측으로 본다면 이것은 단지 타입스크립트의 이점이지 프레임워크의 향상은 아니었습니다. 특히 express는 개발자에게 폴더 및 구조에 대한 자유로운 책임을 주기 때문에 간단한 프로젝트나 빠른 시일에서 만들 때는 효과적이었지만 엔터프라이즈급 프로젝트에서 사용하기에는 너무나 많은 유지 및 관리 비용이 들었습니다.

 

저 역시 express를 사용할때 다른 언어 측에서 사용하고 있는 프레임워크의 디자인패턴과 아키택쳐를 공부해야 했습니다.

 

왜냐하면 처음에 express로 서버측 애플리케이션을 구현할 때 마치 C언어를 배우는 것처럼 개발자에게 너무 많은 책임을 준다는 것을 느꼈습니다. 특히 제가 짜는 프로젝트에 대한 아키택쳐 고민을 자주 하게 되며 비즈니스 로직에서 집중하지 못했습니다. 다른 언어에서는 이미 이러한 고민을 받아들여서 프레임워크에 녹아있는데 js 생태계에서는 이러한 고민을 하기 시작한 지 불과 8년밖에 되지 않기 때문이었습니다. 

 

그리고 아키택쳐를 고민하는 것은 좋지만 저는 너무 자유로운 책임을 주는 express 구조에 마음에 들지 않았습니다. 그래서 특히 express 를 사용할 때 다른 장고나 스프링에 있는 아키택쳐를 받아들여 코드를 짰습니다. 다만 혼자서 이러한 구조를 짤 때도 자신이 정한 아키택쳐에 맞게 짰는지 혹은 실수를 했는지 검증하기에 너무 많은 비용이 들었습니다. 

 

하지만 Nest.js를 사용하면서 문서에서 소개한 것 처럼 마치 JS의 자유로움과 관리하기 쉬운 아키택쳐를 짤 수 있어서 오히려 편했습니다.

 

이러한 방식이 Angular에서 영감을 얻었다고 합니다. 저는 Angular를 다룬 경험이 거의 없기 때문에 영감을 얻었다는 부분을 잘 모르겠습니다.