TL;DR

  • Node.js v26.10.0이 현대화된 자바스크립트 API와 타입스크립트 실행을 갖추면서, Deno를 오래 사용해 온 경험에도 다시 선택할 만한 런타임이 됨.
  • 버전 관리에는 fnm, 패키지 관리에는 설치 후 스크립트를 차단하는 pnpm을 사용하고, 악성 패키지 지연을 위한 설정을 적용함.
  • Node.js는 node_modules 내부의 타입스크립트 파일 처리를 허용하지 않아 패키지 배포 시 tsdown 같은 번들러가 필요함.
  • 정적 사이트 생성기를 Deno에서 Node.js로 최소한만 이전한 결과, 빌드가 15% 빨라졌으며 주요 변경은 파일 시스템 API와 HTTP 서버 어댑터 교체였음.
  • Deno의 혁신 정체와 안정성 문제, JSR의 요청 제한 등을 겪은 뒤 런타임을 제거하고 Deno와 작별함.

Node로 돌아오다

  • SvelteKit 클라이언트 프로젝트에서 한 달 동안 Node를 집중적으로 사용하며, ECMAScript 기능이 지원되고 과거의 불편한 API가 현대화된 점을 확인함.
  • 오랫동안 기본 런타임으로 사용한 Deno에 익숙해져 Node 사용법을 잊고 있었지만, 이제는 require()를 볼 필요가 없음.
  • Oracle 상표권 분쟁이 긍정적인 방향으로 끝날 것 같지는 않다고 봄.

패키지 관리

  • 공식 Node 문서는 Node와 npm 관리를 위해 인터넷 스크립트를 내려받아 곧바로 bash에 전달해 nvm을 설치하도록 권장함. 과거 nvm과 npm을 사용한 경험은 좋지 않았음.
  • Node 버전 전환에는 nvm보다 낫다고 들은 Fast Node Manager(fnm)를 선택함. 최신 버전을 선호하지만 안정성이 필요한 클라이언트 프로젝트도 있음.
  • 패키지 보안 문제를 피하려고 pnpm을 선택함. 일부 스크립트가 실행 파일 이름을 하드코딩해 npm은 pnpm으로, npx는 pnpx로 별칭을 설정함.
  • 설치 안내서에서 npm이 있다고 가정한 단계를 복사할 때 별칭이 도움이 됨. 바이너리 심볼릭 링크를 만들었던 경험과 혼동했을 가능성도 있음.
  • pnpm은 설치 후 스크립트 실행도 차단함. npm이 여전히 이런 스크립트를 무조건 실행하는지는 의문임.
  • 악성 패키지 업데이트를 늦추려고 pnpm-workspace.yaml에 최소 출시 대기 시간 1,440분과 다운그레이드를 허용하지 않는 신뢰 정책을 설정함.
  • 처음에는 Microsoft가 신고된 악성 코드를 제거하는 데 적어도 한 달은 걸린다고 보고 최소 출시 대기 시간을 한 달로 설정했으나, pnpm이 적합한 버전을 찾기 어려워하는 의존성 문제가 발생함.
  • 다른 누군가가 새 Shai-Hulud 패키지를 시험해 볼 시간을 주기에 충분한 기간으로 보고, 대기 시간을 하루로 조정함.

TypeScript

  • Node는 조건이 까다롭지 않아도 타입스크립트를 실행할 수 있지만, 타입스크립트 패키지를 npm에 그대로 배포하는 일은 간단하지 않음.
  • node_modules 경로 아래에 있는 파일은 타입 제거 방식으로 처리할 수 없다는 ERR_UNSUPPORTED_NODE_MODULES_TYPE_STRIPPING 오류가 발생함.
  • Node.js는 패키지 제작자가 node_modules 아래에 타입스크립트 파일을 배포하지 못하도록 해당 파일 처리를 거부함.
  • 이는 기술적 제약이라기보다 철학적 판단으로 보임. 타입스크립트는 Microsoft 제품이며, 이를 허용하면 생태계 전체가 오염될 수 있다는 생각에는 공감하지만 Microsoft 제품이 더 늘어나는 것은 바라지 않음.
  • ECMAScript에 가벼운 네이티브 타입 기능이 포함되기를 바라지만, 타입 주석 제안이 결실을 보기 전에 은퇴할 것 같다고 봄.
  • 타입스크립트 패키지를 사용할 수 없어 번들링 도구로 tsdown을 선택함. 설정용 숨김 파일 두 개가 추가로 필요했으며, 숨김 파일 하나하나가 실수의 흔적이라고 여겨 달갑지 않았지만 deno.json 등을 삭제해 균형을 맞춤.
  • Microsoft 종속 문제와 GitHub에 대한 불만으로 자체 Forgejo 인스턴스를 호스팅함. npm의 제약으로 패키지의 출처 증명이 사라져, 자체 패키지를 허용하도록 pnpm 신뢰 정책을 설정해야 했음.

웹사이트 이전

  • Node의 최종 시험으로 정적 사이트 생성기를 Deno에서 이전함. 몇 버전 전 Node였다면 대대적인 리팩터링이 필요했겠지만, Node.js v26.10.0에서는 필요한 작업이 놀라울 만큼 적었음.
  • 필수 변경은 Deno 파일 시스템 API를 크게 개선된 node:fs로 교체하고, Deno.serve를 node:http를 감싸는 Hono의 Node 어댑터로 바꾸는 작업이었음.
  • 최소한의 이전만 마친 뒤 빌드 속도가 15% 빨라진 것을 확인함. 코드베이스는 여전히 관용적인 Deno 방식을 따르고 있어, 다른 내장 Node API를 사용하지 않아 성능을 더 끌어내지 못하고 있을 가능성이 있음.
  • 추가 변경은 Deno의 @std/path를 node:path로 바꾼 것뿐이며, 가져오기 경로만 교체하면 됨.
  • 중간 요약은 Node가 크게 개선됐다는 감탄임.
  • Deno를 계속 사용한 이유는 습관과 익숙함이었으며, 최근에는 서버 측 자바스크립트 작성에 별다른 흥미가 없었음.

Deno의 쇠퇴

  • Deno가 실리콘밸리의 소란스러운 분위기에 성공의 기준을 맡긴 순간 실패했다고 봄. 혁신적인 현대 자바스크립트 런타임에서 매력 없는 제품을 만드는 평범한 스타트업으로 변했고, 직원 절반이 해고된 뒤 남은 직원들은 인공지능에 대한 환상을 게시하고 Temu판 Cloudflare를 분위기 코딩하고 있다고 비판함.
  • 현재 Deno 런타임을 쓸 이유가 없다고 봄. Deno Land Inc.는 오래전부터 런타임 혁신을 멈췄으며, Node가 꾸준히 따라잡아 일부 영역에서는 Deno를 앞섬.
  • Deno를 떠나게 한 문제는 몇 주 동안 고쳐지지 않은 ZSH 통합, JSR의 공격적인 429(요청이 너무 많음) 응답, 동시 HTTP 요청을 처리할 때 Deno가 멈추는 버그임.
  • 이런 문제는 다른 비판에 더해 Deno를 거의 사용할 수 없는 수준으로 만듦. 요청하자 JSR 지원팀은 계정을 빠르게 삭제했으며, 인터넷에 사용하지 않는 프로필을 남겨 두고 싶지 않았음.
  • 패키지는 더는 표시되지 않지만 이전 버전은 여전히 설치 가능함.
  • 초창기에는 즐거웠지만 이제 작별할 때라고 보고 brew uninstall deno로 Deno를 제거함.