v0 API 사용법: 앱 생성부터 Vercel 배포까지

v0 API로 실제 무엇을 할 수 있나

v0 API는 자연어 요청을 단순한 코드 제안이 아니라 실행 가능한 풀스택 앱으로 바꿉니다. 코드 생성부터 Vercel Sandbox에서의 실행, 안전한 실시간 미리보기, Vercel 배포까지 한 흐름으로 처리합니다.

각 v0 채팅을 앱 하나를 위한 전용 작업실이라고 생각하면 이해하기 쉽습니다. 채팅 ID가 그 작업실의 열쇠입니다. v0는 안에 있는 파일을 읽고 수정하고 실행하며, 이후 보내는 모든 메시지는 현재 상태에서 작업을 이어갑니다. 첫 메시지로 이슈 분류 대시보드를 요청한 다음 담당자 열을 추가해 달라고 하면, 두 번째 요청은 작업대에 올라와 있는 기존 앱을 수정합니다.

핵심은 이렇게 상태를 유지하며 반복하는 과정입니다. 일반적인 코드 모델은 텍스트를 건네고 실행은 사용자에게 맡깁니다. v0는 개발 서버를 시작하고 실제 실행 중인 코드를 확인하며, 작업 도중 오류를 찾아 수정할 수도 있습니다.

새 v2 API는 내부 구현을 몰라도 이해할 수 있는 4가지 요소를 중심으로 구성됩니다.

• **채팅(Chats)**은 앱의 현재 파일, 메타데이터, 공개 범위, Vercel 프로젝트 연결 정보를 보관합니다.
• **메시지(Messages)**는 지시와 작업 기록입니다. 순서가 있는 parts에는 텍스트, 추론, 파일 읽기, 파일 수정, 검색, 셸 명령, 툴 호출, 에이전트 작업이 표시될 수 있습니다.
• **미리보기(Previews)**는 유효 시간이 짧은 토큰으로 보호되는 실행 빌드입니다.
• **배포(Deployments)**는 현재 채팅 상태를 Vercel로 내보냅니다.

이 때문에 예전 예제가 오히려 혼란을 줄 수 있습니다. 현재 v2 퀵스타트는 v0 패키지에서 가져옵니다. 이전 v1 예제는 v0-sdk에서 가져오며, v1 채팅 ID는 v2에서 작동하지 않습니다.

v0 API 사용법: 가장 안전한 시작 순서

가장 간단하면서 안전한 구성은 자체 인터페이스와 v0 사이에 작은 서버 라우트를 두는 것입니다. 브라우저는 사용자의 프롬프트를 자체 서버로 보냅니다. 서버는 API 키를 보관한 채 v0를 호출하고, 반환된 채팅 ID를 저장한 뒤 인터페이스에 필요한 결과만 전달합니다.

1. 목적에 맞는 진입점 선택

다음 3가지 방식 중 하나를 선택합니다.

1. npx create-v0-sdk-app으로 완성된 앱 생성 인터페이스를 시작합니다.
2. npm install v0로 기존 제품에 서버 SDK를 추가합니다.
3. 기존 에이전트에 원격 v0 MCP 서버 접근 권한을 부여합니다. 이 방식은 MCP 설정에 API 키를 넣지 않고 OAuth를 사용합니다.

스타터는 전체 패턴을 가장 빨리 확인하는 방법입니다. React 채팅 인터페이스, 서버 프록시 라우트, 생성된 파일 보기, 격리된 미리보기 앱, v0 에이전트 스킬이 포함되어 있습니다.

2. 키를 만들고 서버에만 보관

v0 설정에서 API 키를 만든 뒤 서버 환경의 V0_API_KEY에 저장합니다. 브라우저 코드에 노출해서는 안 되며, 이름 앞에 NEXT_PUBLIC_을 붙여서도 안 됩니다.

로컬 래퍼는 npm run dev로 실행할 수 있지만, 그 안의 서버 라우트는 여전히 호스팅된 v0 API를 호출합니다. 이는 로컬 통합 환경이지, v0 앱 빌딩 시스템을 로컬에 복제한 것이 아닙니다.

