비개발자를 위한 바이브 코딩: 2026년에 안전하게 만들 수 있는 것들

2026년 현재 비개발자도 바이브 코딩으로 꽤 많은 것을 안전하게 만들 수 있습니다. 다만 넘지 말아야 할 선이 분명히 있습니다. 그 아래에는 프로토타입, 랜딩 페이지, 내부 도구, 로그인과 데이터베이스가 있는 간단한 앱이 있습니다. 그 위에는 맞춤형 결제 로직, 건강 정보나 금융 기록, 여러 회사가 함께 쓰는 앱, 트래픽이 많은 서비스가 있습니다. 이런 것들은 여전히 엔지니어가 필요합니다.

사용자층은 이미 형성되어 있습니다. Lovable은 빌더의 80%가 스스로 비기술 직군이라고 답했고, 웹사이트뿐 아니라 내부 도구, CRM, 온라인 스토어에도 쓰인다고 밝혔습니다(The Next Web). 사고도 함께 따라왔습니다. 올해 UpGuard는 이런 앱 상당수가 백엔드로 쓰는 Supabase에서 인터넷의 누구나 테이블을 읽을 수 있는 데이터베이스 16,326개를 발견했습니다(UpGuard). Veracode는 4년 동안 100개가 넘는 AI 모델을 테스트했고, AI가 작성한 코드의 평균 보안 통과율을 56%로 집계했습니다. 보고서의 표현을 빌리면 "변하지 않았습니다"(Veracode).

피해의 대부분은 코드를 읽지 않아도 확인할 수 있는 한 가지 실수로 거슬러 올라갑니다. 요청하는 누구에게나 데이터 행을 내주는 데이터베이스입니다. 이것을 고치고 비밀 키를 브라우저 밖에 두면, 창업자나 마케터, 애널리스트가 만들고 싶어 하는 대부분은 안심하고 만들어도 됩니다.

2026년의 바이브 코딩은 어떤 모습인가

원하는 것을 평범한 말로 설명하면 도구가 코드를 작성하고, 라이브 미리보기를 클릭해 보며 다음 수정을 요청하는 방식입니다. 비개발자를 겨냥한 도구들은 이제 화면 제작을 훌쩍 넘어섭니다. 데이터베이스, 회원가입 시스템, 호스팅까지 만들어 주기 때문에, 오후 한나절 프롬프트를 입력하는 것만으로 실제 계정이 있는 앱이 나올 수 있습니다.

다이어그램은 출구가 하나 있는 반복 루프로 보시면 됩니다. 사람들이 건너뛰는 부분이 바로 그 출구입니다.

점선 화살표가 테스트 단계에서 나가는 데에는 이유가 있습니다. 생성된 코드를 읽어서 판단할 수는 없지만, 그 코드가 무엇을 하는지는 판단할 수 있습니다. 두 번째 계정이 첫 번째 계정의 기록을 볼 수 있는지, 로그인하지 않고도 페이지가 열리는지 확인하면 됩니다. 테스트가 돈, 다른 사람의 개인 데이터, 실제 규모와 맞닿는 순간에는 멈추고 코드를 읽을 수 있는 사람을 불러야 합니다.

올해는 많은 것이 바뀌었습니다. Lovable은 이제 빌드 메시지 하나가 최대 10시간까지 실행될 수 있고, 작업이 끝날 때까지 계속 진행하는 /goal 명령을 추가했으며, 가격은 눈에 띄게 높습니다(Lovable changelog). Replit은 병렬 에이전트를 갖춘 Agent 4를 내놓았고, AI는 이제 Free Mode와 유료 Power, Max 모드로 운영됩니다. Vercel은 v0를 GitHub 브랜치와 풀 리퀘스트 중심으로 다시 만들었는데, 제품 총괄은 실제 업무의 90%가 기존 코드베이스를 바꾸는 일이라고 말했습니다. Wix의 Base44는 자체 모델 Base1을 학습시켰으며, 창업자는 이 모델이 결국 최신 프런티어 모델보다 고객에게 더 빠르고 저렴해질 것으로 예상합니다.

