IT/모바일
최신 자바스크립트 런타임 알아보기
『디노 첫걸음』 중
기존의 구식 기술 스택을 바꾸는 것 말고도 라이언은 디노로 무엇을 해결하려 했을까? 그는 노드가 적절히 해결하지 못하는 다양한 문제가 있음을 알게 되었고 이는 영구적인 기술 부채tech debt로 남았다.
· · ·
보안이 취약한 플랫폼
라이언은 노드가 안전하지 않은 플랫폼이며 이를 잘 이해하지 못한 개발자가 불필요한 실행 권한을 부여하거나 안전하게 보호되지 않은 시스템 서비스에 접근하는 코드를 구현하면서 보안 구멍이 만들어진다는 걸 깨달았다.
즉 노드로 특정 URL에 TCP로 요청을 보낼 수 있는데 이를 완벽하게 제어하지 못한다면 요청을 받는 쪽에 문제가 생긴다. 호스트 컴퓨터의 네트워크 서비스 사용을 막는 장치가 아무것도 없기 때문이다. 적어도 노드에는 그런 보호 장치가 없다.
마찬가지로 2018년에 아주 유명한 노드 모듈 저장소가 소셜 해킹(모듈 개발자가 해커에게 속아 코드 접근 권한을 줌)을 당했는데 해커는 누군가가 가진 비트코인 지갑의 코인을 훔치는 코드를 숨겨놓은 상태였다. 노드에는 기본적인 보안이 없으므로 이 모듈은 사용자 컴퓨터의 특정 경로에 접근할 수 있었다(모듈이 의도한 기능이 아님에도). 만약 모듈이 어떤 경로를 읽으려 했을 때 사용자에게 이를 허용할 것인지 묻는 알림창이 나타난다면 이는 큰 위협이 되지 못한다.
모듈 시스템의 문제
모듈 시스템에도 문제가 있었다. 라이언은 비동기 I/O, 이벤트 방출기 등의 기능은 공을 들여 잘 만든 데 비해 내부 설계는 즉흥적으로 이루어졌다고 생각했다. 노드 생태계에서 npm을 표준 패키지 관리자로 사용한 점을 후회하며 npm의 중앙화되고 비공개적인 저장소 관리 방식을 좋아하지 않았다. 라이언은 브라우저가 의존성dependency을 임포트하는 방식이 더 깔끔하며 쉽게 유지보수할 수 있다고 생각했다.
다음처럼 간단히 의존성을 추가할 수 있다.
<script type="text/javascript" src="http://yourhostname/resources/module.js" async="true">
매니페스토manifesto 파일(예를 들어 package.json)에 새 진입점을 구현하고 이를 직접 설치(npm이 패키지를 설치하지만 여전히 명령어를 실행해야 하므로)하는 것보다는 훨씬 간단하다.
라이언은 package.json 파일 전체에 불만이 있었고 이 파일을 정의했을 때 실제 내용을 고려하도록 require 함수 로직을 바꿨다. 하지만 파일 문법에 의해 추가된 ‘잡음noise’(작성자 정보, 라이선스, 저장소 URL 등)을 그가 더 잘 처리할 수 있었을 거라고 생각한다.
라이언은 가능하면 모듈을 저장하는 폴더(node_modules)를 없애고 싶었다. 이는 아마 대부분의 노드 커뮤니티가 동의하는 사항일 것이다. 특히 여러 활성 프로젝트를 가진 개발자라면 모두 폴더 크기 때문에 불만을 토로했다.
프로젝트에 로컬로 폴더를 유지하는 이유는 본인이 설치하는 내용을 헷갈리지 않기 위함이다. 물론 깔끔한 해결책은 아니지만 문제는 해결되었다.
다른 사소한 문제
확장자를 지정하지 않고 로컬 모듈을 요청require하는 기능처럼 노드에는 다른 사소한 문제도 있었다. 이는 개발자의 경험을 개선하기 위해 제공되었지만 결국 필요 한 모듈을 정확히 이해하려면 여러 확장자를 확인하는 로직을 추가해야 하는 결과를 낳았다.
index.js 파일과 관련한 암묵적 동작(폴더를 요청할 수 있는데 이때 기본적으로 폴더 안의 index.js 파일을 요청한다)도 문제다. 라이언은 강연에서 이를 웹의 index.html 파일의 동작을 흉내 낸 ‘귀여운’ 기능이라고 표현했다. 하지만 결과적으로 이는 개발자의 경험을 크게 개선하지 못했으며 기능을 만든 사람이 의도하지 않은 패턴을 만들어냈다고 필자는 생각한다.
결국 라이언은 본인이 만들거나 참여했던 많은 기능을 더 제대로 만들고 싶다는 후회를 동기로 전환해 디노를 탄생시켰다.
· · ·
이전 글 : 플러터, 누가 사용하면 좋을까?
다음 글 : 합성 데이터는 어디에 활용될까?
최신 콘텐츠