Deno 클라우드플레어 합류, 런타임은 1년 뒤 끝난다

effidev·2026년 10월 9일

Deno로 서버를 돌리거나 Deno Deploy에 사이트를 올려 뒀다면, 2026년 10월 9일에 나온 발표문 두 편을 모두 읽어야 한다. 제목은 같은데 담긴 내용이 다르다.

Deno 팀 전체가 클라우드플레어에 합류한다. 데노 블로그에 따르면 Deno 런타임은 1년 더 월간 업데이트를 받고, 그 뒤로 개발이 끝난다. Deno Deploy는 6개월 뒤 문을 닫는다. 그런데 같은 소식을 다룬 클라우드플레어 블로그 글에는 이 날짜가 한 번도 나오지 않는다. “Deno 런타임에 무슨 일이 생기는지는 데노 블로그를 보라”는 한 줄이 전부다.

Deno를 오늘 처음 들은 사람도 읽을 수 있게 썼다. 자바스크립트를 서버에서 돌리는 도구가 뭔지, 클라우드플레어가 왜 이 팀을 원했는지, 그래서 내 코드는 지금 뭘 해야 하는지를 순서대로 푼다. 낯선 용어는 나올 때마다 한 줄로 설명했다.

근거로 삼은 자료는 데노 블로그의 합류 발표문, 클라우드플레어 블로그의 공동 글(켄턴 바르다·라이언 달 공동 집필), Deno가 8월에 공개한 celld의 README와 제한 사항·호환성 문서, 그리고 Hacker News 토론이다. 이 사이트가 celld나 workerd를 직접 설치해 돌려 본 것은 없다. 아래는 전부 각 회사가 직접 쓴 문서에 적힌 내용이다.

먼저, Deno는 Node.js를 만든 사람이 다시 만든 런타임이다

런타임은 자바스크립트로 쓴 프로그램을 브라우저 밖, 서버나 내 컴퓨터에서 실행해 주는 프로그램이다. 이 분야의 표준은 Node.js이고, 클라우드플레어 글은 라이언 달을 “Node.js를 만든 사람”이라고 소개한다. 그가 Node.js 다음에 새로 시작한 프로젝트가 Deno다.

Deno 쪽 제품은 데노 사이트 메뉴에 이렇게 나뉘어 있다.

이번 발표문이 직접 이름을 부른 것은 이 가운데 Deno 런타임, Deno Deploy, JSR 셋이다. 나머지 다섯의 운명은 글에 없다. 이 대목은 뒤에서 다시 다룬다.

같은 날 나온 글 두 편, 말하는 내용이 다르다

두 글은 같은 날 올라왔고, 앞부분에서 서로를 가리킨다. 그런데 독자가 가져가는 정보가 꽤 다르다.

클라우드플레어 글만 읽은 사람은 “유명한 팀이 합류했고 셀프 호스팅이 쉬워지나 보다”로 끝난다. 데노 글을 읽은 사람만 “내가 쓰던 게 끝난다”는 사실을 알게 된다. Hacker News에서도 한 댓글이 같은 점을 짚었다. 끝난다는 문장이 Deno 글에만 있고 클라우드플레어 글에는 없는데, 꽤 중요한 내용이라는 지적이다.

무엇이 언제 끝나는지 한 표로

데노 블로그에 적힌 약속을 항목별로 풀면 이렇다. 날짜는 모두 발표일인 2026년 10월 9일 기준의 단순 계산이고, 글에는 정확한 종료일이 없다.

rusty_v8은 자바스크립트 엔진 V8을 러스트에서 부를 수 있게 해 주는 연결 부품이다. workerd는 클라우드플레어 워커스를 돌리는 런타임 본체로, 코드가 공개돼 있다.

눈여겨볼 점이 둘이다. 첫째, “개발을 끝낸다”는 문장은 “삭제한다”가 아니다. 코드는 계속 공개돼 있고, 누군가 이어받을 수는 있다. 다만 발표문은 이어받을 단체나 사람을 지정하지 않았다. 둘째, 데노 사이트는 Subhosting을 “Deno Deploy의 인프라로 내 플랫폼을 확장하는 서비스”로 소개하는데, 그 Deploy가 6개월 뒤 닫힌다. Subhosting이 어떻게 되는지는 글에 쓰여 있지 않다.

celld가 이 거래의 중심인 이유

두 글을 함께 읽으면 합류의 핵심은 Deno 런타임이 아니라 celld다. 켄턴 바르다는 Deno 팀이 8월에 celld를 공개했을 때 “기뻤다”고 적었고, 라이언 달은 Deno에서 Deno Deploy, 그리고 celld로 이어지는 흐름이 이번 선택을 설명한다고 썼다.