3. 앱 하나당 채팅 하나 생성

첫 번째 호출에서 대화와 앱 작업공간이 함께 만들어집니다.

import { v0 } from 'v0'

const created = await v0.chats.create({
  message: 'Build an issue triage app for a support team.',
})

if (created.error) throw new Error(created.error.message)
const chatId = created.data.chat.id

const changed = await v0.messages.send({
  chatId,
  message: 'Add a priority filter and an assignee column.',
})

if (changed.error) throw new Error(changed.error.message)

chatId는 자체 고객, 작업공간 또는 작업 레코드와 함께 저장합니다. 메타데이터로도 같은 식별자별 채팅을 묶을 수 있지만, 메타데이터는 정리 수단일 뿐 접근 제어 수단은 아닙니다.

반드시 빈 프롬프트에서 시작할 필요는 없습니다. GitHub 저장소, ZIP 아카이브 또는 파일 묶음으로 채팅을 시작할 수도 있습니다.

4. 작업 결과를 받을 방식 결정

호출자가 완료된 결과를 기다릴 수 있다면 동기 호출을 사용합니다. 작업을 큐에 넣고 나중에 상태를 확인해야 하는 스크립트, 웹훅, CI 작업에는 비동기 호출이 맞습니다. 사용자가 지켜보는 동안 인터페이스에 에이전트의 파일 읽기, 코드 수정, 명령 실행, 진행 상황 보고를 보여주려면 스트리밍을 선택합니다.

채팅과 메시지 응답에는 사용량도 포함되므로, 작업이 끝날 때 토큰 수와 크레딧 비용을 기록할 수 있습니다.

5. 미리보기는 직접 노출하지 말고 프록시로 전달

API는 미리보기 URL과 유효 시간이 짧은 토큰을 반환합니다. 브라우저 iframe은 이 토큰을 자체적으로 안전하게 첨부할 수 없으므로, 공식 설계에서는 iframe 요청을 직접 관리하는 백엔드 프록시를 거치도록 합니다.

이 프록시는 메인 애플리케이션과 등록 가능 도메인이 다른 미리보기 전용 사이트에 둡니다. 생성된 미리보기에서는 신뢰할 수 없는 코드가 실행될 수 있습니다. 프록시는 현재 사용자를 인증하고, 그 사용자가 요청한 채팅에 접근할 권한이 있는지도 확인해야 합니다. v0 미리보기 헬퍼가 이 권한 검사를 대신해 주지는 않습니다.

6. 자체 검증을 마친 뒤에만 배포

앱이 준비되면 v0.chats.deploy({ chatId })로 현재 채팅 상태를 Vercel에 배포합니다. 환경 변수는 연결된 Vercel 프로젝트에 속하며 Vercel API를 통해 관리되므로, 데이터베이스 자격 증명과 서드파티 키는 별도의 명시적인 설정 단계가 필요합니다.

v0 API 비용 구조

v0는 생성된 앱마다 고정 요금을 받는 대신 크레딧을 차감합니다. 입력 토큰에는 프롬프트, 업로드한 콘텐츠, 채팅 기록, 소스 파일을 비롯해 v0가 읽는 각종 컨텍스트가 포함됩니다. 출력 토큰은 에이전트가 생성한 내용입니다. 따라서 오래 이어지는 채팅은 기록과 코드베이스가 커질수록 비용이 늘어날 수 있습니다.

Free 플랜은 월 $0이며 매월 $5 크레딧과 하루 7개 메시지 한도가 제공됩니다. Plus는 사용자당 월 $30, Business는 사용자당 월 $100이며 두 플랜 모두 사용자당 매월 $30 크레딧을 포함합니다. 사용 가능한 크레딧을 모두 소진하면 생성이 중단됩니다.

고객용 제품이라면 모든 채팅 및 메시지 호출에서 반환되는 사용량을 기록해야 합니다. 테넌트마다 예산이나 작업 한도를 설정하거나 둘 다 적용합니다. 그렇지 않으면 유난히 큰 저장소 하나나 끝없이 이어지는 수정 작업이 공용 잔액을 소진할 수 있습니다.

