Node.js 탄생 비화, 자바스크립트가 서버를 삼킨 날

 

Node.js는 브라우저 안에서만 돌던 자바스크립트를 서버로 끌어낸 런타임입니다. 2009년에 등장한 이 도구 하나가 이후 십수 년간 웹 개발의 판을 바꿔 놨는데요. 오늘은 그 탄생 비화를, 당시 업계에서 자바스크립트가 어떤 취급을 받았는지부터 되짚어 보려 합니다.

 

 

"자바스크립트로 서버를 짠다고요? 그게 됩니까?"
"Node.js는 대체 왜 만든 거예요?"
"이벤트 루프가 정확히 뭐길래 다들 얘기하나요?"
"어쩌다 프론트 개발자들이 백엔드까지 넘어오게 된 거죠?"

 

 

저는 2012년에 웹 개발을 시작했습니다. 그때 제 머릿속에서 자바스크립트는 화면 좀 움직이고 폼 검사나 하는 보조 도구였어요. 서버는 자바나 PHP가 하는 거고요. 그런데 몇 년 지나지 않아 "서버도 자바스크립트로 짠다"는 얘기가 현장에 들려오기 시작했고, 솔직히 처음엔 잘 믿기지 않았습니다.

이 글은 Node.js가 왜, 어떻게 태어났는지 그 배경과 기술적 맥락을 정리한 글입니다. 개발 입문자, 그리고 "다들 쓰니까 쓰긴 하는데 시작이 궁금했던" 분들께 도움이 될 것 같습니다.

목차

1. 2012년, 자바스크립트는 '거드는' 언어였다
2. C10K 문제, 서버가 만 명 앞에서 멈추던 시절
3. 자바스크립트가 서버에서 외면받던 진짜 이유
4. 시작은 업로드 진행바 하나였습니다
5. 브라우저 밖으로 나온 V8 엔진
6. 이벤트 루프와 논블로킹 I/O, 발상의 전환
7. 2009년 JSConf EU, 기립박수를 부른 데모
8. 한 언어로 프론트와 백을 (풀스택의 시작)
9. 그 뒤의 Node.js와 라이언 달의 후회
10. 자주 묻는 질문

1. 2012년, 자바스크립트는 '거드는' 언어였다

제가 신입이던 2012년 무렵, 실무에서 자바스크립트가 하는 일은 대개 정해져 있었습니다. 버튼 누르면 팝업 띄우고, 폼 제출 전에 빈칸 있나 확인하고, jQuery로 화면 요소 몇 개 움직이는 정도요. 무거운 로직은 전부 서버 몫이었고, 그 서버는 자바나 PHP, 파이썬이 담당했습니다.

그래서 당시 개발자들 사이에서 자바스크립트의 위상은 애매했습니다. 없으면 안 되긴 하는데, 그렇다고 이걸로 뭔가 큰 걸 만든다는 생각은 아무도 안 했거든요. 저도 그랬습니다. 자바스크립트 잘한다고 이력서에 크게 쓰는 분위기도 아니었고요.

그런데 이 "거드는 언어"가 몇 년 뒤 서버까지 넘어와 판을 흔들게 됩니다. 그 시작을 이해하려면, 먼저 2000년대 후반 서버들이 어떤 병에 걸려 있었는지부터 봐야 합니다.

2. C10K 문제, 서버가 만 명 앞에서 멈추던 시절

2000년대 후반 웹 서버가 안고 있던 대표적인 고민이 이른바 C10K 문제였습니다. 1999년 댄 케겔(Dan Kegel)이 정리한 표현인데, 이름 그대로 "동시 접속 1만 개를 한 대의 서버가 감당할 수 있는가"라는 물음이었어요.

당시 주류였던 아파치(Apache) 서버는 요청이 들어올 때마다 스레드나 프로세스를 하나씩 새로 만들어 붙이는 방식으로 동작했습니다. 요청 하나에 일꾼 하나를 배정하는 셈이죠. 접속이 적을 땐 문제가 없습니다. 그런데 이 방식엔 함정이 있었어요.

 

 

📌 블로킹(Blocking)이라는 함정

일꾼(스레드) 하나가 데이터베이스 조회나 파일 읽기를 시작하면,

그 작업이 끝날 때까지 그냥 멍하니 기다립니다.

