Node.js에 관한 10가지 후회 - 라이언 달과 Deno.js

개발팁 & 소식

Node.js에 관한 10가지 후회 - 라이언 달과 Deno.js

1 여의도한량이 0 16468 0 0
1794647550_r9BEGWtN_3fad7fc02d052cb21382f2ce33e801e7a40f6702.png

 

 

Node.js를 개발한 라이언 달(Ryan Dahl) 은 지난 2018 년 6월 Javascript 최대 콘퍼런스인 JSConf 2018에서

10 Things I Regret About Node.js  을 발표하였습니다. 그 후 Node.js를 개발하면서 생겼던 후회를 바탕으로 새로운 서버 사이드 런타임인 Deno.js를 발표하였습니다. (Node에서 de를 no 앞에 쓴건데 이거 눈치채고 소름이.. )

 

라이언 달은 Node.js 만들면서 이벤트 기반 HTTP 서버(Event driven HTTP server)에 상당히 많은 심혈을 기울였습니다. 실제로 Node.js를 만들때 가장 중요하게 생각했던 것이 이벤트 기반 HTTP 서버라고 합니다. 이에 대해서는 여전히 Node는 좋은 서버 사이드 런타임이라고 말합니다.

 

 

1794647550_r71AE5Ix_fdee41e046ad217c946649944566516d6ea1889c.jpg JSConf 2018 라이언 달

 

 

그리고 2012년 라이언 달이 Node를 떠나면서 Node가

  • HTTP, HTTPS와 같은 프로토콜 지원

  • IOCP라는 시스템 콜을 사용하여 windows에 노드를 porting 가능

  • Linux와 Mac에서도 무리 없이 작동

  • API도 안정적이면서 NPM의 등장으로 사람들이 자유롭게 모듈도 추가 가능

등 다양한 기능을 할 수 있었기에 라이언 달은 "Node 프로젝트 완료" 를 선언했다고 합니다. 하지만 이는 라이언 달의 착각이였죠. 하물며 본인이 만들었음에도 불구하고 Node보다 Go Language가 더 좋으니 Go를 사용 하라고 말합니다. 

(10가지 후회 중 하나가 Promise를 사용 안한 것인데 Go는 이에 대한 문제가 없습니다. 참고사이트 )

 

이제 막 Node를 공부해가면서 재미를 붙이고 있는데 만든 개발자가 안좋으니 쓰지말라고 하는데 참 씁쓸하더라고요 ㅠㅠㅠ

 

이어서 라이언 달은 Node를 다음과 같이 비유합니다.

뭔가 버그를 만든 게 보이는 데 지금 당장은 그게 버그 같지 않게 동작하여 큰 문제처럼 보이지 않습니다. 하지만 버그는 버그인거죠. 그리고 설계상의 결함이 있는 걸 알면서도 지금은 그것을 고칠 수가 없습니다. 왜냐 이미 너무 많은 소프트웨어에서 사용하고 있기 때문입니다. 

 

그럼 Node를 만들면서 아쉬움이 남았던 라이언 달의 후회는 어떤 것들이 있을까요?

(10가지라고는 하지만 정확히 10가지는 아닌것 같습니다.)


10가지 후회

 

  1. Promises를 고집하지 않은 것(Not sticking with Promises)

  2. 보안 문제에 더 신경 쓰지 못한 것(Security)

  3. 빌드시스템(GYP) 1

  4. 빌드시스템(GYP) 2

  5. 패키지 매니저 파일(package.json) 1

  6.  패키지 매니저 파일(package.json) 2

  7. 모듈 시스템(node_modules)

  8. Require 문법을 쓸 때 js 확장자를 안 써도 되게 한 것

  9. index.js

  10. deno

 


1. Promises를 고집하지 않은 것

 

Node의 비동기 호출은 현재 callback API로 되어있습니다. 따라서 Node는 Promises를 사용하지 않습니다. 2009년에 라이언 달이 Promises를 추가했다가 2010년에 본인 고집으로 인하여 다시 삭제하였다고 합니다. Promises를 사용하지 않는 편이 더 간단해 보이고, Promises를 사용하면 callback마다 Promises 객체를 추가 해줘야했기 때문에 효율적이지 못할거라고 생각한 모양입니다. 이러한 라이언 달의 실수는 더 빠르게 성장할 수 있었던 async/await 생태계 를 더디게 만들었다고 합니다. 

 

