Cloudflare Workers부터 자체 호스팅까지: Deno Deploy 대안 비교 (2026)

Deno Deploy 대안을 찾는다면 Cloudflare Workers부터 검토하는 것이 좋습니다. Deno가 공식 이전 경로로 지목한 플랫폼이며, Deploy는 앞으로 6개월 더 운영된다고 밝혔습니다. Deno 기반 엣지 로직을 사용하는 웹사이트라면 Netlify, 데이터베이스 중심 API라면 Supabase Edge Functions, 프레임워크 중심 앱이라면 Vercel Functions, 소규모 예약 작업이라면 Val Town이 적합합니다. Deno KV를 사용하는 앱은 함수를 어디서 실행할지보다 저장소를 무엇으로 대체할지 먼저 결정해야 합니다.

요금과 문서는 2026년 10월 12일에 확인했습니다. 공개된 요금, 런타임의 동작 조건, 마이그레이션에 필요한 작업을 비교한 글이며, 로그인 후 실제 배포 테스트를 진행하지는 않았습니다. 서비스 종료까지의 운영 기간은 Deno의 10월 9일 발표를 기준으로 합니다.

Deno Deploy 대안 한눈에 비교하기

앱의 동작을 유지하면서 앞으로 관리해야 할 변경 사항이 가장 적은 플랫폼을 선택하는 것이 핵심입니다. 외부 데이터베이스를 호출하는 TypeScript 엔드포인트와 트랜잭션·예약 작업·큐를 모두 Deno Deploy에 의존하는 앱은 이전 과제가 다릅니다.

요금제 출처는 Cloudflare, Netlify, Supabase, Vercel, Val Town, Val Town의 결제 FAQ, DigitalOcean VPS 요금표입니다. 모두 진입 요금이며, 앱 전체의 월 청구액을 보장하는 금액은 아닙니다.

Deno Deploy 종료 발표와 일정의 의미

Deno Deploy는 서비스를 종료하며, Deno 런타임의 유지보수 기간은 별도로 정해져 있습니다. Ryan Dahl은 2026년 10월 9일 발표에서 다음과 같이 밝혔습니다.

Deno Deploy는 6개월 동안 계속 운영된 뒤 종료됩니다.

같은 발표에서 유료 고객의 Cloudflare Workers 이전을 지원하겠다고 약속했습니다. Deno 런타임은 앞으로 1년 동안 버그 수정과 보안 업데이트를 담은 월간 릴리스를 제공하며, 그 이후에는 Deno가 런타임 개발을 종료합니다. 런타임은 계속 오픈 소스로 남습니다. JavaScript 및 TypeScript 패키지 레지스트리인 JSR은 인프라를 Cloudflare로 옮겨 운영을 이어갑니다. Deno 발표 전문에서 확인할 수 있습니다.

Deno가 제시한 것은 남은 운영 기간이며, 특정 종료일이 아닙니다. 발표를 근거로 임의의 마감 날짜를 만들어서는 안 됩니다. 런타임의 유지보수 기간이 더 길다고 해서 Deploy를 그만큼 더 쓸 수 있는 것도 아닙니다. 유료 고객은 앱과 데이터 이전을 함께 계획하면서 제공되는 마이그레이션 지원을 활용하는 것이 좋습니다.

1. Cloudflare Workers: 가장 먼저 검토할 Deno Deploy 이전 경로

Cloudflare Workers는 요청 핸들러와 백그라운드 작업을 실행하는 관리형 플랫폼입니다. Deno가 고객에게 직접 권하는 이전 대상이므로 우선 검토할 후보입니다. TypeScript API, 외부 데이터베이스, 예약 정리 작업을 운영하는 창업자라면 런타임과 맞닿는 코드와 배포 설정을 조정하는 일이 주된 과제입니다. Deno KV 중심으로 만든 앱은 저장소를 별도로 재설계해야 합니다. 이전 플랫폼으로 Workers를 선택하되, 그대로 옮길 수 없는 Deno 고유 기능의 수정 비용을 예산에 명시해야 합니다.

적합한 용도: 관리형 인프라의 이점을 활용할 API, 웹훅, cron 작업, 큐, 웹사이트입니다.
주요 강점: Deno가 지정한 이전 경로이며, 플랫폼 내에 저장소와 스케줄링 서비스가 있습니다.
요금: Workers Free를 제공하며, Workers Paid는 계정당 월 최소 $5 USD입니다. Enterprise 사용량은 계약에 따라 과금됩니다.
무료 체험: 상시 제공되는 Workers Free 요금제로 평가할 수 있습니다.
이전 난이도: 무상태 핸들러는 낮음~중간, KV 트랜잭션과 큐 작업을 재설계해야 한다면 높음입니다.

TypeScript 코드에서 무엇을 바꿔야 할까

Workers는 Deno가 아닌 workerd 런타임에서 실행되며, 전역 Deno 네임스페이스를 제공하지 않습니다. Request, Response, fetch 같은 표준 웹 인터페이스는 이식 가능한 코드의 출발점이 됩니다. 반면 Deno.serve, Deno.env, Deno.openKv, Deno.cron은 대체해야 할 부분을 가리킵니다. Node.js 호환성도 일부 API에 한정되므로, 개발 중 패키지를 정상적으로 임포트했다고 해서 실행 시 필요한 의존성까지 작동한다고 볼 수는 없습니다. Workers 런타임 API를 확인해야 합니다.

Wrangler는 Cloudflare의 배포용 명령줄 도구입니다. Deno의 Wrangler 튜토리얼은 개발 툴체인으로 Deno를 유지하는 방법을 설명합니다. npm:wrangler를 추가하고 Workers 타입을 생성한 뒤, fetch 핸들러가 있는 모듈을 내보냅니다. Deno 방식의 모듈 해석이 필요하면 Deno 플러그인을 적용한 esbuild로 번들링합니다. 업로드할 코드를 Deno로 빌드해도, 배포된 Worker가 Deno 프로세스로 실행되는 것은 아닙니다.

