Deno의 Cloudflare 합류 소식을 읽고 가장 먼저 생각한 것은 다음 런타임의 성능이 아니었다. 지금 서비스가 어느 기능에 기대고 있고, 그 기능을 다른 곳에서도 운영할 수 있는지부터 확인하고 싶었다. 작은 팀에서 플랫폼을 바꿀 때 가장 오래 걸리는 일은 코드 문법을 고치는 작업보다 데이터와 장애 대응의 책임을 다시 정하는 일이기 때문이다.
2026년 10월 9일 Deno의 공식 발표는 팀 전체의 Cloudflare 합류와 함께 앞으로의 지원 계획을 설명했다. 이 글은 그 발표와 Cloudflare의 공동 발표, 공개 기술 문서를 기준으로 쓴다. 앞으로 통합될 플랫폼의 완성도나 기존 서비스의 이전 난이도는 발표만으로 확정하지 않겠다.
Deno의 Cloudflare 합류에서 먼저 확인할 지원 일정
런타임, 호스팅, 패키지 저장소의 계획은 다르다
Deno 발표에 따르면 런타임은 앞으로 1년 동안 버그 수정과 보안 업데이트를 담은 월별 릴리스를 지원하고, 이후 팀의 런타임 개발을 종료한다. 소스는 계속 공개된다. Deno Deploy는 6개월 동안 운영한 뒤 종료하며, 유료 고객의 Workers 이전을 지원할 계획이다. JSR은 운영을 이어가면서 인프라를 Cloudflare로 옮긴다. rusty_v8 지원도 유지하고 workerd 통합을 추진한다.
여기서 나는 세 가지를 따로 적어두겠다. 애플리케이션이 사용하는 실행 환경, 배포를 맡긴 호스팅 서비스, 패키지를 받는 저장소다. 같은 회사 이름으로 묶여 있어도 서비스가 의존하는 방식과 바뀌는 시점이 다르다. 공식 발표의 상대 기간을 내가 임의로 정확한 서비스 종료 시각으로 바꾸어 계약서나 운영 일정에 넣지는 않겠다. 실제 이전 계획을 세울 때는 후속 안내와 해당 계정의 공지를 다시 확인해야 한다.
새 플랫폼의 방향과 오늘 가능한 기능을 구분한다
Cloudflare는 Workers와 Durable Objects를 직접 운영하는 환경에서도 쉽게 쓰도록 celld의 코드와 아이디어를 workerd에 합치는 방향을 제시했다. 앞으로 몇 달에 걸쳐 추가 발표가 있을 것이라고도 설명한다. 이는 개발 방향에 관한 발표다. 내가 쓰는 모든 배포 설정이 오늘부터 같은 방식으로 옮겨진다는 보장은 아니다.
이런 소식을 서비스에 적용할 때는 ‘기술이 어디로 향하는가’와 ‘현재 배포에서 무엇이 동작하는가’를 분리해 보고 싶다. 전자는 중장기 선택의 근거가 된다. 후자는 작은 재현 프로젝트와 실제 요청으로 확인해야 한다. 발표 자료가 설득력 있어도, 내 서비스의 로그인 콜백이나 파일 저장이 같은 조건에서 동작하는지는 별도의 문제다.
같은 JavaScript 코드여도 운영 방식은 달라진다
workerd를 실행하는 일과 서비스를 운영하는 일
Cloudflare의 workerd 저장소는 Workers를 구동하는 JavaScript·Wasm 런타임을 공개한다. 저장소 설명에서도 프로덕션 사용에 필요한 부분과 제한을 함께 안내한다. 소스를 받을 수 있다는 사실만으로 관리형 플랫폼이 제공하던 운영 기능을 모두 갖췄다고 판단하기는 어렵다.
직접 운영하는 선택을 검토한다면 나는 먼저 런타임 바깥의 목록을 만들겠다. TLS 인증서, 도메인, 비밀값 전달, 로그 보관, 메트릭, 프로세스 재시작, 데이터 백업, 장애 알림이다. 애플리케이션을 한 번 실행해 HTTP 200을 받는 것은 시작점이다. 같은 인스턴스가 재시작된 뒤에도 상태가 유지되고, 실패한 요청을 추적하며, 업데이트를 되돌릴 수 있어야 운영 선택을 비교할 수 있다.
반대로 관리형 서비스를 택할 때도 ‘운영을 맡겼다’는 말을 구체적으로 나누겠다. 플랫폼이 처리하는 부분과 애플리케이션 팀이 여전히 책임지는 부분을 적는 것이다. 잘못된 데이터 저장, 권한 검사 누락, 마이그레이션 실패까지 플랫폼이 자동으로 해결해 주는 것은 아니다. 이전 비용은 서버 대수보다 이런 책임 목록에서 더 정확히 드러난다고 생각한다.
상태를 담는 객체가 설계에 들어온다
Durable Objects 공식 문서는 객체마다 상태를 유지하고 요청을 조정하는 모델을 설명한다. 문서에서 확인할 수 있는 기능을 내 서비스에 연결해 생각하면, 채팅방·협업 세션·에이전트 실행처럼 같은 상태를 여러 요청이 공유하는 작업을 검토할 여지가 있다. 이것은 적용 후보에 관한 내 판단이며, 모든 기존 데이터베이스를 대체하라는 뜻은 아니다.
예를 들어 에이전트 실행 상태를 옮긴다면 단순히 running 값을 저장하는 데서 끝내지 않겠다. 같은 실행 요청이 두 번 들어왔을 때 어떤 ID로 합칠지, 도구 응답이 늦게 왔을 때 어느 시점의 상태로 기록할지, 작업을 중단한 뒤 재시도가 다시 실행되지 않게 할지를 확인하겠다. 어디에 저장하는가와 어떻게 상태를 바꾸는가는 함께 설계해야 한다.
이전은 새 플랫폼에서 작은 작업 하나를 재현하는 것부터
코드, 데이터, 외부 연결을 따로 적는다
내가 이번 발표를 보고 Deno 기반 서비스를 점검한다면 세 가지 표부터 만들겠다. 코드 표에는 런타임 전용 API, 파일 접근, 패키지와 버전을 적는다. 데이터 표에는 저장 위치, 데이터 양, 백업과 복구 방식, 쓰기 중 이전할 때의 규칙을 적는다. 외부 연결 표에는 OAuth 콜백, 웹훅, 업로드, 예약 실행, 메일 같은 경계를 적는다.
그다음 가장 작은 사용자 흐름 하나를 고른다. 데이터를 읽는 화면 하나나 상태를 저장하는 API 하나면 충분하다. 새 환경에서 실행하고, 같은 입력의 응답과 데이터 변화를 기존 환경과 비교한다. 성공 응답뿐 아니라 인증 실패, 중복 요청, 네트워크 지연, 재시작 뒤 재조회도 확인한다. 이전 작업을 진행률로 표현할 때는 변환한 파일 수보다 검증한 사용자 흐름을 세고 싶다.
화면이 보이는 서비스라면 이 과정에 브라우저도 포함한다. 서버 빌드가 성공해도 쿠키 도메인, 이미지 경로, 리디렉션, 공개 환경변수가 달라지면 사용자는 기능을 쓰지 못할 수 있다. 이전에 쓴 에이전트 테스트와 검증에 관한 글에서도 같은 이유로 테스트 명령의 성공과 실제 사용 결과를 구분했다.
되돌릴 조건을 먼저 정해두자
한 번에 모든 트래픽을 옮기는 대신, 복구 가능한 단위로 전환하는 편을 택하겠다. 읽기 기능을 먼저 검증하고, 쓰기 기능에는 중복 방지와 재조회 기준을 둔다. 어떤 오류율과 응답 지연을 넘으면 이전 환경으로 돌아갈지, 돌아간 뒤 새 환경의 데이터를 어떻게 정리할지도 시작 전에 적어두겠다.
Deno의 Cloudflare 합류는 런타임과 호스팅을 함께 사용하는 팀에게 실제 점검 계기다. 지금 당장 특정 기술로 모두 바꿔야 한다는 결론보다, 현재 서비스의 의존성을 확인하고 작은 흐름을 재현하는 행동이 먼저라고 본다. 발표된 일정과 오늘 검증한 결과를 나눠 기록하면 다음 공지가 나왔을 때도 판단을 고치기 쉽다. 나는 그 기록부터 시작하겠다.