서론

큰 기업의 경우 Spring을 많이 사용하는 듯하고, 커가는 기업의 경우 Node.js를 많이 사용하는 듯합니다. 그렇다면, Node.js는 왜 사용할까?

링크에 따르면 PayPal에서 Nodejs에 2명, Java 백엔드에 5명을 할당했지만, Nodejs가 더 빠르게 구현했다는 이야기가 존재합니다. 아래와 같은 크게 2가지 이유에서 Node.js를 사용한다고 생각합니다.
  1. 빠른 구현
  2. NETFLIX, Trello, LinkedIn과 같은 대규모 서비스에도 적합 (큰 기업도 많이 사용하네..?)

그렇다면, 왜? Java&Spring Framework는 유행하는데 Node.js는 유행하지않았을까?

단점

1. Java와 비교했을 때, Node.js는 작고 느린 Single Thread 서버이다.
Java는 각 HTTP 요청을 별도의 Thread에서 처리하지만, Node.js는 모든 요청을 하나의 Thread로 처리.
-> 즉, Java Spring은 여러 HTTP 요청을 동시에 처리할 수 있지만 Node.js의 경우 한번에 1개의 요청만 처리할 수 있습니다. 그렇기때문에 강력한 서버에 Node.js를 설치하더라도, 100%의 성능을 활용할 수가 없습니다.

2. Node.js가 사용하는 언어인 Javascript는 신기한(?) 언어다.
Java, script 두개가 합쳐졌지만 자바도 아니고, 단순히 스크립트 언어도 아니라고 합니다. 다른 고급 언어와는 다르게, 자바스크립트는 단순히 웹 브라우저 화면을 컨트롤 하는 스크립트 용도로 만들어진 언어입니다.

그렇기에 발전한 지금의 자바스크립트에는 간단해 보이는 코드 사이사이에 여러 혼란스러운 변화의 흔적들이 남아있습니다. (`this` keyword의 난해함, 혼란스러운 scope 개념 등..)

Javascript는 좋은 부분이 많은 언어이지만, 위험하고 나쁜 부분은 더 많은 언어로 `잘` 알아야 할 필요가 있습니다.

장점

1. Node.js는 (작고 가벼운) Single Thread 서버이다.
말이 아 다르고 어 다르다는 말처럼, Node.js 서버는 Java와 비교했을 때, 작고 느린것은 맞지만 작고 가볍다고 볼 수도 있습니다.

작고 가벼운 Node.js 서버는 대규모 트래픽을 받아주기에는 크게 유용하게 생각되지는 않았습니다.

하지만, Monolithic Architecture를 대체하여 관심받는 MSA(Micro Service Architecture) 구조와 서버 배포와 관리를 간단하고 빠르게 해줄 수 있는 k8s(kubernetes)가 유행을 탄 후, 상황은 조금 달라졌습니다.

MSA는 거대한 서버를 서비스 기능 별로 나눌 뿐만 아니라, 트래픽을 나눕니다. 예를 들어, 쇼핑몰 회사에서 2대로 모든 서비스 요청을 처리하고 있었다치면, MSA 구조에서는 이벤트 서버 2대, 상품 리스트/추천 서버 2대, 주문/배송 처리 서버 3대 등으로 나눠질 수 있습니다. 

얼핏 보았을 때, 2대 vs 7대로 비효율적으로 보이는 MSA 구조는 트래픽이 많이 몰릴 때 빛을 발합니다. 만약, 어떤 시간 한정 이벤트가 발생해서 이벤트 시간에만 사람이 100배로 증가한다면, 이벤트 서버만 증설해주면 트래픽을 문제없이 처리할 수 있습니다. 또한, 이런 증설은 트래픽을 감지한 k8s 시스템이 자동으로 진행해 줍니다. 뿐만아니라, Node.js의 서버 가동 시간은 1초 이내(java spring 서버 가동 시간은 10 ~ 20초 사이)로 갑자그러운 트래픽에 즉각적으로 대응하기에도 유리합니다.

Node.js는 작고 가벼운 장점이 있다고 했습니다. 이는 JVM위에서 구동되는 Java Spring은 Node.js에 비해 무겁다는 것을 의미합니다. 구체적인 예시를 들자면, 아무것도 하지 않는 Java Spring은 400MB 가량의 Memory를 사용하는데 반해, Node.js는 25MB 정도의 Memory만을 사용합니다. (참조 : 링크) 1대의 서버에서 약 375MB가 차이나는데, N대의 서버를 MSA 구조에서 사용한다면 N*375MB의 Memory가 차이가 날 것입니다.

최근 MSA와 k8s가 유행하며 서버 수 자체도 늘고, 서버 수가 트래픽에 맞춰 유동적으로 바뀌는 상황이 많아졌으며, 크고 강력한 한 대의 서버보다는 빠르고 가벼운 서버가 여러대 있는 쪽이 유리한 상황이 많아졌습니다. 이러한 상황에서 빠른 서버 가동 시간과 적은 Memory 사용량 등 Node.js의 가벼움은 빛을 발하고 있습니다.

처리 능력이 떨어지거나 하나의 thread만 사용해 응답성이 떨어지는 단점들은 서버를 여러대 두면 무마 가능하게 되었습니다. (Single Thread 서버 여러 대 == Multi Thread 서버 1대)

또한, Single Thread 서버의 장점이 있습니다. Single Thread 서버에는 오로지 하나의 thread만 존재하기 때문에, concurrency 지옥에서 고통 받을 필요가 없습니다.

2. Javascript 언어는 나아지고(!) 있다.
Javascript는 호불호가 갈리는 언어라고 합니다. Javasciprt의 가장 큰 단점 중 한 가지는 타입이 없기에, 타입을 강제할 방법이 없었다는 것 입니다.

