Cloudflare의 Deno 인수 정리: 런타임 개발은 1년, Deno Deploy는 6개월 뒤 끝난다

핵심 요약

• Deno 팀 전원이 Cloudflare로 갑니다. 2026년 10월 9일 두 회사가 블로그로 함께 발표했습니다. 공식 글은 '합류(joining)'라고만 썼고, 거래 금액과 조건은 공개하지 않았습니다.
• Deno 런타임 개발은 1년 뒤 끝납니다. 그동안은 매달 버그·보안 수정판(2.9.x LTS)만 나오고 새 기능은 들어가지 않습니다. 메인테이너는 유지 기한을 2027년 10월로 적었습니다. 코드는 MIT 라이선스로 남습니다.
• Deno Deploy는 6개월 뒤 문을 닫습니다. Cloudflare Workers로 옮기는 지원은 유료 고객만 받습니다. 정확한 종료일과 공식 이전 문서는 10월 17일까지 나오지 않았습니다. JSR(패키지 레지스트리)은 인프라를 Cloudflare로 옮겨 계속 운영합니다.
• Cloudflare가 원한 것은 런타임이 아니라 celld와 그 팀입니다. celld는 Workers 앱과 Durable Objects를 내 서버 여러 대에 나눠 돌리는 Rust 프로그램이고, 8월에 공개됐습니다. 라이언 달과 버트 벨더가 이 코드를 Cloudflare의 오픈소스 런타임 workerd에 합칩니다.
• Supabase와 Netlify의 엣지 함수는 당장 멈추지 않습니다. Supabase는 공식 X 계정으로, Netlify는 직원이 HN 댓글로 Deno 런타임을 자기 인프라에서 돌린다고 밝혔습니다. Supabase는 Deno 지원이 끝나기 전에 Node.js와 Bun도 돌리는 차세대 Compute로 옮길 길을 내겠다고 했고, Netlify는 아직 계획을 밝히지 않았습니다.

목차

• 무엇이 발표됐나요?
• 무엇이 끝나고 무엇이 남나요?
• Cloudflare가 원한 것은 celld입니다
• 라이언 달은 왜 런타임을 내려놓았나요?
• 개발자 반응: 인수보다 종료 예고에 놀랐다
• 내 서비스는 영향을 받나요?
• Deno Deploy에서 Workers로 옮길 때 확인할 것
• 출처

무엇이 발표됐나요?

2026년 10월 9일(미국 시간) Cloudflare와 Deno가 같은 제목 "Deno is joining Cloudflare"로 블로그 글을 하나씩 올렸습니다. Cloudflare 글은 Workers 수석 엔지니어 켄턴 바르다(Kenton Varda)와 Deno를 만든 라이언 달(Ryan Dahl)이 함께 썼고(Cloudflare 블로그), Deno 글은 라이언 달이 썼습니다(Deno 블로그). Deno 글은 "the entire Deno team is joining Cloudflare"라고 적어 팀 전원이 옮긴다는 점을 분명히 했습니다.

두 글 모두 본문에서 '인수(acquire)'라는 말을 쓰지 않고 '합류(joining)'라고만 썼습니다. Cloudflare 글에 Acquisitions 태그가 붙어 있고, TechCrunch를 비롯한 매체는 인수로 보도했습니다. TechCrunch는 거래 금액이 공개되지 않았다고 전했습니다(TechCrunch, 10월 10일). 10월 17일 기준으로 Cloudflare 보도자료 목록에도 이 건은 없습니다(Cloudflare 보도자료).

이번 건은 Cloudflare가 개발자 도구 회사를 잇달아 데려온 흐름의 연장선에 있습니다. Cloudflare 블로그의 인수 글만 봐도 2024년 4월 PartyKit(Cloudflare 블로그), 2025년 4월 Outerbase(Cloudflare 블로그), 2025년 11월 Replicate(Cloudflare 블로그), 2026년 1월 Astro(Cloudflare 블로그), 2026년 6월 Vite를 만든 VoidZero(Cloudflare 블로그)가 있습니다. 그보다 앞서 2025년 12월에는 다른 자바스크립트 런타임인 Bun을 Anthropic이 인수했습니다(Anthropic). The New Stack은 Anthropic이 Bun 개발을 이어 가기로 한 것과 달리 Deno 런타임은 개발이 끝난다는 점을 짚었습니다(The New Stack).

무엇이 끝나고 무엇이 남나요?

