Deno가 Cloudflare로 간다 — 런타임은 남기고 사람만 옮기는 인수

이것은 런타임의 인수인가, 아니면 런타임을 내려놓는 대가로 프로그래밍 모델을 사들인 것인가?

도입

2026년 10월 9일, Deno 블로그에 Ryan Dahl 명의의 글 「Deno is joining Cloudflare」가 올라왔다. 해커뉴스에서는 「Cloudflare acquires Deno」라는 제목으로 1389점을 받으며 그날 가장 뜨거운 글 중 하나가 됐다. 같은 날 Cloudflare 블로그에도 Kenton Varda와 Ryan Dahl의 공동 글이 게시됐다.

제목만 보면 흔한 인수 소식이다. 그런데 본문 중간에 놓인 네 줄짜리 목록이 이 사건의 성격을 바꿔 놓는다. Deno 런타임은 앞으로 1년 동안 버그 수정과 보안 업데이트를 담은 월간 릴리스로 지원되고, 그 뒤에는 개발이 종료된다. Deno Deploy는 6개월 더 운영한 뒤 문을 닫는다. JSR은 인프라를 Cloudflare로 옮겨 계속 운영된다. rusty_v8은 계속 지원하며 workerd에 통합하는 방향으로 간다.

해커뉴스 댓글창의 온도는 바로 이 목록에서 갈렸다. 한쪽은 「Deno가 Cloudflare에 합류하는 것이 아니라 Deno의 사람들이 합류하는 것」이라며 제목부터 고쳐야 한다고 했고, 다른 쪽은 celld와 workerd의 통합이야말로 진짜 뉴스라고 봤다. 일주일 전에는 오랜 Deno 사용자였던 David Bushell이 「Friendship ended with Deno, now Node is my best friend」라는 글로 Node 복귀를 선언해 323점을 받은 터였다. 이 글은 그 두 흐름 사이에서, 공개된 사실과 해석을 구분해 가며 이 인수의 의미를 따져 본다.

발표문이 말한 것과 말하지 않은 것

먼저 사실관계를 정리하자. Dahl의 글은 Deno가 걸어온 길을 세 단계로 설명한다. 모듈 배포 방식, 런타임이 제공할 수 있는 보안 보장, 완결된 툴체인, 단일 실행 파일 배포를 다시 물었던 Deno 런타임이 첫 단계다. 그다음이 애플리케이션 실행을 최대한 단순하게 만들려던 Deno Deploy다. 그리고 Deploy를 만들고 운영하면서 그 개발자 경험 아래에 얼마나 많은 복잡성이 남아 있는지 알게 됐고, 그 층까지 단순화하려고 만든 것이 celld다. celld는 Cloudflare Workers의 프로그래밍 모델 위에 세워진 것으로, 스케일링을 각 앱이 직접 조립하는 인프라가 아니라 프로그래밍 모델 안에 넣겠다는 시도다.

Dahl은 「Deno에서 Deno Deploy, 그리고 celld로 이어진 흐름이 이 결정이 왜 납득되는지를 설명한다」고 쓴다. Cloudflare에서는 Workers 팀, Durable Objects 팀과 작업을 합치고, 이 프로그래밍 모델을 Cloudflare 네트워크에서든 자체 인프라에서든 서버를 만드는 기본 방식으로 만들고 싶다고 했다. 그리고 「합류한다는 것은 노력을 어디에 집중할지 선택한다는 뜻이기도 하다」며, 별도의 런타임과 호스팅 서비스를 계속 개발하는 대신 이 공유 플랫폼에 미래의 개발 작업을 쏟기로 했다고 밝혔다. Deno 위에 무언가를 만든 사람들에게 중대한 변화라는 점도 스스로 인정했다.

Cloudflare 쪽 글은 강조점이 다르다. 요약문은 「Deno 팀이 Workers와 Durable Objects의 셀프호스팅을 근본적으로 단순화하기 위해 Cloudflare에 합류한다」이다. Varda는 workerd가 이미 오픈소스이고 프로덕션에서 돌아가는 바로 그 코드라는 점, 그러나 Durable Objects는 단일 인스턴스 방식으로만 구현돼 로컬 테스트에는 충분해도 확장할 수 없다는 점을 솔직하게 털어놓는다. 원래 릴리스부터 TODO 주석이 남아 있었고, 자신이 지난봄 한 번 시도했지만 동작하지 않았다는 고백까지 덧붙였다. 그러던 차에 Deno 팀이 8월에 공개한 celld가 바로 Workers 및 Durable Objects와 완전히 호환되면서 셀프호스팅과 확장성에 집중한 구현이었다는 것이다. 계획은 Ryan Dahl과 Bert Belder가 workerd 셀프호스팅을 일급으로 지원되는 방식으로 만드는 작업을 이끌고, celld의 코드와 아이디어를 workerd로 병합하는 것이다.

