Lovable이란? AI 웹 앱 제작 기능·요금·사용법 안내

정보 확인일: 2026년 11월 5일. 공식 페이지 본문을 확인해 작성한 원고입니다. 앱 제작, 외부 서비스 연결, 계약, 게시는 실행하지 않았습니다. 요금은 미국 달러 기준입니다.

들어가며

만들고 싶은 웹 서비스 아이디어는 있지만, 첫 화면을 만드는 단계에서 막히는 경우가 있습니다. Lovable은 자연스러운 말로 원하는 것을 설명하면서 웹사이트나 웹 앱을 만들어 가는 서비스입니다. 공식 안내에서는 생성한 화면을 미리보기로 확인하고, 대화로 수정한 뒤 게시하는 흐름을 소개합니다. Lovable 공식 사이트

다만 화면이 표시된다는 사실만으로는 사용자가 헤매지 않고 사용할 수 있는지, 필요한 처리가 작동하는지 알 수 없습니다. 이 글에서는 가상의 상품 목록을 예로 들어 작은 프로토타입을 만들어 확인하는 접근법을 소개합니다. 기능의 수보다 먼저 하나의 목적을 달성할 수 있는지에 주목해 봅니다.

Lovable이란

Lovable은 만들고 싶은 것을 설명하면 화면과 기능을 구성하고, 채팅과 미리보기를 오가며 조정할 수 있는 제작 서비스입니다. 공식 입문 가이드에서는 빈 상태에서 시작하는 방법과 템플릿을 Remix해 독립된 복사본에서 시작하는 방법을 소개합니다. 입문 가이드

편집부는 처음 만들 대상을 “누가, 무엇을 보고, 어떤 조작을 하는가”로 설명할 것을 권합니다. 예를 들어 비품 목록이라면 이름을 검색하거나, 카테고리로 범위를 좁히거나, 상세 내용을 읽는 사용 방식을 생각할 수 있습니다.

여기서 소개하는 예시는 가상의 이름과 설명을 화면에 표시하는 프로토타입입니다. 재고 관리나 예약 접수까지 구현했다는 뜻은 아닙니다. 화면의 상태가 바뀌는 것과 정보가 저장되어 다른 사람에게도 공유되는 것은 별도의 확인 항목으로 다룹니다.

완성된 모습을 한 번에 전달하려고 하면 꼭 필요한 기능과 나중에 추가해도 되는 기능이 뒤섞입니다. 먼저 최소한의 조작을 정하고 동작을 확인한 뒤 범위를 넓히는 편이 수정 이유도 설명하기 쉽습니다.

할 수 있는 일(주요 기능)

대화로 프로토타입 구성하기

공식 가이드는 자연스러운 말로 페이지와 동작을 설명하고 생성된 결과물을 확인하는 방식을 안내합니다. 처음 생성한 뒤 변경 사항을 하나씩 요청하는 방법과 이전 버전으로 되돌리는 방법도 설명합니다. 제작 시작 방법

편집부가 제안하는 지시 예시는 “가상의 대여 비품을 목록으로 볼 수 있는 페이지. 이름, 카테고리, 설명을 표시하고 이름으로 검색할 수 있게 한다”입니다. 처음에는 샘플 내용을 사용해 실제 개인정보나 고객 정보가 필요하지 않은 형태로 구상합니다.

색상이나 모서리 모양뿐 아니라 검색했을 때 어떤 일이 일어나는지까지 말로 설명하면 확인할 대상이 분명해집니다. “검색 결과가 없으면 이를 알 수 있는 문구를 표시한다”와 같은 조건도 사용성을 검토하는 데 도움이 됩니다.

계획 논의와 구현 구분하기

Lovable에는 코드를 변경하지 않고 상담할 수 있는 Plan mode가 있습니다. 크레딧 안내에 따르면 Plan mode에서는 메시지의 기본 사용량 외에 조사용 하위 에이전트의 처리로 크레딧이 추가 소모될 수 있습니다. 크레딧과 사용량

