지난달 저는 Lovable을 사용하여 이틀 만에 완전한 웹 제품을 출시했습니다. 단순한 랜딩 페이지가 아닙니다. 인증 (auth), 데이터베이스 (database), 결제 (payments), 그리고 템플릿처럼 보이지 않는 커스텀 UI를 갖춘 작동하는 앱입니다.

이 포스트는 Vibecoding 세션이 잘 풀릴 때 정확히 어떻게 진행되는지 — 프롬프트 (prompts), 반복 루프 (iteration loop), 실수, 그리고 실제로 시간을 절약해 주는 지름길들을 분석합니다.

Vibecoding의 실제 의미

Vibecoding은 자연어 (natural language)로 원하는 것을 설명하고 AI 도구가 코드를 생성하게 함으로써 소프트웨어를 구축하는 것입니다. Lovable은 이러한 도구 중 하나로, 대화를 통해 전체 React + Supabase 앱을 생성합니다.

하지만 함정이 있습니다. 결과물의 품질은 대화를 어떻게 시작하느냐에 거의 전적으로 달려 있습니다.

초기 프롬프트 (init prompt)가 전부다

대부분의 사람들은 Lovable을 열고 "퀴즈 앱을 만들어줘"와 같은 식으로 입력합니다. 그러면 일반적인 퀴즈 앱이 나옵니다. 개성도 없고, 비즈니스 로직 (business logic)도 없으며, 차별점도 없습니다.

실제로 효과가 있는 방법은 다음과 같습니다. 첫 번째 프롬프트에는 네 가지 요소가 필요합니다:

1. 분위기 (The vibe). 단순히 "퀴즈 앱"이 아니라 정서적인 경험을 말합니다. "2000년대 초반 잡지 퀴즈 같은 느낌의 성격 테스트 — 장난스럽고 약간은 불손하며, 대담한 타이포그래피 (typography)와 예상치 못한 색상 선택을 가진 스타일."

2. 타겟 오디언스 (The audience). 누가 이것을 사용하는가? "Instagram Stories에 결과를 공유하는 25-35세 여성." 이는 레이아웃 결정, 글꼴 크기, 공유 버튼 배치 등을 변화시킵니다.

3. UX 흐름 (The UX flow). 화면 구성을 설명하세요. "랜딩 페이지 → 퀴즈 유형 선택 → 진행 바가 있는 12개 질문 → 애니메이션 결과 → 공유 카드 → 선택적 이메일 수집." 화면 전환을 운에 맡기지 마세요.

4. 비즈니스 모델 (The business model). "무료 퀴즈, 상세 결과 확인 시 이메일 입력 단계(email gate), 4.99달러의 프리미엄 퀴즈 팩 업셀 (upsell)." AI가 돈의 흐름을 알게 되면, 그에 맞춰 데이터베이스와 UI를 구조화합니다.

단 하나의 프롬프트. 네 가지 차원. 이것이 주말 프로젝트와 실제로 사용자에게 보여줄 수 있는 결과물의 차이를 만듭니다.

반복 루프 (The iteration loop)

초기 프롬프트 (init prompt) 이후, Lovable은 첫 번째 버전을 생성합니다. 그것이 결코 완벽할 리 없습니다. 괜찮습니다. 진짜 기술은 얼마나 빠르게 반복 (iterate) 하느냐에 달려 있습니다.

저의 루프는 다음과 같습니다:

생성 (Generate) → 미리보기 (Preview) → 한 가지 수정 (Fix one thing) → 반복 (Repeat).

핵심 단어는 "한 가지"입니다. 한 번의 프롬프트로 다섯 가지 문제를 해결하려고 하면, Lovable은 종종 잘 작동하던 다른 부분을 망가뜨리곤 합니다. 작고 타겟팅된 수정 사항들이 빠르게 복리로 쌓입니다.

지난 빌드에서 사용한 전형적인 반복 프롬프트 예시입니다:

• "모바일에서 CTA 버튼을 어보브 더 폴드 (above the fold) 위치로 옮겨줘."
• "뒤로 가기를 할 때 프로그레스 바 (progress bar)가 초기화돼. 네비게이션 시 상태 (state)를 유지해줘."
• "결과 카드에 미세한 등장 애니메이션을 추가해줘. 극적인 건 말고, 그냥 페이드 업 (fade-up) 정도로."

이 각각의 프롬프트는 생성하는 데 30초도 걸리지 않았습니다. 첫 렌더링부터 사용자에게 보여줄 수 있는 수준에 이르기까지 전체 반복 사이클은 두 세션에 걸쳐 약 4시간 정도 소요되었습니다.

내가 계속 빠지는 다섯 가지 함정

이 방식으로 16개의 제품을 출시한 후에도, 저는 여전히 똑같은 문제들에 부딪힙니다:

1. 중복 라우팅 (Duplicate routing). Lovable은 가끔 동일한 페이지에 대해 두 개의 라우트 정의를 생성합니다. 배포하기 전까지는 모든 것이 잘 작동하다가, 배포 후 한쪽 경로에서 404 에러가 발생합니다. 게시하기 전에 항상 라우터 설정 (router config)을 확인하세요.

2. 하드코딩된 문구 (Hardcoded copy). 기능을 영어로 설명하면, AI는 모든 곳에 영어 문자열을 하드코딩합니다. 나중에 현지화 (localization)가 필요해지면 몇 시간 동안 리팩토링 (refactoring)을 해야 합니다. 초기 프롬프트에 대상 언어를 명시하세요.

3. 인증 예외 케이스 (Auth edge cases). 생성된 인증 (auth) 흐름은 해피 패스 (happy path)만 처리합니다. 토큰 만료, 이메일 미확인, 또는 OAuth 제공자 오류 등을 우아하게 처리하는 경우는 드뭅니다. 인증 예외 케이스만을 위한 반복 사이클을 하나 따로 할당하세요.