눈여겨볼 비대칭이 있다. 해커뉴스에서 simonw는 런타임 종료라는 사실이 Deno 쪽 글에는 있지만 Cloudflare 쪽 글에는 언급조차 없다는 점을 지적했다(직접 인용은 아니고, 코멘트의 요지를 요약). 실제로 Cloudflare 글은 1분 분량이며 workerd와 celld의 통합, 그리고 「락인」 이론에 대한 반박에 지면을 쓴다. Deno 런타임의 운명을 알고 싶은 사람은 Deno 블로그의 목록까지 내려가야 한다.

또 하나, 인수 금액은 두 글 어디에도 없다. 해커뉴스 제목은 「acquires」지만 발표문 자체는 「팀 전원이 합류한다」는 표현을 쓴다. 어떤 거래 구조였는지는 공개된 자료로는 알 수 없다. 이 글에서도 그 부분은 판단하지 않는다.

왜 런타임이 아니라 프로그래밍 모델인가

댓글창에서 가장 많이 반복된 질문은 단순했다. 「사서 죽일 거라면 왜 샀나.」 이 질문에 답하려면 Cloudflare가 무엇을 원했는지를 발표문에서 다시 읽어야 한다.

Varda의 글 절반은 흔한 비판, 즉 Workers가 다른 클라우드와 다르게 설계된 이유가 락인 때문이라는 이론에 대한 반박이다. 그 이론대로라면 Workers와 Durable Objects의 오픈소스 구현인 celld는 Cloudflare에게 위협이어야 한다. Varda는 반대라고 말한다. 2022년 Workers for Platforms를 Shopify 같은 고객에게 제안했을 때, 고객들은 Workers 런타임이 오픈소스가 아니면 그 위에 만들 수 없다고 했고, 그래서 workerd를 공개했다. workerd를 이용해 떠난 과거 고객도 있지만, 오픈소스가 아니었다면 애초에 계약하지 않았을 고객들이고 떠난 하나당 남은 고객이 훨씬 많다는 것이 그의 설명이다. 탈출구를 주는 것이 좋은 비즈니스라는 주장이다.

이 논리를 받아들이면 그림이 맞아떨어진다. Cloudflare에게 필요한 것은 「Workers 프로그래밍 모델이 Cloudflare 바깥에서도 진지하게 돌아간다」는 신뢰다. 그 신뢰를 만드는 데 필요한 것은 범용 JS 런타임 하나가 아니라, 분산 Durable Objects를 셀프호스팅 환경에서 구현할 줄 아는 팀과 그 팀이 이미 만들어 둔 celld다. Dahl의 설명에 따르면 celld는 Rust로 작성된 단일 바이너리이고, 외부 서비스 의존성은 오브젝트 스토리지 하나뿐이다. 여러 celld 인스턴스와 버킷 하나만 관리하면 된다. 해커뉴스의 ryanrasti는 내구성과 조정을 모두 오브젝트 스토리지 위에 부트스트랩하는 설계가 셀프호스팅을 크게 단순화한다고 평가하며, S3가 직접 운영할 수도 있는 프로토콜이 된 만큼 그 의존성은 정당하다고 봤다(직접 인용은 아니고, 코멘트의 요지를 요약).

반대로 Deno 런타임은 이 전략에서 겹치는 자산이다. Cloudflare는 이미 workerd라는 자체 런타임을 프로덕션에서 쓰고 있다. 두 개의 JS 런타임을 동시에 일급으로 유지하는 것은 한 회사가 감당할 이유가 약하다. Deno Deploy 역시 Workers와 정면으로 겹친다. Deno 측이 유료 고객에게 Workers로의 이전 지원을 약속한 것은 이 겹침을 정리하는 방식이다. 해커뉴스의 networked는 celld가 현재 workerd보다 더 완결된 「집에서 돌리는 Cloudflare」라며, 이번 인수로 다른 회사가 celld를 노리고 Deno를 사는 일은 없어졌다고 짚었다(직접 인용은 아니고, 코멘트의 요지를 요약). 이 관찰은 분석적으로 의미가 있다. Cloudflare 호환 셀프호스팅 구현의 주도권이 Cloudflare 안으로 들어왔다는 뜻이기 때문이다.

