Lovable.dev vs Bolt.new — 1인 창업자를 위한 MVP 개발 플랫폼 분석

자연어 지시문만으로 웹 앱의 뼈대를 세우고 배포까지 끝내는 ‘바이브 코딩’이 1인 창업 쪽에서도 더 이상 특이 사례가 아닙니다. 그중 Lovable.dev와 Bolt.new는 MVP를 짧게 찍어보려는 사람이 거의 처음으로 마주치는 조합입니다. 겉보기엔 둘 다 “채팅으로 앱 만들기”처럼 보이지만, 실제로는 개발 철학·백엔드 결합 방식·막혔을 때 빠져나오는 경로가 꽤 다릅니다.

저는 1인으로 제품 스케치를 돌릴 때 이 둘을 번갈아 썼습니다. 어떤 날은 Lovable로 로그인·테이블·대시보드까지 한 번에 붙였고, 어떤 날은 Bolt.new에서 Next.js 뼈대를 깔고 패키지를 직접 고치며 감을 잡았습니다. 이 글은 기능 나열이 아니라, 그 과정에서 체감한 차이와 실패 모드, 그리고 “언제 이 도구를 버리고 Cursor 같은 로컬 환경으로 넘어갈지”까지 정리한 실무 메모입니다.

세 줄로 먼저

한 줄: Lovable.dev와 Bolt.new는 둘 다 자연어로 작동 가능한 웹 MVP를 만드는 AI 빌더지만, Lovable은 Supabase 중심의 가이드형, Bolt는 브라우저 안 풀스택 통제형입니다.
차이: 로그인·DB·스토리지를 빨리 붙이려면 Lovable이, 프레임워크와 파일·터미널을 직접 다루려면 Bolt.new가 맞습니다.
추천: “회원가입 받고 데이터 쌓는 SaaS 뼈대”면 Lovable, “Next.js/Astro로 SEO·커스텀 로직까지”면 Bolt. 둘 다 막히면 로컬 IDE로 옮기세요.

내가 1인 창업 맥락에서 이 비교를 쓰는 이유

도구 비교 글은 인터넷에 많습니다. 그런데 1인으로 만들다 보면 질문이 달라집니다. “어느 쪽이 더 똑똑한가”가 아니라, 오늘 오후 안에 클릭 가능한 화면이 나오는지, 크레딧이 바닥나기 전에 핵심 플로우를 검증할 수 있는지, 나중에 GitHub로 빼서 유지보수할 수 있는지입니다.

저는 아이디어를 검증할 때 보통 이렇게 나눕니다. (1) 랜딩만 필요하면 정적 사이트나 가벼운 빌더, (2) 계정·데이터가 필요하면 Lovable+Supabase 쪽을 먼저 시험, (3) 프레임워크·배포 파이프라인을 내가 쥐고 싶으면 Bolt나 Cursor. 아래는 그 기준을 Lovable과 Bolt에 맞춰 풀어쓴 것입니다. 요금 숫자는 글에 이미 있던 2026년 스냅샷(대략치)을 유지합니다. 실제 가격은 공식 사이트를 확인하세요.

30분 안에 같은 MVP 스케치를 돌렸을 때 체감 차이

같은 프롬프트로 “이메일 로그인 + 간단한 할 일 목록 + 내 것만 보이는 리스트”를 양쪽에서 돌려보면 차이가 빨리 드러납니다.

Lovable 쪽 워크플로

프롬프트를 넣으면 UI가 먼저 잡힙니다. 버튼·폼·빈 상태가 그럴듯하게 나옵니다. Supabase를 연결하면 Auth와 테이블 생성이 대화 흐름 안에 들어옵니다. 체감상 “기획서 → 클릭 가능한 프로토타입” 구간이 짧습니다. 대신 막히면 원인을 파일 단위로 파고들기보다, 다시 프롬프트를 다듬거나 연동 설정을 다시 누르는 쪽에 시간이 갑니다.

Bolt.new 쪽 워크플로

시작부터 파일 트리와 터미널이 보입니다. Next.js나 Vite 템플릿이 뜨고 npm install이 돌아갑니다. AI가 코드를 짜는 동안 컴파일 에러가 터미널에 찍히고, 그걸 내가 고칠 수 있습니다. 초반 UI 완성도는 Lovable보다 들쭉날쭉할 수 있지만, “이 패키지 버전을 바꿔야지” 같은 개발자형 개입이 자연스럽습니다.