편집부는 기능을 추가하기 전에 “현재 구조로 대응할 수 있는가”, “어느 화면에 영향을 주는가”를 정리하는 용도로 활용할 것을 권합니다. 논의한 내용을 읽고 필요한 범위를 확인한 뒤 변경하면, 나중에 수정하는 이유를 되짚기도 쉬워집니다.

계획이 표시되었다고 해서 기능이 완성된 것으로 보지는 않습니다. 아이디어로 설명된 내용, 화면에 반영된 내용, 실제 조작으로 확인한 내용을 나누어 기록하면 공동 작업에서도 진행 상태를 공유하기 쉽습니다.

미리보기로 화면과 동작 확인하기

미리보기에는 최신 작업 내용이 표시되며 데스크톱, 태블릿, 모바일 화면으로 전환할 수 있습니다. 이미 게시된 사이트에는 게시 시점의 내용이 표시되므로, 편집한 내용은 다시 게시하기 전까지 자동으로 동일하게 반영되지 않습니다. 미리보기

여기서 주의할 점은 미리보기와 게시된 사이트가 동일한 백엔드와 데이터를 사용한다는 공식 설명입니다. 화면을 게시하는 시점이 나뉘어 있어도 데이터 쪽 변경까지 반드시 분리되는 것은 아닙니다.

편집부는 화면 표시와 조작을 나누어 확인할 것을 권합니다. 글자를 읽을 수 있는지, 버튼을 누를 수 있는지에 더해 검색을 해제하면 원래대로 돌아오는지, 상세 내용을 닫고 계속 찾을 수 있는지 등 일련의 행동을 시험합니다.

게시와 코드 활용 방식 선택하기

공식 요금제 비교에는 GitHub 등과의 동기화가 포함되어 있으며, 유료 요금제에서는 코드 편집·다운로드, 사용자 지정 도메인, Lovable 배지 제거 등을 안내합니다. 요금제 비교

코드를 내보낼 수 있다고 해서 이후의 운영이나 수정이 필요 없어지는 것은 아닙니다. 편집부는 누가 유지보수할지, 문제가 생기면 어디를 살펴볼지, 어떤 서비스에 의존하는지도 함께 생각할 것을 권합니다.

실제로 게시하기 전에는 공개 범위, 표시 내용, 연결 대상을 확인합니다. 제작 중인 프로토타입을 보여주는 것과 일반 사용자가 이용하도록 하는 것은 필요한 확인의 깊이가 다릅니다.

요금제

공식 요금제 문서에서는 Free, Pro, Business, Enterprise를 안내합니다. 아래 표는 월 결제 시 가장 기본이 되는 구성입니다. 유료 요금제에는 월간 크레딧을 늘리는 선택지도 있습니다. 공식 요금제 문서

연 결제는 100크레딧 구성 기준으로 Pro가 연 250달러, Business가 연 500달러로 기재되어 있습니다. 연 결제를 하더라도 월간 크레딧은 매달 지급되므로, 1년 치를 처음부터 한꺼번에 사용할 수 있다고 생각해서는 안 됩니다.

크레딧은 제작을 위한 처리뿐 아니라 Cloud나 앱 내 AI 등의 가동과도 관련이 있습니다. 공식 안내에서는 용도별로 지급된 크레딧을 먼저 사용하고, 필요에 따라 공통 잔액을 소모하는 구조를 설명합니다. 사용량 안내

Cloud와 AI의 월간 제공량 중에는 한시적이며 변경될 수 있는 항목도 있습니다. 무료 제공량만을 전제로 장기 운영비를 정하지 말고, 제작 중 사용량과 사용자가 이용할 때의 사용량을 확인해야 합니다.

편집부는 한 번에 주고받는 메시지 수만으로 비용을 추산하지 않을 것을 권합니다. 처리 내용에 따라 소모량이 달라지므로, 작은 변경을 몇 차례 진행했을 때의 실제 사용량을 기록하면 비교하기 쉬워집니다.