다만 이것이 이용자에게 나쁘다고 단정할 근거도 아직 없다. Varda는 celld와 workerd를 지금 당장 셀프호스팅할 수 있다고 적었고, 해커뉴스의 heliosAtwork도 통합 결과물이 닫힌 소스가 된다는 징후는 없으며 로드맵 커뮤니케이션이 부족할 뿐이라고 정리했다(직접 인용은 아니고, 코멘트의 요지를 요약). 판단은 향후 몇 달 안에 나올 것이라는 「추가 발표」를 봐야 가능하다.

Dahl이 이 결정의 동기로 AI를 명시한 점도 기록해 둘 만하다. 그는 Durable Objects가 저렴한 서버리스 실행, 영속 상태, WebSocket, 고수준 JavaScript 인터페이스를 한데 묶어 에이전트 하네스에 특히 유용하다고 썼고, celld가 Durable Objects에 집중하는 이유가 그것이라고 했다. 에이전트를 대규모로 자체 인프라에서 돌리려는 사람은 연락하라는 문장으로 글을 맺는다.

독립 런타임이 사라진 뒤의 생태계

이번 일을 단독 사건으로 읽기 어려운 이유는 1년도 안 된 선례가 있기 때문이다. Bun 블로그에 따르면 2025년 12월 2일 Bun은 Anthropic에 인수됐다. 그 글은 Claude Code가 Bun 실행 파일로 배포되며, Bun이 깨지면 Claude Code가 깨지므로 Anthropic이 Bun을 좋게 유지할 직접적인 동기가 있다고 설명했고, Bun은 MIT 라이선스 오픈소스로 남는다고 밝혔다. Deno의 경우와 결정적으로 다른 점은 런타임 자체가 인수자의 제품 공급망 한가운데 있다는 것이다. 해커뉴스의 wiseowise는 Bun이 킬러 앱(Claude Code)을 찾지 못했다면 같은 일이 벌어졌을 것이라고 했다(직접 인용은 아니고, 코멘트의 요지를 요약).

즉 두 인수는 겉보기엔 닮았지만 런타임이 맡는 역할이 정반대다. Bun은 인수자에게 꼭 필요한 부품이라서 살아남았고, Deno 런타임은 인수자가 이미 대체물(workerd)을 갖고 있어서 정리된다. 플랫폼 기업에 인수된 오픈소스 런타임의 운명은 라이선스가 아니라 인수자의 제품 그래프 속 위치가 결정한다는 것, 이것이 두 사례를 나란히 놓았을 때 보이는 패턴이다.

Wasmer 창업자인 syrusakbary는 Bun은 Anthropic이 가져갔고 Deno는 더 이상 개발되지 않으니 독립적인 Node 계열 런타임이 거의 남지 않았다고 우려했다. 자사 Edge.js를 대안으로 언급하면서 이해관계를 스스로 밝혔다(직접 인용은 아니고, 코멘트의 요지를 요약). 이해관계가 있는 발언이지만 지적 자체는 사실에 기반한다. 2018년 이후 Node 대안으로 진지하게 거론된 두 런타임이 모두 1년 사이 플랫폼 기업 품으로 들어갔다.

남는 것은 무엇인가. 첫째, 코드다. Deno는 오픈소스로 남고, Dahl은 개발을 이어가려는 사람을 환영한다고 했다. 그러나 해커뉴스의 theodorejb가 정리했듯, 누군가 이어받지 않으면 Deno는 더 이상 지원되지 않는다(직접 인용은 아니고, 코멘트의 요지를 요약). (10월 16일 추기: Bushell은 이날 올린 글에서 의미 있는 커뮤니티 포크가 오래 살아남을지 매우 의심스럽다고 적었다.) 대형 런타임은 V8 업그레이드, 보안 대응, Node 호환 레이어 유지라는 끝없는 노동을 요구한다. 「오픈소스로 남는다」는 문장과 「유지된다」는 문장은 같은 뜻이 아니다.

