나만의 러버블 제작 시스템 완성하기

이제는 '따라 하기'를 넘어 '반복 가능한 시스템'으로 갑니다

이제 우리는 러버블을 처음 여는 법, 프롬프트를 쓰는 법, 포트폴리오·예약·견적·디지털 상품 페이지를 만드는 법, Supabase로 데이터를 저장하는 법, 오류를 다루고 배포하는 법까지 지나왔습니다. 처음에는 "내가 이걸 할 수 있을까?"가 질문이었다면, 여기까지 따라온 지금은 질문이 달라져야 합니다.

"다음 아이디어는 어떤 순서로 만들면 될까?"

이 장의 목표는 바로 그 질문에 답하는 것입니다. 러버블은 코딩 지식이 깊지 않아도 웹사이트와 앱을 만들 수 있게 해주는 AI 기반 제작 도구입니다. 공식 소개에서도 웹사이트, 앱, 디지털 제품을 빠르게 만들 수 있고 깊은 코딩 지식이 필요하지 않다는 점을 강조합니다.¹ 하지만 도구가 좋다고 해서 매번 즉흥적으로 만들면 결과물은 들쭉날쭉해집니다. 특히 무료 사용자라면 크레딧을 함부로 태울 수 없습니다.

그래서 마지막 장에서는 '한 번 따라 하는 튜토리얼'이 아니라 '계속 반복해서 쓰는 제작 시스템'을 만듭니다. 앞으로 어떤 아이디어가 떠오르든, 이 흐름에 넣으면 작은 웹페이지나 웹서비스로 바꿀 수 있게 만드는 것입니다.

러버블 제작 시스템의 전체 흐름

나만의 제작 시스템은 복잡할 필요가 없습니다. 오히려 초보자에게 좋은 시스템은 단순해야 합니다. 머릿속에서 아이디어가 떠올랐을 때 바로 러버블을 열지 않고, 먼저 아이디어를 작게 줄이고, 외부 AI에서 정리하고, 화면을 스케치하고, 그다음 구현합니다. 이 순서만 지켜도 크레딧 낭비가 크게 줄어듭니다.

전체 흐름은 다음과 같습니다.

1. 아이디어 선택

2. 외부 AI에서 기획 정리

3. 화면 스케치

4. PRD 작성

5. 러버블 첫 구현

6. 작은 단위로 수정

7. 배포

8. 피드백 수집

9. 유지보수와 다음 버전 결정

이 흐름에서 가장 중요한 원칙은 "러버블에서는 고민하지 않는다"입니다. 고민은 ChatGPT, Gemini, Claude 같은 외부 AI나 종이 위에서 합니다. 러버블은 이미 정리된 내용을 실제 화면과 기능으로 바꾸는 작업장에 가깝습니다. Lovable의 ChatGPT 앱 문서에서도 ChatGPT에서 아이디어와 요구사항을 구체화한 뒤, 방향이 정해졌을 때 러버블로 실제 앱을 만들도록 연결하는 흐름을 설명합니다.² 즉, 생각하는 곳과 만드는 곳을 나누는 방식은 러버블을 더 잘 쓰기 위한 자연스러운 전략입니다.

처음부터 "회원가입, 결제, 관리자 대시보드, 이메일 자동화, AI 추천, 모바일 앱까지 다 되는 서비스"를 만들겠다고 하면 거의 반드시 꼬입니다. 대신 이렇게 물어보세요.

"이 아이디어를 검증하는 데 꼭 필요한 화면 하나는 무엇인가?"

프리랜서라면 포트폴리오와 문의 페이지 하나면 충분할 수 있습니다. 상담형 사업자라면 예약 신청 페이지가 먼저입니다. 전자책을 팔고 싶다면 결제 기능보다 랜딩 페이지와 대기자 신청 폼이 먼저입니다. 크고 멋진 서비스보다, 작고 공개 가능한 첫 버전이 훨씬 강합니다.

1단계: 아이디어를 고르는 기준

아이디어는 많을수록 좋은 것 같지만, 실제 제작 단계에서는 오히려 방해가 됩니다. 특히 초보자는 "좋은 아이디어"보다 "작게 만들 수 있는 아이디어"를 골라야 합니다.

