필사 모드: 엣지 컴퓨트 플랫폼 2026 — Cloudflare Workers / Vercel Fluid / Deno Deploy / Fastly Compute / Bun 심층 비교
한국어1. 2026년 엣지 컴퓨트 지도 — V8 isolate / WASM / Firecracker 3 모델
2026년 5월 현재, "엣지 컴퓨트"라는 단어는 더 이상 단일 카테고리가 아니다. 같은 "서버리스 함수"라도 내부 실행 모델이 완전히 다른 3가지로 갈라졌다.
| 실행 모델 | 콜드스타트 | 격리 단위 | 대표 플랫폼 |
| --- | --- | --- | --- |
| V8 isolate | 0 ms 수준 | V8 컨텍스트 | Cloudflare Workers, Deno Deploy, Vercel Edge, Netlify Edge, Supabase Edge |
| WebAssembly | 35 microseconds | WASM 모듈 | Fastly Compute (구 Compute@Edge), Cloudflare Workers (WASM 백엔드) |
| MicroVM (Firecracker) | 100 ms 이하 (SnapStart 시 50 ms 이하) | VM | AWS 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](https://wintertc.org/) 사양을 따른다. `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월 상태 |
| --- | --- | --- |
| Workers | V8 isolate 실행 환경 | GA, 300+ PoP |
| R2 | S3 호환 객체 스토리지 | GA, egress 무료 |
| D1 | SQLite 기반 글로벌 DB | GA (2024.4) |
| Durable Objects | 상태 있는 객체 (SQLite 백엔드) | GA, SQLite 백엔드 2025년 GA |
| Hyperdrive | Postgres / MySQL 커넥션 풀러 | GA |
| Queues | 메시지 큐 | GA |
| Workers AI | GPU 추론 | GA |
가장 큰 변화는 **Durable Objects의 SQLite 백엔드**다. 기존 Durable Objects는 K/V 형태로 상태를 저장했지만, 2025년부터 각 DO 인스턴스에 임베디드 SQLite가 붙는다. 즉 **각 Durable Object = mini 데이터베이스 + 컴퓨트** 조합이 되었다.
// Durable Object with SQLite backend (2025+)
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"
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
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
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
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 사이트에 적합
워크로드별 빠른 선택 매트릭스
| 워크로드 | 추천 |
| --- | --- |
| 글로벌 정적 사이트 + 일부 API | Cloudflare Workers + Pages |
| Next.js 풀스택 + AI | Vercel 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
- Cloudflare Workers — https://developers.cloudflare.com/workers/
- Cloudflare R2 — https://developers.cloudflare.com/r2/
- Cloudflare D1 — https://developers.cloudflare.com/d1/
- Cloudflare Durable Objects (SQLite backend) — https://developers.cloudflare.com/durable-objects/
- Cloudflare Hyperdrive — https://developers.cloudflare.com/hyperdrive/
- Cloudflare Queues — https://developers.cloudflare.com/queues/
- Cloudflare Workers AI — https://developers.cloudflare.com/workers-ai/
- Cloudflare Vectorize — https://developers.cloudflare.com/vectorize/
- Cloudflare AI Gateway — https://developers.cloudflare.com/ai-gateway/
- Cloudflare Containers — https://developers.cloudflare.com/containers/
- Vercel Fluid Compute (April 2025 announcement) — https://vercel.com/blog/introducing-fluid-compute
- Vercel Edge Functions — https://vercel.com/docs/functions/runtimes/edge
- Deno Deploy — https://docs.deno.com/deploy/
- Deno KV — https://docs.deno.com/deploy/kv/manual/
- Deno Queues — https://docs.deno.com/deploy/kv/manual/queue_overview/
- Fastly Compute — https://www.fastly.com/products/edge-compute
- Fastly Compute Wasmtime — https://docs.fastly.com/products/compute
- Bun — https://bun.sh/
- Fly.io Machines — https://fly.io/docs/machines/
- Render — https://render.com/docs
- Railway — https://docs.railway.app/
- Coolify — https://coolify.io/docs/
- Netlify Edge Functions — https://docs.netlify.com/edge-functions/overview/
- AWS Lambda SnapStart — https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html
- Supabase Edge Functions — https://supabase.com/docs/guides/functions
- WinterTC (Ecma TC55) — https://wintertc.org/
- WinterCG Minimum Common API — https://min-common-api.proposal.wintertc.org/
- Hono framework — https://hono.dev/
현재 단락 (1/352)
2026년 5월 현재, "엣지 컴퓨트"라는 단어는 더 이상 단일 카테고리가 아니다. 같은 "서버리스 함수"라도 내부 실행 모델이 완전히 다른 3가지로 갈라졌다.