30분 기준 제 감각을 거칠게 적으면 이렇습니다. Lovable은 데모용 플로우 완성이 빠르고, Bolt는 코드베이스를 내가 이해할 수 있는 상태로 가져가기가 빠릅니다. 고객 미팅용 클릭 데모면 전자, 다음 주에 직접 고칠 코드가 필요하면 후자를 고릅니다.

Lovable.dev: 비개발자도 다루기 쉬운 가이드형 빌더

Lovable.dev는 백엔드 인프라에 대한 깊은 지식이 없는 기획자·디자이너, 혹은 프론트 작업량을 줄이고 싶은 1인 창업자에게 맞춰진 도구입니다. 기능 요구를 텍스트로 설명하면 컴포넌트와 UI를 맞춰 나갑니다.

UI/UX 템플릿: 외형이 정돈된 컴포넌트를 빠르게 붙입니다. CSS를 깊게 파지 않아도 모던한 톤이 나옵니다.
Supabase 결합: Auth, PostgreSQL 테이블, 스토리지까지 연동 흐름이 제품 안에 녹아 있습니다. “회원 가입 화면 만들고 유저 테이블에 넣어줘” 같은 지시가 실제로 통하는 편입니다.
GitHub 동기화: 작업물을 레포에 동기화해 이후 단계에서 코드를 가져갈 수 있습니다. 다만 “동기화됐다”와 “내가 로컬에서 편하게 유지보수한다”는 다른 이야기입니다.

요금제 구성 (2026년 스냅샷, 대략)

Free: 일일 5 credits 전후. 랜딩·아주 짧은 프로토타입용.
Pro: 월 약 25달러(약 3만 3천 원대)부터. 개인·초기 스타트업이 본격적으로 돌릴 때.
Business: 월 약 50달러(약 6만 6천 원대) 수준. 협업·보안·학습 데이터 opt-out 같은 옵션이 붙는 구간.

무료 크레딧은 “오늘 아이디어가 화면으로 나오는지”를 보기에 충분하지만, 스키마를 여러 번 고치면 금방 닳습니다. 그래서 저는 프롬프트를 쓰기 전에 핵심 화면 2~3개와 데이터 필드 목록을 메모장에 먼저 적습니다.

Lovable + Supabase에서 자주 걸린 함정

연동이 쉽다는 말은, 잘못 열어도 쉽다는 뜻과 같이 옵니다. 제가 실제로 시간을 날린 패턴입니다.

1) 권한과 RLS를 나중에 보면 데모가 무너진다

(RLS 정책 SQL 예제와 출시 전 테스트 방법은 Supabase RLS 설정 방법: 출시 전 막아야 할 7가지 구멍에 따로 정리했습니다.)

테이블은 생겼는데 Row Level Security를 대충 두면, 로그인한 사용자끼리 데이터가 보이거나, 반대로 본인 데이터도 안 보이는 상태가 납니다. 데모 직전에는 “내 계정으로만 잘 보이네”로 넘어가기 쉽습니다. MVP라도 본인 row만 select/insert 규칙을 최소로 걸어두고, 다른 계정으로 한 번 더 로그인해서 확인하세요.

2) 스키마 드리프트

AI에게 “필드 추가해줘”를 반복하면 UI 타입과 DB 컬럼이 어긋납니다. 화면에는 필드가 있는데 insert가 실패하거나, 예전 컬럼명을 코드가 계속 참조합니다. 해결은 거창하지 않습니다. 테이블 컬럼 목록을 스크린샷이나 메모로 고정해 두고, 프롬프트에 “기존 컬럼명 유지, 새 컬럼만 추가”를 명시하세요.

3) 크레딧 소진 타이밍

UI를 예쁘게 다듬는 대화에 크레딧을 다 쓰면, 정작 Auth 콜백·이메일 확인·에러 토스트 같은 “검증용 핵심”을 못 건드립니다. 저는 순서를 바꿉니다. 로그인 → 생성 → 목록 → 삭제가 되면 그다음에 디자인. 디자인이 먼저면 크레딧만 사라지고 검증은 못 끝납니다.

