최근 포토로그


Node.js의 소개글 들에 대한 유감 복잡한컴퓨터이야기

Node.js의 소개글 들에 대한 유감

최근 javascript를 이용한 web application 개발의 새로운 방법으로 유행처럼 번지고 있는 node.js를 다루고 있는 많은 글들을 보게 된다.

대부분의 글과 문서, 책 등을 살펴보면 node.js의 우수성을 알리기 위해서 아파치 웹 서버에 비해 더욱더 높은 성능을 가지고 있으며 메모리 사용량도 적을 뿐만 아니라, 사용자가 아무리 늘어도 메모리 사용량이 거의 일정하다고 그래프를 그려가면서 힘 주어 이야기 한다.

이러한 장점을 가져오는 node.js만의 특징으로 다음과 같이 3가지를 이야기 하고 있다.

 

1.     Event loop

2.     단일 Thread

3.     Async. I/O

 

더 나아가서는 이러한 방식의 도입이 획기적 일뿐만 아니라 혁신적이기까지 하다고 한다.

약간 심하게 말하면 형편없고 터무니 없다. 개인적인 경험으로는 20년 전의 Windows 3 Programming을 처음 시작했을 때, Message Loop, 단일 Thread에 의한 비선전형 Multitasking을 이야기하였고, 단일 메시지를 처리할 때 너무 많은 시간을 소비하면 안되기 때문에 비동기 I/O는 계속적인 관심 대상일 수 밖에 없었다. 그런데 갑자기 이러한 기능이 획기적이고 혁신의 반열에 까지 들어서게 된 것은 웬일이란 말인가?

이러한 황당함은 모 개그 프로그램처럼 70년대 생 이상만 공감할 수 있는 개그인가?

 

Event Loop은 수십년간 이미 잘 알려진 기법이고 GUI를 이용하는 OS의 경우 대부분 내부적으로 이 방법을 사용하고 있으므로 별다를 것이 없다.

 

Network Application에서 단일 Thread를 이용해서 Client Request를 순차적으로 처리하는 방법과 Request별로 Thread를 생성해서 처리하는 방법, 일정 수의 Thread를 생성하여 Thread Pooling을 수행하는 방법 등은 이미 수십 년 전부터 그 각각의 특징이 분석되고 그 장단점이 충분히 논의 되어 왔다. 게다가 지금과 같이 Multi Processor, Multi Core CPU를 사용하는 경우, 단일 Thread만일 이용하면 충분히 Processor, Core의 능력을 사용하지 못한다.(Node.js Cluster따위는 말할 필요도 없다.)

 

비 동기 I/O는 작업을 시키는 입장에서는 그 작업에 대해서 더 이상 신경 쓰지 않고, 요청한 작업이 완료되거나 혹은 여타의 이유로 작업이 중단되는 경우 그 결과만을 통보해 주는 기법이지만, CPU 입장에서는 그것이 User Mode이건 Kernel Mode이건 상관없이 특정 Thread가 작업을 처리해 주어야만 한다. User Mode혹은 자신의 Framework에서 단일 Thread만을 쓰기 때문에 시스템 전반에 걸쳐서도 효율적으로 운용될 것이라는 것은 망상에 가깝다.

 

효율적인 알고리즘을 사용한다면 처리속도와 메모리와 같은 저장소의 효율 상에는 항시 반비례 관계를 가지게 된다. 처리속도를 높이려면 더 많은 메모리를 사용하면 되고, 메모리를 적게 쓰려면 처리 속도를 희생하면 된다.

 

그렇다면 node.js가 가진 진짜 장점은 무엇일까?

개인적으로 가장 좋아 보이는 부분은 javascript를 이용한 전방위 개발이며, 독립적인 수행 환경이다. Client side, server side를 고려하지 않고, javascript language를 이용하여, system 이나 runtime의 도움 없이 독립적으로 수행 가능한 것은 상당히 큰 장점이다. 기존에 javascript가 다른 그 무엇을 수행하기 위한 보조적인 용도로만 사용되었다는 것을 생각해보면 상당한 장점이라 할 수 있겠다.

