Deno에 대해서 알아보자

안녕하세요 Devport 입니다. 이번 포스팅에서는 Deno에 대해서 알아보도록 하겠습니다.

Deno?

Deno는 node.js를 창립자인 라이언달에 의해서 만들어졌습니다. 라이언 달은 node.js를 만들면서 아쉬웠던 부분들과 Deno에 대하여  JsConf 2018에서 "10 Things | Regret About Node.js"에서 이야기를 하였죠.

라이언달이 말했던 10가지의 아쉬웠던 부분들은 무엇이 있을까요?

1. Promise를 고집하지 못했던점.
2. 보안문제
3. GN으로 빌드 시스템을 업데이트 하지 못한 부분
4. 빌드시스템에 C++대신 FFI를 제공하지 못한점
5. package.json으로 인하여 Npm에 대한 의존도가 높아진점
6. 모듈 시스템에 폴더화로 인하여 파일이 증가한점
7. node_modules 구조로 인하여 알고리즘이 복잡해진점
8. require 문법에서의 .js를 쓰지 않은 점
9. inde.js 의 실수 

1가지가 부족하지만 주요한 부분들은 위 9가지 였습니다.

Deno의 홈페이지를 들어가보면 처음부터 있는 문구에서 느껴지듯이 Deno는 javascript, typescript, secure를 강조하고 있습니다. node.js에서의 아쉬웠던 보안적인 부분과 새롭게 뜨고 있는 TypeScript를 강조하고싶어하는 것 같습니다.

 

기본으로 지원하는 TypeScript

 Deno는 Typescript를 사용할 수 있는 초기 구성없이 바로 런타임 할 수 있습니다. 이점은 typescript -> javascript로 트랜스파일 할 필요가 없다는 점입니다. Typescript의 기본 설정이 아닌 사용자 설정이 필요하다면 tsconfig.json파일을 "--config=<file>"로 적용할 수 있습니다.

 

보안

Deno는 프로그램이 허용하는 것 이외의 다른 작업을 수행하지 못하도록 하는 sandbox기반 보안 모델을 가지고 있습니다. 예를 들어 프로그램이 네트워크에 접근하기 위해서는 권한을 부여해줘야 합니다.

deno run --allow-net app.ts

위 권한 이외에도 다른 권한을 지정해줘야합니다.

• --allow-env: 환경 액세스 허용
• --allow-hrtime: 고해상도 시간 측정 허용
• --allow-net=<allow-net>: 네트워크 액세스 허용
• --allow-plugin: 플러그인로드 허용
• --allow-read=<allow-read>: 파일 시스템 읽기 액세스 허용
• --allow-run: 하위 프로세스 실행 허용
• --allow-write=<allow-write>: 파일 시스템 쓰기 액세스 허용
• --allow-all: 모든 권한 허용(-A)

EcmaScript 모듈

외부 모듈을 로딩할때에 node.js에서는 require라는 함수를 사용하는 CommonJS를 사용하였습니다.

Deno에서는 EcmaScript 모듈을 사용함으로써 Web과 같은 모듈 로딩을 할 수 있습니다.

 

Local Cache

node.js에서 외부 종속 모듈을 npm으로 설치하게 되면 node_modules에 설치 되는 로직을 가지고 있었습니다.

하지만 Deno에서는 소스에서 import 하는 외부 Url을 지정할 경우 관련 모듈이 내부 프로젝트에 저장되는 것이 아닌 전역 캐쉬 디렉토리에 저장됩니다. (기본적으로 ~/.deno/src)

단일 실행 파일과 단일 결과물

Deno는 종속성이 없는 단일 실행 파일로 되어있습니다. windows 환경에서 node.js(좌)와 Deno(우)의 압축파일을 해제 해보면 비교가 될 것 같습니다.

Deno를 설치하기 위해서 CLI를 사용하여 설치하거나 release page에서 각 환경의 릴리즈 바이너리를 다운로드 할 수 있습니다. 

node.js의 모듈식 바이너리와 다르게 Deno는 단일 어플리케이션입니다.

