Void: Vite 네이티브 배포 플랫폼

Void: Vite 네이티브 배포 플랫폼

Vite+가 로컬 개발 도구를 하나로 통합했다면, 이번에는 배포까지 먹으러 왔습니다. VoidZero가 내놓은 Void는 Vite 앱에 플러그인 하나를 추가하고 void deploy 한 방이면 데이터베이스, 인증, KV 스토리지, 큐까지 갖춘 풀스택 애플리케이션이 Cloudflare Workers 위에 올라가는 배포 플랫폼입니다.

“자바스크립트에 드디어 Rails 순간이 온 건가, 아니면 그냥 Cloudflare 종속에 리본을 달아놓은 건가?” 궁금해서 Void가 뭘 하는 건지 직접 파헤쳐봤습니다.

2026년 9월에 나온 0.20 버전을 기준으로 내용을 고쳤습니다. 0.20에서는 배포 모델이 크게 바뀌었는데요. 이제 void deploy는 기본적으로 *.void.app이 아니라 여러분의 Cloudflare 계정에 앱을 올리고, 팀이 함께 쓰는 Void 플랫폼을 회사 Cloudflare 계정에 직접 설치할 수도 있게 됐습니다.

Vite+와 Void의 관계

먼저 용어 정리부터 해야겠습니다. VoidZero(2026년 6월 Cloudflare에 인수)는 Vue를 만든 Evan You가 세운 회사로 Vite, Rolldown, Oxc, Vitest를 관리하고 있는데요. 이 회사에서 두 가지 제품을 내놓았습니다.

Vite+는 로컬 개발 도구를 통합한 툴체인입니다. vp라는 CLI 하나로 개발 서버, 빌드, 테스트, 린팅, 포맷팅을 전부 처리하죠. 이전 글에서 자세히 다뤘으니 여기서는 넘어가겠습니다.

Void는 배포 플랫폼이자 풀스택 프레임워크입니다. Vite 앱을 Cloudflare Workers 위에 풀스택으로 올려주는 게 핵심 역할이에요. 로컬 개발은 Vite+로, 배포는 Void로 — 이렇게 짝을 이루는 구조입니다.

Void가 제공하는 것

Void는 단순한 배포 도구가 아닙니다. 풀스택 앱을 만드는 데 필요한 백엔드 인프라를 통째로 제공해요.

  • 데이터베이스: 로컬에서는 SQLite, 프로덕션에서는 Cloudflare D1으로 매핑하고, 외부 PostgreSQL이나 MySQL도 선택 가능 (자세히는 Void 데이터베이스)
  • KV 스토리지: Cloudflare Workers KV 기반의 키-값 저장소
  • 오브젝트 스토리지: 파일 업로드, 이미지 저장 등
  • 인증: 내장 auth 시스템
  • 큐: 비동기 작업 처리
  • 크론 잡: 예약 작업
  • AI 추론: Cloudflare Workers AI 연동
  • 상태 객체: 타입이 붙은 Durable Objects (0.20에서 추가)
  • 이메일: sendEmail()로 트랜잭션 메일 발송 (0.20에서 추가)

이 모든 걸 SDK에서 import하기만 하면 됩니다. Void 프로젝트의 전체 구조를 한눈에 보면 이렇습니다.

