<div style="margin:0px 0px 1.5em;color:#333333;line-height:33px;"><br></div> <p style="margin:0px 0px 1.5em;color:#333333;line-height:33px;"><br></p> <p style="margin:0px 0px 1.5em;color:#333333;font-family:Georgia, Cambria, 'Times New Roman', Times, serif;font-size:22px;line-height:33px;">원문: <a target="_blank" href="http://likelink.co.kr/31809" style="color:#76a34c;text-decoration:none;" target="_blank">Farewell Node.js</a> (TJ가 어제 올린 글. 참고로 <a target="_blank" href="https://github.com/visionmedia" style="color:#76a34c;text-decoration:none;" target="_blank">TJ Holowaychuk</a>는 Express, Jade, Mocha 등을 만든 Node.js 의 대표적인 프로그래머이다.)</p> <h3 style="color:#111111;font-family:Georgia, serif;">Farewell Node.js. node.js 진영을 떠나며..</h3> <ul style="margin:0px 0px 1.5em;padding-left:2.5em;color:#333333;font-family:Georgia, Cambria, 'Times New Roman', Times, serif;font-size:22px;line-height:33px;"><li style="margin:3px;">나는 충분히 오랫동안 운영환경에서의 Node.js 와 싸워왔다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">그리고 불행하게도 지금은 더이상 재밌게 일할 수 없게 되었다.</li> <li style="margin:3px;">그래서 공식적으로 작별을 고하고, 새로운 maintainers를 찾고 있다.</li></ul></li> <li style="margin:3px;">Node는 어떤 것들에는 좋다, 하지만 결과적으로 내가 요즘 흥미로워하는 종류의 소프트웨어를 만들기 위해선 올바른 도구가 아니었다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">그래도 여전히 웹사이트에 Node를 사용할 계획이다</li> <li style="margin:3px;">만약 당신이 어떤것을 maintaining 하고 싶다면 알려달라. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">GitHub 사용자명과 NPM 사용자명, 프로젝트명을 남겨달라.</li> <li style="margin:3px;">내가 요구하는 건 기존 API들을 drastically하게 변경하지 말아달라는 것이다.</li> <li style="margin:3px;">만약 그렇게 하고 싶다면 새로운 프로젝트를 시작해라.</li></ul></li></ul></li> <li style="margin:3px;"><code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">Koa</code>는 내가 계속 maintain하는 프로젝트가 될 것이다.</li></ul><h3 style="color:#111111;font-family:Georgia, serif;">성배 <a target="_blank" href="http://ko.wikipedia.org/wiki/%EA%B1%B0%EB%A3%A9%ED%95%9C_%EC%9E%94" style="color:#76a34c;text-decoration:none;" target="_blank">(The Holy Grail)</a></h3> <ul style="margin:0px 0px 1.5em;padding-left:2.5em;color:#333333;font-family:Georgia, Cambria, 'Times New Roman', Times, serif;font-size:22px;line-height:33px;"><li style="margin:3px;">난 항상 <code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">C</code> 를 사랑해왔다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;"><code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">C</code> 는 rewarding 하지만 에러를 만들기 쉽다는 것을 알고 있다.</li> <li style="margin:3px;">매일하는 업무를 위해 <code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">C</code> 를 선택하는 것은 정당화하기 힘들다.</li> <li style="margin:3px;">단순한 것에대해 나는 언제나 존경해왔다. 하지만 거대한 양의 boilerplate 없이는 당신은 많은 것을 얻을 수 없다.</li></ul></li> <li style="margin:3px;">분산시스템에서 일을 할 수록. 나는 더욱더 usability(사용성)과 robustness(견고함) 보다 성능을 우선하는 <code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">Node</code>의 방향에 대해 frustrated(좌절, 실망, 짜증) 했다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">일주일 전부터 나는 상대적으로 큰 분산시스템을 <code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">Go</code>로 다시쓰고 있다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">그것은 더 견고하고, 더 빠르고, 더 유지보수가 쉽고, 게다가 test coverage도 좋아졌다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">synchronous code(동기적 코드)가 일반적으로 더 좋고 더 단순하다.</li></ul></li></ul></li></ul></li> <li style="margin:3px;">난 <code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">Go</code>가 성배라고 말하고 있는게 아니다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">그것은 완벽하지 않다.</li> <li style="margin:3px;">하지만 오늘까지 존재하는 언어들중 <code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">Go</code>는 나에게 가장 좋은 해결책이다.</li> <li style="margin:3px;"><code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">Rust</code> 와 <code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">Julia</code> 같은 “차세대 언어"들은 자신의 자리를 찾고 성숙해지면, 나는 좀더 많은 해결책을 가지게 될 것이라고 확신한다.</li></ul></li> <li style="margin:3px;">개인적으로 <code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">Go</code>에 가장 흥분되는 점은 (Go 언어 프로젝트의) 개발 속도이다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">그들의 2.0 에 도달하기 위한 열망에 흥분했다.</li> <li style="margin:3px;">그들은 이미 잘 되어있는 것을 부수고 변경하는 것에 너무 걱정하지 않는다.</li> <li style="margin:3px;">(수정: 약간 오해했던것 같다. 그들은 breaking changes에 대한 열망이 언제나 있는건 아닌것 같다.)</li></ul></li> <li style="margin:3px;">이게 진실이면 좋겠다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">왜냐하면 나는 언어에 이익이 있다면 빠르게 breaking things 하는게 좋다고 믿기 때문이다.</li> <li style="margin:3px;">내가 거대한 시스템을 실행시키고 있는건 아니니까. :D</li></ul></li></ul><h3 style="color:#111111;font-family:Georgia, serif;">Why Go?</h3> <ul style="margin:0px 0px 1.5em;padding-left:2.5em;color:#333333;font-family:Georgia, Cambria, 'Times New Roman', Times, serif;font-size:22px;line-height:33px;"><li style="margin:3px;"><code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">Node</code>는 여전히 좋은 도구이고, 만약 working 한다면 걱정할 이유가 없다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">하지만 그것이 당신을 괴롭힌다면, 당신의 box에서 벗어나야 한다는 것을 잊지마라.</li> <li style="margin:3px;">나는 production에 Go를 써본 처음 몇시간만에 Go에 빠지게 되었다.</li></ul></li> <li style="margin:3px;">다시 말하지만, Go는 당신이 사용해야만 하는 절대적으로 가장 좋은 언어는 아니다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">하지만 비슷한 나이인 Node에 비해서 (나이에 비해) 아주 성숙하고 견고하다.</li> <li style="margin:3px;">types 리팩토링은 쉽고 단순하고</li> <li style="margin:3px;">profiling, debugging 은 굉장하고</li> <li style="margin:3px;">커뮤니티는 문서, 포맷, 벤치마킹, API 디자인에 대한 강력한 conventions 갖고 있다. (상욱: TJ는 커뮤니티의 컨벤션을 아주 중요하게 생각하는 듯)</li></ul></li> <li style="margin:3px;">Go 를 처음 들었을때 Go stdlib 의 일부는 끔찍하다고 생각했다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">Node의 ultra-modularity에 익숙해져 있었고</li> <li style="margin:3px;">Ruby의 썩은 stdlib 의 경험이 있었기 때문이다.</li> <li style="margin:3px;">Go언어를 좀더 사용해보고 나는 stdlib의 대부분이 요즘의 프로그램을 만드는데 아주 essential 하다는 사실을 깨달았다. (압축, json, IO, buffered IO, 문자열 조작 등)</li> <li style="margin:3px;">이러한 API들은 잘 정의되어있고 강력하다.</li> <li style="margin:3px;">stdlib만 쓰는 것으로 전체 프로그램을 다 쓸 수 있고, 매우 쉽다.</li></ul></li></ul><h3 style="color:#111111;font-family:Georgia, serif;">Third-party Go packages</h3> <ul style="margin:0px 0px 1.5em;padding-left:2.5em;color:#333333;font-family:Georgia, Cambria, 'Times New Roman', Times, serif;font-size:22px;line-height:33px;"><li style="margin:3px;">대부분의 Go 라이브러리들은 look and feel이 비슷하고, 내가 써본 대부분의 third-party 코드는 품질이 높다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">Javascript 는 스킬레벨의 범위가 넓기 때문에 Node에서 좋은 라이브러리를 찾는 일은 어렵다.</li> <li style="margin:3px;">(상욱: JS가 쉬워서 모듈이 난입한다는 느낌은 나도 가졌지만. 이게 JS의 단점이고 Go의 장점이라는 논리는 동의하기 어렵다. ㅎㅎ)</li></ul></li> <li style="margin:3px;">Go 패키지를 위한 중앙 레지스트리는 없다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">그래서 당신이 5~6개의 같은 패키지네임을 보게될 것이다.</li> <li style="margin:3px;">이것은 약간의 혼란일 수 있지만, side-effect를 가질 수 있기 때문에, 베스트 솔루션을 결정하기 위해 각각을 리뷰해야 한다.</li> <li style="margin:3px;">Node 에는 표준적인 패키지가 있다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">예를 들면 redis, mongodb-native, zeromq 등.</li> <li style="margin:3px;">그래서 당신은 이것이 가장 좋은 것이라고 가정하고, 리뷰를 하지 않는다.</li></ul></li></ul></li></ul><h3 style="color:#111111;font-family:Georgia, serif;">Go versus Node</h3> <ul style="margin:0px 0px 1.5em;padding-left:2.5em;color:#333333;font-family:Georgia, Cambria, 'Times New Roman', Times, serif;font-size:22px;line-height:33px;"><li style="margin:3px;">만약 당신이 분산 작업을 하고 있다면, 당신은 Go의 동시성이 아주 좋다는 사실을 알게 될 것이다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">우리는 Node의 generators로 비슷한 것을 얻었다.</li> <li style="margin:3px;">하지만 내 의견은 generators는 Go의 절반만 얻을 수 있다.</li> <li style="margin:3px;">stacks error handling과 reporting을 분리하지 않는 것은 좋게 봐줘도 평범하다. (가장 좋은 방법은 아니다.)</li> <li style="margin:3px;">솔루션을 알고 있으면서도, 커뮤니티가 defragment(단합)가 될때까지 3년을 기다리고 싶지 않다.</li></ul></li> <li style="margin:3px;">내 의견은: Go의 에러핸들링이 더 우수하다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">Node는 모든 에러에 대해 생각해야만 하고, 무슨일을 할지 생각해야 하고, 당신이 그런 감각이 있는 사람이라면 좋을지도 모른다.</li></ul></li> <li style="margin:3px;">하지만 Node는 실패한다. 왜냐하면: <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">you may get duplicate callbacks <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">중복 callbacks 을 얻을 수 있다</li></ul></li> <li style="margin:3px;">you may not get a callback at all (lost in limbo) <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">callback 을 전혀 얻지 않을 수 있다</li></ul></li> <li style="margin:3px;">you may get out-of-band errors <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">out-of-band(책임 범위를 벗어난) 에러를 얻을 수 있다</li></ul></li> <li style="margin:3px;">emitters may get multiple “error” events <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">emitters 는 "error” 이벤트 여러개를 얻을 수 있다</li></ul></li> <li style="margin:3px;">missing “error” events sends everything to hell <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">“error” 이벤트를 놓치면(받지 않으면) 모든 것은 지옥으로 떨어진다</li></ul></li> <li style="margin:3px;">often unsure what requires “error” handlers <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">“error” 핸들러를 요구하는지가 불확실하다</li></ul></li> <li style="margin:3px;">“error” handlers are very verbose <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">“error” 핸들러가 아주 장황하다</li></ul></li> <li style="margin:3px;">callbacks suck <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">콜백 자체가 똥이다</li></ul></li></ul></li> <li style="margin:3px;">Go 에서는 내 코드가 실행이 끝나면, 끝난 거다. 당신은 그 statement를 재실행할 수 없다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">Node에서는 아니다.</li> <li style="margin:3px;">Node 는 루틴이 완전히 끝났다고 생각해도, 어떤 라이브러리가 갑자기 콜백을 여러번 invoke 하면, 핸들러가 제대로 지워지지 않고, 코드는 재실행될 수 있다.</li> <li style="margin:3px;">이것은 live production code 가 어떻게 동작하고 있는지를 추적하는 것을 어마어마하게 어렵게 만든다.</li> <li style="margin:3px;">왜 괴로워하고 있나? 다른 언어는 당신에게 그런 고통을 주지 않는다구.</li></ul></li></ul><h3 style="color:#111111;font-family:Georgia, serif;">Node의 미래</h3> <ul style="margin:0px 0px 1.5em;padding-left:2.5em;color:#333333;font-family:Georgia, Cambria, 'Times New Roman', Times, serif;font-size:22px;line-height:33px;"><li style="margin:3px;">나는 여전히 Node 가 잘 할것이라는 희망이 있다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">많은 사람들이 투자하고 있고, 잠재력도 가지고 있다.</li> <li style="margin:3px;">나는 Joyent 와 개발팀이 사용성에 초점을 맞출 필요가 있다고 생각한다.</li> <li style="margin:3px;">성능은 app이 작으면, 디버깅, 리팩토링, 개발만 어렵게 만든다고 생각한다.</li></ul></li> <li style="margin:3px;">우리는 4~5년 동안 <code style="padding:2px;overflow:auto;width:auto;font-size:20px;font-family:nanumgothiccoding, 'nanum gothic coding', menlo, monaco, consolas, 'courier new', monospace;border:1px solid rgb(221,221,221);background-color:#f8f8f8;">Error: getaddrinfo EADDRINFO</code> 와 같은 모호한 오류를 봐왔다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">이것만 봐도, Node 개발자들의 우선순위가 어디에 있는지 알 수 있다.</li> <li style="margin:3px;">당연하지만, 시스템의 core 에 아주 집중하고 있으면 이러한 실수를 할 수도 있다. (Node 개발자들이)</li> <li style="margin:3px;">하지만 사용자들이 계속해서 이러한 것들을 표현했다고 생각하는데, 우리는 결과를 보지 못했다.</li></ul></li> <li style="margin:3px;">Streams 는 깨지고, callbacks 는 좋지 않고, errors 는 모호하고, 도구는 좋지 않고, 커뮤니티는 컨벤션을 가지고 있긴 하지만 Go와 비교하면 부족하다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">웹사이트를 만들거나 API 또는 프로토타입을 만든다면 Node 를 앞으로도 사용할 것이다.</li> <li style="margin:3px;">만약 Node 가 기본적인 문제들을 고친다면, 좋은 기회 겠지만.</li> <li style="margin:3px;">사용성보다 성능을 우선하는 방향 또는 성능과 사용성을 모두 잡겠다는 방향으로는 해결되지 않을 것이다.</li></ul></li> <li style="margin:3px;">Node 커뮤니티가 generators를 받아들이고 node의 core를 구현하여 에러처리를 잘 만들 수 있다면, 이것은 아주 좋아질 것이고. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">Node의 사용성과 견고함을 매우 개선할 것이다.</li></ul></li> <li style="margin:3px;">누구를 비방할 목적으로 쓴 글이 아니다.</li> <li style="margin:3px;">내가 말하고 싶은 것은, 당신 스스로의 bubble에 갖혀있지 말라는 것이다. <ul style="margin:0px;padding-left:2.5em;"><li style="margin:3px;">둘러보면 굉장한 솔루션이 널려 있고. 당신은 다시 재밌게 프로그래밍을 할 수 있다!</li></ul></li></ul><div> <hr><div style="margin:0px 0px 1.5em;color:#333333;line-height:33px;"><font face="맑은 고딕" size="3">글 내용을 가져왔지만 <br></font><font face="맑은 고딕" size="3">TJ가 하는 말은 딱 내가 생각 하는 수준의 문제를 집어주고 있어보입니다.<br></font><font face="맑은 고딕" size="3">node는 javascript의 한계를 그대로 물려 받아서 콜백 지옥,  </font><font face="맑은 고딕" size="3">모듈화의 어려움, 병행성,동시성 등등이 거의(네이티브 코드가 아닌 실제적으론 외부 라이브러리코드를 이용) 불가능 등등 수많은 문제 때문에  사실상 사형 선고 받은 자바스크립트란 언어로 쓰였기 때문에 더욱이나.<br></font><font face="맑은 고딕" size="3">정작 진짜 문제는 프론트 엔드 스크립터 들이 자신들도 서버 개발자라고 외치며  </font><span style="font-family:'맑은 고딕';font-size:medium;">node js로 개발 하는 수 많은 쓰레기 코드 생산이 정말 못봐줄 정도입니다.<br></span><span style="font-family:'맑은 고딕';font-size:medium;">엥간 하면 백엔드 개발은 다른 언어로 하시길 <br></span><span style="font-family:'맑은 고딕';font-size:medium;">조금만 규모가 커지고 개발자 1인 이상이 개발 할 경우 정말 node는 답이 없습니다.<br></span><font face="맑은 고딕" size="3">node는 정말 간단하고 심플한 작업에 어울리는 프레임워크 입니다.<br>물론 제 글과 위 글에 발끈할 분들도 많으실거라 보입니다.</font></div></div> <div style="margin:0px 0px 1.5em;color:#333333;line-height:33px;"><font face="맑은 고딕" size="3">하지만 node로 개발 할내용 python, ruby, go 등등 얼마든지 다른 쉽고 빠르고 간편한 언어가 더 많음 </font></div> <div style="margin:0px 0px 1.5em;color:#333333;line-height:33px;"><font face="맑은 고딕" size="3"><br>node js로 백엔드 서버 3달 개발 하면서 미친 디버깅과 콜백 지옥 그리고 거의 모든 라인마다 로그를 찍었음에도 정상적으로 로그 조차 남겨주지 않는 오류에  키보드 두개 와 마우스 3개를 부셔버린.. 개발자 올림</font></div> <div style="margin:0px 0px 1.5em;color:#333333;line-height:33px;"><font face="맑은 고딕" size="3"><br></font></div>