Google AI Studio는 이제 앱에 데이터베이스나 로그인이 필요한 때를 알아채고, 승인하면 두 가지를 모두 Firebase로 설정해 줍니다. 이전 빌더인 Firebase Studio는 종료 예정이므로, 이를 기준으로 한 튜토리얼은 이미 낡은 내용입니다.

위험 사다리: 혼자 만들어도 되는 것

위험은 두 가지에 따라 올라갑니다. 앱이 누구의 데이터를 가지고 있는지, 그리고 앱을 통해 돈이 오가는지입니다. 가짜 기록으로 가득한 프로토타입은 아무것도 유출할 수 없습니다. 낯선 사람의 이메일 주소를 보관하는 가입형 앱은 유출할 수 있고, 올해 실제로 많은 곳에서 그랬습니다.

사다리는 흔한 프로젝트를 그 위험에 따라 나눈 것입니다. 아래 세 칸은 누구나 만들어도 되는 영역입니다. 호박색 칸은 올해 유출 사고 대부분이 일어난 곳입니다.

클릭 가능한 프로토타입, 문의 양식이 있는 랜딩 페이지, 팀 전용 내부 도구가 가장 알맞은 영역입니다. 프로토타입은 누군가 티켓을 쓰기 전에 "이걸 만들어야 할까?"에 답해 줍니다. 영업팀이나 운영팀의 내부 트래커는 아무도 믿지 않는 스프레드시트를 대체할 수 있고, 로그인이 걸린 워크스페이스 전용으로 설정해 두면 오용할 수 있는 사람은 동료뿐입니다. 간단한 자동화도 이 단계에 속하지만, n8n이나 Zapier 같은 워크플로 도구가 앱을 만들지 않고도 같은 일을 해 주는 경우가 많습니다(워크플로 자동화 보드 참고).

계정이 있는 고객용 앱은 호박색 단계입니다. 도구가 만들지 못하는 것은 아닙니다. 문제는 데이터베이스 규칙 하나만 잘못돼도 모든 사용자가 한꺼번에 노출된다는 점입니다. 만든 다음, 실제 사용자가 가입하기 전에 엔지니어에게 비용을 지불하고 검토를 받으세요.

위쪽 두 단계는 엔지니어의 몫입니다. 먼저 결제입니다. Stripe의 호스팅 결제 페이지를 여는 구매 버튼은 괜찮습니다. 카드 정보가 앱을 거치지 않고 곧바로 Stripe로 가기 때문입니다. Stripe의 보안 가이드는 카드 데이터를 직접 받는 사업자가 PCI DSS에 따라 300개가 넘는 보안 통제를 충족해야 할 수 있다고 경고합니다. 사용량 기반 과금이나 여러 회사가 한 데이터베이스를 공유하는 앱은 둘 다 권한 부여 로직에 달려 있는데, AI로 만든 앱에서 결함이 계속 발견되는 곳이 바로 여기입니다.

다른 하나는 규제 대상 데이터입니다. Lovable의 엔터프라이즈 FAQ는 사업제휴계약(BAA)을 체결하지 않으며, HIPAA를 준수하지 않고, 보호 대상 건강 정보를 업로드하지 말라고 안내합니다. 건강, 금융, 아동 데이터에는 어떤 게시 전 스캔으로도 해결할 수 없는 법적 의무가 따릅니다.

지금 중요한 도구들과 각각의 과금 방식

이 글의 독자에게는 빌더 다섯 곳이면 대부분 충분하며, 이들은 무엇을 만들 수 있느냐보다 요금을 매기는 방식과 떠나기 쉬운 정도에서 차이가 납니다. Bolt와 v0가 Lovable, Replit, Base44와 나란히 놓입니다. 가격은 각 업체 요금 페이지의 입문용 유료 플랜 기준입니다.

대부분의 비개발자에게는 Lovable이 무난한 기본 선택입니다. 메시지당 예상 비용을 공개하고, 게시할 때마다 보안 문제를 스캔하며, 무료 플랜을 포함한 모든 플랜에서 코드를 GitHub와 동기화할 수 있습니다. Base44는 코드를 아예 보고 싶지 않은 사람에게 맞지만, 아래 인계 섹션에서 다룰 한 가지 단서가 있습니다. Replit은 앱, 슬라이드, 데이터 대시보드를 한 워크스페이스에서 다루고 싶을 때 어울리고, Free Mode는 가장 부담 없이 시작하는 방법입니다. Bolt는 몰아서 작업하는 사람에게 맞는데, 쓰지 않은 유료 토큰이 한 달간 이월되기 때문입니다. v0는 회사가 이미 Vercel에 배포하고 있고 엔지니어가 프로젝트를 이어받을 때 고를 만합니다.

비주얼 에디터로 비슷한 영역을 다루는 기존 노코드 옵션도 두 가지 있습니다. Bubble은 웹과 모바일 앱을 만들고, Glide는 스프레드시트를 앱으로 바꿔 줍니다. 아래 라이브 보드에서 이 카테고리 전체의 현재 순위를 볼 수 있고, AI 앱 빌더 총정리에서는 열두 가지 도구를 더 깊이 다룹니다.

이 보드에는 개발자를 겨냥한 빌더도 포함되어 있으니, 탐색에는 보드를, 예산 계획에는 위의 표를 활용하세요.

크레딧이 예상보다 빨리 소진되는 이유

이제 이 도구들은 모두 보내는 메시지가 아니라 AI가 하는 작업량을 기준으로 과금합니다. 작은 수정에는 합리적이지만, 모호한 요청에는 비쌉니다.

가장 명확한 예시는 Lovable이 공개하고 있습니다. "버튼을 회색으로 바꿔 줘"는 0.50 크레딧, "인증 추가"는 1.20, "이미지가 있는 랜딩 페이지 만들기"는 2.00이 들었고, 플랜 모드 메시지는 1 크레딧입니다(Lovable). 빌드 메시지 하나가 이제 몇 시간씩 실행될 수 있으므로, Lovable은 한 메시지가 20 크레딧을 넘으면 잠시 멈추고 확인을 요청합니다. 이 기본값은 높이거나 끌 수 있습니다. Pro의 추가 충전은 50 크레딧에 $15로 크레딧당 $0.30이며, 100 크레딧 플랜 안에서는 $0.25입니다.

다른 도구들도 이름만 다를 뿐 방식은 같습니다. Bolt 고객센터에 따르면 토큰 사용의 대부분은 프로젝트 파일을 읽고 동기화하는 데서 나오기 때문에, 같은 프롬프트라도 앱이 커질수록 비용이 늘어납니다. v0는 채팅 기록과 소스 파일을 입력 토큰으로 계산합니다. Base44는 메시지당 정해진 비용은 없다고 밝히며, 일반적인 변경은 대략 0.5~4 크레딧 사이라고 안내합니다. Replit의 Free Mode는 허용량 안에서는 무료이지만 Power와 Max 모드는 월별 크레딧을 소모하며, 추가 크레딧 팩은 구매 후 6개월이 지나면 만료됩니다.

Lovable의 가격 사다리를 보면 예산에 어떤 의미인지 알 수 있습니다.

대량 구매 할인은 거의 없습니다. 800 크레딧까지는 모든 구간이 크레딧당 $0.25이고, 2,000 크레딧 구간도 $0.24입니다. 프롬프트를 두 배로 쓰면 청구액도 두 배가 되므로, 실제로 중요한 것은 낭비되는 메시지를 줄이는 일입니다.

낭비는 대부분 수정 루프에서 나옵니다. AI가 무언가를 망가뜨리고, 그 수정이 또 다른 것을 망가뜨리며, 매 라운드가 모두 과금됩니다. 먼저 계획을 세우면 도움이 됩니다. Lovable의 플랜 모드 메시지는 1 크레딧 정액이고, Bolt는 플랜 모드가 아무것도 바꾸지 않아 토큰을 덜 쓴다고 설명합니다. 버튼도 도움이 됩니다. Bolt에 따르면 버튼으로 버전을 게시하거나 복원하는 것은 비용이 들지 않지만, AI에게 시키면 토큰이 소모됩니다. 세션이 엉뚱한 방향으로 흘러가면 프롬프트로 빠져나오려 하지 말고 체크포인트로 롤백하세요.

아래 계산기에 본인의 작업 습관을 넣어 보세요. Lovable의 예시 비용을 기준으로 하므로, 견적이 아니라 예산 범위로 받아들이시기 바랍니다.

기본값에서는 월 약 162 크레딧이 필요하며, $50 구간이면 충분합니다. 재작업 비율을 60%로 올리면 더 저렴한 방법인 $25 플랜에 추가 충전을 더하는 경우에도 $70까지 올라갑니다. 상한도 설정해 두세요. Lovable의 자동 충전은 "제한 없음" 대신 월 지출 한도를 지정할 수 있고, Replit도 포함된 크레딧을 넘는 지출에 상한을 걸 수 있습니다. 크레딧 요금제가 여전히 헷갈린다면 크레딧, 좌석, 토큰을 설명한 AI 도구 요금제 해설을 참고하세요.

사고 기록이 가리키는 실수는 하나입니다

올해의 사고 보고서를 나란히 놓으면 같은 실패가 계속 나옵니다. 교묘한 해킹이 아닙니다. 묻는 누구에게나 답해 주는 데이터베이스입니다.

UpGuard의 조사에서는 약 30만 개 도메인에서 Supabase 사용 흔적이 나왔고, 읽을 수 있는 테이블을 노출한 데이터베이스가 16,326개였으며, 그중 절반 이상에서 개인 데이터의 흔적이 보였습니다(UpGuard). 설명은 구체적입니다. 코딩 에이전트가 Supabase와 통신하는 방식인 API를 통해 만든 테이블에는 행 수준 보안(RLS)이 기본으로 켜지지 않는다는 것입니다. Supabase의 보안 책임자는 TechCrunch에 프로젝트는 기본적으로 안전하며 보안은 공동의 책임이라고 말했습니다.

AI 에이전트를 위한 소셜 네트워크 Moltbook은 창업자가 "코드를 한 줄도 쓰지 않았다"고 말한 서비스인데, 페이지에 Supabase 키가 그대로 담겼고 행 수준 보안 정책도 없이 출시되었습니다. Wiz 연구진은 API 토큰 150만 개, 이메일 주소 3만 5천 개, 수천 건의 비공개 메시지에 접근했고, 팀은 통보를 받은 지 몇 시간 뒤에 패치했습니다(Wiz).

연구원 Taimur Khan에 따르면 Lovable에서 호스팅된 한 앱이 사용자 기록 18,697건을 노출했고, 그중 수천 건이 학생 계정이었습니다. 그는 접근 확인이 거꾸로 작성된 것을 발견했습니다. "경비가 들여보내야 할 사람은 막고, 막아야 할 사람은 들여보냅니다"(The Register). Lovable은 게시 전에 무료 보안 스캔을 제공하며 그 결과에 따라 조치하는 것은 사용자의 몫이고, 취약한 데이터베이스는 Lovable이 호스팅한 것이 아니며 프로젝트에 Lovable이 생성하지 않은 코드도 들어 있었다고 밝혔습니다.

플랫폼도 실수합니다. 올해 후반에는 한 연구원이 무료 Lovable 계정으로 다른 사람들의 공개 프로젝트에서 소스 코드, 데이터베이스 자격 증명, AI 채팅 기록을 가져올 수 있음을 보여 주었습니다. Lovable은 처음에는 이 동작이 의도된 설계라고 했습니다. 이후 불분명한 문서를 탓하는 것만으로는 부족했다고 인정하며 "더 잘하겠습니다"라고 밝혔고, 공개 프로젝트의 채팅에 접근할 수 없도록 API를 패치했다고 말했습니다(The Register). 보안 업체 RedAccess는 Lovable, Base44, Replit, Netlify로 만든 앱 중 외부에서 접근 가능한 것이 약 38만 개이고, 그중 약 5,000개가 민감한 데이터를 노출하고 있다고 집계했습니다. Replit의 CEO는 공개 앱에 접근할 수 있는 것은 예상된 동작이며 비공개는 클릭 한 번이면 설정된다고 답했습니다.

연구 결과도 반대편에서 같은 이야기를 합니다. Veracode의 장기 테스트는 더 똑똑해진 모델이 얼마나 도움이 되지 않았는지 보여 줍니다.

Veracode의 2026년 라운드에서 가장 좋은 모델조차 보안 과제 세 건 중 거의 한 건에서 실패하며, 코딩용으로 만든 모델도 범용 모델보다 나을 게 없습니다. 스타트업 Tenzai의 별도 연구에서는 코딩 에이전트 다섯 개로 앱 15개를 만들었고 취약점 69개를 찾았습니다. 가장 심각한 것은 권한 부여와 비즈니스 로직 관련이었고, 고전적인 인젝션 버그는 전혀 나타나지 않았습니다. 사고 사례와도 일치합니다. AI는 동작하는 코드를 쓰지만, 누가 그것을 사용할 수 있어야 하는지는 말해 주지 않는 한 묻지 않습니다.

쉽게 풀어 쓴 행 수준 보안

이런 방식으로 만든 앱은 설계상 공개된 키를 사용해 브라우저에서 곧바로 데이터베이스와 통신하는 경우가 많습니다. 낯선 사람이 그 키로 모든 것을 읽지 못하게 막아 주는 것이 행 수준 보안입니다. 누가 무엇을 읽거나 바꿀 수 있는지를 행 단위로 결정하는, 데이터베이스 안의 규칙입니다. Lovable의 내장 백엔드와 Bolt의 데이터베이스는 모두 Supabase와 같은 모델인 이 Postgres 규칙을 사용합니다.

Supabase 문서는 단호합니다. 노출된 스키마에서 RLS가 없는 테이블은 "권한이 부여된 모든 역할이 읽고 쓸 수 있습니다"(Supabase). RLS를 켜면 정책이 허용하기 전까지는 공개 키로 아무것도 볼 수 없습니다. 정책은 짧습니다. 다음은 빌더가 주문 테이블에 작성해야 하는 종류의 정책으로, 로그인한 각 사용자가 자기 행만 읽도록 허용합니다.

create policy "Users read their own orders"
on orders for select
to authenticated
using ( (select auth.uid()) = user_id );

직접 작성할 필요는 없습니다. 하지만 모든 테이블에 정책이 있는지는 반드시 확인해야 합니다. 비밀 키, 즉 "서비스 롤" 키는 이 규칙을 전부 건너뛰므로 브라우저 코드에 절대 두면 안 됩니다. 그리고 "이 사용자가 관리자인가?" 같은 확인을 포함해 프런트엔드에 있는 것은 무엇이든 사용하는 사람이 수정할 수 있습니다. 그래서 Lovable 문서도 프런트엔드 코드가 보안 판단을 내려서는 안 된다고 말합니다.

단계별 안전한 빌드 과정

이 순서를 따르면 실수의 비용이 낮게 유지됩니다. 마지막 단계 전까지는 가짜 데이터를 쓰고, 실제 사용자는 맨 끝에만 들입니다.

1. 1첫 프롬프트 전에 한 페이지짜리 명세서를 작성하세요. 누가 앱을 쓰는지, 다섯 개나 여섯 개의 화면은 무엇인지, 사용자 유형별로 무엇을 보고 바꿀 수 있는지, 범위 밖은 무엇인지 적습니다. 이를 플랜 모드에 붙여 넣고 도구에게 허점을 찾아 달라고 요청하세요.
2. 2가짜 데이터로 프로토타입을 만드세요. 만들어 낸 기록으로 화면과 흐름을 구성하고, 프로젝트는 비공개로 유지한 채 실제로 쓸 사람들에게 보여 주세요. 방향 전환은 메시지 하나로 끝나는 지금 하는 게 좋습니다.
3. 3데이터 모델을 쉬운 말로 설명하세요. 기록의 종류(고객, 주문, 메모)와 각각의 소유자를 나열하고, 도구에게 테이블을 만들게 한 뒤 테이블마다 누가 행을 읽고 바꿀 수 있는지 설명해 달라고 하세요. 답이 하나라도 "누구나"라면 넘어가기 전에 고치세요.
4. 4회원가입과 권한을 같은 단계에서 추가한 뒤 규칙을 다시 읽어 보세요. 예를 들어 Base44는 "주문을 제출한 사람만 그 주문을 볼 수 있어야 한다"처럼 문장으로 쓴 규칙을 받아들입니다.
5. 5가짜 데이터와 계정 두 개로 테스트하세요. Alice와 Bob으로 각각 가입합니다. Bob으로 Alice의 기록을 열어 보고, 주소창의 기록 번호를 고쳐 보고, 로그아웃한 상태로 앱을 사용해 보세요. 코드가 어떻게 생겼든, Bob이 접근해서는 안 될 것에 접근한다면 그것은 버그입니다.
6. 6보안 점검을 실행하세요. 내장 스캔을 사용하고, 심각한 항목은 모두 고친 뒤 다음 섹션의 체크리스트를 따라가세요. Bolt의 전체 감사는 Publish 메뉴에서 실행하면 토큰이 들지 않습니다. 앱이 고객의 개인 데이터를 다룬다면 이 단계에서 엔지니어가 검토해야 합니다.
7. 7한도를 두고 작게 출시하세요. 먼저 소수의 실제 사용자만 초대하고, 지출 한도를 설정하고, 백업과 롤백이 작동하는지 확인한 뒤, 가짜 계정을 삭제하세요.