다음 프로젝트를 고를 때는 난이도보다 검증 가능성을 먼저 보세요. 멋진 기능이 많은 프로젝트가 아니라, 빠르게 공개해서 누군가의 반응을 볼 수 있는 프로젝트가 좋습니다.

좋은 첫 프로젝트는 보통 이런 특징을 가집니다.

• 한 명의 구체적인 사용자가 있다.

• 사용자가 해야 할 핵심 행동이 하나다.

• 데이터 저장이 없어도 첫 버전을 보여줄 수 있다.

• 결제 없이도 관심도를 확인할 수 있다.

• 7일 안에 배포할 수 있다.

예를 들어 "프리랜서를 위한 올인원 비즈니스 운영 플랫폼"은 너무 큽니다. 하지만 "영상 편집 프리랜서가 작업 문의를 받을 수 있는 포트폴리오+문의 페이지"는 작고 명확합니다. "동네 공방 운영자를 위한 예약 관리 SaaS"는 큽니다. 하지만 "원데이 클래스 상담 신청을 받는 모바일 예약 페이지"는 만들 수 있습니다.

아이디어를 고를 때는 다음 문장으로 줄여보세요.

나는 [대상 사용자]가 [겪는 문제]를 해결하기 위해 [핵심 행동]을 할 수 있는 [작은 웹페이지/웹서비스]를 만든다.

예시는 이렇습니다.

나는 1인 디자인 스튜디오 대표가 신규 고객 문의를 더 쉽게 받기 위해 포트폴리오를 보고 상담 신청을 할 수 있는 단일 랜딩 페이지를 만든다.

이 한 문장이 흐릿하면 러버블 결과물도 흐릿해집니다. 반대로 이 한 문장이 선명하면 PRD, 화면 구성, 첫 프롬프트가 모두 쉬워집니다.

2단계: 외부 AI에서 기획을 끝내기

러버블 안에서 "뭘 만들까요?", "어떤 기능이 좋을까요?", "대상 고객은 누구일까요?" 같은 대화를 오래 이어가면 구현 전에 크레딧과 집중력을 잃기 쉽습니다. 따라서 기획은 외부 AI에서 끝내는 것이 좋습니다.

외부 AI에게는 막연히 "기획해줘"라고 하지 말고, 역할과 산출물을 분명히 알려줍니다. 여기서 산출물은 IA, 유저 여정, PRD입니다. IA는 Information Architecture의 줄임말로, 웹사이트의 정보 구조를 뜻합니다. 쉽게 말해 어떤 페이지와 섹션이 어떤 순서로 배치되는지 정리한 뼈대입니다. 유저 여정은 사용자가 처음 들어와서 어떤 생각과 행동을 거쳐 문의, 예약, 구매 같은 목표 행동에 도달하는지 정리한 흐름입니다. PRD는 Product Requirements Document의 줄임말로, 제품 요구사항 정의서입니다. "무엇을 왜 어떻게 만들 것인가"를 러버블이 이해할 수 있게 정리한 문서라고 생각하면 됩니다.

외부 AI에는 이렇게 요청하면 됩니다.

너는 1인 사업자를 위한 웹서비스 기획자야.
아래 아이디어를 러버블에서 구현할 수 있는 작은 MVP로 줄여줘.

아이디어:
[여기에 한 문장 아이디어 입력]

조건:
- 코딩을 모르는 초보자가 Lovable로 만들 예정
- 무료 사용자라 크레딧을 아껴야 함
- 첫 버전은 7일 안에 배포 가능한 범위
- 로그인, 결제, 복잡한 관리자 기능은 제외
- 핵심 행동은 하나만 남길 것

다음 형식으로 정리해줘.
1. 대상 사용자
2. 해결할 문제
3. 핵심 전환 행동
4. 페이지 구조 IA
5. 사용자 여정
6. 꼭 필요한 기능
7. 이번 버전에서 제외할 기능
8. Lovable에 넣을 수 있는 PRD 초안

이 프롬프트의 핵심은 "줄여줘"입니다. AI는 우리가 요청하면 기능을 계속 늘리는 경향이 있습니다. 그래서 처음부터 제외할 기능을 정해두어야 합니다. 로그인, 결제, 관리자 페이지, 알림, AI 추천, 복잡한 데이터 분석은 초보자의 첫 버전에 어울리지 않는 경우가 많습니다. 나중에 붙이면 됩니다. 지금은 살아 있는 첫 화면을 만드는 것이 먼저입니다.