효과를 가장 크게 보는 주체별 7가지 활용 사례

v0는 제품이 이미 사용자와 데이터, 만들어야 할 앱의 유형을 알고 있는 기존 워크플로 안에 들어갈 때 가장 큰 효과를 냅니다.

v0를 기반 엔진으로 쓸지, 필요한 제품 전체로 쓸지 판단 중이라면 2026년 최고의 AI 앱 빌더와 비교해 보십시오. API는 고객 경험, 규칙, 결제, 검토 흐름을 직접 소유하려 할 때 가치가 있으므로 이 차이가 중요합니다.

실제로 만들어 볼 만한 3가지 제품

수요는 분명하지만 범용 앱 빌더 시장은 이미 경쟁이 치열합니다. 기회는 또 하나의 빈 프롬프트 입력창이 아니라, 가치 있는 특정 업무 하나를 누구보다 잘 이해하는 빌더에 있습니다.

1. 최우선 선택: 기존 SaaS에 내장하는 버티컬 앱 빌더

한 업종에 특화된 제한형 생성기를 만들어 해당 고객들이 이미 사용하는 소프트웨어의 애드온으로 판매합니다. 부동산 관리 플랫폼은 소유주 포털을, 물류 플랫폼은 배송 예외 대시보드를, 프랜차이즈 플랫폼은 지점 출시 추적기를 생성할 수 있습니다.

이 카테고리를 뒷받침할 만큼 수요 기반은 넓습니다. ai app builder는 미국 Google에서 월 약 12,100회 검색되며, 데이터셋에 따르면 연간 성장률은 50%입니다. 사용자가 AI 어시스턴트에 build an app with ai를 요청한 횟수는 월 약 392회로, 2025년 8월의 231회에서 약 70% 증가했습니다. 기존 앱 빌더의 월 요금은 이미 $16부터 $160까지 형성되어 있어, 구매자가 이 작업에 반복적인 소프트웨어 비용을 지불할 의사가 있음을 보여 줍니다.

판매 가능한 최소 버전에는 승인된 앱 유형 2~3개, 구조화된 접수 양식, 고객 앱당 v0 채팅 하나, 스트리밍 검토 화면, 안전한 미리보기 프록시, 사람이 제어하는 배포 버튼이 필요합니다. 방어력은 호스트 제품의 데이터 모델, 권한, 템플릿, 유통망에서 나옵니다.

냉혹하지만 유용한 판단 기준도 있습니다. 범용 래퍼에는 방어력이 거의 없습니다. 고객 업무에 대해 v0만으로는 알 수 없지만 이 제품은 무엇을 알고 있는지 명확히 답할 수 없다면, 만들지 않는 편이 낫습니다.

2. 에이전시용 화이트 라벨 웹사이트·캠페인 빌더

에이전시에 브랜드가 적용된 고객 접수 과정, 정해진 페이지 유형, 자체 디자인 시스템 스킬, 수정 대기열, 배포 인계 절차를 제공합니다. 고객에게는 에이전시가 설계한 서비스 경험이 보이고, 뒤에서는 v0가 앱 작업공간과 실시간 미리보기를 처리합니다.

ai website builder는 미국 Google에서 월 약 40,500회 검색되며, 키워드 데이터셋에서 연간 성장률은 49%입니다. 이번 조사에서 확인된 가장 큰 수요층이지만, 동시에 유능한 기존 사업자가 많다는 뜻이기도 합니다. 유효한 진입점은 ‘어떤 웹사이트든 제작’이 아닙니다. ‘이 스택, 이 컴포넌트, 이 승인 절차에 맞춰 이 에이전시가 잘하는 종류의 사이트를 제작’하는 것입니다.

MVP에는 브랜드 구성 하나, 페이지 패턴 3개, 에셋 업로드, 미리보기 댓글, 배포 승인이 필요합니다. 문제는 지원 부담입니다. 생성된 카피, 레이아웃, 접근성 또는 통합을 수정해야 할 때 고객이 평가하는 대상은 v0가 아니라 에이전시입니다.