비밀 값과 리소스 접근은 바인딩으로 옮깁니다. 바인딩은 Worker가 데이터베이스, 큐, 환경 값에 접근할 수 있도록 설정하는 연결 수단입니다. 앱 파일뿐 아니라 의존성도 점검해야 합니다. 라우트 핸들러는 웹 API만 사용하더라도 유틸리티 내부에 파일 시스템 호출이 숨어 있을 수 있습니다. Cloudflare 바인딩 문서를 참고할 수 있습니다.

서비스 이름보다 동작을 기준으로 대체하기

가장 주의할 차이는 Workers KV와 Deno KV입니다. Workers KV는 읽기가 잦고 쓰기가 비교적 드문 용도에 적합하며, 캐시된 읽기에서는 오래된 값이 반환될 수 있습니다. 이름이 비슷하다는 이유로 재고 예약, 계좌 잔액, 원자적 유일성 검사를 그대로 옮겨서는 안 됩니다. Workers KV의 동작 방식을 확인해야 합니다.

D1은 SQL을 선택할 때의 경로입니다. 키 접두사와 보조 인덱스를 명확한 스키마로 설계해야 합니다. D1의 배치 API는 여러 구문을 트랜잭션으로 실행하지만, Deno의 낙관적 검사를 자동으로 옮겨 주지는 않습니다. 상태와 조정 역할을 하는 컴퓨팅 인스턴스를 결합한 Durable Objects는 채팅방이나 계정처럼 엔터티별로 작업 순서를 보장해야 할 때 검토할 만합니다. D1 트랜잭션과 Durable Objects 문서에서 자세히 설명합니다.

예약 작업용 Cron Triggers는 scheduled 핸들러와 UTC 기준 일정을 사용합니다. 나중에 처리할 작업에는 Queues가 메시징 시스템을 제공합니다. 스케줄은 시작 시점을 정하고, 큐는 처리 대기 중인 작업을 보관합니다. 어느 한쪽을 대체했다고 다른 쪽까지 대체되는 것은 아닙니다. 정적 사이트는 Workers Static Assets를 사용해 생성된 파일과 동적 요청 로직을 분리할 수 있습니다.

요금과 실행 한도 확인하기

Workers Free에는 하루 요청 100,000건과 호출당 CPU 10 ms가 포함됩니다. Paid에는 월 요청 1,000만 건과 CPU 3,000만 밀리초가 포함되며, 초과분은 요청 100만 건당 $0.30, CPU 100만 밀리초당 $0.02입니다. 데이터베이스, 큐 등 다른 제품의 사용료도 별도로 계산해야 합니다. Workers 요금표를 기준으로 합니다.

번들 크기만으로 Paid를 선택할 필요는 없어졌습니다. Free와 Paid 모두 압축 해제 기준 64 MiB까지 허용하며, 메모리는 여전히 128 MB입니다. 현재 한도와 번들 크기에 따른 유료 전환 설명을 확인하면 됩니다. 계정 내 여러 제품이 어떻게 연결되는지는 Cloudflare 리뷰에서 더 넓게 다룹니다.

1. 1

   런타임에 의존하는 부분 목록화하기

   Deno 네임스페이스 호출, URL 임포트, 파일 시스템 접근, 비밀 값, KV 작업, 예약 작업, 큐 소비자를 찾아 정리합니다. 이식 가능한 비즈니스 로직과 플랫폼에 맞춰 바꿔야 하는 어댑터를 분리합니다.

2. 2

   Worker에 맞는 진입점 만들기

   Deno의 Wrangler 튜토리얼에 따라 모듈 핸들러와 생성된 Workers 타입을 설정합니다. 임포트에 필요하다면 Deno를 인식하는 커스텀 빌드도 구성합니다. 핸들러 호출 방식은 바꾸되, 기존 응답 규약은 유지합니다.

3. 3

   상태 저장소와 트리거 설계하기

   레코드를 가져오기 전에 데이터베이스를 선택합니다. 바인딩을 추가하고 일정을 Cron Triggers로 옮긴 뒤, 큐 생산자와 소비자를 재작성합니다. 같은 작업이 다시 전달됐을 때 어떻게 처리되는지도 문서로 남깁니다.

4. 4

   트래픽 전환 전 예행연습하기

   로컬 테스트 데이터와 별도의 이전 대상 환경에서 상태 코드, 헤더, 인증, 상태 변경을 비교합니다. 코드 배포는 점검 항목 중 하나일 뿐입니다. 데이터와 백그라운드 작업도 같은 시점에 전환할 준비가 되어 있어야 합니다.

2. Netlify: Deno 기반 엣지 로직을 쓰는 웹사이트에 적합

Netlify는 Deno 기반 Edge Functions를 제공하는 웹사이트 배포 플랫폼입니다. 현지화, 인증 확인, 리디렉션, 간단한 개인화처럼 들어오는 요청을 중심으로 동적 처리를 수행하는 사이트에 적합합니다. 새로운 인프라 모델을 도입하는 것보다 이런 로직을 사이트의 배포 미리보기와 함께 관리하는 편이 더 가치 있을 수 있습니다. 무상태 엣지 핸들러는 옮기기 좋은 대상이지만, 큐 의존도가 높은 백엔드는 더 많은 기능을 분리해야 합니다. 웹사이트가 제품의 중심이고 엣지 로직이 이를 뒷받침한다면 Netlify를 선택하는 것이 좋습니다. Edge Functions 개요에서 구조를 확인할 수 있습니다.