node.js와 같이 외부 모듈을 관리하는 Npm을 사용하지 않습니다. 대신 Deno에서는 개발자가 직접 소스코드의 URL을 사용하여 종속성을 선언합니다. Deno에서 Third Party Module을 사용하기 위해서는 Deno에서 제공하는 Deno 스크립트 호스팅 서비스인 "deno.land/x"를 통해 외부 모듈을 사용할 수 있습니다. 물론 Node.js용으로 작성된 Npm 패키지와는 호환되지 않습니다.

 

Typescript와 Javascript 외에도 Deno는 WebAssembly를 지원하여 WebAssembly 모듈을 로드하고 실행할 수 있습니다. 

또한 Rust로 Deno를 확장할 수 있습니다. 이를 통해서 Rust의 의존성/패키지 관리 시스템인 Cargo를 Deno 플러그인 및 애드온을 관리하는데에 사용할 수 있습니다.

 

효율적인 배포를 위해서 Deno에서는 "deno bundle" 명령을 통해서 단일 .js 파일이 생성할 수 있습니다. 제가 경험해 본 바로는 node.js에서 bunddling을 해봤지만 결코 쉽지 않았었습니다.

내장 테스트 지원

Deno에서는 javascript와 typescript 코드를 테스트 할 수 있도록 기본적으로 제공하는 함수가 있습니다.

javascript의 테스트 라이브러리인 Jest와 Jasmine의 문법과 매우 유사합니다.

Deno 또한 Namespace의 테스트 기능을 사용하여 테스트를 만들수 있습니다. "deno test" 명령으로 테스트를 진행할 수 있지요.

Deno의 제한점

Deno는 Node의 Fork 프로젝트가 아니며 완전히 새롭게 구현된 것이기 때문에 node와 다른 문제가 발생할 수 있습니다.

우선 커뮤니티에서 거론되는 중요한 부분을 확인해 보겠습니다. 밑에 거론되는 내용들도 시간이 지나면 하나씩 해결될 이슈라고 생각이 듭니다.

호환성

Deno는 일반적으로는 node.js의 Npm과 호환되지 않습니다. 하지만 "https://deno.land/std/node/"로 호환될 수 있도록 하는 라이브러리가 있지만 완성적이지는 않아 불완전한 모듈로 보입니다.

이미 많은 open source 상에 Node.js 관련 라이브러리가 생성되어 있기 때문에 Deno에서도 이를 추후 사용할 수 있다면 좋을 것 같습니다.

TSC 병목

내부적으로 Deno는 Microsoft의 TypeScript 컴파일러를 사용하여 Type을 확인하고 Javascript를 생성하고 있습니다.

이로 인하여 V8이 Javascript를 컴파일 시간과 비하여 매우 느립니다. 이에 대하여 개발진도 문제를 인식하고 있어 문제를 해결하려 노력하고 있는것으로 보입니다.

HTTP 서버 성능

hello-world HTTP 서버를 Deno와 node.js로 구분하여 비교를 해본다면 

• [Deno] 요청: 25K, 평균 대기 시간: 1.3ms
• [Node.js] 요청: 34k, 평균 대기 시간: 2~300ms

지연시간이 일정하다는 부분에서 Deno가 좀더 안정적인 모습을 보여줍니다. 하지만 초당 처리 쿼리 수는 Node.js에 비해 부족해 보입니다. 이 또한 로직 개선으로 여지가 있는 것 같습니다.

마치며

node.js로 5년 동안 개발을 해왔던 입장에서 라이언 달과 같이 저 또한 node.js에서의 아쉬웠던 부분들이 많았습니다. deno는 node.js의 아쉬웠던 부분들을 많이 개선하고 있는 모습을 보여주고 있어 앞으로 기대가 됩니다. 앞으로 커뮤니티가 더욱 활성화 되고  Third Party Module이 많이 개발이 된다면 node.js 에서 deno로 새롭게 재편되지 않을까 생각이 됩니다.