2018년 6월의 깃허브 트렌드: deno

2018년 6월의 깃허브 트렌드: deno

지난 아티클에서는 5월의 깃허브(GitHub) 기술 트렌드로 “Build your own X”를 소개했습니다. “X 대신에 내가 만들고 싶은 ‘무엇’을 대입하면 된다”라는 뜻으로, 개발자들이 편하게 개발할 수 있도록 해주는 지극히 평범하면서도 비범한 프로젝트였죠.

데스크에서 노트북 업무 보는 사람 2018년 5월의 깃허브 트렌드:Build your own x
[BY 삼성SDS] Build your own x
Build your own x

이제 6월의 깃허브 트렌드를 살펴보겠습니다.

1. 6월의 가장 핫한 프로젝트 10선 (6월 25일 기준)

6월 한 달간 깃허브에 올라온 프로젝트 중 많은 호응을 얻었던 deno는 node.js를 만들었던 라이언 달(Ryan Dahl)이 만든 프로젝트로서 오랜만에 굉장한 반응을 이끌고 있습니다. vue와 React가 다시 각광받게 된 것은 vue 프로젝트가 깃허브 스타 랭크에서 React를 추월했기 때문인데, 두 진영의 각축전이 대단했습니다.

2. 주목할 만한 프로젝트: deno

2018년 6월 2일부터 3일까지 양일간 JavaScript 최대 콘퍼런스인 JSConf가 유럽에서 개최(JSConf. EU) 되었습니다. 필자는 참석하지 못했지만, TC39 패널도 참석하고 Remy Sharp도 발표자로 참석하고 하니 볼만한 콘퍼런스 였을듯합니다. 참고로, TC39는 ECMAScript(JavaScript의 표준을 정하는 단체)이고, Remy Sharp는 nodemon, jsbin의 개발자로 유명하죠. 하지만, 현재까지 회자되는 것은 단연 ‘deno’ 프로젝트에 대한 것입니다. 이 프로젝트가 공개된 지 20여 일 만에 어떻게 깃허브 스타 2만 개를 받았는지 지금부터 알아보겠습니다.

JavaScript 최고의 콘퍼런스‘ JSConf’ [그림1] JavaScript 최고의 콘퍼런스‘ JSConf’

라이언 달(Ryan Dahl)은 JSConf.EU 행사 첫날의 저녁 세션에서 “10 Things | Regret About Node.js”라는 제목으로 발표했습니다.

Ryan Dahl의 발표 현장 [그림 2] Ryan Dahl의 발표 현장

◎ 유튜브 링크: https://www.youtube.com/watch?v=M3BM9TB-8yA
◎ 발표자료 링크: http://tinyclouds.org/jsconf2018.pdf

라이언 달은 Node.js를 처음 만든 사람으로서 현재 가장 큰 오픈소스 커뮤니티 중 하나인 노드 커뮤니티의 첫 번째 리더였습니다. 그가 이번 발표에서 그동안 많은 사람들이 제시했던 Node.js의 문제를 직접 다루었다는 점이 주목할 만합니다. 그가 말했던 “Node.js에 관한 10가지 후회”를 차례로 살펴보겠습니다.

“10가지 후회” 이야기의 배경

처음 노드를 만들 때 라이언 달은 이벤트 드리븐 HTTP Server를 만들기 원했고, 당시 가장 적합했던 JavaScript를 통해 그 목표를 훌륭하게 달성해냈다고 합니다. (덕분에 Node.js는 가장 빠르게 인기를 얻은 서버사이드 프레임워크가 되었고, 이후 다른 언어에 영향을 미칩니다.)

하지만 최근 학술적인 컴퓨팅 작업을 하면서 버그들이 명확하지 않다는 사실을 알게 되었고, 그로 인해 이번 작업(아쉬운 점을 생각해 보는 것)을 하게 되었다고 합니다.

Node.js에 관한 10가지 후회

① Promises를 고집하지 않은 것(Not sticking with Promises)
Node.js를 작업하는 대부분의 사람들은 이 말에 100% 공감할 겁니다. Node.js의 비동기 호출은 여전히 콜백 API를 기준으로 되어 있습니다. Promises는 Async, Await을 제공하기 위해서 필수였죠. 라이언 달은 2009년에 Promises를 추가했다가 2010년에 삭제한 것을 언급하면서 자신이 Promises를 계속 고집했다면 커뮤니티 소스가 더 빨리 Async Await으로 진보했을 것이라며 후회했습니다.

② 보안 문제에 더 신경 쓰지 못한 것(Security)
V8에 대해서는 그 자체로 훌륭한 샌드박스 모델을 가지고 있다는 것을 언급하며 다만 Node 응용 프로그램이 어떻게 유지ᆞ발전될지를 고려했다면 다른 언어들이 갖지 못한 보안성을 갖출 수 있었을 거라는 후회를 남겼습니다. (V8은 Node.js의 JavaScript 엔진으로써 구글에서 만들어 크롬에도 사용됩니다.)

③ 빌드시스템(GYP) 1
처음 노드를 만들 때 크롬 브라우저가 GYP라는 메타 빌드 시스템을 사용하다가 GN으로 업그레이드한 반면, Node.js는 GN으로 변경하지 않아 이를 후회했습니다. 참고로, 구글의 GN이 GYP보다 20배 정도 빠르게 빌드 된다고 합니다. (GYP_메타 빌드 시스템은 여러 플랫폼(윈도우즈, Mac, Linux)에서 소스코드를 빌드하기 위해 사용되는 빌드 시스템입니다.)

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

