Lovable 사용법: 다들 코딩부터 배우라는데 프롬프트 한 줄로 배포까지 끝내는 순서

가입 화면까지는 왔는데 입력창 하나만 덩그러니 놓여 있고, 여기에 뭘 써야 웹사이트가 나오는 건지 감이 안 잡히는 순간이 있어요. 설치 파일을 찾느라 검색을 반복하는 경우도 많고요. 먼저 답부터 말하면, Lovable은 설치가 필요 없는 브라우저 서비스이고 사용법은 결국 ‘만들 것을 문장으로 설명 → 화면 보고 수정 요청 → 퍼블리시 버튼’ 이 세 단계로 압축돼요. 코딩 지식이 아니라 ‘무엇을 만들지 정리하는 능력’이 결과물을 갈라놓는 도구예요. 이 글에서는 가입부터 첫 프로젝트 생성, 프롬프트 작성, 수정과 되돌리기, 데이터베이스 연결, 배포, 크레딧 관리까지 실제 클릭 순서대로 짚고, Claude Code처럼 코드를 직접 만지는 방식과 비교해 어디까지가 Lovable의 영역인지도 솔직하게 정리해요.

• Lovable 사용법, 한 줄로 먼저 답하면
• Lovable이란 무엇인가 — 노코드와 무엇이 다른가
• 시작 전 준비물과 가입 절차
• 첫 프로젝트 만들기 — 클릭 순서 그대로
• 결과가 달라지는 프롬프트 작성법
• 화면 수정, 되돌리기, 엉뚱한 결과 복구하기
• 데이터베이스·로그인 연결과 배포
• 요금제와 크레딧, 어디서 돈이 새는가
• Claude Code와 비교하면 어디까지 Lovable이 편한가
• 자주 하는 오해와 진실
• 참고자료

Lovable 사용법, 한 줄로 먼저 답하면

Lovable은 프로그램을 내려받아 설치하는 도구가 아니에요. 크롬이나 엣지 같은 브라우저로 공식 사이트에 접속하면 그 자리에서 바로 쓸 수 있어요. “Lovable 다운로드”로 검색해도 설치 파일이 안 나오는 이유가 여기 있어요.

실제 작업 흐름은 채팅과 거의 같아요. 왼쪽에 대화창, 오른쪽에 결과 화면이 뜨고, 대화창에 “카페 예약 페이지를 만들어줘”라고 쓰면 오른쪽에 진짜 동작하는 웹페이지가 만들어져요. 마음에 안 드는 부분은 다시 문장으로 말하면 고쳐지고요.

그래서 초보자가 붙잡고 늘어져야 할 건 버튼 위치가 아니라 설명하는 방식이에요. 같은 도구를 써도 “쇼핑몰 만들어줘”라고 던진 사람과 “상품 목록·상세·장바구니 3개 화면, 로그인 없음, 결제는 나중에”라고 쓴 사람의 결과물은 완전히 달라져요.

아래부터는 가입 화면에서 실제로 누르는 순서대로 따라가요. 중간에 자주 막히는 지점과 크레딧이 새는 구간도 같이 짚을게요.

Lovable이란 무엇인가 — 노코드와 무엇이 다른가

Lovable은 자연어로 요청하면 웹앱의 코드를 직접 만들어주고 배포까지 해주는 AI 앱 빌더예요. 요즘 흔히 말하는 ‘바이브코딩’, 그러니까 코드를 손으로 치는 대신 원하는 결과를 말로 설명해서 만드는 방식의 대표 도구 중 하나로 꼽혀요.

기존 노코드 툴과의 차이는 결과물의 정체예요. 블록을 끌어다 붙이는 방식의 도구들은 그 플랫폼 안에서만 돌아가는 구조물을 만들어요. 반면 Lovable은 리액트 기반의 실제 프로젝트 코드를 생성해요. 코드 자체를 GitHub로 내보낼 수 있다는 게 결정적인 차이고요.

이게 왜 중요하냐면, 나중에 개발자에게 넘기거나 직접 손보고 싶을 때 길이 열려 있기 때문이에요. 플랫폼 종속형 도구는 서비스가 커졌을 때 통째로 다시 만들어야 하는 상황이 자주 생기는데, 코드가 남는 쪽은 이어서 개발하면 돼요.

정리하면 Lovable은 ‘아이디어를 눈에 보이는 형태로 최대한 빨리 바꿔주는 도구’예요. 검증이 목적이라면 강력하고, 완성된 상용 서비스를 처음부터 끝까지 맡기려 하면 아쉬움이 생겨요.

