Node.js의 역사 간단하게 살펴보기 - Node.js는 왜 탄생하게 되었을까?

Dahee Kim·2022년 5월 20일

역사 시리즈

목록 보기

1/1

도입

문득 이런 궁금증이 생겼습니다. Node.js는 누가? 왜? 어떤 필요로 인해 만들었을까? 오늘은 Node.js의 역사에 대해 간단하게 살펴보려고 합니다.

오류가 있다면 댓글로 알려주세요. 언제든지 환영입니다.

Node.js

Node.js는 13살 밖에 되지 않았다는 사실, 알고 있었나요? (2009년 탄생)
이에 비해 JS는 26살, 웹은 33살이나 먹었습니다.

1년 사이에도 많은 것들이 생겨나는 IT기술 분야에서 13년은 그리 긴 시간이 아니지만, Node.js는 꼭 처음부터 존재해왔던 것 같습니다.

지금부터 Node.js의 역사에 대해 간단히 알아봅시다.

Node.js의 탄생이전, 최초의 JS 런타임 환경 - Netscape Livewire

JS는 넷스케이프에서 만든 프로그래밍 언어로, 처음에는 Netscape Navigator(넷스케이프가 개발한 웹 브라우저)내에서 웹 페이지를 조작하기 위해 만들어졌습니다.

넷스케이프의 비즈니스 모델의 중요한 부분 중 하나는 웹 서버 및 웹 개발 요구 사항에 대한 솔루션을 판매하는 것이었습니다.

그 솔루션은 "Netscape Enterprise Server" 였는데, 여기에는 서버 측 JS를 활용하여 동적인 페이지를 생성할 수 있는 Netscape LiveWire이라는 환경이 포함되었습니다.(넷스케이프에서 개발한 JS 런타임 환경이라고 할 수 있겠습니다.)

넷스케이프의 경쟁사였던 Microsoft에서도 비슷한 솔루션으로 "Active Server Pages" 를 판매하였습니다. ASP는 JScript(Microsoft의 초기 Javascript 구현)를 지원했지만 VBScript, PerlScript와 함께 지원되는 3개 언어 중 하나일 뿐이었습니다.

하지만 넷스케이프는 Microsoft와는 다르게 LiveWire의 핵심인 서버 측 Javascript에 올인하였습니다.

여기서 잠깐, Livewire에 대해 알아봅시다.

Node.js는 Non-blocking I/O와 단일 스레드 이벤트 루프를 기반으로 하고 있다는 사실은 모두 알고 있을 것입니다.

LiveWire의 모습은 이와는 많이 달랐습니다. 넷스케이프의 서버측 JS구현은 다목적 런타임이라기 보다는, HTML 전처리기에 가깝고 일부분에서는 오히려 초기 PHP와 다르지 않습니다.

JS의 서버측 구현을 위해 LiveWire에서는 <server> 태그를 사용하였습니다. <server> 태그는 HTML파일이 클라이언트로 전송되기 전에 HTML의 어디에 전처리가 필요한 JS 로직이 포함되어 있는지 결정하는 데에 사용되었습니다. LiveWire에는 컴파일 단계또한 필요했습니다.

넷스케이프의 런타임은 다중 스레드였으며, 주어진 응용 프로그램의 스레드 간에 자원을 공유할 수 있었습니다. 이러한 공유 자원은 모든 스레드에서 액세스하고 수정할 수 있어 상태를 쉽게 공유할 수 있지만, 아래와 같이 중요한 위험이 따랐습니다.

토막 운영체제 지식 : 멀티스레드의 공유자원 문제

Race Condition - 하나의 자원에 둘 이상의 쓰레드로부터 조작이 동시에 일어나 의도하지 않은 결과를 가져옴
(example)

Priority Inversion - QoS가 낮은 쓰레드가 공유 자원을 선점하고 있을 때 QoS가 더 높은 쓰레드가 공유자원을 사용하고자 하면 QoS가 더 높아도 대기가 발생하여 우선순위의 역전이 일어난다.