2. 보안 문제에 더 신경 쓰지 못한 것(Security)

 

Node는 모든 걸 그대로 보여주기 때문에 보안이라고는 1도 없습니다. Node 응용 프로그램을 실행하면 모든 시스템 콜에 접근 또한 가능해집니다.  Node 응용 프로그램이 어떻게 유지되고 발전하는지를 고려했었으면 다른 언어들이 갖지 못할 보안을 가질 수 있었을 텐데 그러지 못하여 아쉬움을 토로했습니다.

 

3. 빌드시스템(GYP) 1

 

가장 후회스러운 부분이라고 합니다. Node는 GYP라는 메타 빌드 시스템을 사용하는데 크롬에서 사용하던 것입니다. 하지만 몇 년후 크롬에서는 GYP을 버리고 GN으로 갈아타지만 Node는 GYP를 그대로 안고갑니다. 그리고 현재 Node만이 유일하게 GYP를 사용합니다. (GYP에 대해 잘 알지는 못하지만 끔직할 정도로 구리다고 합니다.)

Node 지원 때문에 GYP wrapper가 있는데 이거 때문에 너무나 많은 양의 불필요하고 복잡한 기술들이 사용되고 이를 Node의 가장 심각한 실패라고 말합니다. 참고로 구글의 GN이 GYP보다 20배 정도 빠르게 빌드 된다고 합니다.

 

(저 같은 학부생에겐 빌드시스템 부분은 많이 이해하기 힘든 부분이였습니다.)

 

4. 빌드시스템(GYP) 2

 

GYP를 이용해 빌드 시스템을 만들면서 네이티브 콜을 하기 위해서 사용자가 필수적으로 C++ 바인딩을 하도록 했는데, FFI(Foreign Function Interface)를 제공했어야 했다는 아쉬움을 토로했습니다.

 

5. 패키지 매니저 파일(package.json) 1

 

Node.js는 모듈 시스템을 가지고 있습니다. 최근에 이 모듈 시스템이 Go와 java에서 언어 자체적으로 구현이 되는 스펙들이 발표되었습니다. (go는 처음부터 구현됐습니다.) 이 모듈 시스템을 관리하는 프로그램은 3rd 파티 프로젝트로 떼어 놓는 것이 일반적이죠. 그런데 노드는 npm이라는 패키지 매니저가 관리하는 package.json. 파일이 main() 함수에서 찾도록 되어있어 npm에 의존적인 커뮤니티로 만들었다는 점을 스스로 비판했습니다.

최근 facebook에서 만든 yarn이라는 패키지 매니저가 npm을 대체하고 있지만 package.json은 그대로 사용하고 있습니다. 의도하진 않았지만 defacto(사실상의 표준)가 된 셈이죠.
또, 이 package.json 파일은 모듈을 찾을 때 명시적이지 않다는 단점도 있습니다. 쉬운 이해를 위해 아래 그림을 참조하시기 바랍니다.

 

 

1794647550_256JCZua_cf9d884446d216eca29fe427cfcc2b8259acf1eb.png https://tinyclouds.org/jsconf2018.pdf

 

 

6. 패키지 매니저 파일(package.json) 2

 

package.json 파일의 모듈 시스템이 파일 디렉터리를 기준으로 잡히도록 만들어서 라이선스, 리포지터리, 설명 등 모듈 시스템 자체만으로는 필요 없는 정보까지 다 포함시켜 너무 무거워졌다고 합니다. 

 

7. 모듈 시스템(node_modules)

 