그동안 아무 일도 못 해요. 접속이 수만 개로 늘면

서버는 기다리는 일꾼을 계속 만들어내다가 메모리가 바닥나 버립니다.

 

 

정리하면, 그 시절 서버는 사람을 많이 붙일수록 오히려 자기 무게에 눌려 느려지는 구조였습니다. 트래픽이 커질수록 하드웨어를 계속 늘려야 했고요. 이걸 근본에서 다르게 풀 수 없을까 하는 고민이, 뒤에 이야기할 Node.js의 씨앗이 됩니다.

3. 자바스크립트가 서버에서 외면받던 진짜 이유

그렇다고 해서 그 시절 누군가 "그럼 자바스크립트로 서버를 짜자"고 했다면, 아마 웃음거리가 됐을 겁니다. 이유가 분명했어요.

우선 자바스크립트는 애초에 브라우저 안에서 돌라고 만든 언어였습니다. 파일 시스템에 접근하거나, 소켓을 열어 네트워크 통신을 직접 제어하는 기능이 언어 차원에 아예 없었어요. 서버가 하는 기본적인 일들을 할 도구 자체가 없던 거죠. 실행 속도도 그때는 느린 편이었습니다.

그래서 서버 로직은 자바, PHP, 파이썬 같은 "묵직한" 언어들의 몫이었고, 자바스크립트는 그 바깥에서 화면이나 거드는 조연에 머물렀습니다. 여기까지만 보면 자바스크립트가 서버로 갈 길은 없어 보입니다. 그런데 바로 이 "아무것도 없다"는 점이, 조금 뒤에 오히려 강점으로 뒤집힙니다.

4. 시작은 업로드 진행바 하나였습니다

Node.js를 만든 사람은 미국의 개발자 라이언 달(Ryan Dahl)입니다. 그가 이 고민에 빠진 계기는 거창하지 않았어요. 파일 업로드가 얼마나 진행됐는지 보여주는 진행바, 그 흔한 기능 하나를 제대로 구현하려다 벽에 부딪힌 겁니다.

당시 그가 쓰던 환경에서는 업로드 상태를 확인하려고 클라이언트가 서버에 계속 물어보는 방식(폴링)을 써야 했는데, 요청 처리 구조가 한 번에 하나씩 붙잡고 늘어지는 방식이다 보니 이런 실시간 상태 표시가 지독히 비효율적이었습니다. 진행바 하나 그리자고 서버 자원을 잔뜩 낭비하는 상황이었죠.

 

 

💡 사소한 불편이 출발점이 되는 것

돌이켜보면 제 경험에서도 큰 도구는 대단한 목표보다

"이거 왜 이렇게 불편하지?" 하는

작은 짜증에서 시작되는 경우가 많았습니다.

달의 진행바도 딱 그런 경우였습니다.

 

 

여기서 달의 선택이 흥미롭습니다. 그는 새 플랫폼의 언어로 자바스크립트를 골랐는데, 자바스크립트를 특별히 좋아해서가 아니었습니다. 오히려 파일 처리나 네트워크 관련 관행이 아직 정해지지 않은 "백지 상태"라는 점을 봤어요. 규칙이 없으니 잘못 굳어진 관행도 없다, 그러니 처음부터 비동기 방식으로 깔끔하게 설계할 수 있다는 계산이었습니다. 2009년 1월, 그렇게 작업이 시작됩니다.

5. 브라우저 밖으로 나온 V8 엔진

달의 구상을 실제로 굴러가게 만든 부품은 구글의 V8 자바스크립트 엔진이었습니다. V8은 2008년 9월 2일 크롬 브라우저와 함께 오픈소스로 공개됐는데, 개발은 덴마크의 라스 박(Lars Bak)이 이끌었습니다. 그는 이전에 자바의 HotSpot 가상머신을 설계한 사람이기도 해서, V8에도 그 노하우가 녹아 있었어요.

V8의 핵심은 속도였습니다. 코드를 한 줄씩 해석하며 실행하는 기존 방식 대신, 실행 직전에 기계어로 컴파일(JIT)해 버리는 방식을 썼거든요. 덕분에 그동안 느리다고 무시받던 자바스크립트가 갑자기 꽤 빠른 언어가 됐습니다.