3단계: 종이 스케치로 화면을 잠그기

기획이 끝났다면 러버블을 열기 전에 화면을 먼저 그립니다. 멋진 디자인이 아니어도 됩니다. 종이에 네모 상자를 그리고 위에서 아래로 섹션을 배치하는 정도면 충분합니다.

랜딩 페이지라면 보통 이런 흐름이 안정적입니다.

• 첫 화면: 누구를 위한 무엇인지 한눈에 보이는 제목과 CTA 버튼

• 신뢰 형성: 작업 사례, 후기, 숫자, 자격, 대표 이미지

• 설명: 제공 서비스, 진행 방식, 가격 또는 범위

• 행동 유도: 문의, 예약, 신청, 다운로드 버튼

• 보조 정보: FAQ, 연락처, 푸터

스케치를 하는 이유는 러버블에게 예쁜 그림을 보여주기 위해서만이 아닙니다. 내 머릿속의 모호함을 없애기 위해서입니다. "대충 전문가 느낌으로"라고 말하면 러버블도 대충 만듭니다. 하지만 "첫 화면에는 제목, 설명, 버튼 2개, 오른쪽에는 작업 이미지 카드 3개"라고 말하면 결과물이 훨씬 가까워집니다.

FigJam이나 Miro 같은 도구를 써도 좋고, 노트에 손으로 그려도 됩니다. 중요한 것은 디자인 도구의 종류가 아니라 화면의 순서와 역할을 미리 정하는 것입니다. Lovable 관련 모범 사례에서도 사용자 여정을 먼저 시각화하고, 사용자가 어떤 흐름으로 목표 행동까지 가는지 파악한 뒤 개발하는 접근을 권장합니다.³

4단계: 프로젝트마다 복사해서 쓰는 PRD 템플릿

이제 반복 가능한 템플릿을 만들 차례입니다. 아래 PRD 템플릿은 앞으로 어떤 프로젝트든 복사해서 쓸 수 있습니다. 빈칸만 바꾸면 됩니다.

# PRD: [프로젝트 이름]

## 1. 한 줄 소개
[대상 사용자]가 [문제]를 해결하기 위해 [핵심 행동]을 할 수 있는 [웹페이지/웹서비스]입니다.

## 2. 대상 사용자
- 주요 사용자: [예: 개인 사업자, 프리랜서, 강사, 상담가]
- 사용자의 현재 문제: [예: 문의가 흩어져 있고 신뢰를 보여줄 페이지가 없음]
- 사용자가 원하는 결과: [예: 작업 사례를 보고 빠르게 상담 신청]

## 3. 핵심 목표
이번 버전의 목표는 [핵심 전환 행동]입니다.
예: 방문자가 서비스를 이해하고 상담 신청 폼을 제출한다.

## 4. 이번 버전에서 포함할 기능
- [기능 1]
- [기능 2]
- [기능 3]

## 5. 이번 버전에서 제외할 기능
- 로그인 기능 제외
- 결제 기능 제외
- 복잡한 관리자 페이지 제외
- 외부 API 연동 제외

## 6. 페이지 구조 IA
1. Hero 섹션: [제목, 설명, CTA]
2. 문제 공감 섹션: [사용자의 어려움]
3. 서비스 소개 섹션: [제공 내용]
4. 작업 사례/후기 섹션: [신뢰 요소]
5. 신청/문의 섹션: [폼 또는 외부 링크]
6. FAQ 섹션
7. 푸터

## 7. 사용자 여정
방문자는 첫 화면에서 서비스를 이해한다.
아래로 내려가며 문제와 해결책을 확인한다.
작업 사례 또는 후기를 통해 신뢰를 얻는다.
마지막으로 [문의/예약/신청] 버튼을 눌러 행동한다.

## 8. 디자인 방향
- 분위기: [예: 깔끔한, 신뢰감 있는, 따뜻한, 프리미엄]
- 색상: [예: 흰색 배경, 네이비 포인트, 연한 회색 카드]
- 폰트 느낌: [예: 가독성 좋은 산세리프]
- 레이아웃: 모바일 우선, 넉넉한 여백, 카드형 구성