3. 제품 팀을 위한 기능 요청→미리보기 봇

승인된 이슈를 실행 가능한 변경 후보로 바꿉니다. GitHub App 또는 내부 웹훅이 저장소를 가져와 비동기 v0 채팅을 시작하고 채팅 ID를 기록한 뒤, 미리보기를 티켓에 다시 게시합니다. 병합이나 배포 전에는 사람이 검토합니다.

Google에서 how to build an app with ai의 미국 월간 검색량은 약 390회이며, 데이터셋은 연간 성장률을 86%로 집계했습니다. AI 어시스턴트에서 build an app with ai에 대한 수요는 2026년 7월 월 392회에 도달했습니다. 이는 완성된 작동 앱에 대한 관심을 뒷받침하지만, 독립형 CI 시장의 존재를 입증하지는 않습니다. 광범위한 셀프서비스 제품보다 팀 기능이나 개발자 플랫폼 애드온으로 접근해야 합니다.

MVP는 웹훅, 저장소 허용 목록, 비동기 작업 실행기, v0 채팅 저장소, 격리된 미리보기, 승인 상태로 구성됩니다. 문제는 위험입니다. 생성된 미리보기 코드는 신뢰할 수 없고, 저장소 접근은 민감하며, 그럴듯한 데모가 테스트, 보안, 마이그레이션, 예외 상황의 정확성을 보장하지는 않습니다. 프로덕션 배포를 기본 동작으로 설정해서는 안 됩니다.

코딩 에이전트와 프롬프트 기반 앱 제작 툴 사이에서 v0가 어디에 속하는지 더 폭넓게 보려면 2026년 최고의 바이브 코딩 툴을 참고하십시오.

v0 API가 해결해 주지 않는 것

API가 제공하는 것은 앱을 만드는 작업자와 그 작업실입니다. 그 주변의 제품은 여전히 직접 책임져야 합니다.

• 무엇을 만들어야 하는지는 결정해 주지 않습니다. 요청이 모호하면 엉뚱한 결과를 세련되게 구현할 수 있습니다. 접수 과정, 템플릿, 제약 조건, 검토 게이트가 중요합니다.
• 고객 권한을 확인해 주지 않습니다. 미리보기 헬퍼는 미리보기 트래픽을 전달하지만, 각 채팅에 누가 접근할 수 있는지는 애플리케이션이 판단해야 합니다.
• 생성된 코드를 신뢰할 수 있게 만들지는 않습니다. 메인 애플리케이션과 등록 가능 도메인이 다른 미리보기 전용 사이트에서 미리보기를 제공하고, 프로덕션에 반영하기 전에 코드를 검토해야 합니다.
• v1 채팅을 v2로 옮겨 주지 않습니다. v1 버전을 하나 선택해 ZIP으로 내려받은 뒤, 그 상태로 새 v2 채팅을 만듭니다.
• Vercel API를 대체하지 않습니다. 환경 변수와 여러 프로젝트 작업은 연결된 Vercel 프로젝트에서 관리됩니다.
• 비용을 고정해 주지 않습니다. 소스 파일, 대화 기록, 프롬프트, 출력이 모두 토큰 사용량에 반영됩니다.
• 로컬 앱 빌딩 엔진이 아닙니다. 통합 환경은 로컬에서 실행할 수 있지만, 공식 워크플로는 v0의 호스팅 API를 호출하고 Vercel 인프라에서 미리보기를 실행합니다.

제 판단으로는 실행 미리보기와 상태를 유지하는 반복 작업이 제품의 경쟁력이 될 때 v0를 쓰는 것이 좋습니다. 코드 조각이나 일회성 컴포넌트, 결과가 엄격히 정해진 파일 변환만 필요하다면 별도의 작업공간, 프록시, 크레딧 추적, 배포 체계를 둘 이유가 없습니다.

비즈니스에 맞게 설계하고 보안을 강화한 v0 기반 빌더가 필요하다면 프로덕션 AI 시스템을 구축해 드립니다.