적합한 용도: 가벼운 Deno 기반 요청 로직을 사용하는 정적 사이트와 웹 애플리케이션입니다.
주요 강점: Edge Functions를 사이트와 함께 배포하며, 미리보기와 롤백도 지원합니다.
요금: Free 계속 $0, Personal 월 $9, Pro 월 $20에 멤버 수 무제한, Enterprise 별도 견적입니다.
무료 체험: Free에는 월 300크레딧 한도가 있습니다.
이전 난이도: 사이트와 무상태 엣지 로직은 낮음~중간이며, 저장소·예약 작업·큐 소비자를 분리해야 한다면 높아집니다.

익숙한 런타임에서도 앱의 동작 조건은 달라집니다

Edge Function은 Netlify의 핸들러와 컨텍스트를 사용합니다. 임포트 방식도 검토해야 합니다. Netlify 문서는 deno.json 안의 임포트 맵 대신 별도 임포트 맵 파일을 사용하도록 안내하며, npm 패키지 지원은 베타로 설명합니다. 현재 Deno 설정에 의존해 패키지를 해석하는 프로젝트라면 이 부분을 실제 이전 작업에 포함해야 합니다. Edge Functions API를 참고할 수 있습니다.

실행 한도는 요청당 CPU 50 ms, 응답 헤더 타임아웃 40초입니다. 원격 서비스의 응답을 기다리는 일과 큰 문서를 변환하는 일은 서로 다른 한도를 소모합니다. 인증 정보 조회는 가벼운 엣지 설계에 맞을 수 있지만, CPU를 많이 쓰는 처리는 다른 실행 경로로 분리하는 것이 좋습니다. Edge Function 한도에서 확인할 수 있습니다.

Deno KV·cron·큐는 무엇으로 대체할까

키로 접근하는 콘텐츠 중 용도에 맞는 데이터에는 Netlify Blobs를 사용할 수 있습니다. 관계형 데이터와 트랜잭션 업데이트가 필요한 앱에는 Postgres 서비스인 Netlify Database가 적합합니다. Blobs는 강한 일관성의 읽기를 옵션으로 제공하지만, 읽기 일관성을 높이는 것만으로 Deno KV의 원자적 다중 키 API를 재현할 수는 없습니다. 새 저장소에서도 사용자 이름 중복 방지 같은 비즈니스 불변 조건이 지켜지도록 설계해야 합니다.

Scheduled Functions는 Netlify Functions의 별도 기능입니다. Edge Function에 Deno.cron이 들어 있다고 해서 관리형 예약 실행이 자동으로 적용되지는 않습니다. 작업을 분리하고 일정을 설정한 뒤, 해당 작업의 런타임을 따로 검토해야 합니다. 기존 작업이 Deno KV 큐를 소비한다면 메시지를 영속적으로 보관할 저장소와 소비자를 명확히 정해야 합니다. 함수에 일정을 설정하는 것만으로 큐에 쌓인 메시지가 옮겨지지는 않습니다.

콘텐츠 사이트와 매시간 실행하는 동기화 작업을 운영하는 창업자라면 이 정도의 분리는 관리할 만합니다. 사이트 제공과 개인화는 웹 플랫폼에 맡기고, 동기화에는 별도의 예약 함수와 영속 상태를 두면 됩니다. 반대로 앱 대부분이 서로 의존하는 백그라운드 워커로 구성되어 있다면 매력이 줄어듭니다.

크레딧과 팀 구성을 함께 계산하기

Personal에는 월 1,000크레딧이 포함됩니다. Pro의 월별 크레딧 구간은 3,000크레딧에 $20, 5,000크레딧에 $33, 10,000크레딧에 $63, 15,000크레딧에 $95, 20,000크레딧에 $126입니다. 5,000크레딧부터 시작하는 상위 구간은 사용하지 않은 월간 크레딧을 다음 결제 주기로 이월할 수 있지만, 기본 구간은 이월되지 않습니다. Netlify 크레딧 구간 안내를 기준으로 합니다.

자동 충전은 기본적으로 꺼져 있습니다. 활성화하면 Personal은 $5에 500크레딧, Pro는 $10에 1,500크레딧을 추가할 수 있습니다. 추가 크레딧 없이 계정의 제공량을 소진하면 프로젝트가 일시 중지될 수 있으므로, 공개 출시에 앞서 배포뿐 아니라 지출 방침도 정해야 합니다. 현재의 크레딧 요금제를 과거 Netlify의 좌석 기반 요금제와 혼동해서는 안 됩니다.

3. Supabase Edge Functions: 데이터베이스 중심 API에 적합

Supabase Edge Functions는 Deno 호환 런타임에서 실행되는 TypeScript 함수입니다. 마이그레이션과 함께 관계형 데이터베이스인 Postgres로 옮기려는 경우에 가장 잘 맞습니다. 결제 웹훅을 받아 고객 레코드를 갱신하는 구독형 앱이 자연스러운 예입니다. 익숙한 런타임 덕분에 일부 변경 작업은 줄어들지만, 데이터베이스가 설계의 중심 과제가 됩니다. 앱의 영속 데이터가 아키텍처를 좌우한다면 Supabase를 선택하는 것이 좋습니다. Functions 문서에서 실행 환경을 확인할 수 있습니다.

적합한 용도: Postgres, 인증, 파일 저장소와 함께 운영할 웹훅과 API입니다.
주요 강점: 데이터베이스 플랫폼과 통합된 Deno 호환 함수입니다.
요금: Free 월 $0, Pro 월 $25부터, Team 월 $599부터, Enterprise 별도 견적입니다.
무료 체험: Free는 프로젝트당 Edge Function 호출 500,000건과 500 MB 데이터베이스를 포함합니다.
이전 난이도: 호환되는 핸들러는 중간, Deno KV를 관계형 스키마와 새로운 트랜잭션 로직으로 바꿔야 한다면 높음입니다.

엔드포인트와 함께 데이터 모델도 옮기기