또한 요금 페이지에는 지역이나 요금제에 따른 일일 제공량의 예외도 있습니다. 계약 시에는 공식 페이지와 본인의 사용 화면에 표시된 조건을 대조하고, 갱신일, 지급일, 유효기간을 확인하는 것이 좋습니다. 공식 요금

사용 순서: 작은 목록 앱 구상하기

아래 내용은 공식 가이드를 바탕으로 정리한 진행 방법과 편집부의 확인 예시입니다. 이 글을 위해 앱을 제작·게시하여 직접 측정한 결과는 아닙니다.

1. 사용자와 첫 조작 정하기

먼저 “비품을 찾는 사람이 이름이나 종류로 후보를 찾을 수 있다”라고 목적을 적습니다. 목록, 검색, 상세 보기의 세 가지로 좁히면 무엇을 확인해야 하는지 설명하기 쉽습니다.

예약, 승인, 알림, 청구 등을 한꺼번에 넣으면 어느 기능에서 문제가 발생하는지 구분하기 어려워집니다. 처음 정한 목적을 달성하는 데 꼭 필요한 것만 선택하는 것이 좋습니다.

2. 샘플 내용과 화면 설명하기

공식 가이드에 따라 필요한 화면과 동작을 글로 설명합니다. 편집부의 예시에서는 가상의 비품 이름과 짧은 설명을 몇 개 준비하고, 사진 없이도 내용을 구분할 수 있는 목록을 구상합니다.

항목이 하나뿐이면 긴 이름, 설명이 없는 항목, 같은 카테고리에 속한 여러 항목 등을 확인할 수 없습니다. 화면 배치가 흐트러질 만한 내용도 조금 섞어 처음부터 여러 상황을 살펴볼 수 있게 합니다.

3. 생성된 화면 조작하기

미리보기로 화면을 확인하고, 검색에 일치하는 문자, 일치하지 않는 문자, 빈 입력을 차례로 시험합니다. 겉보기에 잘 정돈되어 있어도 조작 결과가 사용자에게 전달되지 않는다면 개선할 여지가 있습니다.

모바일 화면에서는 목록 순서, 버튼 위치, 상세 내용의 가독성도 확인합니다. 가로로 나란히 있던 정보가 세로로 쌓였을 때 이름과 설명의 관계를 알아볼 수 있는지 살펴봅니다.

4. 변경 사항을 하나씩 요청하기

수정할 때는 “더 쓰기 쉽게”라는 요청에 그치지 않고 어느 상황에서 불편한지 적습니다. 예를 들어 “결과가 없으면 목록만 사라지므로, 검색 조건을 바꾸라는 안내를 표시한다”와 같이 전달합니다.

변경 후에는 해당 부분과 그 주변의 조작을 다시 확인합니다. 검색창을 수정한 뒤 목록으로 돌아갈 수 없게 되지는 않았는지 등 관련 행동까지 살펴봅니다. 신경 쓰이는 부분을 모아 기록해 두면 같은 수정을 반복하는 일을 줄일 수 있습니다.

5. 게시 준비와 게시 후 확인 구분하기

공식 가이드는 Publish에서 URL과 공개 범위를 확인하고 게시하는 흐름을 설명합니다. 이후의 변경 사항도 게시 작업을 통해 실제 제공되는 내용에 반영합니다. 게시 절차

실제로 게시할 때는 제목과 설명문, 불필요한 샘플 표시, 링크 대상을 먼저 확인합니다. 게시 후에는 실제로 제공되는 URL을 열고, 편집 화면의 미리보기와 같을 것이라고 가정하지 않은 채 사용자가 접속하는 지점부터 조작을 확인하는 것이 좋습니다.

확인 결과는 “된다”, “안 된다”뿐 아니라 입력한 내용과 기대한 결과까지 남기면 도움이 됩니다. 예를 들어 “비품 이름의 일부로 검색하면 해당하는 두 항목만 표시된다”라고 적어 두면 다음 수정 후에도 같은 조건으로 다시 확인할 수 있습니다.

