Lovable로 진짜 제품 만들기

아이디어를 다듬고, 계획을 세우고, 디자인을 정하고, 작은 반복으로 만들고, 백엔드를 붙이고, 테스트하고, 배포합니다. 사람들이 쓰기 시작하면 앱을 계속 개선합니다.

"제가 뭘 하고 있는지는 하나도 모릅니다... 그래도 무엇을 만들고 싶은지는 정확히 압니다."

이 말이 남 얘기 같지 않다면 이 가이드가 맞습니다. 하나의 아이디어를 막연한 착상에서 출시되어 성장하는 제품까지 끌고 가면서, Lovable을 손쉽게 다루게 해 주는 작업 습관을 함께 익힙니다. 코딩을 몰라도 됩니다. 아직 Lovable로 아무것도 만들어 본 적이 없다면 먼저 Quick start를 해 보세요. 10분이면 됩니다.

설명을 구체적으로 하기 위해 예시는 하나의 프로젝트를 따라갑니다. 작은 사진 스튜디오를 위한 예약 앱 StudioBook입니다. 고객은 세션 종류와 시간대를 고르고, 스튜디오 주인은 일정을 봅니다. 자신의 아이디어로 바꿔 넣어도 과정은 똑같습니다.

전체 여정은 이렇게 흐릅니다. 아이디어를 다듬고, 계획하고, 디자인 방향을 정하고, 작은 반복으로 만들고, 백엔드를 붙이고, 테스트하고, 배포하고, 키우고, 유지합니다.

아이디어 다듬기

생각이 잘 떠오르는 곳이라면 어디서든 시작하세요. 음성 메모, 산책, ChatGPT와의 대화, 펜과 종이 모두 좋습니다. 첫 프롬프트를 쓰기 전에 15분을 들여 네 가지 질문에 답해 보세요:

• 이 제품은 무엇인가?
• 누구를 위한 것인가?
• 사람들이 왜 이 제품을 쓸까?
• 사용자가 취해야 할 핵심 행동 하나는 무엇인가?

그런 다음 그 생각을 Lovable에 옮깁니다. 유용한 요령 하나는 사양서를 쓰는 대신 이야기를 들려주는 것입니다:

Anna runs a small photography studio. Clients email her to book sessions, and she loses track of who booked what. Build the one screen that fixes this: a booking page where a client picks a session type (portrait, family, product) and an available time slot, then enters their name and email. Use realistic sample data. No login or database yet. Tone: warm and professional.

이야기는 불릿 목록이 빠뜨리는 맥락을 Lovable에 전달합니다. 누가 그 화면을 쓰는지, 무엇을 하려는지, 어떤 느낌이어야 하는지 같은 것입니다. 아이디어가 이미 스케치나 Figma 프레임, 또는 마음에 드는 사이트로 존재한다면, 레이아웃을 말로 설명하는 대신 프롬프트에 스크린샷을 첨부하세요.

첫 버전은 작게 유지하세요. 사용자 한 명, 행동 하나, 결과 하나면 됩니다. Anna의 고객이 시간대를 예약합니다. 이 예약 흐름 하나가 v1의 전부입니다. 결제, 알림, 캘린더 보기는 모두 나중에 추가할 수 있습니다. 그리고 나중이 한 번에 모든 것을 요구하는 첫 프롬프트보다 비용이 적게 듭니다.

I want to build a booking app for a photography studio. Before you build anything, ask me the five questions you would need answered to build this well. Don't write code yet.

만들기 전에 계획하기

간단한 수정보다 큰 작업이라면 채팅을 Plan 모드로 전환하세요. Plan 모드는 프로젝트를 인식합니다. Lovable이 파일, 데이터베이스, 로그를 살펴보고, 명확화 질문을 던지고, 코드가 작성되기 전에 편집할 수 있는 구조화된 계획을 제안합니다. Plan 모드는 의사 결정용이고 Build 모드는 실행용이며, 언제든지 전환할 수 있습니다.

Plan 모드로 큰 아이디어를 만들 수 있는 조각으로 나눠 보세요:

Here's my app idea: [describe it]. Break it into features I can build and test one at a time, ordered so each step produces something I can click through.

그런 다음 프로젝트에 기억을 부여하세요. knowledge file은 언제나 Lovable이 다루는 컨텍스트의 일부이므로, 무엇을 만들고 있는지 놓치는 법이 없습니다. 좋은 knowledge file은 위키가 아니라 한 페이지짜리 브리프처럼 읽힙니다:

• 제품이 무엇이고 누구를 위한 것인지
• 주요 사용자 여정('고객이 1분 이내에 세션을 예약한다')
• 핵심 기능, 그리고 역할이 여럿이라면 각 역할이 어떻게 동작하는지(주인 대 고객)
• 디자인 지침(색상, 톤, 해야 할 것과 하지 말아야 할 것)
• Lovable이 자꾸 틀리는 부분

Lovable에게 초안을 맡길 수도 있습니다:

Generate a knowledge file for this project based on what we've built so far.

미리 정해 둘 결정이 하나 더 있습니다. 바로 프론트엔드 우선으로 만들기입니다. 샘플 데이터로 시작해 화면과 흐름을 제대로 잡고, 제품이 괜찮다 싶을 때 데이터베이스를 연결하세요. 프론트엔드 우선 방식은 반복이 더 빠르고, 초반 작업의 초점을 데이터 모델이 아니라 제품에 맞춰 줍니다.

디자인 방향을 일찍 정하기

디자인은 나중에 덧입히는 마감 층이 아니라 토대입니다. 첫 프롬프트에서 앱이 어떤 느낌이어야 하는지 Lovable에 알려 주면, Lovable이 만드는 모든 화면이 그 방향을 물려받습니다. 나중으로 미루면 앱 전체에 걸쳐 기본 외형과 싸우게 됩니다.

세 가지 습관이 대부분의 일을 해냅니다:

• 레이아웃만이 아니라 느낌을 묘사하세요. 'calm', 'premium', 'playful', 'bold' 같은 스타일 단어는 타이포그래피, 여백, 색상을 의미 있게 바꿉니다. StudioBook의 문구는 "warm and professional, like a well-lit studio"(밝게 조명된 스튜디오처럼 따뜻하고 전문적으로)입니다. 이 문구를 프롬프트에서 재사용하거나 knowledge file에 넣어 두세요.
• 첫날부터 실제 콘텐츠를 쓰세요. 자리표시자 텍스트는 디자인 문제를 감추고 Lovable에게 작업할 재료를 주지 않습니다. 실제 헤드라인, 진짜 세션 이름, 그럴듯한 가격을 적으세요. 실제 콘텐츠는 레이아웃이 제대로 작동하는지 즉시 드러냅니다.
• 말하려는 대상을 가리키세요. 시각적 변경에는 preview toolbar가 설명보다 빠릅니다. 정확한 요소를 선택해 무엇을 바꿀지 말하거나, 페이지에서 텍스트를 직접 편집하세요.

앱이 작동은 하지만 밋밋해 보인다면, 다듬기 작업을 한 번 돌리세요:

Take a critical pass across the whole app. Tighten typography and spacing. Improve empty states and loading states. Fix anything that feels generic. Don't add new features. Don't change colors unless something is unreadable.

외형과 느낌을 더 깊이 제어하려면 design guidance를 참고하세요.

작은 반복으로 만들기

가장 중요한 습관 하나는 이것입니다. 프롬프트 하나에 변경 하나, preview에서 확인, 그다음 넘어가기입니다. 작은 프롬프트는 쌓여서 힘을 냅니다. 큰 프롬프트는 요청하지도 않았고 풀어내기도 어려운 변경 덩어리로 무너집니다. 페이지가 아니라 컴포넌트 단위로 프롬프트하세요(예약 폼, 일정 카드, 확인 대화상자처럼).

구체적인 프롬프트가 막연한 프롬프트를 이깁니다. 비교해 보세요:

Make the booking page better.

On the booking page, group the time slots by morning and afternoon, disable slots that are already booked, and show a confirmation summary (session type, date, time, price) before the client submits.

두 번째 프롬프트는 위치, 정확한 동작, 경계를 짚어 줍니다. 'and'를 두 번 넘게 쓰고 있다면, 프롬프트를 여러 개로 쪼개어 각각을 확인한 뒤 다음 것을 보내세요. 효과가 좋은 습관 몇 가지를 더 소개합니다:

• 가드레일을 두세요. 원하지 않는 것을 짚어 주는 일은 원하는 것을 짚어 주는 일만큼 유용합니다:

  Redesign the schedule page header. Don't change the navigation or the booking form.

• 설명하지 말고 보여 주세요. 버그나 레이아웃 문제는 문제 화면의 스크린샷을 첨부하세요. 길거나 복잡한 지시는 타이핑하는 대신 마이크로 프롬프트를 받아쓰게 하세요.

