요약
Deno는 클라우드플레어로 가며 막을 내리지만, 경쟁자로서 Node와 자바스크립트 생태계를 앞으로 밀었습니다.
패키지 매니저 vlt의 창업자 다시 클라크가 쓴 글입니다. Deno 팀이 클라우드플레어에 합류하고 런타임(자바스크립트를 실행하는 환경)을 정리한다는 발표에 맞춰, Deno가 남긴 것을 돌아봤습니다.
왜 중요한가
- Deno는 실서비스에서 널리 쓰이지 못했지만, 그 장점은 Node를 통해 생태계에 퍼졌다고 봅니다.
- Bun은 앤트로픽, Deno는 클라우드플레어로 가면서 주요 독립 런타임이 모두 본업이 따로 있는 회사 안에 들어갔습니다.
- Deno의 커뮤니티 포크가 살아남는지가 클라우드에 묶이지 않은 런타임의 수요를 보여 줄 것이라고 했습니다.
핵심 내용
- Deno 런타임은 앞으로 1년에 걸쳐 정리되고, JSR(Deno가 만든 패키지 저장소)은 클라우드플레어 인프라에서 계속 운영됩니다.
- Node가 fetch, 테스트 러너, 권한 모델, 타입 제거(type stripping)를 들인 데는 경쟁 런타임의 압박이 있었다고 했습니다.
- 기본 차단 권한과 TypeScript 우선 지원은 살아남았지만, URL로 의존성을 가져오는 방식은 차츰 물러났습니다.
- Bun이 npm 호환을 내세우자 Deno도 6주쯤 뒤 npm: 지정자를 발표했고, Deno 2에서 npm 호환을 완성했습니다.
- 프로젝트가 져도 아이디어는 대개 이긴다며, 엔진과 런타임이 여럿 있어야 생태계가 건강하다고 끝맺었습니다.
HN 반응
- 설치 단계 없이 셸 스크립트를 돌리던 이용자들이 아쉬워했고, Dodo 같은 포크(갈라져 나온 프로젝트)와 Bun의 자동 설치가 대안으로 거론됐습니다.
- import maps는 후퇴가 아니라 웹 표준을 따른 것이라는 반론이 나왔고, 글을 LLM이 썼다는 지적도 여러 번 나왔습니다.
저는 이 분류 중 두 가지에 동의하지 않습니다.
deps.ts는 런타임에 내장된 기능이 아니라 관례였습니다. 따르고 싶으면 따르면 되고, 그냥 평범한 타입스크립트 파일일 뿐입니다!
import map은 Deno가 방침을 뒤집은 게 아니라 웹 플랫폼 기능을 구현한 것입니다. 브라우저 JS와의 호환은 처음부터 Deno의 두드러진 특징이었습니다. 굳이 말하자면 앞으로 나아간 겁니다.
다만 큰 흐름에서 보면, Deno가 주관 뚜렷한 출발점에서 멀어져 실용주의(Node의 즉시 대체재)로 간 이야기인 건 맞습니다.
LLM이랑 말씨름하고 계신 거예요.
구현 세부 사항이 중요한 것처럼 말씀하시네요. 안 중요해요.
여기서 "and"를 '&'로 바꾼 건 사람(고깃덩어리 프록시)인 것 같아요. LLM은 앰퍼샌드를 그렇게 쓰지 않거든요. 문법적으로 딱히 맞지 않아서겠죠.
그런데 나머지 문장은 누가 봐도 AI가 찍어낸 쓰레기 글이에요.
짚어 주셔서 감사합니다. 저도 그 부분이 "거짓"처럼 눈에 걸렸습니다.
이번 발표도, 지금까지 알던 Deno 런타임이 사라진다는 것도 정말 안타깝습니다. 앞으로도 계속 지켜볼 거고, 활발히 움직이는 포크가 나오면 아마 그걸 쓸 겁니다.
저는 Deno를 쉘 스크립트 용도로 많이 써 왔습니다. 별도 설치 단계나 node_modules 디렉터리 없이 의존성을 바로 링크해서 실행할 수 있다는 건 정말 큰 장점입니다. 바이너리 하나만 받으면 되고 스스로 업데이트까지 된다는 점도 아주 좋았습니다.
Bun도 이런 기능이 비슷한지는 모르겠습니다. 그냥 이 모든 게 너무 아쉽습니다.
"Dodo"라는 포크가 진행 중이고, 디스코드 서버가 빠르게 차고 있어요. https://github.com/denoland/deno/issues/37030#issuecomment-6204786931
Dodo는 드롭인 대체재를 목표로 합니다.
그리고 제 포크인 Ende도 있는데, 여기선 Node 호환, Deploy, KV, Jupyter 등등(&c.)을 다 뜯어냈습니다. https://ende.sh
&c가 etc.라는 뜻인 줄 오늘 처음 알았네요. 무슨 FFI 기능 같은 건 줄 알고 "&c"를 구글링하는 데 인정하기 민망할 만큼 시간을 썼거든요 ㅋㅋ
&는 말 그대로 e와 t를 합친 글자예요. et, et cetera 할 때의 et요.
하하! 알리게 돼서 기쁩니다. 몇 년 전에 어디선가 쓰는 걸 보고 마음에 들었거든요.
etc(et cetera)의 et는 라틴어로 "그리고"라는 뜻이고, 전체로는 "기타 등등" 정도의 의미죠. 앰퍼샌드는 아주 멋 부린 "E"와 "t"가 합쳐져서 생겼다고들 하니, &c는 역사적으로도 꽤 재미있게 어울리는 표기예요.
의존성이 npm 패키지라면 Bun도 지원합니다. https://bun.sh/docs/runtime/auto-install
단일 독립 바이너리이고 자체 업데이트 기능도 있습니다.
고마워요, Deno!
업무에서 정말 중요해질 거라 생각했지만 서서히 사라진 프로젝트 목록에 Deno도 이름을 올렸네요. 예를 들면 rethinkdb도 그런 경우였고요.
그래도 Deno 덕분에 io.js 때처럼 Node 쪽이 실제로 움직인 건 사실이잖아요.
그리고 역대 가장 멋지고, 웃기고, 똑똑한 제품 발표 영상을 만들어 주셔서 감사합니다. https://www.youtube.com/watch?v=swXWUfufu2w
저도 같은 마음으로 감사 인사를 드립니다!
저는 URL 기반의 반(反)패키지 매니저 노선 때문에 숱한 의존성 공격을 불렀다고 보는 열렬한 Deno "안티"이지만, Deno와 그 뒤의 사람들이 여러 면에서 이 분야를 한 걸음 앞으로 밀어 놓았다는 점만큼은 인정할 수밖에 없습니다!
Node의 미래는 밝습니다. 예를 들어 Platformatic의 "Watt" 서버^1 가 Node를 앞으로 밀고 나가는 사례입니다.
그리고
https://github.com/platformatic#-watt--the-nodejs-application-server
원조 Node와, Node가 아닌 수많은 대안들(저처럼 PHP를 쓰다가 사이드 프로젝트에 Go를 쓰게 된 사람은 이쪽이 더 인기를 얻었으면 하는데요) 사이에는 "Node와 거의 같되 지저분한 부분은 줄인" 프로젝트가 들어설 틈이 없었던 걸까요?
그 틈이 어떤 틈이어야 했느냐의 문제였다고 봅니다. "외부 의존성은 쓰고 싶지 않다"는 Node 개발 영역에서는 Bun이 꽤 잘하고 있습니다. 저희는 Go 프로젝트를 상당수 Bun으로 옮겼는데, Azure와 Bun 모두 마이크로소프트 패키지만으로 해결되기 때문입니다. Go를 쓰던 방식과 비슷하면서 언어는 하나 줄었습니다. Bun은 대체로 Node의 드롭인이라서 다시 돌아가기도 꽤 쉬울 겁니다.
어느 정도는 그렇죠. 그런데 예상보다 Node가 기존 틀 안에서 지저분한 부분을 많이 스스로 고쳐 냈고, 그게 그 틈을 더 크게 갉아먹었다고 생각해요.
글쎄요, Bun은 예전보다 놀랄 만큼 좋아지고 편해졌는데요.
포크가 나오면 좋겠습니다. 댓글에 몇 개가 언급돼 있네요.
Bun과 Deno는 이제 빅테크에 의존하는 처지가 됐습니다. 좋은 쪽으로도, 나쁜 쪽으로도요.
오래전부터 Deno를 의심해 온 우리에게는 "내 그럴 줄 알았다"라고 한마디 할 자격이 조금은 있다고 생각해요.
근본적으로 JavaScript 생태계/문화에는 유행에 휩쓸리고 변화가 극단적으로 잦은 큰 무리가 있어요. 장기적인 건 생각도 안 하고, 역사적 패턴은 아랑곳없이 새 프레임워크와 런타임으로 갈아타죠.
이런 일은 계속 반복돼요. JS 유행의 쳇바퀴를 돌리는 사람들에게, 변화의 대가가 결국 자기들과 생태계 전체를 아프게 할 때 그들이 스스로를 해치고 우스운 꼴이 될 뿐이라는 걸 어떻게든 알려 주고 싶네요.
하지만 Deno의 몰락이 발표되기도 전에 Deno 다음의 반짝이는 새것으로 이미 갈아탔을 테니, 아무것도 배우지 못하겠죠.
기사를 읽어 보세요. 잘 생각해서 쓴 글이고, 말씀하신 지점과 생태계가 무엇을 배웠는지를 직접 다루고 있습니다. 그쪽이 더 흥미로운 논쟁거리가 될 겁니다.
LLM이 쓴 글입니다.
훌륭한 소프트웨어를 만들고 이번 행보까지 보여 준 Deno 팀을 축하합니다. 저는 에이전트 하네스의 스크립트 런타임으로 쓰고 있었는데 잘 동작했습니다. 이제 Node.js로 돌아갈까 합니다.
글쎄요, Bun은 예전보다 놀랄 만큼 좋아졌는데요.
관련 글:
클라우드플레어, Deno 인수
https://news.ycombinator.com/item?id=50019911
포크를 따서 C++로 다시 쓰는 걸 고려 중입니다.
그럴 거면 이미 Node.js가 있잖아요.
저는 Deno의 퍼블리싱 플랫폼에 작은 애플릿을 배포해 보고 싶었고, 언어에 내장된 DB도 써 보고 싶었습니다. 다만 내 앱과 DB가 나중에 어떻게 될지 늘 불안했어요. 그래서 묻고 싶은데, 그 Deno Deploy 앱들은 지금 어떻게 되나요?