4. 공개 Supabase 버킷 (Public Supabase buckets). Lovable은 기본적으로 공개 스토리지 버킷을 사용합니다. 사용자가 개인적인 정보(사진, 문서 등)를 업로드한다면, 서명된 URL (signed URLs)을 사용하는 프라이빗 버킷으로 전환해야 합니다. 이것은 편의성의 문제가 아니라 보안 문제입니다. Audit Vibe Coding과 같은 도구를 사용하면 이러한 문제를 자동으로 찾아낼 수 있습니다.

5. 누락된 행 수준 보안 (Row Level Security, RLS). 데이터베이스 테이블은 생성되지만, RLS 정책이 너무 허용적(permissive)이거나 아예 누락되는 경우가 많습니다. 어떤 사용자든 다른 사용자의 데이터를 읽을 수 있게 됩니다. 이는 Vibe Coding으로 제작된 앱에서 발생하는 가장 흔한 보안 허점입니다. 정책을 확인하세요. 더 좋은 방법은 자동 스캔을 실행하는 것입니다.

실제로 도움이 되는 지름길 (Shortcuts)

@-reference를 통한 다른 프로젝트 참조. Lovable에서는 다른 프로젝트를 컨텍스트(context)로 참조할 수 있습니다. 이미 유사한 제품을 만들었다면, AI가 해당 프로젝트를 참조하도록 지정하세요. "@pet-imagination의 인증 흐름(auth flow)을 사용하되, @party-challenges의 색상 체계를 적용해줘."라고 요청하면 전체 반복 주기(iteration cycle)를 단축할 수 있습니다.

Knowledge 기능을 사용하세요. 디자인 시스템, 브랜드 가이드라인, 또는 일치시키고자 하는 UI의 스크린샷을 업로드하세요. Lovable은 이를 컨텍스트로 읽어 들여, 첫 번째 생성 결과물이 사용자가 필요로 하는 것에 훨씬 더 가깝게 만들어 줍니다.

픽셀 단위 조정을 위한 시각적 편집 (Visual Edit) 모드. 간격을 말로 설명하지 마세요. 요소를 직접 클릭하고 드래그하세요. Lovable은 시각적 편집을 코드 변경 사항으로 변환합니다. 레이아웃 작업에는 어떤 프롬프트보다 이 방식이 더 빠릅니다.

조기에 배포하고 프로덕션 환경에서 반복(iterate)하세요. 모든 것이 완벽해질 때까지 기다리지 마세요. 첫 번째 작동하는 버전이 나오면 바로 게시하세요. 실제 사용자는 당신이 상상도 못 했던 문제들을 찾아냅니다. 그리고 제품이 라이브 상태인 것을 보는 것은 당신의 우선순위를 즉각적으로 변화시킵니다.

실제 비용

집중적인 작업 2일. 디자이너 없음, 백엔드 개발자 없음, DevOps 없음. Lovable이 호스팅을 처리합니다. Supabase가 데이터베이스와 인증(auth)을 처리합니다. 실제 사용자를 서비스하는 제품 기준 총 인프라 비용은 월 약 $25 정도입니다.

트레이드오프(trade-off)는 명확합니다. 속도를 얻는 대신 코드 아키텍처(code architecture)에 대한 통제력을 잃게 됩니다. 생성된 코드는 기능적이지만 아름답지는 않습니다. 제품이 궤도에 오르면 결국 일부를 리팩터링(refactor)하고 싶어질 것입니다. 하지만 그때쯤이면 당신은 사용자, 매출 데이터, 그리고 다음에 무엇을 만들어야 할지에 대한 훨씬 더 나은 이해를 갖추게 될 것입니다.

아무도 말하지 않는 보안 격차

속도는 위험을 동반합니다. 이틀 만에 제품을 출시할 때는 전통적인 개발 주기(dev cycle)에 포함되는 보안 검토를 건너뛰게 됩니다. RLS(Row Level Security) 정책, 스토리지 권한, API 노출 — 이러한 요소들이 놓치기 쉽습니다.

저는 바로 이 문제를 해결하기 위해 Audit Vibe Coding을 구축했습니다. 이 도구는 Lovable 및 Supabase 프로젝트를 스캔하여, 바이브코딩(vibecoding)으로 제작된 앱들이 출시될 때 흔히 저지르는 가장 일반적인 보안 실수들을 찾아냅니다. 공개된 스토리지 버킷(storage buckets), 누락된 RLS, 노출된 API 키, 허용 범위가 너무 넓은 CORS — 이러한 것들은 앱을 망가뜨리지는 않지만, 사용자의 데이터를 노출시킵니다.

만약 Lovable, Cursor 또는 그 어떤 AI 코딩 도구를 사용하여 빠르게 제품을 출시하고 있다면, 보안 점검은 선택 사항이 아닙니다. 이는 서비스를 라이브로 전환하기 전에 수행해야 할 최소한의 책임 있는 행동입니다.

리소스 (Resources)

• Vibe Codéři — 튜토리얼과 사례 연구를 제공하는 체코의 바이브코딩 커뮤니티 (체코어)
• Audit Vibe Coding — AI로 구축된 앱을 위한 자동화된 보안 스캐너
• Inithouse — 이러한 실험들의 배경이 되는 포트폴리오

이런 방식으로 제품을 만드는 것은 소프트웨어에 대한 저의 생각을 바꾸어 놓았습니다. 이제 병목 현상은 더 이상 코드가 아닙니다. 무엇을 만들지 아는 것, 그리고 준비가 완벽하다고 느껴지기 전에 출시할 수 있는 절제력을 갖추는 것이 핵심입니다.