celld의 README는 한 줄로 시작한다. 셀프 호스팅하는 분산 듀러블 오브젝트. 풀어 쓰면 이렇다.

• 클라우드플레어 워커스용으로 만든 앱을 내 컴퓨터들에서 돌려 주는 오픈소스 데몬이다. 이미 쓰는 wrangler.json 설정을 그대로 가져다 배포한다.
• 지원 대상은 워커스, 듀러블 오브젝트, KV, 큐, D1, R2, 워크플로, 크론 트리거, 정적 파일이다.
• 오래 보관할 상태는 S3 호환 저장소, 구글 클라우드 스토리지, 애저 블롭 중 버킷 하나에 둔다. 서비스용 컨트롤 플레인이나 합의 서비스가 필요 없다고 적혀 있다.
• 쓰지 않는 객체는 비용이 거의 들지 않는다.

배포 구조도 단순하다. 라이언 달의 표현으로는 “바이너리 하나, 러스트로 작성, 외부 서비스는 오브젝트 스토리지뿐.” 내가 할 일은 celld 인스턴스 여러 개와 버킷 하나를 관리하는 것이다.

설치는 README 기준으로 curl -fsSL https://celld.dev/install.sh | sh 한 줄이거나 ghcr.io/denoland/celld 도커 이미지다. 이미지는 리눅스 x86-64와 ARM64용이다.

듀러블 오브젝트를 모르는 사람을 위한 설명

위 설명에서 가장 낯선 말이 듀러블 오브젝트일 것이다. 라이언 달의 글이 가장 쉽게 풀어 준다. 그는 이것을 “SQLite 데이터베이스가 붙은 분산 싱글턴”이라고 부른다.

• 객체 하나가 이름을 가진 작은 서버처럼 행동한다.
• 객체마다 자기만의 관계형 데이터베이스(SQLite)를 갖는다.
• 자바스크립트 실행이 한 줄기로만 돌아서 순서를 따지기 쉽다.
• 웹소켓 연결을 받을 수 있고, 로컬 SQLite를 동기적으로 읽고 쓸 수 있다.

그가 드는 예는 채팅이다. 채팅방마다 객체를 하나씩 만들면 방마다 데이터와 웹소켓 연결이 자연스럽게 흩어지고, 방이 늘어도 서버 구조를 다시 짜지 않아도 된다. 클라우드플레어 글에는 이 위에 큐, KV, 내구 실행(클라우드플레어의 워크플로 API), 심지어 깃 저장소까지 올라간다고 나온다.

듀러블 오브젝트로 실시간 서비스를 만들 때 비용이 어떻게 달라지는지는 이 사이트의 듀러블 오브젝트 웹소켓 하이버네이션 글에, 상태를 가진 AI 에이전트를 올리는 방법은 클라우드플레어 Agents SDK 글에 코드와 함께 있다. 라이언 달도 발표문에서 AI 에이전트를 같은 맥락으로 꼽았다. 값싼 서버리스 실행, 지속되는 상태, 웹소켓, 높은 수준의 자바스크립트 인터페이스가 에이전트의 작업대로 잘 맞는다는 설명이다.

클라우드플레어가 ‘락인’ 얘기를 직접 꺼낸 까닭

켄턴 바르다의 부분은 의외의 문장으로 시작한다. 인터넷에는 클라우드플레어가 일부러 워커스를 다른 클라우드와 다르게 만들어 이용자를 가둔다는 주장이 널리 퍼져 있다고 쓴다. 그 이론대로라면 오픈소스로 워커스를 흉내 내는 celld는 위협이고, Deno 팀의 합류는 그걸 없애려는 수가 된다. 켄턴은 “이 이론은 틀렸다”고 못박는다.

그가 내세우는 근거는 다음과 같다.

• 워커스가 다른 건 더 낫기 때문이다. 수백 곳에서 도는 앱을 아주 싸게 관리할 수 있고, 가격은 속임수가 아니라 새 구조에서 나온 효율이다.
• 2022년 쇼피파이 같은 고객에게 플랫폼용 워커스를 제안했을 때 반응은 “런타임이 오픈소스가 아니면 못 쓴다”였다. 그래서 workerd를 공개했고, 프로덕션과 같은 코드라고 한다.
• workerd로 갈아타고 떠난 옛 고객도 있다. 켄턴은 “괜찮다”고 적었다. 오픈소스가 아니었으면 애초에 계약하지 않았을 고객이고, 떠난 한 곳마다 남은 곳이 여럿이라는 논리다.

이건 클라우드플레어가 자기 입장을 설명한 글이다. 이 글이 입증한 것은 “회사가 그렇게 주장한다”까지다. 독자가 실제로 확인할 수 있는 것은 위 README와 호환성 문서의 내용, 앞으로 나올 병합 결과물뿐이다.