Deno KV 호출을 Postgres 접근 코드로 교체합니다. 사용자가 저장한 항목을 나타내는 키 접두사는 조회 가능한 관계로, 유일성 검사는 데이터베이스 제약 조건이나 트랜잭션으로 바뀝니다. 중요한 쿼리를 실행할 때마다 키를 해석해야 한다면, 가져오기가 쉬워 보인다는 이유만으로 내부 구조가 드러나지 않는 키 문자열 묶음을 그대로 유지해서는 안 됩니다.

예를 들어 결제 핸들러는 이벤트 기록과 이용 권한 갱신을 함께 처리해야 할 수 있습니다. 재시도해도 권한이 두 번 부여되지 않아야 이전이 성공한 것입니다. 새 함수에서 HTTP 성공 응답을 받는 것만으로는 저장소를 다시 작성한 뒤에도 이 불변 조건이 유지된다고 입증할 수 없습니다.

Supabase는 데이터베이스 작업을 실행하거나 Edge Function을 호출하는 Cron, Postgres 기반의 영속 메시징 서비스인 Queues도 제공합니다. Deno.cron 등록 코드와 Deno KV의 큐 삽입·소비 코드를 이 서비스에 맞춰 교체해야 합니다. 메시지 수신 확인 방식과 실패한 작업을 다시 시도할 수 있게 되는 조건도 결정해야 합니다.

런타임 한도와 실제 시작 비용 확인하기

Edge Functions는 메모리 256 MB, 요청당 CPU 2초를 허용합니다. 워커의 실제 경과 시간 한도는 Free 150초, 유료 요금제 400초입니다. 워커가 더 오래 유지된다고 CPU 사용 시간까지 늘어나는 것은 아닙니다. 서로 다른 제한이므로 장시간 실행 워커의 한도를 설명할 때 혼용해서는 안 됩니다. 함수 한도를 확인해야 합니다.

Pro와 Team은 함수 호출 200만 건을 포함하며, 초과분은 100만 건당 $2입니다. Free는 활성 프로젝트 2개를 허용하고, 1주 동안 사용하지 않은 프로젝트는 일시 중지합니다. 유료 요금제에는 Micro 인스턴스 비용을 충당하는 월 $10 컴퓨팅 크레딧이 포함됩니다. Supabase 요금표를 기준으로 합니다.

사이트의 정적 프런트엔드를 옮길 대상으로는 Supabase의 적합성이 떨어집니다. 함수 한도 문서에 따르면 HTML을 제공하려면 커스텀 도메인이 필요하며, 그렇지 않으면 text/html 응답이 text/plain으로 바뀝니다. 프런트엔드 호스팅과 API의 이전 대상은 별도로 선택해야 합니다.

4. Vercel Functions: 웹 프레임워크가 이전의 중심일 때 적합

Vercel Functions는 웹 배포에 연결되는 관리형 서버 함수입니다. 프런트엔드 프레임워크와 릴리스 워크플로가 플랫폼을 바꾸는 주된 이유인 앱에 잘 맞습니다. 이미 Vercel이 지원하는 프레임워크를 중심으로 앱을 재구성하고 있다면, API 라우트도 그 구조 안으로 옮기는 것이 합리적일 수 있습니다. 반면 기존 Deno 서비스를 거의 그대로 유지하려는 경우에는 덜 직접적인 이전 경로입니다. 앱의 워크플로를 기준으로 Vercel을 선택하되, 런타임과 저장소를 이식할 계획을 명확히 세워야 합니다.

적합한 용도: 프런트엔드와 API 라우트를 함께 두는 프레임워크 중심 웹 애플리케이션입니다.
주요 강점: 서버 함수를 포함한 앱 배포 워크플로를 하나로 관리합니다.
요금: Hobby 월 $0, Pro 월 $20, Enterprise 별도 견적입니다.
무료 체험: Pro는 체험 제공을 안내하며, Hobby는 개인의 비상업적 용도로 제한됩니다.
이전 난이도: 런타임과 라우트 조정은 중간, 저장소와 백그라운드 작업도 교체해야 한다면 높음입니다.

코드를 이식할지, 커뮤니티 런타임을 유지할지 결정하기

Vercel은 Node.js를 지원 런타임으로, Deno를 vercel-deno라는 커뮤니티 런타임으로 안내합니다. 유지보수 관점에서 서로 다른 선택입니다. 마감이 정해진 이전이라면 프로덕션의 핵심 의존성으로 채택하기 전에 커뮤니티 통합의 호환성과 유지보수 주체를 평가해야 합니다. 그렇지 않다면 프레임워크에서 사용하는 지원 런타임에 맞춰 핸들러와 의존성을 이식하는 것이 좋습니다. Vercel 런타임 문서를 참고할 수 있습니다.

Deno KV는 데이터베이스를 선택한 뒤 API를 교체해야 합니다. Vercel의 저장소 가이드는 파일용 Blob, 설정용 Global Config, 앱 데이터용 Marketplace 데이터베이스를 구분합니다. 키-값 인터페이스가 편리해 보인다는 이유만으로 설정 저장소를 트랜잭션이 필요한 고객 레코드의 기본 저장소로 삼아서는 안 됩니다.

Vercel Cron은 실행 일정을 대체하지만 Deno.cron의 코드 등록 방식을 그대로 받지는 않습니다. Hobby는 작업당 하루 한 번 실행할 수 있고, 실행 시각의 정밀도는 시간 단위입니다. Pro의 최소 실행 간격은 분당 한 번입니다. 동기화를 자주 해야 한다면 스케줄링 조건만으로도 Hobby는 후보에서 제외됩니다. Cron 사용량과 요금을 확인해야 합니다.

Vercel Queues는 현재 모든 요금제에서 베타로 제공되며, 영속 토픽, 자동 재시도, 최소 한 번 전달을 지원합니다. 따라서 Deno KV 큐 작업을 옮길 후보가 될 수 있지만, 생산자·소비자·수신 확인 동작은 다시 작성해야 합니다. 고객 주문을 이행하는 유일한 경로가 이 큐라면 베타 상태도 선택 기준에 포함해야 합니다.

