코드 없이 30분 만에 앱 출시하기 — Lovable·Bolt.new 실전 가이드

유럽에서 가장 빠르게 성장한 스타트업 Lovable은 출시 석 달 만에 ARR 1,750만 달러를 찍었고, 매주 200만 달러씩 신규 매출을 더한다. 30일 리텐션 85%는 ChatGPT보다 높다. 이 열기의 정체는 하나다. "말로 설명하면 앱이 나온다."

진짜 그럴까. 결론부터 말하면 절반만 맞다. 30분이면 화면이 도는 데모는 확실히 나온다. 하지만 그 데모와 실제 출시할 수 있는 제품 사이엔 아무도 크게 말하지 않는 골짜기가 있다. 이 글은 도구를 고르는 법부터 그 골짜기를 건너는 법까지 다룬다.

30분 앱의 정체 — 세 도구는 서로 다른 물건이다

바이브코딩 도구를 "다 비슷한 노코드"로 묶으면 첫 단추부터 어긋난다. 같은 프롬프트를 넣어도 나오는 결과물의 성격이 다르기 때문이다.

Lovable은 비개발자를 정조준한다. 자연어로 설명하면 프론트엔드, 백엔드, Supabase 기반 PostgreSQL 데이터베이스, 인증, 원클릭 배포까지 한 흐름에 뽑아 준다. CEO 안톤 오시카가 "아이디어를 몇 초 만에 앱으로"라고 말할 때의 그 앱은, 로그인이 되고 데이터가 저장되는 풀스택 앱이다.

Bolt.new은 결이 다르다. StackBlitz의 브라우저 기반 개발 환경 위에서 React·Vue·Svelte·Astro를 넘나들고, Claude를 기본 모델로 코드를 생성하되 손으로 고칠 여지를 넉넉히 남긴다. 개발 지식이 조금 있는 사람이 통제권을 쥐고 속도를 얻는 도구다. StackBlitz는 2025년 1월 약 7억 달러 밸류에이션에 시리즈 B로 1억 550만 달러를 조달했다.

v0(Vercel)은 또 다르다. 프론트엔드 프로토타이핑에 특화돼 화면은 빠르게 뽑지만, 백엔드를 갖춘 완결형 앱을 혼자 만들어 주진 않는다. "만든다"는 단어가 도구마다 가리키는 범위가 이만큼 다르다.

실제로 30분 안에 뽑는 순서

초보가 가장 많이 하는 실수는 머릿속 아이디어를 통째로 프롬프트 창에 쏟는 것이다. 50페이지 설계도를 건축가에게 한꺼번에 던지는 셈이라, AI는 압도당하고 제멋대로 가정하고 엉뚱한 걸 짓는다. 잘 되는 사람들의 순서는 정반대다.

1단계 — 10분: 한 문장으로 범위를 자른다

"운동 기록 앱"처럼 뭉뚱그리지 말고, 화면·기능·데이터를 먼저 종이에 적는다. 어떤 페이지가 있고, 페이지마다 뭘 하고, 무엇을 저장하는가. 이 10분이 뒤의 세 시간을 좌우한다.

2단계 — 프롬프트를 5~7개로 쪼갠다

설계 문서(PRD)를 통째로 넣지 말고, AI에게 이렇게 시킨다.

# 프롬프트 계획 생성
이 PRD를 기반으로, AI 코딩 에이전트에게
한 번에 하나씩 순서대로 줄 프롬프트 5~7개로 쪼개라.
각 프롬프트는 이전 것 위에 쌓이는 하나의 기능만 담고,
기본 기능 → 고급 기능 순으로 정렬하라.

기능 하나를 만들고 눈으로 확인한 뒤 다음으로. 뭔가 깨져도(반드시 깨진다) 그 조각만 고치면 전체가 무너지지 않는다.

3단계 — 반복과 디버깅이 진짜 일이다