DeadLock - 자원 A, B가 있을 때 쓰레드A, 쓰레드B가 각각 A,B를 선점하고 있는 상태에서 쓰레드A는 B를, 쓰레드B는 A를 사용하고자 한다면 자원 A,B는 이미 선점당하고 있어서 무한정 기다리는 상태가 발생한다.

Starvation - 여러 프로세스가 부족한 자원을 점유하기 위해 경쟁할 때, 특정 프로세스는 우선 순위가 낮아 영원히 자원을 할당받을 수 없는 경우가 발생한다.

이를 예방하기 위해 Locking 메커니즘을 사용할 수 있었지만 자동으로 적용되지는 않았습니다.

LiveWire 실패의 원인은 아래와 같이 추측되고 있습니다.

HTML 콘텐츠를 포함하여 모든 것을 컴파일하고 번들해야 하기 때문에 번거로운 개발자 경험을 제공했습니다. 이와 다르게 Microsoft의 ASP는 컴파일 단계가 필요하지 않았습니다.

Javascript는 당시에 성숙하지 못한 언어였습니다. 사용자들을 끌어들이기 위해 스스로의 장점을 증명해야 했고, 개발자들이 라이브러리를 사용할 수 있을 만큼 인기를 얻지도 못했습니다.

넷스케이프는 경쟁자만큼 많은 투자를 하지 않았으며, LiveWire는 기능 면에서 빠르게 뒤쳐졌습니다.

그 후 LiveWire가 속했던 "Netscape Enterprise Server" 는 여러번 이름이 바뀌었고, 다른 기술과 병합되었습니다. 엔터프라이즈급 소프트웨어는 장기 지원을 의미합니다. Oracle의 웹 사이트에서 우리는 여전히 LiveWire의 설명서를 찾을 수 있습니다.

불행하게도 LiveWire은 그다지 성공하지 못했고, 서버 측 JS는 Node.js 도입 이전까지, 어쩌면 최근까지도 대중화되지 않았습니다.

Node.js의 탄생

Node.js 어쩌다 탄생하게 되었을까요? 그리고 어떻게 각광받게 되었을까요?

Node.js는 Ryan Dahl이 만들었습니다. 그는 Ruby 웹 서버로 파일을 업로드 할 때 웹 페이지에서 업로드 진행률을 업데이트하는 푸시 기능에 대해 고민하다 Node.js에 대한 영감을 떠올렸습니다. 그가 Javascript를 채택한 이유에 대해 알기 위해서는 JS의 인기 상승에 대한 이해가 필요합니다.

2005년 Google Maps의 등장으로 웹 애플리케이션 언어로서 Javascript의 가능성이 확인되었습니다.

그래서 JS로 웹 애플리케이션을 구축하려는 시도와 활용이 많아졌고, 동시에 빠르게 동작하는 자바스크립트 엔진에 대한 요구 또한 늘었습니다.

이때 많은 브라우저가 사용자에게 최고의 성능을 제공하기 위해 경쟁하였는데, 2008년 9월 구글이 발표한 크롬의 베타버전, 여기에 탑재된 C++ 기반의 오픈소스화된 V8 JS엔진은 어떤 자바스크립트 엔진보다도 빠른 속도를 보였습니다. 또 이러한 경쟁과 함께 V8 엔진의 성능은 크게 향상되었습니다.

JS 엔진이 강력해지자 2009년 1월부터 자바스크립트를 웹 브라우저가 아닌 곳에서 사용할 수 있도록 표준을 만들자는 의견이 많아졌고, 이후 CommonJS 표준이 발표되었습니다.

이러한 흐름에 힘입어 Ryan Dahl은 이벤트 구동 서버에 대한 지식과 CommonJS 표준, V8엔진을 이용하여 non-blocking, evnet-driven I/O 패러다임에서 작업할 수 있는 Node.js를 만들었습니다.

Node.js는 이렇듯 우연히 적절한 장소와 시기에 구축되어 인기를 얻었습니다. 하지만 여전히 인기있는 이유는 '운'만은 아닙니다.