아이디어가 어느 단계에 있는지 모르겠나요? 아래 트리는 질문 세 개 이내로 답을 줍니다.

트리가 엔지니어에게 가라고 안내하더라도 프로토타입이 헛수고가 되지는 않습니다. 동작하는 목업과 명세서는 개발자가 받을 수 있는 가장 명확한 요구사항서입니다.

출시 전 보안 체크리스트

테스트 계정 밖의 누군가에게 링크를 주기 전에 이 체크리스트를 실행하세요. 코드를 읽을 필요는 전혀 없습니다. 모든 항목이 확인할 설정, 실행할 스캔, 해볼 테스트 중 하나입니다.

두 항목이 대부분의 역할을 합니다. 모든 테이블에 행 수준 보안을 적용했는지는 빌더의 데이터베이스나 보안 화면에서 확인하며, Bolt는 모두를 들여보내는 "항상 참(always true)" 규칙을 표시해 줍니다. 두 번째 계정 테스트는 위에서 본 Lovable 앱의 거꾸로 된 접근 확인처럼 스캐너가 놓치는 것을 잡아냅니다.

나머지는 금방 끝납니다. Bolt는 유출된 비밀번호 보호를 기본으로 켜 두고, Lovable의 게시 전 스캔은 이 기능이 꺼져 있으면 경고합니다. Lovable에서는 이름이 VITE_ 접두사로 시작하는 것은 무엇이든 브라우저에 노출되므로, 비밀 키에는 절대 이 접두사를 붙이면 안 됩니다.

스캔에는 한계가 있으며, 업체들도 이를 인정합니다. Lovable 문서는 자사 도구가 "완전한 보안을 보장할 수 없다"고 밝히고, 민감한 데이터를 다루는 앱에는 전문가 검토를 권합니다. Base44 문서는 더 짧습니다. 앱의 보안 설정은 사용자의 책임입니다.

프로젝트를 개발자에게 넘기기

잘 돌아가는 바이브 코딩 앱도 조만간 검토나 소유를 위해 엔지니어가 필요해집니다. 인계는 첫날부터 계획하세요.

GitHub 저장소를 일찍 연결하세요. Lovable의 양방향 동기화는 모든 플랜에서 작동하며, 개발자는 저장소를 클론해 자기 에디터에서 계속 작업할 수 있습니다. Base44의 양방향 동기화는 Builder 플랜부터 시작합니다. v0에서는 연결된 저장소가 기준 소스가 되며, v0는 변경 사항을 시작한 브랜치에 바로 올리지 않고 작업 브랜치에 푸시합니다. Bolt도 커밋을 GitHub에 동기화합니다.