추가적으로 node.js가 나온지 그리 오래되지 않았음에도 불구하고 상당히 폭발적인 반응을 끌어 모으고 있다는 점이다. 패키지의 수와 안정성과 더불어, 주요 기업들이 node.js에 대해서 전방위적인 지원을 아끼지 않고 있다. Microsoft, Ebay, LinkedIn, Yahoo 등이 대표적이다.

 

옛말에 모로가도 서울만 가면 된다.”라는 말이 있기는 하지만, Node.js가 가지는 장점의 본질을 정확히 이야기하지 못하고 깜도 안되는 내용을 특징이면 장점이라고 말하면 Node.js 자체가 우스워 보일지도 모를 일이다.

 

비판으로 일관하였으나 그것은 절대 Node.js 자체에 대한 것은 아니며, 오히려 Node.js의 미래에 대해서는 비관적이기 보다는 희망적으로 보인다. 그렇기에 node.js에 대한 잘못된 시각에 대하여 강한 비판을 하게 되는 것 같다.


핑백

덧글

  • Outsider 2012/02/25 22:14 # 삭제 답글

    안녕하세요. 트위터에서 보고 제목이 인상적이라 흘러들어왔습니다.
    몇가지에 대해서 동의할 수 없는데요.
    일단 제가 본 대부분의 소개자료에는 대부분 자바스크립트로 되어 있다는 특징이 포함되어 있었습니다. 그래서 앞에서 말씀하신 3개의 특징만 꼽은 것은 이 비판을 위해서 마치 자바스크립트로 쓰인다는 장점은 소개안하고 다른 얘기만 한다는 이야기를 위한 잘못된 전제가 아닌가 합니다.
    그리고 node.js를 쓰면 각 작업단위의 작업속도가 빨라지진 않습니다. 디비조회하는데 1초가 걸린다면 어떤 어플리케이션 모델을 사용하든 1초가 걸릴것입니다. 대신 동기I/O에서는 어플리케이션에서도 1초동안 결과를 기다리기 때문에 async를 쓰면 1초를 대기하지 않을 수 있습니다.(작성자께서 이런 내용을 이해못했다고 생각하진 않지만요...) node.js는 이 부분을 통해 성능개선을 했다고 얘기한다고 생각하고 있기 때문에 이 부분이 장점으로 내세우지 못할 거짓이라고는 생각하지 않습니다. node.js가 event loop를 자신들이 만들어낸 개념이라고 얘기하는 것도 아니고요.
    더불어 완전히 같은 모델은 아닐지라도 비슷한 개념을 도입한 nginx의 인기나 apache가 이런 인기에 위기를 느껴서 최근에 event loop를 아파치에 도입해서 릴리즈 한것으로 보아도 이러한 개념이 거짓이라고 볼 수 없다고 생각합니다.
  • 김명신 2012/02/25 23:04 # 답글

    @Outsider 안녕하세요.. 저희 JCO에서 인사 나누었더랬죠? 위 글에서 1~3의 내용은 비판의 대상으로 뽑은 3가지 특징이 맞습니다. 장점이라고 말하는 부분 중 비판하고 싶은 부분을 추려온 것이니 그러하지요.
    동기 I/O와 비동기 I/O에 대해서는 여러가지 논란이 있을 수 있지만, 어느 한쪽이 다른 쪽에 비해서 일방적으로 좋다고 말하는 것은 좋지 않은듯 합니다. 비동기 I/O를 이용하게 되면, 결국 node.js가 말한 단일 Thread의 논지를 무너뜨리는 꼴이고, Thread간 Communication이 필요로 해집니다. 또한 Error Handling이 직관적이지 못하며, 추가적인 메모리 공간의 소요가 생깁니다. 하지만 특정 상황에서는 비동기 I/O가 동기 I/O에 비해서 월등이 뛰어난 경우가 있는데, 바로 UI를 다루는 Thread의 경우입니다. 이는 성능과는 별개의 시나리오지만 사용자에게 작업 완료를 기다리지 않게 할 수 있기 때문에 매우 훌륭한 적용시나리오라고 볼 수 있겠습니다.
    nginx나 apache가 이에 대한 위기로 event loop을 만들었다는 것으로 event loop이 더 나은 대안이라고 말할수는 없을 것입니다. 정확히 nginx와 apache가 어떤 event loop을 가지는지는 살펴보지않았습니다만 그것을 위기감에 대한 대응으로 논리를 확연히 하려면 nginx와 apache가 programming model을 event loop 방식으로 완전히 전환하거나 최소한 그것을 차대세의 방식으로 인정할 때 비로소 그렇게 느끼는 것이겠지요. 대단히 죄송하게도 이것이 아주 큰 일반화의 오류가 아닌가 하고 짚어드리고 싶습니다.
    그보다도 node.js 책을 출간해 주셔서 감사드립니다. 그날 부사장님께서 제가 볼 수 있도록 책을 보내주셨어요...
  • Outsider 2012/02/26 00:07 # 삭제

    앗! 안녕하세요. 혹시 JCO에서 MS Azure에 대해서 얘기했던 분이신가요?(죄송... 그날 너무 많은 분하고 인사를 해서 제가 이름을 다 기억못하네요. ㅠㅠ)
    제가 좋아하는 Node.js에 대해서 비판(?)이라 울컥하는 건 아니고요. 동의안되는 부분도 있고 제가 잘못설명(?)한 부분이 있지 않을까 해서 계속 댓글을 답니다.
    말씀하신 것처럼 비동기 I/O가 우월한 상황들이 있습니다. Node.js에 대해 설명하다보면 말씀하신 3가지 부분에 대해서 반론을 많이 받게 되는데요. 저같은 경우는 사실 기술만 가지고 우위를 논하는건 큰 의미는 없다고 생각합니다. 물론 우위를 논할 수 있는 부분들이 있기는 하지만 대부분은 어디에 쓸꺼냐를 같이 이야기해야 한다고 생각하고 그에 적절한 기술을 선택하는게 좋다고 생각하고 있습니다.

    "노드의 이러이러한 특징으로 적은 메모리로 괜찮은 성능을 낼 수 있다!"라고 얘기하는 것이 "그러므로 여태 쓰던 쓰레드모델은 더이상 필요없다"를 의미한다고 생각하지 않습니다.(저는 사실 이 주장이 저러한 결론으로 이어지는 것을 잘 이해하지 못하고 있습니다.) 분명히 멀티쓰레드가 나은 상황이 있을 것이니까요. 사실 장비가 충분히 성능이 좋다면 적은 메모리라는 건 그다지 장점으로 다가오지 않을 수도 있는 것이고요.
    아파치를 기준으로 설명한다면 말씀하신 것처럼 기존에는 성능을 높이려면 메모리를 늘려서 쓰레드를 더 많이 만들 수 있도록 해야했습니다.(사실 이는 속도가 높아졌다기 보다는 쓰레드가 늘어서 더 많은 요청을 처리할 수 있도록 된것이긴 하지요.) 대신 이벤트기반인 nginx를 사용하면 같은 쓰레드를 만들어서 요청을 처리하는 것이 아니기에 더 많은 요청을 처리할 수 있습니다. 이벤트기반인 차세대 방식인지는 잘 모르겠지만 기존에 쓰레드기반으로 치우쳐진 상황에서 이벤트기반을 재조명하여 새로운 접근을 시도하고 있다고는 생각하고 있습니다. 자바스크립트가 큰 장점이란 부분은 일면 동의하지만 그런 면에서 이벤트기반의 성능이 거짓이다라고 까지 표현한 것은 (죄송하지만) 약간 과한 표현이 아니셨는가 합니다. 이벤트루프를 통해서 이끌어낼 수 있는 장점이 있고 말씀하신 것처럼 멀티코어를 활용못하는 등의 단점을 가지고 있습니다. 어느기술이나 장단점이 있기 마련인데 단점이 있기 때문에 장점 혹은 특징을 특징이라고 말할 수 없는지는 잘 모르겠습니다.

    사실 말씀하신 3개의 특징들은 책을 쓰면서 어떻게 설명해야 하는가에 대해서 무척 고민했던 부분이라서(제가 경력이 짧아서 로우레벨은 깊게는 모르고 다 이해하고 있는 것도 아니라서요) 언제 기회되면 이런 부분에 대해서 다양한 논의를 해보고 싶은 생각이 드는군요.
  • 구경꾼 2012/02/26 00:33 # 삭제 답글

    저도 글쓴분의 의견에 동의하는 편인데요.
    Node.js의 붐은 프로젝터 리더의 뛰어난 마케팅 능력때문때문이 아닌가 생각됩니다.
    (마치 DHH의 마케팅능력 때문에Rails이 반짝했던것 처럼...)
    Node.js이전에도 서버사이드 자바스크립트 프레임웍이 제법 있었지만 다들 제대로 세상에 알려지지도 못했었고
    비동기,이벤트기반 이니 하는 특징들도 소켓사용해서 서버프로그래밍 하는 사람이면 일상적으로 쓰는 대단한 기술도 아니고
    Node.js가 갖다 쓰는 구글의 v8 자바스크립트 엔진도 개발자들이 서버용으로 만든게 아니라고 자기들 입으로 말했고
    비동기,이벤트기반 라이브러리로 갖다 쓴 libev도 원 제작자인 Marc Lehmann은 Node.js에서 자기가 만든 라이브러리를
    갖다쓰는지도 관심도 없고 뭐 그렇죠... 그만큼 핵심 라이브러리들 개발자간에 공감대가 이뤄지지 못한 상태에서 그 위에
    누각을 올린것이라 그 기반이 견고하지 못하다는 리스크를 지니고 있죠.

    IT분야가 작년에 클라우드 올해는 빅데이터 이렇게 중점 마케팅 용어를 내세우며 시장을 만들어 가듯이
    Node.js도 그런 이슈메이커 역할을 하면서 개발자들에게 어떤 판타지를 주면서 파이를 키우는 역할을 하지 않나 생각되네요.

  • Outsider 2012/02/26 01:43 # 삭제

    다른 분의 블로그라 댓글다는게 조심스럽긴 하지만 시작된 논의이니 계속 얘기하겠습니다.
    말씀하신 내용은 잘 이해못하겠습니다. 일단 김명신님의 의견은 이벤트기반과 비동기I/O의 성능장점에 대한 반대의견이라고 생각하는데 구경꾼님의 얘기는 node.js가 과대 포장되었다 라는 의미라고 생각됩니다. 이 두가지는 논점이 다른 부분이라고 생각합니다.

    뛰어난 마케팅능력이라고 하셨는데 어떤 마케팅이 있었느지 궁금합니다. DHH를 포함해서요.. 다른 뜨지 못한 기술과 비교하여 DHH나 Ryan이 어떤 마케팅 능력이나 마케팅행위가 있었다고 하시는 건지 잘 모르겠습니다. 제가 알기로는 자신의 기술에 대해서 설명하는 것 외에 특별히 마케팅을 위한 수단은 없지 않았나 생각합니다. 마케팅 능력으로 뜰 수 있다면 이런 오픈소스기술들 보다는 대기업을 등에 업은 기술들이 훨씬 유리한 위치에 있는 것 아닌가요?(일단 저는 Rails를 실패(?)한 프레임워크라고 생각하지 않습니다. 기술을 인기순위로만 본다면 그렇게 볼 수도 있겠지만요.)

    오픈소스라는 것은 말그대로 오픈된 기술이므로 맘대로 가져다 쓸 수 있는 것이고 그렇기 때문에 다양한 가능성을 가질 수 있다고 생각합니다. 원작자가 의도한 것과 다르게 쓰일 수도 있는 것입니다. Node.js가 다른 오픈소스를 가져다 쓰는데 왜 원작자의 관심여부가 Node.js의 좋고/나쁨의 평가기준에 들어갈 수 있는 것인가요? 제가 jQuery를 가져다가 새로운 프레임워크를 만들었을때 존 레식에 관심이 있으면 괜찮은 프레임워크고 관심이 없으면 안좋은 프레임워크인가요?

    김명신님의 글은 동의는 하지 않지만 글의 의도자체는 수긍하고 있는 편이지만 구경꾼님의 글에서는 어느부분이 문제라는 것인지 잘 이해하지 못하겠습니다.
  • 구경꾼2 2012/02/26 20:55 # 삭제

    '구경꾼'님의 의견은 흡사 '~카더라' 통신으로 전달되는 내용처럼 오히려 더 신빙성이 없어보입니다.

    - DHH의 마케팅 능력때문에 Rails가 반짝했다는 객관적인 증거는 어디있나요?
    - 비동기와 이벤트기반 프로그래밍은 소켓 프로그래밍 개발자가 일상적으로 쓰는 기술이란 말은 맞지만 소켓 프로그래밍 개발자가 자바스크립트를 써서 일상적으로 프로그래밍하진 않았습니다. 따라서 비교자체가 적절치 않습니다.
    - V8은 브라우저에서 동작하는 자바스크립트 엔진으로 제작되었다는 것을 모르는 사람이 있나요? '서버용으로 제작된 것이 아니다'라는 말은 불필요하며 이역시 비교대상이 아닙니다.
    - libev 제작자가 자신이 만든 라이브러리를 누군가 가져다 쓰는지 관심이 없다..? 그게 말이 됩니까? 원 제작자와 직접 대화해서 확인한 건가요? 기술적인 토의에서 제작자의 심경을 고려하는 듯한 이 말 역시 똥인지 된장인지 구분 못하는 비교라고 생각합니다
    - 핵심 라이브러리 개발자간에 공감대가 이뤄지지 못했다는 상태는 어떻게 측정한 것인가요? '공감대'는 버스비 처럼 정확하게 수치로 계산되서 발표된 모양인데, 그 자료의 출처는 어디인가요
    - 그 기반이 견고하지 못하는 리스크를 지니고 있다는 명제는 공감대나 개발자의 심경같은 비교에 의해서 도출되었나보군요.

    이런 정도의 의견을 내놓으니 이름을 달지 않은 것도 이해갑니다.

    기술을 가지고 왈가 왈부하는 떡밥은 물지 않으려 꽤 노력함에도 불구하고 이런 근거없고 허접한 반박은 참기힘들군요.
  • 구경꾼 2012/02/26 23:35 # 삭제

    마케팅말한건 DHH도 37signals란 회사를 세웠고 node.js도 Joyent라는 회사를 세웠죠. 이윤을 추구하는 회사와 일반 유저들 기반의 오픈소스커뮤니티는 홍보와 마케팅에 있어 당연히 차이가 있을 수 밖에 없습니다. Java가 Sun이 없었다면 오늘날 같은 메인스트림 언어가 될 수 있었을가를 생각해보시면 될듯...

    v8과 libev는 Node.js에서 그방 다른것으로 대체될 수 있는게 아닌 severely locked-in된 요소들입니다.
    그냥 fork해와서 독자적으로 딴길을 가기에는 쉽지않죠 그래서 그런 핵심적인 부분을 가져와서 Node.js를 만든것이겠고
    앞으로도 근간을 이루는 v8, libev가 어떻게 되든 완전한 자체적인 개발은 무리며 싫으나 좋으나 패치나 의견을 주고 받으며 간극을 매꿔나가는 수 밖에 없을겁니다. 제가 공감대 어쩌고 말 한건 일례로 Node.js쪽에 사람들이 libev쪽에 제시한 의견에 Marc Lehmann 이 libev메일링 리스트에서 어떻게 반응하는지를 몇번 지켜봤기 때문에 한 말입니다.
    http://lists.schmorp.de/pipermail/libev/2010q4/001137.html
    http://lists.schmorp.de/pipermail/libev/2011q4/001585.html
    같은 글을보면 제대로 알지도 못하면서 이렇다 저렇다 말한다는 식으로 불쾌함을 표하면서 심지어는 "What you are asking here is to make libeio inefficient for everybody because node.js choose to implement an inefficient software-process model." 이런 독설까지 하더군요.
  • 김명신 2012/02/26 11:14 # 답글

    @Outsider @구경꾼
    보내주신 의견 감사합니다. node.js의 프로젝터 리딩이 뛰어나거나 마케팅 능력이 출중하다는 구경꾼 님의 의견에 대해서는 딱히 제가 드릴 말이 없어서 죄송합니다. 말씀하신 바와 같이 그러그러한 능력들이 뛰어난지 아닌지는 제가 아직 잘 알지 못합니다. @Outsider 님이 말씀하신 것 처럼 비동기/동기 I/O는 그것을 어디에 쓸 것인가에 따라 좋을 수도 혹은 나쁠 수도 있습니다. 이 점에 대해서는 완전히 동의합니다. 또한 비동기 I/O가 동기 I/O에 비해서 사용하기 어려웠기 때문에 실제로 비동기 I/O를 사용하였을 경우 성능향상이 충분히 예상되는 부분에 있어서도 동기 I/O를 사용해 구현하였다면, Node.js가 제공해주는 손쉬운 비동기 I/O Model이 비교적 우위에 있다고 말할 수 있을지 모르겠습니다. 그러나 제가 알고 있는 많은 개발자들은 이미 이 두가지의 장단점을 충분히 이해하고 있고, 적재적소에 두가지 기술을 잘 혼용하고 계시는 것으로 알고 있습니다. 물론 사용하는 언어에 따라서 framework에 따라서 그것이 쉽거나 어려운 등의 차이점은 있을 수 있을 겁니다.
    제 글이 Node.js 기술을 폄하하기 위해서 쓰여진 것은 아니라는 것을 다시한번 말씀드리고 싶고, 실제로도 Node.js와 같은 시도를 상당히 좋아하기도 하고 높이 평가하고 있습니다.
    단지 Node.js의 소개 과정에서 기술적 비약이나 적절하지 않은 예 등이 많이 보여서 몇가지 지적하고 싶었을 뿐이고요, 이러한 잘못된 소개나 비약이 Node.js가 가져다 주는 본질적인 장점들을 소개하는데 방해되지 않을까 하는 관점에서 접근한 것 뿐이니 "노여움(?)"은 거두어 주시기 바랍니다...
  • Outsider 2012/02/26 12:00 # 삭제

    노여움은 아니고요 ^^
    단순비판을 위항 비판은 아니라고 생각했기 때문에 동의하지 못하는 부분에 대한 생각을 듣고 싶었습니다 제가 잘못생각하고 있을수도ㅜ있는거고요. 제 댓글이 좀 거칠게 느껴지셨다면 죄송합니다.
  • 김명신 2012/02/26 11:17 # 답글

    그리고 Node.js 성능에 대하여서는 다음과 같은 글도 있답니다.
    http://ppassa.wordpress.com/2012/01/28/server-solution-benchmark/
    참고하시면 좋겠습니다.
  • wafe 2012/03/07 21:35 # 삭제

    사실 성능 면에서는 Erlang 이 굉장히 유명했는데 명성에 걸맞는 벤치마크 결과네요. node.js 는 Server-Side JavaScript 개발환경의 결정판이라는 측면에서 의미가 크겠네요. 거기에다 더불어서 이벤트와 비동기 기반을 사용한다는 점이 덧붙겠고요.

    전통적인 C#/.NET 같은 환경에서 비동기 프로그래밍을 하는게 그다지 쉽지 않았다고 생각되는데, node.js 에서 JavaScript로 처리하는 방식을 보면 훨씬 비동기 프로그래밍하기 수월하다는 생각이 듭니다.

    node.js 는 현시점에서 필요한 장점들을 잘 결합해서 적절한 시점에 나와주었기 때문에 큰 인기를 누리고 있다고 보아야겠네요.
  • seso 2012/09/06 21:16 # 삭제

    좋은 자료 감사합니다, 잘 봤습니다.
  • 김명신 2012/02/26 13:36 # 답글

    @Outsider 다음번에 혹시 offline에서 만나뵐 기회가 있다면 이에 대해서는 좀 더 논의를 해보시죠.. 좋은 모임이 있다면 저도 초대해 주시고요.. 감사합니다.
  • nanhapark 2012/02/26 20:16 # 삭제 답글

    말씀하신 내용 모두 맞습니다. Node.JS의 event loop, kernel event noti mechanism 모두 고전입니다. v8빼고요. ㅋㅋ

    하지만, 시스템쪽에서 10년가까이 일해오면서. 벤치마크 결과 없이 말로만 하는 분들 많이 봤습니다.
    말로만 하지 마시고, 최소한 어떤 프로세스를 가지고 여러경우의 웹서버와 연관된
    근거를 내놓으시면 오해는 없으실 듯 하네요.

    KIN플 ~
  • 구경꾼2 2012/02/27 00:30 # 삭제 답글

    @구경꾼

    Joyent 라는 회사의 창립일과 그간의 사업방향과 결과물을 살펴나 보셨는지요? '회사'가 스폰서이면 다 마켓팅 목적이라는 논리는.. 제발..
    Node.js가 만들어진 때와 그걸 만든 사람이 당시 Joyent 와 어떤 관계이며 어떤 이유로 만들었가에 대해선 이미 널리 퍼지고도 퍼진 얘기인데 .. 반대의견의 단추가 첨부터 잘못 끼워졌으니 나머진 볼 필요도 없네요.

    Node.js를 탐탁치않게 생각하거나 반대의견을 내놓는 것은 자유지만 제발 제대로 반박하셔서 '개발자' 간의 논쟁이 쓸데없다는 소리 듣지 않게 해주시길 바랍니다.

    http://en.wikipedia.org/wiki/Joyent
    http://en.wikipedia.org/wiki/Nodejs
    http://siliconangle.com/blog/2012/01/31/how-a-vacuum-cleaner-salesman-became-the-new-king-of-node-js/

  • rhio.kim 2012/02/27 10:52 # 삭제 답글

    재미난 글과 많은 댓글들 ^-^/ 좋은글 잘보고 갑니다.
    생각이 비슷하시네요. Node.js 의 가장 큰 장점은 프로그래밍 언어로 JavaScript 채택했다는 것이라고 생각합니다.
    서버와 클라이언트의 isomorphic programming 이 가능하다는 것이죠.

    토론의 주제가 된 3가지에 대한 이야기도 동감하구요. 다만 부정하지는 않지만 기술의 마케팅이라는 관점은 개인적으로 거부감이 좀 있네요. :-)

    저는 그것보다 최근 스마트한(?) 시장으로 인한 실시간 성 데이터 처리와 그로 인한 빅 데이터에 대한 관점 그리고 클라우드 기반에서는 Node.js 갖춘 궁합은 큰 장점이라고 저는 믿어 의심치 않습니다. (저도 걸어가고 있는 중이라 facts 는 없고 확신만 갖고 있어요.)
  • 구경꾼2 2012/02/28 12:13 # 삭제 답글

    Node.js는 그것 자체로 신기할 만한 요소는, "서버사이드에서 자바스크립트를 쓸 수 있게해 줬다."겠죠. 원래 자바스크립트가 비동기적인 요소가 있었고, 그것밖에 할 수 없었으므로, 자연스럽게 그런 개념이 서버로 전달되었고요. 완성도 측면에서, 그것을 응용해서 애플리케이션을 만든 친구들의 능숙한 활용 능력 때문에, Node.js가 인기가 있게된 것이겠죠.

    자바스크립트를 하나의 완성된 프로그래밍 언어로 보면, 서버에서도 자바스크립트로 프로그래밍할 수 있다는 것은 축복과도 같은 일이지만, 자바스크립트를 웹프로그래밍할 때 사용하는 보조적인 도구로서 디버깅이 엄청 힘든 골치아픈 존재로 느끼는 사람한테는, "서버에서도 자바스크립트로 할 수 있어!"라고 얘기해 봐야... 귀신 씨나락 까먹는 소리밖에 안됩니다. "헉... 서버 프로그램을 디버깅 불가능한 그넘으로 한다고요?"

    도구는 잘 쓰는 사람에게만 도구입니다. 그걸 잘 못 쓰는 사람에게는... 방해만 되고, 옆사람이 사용하기 시작하면... 또 배워야 하는 귀찮고 성가신 존재죠. 개인 취향이죠.

    세계 최고 개발진들이 그걸 이용해서 세계 최고의 서비스를 만들어 내는 것을 보면, 뭔가 있기는 합니다만... 그걸 받아들이 자세가 되어 있지 않으면... 귀찮고 성가시고, 또 우리 인생을 갉아 먹을 존재로 느껴지겠죠.

    어렵지 않습니다만... 받아들여서 써 보거나... 그냥 피하거나... 어떻게 살든 자기 맘입니다.

    난 그딴거 이용하지 않고도 세상에 더 멋진 S/W를 만들어 내 볼 거야... 라는 당찬 태도가 있다면, 그건 더 좋습니다.
    그런 개발자 만세!
  • 김명신 2012/02/28 20:56 # 답글

    의도한 바는 아니었는데 많은 분들이 좋은 댓글을 많이 달아주셔서 다시 한번 감사의 말씀을 드립니다.
  • blacky 2012/09/04 04:25 # 삭제 답글

    댓글까지 모두 깨알같이 많은 걸 배우고 갑니다. 정말 댓글의 내용뿐만 아니라 모든 분들의 태도에서 상대방을 배려하는 모습이 보여져서 감동이었습니다. 감사합니다.
  • duecorda 2012/09/25 14:11 # 삭제 답글

    오래된 포스트에 댓글을 남기게 되네요. 어떤 결론이나 주장이 있는 댓글이 아니라 많은분들이 열정적으로 자신의 생각과 주장을 이성과 감성을 섞어 멋지게 표현해주시니 가슴이 뜨거워져서요 ㅎㅎ

    Rails 나 Node.js 가 마케팅의 산물이다는 얘기는 많이 섭섭합니다. 그보단 프로그래머로 자신이 사랑하는 언어를 통해 한계를 극복하고자 도전한 아름다운 스토리가 아닐까 싶은데요... 너무 미화했나요? ^-^;;

    Node.js 라든지 특정 프레임워크가 모든 상황과 난제를 해결하겠다는것도 아니고 여기 글 남기신 분들도 그런 만화같은 해결책을 기대하시진 않으시리라 생각합니다.

    진부한 얘기지만 필요한 상황에 맞춰 적당한 신기술을 받아들이면 많은 시간을 아낄 수 있죠. 과하면 독이구요.

    폴 그레이엄이 해커와 화가를 통해 지속적으로 던지는 질문은 "오늘날의 프로그래머는 어떤 꿈을 꾸고 있는가?" 라고 생각합니다.

    자신의 상황에서 꾸역꾸역 문제를 찾아내고 카페인과 니코틴의 힘으로 난제를 풀어내는, 그렇게 한계에 도전하는게 즐거운 사람들이 프로그래머 아닌가 싶습니다. ^^;

    뭔말하고 있는지 모르겠네요. 암튼 다들 사랑하는 일 열심히 합시다!
  • 1 2012/10/23 05:28 # 삭제 답글

    아파치등 비효율적인 소프트웨어가 유행했기때문에,

    nginx nodejs 가 빛나는 거겠죠 .

    열낼 내용은 아니라고 봅니다 ㅋ
  • 좋은글입니다. 2012/12/19 11:55 # 삭제 답글

    노드에 대한 제 생각과 가장 유사한 글인것같네요. 서버를 몇년간 개발해왔는데, 진짜 node.js의 서버 구조는 별다른 감흥이 없었는데 왜 이렇게 열광일까하는 생각이 있었습니다. 사실 .net만 봐도 이벤트 드리븐에 async api로 되어 있거든요. 물론 서버에서 어떻게 처리하는지는 잘 모르겠지만요.

    node를 모바일에 포팅하고 그위에서 개발해야 할 일이 있어서 여기저기 관련 글을 읽고 있는데, 가장 읽을 만한 글이었습니다.

    앞으로도 좋은 글 많이 부탁드리겠습니다.
  • reinhard 2016/03/19 22:58 # 삭제 답글

    비동기냐 동기냐에 따라 성능이 어쩌구 하는 구석기 시대 얘기는 누가 좀 정리를 해줄 필요가 있지 싶은데...
    아직도 이런 얘기가 도는 걸 보면.. 관련 책들의 문제인듯... 비동기 I/O 에 대한 뭔지모를 환상들을 심어준 책들...
    I/O 는 걍 다... 비동기 ... 동기가 될 수가 없음....
    다만... 그 결과를 전달 받을 때 어떤 방식으로 전달 받을거냐의 차이일 뿐...
    node.js 니 뭐니가... 싱글쓰레드에 비동기 I/O 라는게 장점이다라고 내세워진다는 얘기에...걍 웃고 갑니다...
댓글 입력 영역


facebook 프로필 위젯

트위터 위젯