4) “연결된 것처럼 보이는” 상태

연동 버튼은 초록인데 환경 변수나 프로젝트가 다른 걸 가리키는 경우가 있습니다. 증상은 애매합니다. 로그인은 되는데 데이터가 안 쌓이거나, 로컬 프리뷰와 배포 URL 동작이 다릅니다. Supabase 대시보드에서 테이블에 row가 실제로 생기는지, Auth 제공자 설정이 의도한 프로젝트인지 직접 보세요.

Bolt.new: 브라우저 안에서 개발 환경이 필요할 때

StackBlitz가 운영하는 Bolt.new는 코드와 터미널 통제권을 개발자에게 넘기는 쪽에 가깝습니다. WebContainers로 브라우저 안에서 Node 비슷한 환경을 돌리기 때문에, 로컬에 스택을 깔지 않고도 파일·패키지·스크립트를 다룹니다.

프레임워크 선택: React, Astro, Next.js, Vue 등 원하는 스택으로 시작할 수 있습니다.
가상 터미널: npm install, 테스트, 빌드 로그를 바로 봅니다. AI가 짠 코드의 컴파일 에러를 내가 고칠 수 있습니다.
반출이 수월: 파일 트리가 보이니 ZIP이나 GitHub로 빼서 Vercel·Netlify로 이어가기 쉽습니다. 플랫폼 락인이 Lovable+Supabase 묶음보다 약한 편입니다.

Bolt.new + WebContainers에서 자주 걸린 함정

1) 패키지 설치 실패

브라우저 컨테이너 특성상 네이티브 바인딩이 있는 패키지, 무거운 도구, 특정 Node 버전 가정이 깨지기 쉽습니다. AI가 “설치하면 됩니다”라고 해도 터미널이 빨갛게 남습니다. 대응은 단순합니다. 의존성을 줄이거나, 브라우저에서 돌리기 어려운 부분은 나중에 로컬/서버로 미룹니다. MVP 단계에서 sharp 같은 무거운 이미지 파이프라인을 억지로 넣지 마세요.

2) 브라우저 메모리·탭 피로

긴 세션, 큰 node_modules, 여러 프리뷰가 겹치면 탭이 느려지거나 상태가 이상해집니다. 증상은 “방금 고친 코드가 반영이 안 되는 것 같다”로 옵니다. 저장·Git 푸시를 습관화하고, 이상하면 새로 고침보다 현재 파일 상태를 GitHub에 먼저 확보한 뒤 세션을 다시 여는 편이 안전합니다.

3) 배포 전 정리

프리뷰에서는 되는데 배포에서 깨지는 전형적인 원인: 환경 변수 누락, 클라이언트에 넣으면 안 되는 키, 빌드 스크립트와 개발 서버 설정의 불일치입니다. Bolt에서 돌아가는 것을 “프로덕션 준비 완료”로 착각하지 마세요. GitHub에 올린 뒤 Vercel 등에서 한 번 더 빌드 로그를 읽어야 합니다.

4) AI가 파일을 너무 많이 건드릴 때

한 번의 지시에 관련 없는 파일까지 수정되면 디프를 읽기 어려워집니다. “이 파일만 수정”, “기존 API 라우트 시그니처 유지”처럼 범위를 좁히세요. 안 그러면 30분 뒤에 원복할 지점을 잃습니다.

두 플랫폼 비교표

타깃과 백엔드 결합 방식에서 차이가 큽니다. 표로만 보면 이렇습니다.

비교 항목	Lovable.dev (러버블)	Bolt.new (볼트)
주요 사용자층	기획자, 디자이너, 비개발 비즈니스 창업자	풀스택 개발자, 프레임워크 제어가 필요한 엔지니어
백엔드 결합도	매우 높음 (Supabase DB, Auth, Storage 내장 연동)	낮음 (개발자가 API 엔드포인트 직접 바인딩·구성)
코드 통제 수준	AI 가이드 중심 (고수준 추상화)	매우 높음 (파일 수정, 패키지 설치, 가상 터미널)
배포 및 락인	플랫폼 내장 배포 + Supabase 의존 높음	반출 용이 (Netlify, Vercel 등과 궁합)
시작 비용	무료 크레딧 → 본격 이용 시 월 $25대부터	가입 후 사용 가능, 고성능 모델·사용량에 따라 유료
막혔을 때	프롬프트·연동 재시도, 대시보드 확인	터미널 로그·파일 디프·패키지 교체

의사결정 체크리스트: 언제 Lovable / 언제 Bolt / 언제 떠날까

Lovable을 고르는 경우

회원가입·권한·CRUD가 MVP의 중심이다.
고객에게 보여줄 클릭 데모가 이번 주 안에 필요하다.
내가 직접 Nginx나 ORM을 만지고 싶지 않다.
Supabase 하나로 Auth+DB를 감수할 수 있다.

Bolt.new를 고르는 경우

Next.js/Astro 등 특정 프레임워크가 이미 결정돼 있다.
SEO·라우팅·미들웨어처럼 코드 구조가 중요하다.
터미널에서 의존성과 빌드를 직접 보고 싶다.
곧 GitHub → Vercel 파이프라인으로 옮길 계획이다.

둘 다 쓰지 말고 Cursor 등으로 넘어갈 때

같은 버그를 세 번 이상 프롬프트로 고치라고 했는데 회귀한다.
크레딧·토큰 비용이 기능 진척보다 빨리 는다.
보안·결제·복잡한 권한처럼 “틀린 추상화”가 위험한 영역이다.
팀이 생기거나, 테스트·CI가 필요해졌다.

떠나는 기준을 미리 정해 두면, 도구에 미련을 두고 일주일 더 붙잡는 일을 줄일 수 있습니다. 저는 “핵심 플로우 하나가 안정적으로 재현되면 저장소를 로컬로 옮긴다”를 기본 규칙으로 둡니다.

로컬로 옮긴 뒤 Cursor와 Claude Code 중 무엇을 쓸지, 월 사용량에 따라 실제로 얼마가 드는지는 Cursor vs Claude Code 요금 비교에서 따져 봤습니다. 옮긴 코드가 실제 사용자를 받기 전에 어디부터 무너지는지는 바이브 코딩 앱 프로덕션 가이드에 단계별로 적어 두었습니다.

비용·락인·이후 이관 시나리오

비용은 구독료만이 아닙니다. 재작업 시간이 더 큽니다. Lovable에서 예쁘게 만든 뒤 스키마를 크게 바꾸면, 그동안 쌓인 프롬프트 히스토리보다 DB 마이그레이션과 RLS 재설계에 시간이 갑니다. Bolt는 구독보다 WebContainer 한계와 배포 환경 차이를 메우는 시간이 비용입니다.

락인 관점에서는 대략 이렇게 봅니다.

Lovable → 외부: GitHub 동기화로 프론트 코드는 빼기 쉽습니다. 다만 Auth·RLS·스토리지 정책을 Supabase에 맞춰 두었다면, 그 설계를 통째로 다른 BaaS로 옮기기는 무겁습니다. 현실적인 이관은 “코드는 가져가고 Supabase는 당분간 유지”입니다.
Bolt → 외부: 파일과 패키지 구조가 이미 일반 프론트/풀스택 프로젝트에 가깝습니다. 환경 변수와 빌드 명령만 정리하면 Vercel 등으로의 이동이 비교적 직선적입니다.

이관 전에 체크할 최소 목록: (1) 환경 변수 목록, (2) Auth 콜백 URL, (3) DB 스키마 덤프 또는 마이그레이션 파일, (4) 시크릿이 클라이언트 번들에 없는지.

프론트만이 아니라 백엔드 서버까지 따로 띄워야 한다면 Railway 같은 PaaS도 후보에 들어갑니다. 무료 플랜과 Hobby 플랜의 차이, 청구서가 갑자기 커지지 않게 거는 비용 한도는 Railway 요금 가이드에 정리했습니다.

어떤 도구를 골라야 할까 (시나리오)

회원 가입을 받고 데이터를 쌓는 SaaS MVP

로그인 후 데이터가 쌓이고 관리 화면에 보이는 전형적인 형태라면 Lovable.dev가 유리합니다. 백엔드 서버를 따로 세우기 전에 AI에게 화면과 Supabase 테이블을 같이 만들게 할 수 있습니다. 다만 위에서 적은 RLS·스키마·크레딧 순서는 지키세요.

