Java + Spring 개발자 약 1년 반을 하였고 최근에는 Typescript + NestJS 개발자 약 1년 반을 하였다.
나는 객체지향을 좋아하다 보니, Typescript와 NestJS를 사용할 때 Javascrtip라는 근본적인 언어의 특성 때문에 요즘 들어 Java + Spring을 하고 싶어졌다.
나는 크게 두 가지의 지극히 개인적인 아쉬움이 있다.
1. Typescrtipt는 오버로딩이 안된다는 것이다.
2. NestJS는 Spring처럼 자동으로 인터페이스의 구현체를 어노테이션 하나만으로 주입해주지는 않는다.
이외에도 많지만 지극히 개인적으로 저 두 가지가 제일 아쉽다.
메서드의 네이밍은 메서드의 역할이 잘 드러나야 한다. 하지만 그렇다고 너무 길면 가독성을 헤친다.
때문에 오버로딩이 된다면, 메서드의 네이밍은 메서드의 역할 즉 행위에 초점을 두고 필요한 매개변수의 표현은 온전히 메서드의 파라미터에 맡길 수 있어, 메서드의 역할에 맞춰 네이밍이 가능하고 부가적인 정보는 매개변수에 객체로써 표현가능하다.
쉽게 말해 메서드는 행위 즉 동사라고 생각한다면, 매개변수는 동사를 꾸며주는 보어 또는 목적어라고 생각하는데 Typescript는 보어 또는 목적어를 바꿔 끼워 표현할 수 없다보니(오버로딩 불가), 매개변수의 표현을 바꿔가며 다양한 메서드를 만들기 쉽지않다. 그래서 개인적으로는 동사 자체에 모든것을 담아내려하다보니 메서드 네이밍이 길어진다.
NestJS는 Spring처럼 자동으로 인터페이스의 구현체를 주입해주진 않는다, 직접 인터페이스의 구현체를 모듈 또는 사용하는 곳에서 명시를 해줘야 하는데, 물론 이게 나쁘다고는 생각하지 않는다. 다만, OCP 관점에서는 인터페이스의 구현체가 바뀌었을 때 결국 사용하는 곳에서 또는 주입해 주는 모듈에서 개발자가 직접 바꿔줘야 하기 때문에 결국 수정을 해줘야 하는 부분이 생기는 것이라, 이 부분도 살짝 아쉬운 느낌이다.
그렇다면 Typescript와 NesstJS를 왜 써야 하는가? 에 대한 의문이 들었다.
이 부분은 NodeJS를 왜 쓰는가?라고 할 수 있을 것 같다.
1. NodeJS는 가볍다. 여기서 가볍다는 것은 메모리뿐만 아닌 실행속도도 빠르다는 얘기다.
NodeJS는 V8 엔진 위에서 돌아가기에 Tomcat이나 Netty 같은 서버나 JVM 런타임 및 관련 도구들이 필요 없다.
덕분에 빠른 생산성이 필요한 경우 NodeJS가 좋은 선택지가 될 수 있다.
2. 비동기 이벤트 처리 모델이 있다. NodeJS는 Event Loop라는 비동기 이벤트 처리 모델이 있어, 손쉽게 비동기 기반의 코드들을 구현해 낼 수 있다. 이는 비동기 I/O 처리가 많고 동시 요청이 많은 간단한 서버에서는 막강한 힘으로 작용한다.
정리해 보면 NodeJS는 가볍고 복잡하거나 크지 않은 서버로써는 꽤 좋은 선택지가 될 수 있다. 이는 트래픽에 따라 손쉽게 서버를 수평 확장할 수 있는 Cloud 기반의 환경에서는 더 큰 장점으로 다가온다.
그렇지만..
단점도 있다 예를들어 JSON을 파싱하는 작업은 Javascript 의 경우 V8엔진이 최적화가 되어 있지만, 그럼에도 Javascript/Typescript 는 인터프리터 기반 언어이기에 Java의 Jackson라이브러리보다 느릴 수 있고 CPU 집약적인 작업이기 때문에 NodeJs 기반의 환경에서는 이벤트 루프를 차단할 수 있는 병목현상의 원인이 될 수 있다.
또한 개인적으로 나는 Java + Spring 또는 Kotlin + Spring을 하고 싶다. 결국 NodeJS의 비동기 이벤트 처리 모델을 잘 이용하려면, CPU 작업보다는(로직) 비동기 I/O작업을(쿼리) 잘 활용해야 하는 것 같은데, 이러려면 결국 비즈니스 로직을 코드에 담아내기보다는 쿼리단에서 담아내야 하는 것이 아닌가라는 생각이 들기 때문이다. 나는 비즈니스는 코드단에 로직에 잘 드러나야 향후 유지보수에도 효과적이라고 생각한다. 그래서 쿼리단보다는 로직단에서 많은것을 담아내고 표현해 내고 싶다.
(+ 추가적으로 worker thread를 사용하면 NodeJS 또한 멀티 쓰레드의 장점을 가져갈 수 있으나, worker thread를 관리하는 비용인 러닝커브 및 관련 추가되는 코드들을 생각하면 이 또한 Spring을 사용하는게 낫지 않나 싶다)
또한 Spring이 제공하는 막강한 기능들을 사용해보고 싶고, 객체지향 언어로써 책임에 따라 Class를 만드는 것이 너무나 당연하고, 거리낌이 없는 환경에서 객체지향에 대한 고민을 조금이라도 더 하는 개발을 하고 싶기 때문이다.
추가적으로 아래의 글은 NodeJS에 대해 간단하게 정리해본 글이다.
누가 NodeJS 싱글쓰레드라 했냐? / NestJS를 사용한 작업 병렬 처리
- C++ 기반의 NodeJs는 크게 v8과(Javascrtip engine) + libuv로 구성되 었는데 libuv는 thread pool, event loop, network I/O 등을 담당한다.
흔히 NodeJs가 싱글쓰레드라고 하는것은 event loop에 대한 이야기이고 event loop 의 처리는 thread pool이 담당하게된다.
event loop는 Non-Blocking I/O 작업에 특화되어 있는데 그 이유는 NodeJs가 Non-Blocking I/O작업같은 경우 OS의 Thread에 위임하기 때문이다.
만약, OS Thread에 위임하지 않는 CPU 집약적인 연산을 event loop를 통해 실행하는것은 thread pool에 있는 thread를 블락시키는 행위가 될 수 있어 결과적으로 event loop또한 블락되는 행위가 될 수 있다.
(때문에 Non-Blocking I/O 작업이 아닌 async/await 함수는 아무런 도움이 되지 않는다.)
feet) 이벤트 루프를 막지마라