## 9. 콘텐츠 초안
### Hero 제목
[제목]

### Hero 설명
[설명]

### CTA 문구
[예: 무료 상담 신청하기]

### 서비스 항목
- [서비스 1]
- [서비스 2]
- [서비스 3]

### FAQ
Q1. [질문]
A1. [답변]

Q2. [질문]
A2. [답변]

## 10. 데이터와 저장 방식
첫 버전에서는 실제 데이터베이스를 사용하지 않습니다.
문의는 [구글폼/타입폼/이메일/카카오톡 채널]로 연결합니다.
나중에 필요하면 Supabase 저장으로 확장합니다.

## 11. 성공 기준
- 모바일에서 보기 좋게 표시된다.
- 핵심 CTA 버튼이 잘 보인다.
- 방문자가 30초 안에 무엇을 제공하는지 이해한다.
- 문의 또는 신청 경로가 실제로 작동한다.

PRD는 길다고 좋은 것이 아닙니다. 러버블이 구현해야 할 내용과 구현하지 말아야 할 내용이 분명해야 좋습니다. 특히 "이번 버전에서 제외할 기능"은 꼭 넣어야 합니다. 이 부분이 없으면 AI는 친절하게 많은 기능을 붙이려 하고, 초보자는 그 기능을 감당하지 못해 프로젝트를 멈추게 됩니다.

5단계: 첫 프롬프트 템플릿

PRD가 준비되었다면 이제 러버블에 첫 프롬프트를 넣습니다. 첫 프롬프트는 프로젝트의 방향을 결정합니다. 여기서 너무 많은 기능을 한꺼번에 요구하면 결과물이 복잡해지고 수정도 어려워집니다.

러버블 공식 모범 사례에서도 명확하고 구체적인 프롬프트, 작은 단위로 나누는 작업, 중요한 지시사항 반복, 건드리지 말아야 할 영역 지정 등을 권장합니다.⁴ 초보자는 이 원칙을 특히 엄격하게 지켜야 합니다.

아래 템플릿을 복사해서 사용하세요.

아래 PRD를 바탕으로 첫 번째 버전의 웹페이지를 만들어주세요.

중요한 원칙:
- 첫 버전은 단일 랜딩 페이지로 만들어주세요.
- 모바일 우선 반응형으로 만들어주세요.
- 로그인, 결제, 관리자 페이지, 복잡한 데이터베이스 연동은 만들지 마세요.
- 지금은 더미 데이터와 정적 콘텐츠로 구현해주세요.
- 문의/신청 버튼은 [이메일/구글폼/카카오톡 채널/타입폼 링크]로 연결해주세요.
- 디자인은 [원하는 분위기] 느낌으로 해주세요.
- 불필요한 기능을 추가하지 말고 PRD에 있는 범위만 구현해주세요.

PRD:
[여기에 PRD 붙여넣기]

먼저 전체 페이지를 구현한 뒤, 화면 아래까지 자연스럽게 이어지도록 구성해주세요.

첫 프롬프트에서 가장 중요한 문장은 "불필요한 기능을 추가하지 말고 PRD에 있는 범위만 구현해주세요"입니다. 초보자의 프로젝트는 기능 부족으로 실패하기보다 기능 과잉으로 실패하는 경우가 많습니다. 만들 수 있는 것과 운영할 수 있는 것은 다릅니다. 운영할 수 있는 만큼만 만들어야 합니다.

6단계: 수정 프롬프트 템플릿

첫 결과물이 나오면 마음에 안 드는 부분이 보입니다. 이때 많은 초보자가 다시 긴 프롬프트를 넣습니다.

"전체적으로 더 예쁘게 해줘. 문구도 고치고 색도 바꾸고 모바일도 맞춰주고 폼도 추가하고 버튼도 바꿔줘."

이런 요청은 위험합니다. AI가 잘 작동하던 부분까지 건드릴 수 있습니다. 수정은 작게, 정확하게, 한 번에 하나씩 해야 합니다. Lovable의 Visual Edit 기능은 텍스트, 색상, 폰트, 레이아웃의 작은 조정에 빠르고 유용하며, 프롬프트 대신 활용하면 안전하게 수정할 수 있다는 설명도 공식 모범 사례에 포함되어 있습니다.⁴ 그러니 작은 문구와 색상은 Visual Editor로 끝내고, 구조나 기능 변경만 프롬프트로 요청하는 습관을 유지하세요.