달은 이 엔진을 브라우저에서 떼어냈습니다. 그리고 브라우저에는 없던 파일 시스템 접근, 네트워크 통신 같은 서버용 기능을 C++로 붙였어요. 자바스크립트를 실행할 빠른 엔진에, 서버가 필요로 하는 손발을 달아준 셈입니다. 이게 Node.js의 뼈대가 됩니다.

6. 이벤트 루프와 논블로킹 I/O, 발상의 전환

Node.js의 핵심 아이디어는 앞서 본 블로킹 문제를 정반대로 뒤집은 데 있습니다. 요청마다 일꾼을 새로 붙이는 대신, 한 명의 일꾼이 쉬지 않고 돌아가게 만든 거예요. 이 방식을 단일 스레드 이벤트 루프와 논블로킹 I/O라고 부릅니다.

비유하자면 이렇습니다. 기존 방식이 손님 한 명당 종업원 한 명을 붙여 주문받고 요리 나올 때까지 옆에 세워 두는 식당이라면, Node.js는 종업원 한 명이 여러 테이블의 주문을 받아 주방에 넘겨 두고, 요리가 완성됐다는 신호가 오면 그때 가져다주는 식당입니다. 기다리는 시간에 놀지 않고 다음 주문을 받으니, 적은 인력으로 많은 손님을 감당할 수 있죠.

반응형

구분	기존 동기식(블로킹) 서버	Node.js 이벤트 루프
요청 처리	요청마다 스레드를 새로 생성	한 스레드가 여러 요청을 번갈아 처리
대기 시간	DB·파일 작업 동안 그냥 멈춰서 대기	대기 대신 다음 작업을 먼저 진행
동시 접속	늘수록 메모리 부담 급증	적은 자원으로 많은 연결 유지
약점	트래픽 증가에 하드웨어로 대응	무거운 CPU 연산 작업엔 불리

물론 이 방식이 만능은 아닙니다. 무거운 계산을 오래 붙잡고 있어야 하는 작업에서는 그 한 명의 일꾼이 막혀 버리니까요. 하지만 웹 서버가 실제로 하는 일 대부분은 DB 조회하고 파일 읽고 응답 내보내는, 기다림이 많은 작업입니다. 바로 그 지점에서 Node.js가 강했습니다.

7. 2009년 JSConf EU, 기립박수를 부른 데모

Node.js가 세상에 처음 모습을 드러낸 건 2009년 11월 8일, 베를린에서 열린 자바스크립트 컨퍼런스 JSConf EU 무대였습니다. 달은 약 150명의 개발자 앞에서 자신의 프로젝트를 라이브로 시연했어요. 사실 그에게는 이 발표가 절박했습니다. 후원을 못 구하면 거의 1년 가까이 매달린 작업을 접어야 할 상황이었거든요.

발표는 성공했습니다. 기존 서버들이 쩔쩔매던 다수의 동시 연결을, 단일 스레드 비동기 방식으로 매끄럽게 처리하는 모습을 실시간으로 보여줬거든요. 발표가 끝나자 청중이 일어나 박수를 보냈고, 그 컨퍼런스에서 나온 첫 기립박수였다고 전해집니다.

이후 Node.js는 코드 공유 사이트 깃허브(GitHub)를 타고 빠르게 퍼졌습니다. 발표 시점에 수십 명 남짓이던 사용자가 몇 달 만에 수만 명으로 불어났다고 하니, 개발자 커뮤니티가 이걸 얼마나 목말라했는지 짐작이 갑니다.

8. 한 언어로 프론트와 백을 (풀스택의 시작)

Node.js가 남긴 가장 큰 변화는 성능만이 아니었습니다. 저는 오히려 이쪽이 더 컸다고 봅니다. 바로 프론트엔드와 백엔드를 같은 언어로 짤 수 있게 됐다는 점이요.

그 전까지 웹 개발자는 화면은 자바스크립트로, 서버는 자바나 PHP로, 머릿속에서 두 개의 언어를 오가야 했습니다. 그런데 서버까지 자바스크립트로 짜게 되니 언어의 벽이 사라진 겁니다. 화면을 만지던 프론트 개발자가 큰 부담 없이 서버 영역으로 넘어올 수 있는 길이 열렸어요.

