요약
클라우드플레어가 디노 팀 전원을 데려가고, 디노 런타임 개발은 1년 뒤 끝납니다.
디노를 만든 라이언 달이 회사 블로그에서 팀 전원이 클라우드플레어에 합류한다고 발표했습니다. 런타임과 호스팅 서비스를 따로 키우는 대신 클라우드플레어의 Workers 플랫폼에 힘을 모으기로 했다고 밝혔습니다.
왜 중요한가
- 디노 위에 서비스를 만든 기업은 1년 안에 다른 런타임으로 옮기거나 커뮤니티의 후속 개발에 기대야 합니다.
- 독자 런타임을 키우던 팀이 Workers 방식을 서버 개발의 기본값으로 만드는 쪽으로 방향을 바꿨습니다.
- 달은 이번 결정이 디노 사용자에게 큰 변화라는 점을 스스로 인정했습니다.
핵심 내용
- 디노 런타임은 1년간 매달 버그·보안 수정판을 낸 뒤 개발을 멈추고, 오픈소스로 남아 누구나 이어받을 수 있습니다.
- Deno Deploy는 6개월 더 운영한 뒤 문을 닫고, 유료 고객이 Cloudflare Workers로 옮기도록 돕습니다.
- 패키지 저장소 JSR은 계속 운영하며, 서버 기반은 클라우드플레어로 옮깁니다.
- 팀은 Workers·Durable Objects(상태를 저장하며 도는 서버리스 실행 단위) 팀과 합쳐 일하게 됩니다.
- 달은 Durable Objects가 싼 실행 비용과 지속 상태, 웹소켓을 갖춰 AI 에이전트를 돌리기에 알맞다고 봤습니다.
HN 반응
- 런타임 지원 종료를 글 끝에 묻어 뒀다는 비판과 함께, 오래 유지할 서비스라면 Node.js에 머무는 편이 안전하다는 의견이 이어졌습니다.
- 하루면 다른 런타임으로 옮길 수 있다는 반론에는, 설치 없이 패키지를 바로 불러오는 스크립트 실행과 내장 도구는 대체하기 어렵다는 재반론이 붙었습니다.
그러니까 다른 누군가가 개발을 넘겨받지 않으면 Deno는 더 이상 지원되지 않는다는 얘기입니다.
이런 엄청난 내용을 글 맨 아래에 슬쩍 묻어 놨네요. 최근 몇 년 사이 Deno에 올인한 회사가 정말 많습니다. Node.js에서 대규모로 갈아탄 곳도 있고요. 안됐지만, 새롭고 반짝이는 것을 쫓다 보면 오래되고 믿을 만한 것을 지킬 때보다 위험이 큰 법이죠.
정말로 "그렇게 많은 회사"가 썼다면 이런 상황에 처하지 않았겠죠. 행간을 읽어 보면 Deno가 성공한 프로젝트가 아니었다는 건 분명합니다.
그래서 장기 유지보수가 중요한 회사라면 대체 런타임을 써야 할 만한 이유가 있는 경우가 아닌 한 Node.js를 고수해야 하는 겁니다.
Bun도 언젠가 버려진다 해도 놀랍지 않을 것 같습니다.
(그래서 저는 새 런타임이 나오는 건 반갑지만, 진지하게 쓰거나 도입할 만큼 신경 쓰지는 않습니다.)
경쟁 덕분에 Node가 더 나아졌다면 그걸로 된 거죠.
커뮤니티끼리 늘 경쟁하는 건 아니잖아요.
아뇨, 경쟁합니다. 오픈소스 제품 A가 경쟁하는 오픈소스 제품 B보다 기능이 나은 게 없으면 사용자들은 더 나은 A로 옮겨 가고, 얼마 안 가 B를 쓰는 사람은 거의 없어집니다. BSD와 리눅스를 보세요. "BSD로 갈아탔습니다"나 "리눅스로 갈아탔습니다" 같은 글, 그리고 어느 한쪽을 옹호하는 논쟁이 시도 때도 없이 올라옵니다. 승자와 패자가 있냐고요? 있습니다. 더 큰 커뮤니티, 더 많은 개발자, 더 많은 기업 후원, 더 많은 기여 같은 것들이요. 제가 보기엔 분명 경쟁입니다.
자본주의에 세뇌되셔서 그렇게 보이는 겁니다. 덜 주목받는 대안은 자원이 적을 수는 있어도, 여기서 "이길" 게 뭐가 있습니까.
"후원을 받는다"는 건 그 프로젝트를 유지보수하는 일자리를 얻는다는 뜻이죠. 좋은 일입니다! 하지만 그런 경우는 눈에 띄는 극소수 프로젝트에만 해당합니다. 그런 사람들도 자기가 아끼는 프로젝트에서 돈을 받지 못했다면 대안 쪽에서 일하고 있지는 않았을 거고요.
Deno 얘기가 나온 맥락에서는 당연히 시장 점유율을 말하는 겁니다.
Deno에서 갈아타는 건 하루면 됩니다. 별일 아니에요.
맞습니다. 이렇게 호들갑 떨며 종말을 외치는 댓글이 많아서 정말 놀랍네요. 요즘은 정말 별일 아닙니다. Deno 기반 TS가 백만 줄이어도 문제없어요. Deno에서 제공하는 기능은 거의 다 Node에도 있으니까요. 외부 의존성도 대부분 큰 어려움 없이 걷어낼 수 있을 겁니다. 다른 댓글에서 나온 것처럼 아예 다른 언어 생태계로 옮겨 갈 수도 있고요.
아쉽게도 (제가 아는 한) Node는 아직 이런 걸 기본으로 지원하지 못합니다.
이런 직접 import는 JS/TS가 아닌 프로젝트에서 간단한 독립 실행형 도구 스크립트를 짤 때 Deno의 킬러 기능입니다. "배터리 포함" 표준 라이브러리가 없는데도 TS가 파이썬을 완벽하게 대체할 수 있었던 게 이 덕분이죠.
Deno에는 TS 타입 검사기, 린터, 포매터, 커버리지를 지원하는 테스트 러너, 패키지 매니저, 언어 서버 등등이 다 들어 있습니다. Node에서는 이게 전부 따로따로고, 대개 서드파티 도구입니다.
그렇게 큰일 같지는 않은데요. 필요한 걸 그냥 npm install 하고 import 이름만 바꾸면 되지 않나요?
설치 단계가 싫습니다. 불필요하잖아요.
deno run bla.ts로 실행하면 필요한 의존성을 웹에서 알아서 바로 가져오는 .ts 스크립트 하나면 충분합니다.Bun에는 자동 설치 기능이 있습니다. 다만 직접 켜야 합니다.
무슨 말씀인지는 알겠습니다. 다만 Deno에서 벗어나야 할 때, 이런 식으로 import하는 기존 코드베이스를 변환하는 게 그렇게 어려워 보이지는 않는다는 얘기였어요.
참고로 Bun은 독립 실행형 스크립트에서 (
npm:접두사만 빼면) 거의 똑같은 import 문법을 지원합니다.Bun은 대안이 못 됩니다. 거기도 인수합병(acquihire)당했고, 아마 Claude Code용으로 앤트로픽 내부 프로젝트가 될 겁니다.
사실 이건 피해야 할 나쁜 패턴입니다.
가져오는 버전을 통제할 수 없을 때만 그렇습니다. semver 해석은 기대한 대로 동작하고요. 게다가 지금 얘기하는 건 작은 독립 실행형 '셸 스크립트'이지 '진짜 프로젝트'가 아닙니다. 'bla.sh'에 확장자만 .ts인 걸 떠올려 보세요. Deno는 이런 작은 도우미 스크립트에 정말 좋습니다.
기술적으로는 간단한데 서류 작업 때문에 인간성이 말살되는 그런 일 중 하나입니다. 헛소리 같은 엔지니어링 설계 문서를 또 몇 개 써내야 하니까요.
Node는 권한 지원이 아직 실험적이라서(로컬 스크립트에는 그만큼 못합니다) WebGPU도 없습니다(dawn 래퍼를 import할 수는 있지만요). Deno 데스크톱은 Node에서 쓸 수 있는 어떤 것보다도 훨씬 앞서 있습니다.
yt-dlp 프로젝트는 유튜브 영상을 내려받을 때 Deno를 기본이자 선호 JavaScript 런타임으로 씁니다(자체적으로 손수 짠 JS 인터프리터를 이걸로 대체했습니다). 다행히 yt-dlp는 Node와 QuickJS도 지원하고 Bun도 지원 중단 예정이긴 해도 지원합니다. 다만 이식성, 보안, 그리고 속도 같은 여러 이유로 프로젝트에서 그중 어느 것도 선호하지는 않았던 것 같습니다.
https://github.com/yt-dlp/yt-dlp/issues/14404 , https://github.com/yt-dlp/yt-dlp/issues/15012 , https://github.com/yt-dlp/yt-dlp/wiki/EJS 를 참고하세요.
yt-dlp에는 QuickJS로도 충분하고 훨씬 작습니다. 1MB도 안 되는데, Deno는 34MB에 수많은 의존성까지 딸려 옵니다.
https://github.com/denoland/deno/discussions/9811 을 참고하세요.
거대한 미디어 파일을 비동기로 내려받는 거라면 속도는 우선순위가 아니어야 하지 않나요?
제가 알기로는 다운로드 처리 자체보다 봇 차단 장치를 우회하고 챌린지를 푸는 데 더 많이 쓰입니다.
맞는 말씀입니다(저는 아카이빙 작업에 yt-dlp를 쓰는 하위 프로젝트의 메인테이너입니다).
거대한 미디어 파일을 내려받을 때 속도를 제한하는 건 대역폭뿐입니다.
나머지는 전부 무시해도 될 수준이에요.
제 기억에는 6개월 전 바이브코딩으로 재작성했던 소동 때 Bun 대신 Deno를 골랐는데, "AI는 나쁘다"는 전반적인 분위기 말고는 별다른 설명이 없었습니다. 이제 상황이 대체로 괜찮아졌고 소중한 손수 짠 런타임 선택지도 사라지게 됐으니 다시 따져볼지도 모르겠네요.
저는 AI에 아주 낙관적인 사람이지만, 메인 메인테이너인 소프트웨어를 몇 주 만에 바이브 포팅해 놓고 커뮤니티에는 한마디도 알리지 않은 채 사용자층과 오픈소스 커뮤니티 모두에게 기정사실(fait accompli)로 밀어붙이는 건, 의존해도 될 만큼 신뢰할 수 없다고 느끼게 만드는 행동이 분명합니다.