수정 프롬프트는 아래처럼 씁니다.

[수정할 위치]만 수정해주세요.

현재 문제:
[무엇이 마음에 들지 않는지 구체적으로 설명]

원하는 변경:
[어떻게 바꾸고 싶은지 설명]

주의:
- 다른 섹션의 레이아웃과 기능은 변경하지 마세요.
- 기존 CTA 링크와 폼 동작은 유지해주세요.
- 텍스트/디자인만 수정하고 로직은 건드리지 마세요.

예를 들면 이렇게 쓸 수 있습니다.

Hero 섹션만 수정해주세요.

현재 문제:
첫 화면의 제목이 너무 일반적이고, 버튼이 잘 눈에 띄지 않습니다.

원하는 변경:
제목을 "작은 브랜드를 위한 빠른 웹사이트 제작"으로 바꿔주세요.
설명 문구는 2줄 이내로 줄여주세요.
CTA 버튼은 더 크고 대비가 강한 색으로 바꿔주세요.

주의:
- 아래 섹션들은 변경하지 마세요.
- CTA 링크는 기존 링크를 유지해주세요.
- 기능은 변경하지 말고 시각적 수정만 해주세요.

기능 수정은 더 조심해야 합니다.

문의 폼 제출 후 동작만 수정해주세요.

현재 문제:
제출 버튼을 눌러도 사용자가 성공했는지 알기 어렵습니다.

원하는 변경:
제출 후 화면에 "문의가 접수되었습니다. 24시간 안에 답변드릴게요."라는 성공 메시지를 보여주세요.
실패한 경우에는 "제출에 실패했습니다. 이메일로 직접 문의해주세요."라는 안내를 보여주세요.

주의:
- 폼 필드 구성은 변경하지 마세요.
- 페이지 전체 디자인은 변경하지 마세요.
- 기존 데이터 저장 방식이 있다면 유지해주세요.

이렇게 수정 범위를 좁히면 크레딧을 덜 쓰고, 오류가 생겨도 원인을 찾기 쉽습니다.

7단계: 디버깅 프롬프트 템플릿

오류가 나면 사람은 급해집니다. 빨리 고치고 싶어서 "고쳐줘"라고 말하게 됩니다. 하지만 초보자에게 더 좋은 방식은 먼저 원인을 설명받는 것입니다. 그래야 같은 문제가 반복될 때 덜 무섭습니다.

디버깅 프롬프트는 이렇게 씁니다.

오류를 바로 수정하기 전에 먼저 원인을 분석해주세요.

상황:
[무엇을 하다가 오류가 났는지]

오류 메시지:
[보이는 오류 문구를 그대로 붙여넣기]

원하는 답변 순서:
1. 이 오류가 무슨 뜻인지 초보자도 이해할 수 있게 설명
2. 가능한 원인 3가지
3. 가장 가능성이 높은 원인
4. 수정 전에 확인해야 할 것
5. 수정해도 되는 범위 제안

주의:
- 아직 코드를 수정하지 말고 먼저 분석만 해주세요.

분석을 보고 납득이 되면 그때 수정 요청을 합니다.

방금 분석한 원인 중 [선택한 원인]을 기준으로 수정해주세요.

수정 범위:
[파일/화면/기능]

주의:
- 관련 없는 UI 디자인은 변경하지 마세요.
- 기존에 정상 작동하던 기능은 유지해주세요.
- 수정 후 어떤 부분을 테스트해야 하는지 알려주세요.

Lovable의 모범 사례에서도 복잡한 로직이나 데이터베이스 문제를 디버깅할 때 Plan mode를 활용하고, 여러 번의 자동 수정 시도 후에는 접근을 바꾸는 것이 좋다고 안내합니다.⁴ 초보자는 특히 "세 번 이상 같은 방식으로 고치려 하지 않는다"는 원칙을 세우는 것이 좋습니다. 두세 번 고쳐도 안 되면 프롬프트를 바꾸거나, 기능을 줄이거나, 이전 안정 버전으로 돌아가는 편이 낫습니다.

무료 사용자용 7일 제작 플랜