Bolt로 운동 기록 앱을 만든다면 핵심 화면을 먼저 스캐폴딩하고, UI를 다듬고, 마지막에 Supabase를 붙여 로그인과 기록을 영구 저장한다. 화면은 5분이면 나온다. 나머지 25분은 "저장이 안 돼요"를 붙잡고 씨름하는 시간이다. Lovable을 쓴다면 피그마 시안이나 스크린샷을 함께 붙여 넣는 것만으로 결과물의 완성도가 눈에 띄게 올라간다.

가격의 진실 — 크레딧과 토큰, 그리고 청구서

둘 다 Pro 기준 월 25달러로 시작한다. 여기까진 광고 문구가 맞다. 문제는 그 25달러가 실제로 며칠을 버티느냐다.

Lovable은 프롬프트 한 번에 1크레딧이라 계산은 편하지만, 실제로 기능을 붙잡고 반복하는 하루면 5크레딧이 오후 안에 증발한다. Bolt은 토큰이 복잡도에 따라 붙는데 그 개수가 공개되지 않아, 복잡한 프로젝트는 하루치 토큰을 한 세션에 태워 먹기도 한다.

"코드 없이"의 함정 — 여기서부터가 본론이다

여기까지는 대부분의 가이드가 하는 얘기다. 이제 아무도 크게 말하지 않는 쪽을 보자. 코드를 안 봤다는 건 편리함이 아니라 부채다.

2026년 초, 한 바이브코딩 앱이 잘못 설정된 데이터베이스 탓에 API 키 150만 개와 사용자 이메일 3만 5천 건을 노출했다. 앱 주인은 코드를 단 한 줄도 직접 쓰지 않았다고 인정했다. 개인 개발자 하르시는 Claude와 Cursor로 30일 실험을 했는데, 코딩 속도는 다섯 배 빨라졌지만 AI가 비밀번호를 평문으로 저장하고 API 키를 노출하는 결함을 심었다. 그의 결론은 뼈아프다. "바이브코딩은 내 코딩 실력을 대체하지 않았다. 내 실력의 민낯을 드러냈다."

이건 예외적 사고가 아니라 구조적 확률이다. 스탠퍼드 연구에서 GitHub Copilot은 보안 관련 작업의 약 40%에서 취약점이 있는 코드를 생성했다. 모델은 그동안 좋아졌지만 그 비율이 0이 된 적은 없다. 더 무서운 건 이 취약점들이 에러를 던지지 않는다는 점이다. 테스트를 통과하고, 코드 리뷰에서도 멀쩡해 보이다가, 공격 상황에서만 정체를 드러낸다.

그래서 2026년의 성숙한 정의는 "노코드"가 아니다. 개발자가 자연어로 명세를 쓰고, AI가 구조화된 사람의 감독 아래 코드를 생성한다. 결제·인증·암호화 같은 보안 핵심부는 여전히 사람이 읽고 손봐야 한다. 반대로 성공 사례도 이 원칙을 지킨다. 피터 레벨스는 바이브코딩으로 17일 만에 멀티플레이어 게임을 내 연 100만 달러 매출을 냈는데, 그는 실행 속도만 AI에 맡겼을 뿐 아키텍처 통제권은 끝까지 자기 손에 뒀다.

그래서 오늘 뭘 하면 되나

도구를 몇 주씩 비교하는 건 시간 낭비다. 지금 당신의 목적에 맞춰 하나만 고르면 된다. "이게 진짜인지 감이나 보자"면 Bolt, "남에게 보여줄 걸 만들자"면 Lovable, "화면부터 빠르게 검증하자"면 v0. 하루 5크레딧 무료 티어로 오늘 저녁에 시작할 수 있다.

다만 딱 하나는 기억하자. AI가 뽑아 준 코드를 배포 버튼 앞에서 한 번 읽는 습관. 30분 만에 만든 앱이 30초 만에 데이터를 흘리지 않으려면, 결국 누군가는 그 코드를 읽어야 한다. 그 누군가가 당신이 아니라면, 그건 정말 당신 앱일까?