이 문서는 Deno 전문가의 의견을 담은 게시물이 아닙니다. 필자는 Deno를 사용해 본 적도 없고 전문적인 지식을 가지지도 않았기에 “아 그냥 이런게 있나보다” 정도의 정보만을 제공합니다.
데노? 디노?
2018년 처음 소개 될 당시에는 ‘데노’ 라고 발음 되었지만, 심볼의 공룡과 어감으로 인해 ‘디노’라고 불리게 된 Javascript Runtime입니다.
개발 계기
Deno는 Ryan dahl이라는 개발자에 의해서 개발이 되었습니다.
아는 사람은 아시겠지만 Ryan dahl은 NodeJS의 아버지입니다. Javascript를 지금과 같은 메이저 언어로 부상시킨 위인이죠.
Deno는 NodeJS 개발 이후 마음에 들지 않는 부분들을 수정하고 개편하여 만든 새로운 에코시스템이라고 합니다.
중앙 집중 형태
NodeJS는 이미 굉장히 거대해진 오픈소스 생태계입니다.
이 생태계에는 수많은 오픈소스들이 관리되고, 새로 생성이 되는데 이를 중앙에서 관리하는 서비스가 바로 NPM입니다.
그런데 이 NPM은 Closed Source 회사가 관리한다는 아이러니가 존재합니다. 이미 수많은 오픈소스가 존재하고 새로 생겨나는 이 거대한 플랫폼이 누구 하나의 전유물이라는거죠.
물론 현재의 소유주인 Microsoft는 개발자 친화적으로 행동하고 있고, NPM의 소유 권한을 행사하여 오픈소스의 의미가 퇴색될만한 일을 벌일 것이라고 생각이 되지는 않습니다만 사람 일이라는건 모르는거니까요.
보안
오픈소스를 사용하실 때 해당 라이브러리의 코드를 모두 열어보고 해석하여 사용하시는 분 계신가요?
그런 분이라면 이 부분에 딱히 공감을 못하시겠지만, 대부분의 개발자는 “아 그런가보다” 하고 Usage만 대충 읽은 다음 npm install ...을 입력합니다.
사실 이건 다른 산업 분야의 관점으로 바라보자면 매우 이상한 일입니다.
일면식도 전혀 없는 사람에게 집 열쇠, 계좌 비밀번호, 인감 도장, 신분증 등을 모두 공개한 다음 “자 이제 이걸로 나에게 이로운걸 해줘!” 라고 말하는 꼴이거든요.
현재 오픈소스 생태계는 개발자 전원의 신뢰로 이루어지고, 이게 또 잘 돌아가니까 딱히 별 다른 문제를 느끼지는 않습니다만 만약 오픈소스 개발자가 자신의 패키지에 보안 상 위험한 코드를 집어넣는다면 무슨 일이 벌어질까요?
NodeJS는 사용자 컴퓨터에 존재하는 모든 리소스에 대한 접근 권한을 가집니다. 그렇기에 NodeJS 환경에서 구동되는 라이브러리도 실행자의 컴퓨터 자원에 접근이 가능합니다.
당연한거겠죠. 컴퓨터에 설치하고 실행하는 소스코드니까요.
그런 생태계에서 마음만 먹는다면 불특정 다수의 컴퓨터 자원을 특정 서버로 전송하는 일까지도 가능합니다.
Deno는 코드를 직접적으로 다운로드 받는 것이 아닌, Sandbox에서 실행을 하기에 해당 이슈를 발생시킬 원인 자체를 차단한다고 합니다.
패키지 관리
node_modules는 의존성 패키지가 설치 되는 폴더입니다. 그 디펜던시는 package.json 파일에 의해서 관리됩니다.
그런데 node_modules 폴더 안에 있는 패키지를 하나 열어보시면 그 안에도 package.json 파일이 존재하며, 이 파일 안에는 해당 패키지가 의존하는 또 다른 패키지들의 목록이 존재합니다.
이렇게 되면, 내가 필요해서 직접적으로 설치한 패키지와, 디펜던시의 디펜던시가 서로 중복 설치 될 가능성이 존재합니다. 번들 파일의 사이즈가 불필요하게 무거워지게 되는거죠.
유령 의존성
예를 들어, A라는 패키지는 B라는 패키지와 의존성을 갖습니다.
내가 필요한건 A 패키지라서 프로젝트에는 A만을 설치했는데, B 패키지도 사용이 가능하다는 문제가 있는거죠. 이럴 경우, A 패키지만 삭제해도 A와 의존관계에 있는 B까지 같이 삭제되어 B 패키지를 사용하는 모든 부분에서 이슈가 발생한다는 문제를 야기합니다.
Deno는 package.json node_modules를 모두 제거하였기 때문에 위 문제점들이 발생하지 않습니다.
마치며
2018년에 처음 발표가 된 생태계이고, 이미 대다수의 Javascript 개발자가 NodeJS 진영에 포진해 있는 점에서 생각해보면 Deno는 현재 모든 회사들이 필수적으로 고려해야 할 정도로 영향력을 가졌다고 생각되진 않습니다. 다만, Deno의 탄생 배경에서 설명하는 문제점들이 실제로 NodeJS 진영에서 벌어지고 있고 이를 개선하는데 동참하는 사람들이 결코 적지도 않습니다. 그러니 추후에는 여러 개발자들이 회사의 프로젝트에서 Deno를 고려해보는 시대가 올 것이라 추측해볼 수도 있을 것 같습니다.