workerd가 스스로 인정한 빈칸

켄턴의 글에서 가장 솔직한 대목은 workerd의 약점을 인정한 부분이다.

• workerd는 오픈소스지만, 쓰는 사람이 많지 않았다. 켄턴은 “런타임을 내놓고 커뮤니티가 알아서 이식해 주길 바랐는데 그렇게 되지 않았다. 순진했는지도 모른다”고 썼다.
• 가장 큰 공백이 듀러블 오브젝트다. workerd에도 구현돼 있지만 인스턴스 하나에서만 도는 방식이라, 로컬 테스트에는 충분해도 규모를 늘릴 수 없다.
• 이 공백을 메우겠다는 메모(TODO 주석)가 첫 공개 때부터 코드에 있었다고 한다. 클라우드플레어의 실제 서비스용 라우팅은 수백 개 지점과 SRE 팀이 운영하는 외부 서비스에 얽혀 있어서 셀프 호스팅하는 사람이 원할 모양이 아니다.
• 켄턴은 지난봄에 직접 만들어 보려 했지만 “민망하게도 작동하지 않았다”고 적었다.

그래서 계획은 이렇게 요약된다. 라이언 달과 버트 벨더가 새 작업을 이끌고, celld의 코드와 아이디어를 workerd에 병합해 셀프 호스팅을 정식 지원 방식으로 만든다. 자세한 발표는 “앞으로 몇 달 안에” 나온다고 했다. 병합 결과물이 나오기 전까지는 celld나 workerd를 오늘 직접 셀프 호스팅할 수 있다고 안내한다.

celld는 지금 어디까지 되나: 0.6.2 베타의 되는 것과 안 되는 것

README의 제한 사항 문서는 celld v0.6.2를 베타 릴리스라고 부른다. 호환성 문서가 서비스별 상태를 표로 보여 준다.

운영 쪽 제한은 더 실용적이다.

• 플릿(함께 묶인 celld 서버 모음) 하나는 앱 하나만 돌린다. 계정 서비스, 여러 고객이 같이 쓰는 스케줄러, 관리형 입구가 없다.
• celld는 TLS를 끝내지 않는다. 공개 HTTPS는 앞단 프록시가 맡아야 한다.
• 노드끼리 주고받는 통신은 암호화되지 않은 HTTP다. 인증은 하지만 데이터를 암호화하지 않으므로 네트워크가 비공개이거나 암호화돼야 한다.
• 버킷 자격 증명이 플릿 전체를 좌우한다. 한 플릿에만 접근하도록 주라고 문서가 경고한다.
• 윈도우는 지원하지 않는다. 설치 파일은 리눅스 x86-64, 리눅스 ARM64, 애플 실리콘용이다.
• 한 노드만 쓰면 모든 쓰기가 버킷을 기다려서 훨씬 느리다. 2대 이상이어야 쓰기가 디스크 복제로 먼저 안전해진다.

클라우드플레어의 서비스를 통째로 대체하는 물건이 아니라는 점이 분명하다. “클라우드플레어 네트워크, GPU, 브라우저 팜이 필요한 제품은 범위 밖”이라고 README가 직접 적고 있다.

Hacker News는 환영보다 “그래서 Deno는?“을 물었다

글을 쓴 시점에 Hacker News 토론은 206점이었다. 댓글은 대체로 네 갈래로 나뉘었다.

• 끝난다는 문장을 짚은 댓글. “개발을 1년 뒤 끝낸다”는 대목을 인용하며, 이게 클라우드플레어 글에는 없다고 지적했다.
• celld를 죽이려는 인수냐는 우려. 이 우려에는 클라우드플레어 엔지니어 켄턴 바르다가 직접 답했다. 반대로 celld와 workerd를 합쳐 셀프 호스팅 런타임 하나를 만드는 게 목적이라고, 자기 글을 읽어 달라고 했다.
• 런타임 경쟁에 대한 시각. 한 댓글은 지난 1년 사이 Node의 대안으로 꼽히던 둘이 모두 큰 회사 품으로 들어갔다고 썼고, 다른 댓글은 결국 Node.js만 믿는다고 썼다. 이 주장들은 댓글 작성자의 의견이고, 이 글이 확인한 사실이 아니다.
• 써 온 사람의 아쉬움. 매일 Deno를 쓴다는 한 이용자는 개발 경험과 VS Code 확장이 흠잡을 데 없다고 칭찬하며, 새 활력이 되길 바란다고 썼다. 그 댓글에는 곧 “글을 읽어 보니 1년 뒤 접는다더라”는 답이 달렸다.

한쪽 편에 설 이유는 없다. 다만 위 반응이 보여 주는 것이 있다. 개발자들이 이 소식에서 가장 먼저 찾은 정보는 “합류의 의미”가 아니라 **“내가 쓰는 도구가 언제 끝나나”**였다.

오픈소스가 큰 회사에 들어갈 때 코드와 상품의 운명이 갈리는 패턴은 이 사이트가 9월에 다룬 테일윈드의 쇼피파이 합류 글에서도 볼 수 있다. 그쪽은 오픈소스는 MIT 그대로 두고 유료 제품의 신규 가입만 닫았다. 이번에는 오픈소스는 남기고 개발과 호스팅이 접힌다. 구조는 다르지만, 오픈소스라는 말이 곧 계속 관리된다는 약속은 아니라는 점은 같다.

내 프로젝트가 걸리는지 확인하는 순서

Deno를 쓰는 방식에 따라 급한 정도가 다르다. 아래는 발표문에 적힌 일정만 근거로 한 구분이다.

Deno 전용 기능을 얼마나 쓰는지는 코드에서 바로 센다. 내 프로젝트 폴더에서 이렇게 훑어 보면 된다.

grep -rn "Deno\." src | head -30
grep -rn -E "jsr:|npm:|deno\.land" src | head -30
ls deno.json deno.jsonc 2>/dev/null

첫 줄은 Deno 전용 API 호출, 둘째 줄은 Deno식 가져오기 주소를 찾는다. 많이 나올수록 다른 런타임으로 옮길 때 고칠 곳이 늘어난다. 이 명령은 이 글이 제안하는 점검법이고, 발표문에 나온 절차가 아니다.

발표문 어디에도 적혀 있지 않은 것

읽으면서 비어 있다고 느낀 칸을 모았다. 의견이 아니라 두 글에서 찾을 수 없었던 정보다.

• 정확한 종료 날짜. “1년”과 “6개월”뿐이다. 1년과 6개월을 세는 시작점이 발표일인지 다른 날인지도 적혀 있지 않다.
• 런타임을 이어받을 주체. “이어서 개발하려는 사람을 환영한다”가 전부이고, 재단 이관이나 후계자 지정은 없다. Hacker News에서는 재단에 맡기는 시나리오를 예상하는 댓글도 있었지만 추측이다.
• 유료 고객 이전 지원의 범위. Deno Deploy 유료 고객이 워커스로 옮길 때 무엇을 얼마나 도와주는지 구체적인 내용이 없다. 무료 사용자는 언급이 없다.
• JSR 이전 일정. 인프라가 클라우드플레어로 옮겨 간다는 문장뿐이다.
• Fresh·Deno Sandbox·Subhosting의 앞날.
• 병합 결과물의 모습. workerd와 celld가 합쳐진 뒤에 지금의 celld 명령과 설정이 그대로 가는지는 “앞으로 몇 달” 안에 발표한다고만 한다.
• 성능과 안정성의 독립 측정. celld의 속도나 장애 복구 시간을 제3자가 잰 자료는 이 글을 쓴 시점에 찾지 못했다.

오늘 저녁 30분이면 끝나는 점검 세 가지

발표문이 급한 행동을 요구하는 것은 아니다. 하지만 6개월은 인프라를 옮기기에 길지 않다.

1. 내가 Deno를 어디에 쓰는지 한 줄로 적어 본다. 로컬 스크립트인지, 서버인지, Deno Deploy에 올린 사이트인지. 위 표에서 내 칸을 찾으면 급한 정도가 나온다.
2. Deno Deploy 프로젝트가 있다면 목록을 뽑는다. 프로젝트 수, 환경 변수, 도메인 연결을 적어 두면 어디로 가든 이전 작업이 빨라진다. 클라우드플레어 워커스로 옮길 때 바뀌는 점은 데노 쪽이 앞으로 안내하겠다고 한 영역이다.
3. 셀프 호스팅에 관심이 있다면 시험 환경에서 한 번 돌려 본다. README대로 celld dev나 도커 이미지로 시작하되, 지금은 베타이고 노드끼리의 통신이 암호화되지 않으며 앱 하나만 돌릴 수 있다는 한계를 먼저 읽는다. 운영 서버에 바로 올릴 단계는 아니다.

이 글의 숫자와 날짜는 모두 데노 블로그, 클라우드플레어 블로그, celld 저장소의 README·제한 사항·호환성 문서에서 가져온 것이다. 병합 결과물이나 이전 지원 내용이 공지되면 그에 맞춰 고쳐 쓸 필요가 있다. 가장 먼저 확인할 것은 하나다. 내 서비스가 Deno Deploy 위에 있는가?