• 역할을 지정하세요. 앱에 여러 종류의 사용자가 있다면, 변경이 어느 사용자에게 적용되는지 밝혀서 공유 화면이 다른 사용자를 위한 동작을 넘겨받지 않게 하세요:

  As the studio owner, I want to mark a booking as completed from the schedule page. Clients should not see this control.

• 프롬프트 기법 더 보기: 프롬프트 플레이북이 레이아웃 패턴부터 디자인 유행어까지 이 주제를 깊이 다룹니다.

기능 전체를 만들 때는 매번 Lovable에게 같은 형태를 건네세요:

Build [feature] in steps, and wait for me to confirm each one: 1) create the page, 2) add the UI with sample data, 3) connect the data, 4) add logic and edge cases.

버전 기록이 있어서 과감한 프롬프트도 안전합니다. 모든 변경은 version history에 자동으로 저장됩니다. 기능이 하나 잘 작동할 때마다 그 버전을 북마크해 두면, 언제든 되돌아갈 정상 상태를 늘 확보하게 됩니다. 실험이 잘못되면 복원한 뒤 다른 방향으로 시도하거나, 지난 메시지를 편집하고 Revert and resend를 선택해 그 지점부터 새 방향을 잡으세요. 한 가지 유의할 점이 있습니다. 되돌리기는 코드를 복원할 뿐 데이터베이스 데이터는 복원하지 않습니다.

Try to fix로 몇 번 시도해도 오류가 풀리지 않으면, 다시 시도하는 대신 전술을 바꾸세요. Plan 모드로 옮겨 Lovable에게 먼저 근본 원인을 조사하게 하는 것입니다. Lovable이 앱의 콘솔 로그를 직접 읽으므로, 짧은 프롬프트로도 대개 충분합니다:

Investigate why saving a booking fails. Find the root cause before changing any code.

잘 되던 것이 갑자기 망가지면, 증상이 아니라 시간 흐름을 Lovable에게 가리키세요:

The booking form worked earlier today. Review your recent changes to it, figure out which one broke it, and explain what you find before fixing anything.

데이터가 살아남아야 할 때 백엔드 추가하기

프론트엔드만으로는 부족해지는 순간이 있습니다. 고객이 세션을 예약하고, 페이지를 새로 고치면, 예약이 사라집니다. 샘플 데이터는 브라우저 안에서만 존재하기 때문입니다. 정보가 지속되어야 한다면 앱에는 데이터베이스가 필요합니다.

Lovable에는 완전한 백엔드가 들어 있습니다. 내장 백엔드(Cloud)를 켜고 무엇을 저장할지 설명하세요:

Store bookings in the database: session type, date, time slot, client name, client email, and status. Wire the booking form to save real bookings and show them on the schedule page. Include sensible empty, loading, and error states.

마지막 문장이 중요합니다. 실제 앱은 비어 있거나, 로딩 중이거나, 실패하는 상태로 꽤 많은 시간을 보냅니다. 이런 상태를 미리 요청해 두면 나중에 수정 한 번을 아낍니다.

데이터베이스는 확실한 방법으로 검증하세요. 앱을 브라우저 탭 두 개로 열고, 한쪽에서 예약을 만든 뒤, 다른 쪽을 새로 고칩니다. 예약이 나타나면 진짜 백엔드가 갖춰진 것입니다.

그런 다음 누가 무엇을 보는지 제어하세요. sign-in을 추가하면 Anna는 로그인해 일정을 관리하고 고객은 계정 없이 예약할 수 있습니다. 계정을 추가한 뒤에는 항상 서로 다른 사용자 두 명으로 테스트해, 한 사용자의 비공개 데이터가 다른 사용자에게 보이지 않는지 확인하세요. 지금이 첫 security scan을 돌릴 시점이기도 합니다. 문제를 지금 찾는 편이 배포 시점에 찾는 것보다 훨씬 비용이 적게 듭니다.

백엔드는 필요할 때 훨씬 더 많은 일을 할 수 있습니다: 파일 저장소, AI 기능, 예약 작업, 예약 확인용 맞춤 이메일, 보증금용 결제 같은 것입니다. 각 기능은 지금까지 다른 모든 것을 만든 방식 그대로, 프롬프트로, 제품이 실제로 필요로 할 때 추가하세요.

사용자처럼 테스트하기

출시하기 전에, 처음 온 사람이 하듯 앱을 한 바퀴 둘러보세요:

1. 제대로 보이는가: 모든 페이지를 확인하세요. 빈 상태도 포함합니다(예약이 하나도 없을 때 일정은 어떻게 보이나요?).
2. 제대로 작동하는가: 모든 버튼을 누르고 모든 폼을 제출하세요. 잘못된 입력도 넣어 봅니다(유효하지 않은 이메일, 비어 있는 필수 항목).
3. 데이터가 살아남는가: 무언가를 저장해야 하는 동작마다 새로 고침해 보세요.
4. 접근 권한이 지켜지는가: 두 번째 사용자로 로그인해, 첫 번째 사용자의 데이터를 보거나 바꿀 수 없는지 확인하세요. 앱에 역할이 있다면 큰 변경 뒤마다 각 역할을 다시 테스트하세요.
5. 휴대폰 크기에서: preview 위의 기기 토글로 Mobile view로 전환해 중요한 흐름을 다시 밟아 보세요.

이 체크리스트의 일부는 자동화된 테스트로 Lovable에게 맡길 수도 있습니다. 클릭이 아니라 결과를 요청하세요("test that the form submits"는 증명하는 바가 거의 없습니다):

Test that submitting the booking form actually saves a booking that appears on the schedule page.

배포하고 공유하기

첫 배포 전에 security scan을 돌리고, 심각으로 표시된 것은 모두 고치세요. 그런 다음 오른쪽 위의 Publish를 클릭합니다. 앱이 lovable.app URL에서 공개되며, 준비가 되면 언제든 custom domain을 연결할 수 있습니다.

알아 둘 것이 두 가지 있습니다:

• 공개된 사이트는 스냅숏입니다. 이후 변경을 반영하려면 Publish를 클릭한 다음 Publish changes를 누르세요.
• 공유와 배포는 다릅니다. 공유 링크는 진행 중인 작업을 협업자에게 보여 주고 만료됩니다. 배포는 앱을 웹에 올리는 일입니다.

이제 어디에 알리기 전에 실제 사용자 한 명과 공유해 보세요. Anna의 첫 고객이 세션을 예약하는 모습을 지켜보세요. 실제 사용자 한 명이 겪는 혼란은 스스로 열 번 테스트한 것만큼의 가치가 있고, 그들의 피드백이 다음 빌드 반복을 시작하게 합니다.

앱 키우기

출시는 결승선이 아니라 중간 지점입니다. 출시 후에는 사람들이 무엇을 원하는지 짐작하는 대신 무엇을 하는지 읽기 시작합니다.

앱이 실제로 어떻게 쓰이는지 파악하세요. Analytics는 방문자, 페이지뷰, 유입 경로를 보여 줍니다. 정말 중요한 숫자는 앱 자체에 심어 두세요. StudioBook에서 그 숫자는 완료된 예약입니다. 예약 없는 트래픽은 페이지가 설득력이 없다는 뜻이고, 재방문 고객 없는 예약은 예약 이후의 경험이 문제라는 뜻입니다.

Add a simple owner dashboard showing bookings this week, bookings last week, and the most requested session type. Read-only, no filters yet.

검색에 노출되세요. 공개된 사이트에서 SEO 리뷰를 돌리세요. 이 리뷰는 검색 엔진과 AI 시스템이 페이지를 어떻게 이해하는지 색인부터 성능까지 점검합니다. 채팅에서 Lovable에게 사이트 제목, 설명, 소셜 공유 이미지를 조정해 달라고 요청하면, Anna가 링크를 공유할 때 제대로 보입니다.

사용자와의 피드백 고리를 완성하세요. 초반에 가장 빠른 성장 지렛대는 기능이 아니라 대화입니다. 사람들이 무언가 잘못됐다고 알려 줄 가장 작은 수단을 추가하세요:

Add a small "Something wrong?" link in the footer that opens a form with one message field and an optional email field, and store submissions in the database.

사람들이 있는 곳으로 다가가세요. 확인 이메일은 출시 후 추가할 수 있는 가장 값진 하나인 경우가 많습니다. 폼 제출을 고객이 다시 찾아볼 수 있는 무언가로 바꿔 주기 때문입니다. custom domain은 신뢰를 얻어 줍니다. Anna가 고객에게 보낼 때 브랜드가 담긴 주소는 기본 URL과 다르게 읽힙니다.

Send a confirmation email when a client books a session, with the date, time, session type, and the studio's address.

값어치를 할 때 요금을 매기세요. 사람들이 이미 예약하고 있을 때, 그전이 아니라, 예약 시 보증금을 받는 결제를 추가하세요. 검증되지 않은 흐름에 결제 장벽을 세우면 그 흐름이 작동하는지 여부만 가려집니다.