무료 사용자에게 가장 중요한 것은 속도가 아니라 절제입니다. 하루에 조금씩 진행하되, 러버블에서 쓰는 시간을 짧게 유지하세요. 기획과 문구 작성은 외부 AI에서 충분히 하고, 러버블에서는 정리된 지시만 넣습니다.

아래는 무료 사용자에게 추천하는 7일 플랜입니다.

이 플랜의 핵심은 1~4일차에 러버블을 열지 않는 것입니다. 손이 근질거려도 참아야 합니다. 기획이 선명해질수록 5일차의 첫 구현 성공률이 올라갑니다.

7일차에는 완벽하지 않아도 공개하세요. 친구 3명, 잠재 고객 3명, 같은 업계 사람 3명에게 링크를 보내보세요. "어때?"라고 묻지 말고 이렇게 묻습니다.

이 페이지를 보고 제가 무엇을 제공하는 사람인지 10초 안에 이해되나요?
문의하거나 신청한다면 어디를 눌러야 할지 바로 보이나요?
믿음이 안 가는 부분이 있다면 어디인가요?

좋은 피드백은 칭찬보다 구체적인 망설임에서 나옵니다. "좋은데?"보다 "가격이 어디 있는지 모르겠어요"가 훨씬 가치 있습니다.

유료 사용자용 주말 집중 제작 플랜

유료 사용자라면 크레딧 여유가 조금 더 있기 때문에 주말에 몰아서 만들 수 있습니다. 다만 유료라고 해서 즉흥적으로 해도 된다는 뜻은 아닙니다. 유료 사용자는 더 많은 기능을 만들 수 있는 만큼 더 쉽게 복잡해집니다. 그래서 주말 플랜 역시 범위를 제한해야 합니다.

유료 사용자에게 추천하는 전략은 "한 프로젝트를 더 크게"가 아니라 "한 프로젝트를 더 안정적으로"입니다. 예를 들어 무료 사용자는 문의 버튼을 이메일 링크로 연결한다면, 유료 사용자는 Supabase 저장이나 이메일 알림까지 붙여볼 수 있습니다. 하지만 결제, 로그인, 관리자 대시보드, 자동화까지 한 주말에 모두 붙이는 것은 여전히 위험합니다.

주말 집중 플랜에서는 토요일 저녁에 반드시 멈춤 시간을 두세요. 이때 새 기능을 추가하지 말고, 현재 버전이 실제로 작동하는지 확인합니다. 버튼은 눌리는지, 모바일에서 글자가 잘리는 곳은 없는지, 폼 제출 후 안내가 나오는지, 배포 링크가 열리는지 확인합니다. 일요일은 만드는 날이 아니라 공개 가능한 상태로 정리하는 날에 가깝습니다.

완성 후 운영 체크리스트

웹페이지는 배포하면 끝이 아닙니다. 오히려 그때부터 진짜 시작입니다. 운영을 생각하지 않고 만든 페이지는 몇 주 뒤에 내가 무엇을 왜 바꿨는지 기억나지 않습니다. 특히 부업이나 프리랜서 활동으로 이어가려면 작게라도 관리 체계가 필요합니다.

아래 체크리스트를 프로젝트마다 복사해서 사용하세요.

기본 운영 체크리스트

• 배포 URL을 문서에 기록했다.

• 프로젝트 목적과 대상 사용자를 한 문장으로 기록했다.

• 사용한 외부 링크를 정리했다.

• 문의 이메일, 구글폼, 카카오톡 채널 링크가 정상 작동한다.

• 모바일, 태블릿, 데스크톱에서 주요 화면을 확인했다.

• CTA 버튼이 첫 화면과 마지막 화면에 모두 있다.

• 개인정보를 받는 경우 안내 문구를 넣었다.

• 테스트 제출을 1회 이상 해봤다.

• 피드백을 받을 사람 목록을 정했다.

• 다음 수정 후보를 별도 문서에 적었다.

백업 체크리스트

• PRD 원본을 따로 저장했다.

• 첫 프롬프트와 주요 수정 프롬프트를 저장했다.

• 최종 문구를 문서로 백업했다.

• 주요 이미지와 로고 파일을 폴더에 모았다.

• 안정적으로 작동하는 버전을 표시해두었다.

• 가능하다면 GitHub 또는 별도 저장소에 코드를 백업했다.