관계자에게 보여줄 때도 자유롭게 의견을 받는 것에 더해 하나의 작업을 부탁하는 방법이 있습니다. “이 용도에 맞는 비품을 하나 고른다”와 같은 과제라면 어디서 망설였는지 구체적으로 물어볼 수 있습니다. 이는 Lovable의 기능이 아니라 편집부가 권하는 프로토타입 평가 방법입니다. 제작자가 설명을 덧붙이지 않아도 목적을 달성할 수 있는지 살펴보면 다음 수정 사항을 정하기 쉬워집니다.

잘 맞는 사람·잘 맞지 않는 사람

잘 맞는 사람

편집부가 보기에는 기획을 화면으로 옮겨 관계자와 사용 방식을 논의하고 싶은 사람에게 잘 맞습니다. 글만으로는 상상하기 어려운 검색이나 목록의 동작을 작은 규모로 확인하는 데 활용할 수 있습니다.

또한 실제 화면을 보면서 요구사항을 수정할 수 있는 사람에게도 선택지가 됩니다. 첫 지시만으로 완성하기보다는 확인과 수정을 반복한다는 전제로 접근하는 편이 사용 방식에 잘 맞습니다.

잘 맞지 않는 사람

화면이 표시된 시점에 권한, 저장, 운영까지 확인이 끝난 것으로 여기려는 사람에게는 권하기 어렵습니다. 입력하거나 열람할 수 있는 범위가 중요한 서비스라면 화면 이외의 부분도 확인해야 합니다.

생성 후 변경 내용이나 사용량을 확인할 시간을 낼 수 없는 경우에도 도입을 서두르지 않는 편이 좋다고 봅니다. 처음에는 범위를 제한한 주제로 확인 작업까지 포함한 제작 흐름을 시험해 보는 것이 좋습니다.

비슷한 도구와의 차이

Framer도 AI를 활용한 사이트 제작을 안내합니다. 공식 입문 강의에서는 캔버스 편집과 CMS를 포함한 사이트 제작을 설명합니다. Framer 입문 강의

편집부는 두 도구에 동일한 작은 과제를 주면 비교하기 쉽다고 생각합니다. 보여줄 내용과 업데이트의 편의성을 중시하는지, 검색 같은 조작이 가능한 프로토타입을 중시하는지에 따라 확인할 항목을 달리합니다.

용도만으로 우열을 정하기보다, 직접 만들려는 대상에서 필요한 조작과 확인 방법을 동일하게 맞추어 판단하는 것이 좋습니다.

주의할 점

AI가 생성한 문장이나 수치는 게재해도 되는 사실인지 확인합니다. 가상의 실적, 사용자 후기, 가격 등을 그대로 실제 서비스의 정보로 사용하지 않도록 합니다.

미리보기와 게시된 사이트가 데이터를 공유한다면 화면 수정과 데이터 쪽 변경이 미치는 영향을 나누어 생각합니다. 운영 중인 서비스를 다룰 때는 변경이 어느 범위까지 영향을 미치는지 이해한 뒤 진행해야 합니다.

외부 서비스를 추가한다면 연결할 서비스의 요금과 권한도 확인해야 합니다. Lovable의 기본요금에 모든 외부 서비스 이용 비용이 포함된다고 판단하지 않도록 합니다.

마무리

Lovable은 말로 설명하고, 생성된 화면을 보며, 직접 조작하면서 수정하는 웹 제작 도구의 선택지입니다. 처음에는 작은 목록이나 검색 기능을 대상으로 삼으면 필요한 기능과 확인해야 할 동작을 정리하기 쉽습니다.

요금은 크레딧 지급과 소모, 제작과 가동 양쪽을 모두 확인하는 것이 좋습니다. 프로토타입의 외형만으로 판단하지 않고 공개 범위와 실제 조작까지 확인하는 것이 이용 목적에 맞는지 판단하는 출발점입니다.

출처

모두 2026년 11월 5일에 공식 본문을 확인했습니다.

• Lovable 공식 사이트
• 입문 가이드
• 크레딧과 사용량
• 미리보기
• 요금제 비교
• 공식 요금
• 게시 절차
• Framer 입문 강의