최근 Node.js 기반 서버 프레임워크 중 많은 각광을 받고 있는 NestJS. 저번 GraphQL 포스팅과 마찬가지로, 최근 NestJS도 적극적으로 사용해 본 경험이 생겼기 때문에 NestJS에 대해서 여러 포스팅을 작성하려고 한다. 이번 글에서는 NestJS의 등장 배경과 다른 Node.js 기반 서버 프레임워크와 비교했을 때 NestJS가 가지는 장단점 등에 대해 정리해보겠다.
2021년 현재 모던 웹 애플리케이션을 개발하는 데 있어서 Node.js의 인기는 폭발적으로 상승하고 있다. 2021년에 진행된 Stack Overflow Developer Survey에 따르면 Professional Developers에 의해 가장 인기있는 언어 6위에 랭크되어 단연 최고의 인기를 구가하고 있다고 말해도 과언이 아니다. (물론 우리는 한국인이기 때문에 Stack Overflow 말고 프로그래머스에서 진행한 설문 조사를 참고하는 게 조금 더 우리의 현실을 잘 표현하는 설문 결과일 수도 있지만 말이다. 참고로 여기서는 Java와 Spring, Spring Boot가 인기 기술 1위다.)
Node.js가 인기 많은 이유는 여러 가지가 있을 것이고, 서버에서 사용하기에 분명 장점이 충분히 많은 언어인 점은 분명하지만 나름대로의 단점도 가지고 있다. (이 포스팅은 Node.js를 설명하기 위한 글이 아니기 때문에 이 부분은 생략하고 넘어가도록 하겠다.) 아무튼 당신이 Node.js 서버를 만들기로 결정했다고 가정하고, 다음은 서버 프레임워크를 선택할 차례가 되었을 때 당신은 어떤 선택을 해야 할까? 가장 먼저 할 일은 다른 유명한 Node.js 기반 서버 프레임워크인 Express, Koa 등과 함께 비교해보는 것이다.
Express와 Koa는 엄청나게 높은 자유도를 기반으로 삼고 있다. (사실 Node.js 기반 서버들이 대부분 자유도가 높다는 특징을 가지고 있다.) 원하는 기능이 담긴 라이브러리 이것저것을 가져와서 빠르고 가볍게 테스트 서버를 띄워볼 수 있다. 이런 높은 자유도는 그들이 최고 인기 Node.js 서버 프레임워크가 되는 데 큰 긍정적 영향을 주었지만, 어떤 개념이든 장점만 있을 수는 없기에 큰 팀(특히 팀원들이 자주 교체되거나 신입 개발자가 자주 들어오는 성장 중인 팀)의 경우 이런 자유도가 일부 단점으로 다가올 여지를 남겨두게 되었다.
NestJS의 경우 이를 해결하기 위해 컨트롤러, 모듈, 서비스 등 각 파일의 역할이 분명하게 나뉘어 있는 모듈식 아키텍쳐를 사용하고 있다. 여기서 중요한 점은 각 파일의 역할이 분명하게 나뉘어 있다는 점과 모듈식 아키텍처를 사용하고 있다는 점이다.
기존의 다른 서버 프레임워크를 사용하는 경우 프로젝트 코드에 기여한 팀원이 많아지거나 프로젝트의 규모가 빠르게 커질수록 기존 Node.js 서버 프레임워크들이 가지고 있던 자유로움이라는 특성 때문에 개발자 개개인의 설계 구조가 잘 드러나게 되는 상황이나 신입 또는 전배를 통해 팀에 새로 들어온 개발자가 기존 코드를 빠르게 파악하는 데 걸리는 시간을 지체시키는 상황이 발생할 수 있는데 이 경우 통일성을 지키기 어려워지고 유지 보수가 힘들어질 수 있다. 그러나 NestJS의 경우 앞서 말했듯 각 파일의 역할이 분명하게 나뉘어 있어서 모든 개발자가 통일성 있는 코드 구조를 사용하게 된다는 장점이 있다. 실제로 최근 진행한 프로젝트에서 Koa 기반 코드와 NestJS 기반 코드를 번갈아 작업하게 되었는데 이 과정에서 NestJS로 작성된 코드가 훨씬 의도하는 바를 파악하기 쉬웠고, 어떤 방식으로 코드가 동작하는지 전체적인 흐름을 파악하기도 편리했다. 프로젝트 규모가 꽤 컸기 때문에 작성된 코드가 어떤 일을 하는지 파악하는 데 걸리는 시간 차이가 드라마틱하게 발생했다. 이렇듯 다른 팀원이 작성한 코드를 빠르게 이해할 수 있다는 것은 팀 내에서 큰 이득이기 때문에 현재 팀 내에서 NestJS를 사용하는구나 하고 깨닫는 계기가 되었다.
또한, 모듈식 아키텍처를 사용한다는 것은 확장성이 높다는 장점이 있다. 추가되어야 하는 비즈니스 로직이 있다면, 간단하게 새로운 모듈을 작성하는 방식으로 해당 로직을 애플리케이션에 추가할 수 있기 때문에 빠르고 안정적으로 서비스를 확장할 수 있다.
마지막으로, 위에서 설명한 장점 외에 추가적인 장점을 더 꼽아보자면 Nest.js는 기존에 사용되던 Express와 Koa 등과는 다르게 개발 과정에서부터 TypeScript 지원을 고려하여 설계되었기 때문에 안정성이 높다. 그리고, 최근 자주 업데이트되지 않는 Express에 비해 2021년 현재에도 꾸준히 업데이트되고 있기 때문에 전반적인 개발 프로세스에 대해 최신의 트렌드를 포함하고 있다. (2021년 12월 17일, 2년 반 만에 Express 4.17.2 버전이 릴리즈되었습니다. 드라마틱한 업데이트는 아니었지만, 오류라고 생각될 수 있는 부분이기 때문에 정정합니다.) 또한 우리 한국인 개발자들에게 아주 좋은 점이 있다면 NestJS는 다른 프레임워크들과 비교했을 때 (특히 서버 프레임워크 기준으로) 엄청난 고퀄리티의 한국어 공식 문서를 제공하고 있으며 한국어 커뮤니티도 빠르게 성장하고 있다는 추가적인 장점이 있다.
이렇게 들어보면 NestJS와 Express, Koa가 완전히 서로 다른 개념을 가지고 있는 별개의 프레임워크라고 생각될 수 있지만, 사실 Express와 Koa가 같은 뿌리를 두고 있듯 NestJS도 이들과 완벽히 다른 새로운 개념의 기술은 아니다. NestJS는 Express 또는 Fastify를 기반으로 이 위에 새로운 추상화 계층 단계를 덧씌운 구조다. 따라서 살짝 억지를 부리자면 결국 NestJS를 사용하면 자연스럽게 Express 또는 Fastify를 사용하게 되는 것이다. 그러나 앞서 말한 그 추상화 레벨 덕분에 크게 다른 효과를 누리게 되는 것이다.
다음에는 NestJS가 Node.js 위에서 추상화 레벨을 제공하기 위해 어떤 개념을 채택했는지, 위에서 말한 NestJS만이 가지고 있는 장점을 구현하기 위해 내부 구조가 어떻게 되어있는지 등에 대해서 글을 쓰도록 하겠다.