Lovable 공식 모범 사례에서는 안정적인 버전을 표시해두고, 변경 후 문제가 생겼을 때 이전 버전과 비교하는 방식도 권장합니다.⁴ 초보자에게 버전 관리는 어려운 말처럼 들리지만, 본질은 간단합니다. "잘 되던 순간을 기억해두는 것"입니다. 잘 되던 순간을 저장해두면, 망가졌을 때 돌아갈 곳이 생깁니다.

고객 피드백 체크리스트

피드백은 많이 받는 것보다 제대로 받는 것이 중요합니다. 가족이나 친구에게 "괜찮아?"라고 물으면 대부분 괜찮다고 합니다. 대신 실제 행동을 기준으로 물어야 합니다.

• 이 페이지가 누구를 위한 것인지 이해했는가?

• 어떤 서비스를 제공하는지 이해했는가?

• 문의하거나 신청하려면 어디를 눌러야 하는지 알겠는가?

• 가격, 일정, 진행 방식 중 부족한 정보가 있는가?

• 믿음을 주는 요소가 충분한가?

• 모바일에서 불편한 부분이 있는가?

• 실제로 신청하지 않았다면 가장 큰 이유는 무엇인가?

피드백을 받으면 바로 러버블을 열지 마세요. 먼저 피드백을 모아 비슷한 의견끼리 묶습니다. 한 사람이 말한 취향은 반영하지 않아도 됩니다. 하지만 세 명 이상이 같은 부분에서 헷갈렸다면 수정 후보가 됩니다.

유지보수 문서 템플릿

운영이 길어질수록 문서화가 힘을 발휘합니다. 문서화라고 해서 거창한 개발 문서를 만들 필요는 없습니다. 내가 나중에 봐도 이해할 수 있을 정도면 충분합니다.

아래 템플릿을 프로젝트마다 하나씩 만들어두세요.

# 운영 문서: [프로젝트 이름]

## 1. 프로젝트 목적
[이 웹페이지/웹서비스를 만든 이유]

## 2. 대상 사용자
[누가 사용하는가]

## 3. 핵심 행동
[문의, 예약, 신청, 구매, 다운로드 등]

## 4. 배포 주소
[URL]

## 5. 사용한 도구
- 제작: Lovable
- 기획: [ChatGPT/Gemini 등]
- 폼: [구글폼/타입폼/Supabase 등]
- 도메인: [사용 시 기록]
- 이메일: [사용 시 기록]

## 6. 주요 링크
- 문의 링크:
- 예약 링크:
- 관리자 확인 링크:
- 분석 도구 링크:

## 7. 주요 프롬프트 기록
### 첫 프롬프트
[붙여넣기]

### 중요한 수정 프롬프트
[붙여넣기]

## 8. 변경 이력
- [날짜] 첫 배포
- [날짜] Hero 문구 수정
- [날짜] 문의 버튼 위치 변경

## 9. 피드백 모음
- [피드백 1]
- [피드백 2]
- [피드백 3]

## 10. 다음 개선 후보
- [개선 1]
- [개선 2]
- [개선 3]

이 문서는 미래의 나를 돕습니다. 한 달 뒤에 다시 수정하려고 러버블을 열었을 때, 왜 이런 구조로 만들었는지 기억나지 않으면 또 처음부터 헤매게 됩니다. 문서가 있으면 다음 수정이 빨라지고, 다른 사람에게 도움을 요청할 때도 훨씬 수월합니다.

다음 프로젝트를 고르는 법

첫 프로젝트를 배포하고 나면 이상한 욕심이 생깁니다. "이제 더 어려운 걸 만들어볼까?" 물론 언젠가는 그래도 됩니다. 하지만 부업이나 사업 검증이 목적이라면 난이도를 올리는 것이 정답은 아닙니다. 다음 프로젝트는 더 어려운 것이 아니라 더 빨리 검증할 수 있는 것이어야 합니다.

다음 프로젝트를 고를 때는 이 질문을 던져보세요.

이 아이디어는 작게 출시해서 7일 안에 반응을 볼 수 있는가?

대답이 "아니요"라면 아직 큽니다. 줄여야 합니다.