⑤ 패키지 매니저 파일(package.json) 1
Node.js는 모듈 시스템을 가지고 있습니다. 최근에 이 모듈 시스템이 go와 java에서 언어 자체적으로 구현이 되는 스펙들이 발표되었습니다. (go는 처음부터 구현됐습니다.) 이 모듈 시스템을 관리하는 프로그램은 3rd 파티 프로젝트로 떼어 놓는 것이 일반적이죠. 그런데 노드는 npm이라는 패키지 매니저가 관리하는 package.json. 파일이 main() 함수에서 찾도록 되어있어 npm에 의존적인 커뮤니티로 만들었다는 점을 스스로 비판했습니다. 최근 facebook에서 만든 yarn이라는 패키지 매니저가 npm을 대체하고 있지만 package.json은 그대로 사용하고 있습니다. 의도하진 않았지만 defacto(사실상의 표준)가 된 셈이죠.
또, 이 package.json 파일은 모듈을 찾을 때 명시적이지 않다는 단점도 있습니다. 쉬운 이해를 위해 아래 그림을 참조하시기 바랍니다.

패키지 매니저 파일 [그림3] somemodule을 찾아라! (출처: http://tinyclouds.org/jsconf2018.pdf)

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

⑦ 모듈 시스템(node_modules)
위에서 언급한 파일 디렉터리 기반 모듈 시스템의 약점과 마찬가지로 모듈을 가져오는 알고리즘이 복잡해졌습니다. 또, 브라우저에서 가져오는 방법과도 맞지 않아 굉장히 어려워졌죠. 그럼에도 불구하고 돌이킬 수 없다는 사실에 커뮤니티에 미안함을 전했습니다.

⑧ Require 문법을 쓸 때 js 확장자를 안 써도 되게 한 것
브라우저 내 자바스크립트가 작동하는 것과 표준이 달라서 모듈 로더가 사용자의 의도를 파악하기 위해 많은 고민을 해야 한다는 점을 언급했습니다.

⑨ index.js
브라우저가 index.html을 default로 갖기 때문에 index.js를 지정한 것이 당시엔 괜찮은 생각 같았으나, 결과적으로 모듈 로딩 시스템을 더 복잡하게 만들었다고 합니다.

⑩ deno
라이언 달은 이상의 10가지 이야기를 마치고 나서 새로 만들고 있는 프로젝트를 공개했는데, 그게 바로 ‘deno’ 프로젝트입니다. (프로젝트 링크: https://github.com/ry/deno)

TypeScript Runtime [그림4] TypeScript Runtime

아직은 프로토타입처럼 시작에 불과한 프로젝트지만, 우리는 그동안 Node.js를 통해 이렇게 작은 소스코드가 얼마나 커질 수 있는지 확인해 왔습니다.

deno의 가장 기본적인 특징은 TypeScript를 Runtime으로 가진다는 것입니다. 트랜스 파일이 아닌 런타임 지원이라는 중요한 특징이죠.

package.json이나 npm이 아닌 source code url만 import 할 수 있습니다. 아래 내용을 살펴보시죠.

import { test } from "https://unpkg.com/deno_testing@0.0.5/testing.ts"

import { log } from "./util.ts"

require가 아니라 import 명령어를 사용하고, 확장자 .ts를 지정하며, url로 임포트 한다는 것을 알 수 있습니다.

파일시스템과 네트워크는 샌드박스 모델을 사용했기 때문에 인터페이스를 통해서만 가능하며, 현재는 프로토콜 버퍼를 통해 V8 엔진과 인터페이스 할 수 있습니다. 빌드 스크립트에는 gn과 ninija를 사용합니다.

빌드 스크립트 [그림5] Goodbye gyp!

그 외에도 라이언 달이 스스로 후회하는 점들을 모두 바로잡아 둔 것을 확인할 수 있습니다. 흥미로운 것은 브랜치 중 golang이 포함되어 있다는 것입니다.

브랜치에 포함된 golang [그림6] 브랜치에 포함된 golang

브랜치로 가 보면, go로 빌드하는 인스트럭션이 나와 있는 걸로 봐서 go 빌드를 고려했다가 gn으로 선회한 것으로 보입니다. (혹시 아닌 경우, 댓글을 달아주시면 수정하겠습니다.)

3. 맺으며

아직은 좀 더 두고 봐야 하는 프로젝트지만, 아마도 Node.js 진영에서 이러한 변화를 강 건너 불구경하듯 가만있지는 않을 듯합니다. 현재로서는 Node.js에 합칠 수 없어 오랜 시간의 단련이 필요해 보이지만, 서버사이드 스크립트 엔진의 새로운 시작이라고 여기며 계속 주목해야 할 것 같습니다.



▶   해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 기고자에 저작권이 있습니다.
▶   해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금하고 있습니다.

도경태 프로
도경태 프로 IT테크놀로지 전문가
삼성SDS 개발실

SCP(SDS Certified Professional)로 삼성SDS에서 테크리드를 담당하고 있습니다. OSGeo에서 오픈소스 활동을 하고 있습니다. 잘 모르는 기술에 대해서 낯선 사람들과 이야기 하면서 배워 나가는 것을 좋아합니다.

구독하기

인사이트 리포트 소식을 메일로 받아보세요