Take a deposit when a client books: set up payments in test mode, charge 20% of the session price at booking, and mark the booking confirmed only after the payment succeeds.

관찰한 것이 다음 할 일을 고르게 하세요. 모든 새 기능은 실제 무언가로 거슬러 올라가야 합니다. 사용자가 막혔거나, 어떤 숫자가 정체됐거나, 같은 요청이 두 번 들어온 것처럼 말입니다. '멋져 보여서' 만든 기능은 석 달 뒤 삭제하게 되는 기능입니다.

유지하고 발전시키기

운영 중인 앱에는 영웅적 분투가 아니라 리듬이 필요합니다.

사용자가 알리기 전에 문제를 먼저 들으세요. 프로젝트 모니터링은 정해진 주기로 앱을 점검하고, 방문자가 마주친 오류를 잡아내며, 이메일로 알려 줍니다. 무언가 표시되면, 통째로 넘기세요:

Monitoring reports an error when a client submits the booking form without picking a time slot. Investigate the root cause, then fix it.

의도적으로 배포하세요. preview에서 계속 개선하고, 테스트한 다음, Publish → Publish changes를 누르세요. 사용자는 배포하기로 고른 버전만 보게 되고, 그래서 preview는 무언가를 하다 만 상태로 두어도 안전한 공간이 됩니다.

정상 상태를 하나 유지하세요. 기능이 하나 잘 작동할 때마다 그 버전을 북마크하세요. 이렇게 해 두면 몇 달 뒤 '화요일 버전으로 복원'과 '이게 언제 망가졌는지 도무지 모르겠다'를 가르는 차이가 생깁니다.

주기적으로 한 바퀴 돌아보세요. 몇 주에 한 번씩, 처음 온 사람이 된 것처럼 휴대폰으로 앱을 둘러보세요. 운영 중인 앱은 특정한 방식으로 낡아 갑니다. 계정에 데이터가 있어서 한 번도 못 본 빈 상태, 페이지가 늘면서 느려진 흐름, 제품의 실제 동작과 더는 맞지 않는 문구 같은 것들입니다. 그리고 데이터나 역할을 건드리는 변경 뒤에는 테스트의 두 사용자 접근 점검을 반복하세요.

Take a critical pass over the app as it stands. Check empty and error states on every page, flag anything where the copy no longer matches the behavior, and list what you find before changing anything.

프로젝트가 뒤엉키면, remix하세요. 배운 것을 전부 살려 다시 만들 깨끗한 사본이 생기고, 원본은 그대로 남습니다. 두 번째 시도는 대개 시간이 훨씬 덜 걸립니다.

계속 만들기

빠르게 실력을 키운 빌더들에게서 얻은 마지막 습관이 하나 있습니다. 작은 것을 자주 만드는 것입니다. 버리는 셈 치고 만든 프로젝트 하나하나가 기술을 가르쳐 주고, 그 반복이 쌓입니다. 스스로가 자신의 첫 사용자이기도 하니, 자신을 위해 만들고, 사용자가 하듯 테스트하고, 실제 피드백이 다음에 만들 것을 고르게 하세요.

반복 고리는 절대 변하지 않습니다. 설명하고, 다듬고, 배포하는 것입니다. 아무리 야심 찬 앱이라도, 만드는 모든 앱은 이 고리의 반복입니다.

코드를 소유하기

Lovable이 만드는 모든 것은 진짜 애플리케이션이고, 그 코드는 온전히 자신의 것입니다:

• Code view: 궁금하거나 정밀하게 제어하고 싶을 때 에디터에서 바로 코드를 읽고 편집합니다.
• Git sync: 프로젝트를 GitHub이나 GitLab에 연결하면 자신의 저장소에 동기화된 사본이 생깁니다. 즐겨 쓰는 IDE에서 편집하거나 팀원이 기여하게 할 수 있고, 변경은 양방향으로 오갑니다.
• 이식성: 원할 때 언제든 Lovable 밖에서 앱을 호스팅할 수 있습니다. 어떤 것에도 얽매이지 않습니다.

이 중 무엇도 출시에 필수는 아닙니다. 만드는 제품이 진정으로 자신의 것이 되도록 마련된 장치일 뿐입니다.

FAQ

관련 주제

• 러버블 사용법: 빠른 시작
• FAQ
• 프롬프팅 모범 사례
• 앱에 결제 기능 추가하기
• Lovable에 오신 것을 환영합니다