배포하는 사람이 늘면 비용도 달라집니다

Pro 플랫폼 요금에는 배포 권한이 있는 좌석 1개와 월 사용량 크레딧 $20이 포함됩니다. 유료 좌석을 추가하면 좌석당 월 $20이며, 열람 전용 좌석은 무료입니다. 크레딧 초과 사용량과 유료 부가 기능은 별도로 청구됩니다. Pro 결제 안내를 기준으로 합니다.

Deno Deploy를 떠나는 사업자에게 무료 Hobby 요금은 프로덕션 예산의 기준이 될 수 없습니다. 상업적 용도로 사용할 수 있는 요금제에서 출발해 데이터베이스와 큐 요구 사항을 더해야 합니다. 그래야 저렴해 보였던 이전이 예상 밖의 여러 청구서로 돌아오는 일을 막을 수 있습니다.

5. Val Town: 소규모 API와 예약 작업에 적합

Val Town은 HTTP, 이메일, cron 트리거를 갖춘 소규모 프로그램용 호스팅 환경입니다. 하나의 유용한 일을 수행하는 작은 서비스에 잘 맞습니다. 외부 시스템을 갱신하는 웹훅, 내부 도구에서 쓰는 API, 정기 요약 발송 작업이 그 예입니다. Deno 런타임을 사용하므로 이전 후보가 되지만, 저장소와 트리거 인터페이스는 여전히 다릅니다. 직접 운영할 플랫폼보다 작은 자동화 작업이 필요한 프로젝트라면 Val Town을 선택하는 것이 좋습니다. Val Town 문서에서 구조를 확인할 수 있습니다.

적합한 용도: 소규모 API, 웹훅 핸들러, 예약 연동 작업, 내부 유틸리티입니다.
주요 강점: 코드 호스팅에 트리거와 SQLite 저장소가 내장되어 있습니다.
요금: Free $0, Pro 연간 결제 시 월 $21, Business 연간 결제 시 월 $167부터, Enterprise 별도 견적입니다. 업체 FAQ에 나온 월간 구독 요금은 Pro $25, Business $200입니다.
무료 체험: Free는 상시 제공되는 요금제이며, 커스텀 도메인과 비공개 val은 지원하지 않습니다.
이전 난이도: 무상태 유틸리티는 낮음, 소규모 영속 작업은 중간, 더 큰 상태 기반 앱은 높음입니다.

결제 주기를 구분해야 합니다. 연간 결제가 선택된 요금 페이지의 금액을 매달 해지할 수 있는 월간 구독 요금처럼 소개해서는 안 됩니다. Val Town FAQ에서 월간 결제 요금을 비교할 수 있으며, Deno 런타임을 사용한다는 점도 확인할 수 있습니다.

작업이 작아야 이전 범위도 작습니다

핸들러를 Val Town의 버전 관리형 앱 컨테이너인 val로 옮기고, HTTP 또는 cron 트리거로 호출하도록 연결합니다. 외부 API를 호출해 요약을 보내기만 하는 작업이라면 마지막으로 처리한 항목만 영속 상태로 남겨도 될 수 있습니다. 여러 트랜잭션 엔터티와 큐 소비자를 갖춘 고객용 앱보다 동작을 파악하기 훨씬 쉽습니다.

용도에 맞는다면 Deno KV를 Val Town의 val별 SQLite 데이터베이스로 바꾸고, 그렇지 않다면 외부 데이터베이스를 유지합니다. 키 조회와 원자적 검사는 데이터베이스 작업으로 다시 작성해야 합니다. Deno.openKv가 종료 예정인 호스팅 저장소를 계속 가리키는 상태에서 이전이 끝났다고 판단해서는 안 됩니다.

큐 작업은 대기 중인 작업이 설계에 명확히 드러나야 합니다. cron으로 작업 테이블을 주기적으로 조회하는 방식도 가능하지만, 작업을 가져가 처리할 권한의 확보, 재시도, 중복 처리를 직접 구현해야 합니다. 이 방식이 Deno KV 큐의 동작을 자동으로 보존해 주지는 않습니다.

실행 빈도·비공개 여부·소요 시간으로 요금제 고르기

Free의 최소 cron 간격은 15분, 실제 경과 시간 한도는 실행당 1분입니다. Pro는 간격을 1분으로 줄이고 실행 한도를 10분으로 늘립니다. 요금 안내에는 커스텀 도메인 10개와 비공개 val 2,000개도 명시되어 있습니다. 현재 요금과 한도를 확인해야 합니다.

공개된 일일 요약 작업은 Free에 맞을 수 있습니다. 비공개 연동이나 더 자주 폴링해야 하는 작업은 트래픽이 아주 적더라도 다른 요금제가 필요합니다. 코드의 비공개 여부와 엔드포인트 접근 권한도 별개입니다. 소스가 비공개라는 사실만으로 누가 HTTP 엔드포인트를 호출할 수 있는지가 정해지지는 않습니다.

단순한 트리거를 쓰는 무상태 유틸리티의 이전 난이도는 낮고, 영속적인 작업 상태를 옮겨야 한다면 중간입니다. 더 큰 앱의 런타임과 데이터 아키텍처를 이 안에서 재현하려 한다면 난이도는 높습니다. 이는 작업 범위에 대한 판단이며, 소요 시간을 추정한 값은 아닙니다.

6. Deno 자체 호스팅: 런타임 동작을 유지해야 할 때 적합

가상 사설 서버, 즉 VPS에서 Deno를 실행하면 런타임을 유지하는 대신 호스팅을 직접 책임지게 됩니다. 컨테이너는 런타임과 앱을 묶어 원하는 호스트에서 실행할 수 있게 합니다. 파일 시스템 접근, Deno 고유 API, 장시간 유지되는 프로세스의 동작이 이식 작업의 큰 부분을 차지한다면 검토할 만합니다. 런타임을 유지해 줄어드는 복잡성이 서버 운영으로 늘어나는 복잡성보다 크다면 자체 호스팅을 선택하는 것이 좋습니다. Deno는 공식 Docker 가이드를 제공합니다.

적합한 용도: 운영자가 서버나 컨테이너 배포를 관리할 수 있는 Deno 의존도가 높은 앱입니다.
주요 강점: 런타임, 파일 시스템, 프로세스 수명주기를 직접 제어할 수 있습니다.
요금: 오픈 소스 런타임 자체에는 관리형 호스팅 요금제가 없습니다. 호스팅 업체의 한 예로 DigitalOcean은 RAM 512 MiB를 갖춘 Basic Regular Droplet을 월 $4.00, 1 GiB 옵션을 월 $6.00에 안내합니다.
무료 체험: DigitalOcean은 프로모션 크레딧을 언급하지만, 요금 페이지에 상시 무료 Droplet 요금제를 제공하지는 않습니다.
이전 난이도: 런타임 코드 수정 부담은 줄고 운영 책임은 늘어납니다. 호스팅된 데이터에는 여전히 내보내기·가져오기·복구 계획이 필요합니다.

이 금액은 공개된 VPS 요금이며, 모든 Deno 앱에 해당 사양을 권한다는 뜻은 아닙니다. 백업 저장소, 모니터링, 직접 운영하는 데 드는 시간도 판단에 포함해야 합니다. 이미 보유한 서버를 쓰면 새 호스팅 구독료는 들지 않을 수 있지만 유지보수 작업은 여전히 생깁니다.

Deno KV와 cron은 어떻게 달라질까

Deno KV는 영속적인 로컬 데이터베이스 경로를 사용할 수 있으며, CLI에서는 내부적으로 SQLite를 사용합니다. 다른 업체의 저장소로 옮기는 것보다 KV API를 더 많이 유지할 수 있습니다. 다만 호스팅된 레코드를 복사하거나, 분산 호스팅을 재현하거나, 컨테이너의 임시 파일 시스템에 영속성을 부여해 주지는 않습니다. 데이터를 내보내고 계획에 따라 가져온 뒤, 영속 저장소를 마운트하고 백업을 실제로 복원할 수 있는지 검증해야 합니다. Deno KV 문서를 참고할 수 있습니다.

스케줄링에도 같은 구분이 적용됩니다. CLI의 Deno.cron은 실행 상태를 메모리에 저장하며, 프로세스마다 독립적인 작업 집합을 가집니다. 앱 복제본을 여러 개 실행한다면 어느 복제본이 예약 작업을 맡을지, 또는 어떻게 서로 조정할지 결정해야 합니다. API 호출을 그대로 둔다고 Deploy의 관리형 스케줄링 서비스까지 유지되는 것은 아닙니다. Deno cron 동작 방식을 확인해야 합니다.

작은 단일 서버 앱이라면 이 정도의 운영 범위를 감당할 수 있습니다. 하지만 이중화된 인프라가 필요한 사업에서 백업·패치·복구를 맡을 사람이 없다면, 저렴한 VPS 요금이 오히려 큰 부담으로 돌아올 수 있습니다.

workerd와 celld는 별도의 자체 호스팅 경로입니다

Cloudflare는 발표에서 현재 이용 가능한 자체 호스팅 옵션으로 workerd와 celld를 언급합니다. 두 도구는 Workers 프로그래밍 모델을 사용하므로 Workers 방식으로 코드를 이식한 뒤 검토할 대상입니다. 기존 Deno 코드를 모두 그대로 실행할 수 있다는 약속으로 받아들여서는 안 됩니다. Cloudflare는 독립형 workerd의 Durable Objects 구현에 단일 인스턴스를 넘어서는 확장성의 한계가 있음을 인정하며, celld의 작업 결과와 아이디어를 workerd에 통합하는 방향도 설명합니다. Cloudflare 발표에서 확인할 수 있습니다.

둘 중 어느 쪽도 임의의 무료 요금제를 붙여 새로운 관리형 구독 서비스처럼 계산해서는 안 됩니다. 예산에 넣어야 할 것은 직접 마련하는 인프라와 운영 비용입니다. 이전 일정에 쫓기는 팀이라면 현재 제공되는 기능과 직접 실행할 수 있는 복구 계획을 평가해야 합니다. 향후 통합 작업이 이런 결정을 대신해 주지는 않습니다.

Deno 자체 호스팅은 과도기적 대안이 될 수 있습니다. 다만 Deno가 발표한 지원 기간을 고려하면, 더 장기적인 런타임 유지보수 계획도 중요합니다.

프로젝트에서 실제로 실행하는 작업을 기준으로 선택하기

옮기기 가장 어려운 대상이 코드가 아니라 상태라면 선택도 달라집니다. 구체적으로 필요한 변경을 기준으로 난이도를 평가해야 합니다. 낮음은 외부 상태 저장소를 그대로 둔 채 핸들러나 빌드만 조정하는 경우입니다. 중간은 여기에 런타임 연동부나 저장소 API 재작성이 더해지는 경우입니다. 높음은 트랜잭션 재설계, 큐에 쌓인 작업 이전, 새로운 운영 책임까지 생기는 경우입니다. 작은 앱이라도 정확한 동작이 이런 요소에 달려 있다면 이전 난이도가 높을 수 있습니다.

Deno 고유 API를 사용하지 않는 TypeScript 함수라면 Workers부터 검토합니다. 요청과 응답 규약을 유지한 뒤 진입점과 배포 방식을 조정합니다. 사이트 요청을 수정하는 함수라면 Netlify, 주로 데이터베이스를 다루는 함수라면 Supabase의 매력이 커집니다. 앱을 둘러싼 프레임워크가 이미 이전의 이유라면 Vercel이 유리합니다. 어느 플랫폼이든 무상태 핸들러는 대체로 이전 부담이 가장 적습니다.

Deno KV는 저장 모델부터 선택합니다. 읽기 위주의 콘텐츠라면 Workers KV나 Netlify Blobs가 맞을 수 있습니다. 트랜잭션이 필요한 레코드는 D1, Postgres 또는 필요한 불변 조건을 지키도록 설계된 다른 데이터베이스를 검토해야 합니다. 조정이 필요하다면 Durable Objects가 후보가 됩니다. 작은 유틸리티는 Val Town SQLite만으로 충분할 수 있습니다. 자체 호스팅하는 로컬 KV는 코드를 더 많이 보존하지만 데이터 내구성과 복구 책임을 직접 맡아야 합니다. 호스팅된 KV의 이전은 트랜잭션과 인덱스 목록을 점검해 더 단순하다고 확인하기 전까지 최소 중간 수준의 범위로 보는 것이 좋습니다.

cron은 실행 조건을 비교합니다. 일일 보고서와 빈번한 폴링 작업은 요금제 요구 사항이 다릅니다. 관리형 경로로는 Workers Cron Triggers를 먼저 검토하고, 작은 작업에는 Val Town, 데이터베이스 유지보수에는 Supabase Cron, 사이트와 관련된 작업에는 Netlify Scheduled Functions를 고려할 수 있습니다. Vercel Hobby는 하루 단위 실행 제약 때문에 잦은 작업에 맞지 않습니다. 일정을 다시 등록하는 일은 간단해도, 실행이 겹쳐 같은 효과가 중복 발생하지 않게 하는 일은 그렇지 않을 수 있습니다.

큐는 대기 작업과 소비자를 함께 옮깁니다. Cloudflare Queues와 Supabase Queues는 명확한 이전 대상이며, Vercel Queues는 베타 후보입니다. 메시지 식별, 재시도, 수신 확인, 이미 대기 중인 작업을 모두 이전 범위에 포함해야 합니다. 타이머만으로 대체할 수는 없습니다. 큐 작업이 유료 고객에게 이행해야 할 의무를 나타낸다면 이전 범위를 높음으로 잡아야 합니다.

정적 사이트는 불필요한 서버 코드를 이식하기 전에 생성된 결과물부터 옮깁니다. Workers Static Assets와 Netlify가 직접적인 후보입니다. 사이트 프레임워크가 Vercel의 워크플로에서 이점을 얻는다면 Vercel도 후보에 넣습니다. 리디렉션, 헤더, 폼, 인증, 동적 라우트는 각각 점검해야 합니다. 단순한 정적 결과물의 이전은 요청마다 개인화된 응답을 렌더링하는 사이트보다 부담이 적습니다.

Deno Deploy 마이그레이션: KV 데이터와 동작 규칙 지키기

코드 배포와 데이터 마이그레이션은 성공 기준이 다릅니다. 코드는 올바른 응답을 내면 성공이지만, 데이터 이전은 그 응답을 올바르게 만드는 레코드와 규칙이 새 환경에서도 보존되어야 성공입니다.

내보내기 전에 사용 중인 KV 기능을 목록으로 정리해야 합니다. 타입이 있는 복합 키, 접두사 스캔, 만료, 보조 인덱스, 낙관적 버전 검사, 원자적 갱신, 변경 감시가 대상입니다. Deno의 KV 가이드를 보면, 키 모음 안에 단순한 객체 덤프로는 드러나지 않는 앱의 동작 규칙이 담길 수 있음을 알 수 있습니다.

사용자 이름 인덱스를 예로 들 수 있습니다. 사용자 레코드와 사용자 이름으로 사용자를 찾는 조회 항목을 저장하는 앱이라면, 두 레코드를 복사하는 것만으로는 충분하지 않습니다. 새 쓰기 경로가 둘 사이의 관계를 유지하고 충돌하는 갱신을 거부해야 합니다. 마찬가지로 세션 만료에 쓰던 타임스탬프에는 새 환경의 명시적인 만료 정책이 필요합니다. 동작 없이 값만 가져오면 세션이 의도보다 오래 유효할 수 있습니다.

큐는 원본에서 확인할 수 있는 범위 안에서 대기·완료·실패 작업 목록을 따로 관리해야 합니다. 전환 전에 기존 소비자가 큐를 모두 처리하게 할지, 안전하게 재실행할 수 있는 식별자와 함께 작업을 옮길지 결정합니다. 멱등성은 작업을 반복해도 비즈니스 효과가 중복 발생하지 않는 성질입니다. 영수증 발송 작업을 재시도해도 여러 장이 발송되지 않게 하고, 주문 이행 메시지가 반복되어도 중복 작업이 생기지 않게 하는 속성입니다.

1. 1

   복사 중 쓰기 처리 방침 정하기

   원본을 백업하고 복사 중 들어오는 쓰기를 어떻게 처리할지 결정합니다. 작은 앱은 잠시 쓰기를 멈추는 방식이 적합할 수 있습니다. 더 복잡한 동기화 방식을 쓰려면 차이를 대조하고 조정하는 과정이 필요합니다. 내보내기와 전환 사이에 동시에 발생한 변경이 소리 없이 사라지지 않도록 해야 합니다.

2. 2

   레코드와 동작 검증하기

   엔터티 유형별 개수, 대표 값, 키 인코딩을 비교합니다. 통제된 테스트 데이터로 중복 제출, 충돌하는 갱신, 만료, 레코드 누락을 확인합니다. 새 API가 성공을 반환하는지만 볼 것이 아니라, 기대한 비즈니스 결과가 나오는지 검증해야 합니다.

3. 3

   트래픽과 작업 담당 주체를 함께 전환하기

   이전 대상의 상태가 준비된 뒤에만 요청을 전환합니다. 기존 예약 작업과 소비자는 중지하거나 담당을 넘겨 양쪽 플랫폼이 같은 효과를 중복 발생시키지 않게 합니다. 비밀 값과 웹훅 목적지도 빠짐없이 다시 설정합니다.

4. 4

   전환 후 관찰하고 실제로 쓸 수 있는 롤백 경로 유지하기

   변경 후 오류, 실패한 작업, 비즈니스 이벤트를 모니터링합니다. 원본 백업은 유지해야 합니다. 새 환경에서 이미 쓰기를 받았다면 DNS만 되돌려서는 안 되며, 롤백 시 데이터를 대조하고 조정할 계획이 필요합니다.

다음 작업 시간에는 현황 목록을 만들고, 상태를 다루는 가장 까다로운 작업의 이전 대상을 결정하는 것이 좋습니다. 나머지 이전 작업을 다듬기 전에 그 작업부터 이식해야 합니다. 무상태 헬스 체크 엔드포인트를 하나 더 옮기는 것보다 더 많은 위험을 드러낼 수 있습니다.

이 대안들을 선정한 기준

Deno Deploy 앱이 처리하는 HTTP 함수, 영속 상태, 예약 작업, 큐 작업, 정적 결과물을 기준으로 이전 경로를 골랐습니다. Cloudflare를 가장 앞에 둔 이유는 Deno가 이전 경로로 지목했기 때문입니다. Netlify, Supabase, Val Town은 Deno 기반 실행 환경과 각기 다른 앱 용도에 대한 적합성으로, Vercel은 웹 배포 워크플로로, 자체 호스팅은 런타임 제어권으로 선정했습니다.

요금과 기능은 2026년 10월 12일 각 업체의 공개 페이지를 기준으로 확인했습니다. 난이도 평가는 문서에 나온 인터페이스를 사용할 때 필요한 변경을 설명합니다. 실제로 측정한 마이그레이션 시간이나 부하 테스트 결과가 아니며, 로그인 후 체험했다는 주장도 아닙니다. 범용 클라우드 서비스는 후보에서 제외했습니다. 공급업체 이름을 더 늘려도 런타임, 상태, 작업 담당 주체에 관한 핵심 결정이 해결되지는 않기 때문입니다.

이번 이전에서 피해야 할 선택

트랜잭션을 사용하는 Deno KV를 Workers KV로 기계적으로 교체해서는 안 됩니다. 데이터에 읽기·쓰기 동작이 맞을 때만 선택해야 합니다. 일관성에 대한 전제가 무너지는 문제를 저렴한 저장소 요금으로 보상할 수는 없습니다.

CPU를 많이 쓰는 백그라운드 처리에 Netlify Edge Functions를 사용해서는 안 됩니다. 엣지 요청의 실행 한도는 설계의 경계로 받아들여야 합니다. 유료 요금제라면 실행 모델도 달라질 것이라는 기대만으로 우회하려 해서는 안 됩니다.

상업용 프로덕션 앱에 Vercel Hobby를 사용해서는 안 됩니다. 요금 페이지는 용도를 개인의 비상업적 사용으로 제한합니다. cron 제약 때문에 잦은 작업을 위한 무료 요금제 비교 대상으로도 적절하지 않습니다.

비공개로 유지해야 하는 소스에 Val Town Free를 사용해서는 안 됩니다. 트래픽 규모보다 요금제의 이용 조건을 먼저 확인해야 합니다. 일반적인 정적 사이트의 기본 이전 대상으로 Supabase Edge Functions를 택하는 것도 피해야 합니다. 프런트엔드 호스팅은 용도에 맞춰 별도로 선택해야 합니다.

복구 담당자 없이 자체 호스팅을 선택해서는 안 됩니다. 프로세스를 실행하는 일은 이 선택에서 쉬운 부분입니다. 누군가는 데이터를 복원하고 서비스를 다시 시작할 수 있어야 하며, 장애 뒤 어느 스케줄러가 작업을 맡는지 설명할 수 있어야 합니다.

Deno Deploy 이전 전 자주 묻는 질문

Deno Deploy는 언제 종료되나요?

발표는 특정 날짜 대신 6개월의 운영 기간을 제시합니다. 명시된 기간을 기준으로 계획해야 하며, 더 긴 런타임 유지보수 기간으로 바꿔 해석해서는 안 됩니다.

Deno Deploy를 떠나도 Deno를 계속 쓸 수 있나요?

가능합니다. Netlify Edge Functions, Supabase Edge Functions, Val Town은 Deno 기반 또는 Deno 호환 실행 환경을 제공하며, VPS나 컨테이너에서는 Deno를 직접 실행할 수 있습니다. 관리형 플랫폼마다 API와 한도가 다릅니다. Deno를 유지한다고 호스팅된 KV 데이터베이스, 예약 작업, 큐까지 자동으로 유지되는 것은 아닙니다.

Deno KV를 Cloudflare KV로 바로 옮길 수 있나요?

API를 조정하고 앱의 일관성 요구 사항이 Workers KV에 맞는지 확인한 경우에만 가능합니다. Deno KV의 원자적 검사, 트랜잭션, 인덱스, 변경 감시는 각각 대체 방식을 정해야 합니다. 트랜잭션이 필요한 레코드는 D1이나 다른 데이터베이스를, 엔터티별 상태 조정은 Durable Objects를 검토하는 것이 좋습니다.

cron 작업을 실행할 수 있는 무료 요금제는 무엇인가요?

실행 빈도와 한도, 소스 비공개 여부, 상업적 이용 가능 여부부터 맞춰야 합니다. Val Town Free의 최소 실행 간격은 15분이고 실행 한도는 1분입니다. Vercel Hobby는 하루 단위 작업과 개인의 비상업적 사용으로 제한됩니다. Workers Free의 CPU 한도는 빠듯하며, Netlify와 Supabase에는 각각 요금제에서 공유하는 제공량이 있습니다. 스케줄러가 무료라고 전체 작업까지 무료 범위에 들어간다는 뜻은 아닙니다.