Deno 팀은 2026년 10월 9일 Cloudflare 합류를 발표하면서 Deno Deploy를 앞으로 6개월 운영한 뒤 종료하겠다고 밝혔다. 유료 고객이 Cloudflare Workers로 옮길 때는 마이그레이션을 지원한다. Deploy를 쓰는 제품팀은 새 기능 일정에 서버 이전 작업을 넣어야 한다.
Deno는 자바스크립트와 타입스크립트 코드를 실행하는 런타임이고, Deno Deploy는 그 애플리케이션을 배포하고 운영하는 호스팅 서비스다. 두 제품의 종료 일정은 다르다. 런타임은 1년 동안 월별 버그 수정과 보안 업데이트를 제공한 뒤 Deno 팀의 개발을 끝낸다. 호스팅은 그보다 먼저 닫힌다.
막대 길이는 발표된 지원기간에 비례한다. 위는 호스팅 운영, 아래는 런타임 월별 수정이다.
6개월과 1년, 어느 일정에 맞춰야 하나
Deploy 사용자의 첫 마감은 6개월이다. 발표일을 기준으로 하면 2027년 4월 무렵이지만, 공지에는 종료하는 정확한 날짜와 시각이 적혀 있지 않다. 이 기간을 새 서버에 코드를 올릴 수 있는 마지막 날로 잡으면 위험하다. 실제 트래픽 전환과 데이터 확인, 문제가 생겼을 때 되돌릴 시간을 포함해 그보다 앞선 내부 마감이 필요하다.
공통 발표 시점에서 두 지원이 겹치는 구간과 서로 다른 종료를 표시했다. 월 단위 환산이며 정확한 종료 날짜·시각은 미명시다.
자체 서버에서 Deno 런타임만 쓰는 팀에는 Deploy 종료가 곧 서비스 중단을 뜻하지 않는다. 오픈소스 코드도 남고 다른 개발자가 이어서 개발할 수 있다. 그러나 기존 팀이 제공하는 수정의 시간표는 별개다. 의존 라이브러리와 보안 대응을 누가 맡을지, 런타임을 유지할지 다른 실행 환경으로 바꿀지를 1년의 지원 기간 안에 판단해야 한다. 커뮤니티가 개발을 이어갈 수 있다는 설명을 기존 팀의 지속 지원 약속으로 읽어서는 안 된다.
이전은 저장소 연결만 바꾸면 끝날까
공식 Deploy 문서의 빌드 설정 화면에는 프레임워크, 의존성 설치 명령, 빌드 명령, 실행 방식과 시작 파일이 따로 있다. 환경변수와 비밀값도 개발·운영 환경에 맞춰 설정한다. 호스팅을 옮긴다는 것은 이런 운영 설정을 새 환경에서 다시 확인한다는 뜻이다. 저장소가 그대로여도 같은 설정으로 앱이 실행된다고 단정할 수 없다.
원문 기반 한글 번역 주석, 캡처 범위: 빌드 설정 패널 전체.
제품팀은 현재 앱이 Deno 전용 API를 어디서 쓰는지부터 찾아야 한다. Deno KV를 쓴다면 저장한 데이터의 이전 방식을 정하고, 예약 작업과 도메인 연결도 별도로 챙긴다. Workers로 가는 앱은 요청 처리 코드와 저장소 접근을 새 환경에서 시험해야 한다. 같은 자바스크립트 생태계에 속해 있어도 실행 환경의 API와 운영 설정이 같지는 않기 때문이다.
유료 고객은 지원 대상과 지원 범위를 먼저 문의할 수 있다. 공지는 유료 고객의 Workers 이전 지원을 약속했지만 세부 절차와 무료 고객 대상의 같은 지원은 명시하지 않았다. 지원을 받더라도 로그인, 결제 콜백, 파일 업로드처럼 실패하면 고객에게 바로 영향을 주는 경로의 검증은 팀 일정에 남겨야 한다. 전환 전에는 기존 서비스와 새 서비스의 결과를 비교하고, 최종 데이터 반영과 도메인 전환 순서를 정하는 편이 좋다.
Cloudflare로 옮기면 다시 벗어날 수 있나
두 회사가 집중하려는 대상은 Workers와 Durable Objects의 프로그래밍 모델이다. Workers는 요청에 코드를 실행하고, Durable Objects는 개별 객체에 상태와 저장소를 묶는 방식이다. 공동 발표는 채팅방마다 객체 하나를 두면 방별 데이터와 웹소켓 연결을 나눌 수 있다는 예를 든다. 앱이 분산될 때 필요한 상태 관리까지 실행 모델에 포함하려는 선택이다.
Cloudflare의 런타임 workerd는 이미 오픈소스다. 하지만 공동 발표는 현재 workerd의 Durable Objects 지원이 단일 인스턴스에 한정돼 확장 가능한 자체 호스팅에는 부족했다고 설명한다. Deno 팀의 celld는 여러 서버에 객체를 분산하는 자체 호스팅을 겨냥해 만들었다. 앞으로 celld의 코드와 아이디어를 workerd에 합쳐 자체 호스팅을 정식으로 지원하는 실행 경로로 만들겠다는 것이 이번 계획이다.
공동 발표의 채팅방 객체 예시를 재구성했다. 방 이름과 일반 서버·공용 DB 대안은 설명용 설계 예시다. 자체 workerd의 현재 객체 지원은 단일 인스턴스이며 celld 통합을 통한 확장은 향후 계획이다.
호스팅 사업자를 바꾸는 일과 코드의 실행 모델을 바꾸는 일은 다르다. Workers 방식으로 쓴 앱을 자체 서버에서 돌릴 수 있어도, 다른 실행 모델로 옮기려면 상태 저장과 요청 라우팅 설계를 바꿔야 할 수 있다. 오픈소스 런타임이 있어도 이런 수정 비용은 남는다. Deploy 사용자는 통합 계획의 완성을 기다리며 이전을 미루기보다 지금 사용할 새 호스팅을 정해야 한다. 자체 호스팅을 대안으로 삼을 앱은 실제 운영 가능 범위를 따로 시험할 필요가 있다.
JSR 패키지 레지스트리는 운영을 계속하며 인프라를 Cloudflare로 옮긴다. V8 연결 라이브러리인 rusty_v8도 지원을 계속하고 workerd 통합을 추진한다. Deno 관련 도구가 모두 같은 시점에 종료되는 것은 아니다. Deploy 이전 계획에는 현재 호스팅에서 빠져나오는 날짜를 적고, 런타임 유지 계획에는 기존 팀의 수정이 끝난 뒤의 담당자를 적어야 한다.