Node.js: 두 판 사이의 차이
편집 요약 없음 |
편집 요약 없음 |
||
3번째 줄: | 3번째 줄: | ||
이전까지 자바스크립트는 프론트엔드, 즉 웹 브라우저 쪽에서 구동되는 프로그래밍 언어로 주로 웹 페이지에 동적인 효과를 주기 위해서 많이 쓰였다. Ajax 덕분에 활용 폭이 넓어졌지만 그래도 프론트엔드로 한정되어 있다는 게 널리 퍼진 인식이었는데, NodeJS가 인기를 얻으면서 백엔드, 즉 웹 서버 프로그래밍에도 자바스크립트가 폭발적으로 늘어나는 계기가 되었다. [[자바스크립트]] 기반으로 웹 서버를 만들려는 시도는 그 전에도 있었지만 제대로 인기를 얻은 것은 NodeJS다. 이를 통해서 [[자바스크립트]] 프로그래머들도 웹 서버 프로그래밍을 할 수 있게 되었고, 특히 개발자가 혼자 또는 소수인 스타트업은 프론트엔드와 백엔드 프로그래머를 따로 두지 않아도 되는 엄청난 이점을 얻게 되었다. <del>이로써 [[자바스크립트]] 개발자들은 더더욱 가혹한 야근에 시달리게 되었다 카더라.</del> | 이전까지 자바스크립트는 프론트엔드, 즉 웹 브라우저 쪽에서 구동되는 프로그래밍 언어로 주로 웹 페이지에 동적인 효과를 주기 위해서 많이 쓰였다. Ajax 덕분에 활용 폭이 넓어졌지만 그래도 프론트엔드로 한정되어 있다는 게 널리 퍼진 인식이었는데, NodeJS가 인기를 얻으면서 백엔드, 즉 웹 서버 프로그래밍에도 자바스크립트가 폭발적으로 늘어나는 계기가 되었다. [[자바스크립트]] 기반으로 웹 서버를 만들려는 시도는 그 전에도 있었지만 제대로 인기를 얻은 것은 NodeJS다. 이를 통해서 [[자바스크립트]] 프로그래머들도 웹 서버 프로그래밍을 할 수 있게 되었고, 특히 개발자가 혼자 또는 소수인 스타트업은 프론트엔드와 백엔드 프로그래머를 따로 두지 않아도 되는 엄청난 이점을 얻게 되었다. <del>이로써 [[자바스크립트]] 개발자들은 더더욱 가혹한 야근에 시달리게 되었다 카더라.</del> | ||
NodeJS가 가진 가장 큰 장점을 꼽으라면 빠른 처리 속도다. [[아파치]]나 [[JBoss]]와 같은 서버들은 [[멀티스레드]] 혹은 [[멀티프로세스]] 기반이다. 즉, 연결 요청마다 [[프로세스]]나 스레드를 하나씩 배정한다. 반면 NodeJS는 스레드가 딱 하나 뿐이고, 이 한 개의 스레드에서 모든 요청을 처리한다. 단, 모든 요청은 비동기 방식으로 처리된다. 무슨 말인고 하니, 기존의 방식은 사용자 A가 서버에 접속해서[[ 데이터베이스]]에 있는 데이터를 요청했을 때, 서버가 [[데이터베이스]]에 자료를 요청하고 응답이 올 때까지 기다린다. 반면 비동기 방식은 서버가 [[데이터베이스]]에 자료를 요청하고 나서 기다리지 않고 다음 명령으로 넘어간다. 자료를 요청할 때, '자료가 들어오면 이 함수를 실행시키라'고 콜백함수를 넘겨주므로, [[데이터베이스]]에서 응답이 오면 콜백함수가 실행된다. 이런 식으로 [[싱글스레드]]지만 몰려드는 요청을 지연 없이 빠르게 처리한다. 마치 예전에 반쪽짜리 멀티태스킹이었던 윈도우 3의 프로그램과 비슷한 방식이다. 이게 왜 빠르지? 할 수 있겠지만 프로세스나 스레드가 하나 생길 때마다 그만큼의 시스템 자원 소모가 발생하고, 여러 프로세스가 스레드를 | NodeJS가 가진 가장 큰 장점을 꼽으라면 빠른 처리 속도다. [[아파치]]나 [[JBoss]]와 같은 서버들은 [[멀티스레드]] 혹은 [[멀티프로세스]] 기반이다. 즉, 연결 요청마다 [[프로세스]]나 스레드를 하나씩 배정한다. 반면 NodeJS는 스레드가 딱 하나 뿐이고, 이 한 개의 스레드에서 모든 요청을 처리한다. 단, 모든 요청은 비동기 방식으로 처리된다. 무슨 말인고 하니, 기존의 방식은 사용자 A가 서버에 접속해서[[ 데이터베이스]]에 있는 데이터를 요청했을 때, 서버가 [[데이터베이스]]에 자료를 요청하고 응답이 올 때까지 기다린다. 반면 비동기 방식은 서버가 [[데이터베이스]]에 자료를 요청하고 나서 기다리지 않고 다음 명령으로 넘어간다. 자료를 요청할 때, '자료가 들어오면 이 함수를 실행시키라'고 콜백함수를 넘겨주므로, [[데이터베이스]]에서 응답이 오면 콜백함수가 실행된다. 이런 식으로 [[싱글스레드]]지만 몰려드는 요청을 지연 없이 빠르게 처리한다. 마치 예전에 반쪽짜리 멀티태스킹이었던 윈도우 3의 프로그램과 비슷한 방식이다. 이게 왜 빠르지? 할 수 있겠지만 프로세스나 스레드가 하나 생길 때마다 그만큼의 시스템 자원 소모가 발생하고, 여러 프로세스가 스레드를 관리하고 자원을 배분<del>이라기 보다는 줬다 뺐었다</del> 하는 것 역시도 시스템 자원이 들어간다. 싱글스레드 기반에서는 이러한 자원 소모가 최소화되므로 상대적으로 시스템의 자원을 최대한 웹 서버 쪽으로 돌릴 수 있다. | ||
가장 큰 문제는 에러가 생겼을 때 웹 서버가 통째로 죽어버리기 쉽다는 것이다. 멀티프로세스인 경우 프로세스 하나에서 오류가 터져도 그 프로세스만 정리하면 되지만 NodeJS는 싱글스레드이므로 연결 중 하나에서 오류가 터지면 웹 서버가 싹 죽어버리는 것. | 가장 큰 문제는 에러가 생겼을 때 웹 서버가 통째로 죽어버리기 쉽다는 것이다. 멀티프로세스인 경우 프로세스 하나에서 오류가 터져도 그 프로세스만 정리하면 되지만 NodeJS는 싱글스레드이므로 연결 중 하나에서 오류가 터지면 웹 서버가 싹 죽어버리는 것. 또한 프로그래밍이 까다롭다. 멀티프로세스인 경우에는 각각의 프로세스는 자기 혼자 돌아가는 것처럼 생각하고 프로그래밍 되어도 웹 서버가 알아서 관리해 주지만 NodeJS는 신경써야 할 게 많다. 멀티프로세스 하듯이 했다가는 한 연결이 [[CPU]]를 차지하고 앉아서 다른 연결이 먹통이 되는 일이 생기기 쉽다. 이러다 보면 [[자바스크립트]]의 특징과 엮여서 코드도 알아보기도 힘들고 디버그도 오리무중이 되기 쉽다. | ||
npm 패키지 관리자는 NodeJS에 어마어마한 날개를 달아주게 되는데, 중앙집중식 패키지 저장소에서 원하는 모듈을 손쉽게 검색하고 설치할 수 있기 때문에 NodeJS의 활용 폭을 어마어마하게 넓혀 주었다. 다른 프로그래밍 언어도 없는 건 아니지만 패키지의 수나 성장속도가 정말 어마어마하게 빨라서 '혹시 이런 모듈 없나?' 하고 검색하면 우루루 쏟아져 나올 정도다. | npm 패키지 관리자는 NodeJS에 어마어마한 날개를 달아주게 되는데, 중앙집중식 패키지 저장소에서 원하는 모듈을 손쉽게 검색하고 설치할 수 있기 때문에 NodeJS의 활용 폭을 어마어마하게 넓혀 주었다. 다른 프로그래밍 언어도 없는 건 아니지만 패키지의 수나 성장속도가 정말 어마어마하게 빨라서 '혹시 이런 모듈 없나?' 하고 검색하면 우루루 쏟아져 나올 정도다. | ||
최근에는 NodeJS에 가장 인기 있는 웹 프레임워크인 [[ExpressJS]], 여기에 [[자바스크립트]] 기반 [[NoSQL]] [[데이터베이스]] 서버인 [[몽고DB]], 그리고 [[구글]]이 만든 [[MVC]] 방식 클라이언트 측 [[자바스크립트]] 프레임워크인 [[앵귤러JS]]를 묶어서 [[MEAN 스택]]이라는 [[자바스크립트]] 풀 스택 플랫폼 개념이 구축되고 있고 인기 급 상승 중이다. [[자바스크립트]] 언어 하나로 프론트엔드-백엔드-[[데이터베이스]]까지 퉁쳐버리는 것이다. 자세한 내용은 해당 항목 참조. | 최근에는 NodeJS에 가장 인기 있는 웹 프레임워크인 [[ExpressJS]], 여기에 [[자바스크립트]] 기반 [[NoSQL]] [[데이터베이스]] 서버인 [[몽고DB]], 그리고 [[구글]]이 만든 [[MVC]] 방식 클라이언트 측 [[자바스크립트]] 프레임워크인 [[앵귤러JS]]를 묶어서 [[MEAN 스택]]이라는 [[자바스크립트]] 풀 스택 플랫폼 개념이 구축되고 있고 인기 급 상승 중이다. [[자바스크립트]] 언어 하나로 프론트엔드-백엔드-[[데이터베이스]]까지 퉁쳐버리는 것이다. 자세한 내용은 해당 항목 참조. |
2016년 1월 7일 (목) 12:06 판
자바스크립트를 기반으로 하는 웹 서버. 구글 크롬의 자바스크립트 엔진인 V8을 기반으로 하고 있으며, 싱글스레드에 비동기 방식을 기반으로 하고 있다.
이전까지 자바스크립트는 프론트엔드, 즉 웹 브라우저 쪽에서 구동되는 프로그래밍 언어로 주로 웹 페이지에 동적인 효과를 주기 위해서 많이 쓰였다. Ajax 덕분에 활용 폭이 넓어졌지만 그래도 프론트엔드로 한정되어 있다는 게 널리 퍼진 인식이었는데, NodeJS가 인기를 얻으면서 백엔드, 즉 웹 서버 프로그래밍에도 자바스크립트가 폭발적으로 늘어나는 계기가 되었다. 자바스크립트 기반으로 웹 서버를 만들려는 시도는 그 전에도 있었지만 제대로 인기를 얻은 것은 NodeJS다. 이를 통해서 자바스크립트 프로그래머들도 웹 서버 프로그래밍을 할 수 있게 되었고, 특히 개발자가 혼자 또는 소수인 스타트업은 프론트엔드와 백엔드 프로그래머를 따로 두지 않아도 되는 엄청난 이점을 얻게 되었다. 이로써 자바스크립트 개발자들은 더더욱 가혹한 야근에 시달리게 되었다 카더라.
NodeJS가 가진 가장 큰 장점을 꼽으라면 빠른 처리 속도다. 아파치나 JBoss와 같은 서버들은 멀티스레드 혹은 멀티프로세스 기반이다. 즉, 연결 요청마다 프로세스나 스레드를 하나씩 배정한다. 반면 NodeJS는 스레드가 딱 하나 뿐이고, 이 한 개의 스레드에서 모든 요청을 처리한다. 단, 모든 요청은 비동기 방식으로 처리된다. 무슨 말인고 하니, 기존의 방식은 사용자 A가 서버에 접속해서데이터베이스에 있는 데이터를 요청했을 때, 서버가 데이터베이스에 자료를 요청하고 응답이 올 때까지 기다린다. 반면 비동기 방식은 서버가 데이터베이스에 자료를 요청하고 나서 기다리지 않고 다음 명령으로 넘어간다. 자료를 요청할 때, '자료가 들어오면 이 함수를 실행시키라'고 콜백함수를 넘겨주므로, 데이터베이스에서 응답이 오면 콜백함수가 실행된다. 이런 식으로 싱글스레드지만 몰려드는 요청을 지연 없이 빠르게 처리한다. 마치 예전에 반쪽짜리 멀티태스킹이었던 윈도우 3의 프로그램과 비슷한 방식이다. 이게 왜 빠르지? 할 수 있겠지만 프로세스나 스레드가 하나 생길 때마다 그만큼의 시스템 자원 소모가 발생하고, 여러 프로세스가 스레드를 관리하고 자원을 배분이라기 보다는 줬다 뺐었다 하는 것 역시도 시스템 자원이 들어간다. 싱글스레드 기반에서는 이러한 자원 소모가 최소화되므로 상대적으로 시스템의 자원을 최대한 웹 서버 쪽으로 돌릴 수 있다.
가장 큰 문제는 에러가 생겼을 때 웹 서버가 통째로 죽어버리기 쉽다는 것이다. 멀티프로세스인 경우 프로세스 하나에서 오류가 터져도 그 프로세스만 정리하면 되지만 NodeJS는 싱글스레드이므로 연결 중 하나에서 오류가 터지면 웹 서버가 싹 죽어버리는 것. 또한 프로그래밍이 까다롭다. 멀티프로세스인 경우에는 각각의 프로세스는 자기 혼자 돌아가는 것처럼 생각하고 프로그래밍 되어도 웹 서버가 알아서 관리해 주지만 NodeJS는 신경써야 할 게 많다. 멀티프로세스 하듯이 했다가는 한 연결이 CPU를 차지하고 앉아서 다른 연결이 먹통이 되는 일이 생기기 쉽다. 이러다 보면 자바스크립트의 특징과 엮여서 코드도 알아보기도 힘들고 디버그도 오리무중이 되기 쉽다.
npm 패키지 관리자는 NodeJS에 어마어마한 날개를 달아주게 되는데, 중앙집중식 패키지 저장소에서 원하는 모듈을 손쉽게 검색하고 설치할 수 있기 때문에 NodeJS의 활용 폭을 어마어마하게 넓혀 주었다. 다른 프로그래밍 언어도 없는 건 아니지만 패키지의 수나 성장속도가 정말 어마어마하게 빨라서 '혹시 이런 모듈 없나?' 하고 검색하면 우루루 쏟아져 나올 정도다.
최근에는 NodeJS에 가장 인기 있는 웹 프레임워크인 ExpressJS, 여기에 자바스크립트 기반 NoSQL 데이터베이스 서버인 몽고DB, 그리고 구글이 만든 MVC 방식 클라이언트 측 자바스크립트 프레임워크인 앵귤러JS를 묶어서 MEAN 스택이라는 자바스크립트 풀 스택 플랫폼 개념이 구축되고 있고 인기 급 상승 중이다. 자바스크립트 언어 하나로 프론트엔드-백엔드-데이터베이스까지 퉁쳐버리는 것이다. 자세한 내용은 해당 항목 참조.