오랫동안 Deno를 주력 런타임으로 써 온 개발자가 최근 SvelteKit 클라이언트 프로젝트를 진행하며 다시 Node.js로 돌아선 경험을 공개했다. 그의 결론은 간단하다. Node가 몰라보게 좋아졌다는 것이다. 한동안 Node를 떠나 있던 탓에 사용법마저 잊었던 그는, 돌아와 보니 최신 ECMAScript 문법이 대부분 지원되고 과거의 불편했던 API들이 현대적으로 교체돼 있었다고 전한다. 무엇보다 이제는 require()를 마주칠 일이 없다는 점을 반겼다.
이 글이 한국 실무자에게 의미 있는 이유는, 단순한 '취향 선언'이 아니라 런타임 전환 과정에서 마주치는 구체적인 결정들을 짚고 있기 때문이다. 버전 관리부터 패키지 매니저, TypeScript 배포, 빌드 성능까지 Node 생태계로 복귀할 때 실제로 고민하게 되는 지점들이 비교적 솔직하게 담겨 있다.
설치와 패키지 매니저 선택
필자는 Node 공식 문서가 여전히 인터넷 스크립트를 bash로 직접 파이프해 NVM을 설치하라고 권한다는 점을 비판적으로 언급한다. 과거 NVM과 NPM 경험이 좋지 않았던 그는 버전 전환이 더 낫다고 알려진 FNM(Fast Node Manager)을 택했다. 최신 버전을 선호하면서도 클라이언트 프로젝트에서는 안정성이 필요하다는, 많은 실무자가 공감할 딜레마를 드러낸 대목이다.
패키지 매니저로는 보안을 이유로 PNPM을 골랐다. PNPM은 설치 후 자동 실행되는 post-install 스크립트를 기본 차단한다. 그는 공급망 공격을 의식해 pnpm-workspace.yaml에 패키지의 최소 배포 경과 기간을 두는 설정까지 추가했다. 처음에는 한 달로 잡았으나 의존성 버전 매칭에 문제가 생겨 결국 하루로 타협했다고 한다. 과장과 냉소가 섞인 표현이지만, 신규 배포본을 곧바로 끌어오지 않고 일정 기간 묵혀 두는 방식은 npm 생태계의 실제 공급망 위협에 대응하는 현실적인 완충 장치다.
TypeScript 패키지라는 벽
가장 눈여겨볼 지점은 TypeScript 처리다. 이제 Node는 별도의 까다로운 설정 없이도 TypeScript 파일을 직접 실행할 수 있다. 그러나 node_modules 경로 아래의 TypeScript 파일은 처리하기를 거부한다. 필자는 이것이 기술적 제약이 아니라 철학적 결정이라고 설명한다. 패키지 작성자들이 TypeScript로 쓴 코드를 그대로 npm에 올리는 것을 막기 위한 장치라는 것이다. 결국 패키지를 배포하려면 타입을 걷어내고 번들링하는 도구가 필요했고, 그는 Tsdown을 선택했다. 다만 이 과정에서 설정용 dotfile이 늘어나는 점은 달가워하지 않았다.
여기에 더해 그는 Microsoft의 GitHub 운영 방식에 불만을 품고 Forgejo 인스턴스를 직접 호스팅하고 있다. 이 때문에 자신의 패키지가 npm에서 'provenance'(출처 증명)를 잃게 됐고, PNPM의 신뢰 정책을 직접 조정해 자기 패키지를 허용해야 했다고 밝힌다. 공식 레지스트리 바깥에서 자체 인프라를 운영할 때 치러야 하는 비용을 보여주는 사례다.
마이그레이션의 실제 비용
마지막 시험은 정적 사이트 생성기를 Deno에서 Node로 옮기는 작업이었다. 결과는 의외로 가벼웠다. Node v26.10.0 환경에서 필요한 변경은 Deno의 파일 시스템 API를 node:fs로 바꾸고, Deno.serve를 node:http를 감싼 Hono의 Node 어댑터로 교체하며, Deno의 @std/path를 node:path로 바꾸는 정도였다. 특히 node:path는 단순 import 교체만으로 끝났다. 코드베이스가 여전히 Deno 관용구에 맞춰져 있는데도 빌드 속도가 15% 빨라졌다는 점에 그는 놀라워했으며, Node 내장 API를 제대로 활용하면 성능 여지가 더 남아 있을 것으로 봤다.
글 후반부에서 그는 Deno에 대한 아쉬움을 토로한다. 혁신적인 현대 자바스크립트 런타임으로 출발했던 Deno가 실리콘밸리식 '성공' 기준을 좇으면서 매력을 잃었다는 평가다. 인력 감축과 제품 방향에 대한 실망, JSR에서 계정을 삭제한 경험까지 언급하며, 오늘날 Deno 런타임을 굳이 쓸 이유가 없고 Node가 꾸준히 따라잡아 일부 영역에서는 앞섰다고 결론짓는다.
물론 이 글은 한 개인 개발자의 경험담이자 다분히 주관적인 논평이라는 점을 감안해 읽어야 한다. 성능 수치는 단일 프로젝트의 체감이고, Deno에 대한 평가도 감정이 실려 있다. 그럼에도 런타임 선택을 저울질하는 실무자라면, 최신 Node가 TypeScript 실행과 표준 라이브러리 면에서 상당히 성숙했으며 Deno에서의 이전 비용이 생각보다 낮아졌다는 신호만큼은 참고할 만하다. 동시에 TypeScript 패키지 배포 제약이나 출처 증명 관리처럼, Node 생태계로 돌아올 때 여전히 감수해야 하는 마찰도 분명히 존재한다.