종료 일정은 Deno 글에만 있습니다. Cloudflare 글은 celld와 workerd를 합치는 계획을 주로 다루고, 런타임과 Deploy를 언제 끝내는지는 Deno 글에 네 줄로 적혀 있습니다(Deno 블로그). 그 네 줄과 이후 메인테이너 공지를 제품별로 모으면 아래와 같습니다.

런타임 일정은 10월 15일 Deno 메인테이너 바르트워미에이 이바인추크(Bartek Iwańczuk)가 GitHub에 올린 고정 이슈에서 더 구체적으로 나왔습니다. 그는 "The Deno Company (now Cloudflare) will continue maintain Deno until October 2027"라고 적었고, 2.9.x LTS를 매달 내되 새 기능 작업은 하지 않으며, 2.9 분기 이후 main에 들어간 deno sync-types 같은 기능은 되돌린다고 밝혔습니다. 2027년 10월 이후의 개발을 어떻게 꾸릴지는 "considering"이라고만 했습니다(denoland/deno #37030).

Deploy 종료일을 2027년 4월로 못 박아 일정을 짜면 안 됩니다. GIGAZINE 같은 매체는 "2027年4月ごろ"로 환산해 썼지만(GIGAZINE), 원문에는 "six months"뿐이고 날짜가 없습니다. 10월 17일 현재 Deno Deploy 문서는 7월 20일에 끝난 Deploy Classic의 종료만 다루고 있고(Deno Deploy Classic 문서), 문서가 아직 새 Deploy를 이전 목적지로 안내한다는 지적이 GitHub 이슈로 올라와 있습니다(denoland/docs #3491). 무료 사용자를 어떻게 처리할지도 공지되지 않았습니다. 국내 보도 가운데 지디넷코리아 기사는 런타임 종료와 Deploy 종료 일정을 아예 다루지 않았으니(지디넷코리아), 일정은 Deno 블로그 원문으로 확인하는 것이 안전합니다.

Cloudflare가 원한 것은 celld입니다

이번 거래의 중심은 Deno 런타임이 아니라 Deno 팀이 8월에 공개한 celld입니다. 라이언 달은 Cloudflare 글에서 "we're merging workerd and celld!"라고 썼습니다(Cloudflare 블로그). celld 사이트는 이 프로그램을 "an open-source daemon that runs a Cloudflare Workers application on your own machines, including Durable Objects, KV, Queues, D1, and R2"라고 소개합니다(celld.dev). Workers용으로 만든 앱을 Cloudflare가 아닌 내 서버 여러 대에서 그대로 돌리게 해 주는 데몬이라는 뜻입니다.

celld가 무엇을 풀었는지 보려면 workerd부터 알아야 합니다. Cloudflare는 2022년 9월 Workers 런타임을 workerd라는 이름으로 공개했고(Cloudflare 블로그, 2022년), 바르다는 이번 공동 글에서도 workerd가 "the same code we run in production"이라고 강조했습니다. 하지만 같은 글은 "Workerd is already open source, but its Durable Objects support is limited to a single instance"라고 한계를 인정했습니다. Durable Objects는 객체 하나하나가 자기 SQLite 데이터베이스를 가진 작은 서버처럼 동작하고 ID로 하나씩 찾아갈 수 있는 Workers의 핵심 기능인데(공동 글은 "distributed singleton"이라고 부릅니다), workerd로는 이것을 서버 한 대 안에서만 돌릴 수 있었다는 뜻입니다. celld는 이 부분을 채웠습니다. 공동 글은 celld를 "one binary, written in Rust, with object storage as its only external service dependency"라고 설명합니다. S3 같은 오브젝트 스토리지 버킷 하나만 있으면 여러 대의 서버가 Durable Objects를 나눠 맡는 구조입니다.

celld는 아직 어린 프로젝트입니다. GitHub의 첫 릴리스 v0.1.0은 2026년 8월 5일에 나왔고, 10월 7일 v0.6.2까지 올라왔으며, 라이선스는 Apache-2.0입니다(denoland/celld). celld 사이트는 Workers, Durable Objects, KV, Queues, D1, R2, Workflows, Cron Triggers를 지원한다고 표시했고 Containers는 실험 단계로 적었습니다(celld.dev). Forbes도 celld가 두 달 된 프로젝트라 이식성은 아직 제품이 아니라 약속에 가깝다고 평가했습니다(Forbes, 웹 아카이브 보관본).

켄턴 바르다는 "탈출구를 주는 것이 좋은 사업"이라고 설명했습니다. 공동 글에서 그는 오픈소스로 공개하면 고객이 떠난다는 생각을 "This theory is wrong"이라고 반박하고, "being open source and giving people an escape hatch is good business"라고 썼습니다. 2022년 Shopify 같은 고객에게 Workers for Platforms를 제안했을 때 런타임이 오픈소스가 아니면 그 위에 만들 수 없다는 답을 들었다는 일화와 함께, workerd로 Cloudflare를 떠난 고객이 실제로 있지만 "And that's OK!"라고도 적었습니다(Cloudflare 블로그). The New Stack 인터뷰에서는 "If the model is exclusive to us, that narrows our TAM"이라고 말했습니다. Workers 방식이 Cloudflare 안에서만 돌면 공략할 수 있는 시장이 좁아진다는 뜻입니다(The New Stack).

앞으로의 계획은 공동 글에 이렇게 적혀 있습니다. 라이언 달과 버트 벨더(Bert Belder)가 workerd 자체 호스팅을 Workers 방식으로 앱을 만드는 정식 지원 경로로 만드는 작업을 이끌고, 그 과정에서 celld의 코드와 아이디어를 workerd에 합칩니다. 자세한 내용은 앞으로 몇 달 안에 발표하겠다고 했고, 그 전에도 celld나 workerd를 지금 바로 자체 호스팅해 볼 수 있다고 덧붙였습니다(Cloudflare 블로그). 바르다는 HN에서 합쳐진 결과물도 "it will absolutely be open source"라고 답했습니다(Hacker News, kentonv).

라이언 달은 왜 런타임을 내려놓았나요?

라이언 달은 Node.js 호환이 Deno를 붙잡아 두었다고 설명했습니다. 발표 당일 Hacker News 댓글(계정 rough-sea)에서 그는 이번 결정이 함께 내린 결정이고 자신도 동의한다고 밝히며, Deno가 "sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does"라고 썼습니다. 이어 "Why reimplement Node? It works."라고 덧붙였습니다(Hacker News, rough-sea). Node와 똑같이 동작하도록 맞추는 일에 힘이 빨려 들어가 더 중요한 문제를 풀지 못했다는 진단입니다. Deno 글에도 "We've decided to put our future development work into this shared platform rather than continuing to develop a separate runtime and hosting service"라는 문장이 있습니다(Deno 블로그).

이 진단은 Deno의 역사와 겹칩니다. 라이언 달은 2018년 JSConf EU에서 "10 Things I Regret About Node.js" 발표로 Deno를 처음 알렸고(JSConf 영상), 2020년 5월 Deno 1.0을 냈습니다(Deno 1.0). 처음에는 Node와 다른 길을 내세웠지만, 2024년 10월 9일 나온 Deno 2는 npm: 지정자로 200만 개가 넘는 npm 모듈을 쓸 수 있다는 점을 앞세웠습니다(Deno 2). Deno 2가 나온 지 정확히 2년 되는 날에 런타임 개발 종료가 발표된 셈입니다.

회사로서의 Deno는 투자를 받아 움직였습니다. 2021년 3월 490만 달러 시드 투자로 회사를 세웠고(Deno 블로그, 2021년), 2022년 6월 Sequoia Capital이 이끈 2,100만 달러 시리즈 A를 받았습니다. 이 라운드에는 Netlify와 Insight Partners도 참여했습니다(Deno 블로그, 2022년). TechCrunch는 당시 누적 투자액을 2,600만 달러로 적었습니다(TechCrunch, 2022년). 새 Deno Deploy가 정식 출시된 것은 2026년 2월 3일이라(Deno 블로그), 이번 종료 예고는 정식 출시 약 8개월 만에 나왔습니다.

발표 직전에도 Deno를 떠나 Node로 돌아갔다는 글이 주목을 받았습니다. 10월 3일 David Bushell은 오래 쓰던 Deno에서 Node로 돌아갔다는 글을 올렸고(dbushell.com), 이 글은 Hacker News에서 323점을 받았습니다(Hacker News). 국내 긱뉴스에도 같은 글이 소개됐고(긱뉴스), 발표 뒤 긱뉴스 주간 소식은 이 글과 합류 소식을 나란히 묶어 예고편처럼 다시 꺼냈습니다(긱뉴스 Weekly).

개발자 반응: 인수보다 종료 예고에 놀랐다

반응의 중심은 인수 자체가 아니라 런타임 개발 종료였습니다. Hacker News 본 스레드는 10월 17일 기준 1,389점, 댓글 726개를 받았고(Hacker News), 가장 위 댓글은 1년 지원 문장을 그대로 옮겨 붙인 것이었습니다(Hacker News, theodorejb). 'Cloudflare의 acquihire(인재 확보형 인수)로 Deno 개발이 사실상 중단됐다'가 더 맞는 제목이라는 댓글처럼(Hacker News, coldtea), 팀만 데려가고 제품은 끝내는 거래로 읽은 사람이 많았습니다. 켄턴 바르다는 사들여서 없애려 한다는 해석에 "I understand why it looks that way ... But it's simply not true."라고 답했습니다(Hacker News, kentonv).

구독자가 많은 채널도 같은 방향으로 정리했습니다. Fireship은 "The runtime wars are over... and Node won"이라는 제목의 영상에서 celld가 아닌 Deno 제품을 쓰고 있다면 곤란해졌다고 말했고, 이 영상은 10월 17일 기준 조회수 91만 회를 넘겼습니다(Fireship). Simon Willison은 Cloudflare가 앞으로 1년이 지나면 Deno를 유지하지 않는다는 점을 나쁜 소식으로 꼽았습니다(Simon Willison). 반대로 celld 모델이 workerd에 합쳐져 자체 호스팅이 쉬워진다는 점을 더 흥미로운 대목으로 꼽은 의견도 있었습니다(Hacker News, ryanrasti).

커뮤니티 포크도 생겼지만 아직 작습니다. Dodo는 10월 13일(한국 시간) 만들어진 "A community fork of Deno"로, 10월 17일 기준 GitHub 스타 29개에 릴리스가 없습니다(are-we-dodo-yet/dodo). 라이언 달은 "If people want to carry it forward, I'd like that."이라고 했고(Hacker News, rough-sea), 메인테이너 이슈도 2027년 10월 이후 개발을 어떻게 꾸릴지 검토 중이라고만 밝혔습니다(denoland/deno #37030).

국내 반응은 조용한 편입니다. 필자가 찾은 국내 매체 기사는 디지털투데이(디지털투데이), 지디넷코리아(지디넷코리아), AI매터스(AI매터스), 토큰포스트(토큰포스트) 정도였습니다. 긱뉴스 소개 글에는 "사실상 Deno는 끝났군요", "Deno로 프로젝트 완전 이동할 계획이었는데 안타깝네요", "결국 다 node로 회귀하겠군요" 같은 댓글이 달렸습니다(긱뉴스). 댓글이 일곱 개뿐이라 국내 여론으로 일반화하기는 어렵습니다.

내 서비스는 영향을 받나요?

어떤 시한이 걸리는지는 Deno의 무엇을 쓰느냐에 따라 다릅니다. Deno Deploy에 올린 앱은 6개월, Deno 런타임에 기대는 코드는 2027년 10월이 기준입니다.

Deno Deploy에 앱을 올렸다면

가장 급한 쪽입니다. 6개월 안에 옮겨야 하고, Deno가 약속한 이전 지원은 Workers로 가는 유료 고객만 받습니다(Deno 블로그). 무료 플랜 사용자에 대한 안내는 아직 없습니다. Reddit r/Deno의 발표 스레드에는 Deploy에 앱 세 개를 올려 두었다는 사용자의 한숨 섞인 댓글이 달렸습니다(Reddit r/Deno). Deno KV에 데이터를 쌓아 두었다면 데이터를 먼저 빼 두는 것이 좋습니다. 옮기는 방법은 아래 옮길 때 확인할 것에 정리했습니다.

Deno CLI를 로컬이나 자체 서버에서 쓴다면

당장 멈추는 것은 없습니다. 2027년 10월까지는 매달 버그·보안 수정판이 나옵니다(denoland/deno #37030). 다만 새 기능은 들어가지 않고, 그 뒤 보안 수정을 누가 맡을지는 정해지지 않았습니다. 지금 새 프로젝트를 Deno로 시작할 이유는 줄었고, 운영 중인 서비스라면 1년 안에 Node.js나 Bun으로 옮길 계획을 세우는 편이 현실적입니다. Reddit r/Deno에는 deno fmt, deno lint, deno test를 Node 쪽 도구 무엇으로 바꿀지 묻는 글도 올라왔습니다(Reddit r/Deno).

Supabase나 Netlify의 엣지 함수를 쓴다면

당장 바꿀 것은 없습니다. 발표 직후 Supabase 함수도 Deno 위에서 돌아가니 바뀌는 것이 있으리라는 걱정이 나왔지만(Hitesh Choudhary X), Supabase는 10월 12일 X에서 "we operate our own infrastructure and don't depend on Deno's hosted services"라고 밝혔습니다(Supabase X). Supabase 문서도 런타임을 "Supabase Edge Runtime (Deno compatible runtime with TypeScript first)"으로 적고 있고(Supabase 문서), 그 런타임은 Supabase 팀이 직접 만들고 관리하는 Deno 기반 서버입니다(supabase/edge-runtime). Netlify도 비슷합니다. Netlify 엔지니어는 HN에서 "Netlify no longer uses Deno's managed infrastructure, but still uses the Deno runtime."이라고 답했습니다(Hacker News, serhalp). Unikraft가 9월 29일 공개한 사례 글에 따르면 Netlify는 자체 패치한 Deno 빌드를 microVM 안에서 돌리고 있습니다(Unikraft 블로그).

그래서 두 서비스는 Deploy 종료(6개월)와는 상관이 없고, 남은 위험은 2027년 10월 이후 상류 Deno의 보안 수정이 끊기는 것입니다. 국내 블로그 wild_it도 Supabase Edge Functions는 6개월 시한보다 1년 시한과 엮인다고 같은 분석을 내놓았습니다(wild_it 블로그). Supabase는 같은 X 글에서 Deno와 함께 Node.js, Bun 같은 다른 런타임도 지원하는 차세대 Compute를 만들고 있고, Edge Functions에서 Compute로 옮기는 길을 Deno 지원 기간이 끝나기 훨씬 전에 내놓겠다고 밝혔습니다(Supabase X). 기존 Edge Functions는 계속 지원하니 지금 옮길 필요는 없고, 공개 일정은 아직 없다고 덧붙였습니다. Netlify는 아직 계획을 공지하지 않았습니다. 바이브코딩으로 Supabase를 쓰는 분이라면 지금은 Compute 출시 공지를 지켜보면 됩니다.

yt-dlp를 쓴다면

Deno를 직접 쓰지 않아도 Deno와 닿는 대표적인 접점이 yt-dlp입니다. yt-dlp는 YouTube를 온전히 받으려면 외부 자바스크립트 런타임이 필요해졌고, 그중 Deno를 "recommended for most users"로 권합니다(yt-dlp #15012). 발표 당일 저장소에는 지원이 끝나면 Deno의 우선순위를 낮추자는 이슈가 열렸고, 메인테이너는 Node의 권한 제한 기능이 아직 Deno만큼 충분하지 않다는 의견을 남겼습니다(yt-dlp #17799). 긱뉴스 주간 소식도 직접 만든 앱이 아니어도 쓰는 도구가 Deno에 기대고 있을 수 있다고 짚었습니다(긱뉴스 Weekly). 지금은 Deno를 그대로 두고 yt-dlp 릴리스 노트에서 권장 런타임이 바뀌는지만 보면 됩니다.

JSR에 패키지를 올렸다면

JSR은 계속 운영되고 인프라만 Cloudflare로 옮겨 갑니다(Deno 블로그). 다만 Deno 사용자가 줄면 JSR을 쓸 이유도 줄어든다는 회의론과(Hacker News, chiffaa), JSR 패키지는 Node.js, Bun, Workers에서도 돌아간다는 반론이 함께 나왔습니다(Hacker News, skybrian). 이미 올린 패키지를 서둘러 옮길 근거는 아직 없습니다.

Deno Deploy에서 Workers로 옮길 때 확인할 것

공식 이전 문서가 아직 없으니, 요금, 코드, 데이터 순서로 미리 확인해 두는 것이 좋습니다. 순서는 이렇게 잡으면 됩니다.

1. 요금표로 내 앱의 요청 수와 CPU 사용량이 어느 플랜에 맞는지 본다.
2. Deno.serve, Deno.env, Deno.cron 같은 Deno 전용 API를 Workers 방식으로 바꾼다.
3. Deno KV 데이터를 내보내고, 데이터 성격에 맞는 Cloudflare 저장소를 고른다.
4. Cloudflare의 추가 발표와 Deno Deploy 이전 문서가 나오면 실제 이전 날짜를 정한다.

요금: 요청이 많으면 Workers가 유리합니다

두 서비스의 기본 요금은 이렇습니다. 10월 17일에 각 회사 요금표에서 확인했습니다(Deno Deploy 요금, Workers 요금).

CPU를 시간으로 바꿔 보면(필자 환산), Workers 유료에 포함된 3,000만 밀리초는 약 8.3시간이라 Deno Deploy Pro(50시간)보다 적지만, 초과 단가는 시간당 약 0.072달러로 Deno Deploy(0.10달러)보다 쌉니다. 요청 단가는 Workers가 100만 건당 0.30달러로 Deno Deploy(2달러)의 15% 수준이니, 요청이 많은 앱은 Workers 쪽이 싸게 나올 가능성이 큽니다. Workers 유료 플랜은 데이터 송신(egress)에 따로 요금을 받지 않는다고 적혀 있고, Deno Deploy Pro는 월 200GiB를 넘으면 GiB당 0.20달러를 받습니다. 반대로 Workers 무료 플랜은 호출당 CPU가 10밀리초라, Deno Deploy 무료에서 무거운 계산을 하던 앱은 Workers 무료로는 버티기 어렵습니다. Workers 무료 플랜이 한도를 넘으면 과금 대신 멈춘다는 점은 왜 다들 Cloudflare로 갈까에, 서버를 AWS 대신 이런 플랫폼에 올리는 이유는 서버를 이제 AWS에 올리지 않는 이유에 따로 정리했습니다.

코드: Deno 전용 API를 Workers 방식으로 바꿉니다

Workers 런타임은 Deno가 아니라 workerd라서, Deno.*로 시작하는 API는 Workers 방식으로 바꿔야 합니다. Deno 서버는 보통 Deno.serve(handler)로 요청을 받지만(Deno HTTP 서버 문서), Workers는 export default { async fetch(request, env, ctx) { ... } } 형태의 모듈에서 요청을 받습니다(Workers fetch 핸들러 문서). 환경 변수도 Deno.env.get() 대신 핸들러로 들어오는 env에서 읽고(Workers 환경 변수 문서), Deno.cron()으로 돌리던 정기 작업은 Cron Triggers와 scheduled() 핸들러로 옮깁니다(Workers Cron Triggers 문서). 가장 단순한 경우를 나란히 놓으면 아래와 같습니다.

// Deno Deploy
Deno.serve(() => new Response(`API host: ${Deno.env.get("API_HOST")}`));

// Cloudflare Workers
export default {
  async fetch(request, env, ctx) {
    return new Response(`API host: ${env.API_HOST}`);
  },
};

앱을 옮기면 사용자와 서버, 데이터베이스 사이의 거리도 바뀝니다. 리전과 왕복 횟수가 응답 속도에 주는 영향은 바이브코딩 배포가 느린 진짜 이유에 정리했습니다.

데이터: Deno KV는 직접 빼고, 옮길 곳을 성격에 맞게 고릅니다

Deno KV를 썼다면 데이터를 먼저 내보내 두세요. Deno는 @deno/kv-utils의 exportEntries로 KV 데이터를 NDJSON 파일로 내보내고 importEntries로 다시 넣는 방법을 제공합니다(JSR @deno/kv-utils). 로컬에서 인자 없이 Deno.openKv()를 부르면 로컬 KV만 열리므로, Deploy에 쌓인 데이터를 받으려면 대시보드에 나오는 데이터베이스 ID로 만든 연결 주소를 넘기고 액세스 토큰을 DENO_KV_ACCESS_TOKEN 환경 변수에 넣어야 합니다(Deno KV 원격 연결 문서). 내보내기 예시는 아래에 두었습니다. 필자가 Deno 2.9.7로 돌려 보니 Deno.openKv()는 여전히 --unstable-kv 플래그가 있어야 열렸고, 원격 연결에는 토큰을 읽을 --allow-env 권한도 필요했습니다(실제 Deploy 데이터베이스 내보내기는 계정이 없어 로컬 KV로 대신 확인했습니다).

// 실행: DENO_KV_ACCESS_TOKEN=<토큰> deno run --unstable-kv --allow-net --allow-env=DENO_KV_ACCESS_TOKEN --allow-write=export.ndjson export.ts
import { exportEntries } from "jsr:@deno/kv-utils";

const db = await Deno.openKv("https://api.deno.com/v2/databases/<Database ID>/connect");
const file = await Deno.open("export.ndjson", { write: true, create: true, truncate: true });
for await (const chunk of exportEntries(db, { prefix: [] })) {
  await file.write(chunk);
}
file.close();
db.close();

내보낸 파일은 importEntries로 다른 Deno KV에 다시 넣을 수 있지만, Cloudflare 저장소에는 그대로 들어가지 않습니다. Deno KV의 키는 ["users", 123]처럼 문자열과 숫자를 담은 배열이고(Deno KV 문서), 위 코드로 내보낸 NDJSON에서도 키는 배열 그대로이고, 키 요소와 값마다 {"type":"string","value":"users"}처럼 형식 정보가 붙습니다. Workers KV에 넣으려면 키를 users/123 같은 문자열로 바꿔야 하고, 키 크기는 512바이트까지입니다(Workers KV 한도). 바꾼 데이터는 wrangler kv bulk put <파일> 명령으로 한꺼번에 올릴 수 있습니다(Wrangler KV 명령).

옮길 곳은 이름만 보고 고르면 안 됩니다. Deno KV는 읽기를 강한 일관성 모드로 할 수 있고 원자적 트랜잭션(kv.atomic())을 지원합니다(Deno KV 문서). 반면 Workers KV는 최종 일관성 저장소라, 쓴 값이 다른 지역에 보이기까지 최대 60초, 길게는 그 이상 걸릴 수 있고 읽기가 많은 캐시성 데이터에 맞습니다(Workers KV 동작 방식). Deno KV의 원자적 갱신에 기대던 코드라면 Workers KV보다 Durable Objects나 D1 쪽을 먼저 살펴보는 편이 맞습니다. Cloudflare 문서도 쓰기 순서를 보장하려면 쓰기를 Durable Object 하나로 모으는 방법을 소개합니다(Workers KV 동작 방식). Deploy Classic 시절의 Deno.Kv.enqueue() 큐 코드가 남아 있다면, 이 기능은 새 Deno Deploy에서도 이미 지원되지 않았으므로(Deno Deploy 이전 가이드) Cloudflare Queues로 바꿔야 합니다.

대안: Cloudflare에 묶이기 싫다면 celld

Cloudflare 공동 글은 celld나 workerd를 지금 자체 호스팅할 수 있다고 적었고(Cloudflare 블로그), celld는 Workers 설정 파일(wrangler.json)을 그대로 읽어 내 서버에서 돌리는 것을 목표로 합니다(celld.dev). 다만 아직 0.x 베타이고 workerd와 합쳐지는 과정에서 형태가 바뀔 수 있으니, 운영 서비스는 Workers로 먼저 옮기고 celld는 시험용으로 지켜보는 순서가 안전합니다.

출처

1. Cloudflare 블로그: blog.cloudflare.com/deno-joins-cloudflare
2. Deno 블로그: deno.com/blog/cloudflare
3. TechCrunch, 10월 10일: techcrunch.com/2026/10/10/cloudflare-acquires-deno-to-improve-its-worke…
4. Cloudflare 보도자료: cloudflare.com/press-releases
5. Cloudflare 블로그: blog.cloudflare.com/cloudflare-acquires-partykit
6. Cloudflare 블로그: blog.cloudflare.com/cloudflare-acquires-outerbase-database-dx
7. Cloudflare 블로그: blog.cloudflare.com/replicate-joins-cloudflare
8. Cloudflare 블로그: blog.cloudflare.com/astro-joins-cloudflare
9. Cloudflare 블로그: blog.cloudflare.com/voidzero-joins-cloudflare
10. Anthropic: anthropic.com/news/anthropic-acquires-bun-as-claude-code-reaches-usd1b-…
11. The New Stack: thenewstack.io/cloudflare-acquires-deno-ryan-dahl
12. denoland/deno #37030: github.com/denoland/deno/issues/37030
13. denoland/celld 릴리스: github.com/denoland/celld
14. GIGAZINE: gigazine.net/news/20261013-cloudflare-deno
15. Deno Deploy Classic 문서: docs.deno.com/deploy/classic
16. denoland/docs #3491: github.com/denoland/docs/issues/3491
17. 지디넷코리아: zdnet.co.kr/view/?no=20261012163029
18. celld.dev: celld.dev
19. Cloudflare 블로그, 2022년: blog.cloudflare.com/workerd-open-source-workers-runtime
20. Forbes, 웹 아카이브 보관본: web.archive.org/web/20261012032833/https://www.forbes.com/sites/janakir…
21. Hacker News, kentonv: news.ycombinator.com/item?id=50022333
22. Hacker News, rough-sea: news.ycombinator.com/item?id=50023277
23. JSConf 영상: youtube.com/watch?v=M3BM9TB-8yA
24. Deno 1.0: deno.com/blog/v1
25. Deno 2: deno.com/blog/v2.0
26. Deno 블로그, 2021년: deno.com/blog/the-deno-company
27. Deno 블로그, 2022년: deno.com/blog/series-a
28. TechCrunch, 2022년: techcrunch.com/2022/06/21/deno-raises-21m-to-launch-a-fully-managed-run…
29. Deno 블로그: deno.com/blog/deno-deploy-is-ga
30. dbushell.com: dbushell.com/2026/10/03/deno-to-node
31. Hacker News: news.ycombinator.com/item?id=49971719
32. 긱뉴스: news.hada.io/topic?id=34851
33. 긱뉴스 Weekly: news.hada.io/weekly/202641
34. Hacker News: news.ycombinator.com/item?id=50019911
35. Hacker News, theodorejb: news.ycombinator.com/item?id=50020072
36. Hacker News, coldtea: news.ycombinator.com/item?id=50020818
37. Hacker News, kentonv: news.ycombinator.com/item?id=50025430
38. Fireship: youtube.com/watch?v=l3L_lETiSzc
39. Simon Willison: simonwillison.net/2026/Oct/9/deno-is-joining-cloudflare
40. Hacker News, ryanrasti: news.ycombinator.com/item?id=50020609
41. are-we-dodo-yet/dodo: github.com/are-we-dodo-yet/dodo
42. 디지털투데이: digitaltoday.co.kr/news/articleView.html?idxno=706216
43. AI매터스: aimatters.co.kr/news-report/54734
44. 토큰포스트: tokenpost.kr/news/breaking/420597
45. 긱뉴스: news.hada.io/topic?id=35073
46. Reddit r/Deno: reddit.com/r/Deno/comments/1x1lfbq/deno_is_joining_cloudflare
47. Reddit r/Deno: reddit.com/r/Deno/comments/1x24hnv/what_packages_are_we_migrating_to_fo…
48. Hitesh Choudhary X: x.com/Hiteshdotcom/status/2108646553812701237
49. Supabase X: x.com/supabase/status/2109630227085168640
50. Supabase 문서: supabase.com/docs/guides/functions
51. supabase/edge-runtime: github.com/supabase/edge-runtime
52. Hacker News, serhalp: news.ycombinator.com/item?id=50032789
53. Unikraft 블로그: unikraft.com/blog/netlify-edge-functions
54. wild_it 블로그: blog.naver.com/wild_it/224439552016
55. yt-dlp #15012: github.com/yt-dlp/yt-dlp/issues/15012
56. yt-dlp #17799: github.com/yt-dlp/yt-dlp/issues/17799
57. Hacker News, chiffaa: news.ycombinator.com/item?id=50024273
58. Hacker News, skybrian: news.ycombinator.com/item?id=50027128
59. Deno Deploy 요금: deno.com/deploy/pricing
60. Workers 요금: developers.cloudflare.com/workers/platform/pricing
61. Deno HTTP 서버 문서: docs.deno.com/runtime/fundamentals/http_server
62. Workers fetch 핸들러 문서: developers.cloudflare.com/workers/runtime-apis/handlers/fetch
63. Workers 환경 변수 문서: developers.cloudflare.com/workers/configuration/environment-variables
64. Workers Cron Triggers 문서: developers.cloudflare.com/workers/configuration/cron-triggers
65. JSR @deno/kv-utils: jsr.io/@deno/kv-utils
66. Deno KV 원격 연결 문서: docs.deno.com/deploy/reference/deno_kv
67. Deno KV 문서: docs.deno.com/deploy/kv
68. Workers KV 한도: developers.cloudflare.com/kv/platform/limits
69. Wrangler KV 명령: developers.cloudflare.com/kv/reference/kv-commands
70. Workers KV 동작 방식: developers.cloudflare.com/kv/concepts/how-kv-works
71. Deno Deploy 이전 가이드: docs.deno.com/deploy/migration_guide