시작 전 준비물과 가입 절차

준비물은 단순해요. 브라우저, 이메일 또는 구글 계정, 그리고 만들고 싶은 것에 대한 대략의 그림이면 돼요. 신용카드는 무료 범위 안에서 시작할 때는 필요 없어요.

가입은 공식 사이트에서 Sign up을 눌러 구글 계정으로 진행하는 게 가장 빨라요. 이메일 인증 절차 없이 바로 작업 화면으로 넘어가는 경우가 많아요.

한국어 관련해서 자주 나오는 질문은 두 가지예요. 첫째, 프롬프트는 한국어로 써도 잘 알아들어요. 요청 내용을 이해하는 데는 큰 문제가 없어요. 둘째, 인터페이스 자체는 영어 위주라 버튼 이름은 영어로 보여요. 다만 눌러야 할 버튼이 몇 개 안 돼서 며칠이면 익숙해져요.

다만 결과물 안에 들어가는 문구는 영어로 나올 때가 있어요. 이때는 프롬프트 끝에 “모든 UI 텍스트와 버튼 문구는 한국어로 작성해줘”라고 한 줄 덧붙이면 대부분 해결돼요. 한글 폰트가 어색하면 “본문 폰트는 Pretendard 같은 한글 웹폰트로 지정해줘”라고 요청하는 방법도 있어요.

첫 화면 구성은 크게 세 덩어리예요. 왼쪽 대화 패널, 오른쪽 미리보기 영역, 그리고 상단의 프로젝트 설정·배포 관련 버튼들이죠. 처음엔 이 세 곳만 알아도 충분해요.

첫 프로젝트 만들기 — 클릭 순서 그대로

가입 직후 보이는 큰 입력창이 사실상 프로젝트 생성 버튼이에요. 여기에 첫 문장을 넣는 순간 새 프로젝트가 만들어져요.

첫 프로젝트는 욕심을 줄이는 게 좋아요. 회원가입·결제·관리자 기능을 한 번에 넣으려 하면 완성도가 뚝 떨어져요. 화면 3개짜리 랜딩페이지로 시작해 흐름을 익히고, 그 다음에 기능을 얹는 순서가 훨씬 덜 막혀요.

결과가 달라지는 프롬프트 작성법

상위 문서들이 공통으로 강조하는 원칙이 하나 있어요. 프롬프트보다 구조 설계가 먼저라는 거예요. 어떤 화면이 몇 개 필요하고 각 화면에 뭐가 들어가는지를 먼저 적어두면, 프롬프트는 그걸 옮겨 적는 일에 가까워져요.

차이를 만드는 건 세 가지예요. 대상을 특정하고(어느 화면의 어느 요소인지), 기대 결과를 서술하고(무엇이 어떻게 되어야 하는지), 범위를 제한하는 것(이번엔 여기까지만).

복붙해서 쓸 수 있는 첫 프롬프트 골격을 하나 남겨둘게요.

여기서 마지막 줄이 의외로 중요해요. 범위를 못 박지 않으면 요청하지 않은 기능까지 만들어 넣는 경우가 있고, 그만큼 크레딧과 수정 시간이 늘어나요.

참고 사이트를 알려주는 것도 효과가 커요. “○○ 같은 여백 위주 레이아웃”처럼 방향을 주면 추상적인 표현보다 훨씬 정확하게 잡혀요. 다만 특정 사이트를 그대로 베끼라는 요청은 저작권 문제가 생길 수 있으니 분위기 참고 수준으로만 쓰는 게 안전해요.

화면 수정, 되돌리기, 엉뚱한 결과 복구하기

실제로 시간을 가장 많이 잡아먹는 구간이 여기예요. 처음 생성은 순식간인데, 그 뒤 다듬는 과정에서 무한 반복에 빠지기 쉬워요.

먼저 알아둘 건 모든 수정을 대화로 할 필요가 없다는 점이에요. 글자 몇 개 바꾸거나 색상 조정처럼 사소한 변경은 시각 편집 모드에서 요소를 골라 직접 고치는 편이 빠르고, 크레딧도 아껴요. 대화 한 번이 곧 사용량이라는 걸 생각하면 차이가 꽤 커요.

결과가 크게 어긋났을 때 쓰는 복구 순서는 이래요. 첫째, 히스토리에서 정상 동작하던 시점으로 되돌려요. 둘째, 문제가 됐던 요청을 두세 개의 작은 요청으로 쪼개요. 셋째, 하나씩 실행하고 매번 미리보기를 확인해요.

