Deno 팀 Cloudflare 합류, Deploy는 6개월 뒤 종료

2026년 10월 9일 Deno 창업자 라이언 달은 공식 발표에서 “the entire Deno team is joining Cloudflare”라고 밝히고, Deno Deploy는 6개월 뒤 종료하며 Deno 런타임은 1년간 매월 버그·보안 수정 릴리스를 제공한다고 예고했다. Deno 팀의 합류와 함께 상용 호스팅, 오픈소스 런타임, 패키지 레지스트리가 서로 다른 경로를 밟게 됐다. Deploy를 이용하는 기업에는 호스팅 이전 시한이, 자체 환경에서 런타임을 쓰는 조직에는 공식 개발 종료 시점이 각각 중요해졌다.

테크크런치의 인수 보도는 이번 거래의 금전적 조건이 공개되지 않았다고 전했다. 공개된 계획은 Deno 전체 팀이 Cloudflare에 합류하고 향후 개발 역량을 공동 플랫폼에 집중한다는 것이다. 기존 Deno Deploy 애플리케이션이 자동으로 Cloudflare Workers로 옮겨진다는 뜻은 아니며, Deno 제품마다 운영 종료와 유지보수 일정도 따로 적용된다.

Deno Deploy 고객이 먼저 맞는 종료 시한

Deno Deploy의 운영 종료와 유료 고객의 Cloudflare Workers 이전 경로를 구분한 구성

가장 가까운 변화는 Deno가 운영하는 Deploy 호스팅의 종료다. 발표된 유예 기간에는 서비스를 계속 운영하지만, 그 뒤에는 같은 호스팅 환경에 의존해 애플리케이션을 제공할 수 없다. 유료 고객에게 약속된 지원은 Cloudflare Workers로 이전할 때의 마이그레이션 지원이다. 지원 대상은 유료 고객으로 명시됐으며, 다른 요금제의 고객에게 같은 지원이 제공되는지는 정해진 바가 없다.

이전 목적지로 지목된 Workers는 Cloudflare의 현재 서비스다. 반면 자체 인프라에서 Workers 모델을 운영하기 위한 workerd·celld 통합은 앞으로 진행할 개발 과제다. Deploy 고객이 그 통합 결과를 기다려야 이전할 수 있는 것은 아니지만, 앞으로 나올 자체 호스팅 방안이 현행 Deploy의 기능과 운영 방식을 그대로 복제한다고 가정할 수도 없다. 두 경로를 혼동하면 가까운 호스팅 종료 시한과 장기적인 플랫폼 개발 일정을 하나로 묶게 된다.

기업의 이전 범위는 소스 코드의 실행 여부만으로 결정되지 않는다. 실제 서비스에서는 환경 변수와 비밀값, 외부 데이터베이스 연결, 도메인과 요청 라우팅, 예약 작업처럼 배포 환경에 묶인 구성이 함께 작동할 수 있다. 이런 요소가 있는 프로젝트라면 Workers에서 코드를 실행하는 것과 서비스 전체를 옮기는 것은 서로 다른 작업이다. 지원의 상세 절차나 고객별 완료 시점은 공개된 계획에 제시되지 않았다.

Deno 런타임의 공식 개발 종료는 별도 일정

독립적인 JavaScript·TypeScript 실행 환경인 Deno 런타임은 Deploy와 같은 날 멈추지 않는다. 예정된 기간에는 버그 수정과 보안 업데이트를 담은 정기 릴리스가 제공되고, 이후 Deno 팀의 공식 개발이 끝난다. 따라서 자체 서버나 다른 호스팅에서 런타임을 사용하는 프로젝트에 Deploy의 서비스 종료 일정을 그대로 적용하면 실제 영향 범위를 잘못 읽게 된다. 운영 장소와 프로그램 유지보수 주체가 다른 문제이기 때문이다.

런타임 코드는 오픈소스로 남고 외부 기여자가 개발을 이어갈 수 있다. 다만 커뮤니티가 어떤 방식으로 릴리스를 관리할지, 누가 보안 수정의 책임을 맡을지는 현재 확정된 후속 체계로 제시되지 않았다. Deno를 자체 인프라에서 실행하는 조직에 중요한 변화는 당장 실행 파일이 사라지는 일이 아니라 공식 수정 릴리스의 종료다. 그 이후 사용 중인 버전을 그대로 유지할지, 다른 런타임으로 옮길지, 새로운 유지보수 주체를 따를지는 별도 판단이 필요하다.