둘째, Node에 흡수된 아이디어다. sholladay는 초기 Deno가 너무 좋아서 Node가 일부 기능을 베꼈고, 덕분에 더 나은 Node가 생겼다고 했다(직접 인용은 아니고, 코멘트의 요지를 요약). Bushell의 10월 3일 글이 이를 실증한다. 그는 Node v26.10.0으로 정적 사이트 생성기를 옮기면서 Deno 파일 시스템 API를 node:fs로, Deno.serve를 Hono의 Node 어댑터로 바꾸는 정도로 끝났고, 최소 이전만으로 빌드가 15% 빨라졌다고 보고했다. 동시에 Node가 node_modules 아래의 TypeScript 파일에 대해서는 타입 스트리핑을 거부한다는 한계도 기록했다. Deno가 처음부터 풀었던 문제 중 일부는 여전히 Node에 남아 있다는 뜻이다.

셋째, JSR이다. JSR은 인프라를 Cloudflare로 옮겨 계속 운영된다. 하지만 JSR의 주된 소비자였던 Deno 런타임이 1년 뒤 개발을 멈춘다면, TypeScript 우선 레지스트리의 수요가 어디서 올지는 열린 질문이다. Bushell은 3월 글에서 JSR이 인프라 투자 부족으로 고전했다고 평가했고, 10월 3일 글에서는 JSR의 공격적인 429 응답을 이탈 이유 중 하나로 꼽았다. 해커뉴스의 chaosharmonic도 JSR이 남는 이유와 표준 라이브러리 개발이 계속되는지를 물었지만, 발표문은 여기에 답하지 않는다.

마지막으로 거버넌스다. 해커뉴스에서는 VC 투자를 받는 순간 이 결말은 예정돼 있었다는 의견이 여럿 나왔다. Bushell의 3월 글은 Deno Land가 490만 달러 시드와 2,100만 달러 시리즈 A를 조달했다고 정리하며, 그 시점에 직원의 상당수가 회사를 떠났다고 썼다. 이 수치들은 그의 글에 인용된 것이며 여기서 별도로 검증하지는 않았다. 반면 Node는 io.js 분열을 거쳐 재단 거버넌스로 정착했다. 해커뉴스의 bilalq는 io.js, Bun, Deno를 거치며 메인스트림 Node/npm 스택에 남는 선택이 매번 옳았다고 보면서도, 대안들이 Node를 움직였다는 점은 인정했다(직접 인용은 아니고, 코멘트의 요지를 요약). 회사가 소유한 런타임과 재단이 소유한 런타임의 차이는 평상시에는 보이지 않다가, 회사의 전략이 바뀌는 날 한꺼번에 드러난다.

결론

Deno를 쓰는 팀에게 실무적 결론은 명확하다. Deno Deploy 이용자는 6개월, 런타임 이용자는 1년이라는 시한이 생겼다. 유료 Deploy 고객에게는 Workers 이전 지원이 약속됐고, 런타임 이용자에게는 Node로의 이전이 Bushell의 보고처럼 예전보다 훨씬 쉬워졌다. 다만 Deno 고유 API, 권한 시스템, URL 임포트에 깊이 기대 온 코드라면 이야기가 다르다. 해커뉴스에서 sheept는 에이전트용 샌드박스로 Deno의 권한 시스템을 쓰고 있었다고 했는데, 이런 용도는 Node에서 바로 대체되지 않는다.

더 큰 질문은 산업 구조에 관한 것이다. Cloudflare의 선택은 범용 런타임 대신 프로그래밍 모델에 거는 것이고, 그 모델을 Cloudflare 밖에서도 돌릴 수 있게 하겠다는 약속과 함께 왔다. 그 약속이 지켜진다면 이용자는 Deno라는 런타임을 잃는 대신 Workers와 Durable Objects를 자체 인프라에서 돌릴 수단을 얻는다. 지켜지지 않는다면 독립 런타임 하나가 사라지고 플랫폼 하나가 더 두꺼워진 것으로 끝난다.

당신의 서비스가 의존하는 런타임은 지금 누구의 제품 그래프 위에 놓여 있는가. 그 런타임이 그 회사에게 꼭 필요한 부품인가, 아니면 이미 대체물이 있는 중복 자산인가. 라이선스 파일보다 그 질문이 더 많은 것을 말해 줄 것이다.

출처: