Skip to content
Published on

엣지 컴퓨트 플랫폼 2026 — Cloudflare Workers / Vercel Fluid / Deno Deploy / Fastly Compute / Bun 심층 비교

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

1. 2026년 엣지 컴퓨트 지도 — V8 isolate / WASM / Firecracker 3 모델

2026년 5월 현재, "엣지 컴퓨트"라는 단어는 더 이상 단일 카테고리가 아니다. 같은 "서버리스 함수"라도 내부 실행 모델이 완전히 다른 3가지로 갈라졌다.

실행 모델콜드스타트격리 단위대표 플랫폼
V8 isolate0 ms 수준V8 컨텍스트Cloudflare Workers, Deno Deploy, Vercel Edge, Netlify Edge, Supabase Edge
WebAssembly35 microsecondsWASM 모듈Fastly Compute (구 Compute@Edge), Cloudflare Workers (WASM 백엔드)
MicroVM (Firecracker)100 ms 이하 (SnapStart 시 50 ms 이하)VMAWS Lambda, Lambda SnapStart, Fly.io Machines, Vercel Fluid (혼합)

핵심 트레이드오프는 항상 같다.

  • V8 isolate: 가장 빠른 콜드스타트, 가장 빠른 글로벌 분산 (200개 이상 PoP), 그러나 Node.js native addon 불가
  • WebAssembly: 언어 자유도 (Rust, Go, Swift, JavaScript 모두 WASM 컴파일), 매우 빠른 콜드스타트, 그러나 생태계 작음
  • MicroVM: 완전한 Linux, 모든 npm 패키지 호환, 그러나 콜드스타트 무겁고 지역 분산 제한적

2026년 트렌드는 명확하다. 풀스택 엣지 플랫폼(Cloudflare)과 하이브리드 서버리스(Vercel Fluid Compute)가 양극을 차지하고, 나머지는 특정 워크로드(Fastly의 CDN, Deno의 Web 표준, Bun의 속도)로 자리를 잡았다.

WinterCG에서 WinterTC로 — 표준의 진화

이제 모든 엣지 런타임이 WinterTC (구 WinterCG)의 Minimum Common API 사양을 따른다. fetch, Request, Response, URLPattern, crypto.subtle, TextEncoder, ReadableStream, Headers, FormData, AbortController는 어디서나 동일하게 동작한다. 즉, 잘 만든 엣지 함수는 Cloudflare Workers, Deno Deploy, Vercel Edge, Netlify Edge에서 코드 한 줄 안 바꾸고 돌아간다.

2. Cloudflare Workers — 가장 완성된 엣지 플랫폼

Cloudflare Workers는 2025-2026년에 걸쳐 단순한 "엣지 함수"에서 완전한 풀스택 플랫폼으로 진화했다. 핵심 빌딩 블록은 7가지다.

서비스역할2026년 5월 상태
WorkersV8 isolate 실행 환경GA, 300+ PoP
R2S3 호환 객체 스토리지GA, egress 무료
D1SQLite 기반 글로벌 DBGA (2024.4)
Durable Objects상태 있는 객체 (SQLite 백엔드)GA, SQLite 백엔드 2025년 GA
HyperdrivePostgres / MySQL 커넥션 풀러GA
Queues메시지 큐GA
Workers AIGPU 추론GA

가장 큰 변화는 Durable Objects의 SQLite 백엔드다. 기존 Durable Objects는 K/V 형태로 상태를 저장했지만, 2025년부터 각 DO 인스턴스에 임베디드 SQLite가 붙는다. 즉 각 Durable Object = mini 데이터베이스 + 컴퓨트 조합이 되었다.

// Durable Object with SQLite backend (2025+)
import { DurableObject } from 'cloudflare:workers'

export class ChatRoom extends DurableObject {
  sql: SqlStorage

  constructor(state: DurableObjectState, env: Env) {
    super(state, env)
    this.sql = state.storage.sql
    this.sql.exec(`
      CREATE TABLE IF NOT EXISTS messages (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        user TEXT NOT NULL,
        body TEXT NOT NULL,
        ts INTEGER NOT NULL
      )
    `)
  }

  async addMessage(user: string, body: string) {
    this.sql.exec(
      'INSERT INTO messages (user, body, ts) VALUES (?, ?, ?)',
      user,
      body,
      Date.now()
    )
  }

  async recent(limit = 50) {
    return this.sql
      .exec('SELECT * FROM messages ORDER BY ts DESC LIMIT ?', limit)
      .toArray()
  }
}

Hyperdrive — 엣지에서 Postgres를 쓰는 법

Workers의 V8 isolate는 TCP 소켓을 직접 열 수 없는 게 오래된 한계였다. Hyperdrive가 이걸 해결한다. Postgres / MySQL 연결을 Cloudflare 네트워크 내부에서 풀링하고, Workers는 HTTP-like 인터페이스로 쿼리를 보낸다.

// wrangler.toml
// [[hyperdrive]]
// binding = "DB"
// id = "your-hyperdrive-id"

import { Client } from 'pg'

export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    const client = new Client({ connectionString: env.DB.connectionString })
    await client.connect()
    const { rows } = await client.query('SELECT NOW()')
    return Response.json(rows)
  },
}

Hyperdrive의 진짜 가치는 글로벌 connection pooling + edge caching이다. 도쿄에서 들어온 요청이 미국 RDS까지 가지 않고, 도쿄 PoP의 풀링된 커넥션을 재사용하면서 캐시 가능한 쿼리는 캐시로 응답한다.

3. Cloudflare Workers AI / Vectorize / AI Gateway

Cloudflare의 AI 스택은 2026년 5월 현재 세 축이다.

  • Workers AI: Llama 3, Mistral, Stable Diffusion 등 50+ 모델을 GPU에서 직접 추론. PoP에 분산된 H100/A100.
  • Vectorize: 벡터 DB. RAG에 필수. 메타데이터 필터링, 32K dim 지원.
  • AI Gateway: OpenAI, Anthropic, Replicate 등 외부 LLM API를 프록시. 캐싱, rate limiting, 로깅, 토큰 비용 트래킹.
// AI Gateway through Workers
export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    // 1) Workers AI (Cloudflare's own GPU)
    const llmResp = await env.AI.run('@cf/meta/llama-3-8b-instruct', {
      messages: [
        { role: 'system', content: 'You are a helpful assistant.' },
        { role: 'user', content: 'Explain edge compute in one sentence.' },
      ],
    })

    // 2) AI Gateway proxy to OpenAI (cached, rate-limited)
    const openaiResp = await fetch(
      'https://gateway.ai.cloudflare.com/v1/ACCOUNT/my-gw/openai/chat/completions',
      {
        method: 'POST',
        headers: {
          Authorization: `Bearer ${env.OPENAI_KEY}`,
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          model: 'gpt-4o-mini',
          messages: [{ role: 'user', content: 'Hello' }],
        }),
      }
    )

    return Response.json({ workers_ai: llmResp, openai: await openaiResp.json() })
  },
}

AI Gateway가 무서운 건 모든 외부 LLM 호출을 캐싱한다는 것이다. 같은 프롬프트 + 같은 모델이면 응답을 캐시 히트시켜 비용을 0으로 만들 수 있다. 토큰 단가 절감 효과가 30-60%에 달하는 사례가 흔하다.

4. Cloudflare Containers (2024) — Linux at Edge

2024년 9월에 발표되고 2025년 베타, 2026년 GA로 진입한 Cloudflare Containers는 Workers의 V8 isolate 한계를 정면 돌파한다. 풀 Linux 컨테이너를 엣지 PoP에서 실행할 수 있다.

특징은 다음과 같다.

  • 고정 region 선택 가능: Workers와 달리 컨테이너는 특정 지역(예: 서울)에서만 실행하도록 핀할 수 있다.
  • Workers와의 결합: Workers 코드 안에서 env.MY_CONTAINER.fetch(req)로 컨테이너를 깨워서 호출한다. 처음 호출은 콜드스타트(5-10초)지만 이후는 따뜻한 상태로 유지된다.
  • OCI 이미지: 일반 Dockerfile 사용 가능. ffmpeg, headless Chrome, Python ML 라이브러리 등 무엇이든.
  • 유스케이스: 비디오 트랜스코딩, headless 브라우저, AI 모델 추론(GPU 미지원), 레거시 코드 호스팅.
// wrangler.toml
// [[containers]]
// binding = "MY_CONTAINER"
// image = "./Dockerfile"
// max_instances = 5

export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    // Container is auto-started, kept warm for some time
    const container = env.MY_CONTAINER.get(env.MY_CONTAINER.idFromName('worker-1'))
    return container.fetch(req)
  },
}

Cloudflare Containers는 Workers + Containers 하이브리드 아키텍처의 길을 연다. 일반 요청은 Workers (0ms cold), 무거운 작업은 Containers (Linux full)로 라우팅하는 패턴이 표준이 되고 있다.

5. Vercel Fluid Compute (2025.4) — 서버리스 진화의 다음 단계

2025년 4월, Vercel은 기존 Serverless Functions를 Fluid Compute라는 이름으로 전면 재설계했다. 핵심 아이디어는 단순하다.

"1 instance = 1 request"의 서버리스 모델을 버리고, 하나의 인스턴스가 여러 요청을 동시에 처리하게 한다.

기존 AWS Lambda 모델은 동시 요청마다 새 인스턴스를 깨운다. Vercel Fluid Compute는 Node.js의 단일 프로세스가 여러 요청을 in-flight로 처리하면서, I/O 대기 중인 시간을 다른 요청에 양보한다. 결과적으로:

  • 콜드스타트 빈도 감소: 같은 인스턴스가 더 오래 살아 있고, 더 많은 요청을 처리
  • 비용 절감: 동시 처리 덕분에 같은 트래픽을 더 적은 인스턴스로 처리 (Vercel 공식 발표 기준 평균 40-90% 절감)
  • AI 워크로드 최적화: LLM 응답 대기 시간(수 초)에 다른 요청을 끼워 넣음

Fluid Compute는 모든 Vercel 함수의 기본값이 되었다. Edge Runtime은 그대로 V8 isolate 위에서 돌고, Node.js Runtime이 Fluid로 진화한 것이다.

// app/api/chat/route.ts (Next.js 15+)
// Runs on Vercel Fluid Compute by default
export async function POST(req: Request) {
  const { prompt } = await req.json()

  // This await frees the Fluid worker to handle other requests
  // while the LLM streams back
  const stream = await openai.chat.completions.create({
    model: 'gpt-4o',
    messages: [{ role: 'user', content: prompt }],
    stream: true,
  })

  return new Response(stream.toReadableStream(), {
    headers: { 'Content-Type': 'text/event-stream' },
  })
}

Edge Functions의 미래는?

Vercel은 2025년 후반부터 Edge Functions (Edge Runtime)와 Fluid Compute의 경계를 점차 흐릿하게 만들고 있다. Middleware는 여전히 Edge에서 돌지만, route handler는 대부분 Fluid가 더 유리하다. 권장 룰은:

  • Middleware, geolocation, A/B 라우팅: Edge Runtime (V8 isolate)
  • API route, LLM 호출, DB 쿼리: Fluid Compute (Node.js)
  • 정적 페이지: ISR + CDN (Edge Cache)

6. Deno Deploy + KV + Queues

Deno Deploy는 Deno 런타임을 글로벌 35개 region V8 isolate에서 실행한다. 핵심 강점은 웹 표준 우선이다.

  • Deno.serve()로 즉시 HTTP 서버 시작
  • Deno.openKv() — strongly consistent KV store (FoundationDB 기반)
  • Deno.cron() — 코드 안에서 직접 크론 정의
  • Deno.serve() 핸들러에서 직접 큐 enqueue / dequeue
// main.ts
const kv = await Deno.openKv()

Deno.serve(async (req) => {
  const url = new URL(req.url)

  if (url.pathname === '/enqueue') {
    await kv.enqueue({ task: 'send-email', to: 'user@example.com' })
    return new Response('Queued')
  }

  if (url.pathname === '/count') {
    const result = await kv.get<number>(['visits'])
    const next = (result.value ?? 0) + 1
    await kv.atomic().check(result).set(['visits'], next).commit()
    return new Response(`Visits: ${next}`)
  }

  return new Response('Hello from Deno Deploy')
})

// Queue consumer
kv.listenQueue(async (msg: { task: string; to: string }) => {
  console.log('Processing:', msg.task, msg.to)
  // send email...
})

// Cron job — runs every hour
Deno.cron('hourly cleanup', '0 * * * *', async () => {
  await kv.delete(['expired-cache'])
})

Deno Deploy의 매력 포인트는 추가 인프라 없이 작은 풀스택 앱이 완성된다는 것이다. Deno + Deno KV + Deno Queues + Deno Cron 만으로 백엔드가 끝난다. Fresh 프레임워크나 Hono와 잘 어울린다.

2026년 현재 Deno Deploy의 약점은 AWS / Cloudflare 대비 region 수가 적다는 것 (35개 vs 300개+)과 콜드스타트가 Workers보다 약간 느리다는 점이다.

7. Fastly Compute@Edge — WASM 기반

Fastly는 처음부터 **WebAssembly (Wasmtime 기반)**를 선택한 유일한 메이저 엣지 플랫폼이다. 이름도 2024년에 그냥 "Fastly Compute"로 줄였다. WASM의 장점은:

  • 마이크로초 단위 콜드스타트: V8 isolate보다도 빠른 35 microseconds 수준
  • 다언어 지원: Rust, JavaScript, Go (TinyGo), AssemblyScript, Swift, C/C++
  • 샌드박싱이 V8 isolate보다 강함: WASI를 통한 capability-based 권한 모델
// Rust on Fastly Compute
use fastly::http::{Method, StatusCode};
use fastly::{Error, Request, Response};

#[fastly::main]
fn main(req: Request) -> Result<Response, Error> {
    match (req.get_method(), req.get_path()) {
        (&Method::GET, "/") => Ok(Response::from_status(StatusCode::OK)
            .with_body_text_plain("Hello from Fastly WASM!")),
        (&Method::POST, "/api/echo") => {
            let body = req.into_body_str();
            Ok(Response::from_status(StatusCode::OK).with_body_text_plain(&body))
        }
        _ => Ok(Response::from_status(StatusCode::NOT_FOUND)),
    }
}

Fastly의 강점은 CDN의 깊은 통합이다. 원래부터 CDN 회사였기 때문에 캐시 무효화, ESI (Edge Side Includes), VCL과의 결합이 자연스럽다. 미디어, 뉴스, e-commerce CDN 워크로드에 최적.

약점은 풀스택 빌딩 블록이 없다는 점이다. KV store는 있지만 DB, 큐, AI는 외부 의존. Cloudflare처럼 한 곳에서 다 끝낼 수는 없다.

8. Bun on Render / Fly.io / Railway / Coolify

Bun은 엣지 플랫폼의 1급 시민이 아니다. 정확히는 로컬 개발 + 일반 컨테이너 호스팅 조합에서 강력하다. 2026년 현재 Bun 1.2가 정식 안정 버전이고, Render / Fly.io / Railway / Coolify가 1급 Bun 지원을 한다.

// server.ts — Bun 1.2 native HTTP server
const server = Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url)
    if (url.pathname === '/json') {
      return Response.json({ hello: 'world', runtime: 'bun' })
    }
    return new Response('Hello from Bun!')
  },
})
console.log(`Listening on ${server.url}`)

Bun의 가치 제안은:

  • 빠른 시작 시간: Node.js 대비 2-3배 빠른 콜드스타트
  • 번들러 + 트랜스파일러 + 패키지 매니저 + 테스트 러너 통합: bun install, bun build, bun test 한 도구
  • Web 표준 API 우선: fetch, Request, Response 네이티브
  • Node.js 호환성 95%+: npm 패키지 대부분 동작

Bun을 어디서 돌릴까?

  • Fly.io: Firecracker microVM 기반, 글로벌 30+ region. Bun 컨테이너를 그대로 배포 가능. WebSocket, 영구 볼륨 지원.
  • Render: 단일 region 위주지만 가장 쉬운 배포 경험. Bun 빌드팩 1급.
  • Railway: Render와 유사. 더 강한 PaaS 느낌.
  • Coolify: 셀프 호스팅 PaaS. 본인 VPS에서 Vercel-like 경험.

Bun + Fly.io 조합이 특히 인기 있는 이유는 Cloudflare Workers의 제약(50ms CPU time, 128MB RAM)을 피하면서 글로벌 분산을 유지할 수 있어서다.

9. Netlify Edge Functions

Netlify Edge Functions는 Deno 런타임을 Netlify 인프라에서 실행하는 형태다. 즉, 코드 모델은 Deno Deploy와 동일하고, 차이는 인프라(Netlify의 CDN) + 통합(Netlify Forms, Identity, Blobs)뿐이다.

// netlify/edge-functions/geo.ts
import type { Config, Context } from '@netlify/edge-functions'

export default async (req: Request, context: Context) => {
  const country = context.geo.country?.code ?? 'unknown'
  const city = context.geo.city ?? 'unknown'

  return new Response(
    JSON.stringify({ country, city, ip: context.ip }),
    { headers: { 'Content-Type': 'application/json' } }
  )
}

export const config: Config = {
  path: '/api/geo',
}

Netlify는 정적 사이트 호스팅이 본업이고 Edge Functions는 보조 도구다. SSG + 일부 동적 라우트라면 Netlify가 가장 빠르게 배포되지만, 풀 서버사이드 앱이라면 Vercel이나 Cloudflare가 더 적합하다.

10. AWS Lambda SnapStart — Cold Start 해결

Lambda는 오랫동안 콜드스타트 때문에 엣지에서 밀렸다. Java는 수 초, Python도 수백 ms가 기본이었다. 2022년 Java용으로 시작한 SnapStart가 2024년에 Python / .NET 까지 확장되고, 2026년 현재는 거의 모든 매니지드 런타임에서 사용 가능하다.

SnapStart 원리:

  1. 함수가 처음 배포될 때 한 번만 초기화(Init)를 실행
  2. Firecracker microVM 메모리 스냅샷을 저장 (수십 MB)
  3. 콜드스타트 시 스냅샷을 복원 — 초기화 단계를 건너뜀
  4. 결과: 콜드스타트가 50ms 이하로 떨어짐 (Java 기준 90% 감소)
# AWS SAM template
Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.13
      Handler: app.handler
      CodeUri: ./src
      SnapStart:
        ApplyOn: PublishedVersions

SnapStart의 한계:

  • PublishedVersions에만 적용: $LATEST 별칭에는 불가. 배포 워크플로우가 약간 복잡해진다.
  • VPC + ENI 시간은 줄지 않음: 네트워크 부착 시간은 별개.
  • 스냅샷 시점의 가변 상태 주의: 초기화 단계에서 만든 DB 커넥션 등은 스냅샷에 박혀서, 복원 후엔 죽은 커넥션일 수 있음. SDK가 제공하는 후크(beforeCheckpoint / afterRestore)로 처리해야 한다.

Lambda는 SnapStart로 콜드스타트를 어느 정도 해결했지만, 여전히 region 수가 30개 수준이라 진짜 엣지(300+ PoP)는 아니다. Lambda@Edge가 그 역할을 했지만 CloudFront에 종속되고 제약이 많아, 2026년에는 Cloudflare Workers / Vercel Edge에 사실상 자리를 내줬다.

11. Supabase Edge Functions

Supabase Edge Functions는 Deno 런타임 + Supabase DB / Auth / Storage 통합이다. 코드는 Deno Deploy와 거의 동일하지만, import { createClient } from 'jsr:@supabase/supabase-js'로 Supabase 리소스에 인증 없이 접근할 수 있다.

// supabase/functions/send-welcome/index.ts
import { createClient } from 'jsr:@supabase/supabase-js@2'

Deno.serve(async (req) => {
  const { user_id } = await req.json()

  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  )

  const { data: profile } = await supabase
    .from('profiles')
    .select('email, name')
    .eq('id', user_id)
    .single()

  // Send email...
  return new Response(JSON.stringify({ ok: true, profile }))
})

배포는 supabase functions deploy send-welcome 한 줄. 자동으로 https://PROJECT.supabase.co/functions/v1/send-welcome 엔드포인트가 생긴다.

Supabase Edge는 이미 Supabase를 쓰는 팀에게 최적이다. DB + Auth + Storage + Realtime + Edge Functions가 한 콘솔에 있고, RLS와 자동 연동된다. 단점은 region이 적고 Cloudflare 만큼의 분산은 아니라는 것.

12. WinterCG / WinterTC — 크로스 플랫폼 표준

WinterCG는 2022년 W3C Community Group으로 시작해 2025년에 Ecma TC55 (WinterTC) 로 승격했다. 이제 ECMA 공식 표준 트랙이다. 목표는 단순하다.

서버사이드 JavaScript 런타임이 따라야 할 공통 API 표면(Minimum Common API)을 정의한다.

2026년 5월 기준, 다음 런타임이 WinterTC Minimum Common API 호환을 선언한다.

  • Cloudflare Workers
  • Deno Deploy / Deno
  • Vercel Edge Runtime
  • Netlify Edge Functions
  • Supabase Edge Functions
  • Bun
  • Fastly Compute (JavaScript SDK)

핵심 API:

  • fetch, Request, Response, Headers, FormData
  • URL, URLPattern, URLSearchParams
  • TextEncoder, TextDecoder, Blob, File
  • crypto.subtle, crypto.getRandomValues
  • ReadableStream, WritableStream, TransformStream
  • AbortController, AbortSignal
  • console, setTimeout, setInterval, queueMicrotask
  • structuredClone, EventTarget, Event, CustomEvent

실용적 함의: 잘 만든 엣지 함수는 WinterTC API만 쓰면 5개 플랫폼에서 코드 한 줄 안 바꾸고 돈다. 프레임워크(Hono, itty-router, Hattip)들이 이 표준 위에서 멀티 플랫폼을 지원한다.

// Hono — runs on Cloudflare Workers, Deno Deploy, Vercel Edge, Bun, Node.js
import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => c.text('Hello from any edge runtime!'))
app.get('/json', (c) => c.json({ runtime: 'wintertc-compatible' }))
app.post('/echo', async (c) => c.json(await c.req.json()))

export default app
// Cloudflare: export default app
// Deno: Deno.serve(app.fetch)
// Bun: Bun.serve({ port: 3000, fetch: app.fetch })
// Node: serve({ fetch: app.fetch, port: 3000 })

13. 누가 무엇을 골라야 하나 — 글로벌 / 한국 / 일본 트래픽

글로벌 트래픽 (북미 + 유럽 + 아시아 균등)

  • 1순위: Cloudflare Workers + R2 + D1 + Workers AI — 300+ PoP, 가장 빠른 글로벌 응답, egress 무료
  • 2순위: Vercel Fluid Compute (Edge + Fluid 하이브리드) — Next.js 우선, AI/RAG 워크로드 최적
  • AI 헤비: Workers AI + Vectorize + AI Gateway 조합이 가장 통합도 높음

한국 트래픽 위주

한국은 모든 메이저 클라우드의 KR region이 있어 선택지가 많다.

  • 풀스택 엣지: Cloudflare (서울 PoP 존재) 또는 Vercel (icn1)
  • DB가 한국에 있어야 함: AWS Seoul (Lambda + RDS) 또는 Supabase Tokyo + Cloudflare 캐시
  • 레거시 호환 / Linux 필요: AWS Lambda + SnapStart 또는 Fly.io Singapore (한국에서 40-60ms)
  • 헷갈리면: Vercel + Supabase Tokyo가 가장 손쉬운 풀스택

일본 트래픽 위주

  • Cloudflare: 도쿄 PoP가 가장 큰 노드 중 하나, 일본 트래픽 매우 빠름
  • Vercel: nrt1 (Tokyo) region이 Edge에서 즉시 응답
  • AWS: ap-northeast-1 (Tokyo) Lambda SnapStart가 50ms 이하 콜드스타트
  • Deno Deploy: 도쿄 region 존재, 일본어 i18n 사이트에 적합

워크로드별 빠른 선택 매트릭스

워크로드추천
글로벌 정적 사이트 + 일부 APICloudflare Workers + Pages
Next.js 풀스택 + AIVercel Fluid Compute
Postgres 헤비 + 엣지Cloudflare Workers + Hyperdrive
LLM API 캐싱 / 비용 절감Cloudflare AI Gateway
Deno 우선, KV로 끝낼 수 있는 백엔드Deno Deploy
WASM 멀티언어 (Rust 등)Fastly Compute
Linux 필요, npm 풀호환Bun + Fly.io 또는 Lambda SnapStart
Supabase 이미 사용 중Supabase Edge Functions
비디오 트랜스코딩 / headless 브라우저Cloudflare Containers
단일 region OK, 가장 쉬운 배포Render 또는 Railway

14. 참고 / References

Discuss on Twitter • View on GitHub