이 구분은 Deno를 개발 도구로 쓰면서 애플리케이션 배포는 다른 곳에서 하는 팀에도 영향을 준다. 이들은 Deploy의 호스팅 종료로 직접 서비스를 내려야 하는 대상은 아니지만, 런타임 업데이트 정책 변화에서는 벗어나지 않는다. 반대로 Deploy에 배포했더라도 코드가 다른 실행 환경으로 쉽게 옮겨질지는 사용한 API와 서비스 구성을 봐야 한다. 상용 호스팅의 종료와 언어 실행 환경의 향후 유지보수는 같은 이름 아래 놓인 별개의 의사결정이다.

JSR은 유지, rusty_v8은 공동 개발로

JSR 패키지 레지스트리는 운영을 계속하고 기반 인프라를 Cloudflare로 옮기는 계획이다. JSR을 통해 패키지를 게시하거나 내려받는 일은 Deploy에 애플리케이션을 호스팅하는 것과 다른 이용 방식이다. 따라서 Deploy가 종료된다는 사실만으로 JSR에 등록된 패키지도 사라진다고 볼 근거는 없다. 레지스트리의 운영 장소는 바뀌지만, 공개 계획상 패키지 유통 창구는 계속 열린다.

Rust에서 V8 엔진을 사용하는 데 쓰이는 rusty_v8도 계속 지원되며 workerd와의 통합이 추진된다. 이 작업은 패키지 레지스트리의 운영 지속이나 Deploy 고객의 호스팅 이전과는 또 다른 개발 경로다. 런타임의 공식 개발을 마치더라도 그 과정에서 만든 구성 요소가 곧바로 모두 폐기되는 것은 아니다. Cloudflare가 Workers 실행 환경을 확장하는 동안 어떤 Deno 기술이 실제로 채택되는지는 이후 통합 작업의 결과로 드러날 사안이다.

workerd와 celld 결합이 겨냥한 자체 호스팅

Cloudflare의 workerd에 Deno 팀의 celld 작업을 결합하려는 계획

Cloudflare의 공동 발표에 따르면 라이언 달과 버트 벨더는 workerd를 자체 인프라에서 본격적으로 운영할 수 있도록 하는 작업을 이끌고, celld의 코드와 아이디어를 그 안에 결합할 계획이다. 이 계획의 목적은 Cloudflare 네트워크에서 쓰는 Workers 프로그래밍 모델을 개발사가 관리하는 인프라에서도 운용하기 쉽게 만드는 것이다. 현재 공개된 것은 개발 방향이며, 통합된 제품의 출시 시점이나 기존 Deploy 고객에게 제공되는 구체적인 이전 도구는 제시되지 않았다.

기술적으로 비어 있던 지점은 상태를 가진 Durable Objects의 분산 운영이다. 오픈소스 Workers 런타임인 workerd에는 Durable Objects 구현이 있지만 자체 호스팅에서는 단일 인스턴스 수준에 머물러, 여러 인스턴스 사이의 배치와 라우팅을 맡길 체계가 부족했다. Cloudflare의 실제 운영 환경은 많은 지역과 외부 서비스에 의존하므로 개발사가 그대로 가져와 설치하기에 적합한 형태가 아니다. celld는 Workers와 Durable Objects 모델을 자체 인프라에서 분산 운영하는 쪽에 초점을 맞춰 만들어졌다.

celld의 설계는 Rust로 작성된 단일 실행 파일과 외부 의존성으로서의 오브젝트 스토리지를 중심에 둔다. 개발자는 여러 celld 인스턴스와 저장소를 관리하면서 계산, 상태 저장, 실시간 통신 기능을 하나의 분산 애플리케이션 모델 안에서 다루는 구상이다. 이 접근을 workerd에 합치면 단순히 이름이 같은 런타임을 제공하는 데 그치지 않고, Durable Objects를 자체 호스팅 환경에서도 확장할 수 있게 만드는 것이 목표가 된다. 현재 workerd나 celld를 각각 자체 호스팅할 수 있다는 사실과 두 프로젝트가 이미 통합됐다는 주장은 구분해야 한다.

workerd·celld 통합에 관한 후속 발표는 앞으로 몇 달에 걸쳐 예고돼 있다. 그 발표에서 확인할 핵심은 여러 인스턴스에 걸친 Durable Objects의 배치와 라우팅을 어떤 방식으로 제공할지, 그리고 통합 코드가 실제로 언제 제공될지다. 자체 인프라를 선택하려는 개발사에는 그 결과가 Workers 모델의 운영 범위를 결정한다. Deploy 이용 기업에는 그와 별도로 이미 시작된 호스팅 종료 유예 기간이 적용된다.

함께 읽기: