기대치를 제대로 맞추면 러버블은 훨씬 강력해진다
러버블을 처음 열면 묘한 흥분이 생깁니다. "프리랜서 포트폴리오 사이트를 만들어줘." "상담 신청을 받는 랜딩 페이지를 만들어줘." "고객 문의를 저장하는 간단한 웹앱을 만들어줘." 이렇게 말했을 뿐인데 화면이 생기고, 버튼이 생기고, 페이지가 연결됩니다. 코딩을 몰라도 무언가가 만들어지는 경험은 분명히 짜릿합니다.
하지만 여기서 한 가지를 먼저 정해야 합니다. 러버블을 최종 개발자 대체재로 볼 것인지, 아니면 첫 70%를 빠르게 만들어주는 제작 파트너로 볼 것인지입니다.
이 책에서는 두 번째 관점을 권합니다. 러버블은 아이디어를 눈에 보이는 결과물로 바꾸는 속도가 매우 빠릅니다. 특히 개인 사업자, 프리랜서, 1인 창업자, 토이 프로젝트를 부업으로 키우려는 사람에게는 "일단 보여줄 수 있는 웹페이지"를 만드는 데 큰 힘이 됩니다. 그러나 결제, 권한, 복잡한 데이터 처리, 외부 서비스 연동, 보안, 장기 유지보수까지 모두 맡기기에는 조심해야 할 부분이 많습니다.
좋은 도구는 "무엇을 할 수 있는지"보다 "어디서 멈춰야 하는지"를 알고 쓸 때 빛납니다. 망치가 좋다고 해서 모든 것을 망치로 두드리면 안 되듯, 러버블도 잘 맞는 일이 있고, 억지로 맡기면 크레딧과 시간을 함께 잃는 일이 있습니다.
이 장의 목표는 러버블을 겁주려는 것이 아닙니다. 오히려 반대입니다. 러버블을 오래, 싸게, 효과적으로 쓰기 위해 먼저 현실적인 지도를 펼쳐보려는 것입니다.
러버블이 특히 잘하는 일
러버블의 가장 큰 장점은 "시작 비용"을 낮춰준다는 데 있습니다. 여기서 비용은 돈만 뜻하지 않습니다. 설치 비용, 학습 비용, 시행착오 비용, 개발자를 구해야 하는 부담, 첫 화면을 만들기까지의 심리적 장벽까지 모두 포함합니다.
기존 방식에서는 웹사이트 하나를 만들기 위해 도메인, 호스팅, 화면 설계, 프론트엔드, 백엔드, 배포 같은 단어를 줄줄이 만나야 했습니다. 초보자에게는 용어부터 벽입니다. 그런데 러버블에서는 원하는 결과를 문장으로 설명하고, AI가 기본 구조를 만들어줍니다. 공식 가격 페이지에서도 요금제에 따라 커스텀 도메인, 배지 제거, 역할과 권한 같은 기능을 제공한다고 안내합니다.1 다만 GitHub 연동이나 코드 내보내기처럼 개발 워크플로우와 관련된 기능은 가격표 한 줄만 보고 판단하기보다, 공식 문서와 프로젝트 설정에서 현재 제공 범위를 함께 확인하는 편이 안전합니다.
초보자 입장에서 체감되는 실전 장점은 크게 다섯 가지입니다.
빠른 MVP 제작
보기 좋은 기본 UI 생성
원클릭 배포
GitHub 연동 또는 코드 내보내기를 통한 백업·협업 가능성
Supabase 연동을 통한 데이터베이스와 로그인 기능 확장
여기서 MVP는 Minimum Viable Product, 즉 "최소 기능 제품"이라는 뜻입니다. 완벽한 서비스가 아니라, 사람들이 실제로 눌러보고 반응할 수 있는 최소한의 버전입니다. 프리랜서라면 "내 소개, 작업물, 가격 안내, 문의 폼"만 있어도 MVP가 될 수 있습니다. 상담형 사업자라면 "서비스 설명, 고객 후기, 예약 신청 폼"만 있어도 충분히 첫 테스트를 할 수 있습니다.
러버블의 강점은 바로 이 MVP 단계에서 크게 드러납니다. 머릿속에만 있던 아이디어를 몇 시간 안에 클릭 가능한 화면으로 바꿔줍니다. 완성품은 아니어도, 사람에게 보여주고 피드백을 받을 수 있는 상태가 됩니다. 부업을 시작할 때 가장 위험한 것은 '아무것도 공개하지 않은 채 혼자 완벽한 계획만 세우는 것'입니다. 러버블은 그 시간을 줄여줍니다.
개인 사업자와 프리랜서에게 특히 유리한 이유
개인 사업자나 프리랜서에게 웹페이지는 단순한 명함이 아닙니다. 웹페이지는 24시간 일하는 영업사원입니다. 내가 자고 있을 때도 누군가 내 서비스를 읽고, 가격을 확인하고, 문의를 보낼 수 있습니다. 문제는 그 영업사원을 만드는 일이 생각보다 부담스럽다는 데 있습니다.
디자이너에게 맡기자니 비용이 들고, 개발자에게 맡기자니 요구사항을 설명하는 것부터 어렵습니다. 직접 만들자니 코딩은 멀게 느껴집니다. 그래서 많은 사람이 인스타그램 프로필 링크 하나, 블로그 글 몇 개, 노션 페이지 하나로 버팁니다. 물론 그것도 시작으로는 좋습니다. 하지만 서비스를 판매하려면 결국 "내 제안이 정리된 한 페이지"가 필요합니다.
러버블은 이런 상황에서 빠르게 초안을 만들어줍니다. 예를 들어 다음과 같은 웹페이지는 러버블과 궁합이 좋습니다.
프리랜서 포트폴리오와 문의 페이지
예약·상담 신청 랜딩 페이지
견적 요청과 리드 수집 페이지
전자책, 강의, 템플릿 같은 디지털 상품 판매 안내 페이지
소규모 고객 관리나 신청자 목록을 보는 간단한 내부 대시보드
이런 페이지들은 처음부터 복잡한 기술이 필요하지 않습니다. 핵심은 "누가, 왜, 무엇을 보고, 어떤 행동을 해야 하는가"입니다. 러버블은 이 구조가 명확할수록 좋은 결과를 냅니다.
예를 들어 "예쁜 홈페이지 만들어줘"라고 하면 러버블은 대충 그럴듯한 페이지를 만들 수는 있습니다. 하지만 "1인 세무 상담 서비스를 위한 랜딩 페이지를 만들어줘. 방문자는 프리랜서이고, 목적은 무료 상담 신청이야. 섹션은 문제 제기, 서비스 소개, 상담 절차, 가격, 후기, FAQ, 신청 폼 순서로 구성해줘"라고 하면 결과가 훨씬 좋아집니다.
도구의 성능보다 중요한 것은 내가 얼마나 분명히 요청하느냐입니다.
보기 좋은 UI를 빠르게 뽑아주는 힘
러버블의 첫인상이 좋은 이유 중 하나는 기본 UI가 꽤 그럴듯하게 나온다는 점입니다. UI는 User Interface, 즉 사용자가 보는 화면과 버튼, 입력창, 메뉴 같은 요소를 말합니다. 초보자는 기능보다 화면에서 먼저 자신감을 얻습니다. 화면이 예쁘면 "어, 진짜 뭔가 만들어지고 있네?"라는 느낌이 듭니다.
러버블은 React, Tailwind CSS, Supabase 같은 현대적인 웹 개발 도구와 연결되는 방식으로 자주 설명됩니다. React는 웹 화면을 구성하는 기술이고, Tailwind CSS는 디자인 스타일을 빠르게 적용하는 도구입니다. Supabase는 로그인, 데이터베이스, 파일 저장 같은 백엔드 기능을 쉽게 붙일 수 있게 해주는 서비스입니다. 지금 이 기술 이름을 외울 필요는 없습니다. 다만 러버블이 단순히 그림만 그리는 도구가 아니라, 실제 코드와 데이터 구조를 함께 생성하는 방향의 도구라는 점은 알아두면 좋습니다.
이 장점은 프리랜서나 개인 사업자에게 꽤 실용적입니다. 고객에게 보여줄 시안, 강의 상세 페이지, 이벤트 모집 페이지, 무료 자료 신청 페이지를 만들 때 처음부터 흰 화면을 마주하지 않아도 됩니다. 러버블이 첫 레이아웃을 만들어주면, 우리는 문구와 흐름을 다듬는 데 집중할 수 있습니다.
단, "보기 좋은 화면"과 "전환이 잘 되는 화면"은 다릅니다. 전환이란 방문자가 내가 원하는 행동을 하는 것입니다. 예를 들어 문의하기 버튼을 누르거나, 상담 신청서를 제출하거나, 이메일을 남기는 행동입니다. 러버블이 예쁜 화면을 만들어줘도, 내 고객이 무엇을 망설이는지, 어떤 문장이 설득력 있는지, 어떤 순서로 정보를 보여줘야 하는지는 사람이 판단해야 합니다.
그러니 러버블이 만든 UI를 그대로 믿기보다, 이렇게 질문해보세요.
첫 화면만 보고 내가 무엇을 파는지 알 수 있는가?
방문자가 다음에 무엇을 눌러야 하는지 분명한가?
가격, 절차, 문의 방법처럼 구매 전에 궁금한 내용이 빠지지 않았는가?
모바일 화면에서도 읽기 편한가?
신뢰를 줄 수 있는 후기, 사례, 프로필, 자격 정보가 있는가?
이 질문에 답하면서 다듬으면 러버블의 기본 UI는 훌륭한 출발점이 됩니다.
원클릭 배포가 주는 심리적 효과
초보자에게 배포는 무서운 단어입니다. 배포란 내가 만든 웹페이지를 인터넷 주소로 접속할 수 있게 공개하는 일입니다. 개발을 조금이라도 배워본 사람은 배포에서 많이 막힙니다. "로컬에서는 되는데 왜 인터넷에서는 안 되지?"라는 말은 개발자 세계의 오래된 농담이자 현실입니다.
러버블의 장점은 이 배포 과정을 크게 단순화한다는 데 있습니다. 프로젝트를 만들고, 미리보기로 확인하고, 클릭 몇 번으로 공개 주소를 만들 수 있습니다. 공식 요금 페이지에서도 무료 사용자는 lovable.app 도메인 기반으로 시작할 수 있고, 유료 요금제에서는 커스텀 도메인 연결이나 러버블 배지 제거 같은 기능을 사용할 수 있다고 안내합니다.1
개인 사업자에게 이 기능은 단순한 편의 기능이 아닙니다. "오늘 만든 것을 오늘 공유할 수 있다"는 뜻입니다.
예를 들어 오전에 상담 페이지를 만들고, 오후에 인스타그램 스토리에 링크를 올릴 수 있습니다. 지인에게 보내 피드백을 받을 수도 있습니다. 잠재 고객에게 "이 페이지에서 신청해 주세요"라고 말할 수도 있습니다. 완벽하지 않아도 실제 반응을 얻을 수 있다는 것이 중요합니다.
부업과 토이 프로젝트에서 가장 큰 적은 완벽주의입니다. 완벽해질 때까지 공개하지 않으면 아무 데이터도 얻지 못합니다. 러버블의 원클릭 배포는 완벽주의를 조금 무너뜨려줍니다. 일단 공개하고, 반응을 보고, 고치게 만듭니다.
GitHub 연동은 초보자에게도 보험이다
GitHub는 개발자들이 코드를 저장하고 버전을 관리하는 서비스입니다. 초보자에게는 낯설지만, 러버블을 쓴다면 GitHub 연동이나 코드 내보내기를 "보험" 정도로 이해하면 됩니다. 내가 만든 프로젝트의 코드가 한곳에 저장되고, 나중에 다른 개발자나 도구와 이어서 작업할 수 있는 길이 생깁니다.
러버블을 쓰다 보면 언젠가 이런 순간이 옵니다. "이제 여기서 더 고치기 어렵다." "AI가 계속 같은 문제를 반복한다." "개발자에게 맡겨야겠다." 이때 GitHub에 코드가 정리되어 있으면 다음 단계로 넘어가기가 훨씬 쉽습니다. 여러 리뷰에서도 러버블의 GitHub 연동과 코드 소유는 중요한 장점으로 언급됩니다. 러버블이 만든 결과물을 플랫폼 안에만 가둬두지 않고, 이후 다른 개발 환경에서 이어갈 수 있다는 점은 장기적으로 큰 의미가 있습니다.2
물론 GitHub를 연결했다고 해서 모든 문제가 자동으로 해결되는 것은 아닙니다. 초보자가 직접 코드를 이해하기는 여전히 어렵습니다. 하지만 적어도 프로젝트를 "꺼내갈 수 있는 상태"로 만들어두는 것은 중요합니다.
이 책의 뒤쪽 장에서는 배포와 확장 도구를 다룰 때 GitHub를 다시 만나게 될 것입니다. 지금은 이렇게만 기억해도 충분합니다. 러버블에서 조금이라도 진지하게 만든 프로젝트라면, 가능한 한 이른 시점에 GitHub 연동이나 코드 백업 방식을 고려하세요. 특히 고객에게 보여줄 페이지, 실제 문의를 받을 페이지, 나중에 유료 서비스로 키울 가능성이 있는 프로젝트라면 더욱 그렇습니다.
Supabase 연동은 데이터가 필요한 순간 빛난다
정적인 웹페이지는 정보를 보여주기만 합니다. 예를 들어 자기소개, 서비스 설명, 가격 안내, FAQ 같은 페이지입니다. 하지만 사업형 웹사이트는 어느 순간 데이터를 받아야 합니다. 방문자가 이름과 이메일을 남기고, 상담 내용을 작성하고, 예약 시간을 선택하고, 관리자가 그 목록을 확인해야 합니다.
이때 필요한 것이 백엔드입니다. 백엔드는 화면 뒤에서 데이터를 저장하고 불러오고 처리하는 부분입니다. 초보자에게 백엔드는 매우 어렵게 느껴집니다. 데이터베이스, 인증, 서버, API 같은 단어가 한꺼번에 등장하기 때문입니다.
러버블은 Supabase와의 연동을 통해 이런 백엔드 기능을 비교적 쉽게 시작할 수 있게 해줍니다. Supabase는 데이터베이스, 로그인, 파일 저장 같은 기능을 제공하는 서비스입니다. 러버블에서 "문의 폼 제출 내용을 저장해줘" "사용자 로그인 기능을 추가해줘" 같은 요청을 하면 Supabase와 연결된 구조를 만들어줄 수 있습니다.
이 장점은 사업형 프로젝트에서 꽤 큽니다. 단순한 랜딩 페이지를 넘어 "신청을 받고 관리하는 작은 시스템"으로 확장할 수 있기 때문입니다. 예를 들어 상담 신청 페이지를 만든 뒤, 신청자 목록을 관리자 페이지에서 볼 수 있게 만들 수 있습니다. 견적 요청 폼을 만든 뒤, 고객별 상태를 "신규 문의, 상담 완료, 견적 발송, 계약 완료"처럼 관리하게 할 수도 있습니다.
하지만 Supabase 연동은 동시에 제약이 되기도 합니다. 러버블이 Supabase와 잘 맞는 방식으로 프로젝트를 만드는 만큼, 더 복잡한 백엔드 구조나 다른 시스템으로의 이전이 필요해질 때는 어려움이 생길 수 있습니다. 여러 실사용 리뷰에서도 Supabase 기반 백엔드가 빠른 시작에는 강점이지만, 복잡한 권한, 대규모 확장, 세밀한 인프라 제어가 필요한 상황에서는 병목이 될 수 있다고 지적합니다.3
그래서 초보자는 이렇게 생각하는 것이 좋습니다. Supabase는 처음 데이터를 저장하고 로그인 기능을 붙이는 데 아주 좋은 사다리입니다. 다만 그 사다리 위에 거대한 빌딩을 계속 올릴 수 있다고 가정해서는 안 됩니다.
작은 수정은 Visual Editor와 선택 편집으로 끝내기
무료 사용자에게 가장 아까운 것은 크레딧입니다. 그런데 많은 초보자가 정말 사소한 수정에도 프롬프트를 씁니다.
"버튼을 조금 더 크게 해줘."
"제목 색을 파란색으로 바꿔줘."
"이 문구를 다른 말로 바꿔줘."
이런 요청은 하나하나 보면 작아 보이지만, 반복되면 크레딧을 갉아먹습니다. 특히 무료 사용자라면 하루에 쓸 수 있는 크레딧이 제한되어 있기 때문에, 작은 디자인 수정에 프롬프트를 낭비하면 정작 중요한 기능을 만들 때 멈추게 됩니다.
이때 활용해야 하는 것이 Visual Editor와 선택 편집 방식입니다. Visual Editor는 화면에서 요소를 직접 보고 고치는 방식의 편집 기능입니다. 문서 편집기에서 글자를 클릭해 고치듯, 버튼이나 텍스트 같은 화면 요소를 눈으로 확인하면서 수정할 수 있습니다. 여러 가이드에서도 작은 UI 변경은 AI에게 새로 설명하기보다 선택 도구나 시각 편집 기능을 활용해 수정 범위를 명확히 하는 편이 좋다고 조언합니다.4
핵심은 이렇습니다. AI에게 말로 모든 것을 맡기지 말고, 내가 직접 할 수 있는 작은 변경은 직접 하세요.
예를 들어 다음과 같은 수정은 가능하면 Visual Editor나 선택 편집으로 해결하는 것이 좋습니다.
버튼 문구 변경
제목과 설명 문장 수정
색상, 여백, 폰트 크기 같은 가벼운 디자인 조정
특정 카드나 버튼의 스타일만 바꾸기
이미지 교체나 기존 이미지 URL 변경
반대로 다음 작업은 프롬프트로 요청하는 편이 안전합니다.
새 섹션 추가 또는 기존 섹션 삭제
섹션 순서 변경
새로운 페이지나 컴포넌트 생성
폼 항목 추가와 제출 동작 변경
데이터 저장, 로그인, API, 결제 같은 기능 변경
Visual Editor가 모든 것을 해결하는 도구는 아닙니다. 기능 로직이 바뀌거나, 데이터 저장 방식이 바뀌거나, 새로운 페이지 구조가 필요한 경우에는 프롬프트가 필요합니다. 하지만 문구와 디자인의 작은 조정까지 매번 AI에게 맡기면, 러버블은 편리한 도구가 아니라 비싼 자동 수정기가 됩니다.
이 책에서 계속 강조할 원칙이 있습니다.
프롬프트는 구조와 기능에 쓰고, 작은 디자인 수정은 직접 한다.
이 원칙 하나만 지켜도 무료 크레딧의 체감 사용량이 크게 달라집니다.
프롬프트 반복이 길어질수록 위험해지는 이유
러버블을 쓰다 보면 처음에는 모든 것이 잘 풀리는 것처럼 보입니다. 첫 프롬프트로 페이지가 생깁니다. 두 번째 프롬프트로 버튼이 생깁니다. 세 번째 프롬프트로 폼이 생깁니다. 그런데 어느 순간부터 이상한 일이 벌어집니다.
"분명히 아까 고친 부분이 다시 원래대로 돌아갔는데?"
"문의 폼만 고쳐달라고 했는데 헤더 디자인이 바뀌었네?"
"로그인 오류를 고치라고 했더니 다른 페이지가 깨졌네?"
이런 현상을 회귀 버그라고 부릅니다. 회귀 버그는 예전에 잘 되던 기능이 새 수정 이후 다시 고장 나는 문제입니다. 개발 세계에서는 흔한 일이지만, AI 기반 개발에서는 초보자가 더 자주 당황합니다. AI가 자신 있게 "수정했습니다"라고 말했는데 실제로는 문제가 남아 있거나, 다른 곳을 건드렸을 수 있기 때문입니다.
왜 이런 일이 생길까요? 러버블이 무능해서라기보다, 프로젝트가 커질수록 AI가 고려해야 할 맥락이 복잡해지기 때문입니다. 웹앱은 여러 파일과 컴포넌트가 서로 연결되어 있습니다. 버튼 하나가 단순한 버튼이 아니라, 데이터 저장, 화면 전환, 로그인 상태, 알림 메시지와 연결되어 있을 수 있습니다. 이 상태에서 "이 부분 좀 고쳐줘"라고만 말하면 AI가 의도와 다르게 넓은 범위를 수정할 수 있습니다.
실사용 리뷰들에서도 러버블은 빠른 프로토타입 제작에는 강하지만, 프로젝트가 복잡해질수록 디버깅 루프, 엉뚱한 수정, 코드 복잡도 증가가 문제가 될 수 있다고 지적합니다.5 특히 같은 문제를 여러 번 고치게 되는 상황에서는 크레딧이 빠르게 줄어들고, 사용자는 "진전 없이 돈만 쓰는 느낌"을 받게 됩니다.
초보자는 이 지점에서 무작정 더 많은 프롬프트를 던지기 쉽습니다.
"다시 고쳐줘."
"아니야, 아직 안 돼."
"제대로 확인하고 수정해."
"전체를 다시 점검해."
이런 식의 프롬프트는 감정적으로는 시원하지만, 크레딧 절약에는 좋지 않습니다. 더 큰 문제는 AI가 이전 수정 위에 또 다른 수정을 덮어씌우면서 코드가 점점 복잡해질 수 있다는 점입니다.
프롬프트 반복이 세 번 이상 이어진다면 잠시 멈춰야 합니다. 계속 달리는 것이 아니라, 지금 내가 무엇을 고치려는지 다시 적어야 합니다. 가능하면 오류 메시지, 발생 조건, 기대 동작, 실제 동작을 분리해 설명해야 합니다. 그래도 해결되지 않으면 프로젝트를 복제해 실험하거나, GitHub로 내보내 다른 도구나 개발자의 도움을 받는 편이 낫습니다.
러버블은 대화형 도구지만, 긴 말싸움에 강한 도구는 아닙니다. 좋은 사용자는 AI를 설득하려고 하지 않고, 문제를 작게 잘라서 전달합니다.
복잡한 상태 관리가 초보자를 막는 순간
상태 관리는 웹앱이 "현재 무엇을 기억하고 있는가"를 다루는 일입니다. 예를 들어 사용자가 로그인했는지, 장바구니에 무엇이 들어 있는지, 신청 폼의 몇 단계까지 작성했는지, 관리자가 어떤 필터를 선택했는지 같은 정보가 상태입니다.
처음에는 상태가 단순합니다. 버튼을 누르면 팝업이 열리고, 다시 누르면 닫힙니다. 체크박스를 누르면 선택됩니다. 이 정도는 러버블이 잘 처리합니다.
문제는 상태가 여러 페이지와 기능에 걸쳐 연결될 때 생깁니다. 예를 들어 예약 상담 웹앱을 만든다고 해봅시다. 사용자는 날짜를 고르고, 시간을 고르고, 이름과 연락처를 입력하고, 결제 여부를 확인하고, 관리자에게 알림을 보내야 합니다. 중간에 사용자가 뒤로 가기를 누르면 이전 입력값이 유지되어야 할까요? 이미 예약된 시간은 숨겨야 할까요? 관리자가 일정을 바꾸면 사용자 화면에도 즉시 반영되어야 할까요?
이런 질문이 많아질수록 상태 관리는 어려워집니다. 러버블이 첫 구조는 만들어줄 수 있지만, 비즈니스 규칙이 늘어나면 초보자는 어디서 문제가 생겼는지 이해하기 어렵습니다.
특히 다음과 같은 기능은 초보자에게 병목이 되기 쉽습니다.
여러 단계로 진행되는 신청·예약·설문 폼
관리자와 일반 사용자의 화면이 다른 서비스
로그인 상태에 따라 메뉴와 권한이 달라지는 앱
데이터가 실시간으로 바뀌는 대시보드
사용자가 입력한 값에 따라 가격이나 결과가 계산되는 견적 시스템
이런 기능을 만들지 말라는 뜻은 아닙니다. 다만 처음부터 한 번에 만들려고 하면 안 됩니다. 예를 들어 견적 시스템을 만들고 싶다면, 처음에는 "문의 폼으로 희망 예산과 요청사항을 받기" 정도로 시작하세요. 자동 견적 계산, 관리자 승인, 이메일 발송, 결제 연동은 나중에 붙여도 됩니다.
러버블로 부업형 웹페이지를 만들 때는 "멋진 자동화"보다 "확실히 작동하는 신청 흐름"이 먼저입니다.
결제, 권한, 외부 API는 신중하게 다루기
초보자가 러버블에서 가장 쉽게 욕심내는 기능 중 하나가 결제입니다. "전자책 판매 페이지를 만들고 바로 결제까지 붙이면 좋겠다." "상담 예약과 동시에 결제도 받으면 좋겠다." 당연히 좋은 생각입니다. 하지만 결제는 단순한 버튼이 아닙니다.
결제에는 금액, 통화, 환불, 영수증, 성공 페이지, 실패 페이지, 중복 결제 방지, 고객 정보, 결제 제공업체의 규칙이 얽혀 있습니다. 여기에 로그인과 권한이 붙으면 더 복잡해집니다. 누가 구매자인지, 구매한 사람만 자료를 볼 수 있는지, 관리자는 주문 내역을 볼 수 있는지 같은 문제가 생깁니다.
외부 API 연동도 비슷합니다. API는 다른 서비스와 데이터를 주고받는 통로입니다. 예를 들어 결제 서비스, 이메일 발송 서비스, 문자 발송 서비스, 지도 서비스, AI 요약 서비스와 연결할 때 API를 사용합니다. 러버블이 기본 코드를 만들어줄 수는 있지만, 각 서비스의 인증 방식, 제한 사항, 오류 처리까지 완벽하게 이해하고 처리한다고 기대하면 위험합니다.
특히 다음 세 가지가 들어가면 초보자는 속도를 늦춰야 합니다.
결제: Stripe, 토스페이먼츠, PayPal 등 실제 돈이 오가는 기능
권한: 관리자, 고객, 팀원, 판매자처럼 역할이 나뉘는 기능
외부 API: 이메일, 문자, 지도, AI, CRM 등 다른 서비스와 연결되는 기능
이 기능들은 사업적으로 중요하기 때문에 더 조심해야 합니다. "대충 작동하는 것"과 "실제로 고객에게 열어도 되는 것" 사이에는 차이가 큽니다. 결제 버튼이 한 번 눌리는 것보다 중요한 것은 결제 실패, 중복 클릭, 환불 요청, 권한 없는 접근 같은 상황을 막는 것입니다.
처음에는 결제 자동화를 미루는 것도 좋은 전략입니다. 전자책 랜딩 페이지라면 먼저 신청 폼과 계좌이체 안내로 시작할 수 있습니다. 상담 서비스라면 예약 신청 후 수동으로 결제 링크를 보내는 방식으로 시작할 수 있습니다. 실제 수요가 확인된 뒤 결제를 붙여도 늦지 않습니다.
러버블은 빠른 실험 도구입니다. 돈과 개인정보가 들어오는 순간부터는 실험 도구가 아니라 운영 시스템이 됩니다. 운영 시스템에는 더 높은 신뢰성이 필요합니다.
러버블을 첫 70% 제작 파트너로 보는 관점
러버블을 잘 쓰는 사람은 "끝까지 다 해줘"라고 말하지 않습니다. 대신 이렇게 생각합니다.
"내가 직접 만들기 어려운 첫 구조를 빠르게 만들어줘."
"빈 화면을 없애줘."
"사용자에게 보여줄 수 있는 흐름을 만들어줘."
"그다음부터는 내가 테스트하고, 줄이고, 다듬고, 필요하면 전문가에게 넘길게."
이 관점이 중요합니다. 러버블은 첫 70%에서 엄청난 속도를 보여줍니다. 첫 화면, 기본 섹션, 문의 폼, 간단한 데이터 저장, 로그인, 관리자 페이지 초안 같은 것들을 빠르게 만들 수 있습니다. 하지만 마지막 30%는 다릅니다. 마지막 30%에는 예외 처리, 보안, 성능, 모바일 디테일, 결제 안정성, 권한 검증, 실제 고객 운영 문제가 들어갑니다.
여러 기술 리뷰에서도 러버블은 초기 프로토타입과 MVP 검증에 강하지만, 복잡한 비즈니스 로직과 장기 운영이 필요한 프로덕션 앱에서는 사람의 검토와 추가 개발이 필요하다고 평가합니다.6 이 말은 러버블을 낮게 보는 말이 아닙니다. 오히려 러버블을 가장 가치 있게 쓰는 위치를 알려주는 말입니다.
개인 사업자와 프리랜서에게 첫 70%는 정말 중요합니다. 그 70%가 없어서 아이디어가 묻히는 경우가 많기 때문입니다. 상세 페이지를 못 만들어 상품 출시를 미루고, 상담 폼을 못 만들어 문의를 놓치고, 포트폴리오를 못 만들어 소개 기회를 잃습니다. 러버블은 이 막힌 구간을 뚫어줍니다.
다만 마지막 30%를 러버블에게 계속 밀어붙이다 보면 크레딧이 빠르게 사라질 수 있습니다. 이때는 완성도를 더 높일지, 범위를 줄일지, 외부 도구로 넘길지, 개발자에게 도움을 받을지 판단해야 합니다.
초보자를 위한 현실적인 사용 기준
러버블을 쓸 때 가장 좋은 기준은 "이 프로젝트가 실패해도 배울 수 있는 크기인가?"입니다. 처음부터 너무 큰 서비스를 만들려고 하면 실패 비용이 커집니다. 반대로 작게 만들면 실패해도 배움이 남고, 성공하면 확장할 수 있습니다.
처음 러버블로 만들기 좋은 프로젝트는 조건이 분명합니다.
한 가지 목적이 있다.
페이지 수가 적다.
로그인 없이도 핵심 가치가 전달된다.
데이터 저장이 단순하다.
결제나 복잡한 권한이 없어도 검증할 수 있다.
실패해도 개인정보나 금전 피해가 크지 않다.
예를 들어 "프리랜서 포트폴리오와 문의 폼"은 좋은 첫 프로젝트입니다. "다중 강사, 수강생, 결제, 진도율, 쿠폰, 환불, 관리자 승인까지 들어간 온라인 강의 플랫폼"은 첫 프로젝트로 무겁습니다. 둘 다 언젠가는 만들 수 있지만, 처음부터 후자를 목표로 하면 러버블의 강점보다 한계를 더 많이 만나게 됩니다.
초보자는 기능을 줄이는 능력이 필요합니다. 기능을 줄이는 것은 포기가 아니라 전략입니다. 처음에는 수동으로 해도 되는 일을 굳이 자동화하지 마세요. 문의가 하루 100건 들어오기 전까지는 고급 관리자 시스템이 필요 없을 수 있습니다. 결제가 매주 꾸준히 발생하기 전까지는 복잡한 회원 권한 시스템이 필요 없을 수 있습니다.
러버블은 작게 시작하는 사람에게 더 친절합니다.
크레딧을 지키는 판단법
앞 장에서 크레딧 구조를 살펴봤다면, 이제는 크레딧을 "어디에 써야 하는지" 판단해야 합니다. 무료 사용자라면 특히 중요합니다. 크레딧은 단순히 사용량이 아니라 집중력입니다. 하루에 몇 번밖에 요청하지 못한다면, 요청 하나하나가 기획서처럼 선명해야 합니다.
프롬프트를 보내기 전에 다음 질문을 해보세요.
이 수정은 Visual Editor로 직접 할 수 없는가?
이 요청은 한 문장으로 설명하기에 너무 모호하지 않은가?
지금 만들 기능이 실제 검증에 꼭 필요한가?
같은 문제를 이미 두 번 이상 고치고 있지는 않은가?
이 요청 때문에 다른 기능이 깨질 위험은 없는가?
이 질문 중 하나라도 걸리면 바로 프롬프트를 보내지 말고 잠시 멈추세요. 특히 "예쁘게 해줘" "더 고급스럽게 해줘" "전체적으로 개선해줘" 같은 말은 크레딧을 태우기 쉽습니다. 이런 요청은 결과 범위가 넓고, AI가 어디를 얼마나 바꿔야 하는지 판단하기 어렵습니다.
대신 이렇게 바꿔야 합니다.
"첫 화면의 CTA 버튼만 더 눈에 띄게 수정해줘. 배경색은 진한 남색, 글자는 흰색, 버튼 문구는 '무료 상담 신청하기'로 해줘. 다른 섹션은 수정하지 마."
이렇게 수정 범위를 좁히면 엉뚱한 변경 가능성이 줄어듭니다. 러버블에게 일을 맡길 때는 "무엇을 할지"만큼 "무엇을 건드리지 말지"도 알려주는 것이 좋습니다.
막히는 순간은 실패가 아니라 전환 신호다
러버블을 쓰다가 막히는 순간이 올 수 있습니다. 이것은 실패가 아닙니다. 오히려 프로젝트가 한 단계 진지해졌다는 신호일 수 있습니다.
처음에는 랜딩 페이지만 필요했는데, 이제 고객 문의가 들어옵니다. 처음에는 수동으로 관리해도 됐는데, 이제 신청자가 늘어납니다. 처음에는 결제가 필요 없었는데, 이제 유료 상품을 팔고 싶어집니다. 처음에는 나 혼자 쓰면 됐는데, 이제 팀원이나 고객 권한을 나눠야 합니다.
이때 러버블 안에서 계속 해결할 수도 있지만, 무조건 그래야 하는 것은 아닙니다. 때로는 기능을 줄이는 것이 답이고, 때로는 외부 AI에서 요구사항을 다시 정리하는 것이 답입니다. 때로는 GitHub로 코드를 내보내고 개발자의 도움을 받는 것이 답입니다. 때로는 아예 새로운 프로젝트로 다시 시작하는 것이 더 싸게 먹힐 수도 있습니다.
중요한 것은 막힌 상태에서 감정적으로 프롬프트를 반복하지 않는 것입니다. 크레딧이 줄어드는 속도보다 결과가 나오는 속도가 느려졌다면 멈춰야 합니다. 이 지점을 알아차리는 사람이 러버블을 오래 씁니다.
러버블은 초보자를 개발자로 마법처럼 바꿔주는 도구가 아닙니다. 대신 초보자가 자신의 아이디어를 더 빨리 검증하게 도와주는 도구입니다. 웹페이지를 만들고, 사람에게 보여주고, 반응을 얻고, 다음 결정을 하게 해줍니다. 그 정도만으로도 개인 사업자와 프리랜서에게는 충분히 강력합니다.
이 장에서 가져갈 핵심
러버블은 빠릅니다. 보기 좋은 UI를 만들고, 배포를 쉽게 해주며, GitHub와 Supabase 같은 도구를 통해 초보자도 웹앱의 세계에 들어갈 수 있게 해줍니다. 특히 포트폴리오, 문의 페이지, 상담 신청 페이지, 견적 요청 페이지, 디지털 상품 랜딩 페이지처럼 사업 검증에 필요한 웹페이지를 빠르게 만들 때 강합니다.
하지만 러버블은 만능이 아닙니다. 프롬프트 반복이 길어질수록 회귀 버그와 엉뚱한 수정이 생길 수 있고, 코드가 복잡해질 수 있습니다. 복잡한 상태 관리, 결제, 권한, 외부 API 연동이 들어가면 초보자는 병목을 만날 가능성이 큽니다.
따라서 러버블을 "내 서비스를 끝까지 완성해줄 개발자"로 보기보다 "첫 70%를 빠르게 만들어주는 제작 파트너"로 보는 것이 현실적입니다. 작은 디자인 수정은 Visual Editor와 선택 편집으로 처리하고, 프롬프트는 구조와 기능처럼 중요한 일에 아껴 쓰세요. 막히는 순간에는 더 많은 프롬프트를 던지는 대신, 범위를 줄이거나 요구사항을 다시 정리하거나 다음 도구로 넘어갈 준비를 해야 합니다.
다음 장부터는 본격적으로 "무엇을 만들 것인가"를 정합니다. 러버블을 열기 전에 사업형 웹사이트 아이디어를 어떻게 고르고, 어떤 프로젝트가 초보자에게 적합한지 살펴보겠습니다. 러버블에서 잘 만드는 법은 결국 러버블 밖에서 잘 정하는 것에서 시작됩니다.
참고
2Lovable Review 2026: Honest Pros, Cons & Is It Worth It?
3My Lovable.dev Review (2026): Is It Any Good?
4Do's and Don'ts of Using Lovable.dev: Everything You Need to Know
5Lovable.dev Limitations: Why It Got You to Launch but Won't Get You to Scale
6Lovable AI Review (2026): Key Limitations & How to Prepare Your App for Production
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.