예를 들어, javascript로 아래와 같이 함수를 짰다면
function plus(number1, number2)
{
    return number1 + number2;
}
우리는 함수를 사용하는 사람한테 number1, number2를 숫자로 쓰라고 강제할 수 없습니다. (어..? 이걸 하나하나 기억해야하나..)

함수 사용자가 아래와 같은 악랄한(!) 짓을 해도 딱히 막을 방법은 없습니다.
var result = plus('1', '2') // 3...! 다행이 이건 의도대로 작동합니다.
var result2 = plus('2', 'number') // '2number'? 우리가 원했던 결과는 아니네요
var result3 = plus(1, '2') // 12, 여기부터 심각하게 잘못된 결과가 나오기 시작합니다.
우리가 할 수 있는 최선은 주석을 길게 달아 사용자에게 제발 이 함수를 정확히 써달라고 아래와 같이 명시(!)하는 것 뿐입니다.
/**
 * @param {number} number1- 더하는 첫번째 수, 제발 숫자만 넣어주세요 ㅜㅜ
 * @param {number} number2- 더하는 두번째 수, 꼭 무조건 숫자만 ㅠㅠ;
 *
 * WARNING!!!! 숫자가 아닌 param을 넣으면 오작동함!!!!
 */
function plus(number1, number2) {
  // ...
}
하지만, 이러한 주석 속의 울부짖음을 무시할 사람은 너무나 많습니다. 소규모 프로젝트에서는 큰 문제가 되지 않았지만, javascript에도 많은 대규모 프로젝트들이 생기며, 이 문제는 심해져 갔습니다. 다행히, 지금은 Typescript가 나왔습니다.

Typescript는 아주 기발한 방법으로 (솔직히 말하면 조금 꼼수를 써서) Javascript를 Type이 존재하는 언어로 재탄생 시켰습니다.

아무튼, Typescript의 탄생으로 인해 Javascript도 type이 있는 interface를 개발자들에게 제공해 줄 수 있게 되었고, Javascript는 대규모 개발에는 어울리지 않는다는 오명도 조금은 벗을 수 있게 되었습니다.

Nest.js의 출시 역시 놓칠 수 없는 포인트입니다.

Java Spring이라는 Framework가 제공하는 DI, IoC 기반의 개발은 Java를 포기하기 힘들게 만드는 Spring의 큰 장점입니다. 하지만, 지금은 Nest.js의 출시로 인해, Javascript에서도 마치 Java Spring을 쓰는 것처럼 Annotation을 통해 편리하게 DI, IoC 기반의 개발을 할 수 있습니다.

그리고 Nest.js는 Typeorm이라는 ORM 프레임워크 역시 적극적으로 지원하고 있기에, 더더욱 Java Spring + JPA 과 같은 조합을 쓰는 느낌으로 Javascript(Nest.Js + Typeorm) 개발을 할 수 있습니다.

Nest.js에 대해 조금 더 자세히 알고 싶으시다면 링크를 통해 글을 참조해보셔도 좋을 것 같다고 합니다.

또한, Javascript 진영에도 Jest나 Mocha 같은 좋은 테스트툴이 나왔기에 DI, IoC 구조가 제공하는 장점 중 하나인 `유닛테스트의 편리함` 역시 잘 활용할 수 있게 되었습니다.

결론은, 서버 개발 언어로서의 javascript는 발전하고 있다는 것 입니다. 부족한 부분은 채워지고 있고(Typescript, Next.js) 개발 툴 역시 보강되고 있습니다. (Typeorm, Jest, Mocha)

위에서도 말했지만, `Javascript는 좋은 부분이 많은 언어이지만, 위험하고 나쁜 부분은 더 많습니다.` 
그렇지만 좋은 부분도 천천히, 하지만 확실하게 많아지고 있습니다.

 

네이버 파이낸셜의 페이플랫폼 직속 팀에서는 미래(PHP가 이끌던 백엔드 개발 트렌드를 Java Spring이 가져갔던 것처럼, 언젠가는 Node.js 역시 개발 트렌드를 주도)에 대비하여, 적극적으로 Node.js를 도입하고 노하우를 쌓아가고 있다고 합니다.

  • 네이버 쇼핑 구매 목록 API를 제공하는 타임라인 서버
  • 혜택 광고 API를 제공하는 리워드 서버
  • 카드 정보 API를 제공하는 간편 입력 서버
  • 마이데이터 API를 제공하는 마이데이터 서버

... 외 다양한 서버들을 Node.js(+ MSA, k8s)로 개발하고 운영하고 있다고 합니다. 또한, 대규모의 CPU 연산이 필요한 신규 DB 구축을 위한 마이그레이션 작업 역시 MSA 구조의 Node.js 서버로 처리해서, Node.js 서버로도 대규모 CPU 연산 작업이 가능하다는 것을 검증했고, 노하우를 쌓아가고 있다고 합니다.

 

 

내용들을 정리하며, Node.js에 대해 궁금해졌고 공부해보면 좋을 것 같다는 생각이 들었습니다. Java Spring을 경험해본 입장에서 비교해보며, 어떤 차이가 있는지 토이프로젝트를 진행해봐야겠습니다.

 

 

 

 

 

Reference

 

 

 

 

'Javascript' 카테고리의 다른 글

Nest.js를 이용한 게시판 API 개발  (0) 2024.07.21
Nest.js Pipes  (0) 2024.06.17
[Nest.js] Module  (0) 2024.06.11
ES6  (0) 2024.06.05
기본 Javascript 문법  (0) 2024.06.04

+ Recent posts

티스토리툴바