Lovable — AI 풀스택 앱 생성기은(는) 무엇을 하나요?
개요
Lovable(lovable.dev)은 브라우저에서 채팅 프롬프트를 통해 웹 앱을 생성하고 편집합니다. 프로젝트는 Tailwind CSS와 shadcn/ui를 사용하며, 2026년 5월 이후 생성된 앱은 TanStack Start(서버 렌더링)를 기반으로 하고, 이전 앱은 React + Vite를 사용합니다. 백엔드로는 Lovable Cloud(Supabase의 오픈소스 스택 기반의 내장 데이터베이스, 인증, 스토리지, 실시간 및 함수 제공) 또는 사용자 소유 Supabase 프로젝트 중 선택할 수 있습니다. 코드는 GitHub와 양방향으로 동기화할 수 있으며, 앱은 lovable URL 또는 커스텀 도메인으로 퍼블리시됩니다. 설치할 것은 없고 CLI도 없습니다. 에이전트는 좋은 프롬프트를 작성하고, 결과물을 검토하며, 동기화된 저장소에서 작업함으로써 도움을 줍니다.
지침
1. 첫 프롬프트 전에 계획하세요
네 가지 질문에 답하세요: 무엇인가, 누가 사용하는가, 왜 사용하는가, 핵심 동작은 무엇인가. 앱을 섹션별로 설명하고 실제 문구를 사용하세요(플레이스홀더 사용 금지). Lovable의 지침: 전체 페이지 프롬프트는 노이즈를 주고, 섹션 기반 프롬프트는 신호를 줍니다. 디자인 방향("미니멀", "프리미엄", "플레이풀")을 지정하여 타이포그래피와 간격을 조정하세요.
2. 백엔드 선택
- 새 프로젝트: Lovable Cloud(기본값) 또는 Supabase. 백엔드가 처음 활성화될 때 선택합니다.
- 기존 Supabase 연결 프로젝트는 계속 작동합니다. Supabase에서 Cloud로의 마이그레이션은 없으며, Cloud에서 자체 Supabase 프로젝트로의 원클릭 이동도 없으므로 초기에 결정하세요.
3. 모드로 작업하기
Lovable에는 Agent 모드(빌드 및 변경)와 Chat 모드(토론, 계획, 편집 없음)가 있습니다. Plan 모드는 메시지당 1크레딧이 소모되며, 일반 편집은 복잡도에 따라 약 0.5-1.7크레딧이 소모됩니다. "빌드 전에 필요한 질문을 모두 해주세요"를 추가하여 명확화 질문을 받으세요. 지속적인 규칙(스택, 네이밍, 톤)은 프로젝트 또는 워크스페이스 지식에 저장하여 채팅 간에 유지되도록 하세요.
4. 보안 검토
생성된 테이블에는 Row Level Security가 있어야 합니다. 각 정책을 읽고, 내장 보안 스캔을 실행하며, 퍼블리시 전에 두 명의 다른 사용자로 테스트하세요.
5. 코드 동기화 및 소유
프로젝트 설정에서 GitHub를 연결하세요. 동기화는 한 번에 하나의 브랜치(기본 브랜치로 설정되지 않은 경우 활성 브랜치)에 대해 양방향으로 이루어집니다. 새 브랜치는 활성 브랜치에서 시작됩니다. Lovable 프로젝트를 GitHub로 내보내기만 가능하며, 기존 저장소를 가져올 수는 없습니다. 10MB를 초과하는 파일은 Lovable이 편집할 수 없습니다. 연결을 해제하면 두 복사본 모두 유지되지만, 다시 연결하면 새 저장소가 생성됩니다.
6. 요금제
무료, Pro, Business 및 Enterprise 요금제가 있으며, 가격은 좌석이 아닌 크레딧 기준입니다. 무료 요금제는 일일 5개의 빌드 크레딧(월 최대 30개)과 소량의 Cloud 크레딧을 포함합니다. 현재 가격은 lovable.dev/pricing을 확인하세요.
예시
예시 1: 추천이 포함된 대기자 명단 앱
요청: "Lovable을 사용하여 SaaS 대기자 명단을 구축하세요: 카운터가 있는 가입 양식, 추천 링크, 리더보드 및 관리자 페이지."
붙여넣을 프롬프트:
Etsy 판매자를 위한 배송 라벨 도구 "Parcelly"의 대기자 명단 사이트를 구축하세요.
섹션: 히어로 ("10초 만에 라벨 인쇄")와 이메일 양식 및 실시간 가입 카운터;
상위 10명의 추천인 리더보드; 이메일 로그인 뒤에 있는 /admin 페이지로 가입 목록 및 CSV 내보내기.
모든 가입자는 고유 추천 링크(?ref=code)를 받아 추천인에게 크레딧을 부여합니다.
스타일: 미니멀, 다크 모드. 데이터 및 인증에는 Lovable Cloud를 사용하세요.
빌드 전에 필요한 질문을 모두 해주세요.
결과: Lovable이 초대 이메일에 대해 질문한 후, 페이지와 signups 테이블 및 정책, 그리고 미리보기 URL을 생성합니다. 생성된 정책과 비교할 합리적인 테이블 및 정책 세트:
create table public.signups (
id uuid primary key default gen_random_uuid(),
email text not null unique,
referral_code text not null unique default encode(gen_random_bytes(6), 'hex'),
referred_by uuid references public.signups(id),
created_at timestamptz not null default now()
);
alter table public.signups enable row level security;
create policy "anyone can join" on public.signups for insert to anon with check (true);
-- 모든 행을 읽는 것은 관리자로 제한되어야 합니다(예: user_roles 테이블 사용).
예시 2: 반복 및 GitHub에 동기화
요청: "시간별 가입 수 차트를 추가한 다음, Cursor에서 계속 작업할 수 있도록 코드를 내 저장소로 가져오세요."
채팅 프롬프트: "/admin에 기존 데이터를 사용하여 일별 가입 수 선 차트를 추가하세요. 가입이 없으면 빈 상태를 표시하세요." 그런 다음: 프로젝트 설정, GitHub, 연결, 계정 선택 및 저장소 생성. 이후:
git clone [email protected]:parcelly-dev/parcelly-waitlist.git
cd parcelly-waitlist && npm install && npm run dev
동기화된 브랜치에 푸시하면 Lovable에 나타납니다. 로컬 편집은 해당 브랜치에서 유지하거나(또는 프로젝트 설정에서 브랜치 전환).
가이드라인
- 모든 핵심 기능을 첫 번째 프롬프트에 넣고, 이후에는 한 번에 하나씩 변경하여 버전 기록이 유용하게 유지되도록 하세요. 작업 중인 버전은 북마크하세요.
- API 키를 채팅에 붙여넣지 말고, 시크릿/통합 대화상자를 사용하세요. 서버 측 키는 백엔드 함수에 속하며, 클라이언트 코드에 절대 넣지 마세요.
- 생성된 RLS를 맹신하지 마세요.
insert ... with check (true)정책은 공개 양식에 적합하지만,select정책은 그렇지 않습니다. - 크레딧은 빌드, 호스팅 및 AI 기능에 사용되며 환불되지 않습니다. 질문이 있을 때는 Chat/Plan 모드를 선호하세요.
- 네이티브 모바일 앱, 대규모 커스텀 백엔드 또는 복잡한 기존 모노레포에는 적합하지 않습니다. 대신 저장소 내에서 코딩 에이전트를 사용하세요.