에러 메시지가 화면에 뜬다면 그 문구를 그대로 복사해서 대화창에 붙여넣는 것도 좋은 방법이에요. “이 에러가 떴어요”라며 원문을 주면 원인을 훨씬 정확히 짚어요. 그리고 “수정하기 전에 무엇이 문제인지 먼저 설명해줘”라고 덧붙이면, 무작정 코드를 뜯어고치는 걸 막을 수 있어요.

또 하나 자주 나오는 상황이 ‘고쳤더니 다른 데가 망가지는’ 경우예요. 이럴 땐 요청 끝에 “다른 화면과 기존 기능은 건드리지 말고 이 부분만 수정해줘”라는 제한 문장을 붙여두면 부작용이 줄어요.

데이터베이스·로그인 연결과 배포

화면만 있는 사이트는 여기까지로 충분하지만, 문의 내용을 저장하거나 회원가입을 붙이려면 데이터베이스가 필요해요. Lovable은 Supabase 연동을 기본 경로로 안내하는 편이고, 연결 자체는 계정을 잇는 수준이라 어렵지 않아요.

순서는 단순해요. Supabase 계정을 만들고, Lovable 프로젝트 설정에서 연동을 승인한 뒤, 대화창에 “문의 폼 내용을 데이터베이스에 저장하고 관리자 페이지에서 목록으로 볼 수 있게 해줘”라고 요청하면 필요한 테이블과 연결 코드를 만들어줘요.

배포는 상단 퍼블리시 버튼 한 번이면 끝나요. 누르면 공개 주소가 만들어지고, 그 시점의 상태가 그대로 공개돼요. 이후 수정한 내용은 다시 퍼블리시를 눌러야 반영된다는 점만 기억하면 돼요.

직접 산 도메인을 붙이고 싶다면 프로젝트 설정의 도메인 메뉴에서 주소를 등록하고, 도메인 등록업체의 DNS 관리 화면에서 안내받은 값을 넣으면 돼요. 반영까지는 보통 몇 분에서 몇 시간까지 걸리니 바로 안 열린다고 설정을 계속 바꾸지 않는 게 좋아요.

GitHub 연동은 처음엔 안 해도 되지만, 프로젝트가 커지면 해두는 걸 권해요. 코드가 내 저장소에 그대로 쌓이니 백업 역할을 하고, 나중에 Claude Code 같은 도구로 같은 코드를 이어서 손볼 수도 있어요. 실제로 초반 화면은 Lovable로 빠르게 뽑고 세부 로직은 코드 편집 도구로 다듬는 조합을 쓰는 경우가 많아요.

요금제와 크레딧, 어디서 돈이 새는가

Lovable은 대화(메시지) 단위로 사용량을 차감하는 구조예요. 버튼 하나 색을 바꾸는 요청과 페이지 전체를 새로 만드는 요청이 같은 한 번으로 계산되는 방식이라, 요청을 얼마나 잘 묶느냐가 곧 비용이 돼요.

무료 플랜으로도 체험이 가능하고, 유료 플랜은 월 결제와 연 결제 가격이 다르며 학생 대상 할인이나 프로모션이 진행되기도 해요. 다만 크레딧 수량과 금액은 정책이 자주 바뀌는 영역이라 결제 전에는 공식 요금제 페이지에서 직접 확인하는 게 정확해요.

실제로 사용량이 훅 줄어드는 지점은 3번이에요. 생각나는 대로 던지면 같은 부분을 대여섯 번 고치게 되는데, 미리 정리하고 들어가면 두세 번으로 끝나요. 무료 범위 안에서 감을 잡을 때 특히 차이가 커요.

배포 이후 비용도 미리 생각해두면 좋아요. 사이트를 계속 수정한다면 구독은 이어져야 하고, 도메인 갱신비와 데이터베이스 사용료가 별도로 붙어요. 반대로 더 손댈 일이 없다면 코드를 GitHub로 내보내 다른 호스팅에 올리는 선택지도 있어요.

Claude Code와 비교하면 어디까지 Lovable이 편한가

둘 다 AI에게 말로 시켜 만든다는 점은 같은데, 서 있는 자리가 달라요. Lovable은 브라우저 안에서 화면을 보며 만드는 도구이고, Claude Code는 내 컴퓨터의 파일을 직접 다루는 도구예요.

편한 구간은 명확해요. 아무것도 없는 상태에서 눈에 보이는 결과물까지 가는 초반 속도는 Lovable이 확실히 앞서요. 디자인 감각이 없어도 첫 결과물이 부끄럽지 않은 수준으로 나오니까요.