특정 프레임워크와 코드 통제가 필요할 때

로컬 개발 경험이 있고 Next.js·Astro로 SEO나 커스텀 라우팅을 가져가고 싶다면 Bolt.new가 맞습니다. 보일러플레이트는 AI에게, 민감한 키 연동과 복잡한 도메인 로직은 터미널·에디터로 직접 다루는 식이 잘 맞았습니다.

FAQ

Q. 비개발자인데 Bolt.new부터 해도 되나요?
터미널 로그를 읽는 게 부담이면 Lovable이 심리적으로 낫습니다. Bolt는 “에러 메시지를 보고 다음 프롬프트를 쓰는” 루프에 익숙할수록 효율이 납니다.

Q. Lovable만으로 출시까지 가능한가요?
간단한 B2C/내부 도구 MVP는 가능한 경우가 많습니다. 결제·규정·복잡한 멀티테넌시가 붙으면 추상화 밖으로 나가는 순간이 옵니다. 그때를 실패가 아니라 졸업으로 보시면 됩니다.

Q. 둘을 동시에 구독해야 하나요?
보통은 아닙니다. 같은 아이디어를 양쪽에 30분씩 시험한 뒤 하나만 깊게 가는 편이 크레딧 낭비가 적습니다.

Q. Supabase 없이 Lovable을 쓰나요?
UI만 보는 단계에서는 가능하지만, Lovable을 고르는 이유의 상당 부분이 Supabase 결합입니다. 데이터 없는 화면만 필요하면 더 가벼운 랜딩 도구도 있습니다.

Q. Bolt에서 만든 코드를 Cursor로 이어갈 수 있나요?
됩니다. GitHub에 올린 뒤 로컬에서 클론해 Cursor로 여는 흐름이 자연스럽습니다. 오히려 그게 Bolt의 강점입니다.

Q. 가격이 오른 것 같은데 글을 믿어도 되나요?
이 글의 달러·원화는 2026년 기준 대략치입니다. 결제 전에 공식 요금 페이지를 확인하세요.

Q. AI가 보안을 알아서 해주나요?
아닙니다. RLS, 키 노출, 관리자 권한 같은 건 사람이 확인해야 합니다. “작동한다”와 “안전하게 작동한다”는 다릅니다.

정리

Lovable.dev와 Bolt.new는 “1인으로도 아이디어를 빨리 화면에 올릴 수 있는가”에 대한 현실적인 답에 가깝습니다. 예전에는 MVP 하나에 외주와 인프라로 수개월이 갔지만, 지금은 월 수십 달러대 도구로 하루 안에 뼈대를 볼 수도 있습니다. 다만 도구가 완벽해서가 아니라, 시나리오에 맞는 쪽을 고르고 실패 모드를 미리 아는 사람이 더 빨리 검증합니다.

생산성은 모델 이름보다 순서에서 갈립니다. 핵심 플로우 먼저, 예쁜 화면은 나중. 막히면 며칠을 더 붙잡지 말고 저장소를 옮겨세요. 솔직히 하루만 같은 오류를 프롬프트로 때려도 이미 신호입니다.

바로 실행할 체크리스트

검증하고 싶은 사용자 행동 하나를 문장으로 적는다. 예: “가입한 사용자가 할 일 하나를 만들고 다시 로그인해도 보인다.”
그 행동에 DB가 필요하면 Lovable+Supabase, 프레임워크·SEO가 먼저면 Bolt.new로 30분 스파크 테스트를 한다.
Lovable을 택했다면 RLS로 본인 데이터만 보이게 한 뒤, 두 번째 계정으로 교차 확인한다.
Bolt를 택했다면 첫 커밋을 GitHub에 푸시한 뒤, 배포 환경에서 빌드가 한 번 통과하는지 본다.
크레딧/토큰을 UI 장식에 쓰기 전에 생성·조회·삭제 플로우를 끝낸다.
같은 버그가 세 번 회귀하면 Cursor(또는 익숙한 로컬 IDE)로 이관 일정을 잡는다.
환경 변수·콜백 URL·스키마 메모를 README 한 페이지에 남긴다.

공식 링크: Lovable.dev · Bolt.new · Supabase