코드가 남기고 가지 않는 것을 알아 두세요. Lovable 문서에 따르면 Git 동기화나 코드 다운로드에는 데이터베이스 안의 데이터가 포함되지 않으며, 다른 곳에 호스팅하는 가이드에서는 스토리지 파일을 직접 옮기도록 안내합니다. Base44는 플랫폼에 묶이는 것은 없으며 GitHub 동기화로 전체 소스를 내보낼 수 있다고 말합니다. 개발자 문서에는 내보낸 프로젝트가 데이터와 백엔드 함수를 위해 Base44 자체 서비스에 접근할 때 쓰는 SDK도 설명되어 있습니다. 이것은 Base44의 주장이 아니라 저희의 해석입니다. Base44에서 완전히 옮기려면 그 계층을 교체해야 할 수 있습니다.

개발자에게 짧은 인계 자료를 건네세요.

• 명세서: 모든 화면과 각 화면을 쓸 수 있는 사람.
• 저장소와 빌더 프로젝트에 대한 접근 권한.
• 각 테이블과 누가 읽고 바꿀 수 있어야 하는지를 쉬운 말로 적은 목록.
• 추가한 통합 서비스와 사용하는 시크릿의 이름. 값 자체는 채팅이나 이메일로 절대 보내지 마세요.
• 알려진 버그, 프롬프트로 넣은 이상한 임시방편, 지금까지 프로젝트에 들어간 크레딧 비용.

새 기능에 앞서 접근 규칙, 서버 측 함수, 시크릿이 있는 위치에 대한 보안 검토를 요청하세요. 대부분의 개발자는 Cursor나 Claude Code 같은 코딩 도구로 저장소를 엽니다. 코딩 어시스턴트 총정리와 AI 코딩 어시스턴트 vs 에이전트 빌더에서 이런 도구가 앱 빌더와 어떻게 다른지 설명하고, AI 코딩 어시스턴트 보드에서 전체 순위를 볼 수 있습니다.

자주 묻는 질문

바이브 코딩 도구가 작성한 코드의 소유권은 제게 있나요?

Lovable, Base44, Bolt, v0 모두 사용자가 관리하는 GitHub 저장소로 코드를 동기화하며, Base44는 Builder 플랜부터입니다. 하지만 코드를 소유하는 것과 실행 중인 앱을 소유하는 것은 다릅니다. 데이터, 저장된 파일, 백엔드 서비스는 누군가 이전하기 전까지 플랫폼에 남아 있을 수 있습니다.

어떤 바이브 코딩 도구가 시작하기에 가장 저렴한가요?

다섯 곳 모두 무료 티어가 있습니다. Lovable은 무료 사용자에게 하루 5 빌드 크레딧을 주며 월 최대 30으로 제한되고, Replit의 Free Mode는 무료 및 유료 개인 플랜에서 실행되며 한도는 플랜에 따라 정해집니다. 유료 플랜 중에서는 Base44 Starter가 연간 결제 시 월 $16, Replit Core가 월 $20로 표기되어 있습니다.

바이브 코딩한 앱에서 결제를 받을 수 있나요?

네, 호스팅 결제 페이지를 통해서라면 가능합니다. Lovable의 Stripe 연동은 Stripe Checkout을 열고, 시크릿 키를 앱 코드가 아닌 백엔드 시크릿으로 저장합니다. 먼저 샌드박스 키와 Stripe 테스트 카드로 테스트하세요. 사용량 과금, 다른 사용자에게 보내는 정산금, 다중 회사 계정 과금은 엔지니어의 영역입니다.

AI가 자기 코드의 보안을 스스로 점검할 수 있나요?

부분적으로만 가능합니다. 내장 스캔은 접근 규칙 누락, 노출된 키, 취약한 패키지 같은 흔한 문제를 잡아냅니다. 하지만 업체들도 스캔이 보안을 보장할 수 없다고 말하며, 18,697건의 기록이 유출된 앱도 게시 전 무료 스캔을 제공하는 플랫폼에 있었습니다. 스캔은 최소한의 기준선이지 승인 도장이 아니라고 생각하세요.

Firebase Studio는 어떻게 되었나요?

Google이 종료합니다. 더 이상 새 워크스페이스를 만들 수 없고 2027년에 문을 닫으며, Google은 기존 워크스페이스를 Google AI Studio나 Antigravity로 옮길 수 있다고 안내합니다. Firestore나 Authentication 같은 Firebase 서비스는 이전과 같이 계속됩니다.