위에서 언급한 파일 디렉터리 기반 모듈 시스템의 약점과 마찬가지로 모듈을 가져오는 알고리즘이 복잡해졌습니다. 그 중 하나가 resolving 알고리즘인데 이 알고리즘은 미친 듯이 복잡합니다. node_modules 폴더 뒤에 깔린 개념인 vendored-by-default(서드 파티 라이브러리를 디폴트로 같이 설치하는 것)는 연결하는 상대가 어떤 것인지에 대해 정확히 알수 있도록 한 의도였지만(환경변수처럼), 지금 방식은 브라우저 작동 방식에서 크게 벗어났고, 이는 본인의 실수라고 말합니다. 그리고 이를 되돌릴 수 없다고 합니다.

 

 

1794647550_QHgS7vcj_77727a9029044372061d13cf6b29dc8ecac6f175.png https://tinyclouds.org/jsconf2018.pdf

 

 

8. Require 문법을 쓸 때 js 확장자를 안 써도 되게 한 것

 

Node가 파일 시스템에 브라우저 내 자바스크립트가 작동하는 것과 표준이 달라서 모듈 로더가 사용자의 의도를 파악하기 위해 많은 고민을 해야 한다는 점을 언급했습니다.

실제로 Node에서는 Require("poo.js") 에서 Require("poo")처럼 import 관련 .js 확장자 생략이 가능합니다. 그리고 deno에서 이 부분이 확실하게 바뀐게 눈에 띄죠.

 

9. index.js

 

그냥 귀여워서 default를 index.js로 했다고 합니다. 디렉토리를 include할 때 index.js를 살펴보면 귀여울것 같았다고 합니다. 하지만 이는 불필요한 도입이였습니다. 결과적으로 모듈 로딩 시스템을 더욱 복잡하게 만들었다고 합니다.

 

10. Deno

 

라이언 달이 Node에 관한 후회에 대해 발표를 한 후 새로 만들고 있는 프로젝트를 공개했는데 그것이 바로 Deno였습니다. 

 

라이언 달이 개발한 개선되고 더 안전한 Node입니다. Node는 JavaScript를 실행하기 위한 런타임인 것처럼, Deno는 TypeScript를 실행하기 위한 Command-line 런타임이라고 보시면 됩니다.

 

 

1794647550_sPFgNTG0_e290f8113698d29e4a5e1b3bc12ffed7a2d92b73.png https://javascript.plainenglish.io/what-is-deno-and-what-happens-to-node-js-now-57aae2afa2bc

 

 

(git hub 프로젝트 링크: https://github.com/ry/deno)

 

 

1794647550_hFYrdIQk_3170a38d75cd01263f1003baf19ba747dc0372e8.png

 

6개인가 5개였던 브랜치가 현재는 494개인거 보면 활발하게 개발하고 있는 모양입니다.

 

1794647550_vEg3Sbtp_c2fcb09cb51c3a50c0a5ab6958e867ca985252ed.png

 

그리고 확실히 TypeScript가 40% 이상을 차지하는 걸 볼 수 있습니다.


맺으며..

 

물론 3년 전 발표한 내용이지만 이제 막 Node.js에 대해 알아가고 있는 저에겐 충격적인 영상이였던것 같습니다.  만든 개발자가 안좋다는데... 참 ㅠㅠㅠㅠ 계속 Node를 공부해야하나 혼란스럽기도 합니다...

결국 프로그래밍이라는 것도 인간이 만든 것이기 때문에  라이언 달 같은 천재 개발자도 실수를 하는구나 라는 생각도 들었습니다.

 

Deno 같은 경우 Node와 아직 연결성이 없어 이를 연결하려면 오랜 시간이 걸릴 것 같지만 JSConf 발표 후 3년이라는 시간이 흘렸고 Deno라는 새로운 서버사이드 자바스크립트 엔진이 서버사이드 생태계에 어떠한 영향을 줄지 기대가 됩니다.

 

 

 

[참고]

www.youtube.com/watch?v=M3BM9TB-8yA

gocoder.tistory.com/1578

ebbnflow.tistory.com/257

jsdevelopers.medium.com/10-things-i-regret-about-node-js-ryan-dahl-e56b78dffe8c

www.samsungsds.com/kr/insights/github-June-Trend.html

[이 게시물은 플래토님에 의해 2021-04-20 14:10:25 플랫폼개발에서 이동 됨]

0 Comments