반대로 막히기 시작하는 지점도 뚜렷해요. 화면이 열 개를 넘어가고 기능이 서로 얽히기 시작하면, 대화만으로 어디를 고쳐야 할지 지정하기가 어려워져요. 한 곳을 고치면 다른 곳이 흔들리는 일도 이 구간에서 늘어나요.

그래서 현실적인 조합은 이거예요. 초기 뼈대는 Lovable, GitHub로 내보낸 뒤 세부 조정은 코드 도구로. 워드프레스 블로그를 운영하면서 별도 랜딩페이지나 소개 사이트가 필요한 경우라면 Lovable로 하루 만에 만들어 붙이는 게 합리적이고, 블로그 테마 자체를 손보는 일은 코드를 직접 다루는 쪽이 맞아요.

자주 하는 오해와 진실

Lovable 다운로드는 어디서 하나요?

다운로드할 게 없어요. 설치형 프로그램이 아니라 브라우저에서 접속해 쓰는 웹 서비스라서, 공식 사이트에 로그인하면 그게 곧 실행이에요. 윈도우든 맥이든 상관없고, 사양 걱정도 필요 없어요.

정말 코딩을 하나도 몰라도 되나요?

시작은 몰라도 되지만, 오래 쓰려면 최소한의 개념은 알게 돼요. 페이지·컴포넌트·데이터베이스·배포 같은 단어의 뜻 정도는 자연스럽게 익히게 되고, 이걸 알수록 요청이 정확해져서 결과물도 좋아져요. 코드를 직접 못 짜도 괜찮지만, 구조를 이해하려는 태도는 필요해요.

한국어로 요청하면 결과가 나빠진다던데?

요청 이해 자체는 한국어로도 충분히 잘 돼요. 다만 결과물의 문구가 영어로 나오거나 한글 줄바꿈이 어색한 경우가 있는데, 이건 언어 이해력 문제라기보다 기본 설정 때문이에요. “모든 문구는 한국어로”, “한글 웹폰트 적용”을 명시하면 대부분 정리돼요.

무료로 끝까지 만들 수 있나요?

간단한 한 페이지 사이트라면 무료 범위 안에서도 배포까지 가볼 수 있어요. 하지만 화면이 여러 개이고 수정을 반복하는 프로젝트는 무료 사용량으로 부족해지는 경우가 많아요. 무료로 감을 잡고, 진짜 만들 게 정해졌을 때 한 달만 결제해 집중적으로 끝내는 방식이 비용 대비 효율이 좋아요.

여기서 만든 사이트로 애드센스를 붙일 수 있나요?

기술적으로는 가능하지만 권하지는 않아요. 애드센스 승인은 꾸준히 쌓이는 콘텐츠와 정책 페이지 구성이 중요한데, 이런 운영은 워드프레스처럼 글 관리 기능이 갖춰진 플랫폼이 훨씬 편해요. Lovable은 랜딩페이지나 서비스형 웹앱 쪽에 쓰고, 수익형 블로그는 별도 플랫폼으로 나누는 게 현실적이에요.

참고자료

• Lovable 공식 사이트 — 가입, 요금제, 최신 기능 확인
• Lovable 공식 문서 — 프롬프트 작성법, 연동, 배포 가이드
• Supabase 공식 문서 — 데이터베이스 연동과 보안 정책 설정
• GitHub 공식 문서(한국어) — 저장소 연동과 코드 관리 기초

Lovable 사용법에서 진짜 관문은 버튼 위치가 아니라 ‘무엇을 만들지 문장으로 정리하는 일’이에요. 화면 목록을 먼저 적고, 요청은 하나씩 쪼개고, 어긋나면 고치기보다 되돌리는 습관만 잡으면 첫날 안에 공개 주소까지 만들 수 있어요. 처음이라면 화면 3개짜리 랜딩페이지로 흐름을 익힌 뒤 데이터베이스와 도메인을 붙이는 순서를 권해요. 그러다 화면이 늘고 대화만으로 답답해지는 순간이 오면, 그때가 GitHub로 코드를 내보내 직접 손보는 방식으로 넘어갈 시점이에요. 도구를 고르느라 시간을 쓰기보다 오늘 한 페이지라도 배포해보는 쪽이 훨씬 빨리 감이 잡혀요.

함께 보면 좋은 글

• JSON-LD 형식, 순위엔 영향 없는데 다들 붙이는 진짜 이유
• “커밋을 잘못했어요” 깃 사용법, 비전공자가 실제로 친 명령어 순서대로
• 네이버 블로그 수익화, 정말 될까? 애드포스트 현실과 내 도메인으로 넘어가는 순서