예를 들어 "프리랜서 매칭 플랫폼"은 큽니다. 하지만 "영상 편집자를 찾는 사람을 위한 견적 요청 페이지"는 작습니다. "온라인 강의 플랫폼"은 큽니다. 하지만 "전자책 대기자 모집 랜딩 페이지"는 작습니다. "AI 기반 회계 관리 서비스"는 큽니다. 하지만 "개인 사업자 지출 정리 체크리스트 다운로드 페이지"는 작습니다.

작게 출시한다는 것은 대충 만든다는 뜻이 아닙니다. 핵심 가설만 검증한다는 뜻입니다.

• 사람들이 이 문제에 관심이 있는가?

• 이 문구를 이해하는가?

• 이 제안에 문의하거나 신청하는가?

• 돈을 내기 전 단계의 행동이라도 하는가?

• 내가 이 프로젝트를 계속 운영할 마음이 생기는가?

이 질문에 답을 얻으면 다음 버전이 보입니다. 반응이 없다면 디자인 문제가 아니라 제안 자체가 약할 수 있습니다. 반응은 있는데 문의가 적다면 CTA나 신뢰 요소가 부족할 수 있습니다. 문의는 오는데 실제 고객이 되지 않는다면 가격, 대상, 제공 범위를 조정해야 할 수 있습니다.

러버블은 답을 대신 찾아주는 도구가 아닙니다. 답을 빨리 실험하게 해주는 도구입니다.

나만의 제작 시스템 만들기

이제 이 책의 내용을 하나의 시스템으로 묶어보겠습니다. 아래 문장을 그대로 저장해두면 좋습니다.

나는 아이디어가 떠오르면 바로 만들지 않는다. 먼저 한 문장으로 줄이고, 외부 AI에서 IA·유저 여정·PRD를 만든다. 종이 또는 기획 도구로 화면을 스케치한 뒤, 러버블에는 구현할 내용만 넣는다. 첫 버전은 작게 만들고, Visual Editor로 작은 수정을 처리하며, 배포 후 실제 피드백을 보고 다음 버전을 결정한다.

이 문장이 바로 당신의 러버블 제작 시스템입니다.

처음에는 템플릿을 보면서 따라 하게 될 것입니다. 두 번째 프로젝트에서는 일부 문장을 바꾸게 됩니다. 세 번째 프로젝트부터는 자신만의 PRD 문체가 생깁니다. 네 번째 프로젝트쯤 되면 어떤 기능이 위험한지, 어떤 요청이 크레딧을 많이 쓰는지, 어떤 화면이 반응을 얻는지 감이 옵니다.

그때부터는 도구를 쓰는 사람이 아니라, 도구를 다루는 사람이 됩니다.

마지막으로: 완성보다 출시

초보자가 가장 자주 빠지는 함정은 완성이라는 단어입니다. 완성된 뒤에 공개하겠다고 생각하면 대부분 공개하지 못합니다. 웹페이지는 머릿속에서 완성되는 것이 아니라, 사람들에게 보여주고 반응을 받으면서 완성됩니다.

처음 만든 페이지는 어색할 수 있습니다. 문구가 부족할 수 있습니다. 색상이 마음에 들지 않을 수 있습니다. 모바일에서 여백이 살짝 이상할 수도 있습니다. 그래도 핵심 메시지가 보이고, 버튼이 작동하고, 누군가에게 링크를 보낼 수 있다면 그것은 이미 중요한 단계에 도착한 것입니다.

당신에게 필요한 것은 거대한 개발 실력이 아니라 반복 가능한 작은 실행력입니다. 아이디어를 줄이고, 기획을 정리하고, 화면을 그리고, 러버블로 구현하고, 배포하고, 피드백을 받는 힘. 이 힘이 쌓이면 포트폴리오 페이지 하나가 상담 페이지가 되고, 상담 페이지가 상품 랜딩 페이지가 되고, 상품 랜딩 페이지가 작은 부업의 시작점이 됩니다.

앞으로 새 아이디어가 떠오르면 이렇게 시작하세요.

"이걸 7일 안에 작게 보여준다면 어떤 모습일까?"

그 질문에 답할 수 있다면, 당신은 이미 다음 프로젝트를 만들 준비가 되어 있습니다.

참고

¹Lovable 공식 홈페이지

²Lovable ChatGPT App 문서

³The Guideline for a Successful Lovable Project

⁴Lovable Best Practices 문서