vite.config.ts        → voidPlugin() — 어떤 Vite 앱이든 동작
import { db }         → D1 데이터베이스
import { kv }         → KV 네임스페이스
import { storage }    → R2 버킷
import { ai }         → Workers AI 또는 BYOK
import { auth }       → 인증 (Better Auth 기반)
import { sendEmail }  → 이메일 발송
db/schema.ts          → Drizzle 스키마 — DB 타입의 단일 진실 공급원
db/migrations/*.sql   → 배포 시 D1에 자동 적용
crons/*.ts            → 크론 잡
queues/*.ts           → 큐
durable-objects/*.ts  → 타입이 붙은 Durable Object
void deploy           → 내 Cloudflare 계정(또는 팀의 Void 플랫폼)에 배포 완료

vite.config.ts에 voidPlugin()만 추가하면 나머지는 Void가 알아서 처리해요. Drizzle ORM이 스키마 정의부터 마이그레이션, 타입 생성까지 담당하니까 데이터베이스 레이어의 타입 안전성도 자동으로 확보됩니다.

코드에서 인프라로

Void에서 가장 인상적인 부분은 자동 프로비저닝입니다. 소스 코드를 스캔해서 어떤 리소스를 사용하는지 감지하고 알아서 인프라를 구성해줘요.

void/db를 import하면 D1 데이터베이스가 프로비저닝되고, void/kv를 import하면 KV 네임스페이스가 생깁니다. 바인딩을 일일이 선언할 필요도, 대시보드에서 클릭할 것도 없습니다. Infrastructure-as-Code라기보다는 Infrastructure-from-Code라고 부르는 게 맞을 것 같아요.

Cloudflare Workers를 직접 써보신 분이라면 아시겠지만 Wrangler 설정 파일에 바인딩을 적고 대시보드에서 D1 데이터베이스를 만들고 KV 네임스페이스를 연결하는 과정이 꽤 번거롭거든요. Void는 이 과정을 전부 추상화합니다.

0.20에서 추가된 Durable State도 같은 방식입니다. durable-objects/ 디렉토리에 파일을 하나 만들면 그 파일 이름으로 바인딩과 Worker 클래스, 마이그레이션 태그가 정해져요.

durable-objects/counter.ts
import { defineDurableState } from "void/durable";

export const Counter = defineDurableState({
  initialState: { count: 0 },
  methods: {
    increment(context, amount: number) {
      context.state.count += amount;
      return context.state.count;
    },
  },
});

export default Counter;

라우트에서는 Counter.get("global").increment(1)처럼 부르면 되고, 인자와 반환값에 타입이 그대로 따라옵니다. wrangler.jsonc에 COUNTER 바인딩과 CounterDurableObject 클래스를 손으로 등록하던 일을 파일 하나가 대신하는 셈이죠.

직접 시작해보기

말로만 들으면 감이 안 오니 직접 돌려볼게요. 0.20부터는 Node.js 24.21.0 이상이 필요합니다. 빈 디렉토리에서 패키지를 설치하고 초기화 명령을 실행합니다.

bun add -D void
bunx void init

npm을 쓴다면 다음과 같이 설치합니다. Void는 npm, pnpm, yarn, bun을 모두 지원해요.

npm install -D void
npx void init

void init은 대화형으로 진행돼요. 툴체인(Vite+가 기본)과 프레임워크(React, Vue, Svelte, Solid), 스타터 종류(D1, PostgreSQL, MySQL, 정적 페이지)를 고르면 프로젝트 뼈대가 잡힙니다. 이미 쓰던 Vite 앱이라면 voidPlugin()만 추가하고 같은 명령을 돌리면 되고요.

실제로 0.20.3 버전으로 빈 디렉토리에서 bunx void init을 돌리면 이렇게 흘러갑니다. 모두 기본값을 골랐어요.

┌  void init
│
◇  Initialize a git repository?
│  Yes
│
●  Empty project detected. Scaffolding a Pages starter...
│
◇  Choose a Pages scaffold toolchain:
│  Vite+
│
◇  Choose a Pages framework to scaffold:
│  React
│
◇  Choose a Pages starter:
│  D1 (SQLite)
│
◆  Updated package.json with starter scripts and dependencies
◆  Created vite.config.ts
◆  Created pages/index.tsx
◆  Created pages/index.server.ts
◆  Created routes/api/hello.ts
◆  Created db/schema.ts
◆  Created db/seed.ts
◆  Created .gitignore
●  Using default D1 (SQLite) configuration
◆  Created tsconfig.json
◆  Pinned worker compatibility_date in void.json
◆  Created AGENTS.md with Void instructions
●  No coding agent detected; read the bundled docs linked in AGENTS.md
│
◇  Where should this project deploy?
│  Cloudflare
│
◇  Create .github/workflows/void-deploy.yml to deploy on pushes to main?
│  Yes
│
◆  Created .github/workflows/void-deploy.yml
◆  Installed dependencies with bun
◆  Generated initial Drizzle migration
│
●  Git (optional): git add -A && git commit -m "chore: initial commit"
│
└  Run `vp dev` to start developing

스캐폴딩 도구(Vite+)와 프레임워크(React), 스타터(D1)를 고르면 페이지, API 라우트, DB 스키마, 시드 파일까지 한 번에 깔립니다. 예전 버전과 비교하면 눈에 띄는 변화가 세 가지 있어요.

먼저 맨 앞에 Git 저장소를 초기화할지 묻습니다. 다만 커밋까지 대신 해주지는 않고, 마지막에 커밋 명령을 제안만 해요. 다음으로 코딩 에이전트를 고르라고 묻지 않고, 무조건 AGENTS.md를 만듭니다. 이 부분은 뒤에서 자세히 다룰게요. 마지막으로 가장 큰 변화는 “Where should this project deploy?” 질문입니다. 기본값이 Cloudflare, 즉 여러분 자신의 Cloudflare 계정이에요. Cloudflare를 고르면 브라우저로 로그인한 뒤 배포할 계정을 골라 wrangler.jsonc에 저장합니다. 이 질문은 건너뛰었다가 나중에 void connect로 정해도 됩니다.

초기화가 끝나면 이런 구조가 생깁니다.

my-app/
├─ pages/              # 파일 기반 페이지 (index.tsx + index.server.ts)
├─ routes/api/         # API 엔드포인트 (hello.ts)
├─ db/                 # Drizzle 스키마, 시드, 마이그레이션
├─ .void/project.json  # 배포 대상 ({"platform": "cloudflare"})
├─ .github/workflows/  # void-deploy.yml (선택 시)
├─ AGENTS.md           # 에이전트용 Void 사용법
├─ vite.config.ts      # voidPlugin()을 끼운 Vite 설정
├─ void.json           # Void 앱 설정 (호환성 날짜, 인증, 라우팅)
└─ package.json

pages는 UI 컴포넌트(.tsx)와 서버 로직(.server.ts)을 짝지어 두는 곳이고, routes/api는 API 엔드포인트인데, 이 둘이 어떻게 URL과 데이터로 이어지는지는 Void 라우팅에서 따로 깊이 다룹니다. void.json에는 Worker 호환성 날짜나 인증 프로바이더, 페이지별 재검증 주기 같은 앱 설정을 선언하고, 어디로 배포할지는 .void/project.json에 따로 기록돼요. 크론이나 큐를 쓰는 스타터를 골랐다면 crons/, queues/ 디렉토리도 함께 생깁니다.

이제 로컬 개발 서버를 띄워봅니다.

bun run dev
$ vp dev

[void] Applied 1 migration(s): 20260926221439_conscious_paper_doll.sql

  VITE+ v0.1.24

  ➜  Local:  http://localhost:5173/
  ➜  Debug:  http://localhost:5173/__debug
  ➜  press b + enter to list configured Cloudflare bindings
  ➜  press e + enter to open local explorer
  ➜  press t + enter to start tunnel
  ➜  press h + enter to show help

bun run dev는 내부적으로 vp dev를 띄우고, 마이그레이션도 자동으로 적용해줍니다. 그러면 http://localhost:5173에서 앱이 뜨고 API 라우트도 바로 동작해요.

curl localhost:5173/api/hello
결과
{ "message": "Hello from Void", "framework": "React", "database": "D1" }

개발 서버에서 t를 누르면 Cloudflare 터널로 로컬 서버를 잠깐 외부에 공개할 수도 있고요. 로컬 개발 환경에서는 Miniflare가 Workers 런타임을 시뮬레이션합니다. 프로덕션과 같은 런타임에서 개발하니까 “내 컴퓨터에서는 되는데” 하는 문제가 줄어들죠. 여기까지는 Cloudflare 계정 없이도 됩니다.

배포는 한 줄

배포 명령은 여전히 한 줄입니다.

bunx void deploy

void init에서 Cloudflare를 골랐다면 이 명령이 여러분의 Cloudflare 계정으로 바로 배포합니다. 로그인이 안 돼 있으면 브라우저가 열리고, 인증 정보는 운영체제의 키체인에 저장돼요. 배포는 대략 다음 순서로 진행됩니다.

  1. 앱 종류와 계정, 인증 정보를 확인합니다.
  2. 코드가 쓰는 D1, KV, R2 같은 리소스를 계정에 만들거나, 이미 있으면 재사용합니다.
  3. 앱을 빌드하고 시크릿과 마이그레이션 이력을 검증한 뒤, 밀린 마이그레이션을 적용합니다.
  4. 새 Worker 버전을 올리고 준비됐는지 확인한 다음에야 트래픽을 넘깁니다.

만들어진 리소스 ID는 wrangler.jsonc에 기록되니 이 파일을 커밋해두면 다른 머신이나 CI에서도 같은 리소스를 씁니다. 새 버전을 먼저 확인하고 트래픽을 옮기는 구조라, 헬스 체크에 실패한 버전이 사용자에게 노출될 일이 없어요. 롤백은 void project rollback으로 하는데, 데이터베이스 마이그레이션까지 되돌리지는 않는다는 점은 알아두세요.

그럼 예전처럼 https://<slug>.void.app 주소를 받던 관리형 호스팅은 어떻게 됐을까요? 0.20의 CLI에서 “Void” 선택지는 팀이 운영하는 Void 플랫폼에 연결하는 용도로 바뀌었습니다. 관리자에게 받은 API 주소로 연결하는 방식이에요.

bunx void connect https://platform.example.com
bunx void project link

그리고 이 플랫폼 자체를 회사 Cloudflare 계정에 직접 설치할 수 있게 됐습니다. void platform install 한 번이면 GitHub, Google, OIDC, Cloudflare Access 로그인과 D1, KV, R2, 큐, 크론, 로그, 롤백을 갖춘 사내 배포 플랫폼이 생겨요. 설치하려면 Workers for Platforms가 필요하고, 사용자 대시보드나 GitHub 빌드, 커스텀 도메인은 기본 설치에 포함되지 않습니다. 개인 프로젝트라면 굳이 플랫폼을 설치할 필요 없이 본인 계정으로 직접 배포하면 됩니다.

main에 푸시하면 자동 배포

매번 손으로 void deploy를 치는 대신, main에 푸시하면 알아서 배포되게 만들 수도 있어요. void init 도중에 물어보는 질문에 Yes라고 답하거나, 나중에 이 단계만 따로 실행하면 GitHub Actions 워크플로우가 생깁니다.

bunx void init --github

Cloudflare를 배포 대상으로 골랐을 때 실제로 만들어진 워크플로우는 이렇습니다. bun 프로젝트라 setup-bun을 쓰는 게 보이네요.

.github/workflows/void-deploy.yml
name: Deploy to Cloudflare
on:
  push:
    branches: [main]

concurrency:
  group: void-cloudflare-deploy-${{ github.repository }}-${{ github.ref }}
  cancel-in-progress: true

permissions:
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: oven-sh/setup-bun@v2
      - run: bun install --frozen-lockfile
      - name: Deploy
        env:
          # Add this scoped token at Settings → Secrets and variables → Actions.
          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
          # Required only for PostgreSQL/MySQL provisioning and migrations.
          DATABASE_URL: ${{ secrets.DATABASE_URL }}
          # Required in fresh checkouts when a Worker Version has no preview URL.
          CLOUDFLARE_WORKERS_SUBDOMAIN: ${{ vars.CLOUDFLARE_WORKERS_SUBDOMAIN }}
          # Required only when Cloudflare Access protects Worker readiness.
          CF_ACCESS_CLIENT_ID: ${{ secrets.CF_ACCESS_CLIENT_ID }}
          CF_ACCESS_CLIENT_SECRET: ${{ secrets.CF_ACCESS_CLIENT_SECRET }}
        run: bunx void deploy --platform cloudflare

본인 계정으로 배포하는 만큼 저장소 시크릿에 CLOUDFLARE_API_TOKEN을 등록해야 합니다. 토큰은 앱이 쓰는 계정과 리소스에만 권한을 주도록 범위를 좁혀 발급하세요. PostgreSQL이나 MySQL을 쓴다면 DATABASE_URL도 필요하고요. 최신 푸시가 진행 중인 배포를 취소하는 concurrency 그룹이 들어 있어서, 오래된 커밋이 새 커밋을 덮어쓰는 일도 없습니다.

0.10에서 소개했던 시크릿 없는 배포는 이제 Void 플랫폼에서만 쓸 수 있습니다. 플랫폼이 지원한다면 GitHub OIDC로 받은 단기 토큰으로 배포하거나(void github connect --executor github_actions), Void GitHub App이 푸시를 받아 플랫폼에서 직접 빌드하게 할 수도 있어요(--executor container). 다만 직접 설치한 기본 플랫폼은 아직 둘 다 지원하지 않아서, 이 경우엔 프로젝트 범위로 발급한 토큰(void project token create)을 CI에 넣어 배포합니다.

프레임워크 지원

Void는 특정 프레임워크에 종속되지 않습니다. Vite 기반이라면 React, Vue, Svelte, Solid 뭐든 됩니다. Evan You의 회사답게 Vue는 당연히 지원하고 SvelteKit, Nuxt, React Router, TanStack Start, Analog, Astro 같은 메타 프레임워크의 Cloudflare 빌드 결과물도 배포할 수 있어요.

렌더링 방식도 폭넓습니다. SSR, SSG, ISR은 기본이고 아일랜드 아키텍처와 부분 하이드레이션, 마크다운 기반 콘텐츠까지 지원하죠. 기존에 쓰던 Vite 앱에 플러그인만 추가하면 되니까 마이그레이션 비용이 낮습니다.

코딩 에이전트와 함께

앞서 봤듯이 void init은 처음부터 코딩 에이전트용 설정을 깔아줍니다. 이미 만든 프로젝트에 나중에 더하거나 설정을 새로 고치고 싶을 땐, 이 단계만 따로 실행할 수도 있어요.

bunx void init --agents

0.20에서 이 명령은 훨씬 단순해졌습니다. 에이전트를 고르라고 묻지 않고 두 가지만 해요. 우선 AGENTS.md를 만들거나 갱신해서 Void 소개, 배포 대상, 개발 흐름, 그리고 설치된 패키지 안의 문서 경로(node_modules/void/skills/void/docs/)를 짧게 적어둡니다. 기존 내용은 건드리지 않고 버전이 붙은 블록만 끼워 넣어요. 그리고 Claude Code 같은 에이전트의 설정 디렉토리가 감지되면 Void의 스킬을 링크합니다. .claude/ 디렉토리가 있는 프로젝트에서 실행해보면 이렇게 나와요.

┌  void init
│
●  AGENTS.md already has Void instructions (v0.20.3)
│
●  Claude Code → .claude/skills
│
◆    migrate-cloudflare-to-void — linked
│
◆    void — linked
│
└  Run `vp dev` to start developing

스킬은 void와 migrate-vite-cloudflare-to-void 두 개입니다. 앞의 것은 요청에 맞는 Void 문서로 에이전트를 안내하는 메인 스킬이고, 뒤의 것은 @cloudflare/vite-plugin 앱을 Void로 옮기는 마이그레이션 스킬이에요. 둘 다 node_modules/void 안을 가리키는 심볼릭 링크라서, 앱이 쓰는 Void 버전과 문서 버전이 항상 일치합니다.

예전에 만들어주던 CLAUDE.md와 MCP 서버 설정은 빠졌습니다. 여러 에이전트가 공통으로 읽는 AGENTS.md 하나로 모으고, 자세한 내용은 패키지에 딸린 마크다운 문서를 직접 읽게 한 거죠. 실제 마이그레이션 기록에서 밟았던, MCP 설정이 엉뚱한 파일에 써지는 문제도 이렇게 자연스럽게 사라졌습니다.

왜 굳이 이런 단계를 거치냐면, 에이전트가 Void의 import 규약(void/db, void/kv 같은)이나 배포 흐름을 모른 채로 코드를 짜면 십중팔구 어긋나기 때문이에요. 이 한 줄이 에이전트에게 “이 프로젝트는 Void 방식으로 짜야 한다”는 맥락을 미리 깔아주는 셈입니다.

사실 이 기능은 요즘 흐름에서 점점 더 중요해지고 있어요. 코드를 짜는 주체가 사람에서 AI 에이전트로 옮겨가면서, 프레임워크의 경쟁력도 “에이전트가 이걸로 코드를 얼마나 잘 짜느냐”에 갈리기 시작했거든요. Cloudflare가 VoidZero를 인수하며 내건 슬로건이 “AI 네이티브 웹의 미래”였던 걸 떠올리면, void init --agents는 단순한 편의 기능이 아니라 그 비전을 가장 구체적으로 보여주는 지점인 셈입니다. 개발 서버도 에이전트 안에서 실행되는 걸 감지하면 단축키 안내 대신 로컬 바인딩과 요청 로그를 조회하는 API 목록을 출력해줄 정도예요.

자바스크립트의 Rails가 될 수 있을까

솔직히 Void를 처음 봤을 때 Ruby on Rails가 떠올랐습니다. 라우팅, 데이터베이스, 인증, 배포까지 프레임워크 하나로 해결하는 그 올인원 철학이요. 자바스크립트 생태계에서 이 정도로 통합된 경험을 제대로 제공한 적이 있었나 싶을 만큼 범위가 넓어요.

하지만 걸리는 점도 있습니다.

가장 큰 건 Cloudflare 종속입니다. void/db는 Cloudflare D1이고, void/kv는 Workers KV고, 기본 배포 타겟은 Cloudflare Workers예요. Vercel과 Next.js의 관계에서 봤던 벤더 락인(vendor lock-in) 논쟁이 여기서도 고스란히 반복될 수 있습니다.

다만 0.20에서 ‘Void라는 플랫폼’에 묶이는 락인은 거의 사라졌다고 봐도 됩니다. 처음 이 글을 쓸 때만 해도 기본 배포처가 *.void.app이었고, 본인 계정으로 옮기려면 wrangler.json을 손수 챙겨 wrangler deploy를 해야 했는데요. 이제는 본인 Cloudflare 계정이 기본값이고, 팀용 플랫폼조차 회사 계정에 직접 설치해서 운영합니다. 이미 Wrangler로 배포하던 Void 앱이라면 void deploy가 기존 Worker와 리소스, 시크릿을 그대로 넘겨받는 연결 흐름까지 제공해요.

Cloudflare 인프라 자체에서 벗어나는 길도 조금 열렸습니다. void.json의 target을 바꾸면 Node.js, Bun, Deno에서 돌아가는 독립 서버로 빌드할 수 있거든요. 물론 이 경우엔 D1, KV, R2, Workers AI 같은 Cloudflare 바인딩을 쓸 수 없으니, 라우팅과 페이지 렌더링 정도만 가져가는 탈출구로 보는 게 맞습니다.

성숙도도 여전히 신경 쓰입니다. 공식 문서가 스스로 “베타 지원”이라는 표를 두고 직접 Cloudflare 배포와 플랫폼 배포 사이에서 되는 기능과 안 되는 기능을 나눠 적어둘 정도예요. 새벽 2시에 프로덕션이 터졌을 때 Stack Overflow에서 답을 찾을 수 있는 환경은 아직 아니죠. 실제로 실서비스를 Void로 옮겨본 기록을 보면 문서에 없는 지뢰가 한 번의 마이그레이션에서 다섯 개나 튀어나오기도 했고요. 버전도 0.10에서 0.20으로 넘어가며 배포 모델이 통째로 바뀐 만큼, 당분간은 업그레이드할 때마다 변경 사항을 꼼꼼히 확인해야 합니다.

그래도 방향성 자체는 매력적입니다. 도구 파편화에 지친 자바스크립트 개발자들에게 “Vite+ 하나로 개발하고 Void 하나로 배포하라”는 메시지는 설득력이 있거든요. Cloudflare의 글로벌 엣지 네트워크 위에서 돌아간다는 성능상 이점도 무시하기 어렵고요.

Next.js/Vercel과의 차이

Void의 포지셔닝을 이해하려면 Next.js와 Vercel의 관계를 떠올리면 됩니다. “Void is to Cloudflare as Next.js is to Vercel”이라는 비유가 딱 맞아요.

다만 접근 방식에 차이가 있습니다. Next.js는 React 전용이지만 Void는 React, Vue, Svelte, Solid 어떤 프레임워크든 Vite 기반이면 다 받아줍니다. Next.js는 프레임워크가 먼저고 배포가 따라오는 구조인 반면 Void는 기존 Vite 앱에 배포 레이어를 얹는 방식이죠.

또 Next.js는 Vercel 외 플랫폼에서도 돌릴 수 있지만 최적화는 Vercel에서만 제대로 됩니다. Void는 처음부터 Cloudflare를 전제로 설계했고, Node.js나 Bun, Deno 타겟은 Cloudflare 바인딩을 빼고 돌리는 보조 선택지에 가깝습니다. 흥미로운 건 방향이 반대라는 점이에요. Vercel은 자사 호스팅으로 끌어들이는 쪽이라면, Void는 0.20에서 자체 호스팅을 뒤로 물리고 사용자의 Cloudflare 계정을 기본값으로 삼았습니다. 이걸 단점으로 볼 수도 있고 오히려 최적화에 집중할 수 있다는 장점으로 볼 수도 있습니다.

마치며

Void가 자바스크립트의 Rails가 될지는 아직 모릅니다. 하지만 VoidZero가 Vite+로 로컬 개발을, Void로 배포를, 그리고 그 사이를 Cloudflare 인프라로 채우는 그림은 꽤 야심찬 비전이에요.

그리고 2026년 6월, 그 그림은 한층 선명해졌습니다. Cloudflare가 VoidZero를 인수하면서 로컬 개발(Vite+)부터 배포(Void), 그 아래 인프라(Cloudflare Workers)까지 전부 한 회사 안으로 들어왔거든요. 도입부에서 던졌던 “Cloudflare 종속에 리본을 단 것 아니냐”는 질문이 더 묵직해진 셈인데요. 다만 Vite, Vitest, Rolldown, Oxc는 MIT 라이선스 오픈소스로 남고 벤더 중립을 유지한다고 못 박았고, Cloudflare가 Vite 생태계 펀드에 100만 달러를 별도로 약속한 만큼, 한쪽으로 완전히 기우는 그림은 아닙니다. 인수 석 달 뒤에 나온 0.20이 자체 호스팅 대신 사용자의 Cloudflare 계정을 기본값으로 삼은 것도 같은 맥락으로 읽혀요. Void는 이제 별도의 호스팅 서비스라기보다 Cloudflare 위에서 풀스택 앱을 가장 쉽게 만드는 방법에 가까워졌습니다.

아직 베타라 프로덕션 투입은 신중해야 하지만, 이제는 얼리 액세스를 기다릴 필요 없이 void init 한 번과 본인 Cloudflare 계정만 있으면 바로 써볼 수 있습니다. Cloudflare를 이미 쓰고 계시거나 새 프로젝트를 시작하려는 분이라면 주말 프로젝트 하나쯤 올려보셔도 좋겠습니다.

Void의 기반이 되는 로컬 개발 툴체인이 궁금하다면 Vite+로 웹 개발 도구 통합하기를, 메타 프레임워크라는 개념이 익숙하지 않다면 메타 프레임워크 소개부터 읽어보시는 것도 좋습니다. 더 자세한 내용은 Void 공식 사이트를 참고하세요.

This work is licensed under CC BY 4.0CCBY

개발자를 위한 뉴스레터

달레가 정리한 AI 개발 트렌드와 직접 만든 콘텐츠를 전해드립니다.

관련 포스트

Void로 프로덕션 앱 이전하기: 하루 만의 컷오버 실전 기록

지난번 Void는 Vite 네이티브 배포 플랫폼이라는 글에서 "이게 자바스크립트의 Rails가 될 수 있을까"를 다뤘는데요. 그때는 직접 써보지 않고 개념만 파헤친 소개글이었습니다. 이번엔 다릅니다. TanStack Start + Cloudflare Workers + D1으로 운영 중이던 실서비스를 하루 만에 Void로 컷오버하면서 직접 부딪힌 기록이에요. 결론부터 말씀드리면 코드 변경은 거의 없었고, 빌드는 3배 빨라졌고, 그리고 베타 제품답게 문서에 없는 지뢰를 다섯 개나 밟았습니다. 💥 이 글은 그 지뢰들을 어떻게 역공학으로

Void 인증: Better Auth로 로그인부터 라우트 보호까지

Void 데이터베이스에서 테이블을 만들고 Void 라우팅으로 API까지 열고 나면, 다음으로 부딪히는 벽은 늘 똑같습니다. "그래서 이 요청을 보낸 사람이 누구인지 어떻게 알지?"라는 질문이죠. 로그인 없는 앱은 결국 누구나 같은 화면을 보는 앱이니까요. 다행히 Void는 인증을 거의 공짜로 얹어줍니다. 따로 라이브러리를 고르고 세션 저장소를 붙이고 콜백을 짜는 그 지난한 과정 없이, 설정 한 줄과 헬퍼 몇 개로 로그인이 돌아가거든요. 이번 글에서는 인증을 켜고, 회원가입과 로그인을 붙이고, "로그인한 사람만 들어올 수 있는" 영역

Void 환경변수: env.ts로 타입 안전하게, 시크릿까지

Void 인증을 붙이고 나면 곧바로 BETTER_AUTH_SECRET이라는 비밀 키를 마주하게 됩니다. 세션 토큰을 서명하는 값인데, 코드에 적을 수도 없고 깃에 올릴 수도 없죠. 비단 인증만의 문제도 아닙니다. Stripe 키, 웹훅 URL, 외부 API 토큰까지, 앱을 키우다 보면 "코드 밖에서 주입해야 하는 값"이 계속 늘어나거든요. 그런데 우리가 환경변수로 늘 겪던 불편이 있습니다. process.env.PORT는 항상 문자열이라 매번 숫자로 바꿔야 하고, 키 이름에 오타가 나도 런타임에야 터지고, 어떤 값이 필수인지는 RE

Void AI: 라우트 핸들러에서 LLM을 타입 안전하게 호출하기

앱에 AI 기능을 하나 붙이려고 마음먹으면, 정작 모델을 부르는 코드보다 그 주변을 차리는 일이 더 번거롭습니다. 어느 제공사를 쓸지 정하고, SDK를 설치하고, API 키를 환경변수로 빼고, 스트리밍 응답을 직접 파싱하고, 사용량이 얼마나 나왔는지 따로 추적하고… 정작 "프롬프트를 보내고 답을 받는" 본질은 한 줄인데 말이죠. Void는 이 주변 작업을 void/ai라는 클라이언트로 미리 차려둡니다. Cloudflare의 AI 게이트웨이 위에서 동작하는 타입 안전한 클라이언트인데, Void 라우팅에서 본 라우트 핸들러 안에서 모델

Void 라우팅: pages로 화면을, routes로 API를

Void: Vite 네이티브 배포 플랫폼에서 프로젝트 구조를 훑어볼 때 pages/와 routes/ 디렉토리를 잠깐 스쳐 지나갔는데요. 사실 이 두 디렉토리가 Void로 앱을 만드는 거의 모든 것을 담당합니다. 화면을 그리는 일도, API를 여는 일도 결국 "어떤 파일을 어디에 두느냐"로 결정되거든요. 이번 글에서는 Void의 라우팅을 제대로 파헤쳐볼게요. 파일 하나가 어떻게 URL이 되는지, 서버에서 가져온 데이터가 어떻게 화면 컴포넌트로 흘러가는지, API 핸들러는 어떻게 쓰고 입력 검증과 미들웨어는 어떻게 거는지까지 차근차근

Void 데이터베이스: 로컬 SQLite에서 Cloudflare D1까지

Void: Vite 네이티브 배포 플랫폼에서 데이터베이스를 소개할 때 "로컬에서는 SQLite, 프로덕션에서는 Cloudflare D1로 매핑된다"는 한 줄로 짚고 넘어갔는데요. 이번엔 그 데이터베이스 레이어를 제대로 들여다볼게요. 스키마는 어떻게 정의하고, 마이그레이션은 어떻게 굴리고, 쿼리는 어떻게 날리는지까지 차근차근 살펴보겠습니다. Void 라우팅에서 API 핸들러에 insertUserSchema로 입력을 검증하는 예제를 봤는데, 그 검증기가 어디서 오는지도 이 글에서 채워집니다. 로컬은 SQLite, 프로덕션은 D1 Voi