이 흐름을 타고 "한 사람이 프로젝트 전체를 아우른다"는 풀스택(Full-Stack) 개발자라는 말이 널리 자리 잡았습니다. 스타트업 입장에서는 언어 하나로 앞뒤를 다 커버할 인력을 뽑을 수 있으니 매력적이었고요. 앞서 제가 "믿기지 않았다"고 했던 그 변화가, 이 무렵 실제 채용 공고와 프로젝트 구성에서 눈에 보이기 시작했습니다.

9. 그 뒤의 Node.js와 라이언 달의 후회

여기까지만 보면 완결된 성공담 같지만, 뒷이야기가 하나 더 있습니다. 정작 이걸 만든 달 본인이 나중에 아쉬움을 공개적으로 털어놓았거든요.

2018년, 그는 같은 JSConf EU 무대에 다시 올라 "Node.js에서 후회하는 열 가지"라는 제목으로 발표를 했습니다. 패키지 관리 방식이 지나치게 중앙집중적이라 보안에 취약해진 점, 설치한 코드가 사실상 시스템 전체에 접근할 수 있는 구조 등을 스스로 짚었어요. 그러면서 이런 문제를 처음부터 다시 설계한 새 런타임 Deno(디노)를 함께 선보였습니다.

그렇다고 Node.js가 저문 건 아닙니다. 2026년 지금도 수많은 서비스가 Node.js 위에서 돌아가고, 링크드인·페이팔·우버 같은 기업들이 도입 사례로 자주 언급됩니다. 다만 만든 사람조차 "다시 하면 이렇게 안 했을 것"이라고 말한다는 점은 기억해 둘 만합니다. 지금 표준처럼 보이는 도구도 특정 시대의 선택이었고, 시간이 지나면 다른 답이 나온다는 뜻이니까요.

10. 자주 묻는 질문

Node.js는 프로그래밍 언어인가요?

아닙니다. Node.js는 자바스크립트를 브라우저 밖에서 실행하게 해 주는 런타임 환경입니다. 언어는 어디까지나 자바스크립트고, Node.js는 그 자바스크립트를 서버에서 돌릴 수 있게 해 주는 실행 무대라고 보시면 됩니다.

Node.js는 지금도 배울 가치가 있나요?

제 개인적인 생각으로는 그렇습니다. 여전히 널리 쓰이고 자료도 많아서 처음 서버를 다뤄 보기에 무난한 편입니다. 다만 무거운 연산이 많은 서비스라면 다른 선택지도 함께 검토하시는 걸 권합니다. 상황에 따라 답이 다르니까요.

이벤트 루프가 한 줄로 뭐죠?

한 명의 일꾼이 여러 작업을 기다리지 않고 번갈아 처리하도록 돌리는 구조입니다. 대기 시간에 놀지 않는다는 게 핵심입니다.

마무리

Node.js의 이야기를 한 줄로 줄이면, 브라우저에 갇혀 화면이나 거들던 자바스크립트가 서버까지 넘어온 과정입니다. 그 뒤엔 C10K라는 시대의 골칫거리, 마침 등장한 빠른 V8 엔진, 그리고 업로드 진행바 하나에서 출발한 한 개발자의 고집이 있었습니다.

재미있는 건, 그 큰 변화가 "이거 왜 이렇게 불편하지"라는 작은 짜증에서 시작됐다는 점입니다. 저는 개발하면서 이런 순서를 꽤 자주 봤습니다. 지금 당연하게 쓰는 도구도 결국은 누군가의 불편에서 나왔고, 만든 사람조차 뒤에 가서는 다르게 봤다는 것. 그 사실이 오히려 이 기술을 더 사람 냄새 나게 만든다고 저는 생각합니다.

📚 함께 보면 좋은 글

PHP는 원래 개인 홈페이지 도구였다 — 언어가 될 생각이 없던 코드가 웹을 먹은 이야기

HTML 역사, 누가 왜 만들었을까 (태그 18개의 시작)

프론트엔드 3대장 비교 - 리액트 뷰 앵귤러 탄생 이유와 장단점 (2026)

타입스크립트는 왜 만들어졌을까 - 자바스크립트가 커지자 마이크로소프트가 내놓은 답

자바와 자바스크립트 차이는? 10일 만에 만들어진 자바스크립트 역사 이야기