더 큰 프로젝트로 가기 전에 알아야 할 확장 도구들

확장 도구는 '처음부터'가 아니라 '막히기 직전'에 배운다

러버블로 첫 웹페이지를 만들고, 배포하고, 사람들에게 보여주기 시작하면 어느 순간 이런 생각이 듭니다.

"이제 결제도 붙여야 하나?"

"문의가 들어오면 자동으로 이메일이 가게 만들 수 있나?"

"내 도메인으로 바꾸면 더 전문적으로 보일까?"

"나중에 개발자에게 넘기려면 지금 뭘 준비해야 하지?"

이 질문들이 나오기 시작했다면 좋은 신호입니다. 이제 당신은 단순히 예쁜 페이지를 만드는 단계를 지나, 웹페이지를 실제 사업 도구로 운영하는 단계에 가까워지고 있다는 뜻입니다.

하지만 여기서 조심해야 합니다. 초보자가 가장 많이 빠지는 함정은 '아직 방문자도 없는데 확장 도구부터 붙이는 것'입니다. 결제, 자동화, 이메일, GitHub, 도메인, 분석 도구를 한꺼번에 붙이면 멋져 보입니다. 문제는 그만큼 설정할 것도 많아지고, 오류가 날 곳도 많아지고, 러버블 크레딧도 빠르게 사라진다는 점입니다.

확장 도구는 장식품이 아닙니다. 막힌 지점을 뚫기 위한 도구입니다. 문의가 정리되지 않을 때 Google Sheets나 Supabase가 필요해지고, 결제를 수동으로 받기 번거로울 때 Stripe나 Paddle이 필요해지고, 고객에게 자동 안내를 보내야 할 때 Resend나 브랜드 이메일이 필요해집니다. 개발자와 협업하거나 장기 유지보수를 해야 할 때 GitHub가 필요해집니다.

이 장에서는 러버블 주변에 붙일 수 있는 대표적인 확장 도구를 '언제 필요한가'라는 기준으로 정리합니다. 지금 당장 모두 사용할 필요는 없습니다. 다만 이름과 역할을 미리 알아두면, 프로젝트가 커졌을 때 덜 당황합니다.

큰 프로젝트가 되어가고 있다는 신호

처음 만든 페이지가 단순한 포트폴리오나 랜딩 페이지라면 러버블만으로도 충분한 경우가 많습니다. 특히 무료 사용자라면 더더욱 그렇습니다. 무료 크레딧은 기획 실험과 첫 구현에 아껴 써야지, 아직 필요하지 않은 고급 기능을 붙이는 데 쓰면 안 됩니다.

그런데 다음과 같은 일이 생기면 확장 도구를 검토할 때입니다.

이 표에서 중요한 것은 순서입니다. 초보자는 보통 도구 이름을 먼저 보고 흥분합니다. 하지만 실제 순서는 반대입니다. 먼저 문제가 생기고, 그 문제를 해결하기 위해 도구를 붙여야 합니다.

예를 들어 "언젠가 결제 기능이 필요할 것 같아"는 아직 결제 도구를 붙일 이유가 아닙니다. "전자책 랜딩 페이지를 공유했더니 10명이 구매 방법을 물어봤고, 계좌이체 안내를 매번 보내기 번거롭다"가 되었을 때 결제 도구를 검토하면 됩니다.

GitHub는 개발자만 쓰는 곳이 아니다

GitHub를 처음 보면 겁이 납니다. 코드가 잔뜩 있고, 영어가 많고, 이상한 파일 이름이 줄줄이 보입니다. 그래서 초보자는 이렇게 생각합니다.

"나는 코딩을 모르니까 GitHub는 나중에 개발자만 쓰면 되겠지."

반은 맞고, 반은 틀립니다. GitHub는 개발자가 코드를 수정하는 공간이기도 하지만, 러버블 사용자에게는 더 중요한 의미가 있습니다. GitHub는 내 프로젝트의 백업 창고이자, 변경 이력을 남기는 일기장입니다.

러버블에서 만든 프로젝트가 점점 커지면, 어느 날 이런 일이 생깁니다. 어제까지 잘 되던 폼이 오늘 갑자기 안 됩니다. 결제 버튼을 붙였더니 예약 페이지 레이아웃이 깨집니다. 개발자에게 도움을 요청했는데, 개발자가 "코드 저장소가 있나요?"라고 묻습니다. 이때 GitHub가 있으면 대화가 훨씬 쉬워집니다.

Git을 사용하면 변경 사항을 추적하고, 다른 사람과 협업하고, 이전 버전으로 되돌리는 데 도움이 됩니다. Netlify의 러버블 배포 가이드도 GitHub 연결을 장기 운영과 협업, 롤백을 위한 중요한 기반으로 설명합니다.¹

초보자는 GitHub를 이렇게 이해하면 됩니다.

• 코드 백업: 러버블에서 만든 결과물을 외부 저장소에 보관한다.

• 변경 기록: 언제 무엇이 바뀌었는지 흔적을 남긴다.

• 협업 통로: 개발자나 기술 파트너가 코드를 보고 수정할 수 있다.

• 장기 유지보수: 러버블 밖에서도 프로젝트를 이어갈 수 있다.

러버블 프로젝트는 GitHub로 코드를 내보낼 수 있고, GitHub와 연결하면 러버블에서 만든 변경이 저장소에 반영되는 흐름을 만들 수 있습니다. 러버블 FAQ에서도 프로젝트 코드를 GitHub로 전송해 내보낼 수 있다고 안내합니다.²

다만 GitHub를 연결한다고 해서 갑자기 코딩을 해야 하는 것은 아닙니다. 처음에는 코드를 직접 만지지 않아도 됩니다. 오히려 초보자에게 가장 중요한 원칙은 "GitHub는 열어보되, 모르는 파일은 함부로 수정하지 않는다"입니다.

GitHub 동기화를 검토할 타이밍은 명확합니다. 프로젝트가 단순 랜딩 페이지일 때는 급하지 않습니다. 하지만 다음 단계로 넘어가려면 연결해두는 편이 좋습니다.

첫째, 결제나 로그인처럼 민감한 기능을 붙이기 전입니다. 둘째, 개발자에게 점검을 맡기기 전입니다. 셋째, 고객에게 제작 대행 결과물을 납품하기 전입니다. 넷째, 프로젝트를 장기 운영할 생각이 생겼을 때입니다.

여기서 꼭 기억해야 할 보안 원칙이 있습니다. API 키, 결제 비밀 키, 이메일 발송 키 같은 민감한 값은 GitHub 코드에 들어가면 안 됩니다. 이런 값은 코드가 아니라 Secrets, 환경 변수, Supabase Edge Function 같은 안전한 저장 위치에 둬야 합니다. 러버블 FAQ도 민감한 API 키를 채팅에 직접 입력하지 말고, Secrets와 Edge Functions 조합을 사용하라고 안내합니다.³

도메인은 신뢰를 만든다

처음에는 러버블 기본 주소로도 충분합니다. 예를 들어 포트폴리오를 친구에게 보여주거나, 초기 테스트를 하거나, 고객 반응을 확인하는 단계라면 .lovable.app 주소가 큰 문제가 되지 않습니다.

하지만 모르는 고객에게 상담 신청을 받거나, 광고를 돌리거나, 결제까지 받을 생각이라면 이야기가 달라집니다. 사람들은 주소를 봅니다. 같은 페이지라도 yourname.lovable.app보다 yourbrand.com이 더 전문적으로 느껴집니다.

러버블 공식 문서도 커스텀 도메인이 브랜드 정체성, 검색 노출, 기억하기 쉬운 주소 측면에서 도움이 된다고 설명합니다. 다만 커스텀 도메인은 유료 플랜에서 사용할 수 있으며, 프로젝트를 먼저 Publish해야 실제 도메인으로 서비스할 수 있습니다.⁴

도메인은 쉽게 말해 웹사이트의 간판입니다. 러버블 기본 주소가 임시 사무실 문패라면, 커스텀 도메인은 내 이름으로 단 정식 간판에 가깝습니다.

초보자가 도메인을 고민할 때는 세 가지를 보면 됩니다.

• 고객에게 링크를 보냈을 때 신뢰가 필요한가?

• 검색이나 SNS 공유에서 기억하기 쉬운 주소가 필요한가?

• 결제, 예약, 회원가입처럼 중요한 행동을 요구하는가?

세 가지 중 하나라도 '그렇다'면 도메인을 검토할 만합니다. 반대로 아직 아무에게도 보여주지 않은 테스트 페이지라면 급하지 않습니다. 무료 사용자라면 먼저 기본 주소로 반응을 확인하고, 실제 문의나 구매 의사가 생겼을 때 도메인을 붙이는 편이 낫습니다.

도메인을 붙일 때는 루트 도메인과 서브도메인의 차이도 알아두면 좋습니다. 루트 도메인은 yourbrand.com처럼 가장 기본 주소입니다. 서브도메인은 app.yourbrand.com, booking.yourbrand.com, course.yourbrand.com처럼 앞에 단어가 붙은 주소입니다. 사업 소개 페이지는 루트 도메인에 두고, 예약 시스템은 booking.yourbrand.com에 두는 식으로 나눌 수 있습니다.

도메인 설정에서 자주 등장하는 DNS는 인터넷 주소록이라고 생각하면 됩니다. "이 도메인으로 들어온 사람을 어느 서버로 보낼 것인가?"를 정하는 설정입니다. 러버블에서 도메인을 직접 구매하면 DNS와 SSL 설정이 자동으로 처리되는 흐름을 제공하고, 외부에서 산 도메인을 연결할 때는 안내된 DNS 레코드를 도메인 업체에 입력해야 합니다.⁴

여기서 SSL은 주소 앞에 https가 붙게 해주는 보안 연결입니다. 고객 입장에서는 자물쇠 표시가 보이는 것이고, 운영자 입장에서는 기본 신뢰 장치입니다.

브랜드 이메일은 작지만 강한 신뢰 장치다

웹사이트 주소가 간판이라면 이메일 주소는 명함입니다. 고객에게 안내 메일이 Gmail 주소에서 오느냐, [email protected]에서 오느냐는 생각보다 큰 차이를 만듭니다.

물론 처음부터 브랜드 이메일이 꼭 필요한 것은 아닙니다. 무료 상담 신청을 받는 정도라면 개인 Gmail로도 시작할 수 있습니다. 하지만 다음 단계에서는 브랜드 이메일이 신뢰도를 높입니다.

예를 들어 이런 상황입니다. 예약 신청이 들어오면 고객에게 자동 확인 메일을 보내고 싶습니다. 전자책을 구매한 사람에게 다운로드 링크를 보내고 싶습니다. 회원가입한 사람에게 비밀번호 재설정 메일을 보내야 합니다. 이때 발신자가 [email protected] 또는 [email protected]이면 고객은 더 안심합니다.

러버블에는 자체 도메인으로 인증 이메일과 앱 이메일을 보낼 수 있는 Custom Emails 기능이 있습니다. 공식 문서에 따르면 이 기능은 유료 플랜에서 사용할 수 있고, 도메인 인증, SPF, DKIM, DMARC 같은 이메일 인증 설정을 러버블이 처리해 줍니다.⁵

SPF, DKIM, DMARC는 처음 들으면 어려운 말입니다. 아주 쉽게 말하면 "이 메일은 진짜 이 도메인에서 보낸 것이 맞습니다"라고 메일 서버에 증명하는 장치입니다. 이 설정이 제대로 되어 있으면 이메일이 스팸함으로 갈 가능성을 줄이는 데 도움이 됩니다.

이메일 도구는 크게 두 갈래로 나눠 생각하면 쉽습니다.

첫째는 인증 이메일입니다. 회원가입 확인, 비밀번호 재설정, 매직 링크 로그인처럼 계정 접근과 관련된 이메일입니다. 둘째는 앱 이벤트 이메일입니다. 예약 완료, 주문 확인, 문의 접수, 결제 완료, 상담 일정 안내처럼 사용자의 행동에 반응해 보내는 이메일입니다.

만약 러버블의 Custom Emails가 아직 부담된다면 Resend 같은 이메일 API 도구를 검토할 수 있습니다. 러버블의 Resend 문서는 Resend를 이메일 전송과 관리용 플랫폼으로 설명하며, 주문 확인, 예약 알림, 온보딩 메일, 뉴스레터 가입 흐름 같은 용도에 사용할 수 있다고 안내합니다.⁶

단, 이메일 자동화에서 반드시 지켜야 할 것이 있습니다. 고객이 원하지 않는 마케팅 메일을 마음대로 보내면 안 됩니다. 문의 확인이나 예약 안내처럼 필요한 거래성 메일과, 홍보성 뉴스레터는 구분해야 합니다. 뉴스레터를 보낼 때는 동의, 수신 거부, 발송 주체 표시 같은 기본 원칙을 확인해야 합니다.

결제는 버튼이 아니라 책임이다

초보자가 가장 설레는 확장 기능은 결제입니다. 결제 버튼이 생기면 갑자기 내 프로젝트가 진짜 사업처럼 느껴집니다. 전자책을 팔 수 있고, 강의 신청을 받을 수 있고, 구독 서비스를 만들 수 있습니다.

하지만 결제는 단순히 버튼 하나를 붙이는 일이 아닙니다. 결제는 고객의 돈, 환불, 영수증, 세금, 개인정보, 서비스 제공 책임이 함께 따라오는 기능입니다.

러버블 공식 문서에 따르면 내장 결제 기능은 디지털 제품과 소프트웨어 수익화에 사용할 수 있고, 구독과 일회성 결제를 지원합니다. 2026년 5월 기준 문서상 내장 결제는 Pro 플랜 이상이 필요하며, Lovable Cloud를 사용하고, 구매를 사용자와 연결하려면 인증 기능이 권장됩니다. 결제 제공자는 Paddle과 Stripe가 있으며, 테스트 환경과 실제 결제 환경을 나누어 운영할 수 있습니다.⁷

여기서 Stripe와 Paddle의 차이를 아주 단순하게 말하면 이렇습니다. Stripe는 결제를 처리하는 강력한 결제 인프라에 가깝고, Paddle은 디지털 제품 판매에서 세금과 컴플라이언스 부담을 더 많이 대신 처리하는 Merchant of Record 모델을 제공합니다. Merchant of Record는 고객에게 판매하는 법적 판매자 역할을 맡는 구조라고 이해하면 됩니다. 다만 어떤 방식이 나에게 맞는지는 판매 국가, 상품 유형, 세금 처리 방식, 수수료, 정산 조건을 확인한 뒤 결정해야 합니다.

러버블은 Stripe 설정도 채팅 기반으로 도와줄 수 있습니다. 공식 Stripe 연동 문서는 Supabase 연결과 Stripe Secret Key 저장 후, "전자책을 29달러에 판매하는 일회성 체크아웃을 만들어줘" 같은 식으로 요청하면 checkout, portal edge functions, 데이터베이스 테이블, UI 버튼을 생성할 수 있다고 설명합니다. 동시에 Stripe Secret Key를 채팅에 직접 붙여넣지 말고 Add API Key 같은 안전한 입력 흐름을 사용하라고 강조합니다.⁸

초보자는 결제 기능을 붙이기 전에 다음 질문에 먼저 답해야 합니다.

• 무엇을 파는가? 전자책, 상담권, 강의, 구독, 템플릿 중 무엇인가?

• 얼마에 파는가? 일회성 결제인가, 월 구독인가?

• 결제 후 고객은 무엇을 받는가? 파일, 링크, 계정 권한, 예약 확정 중 무엇인가?

• 환불 조건은 무엇인가? 다운로드 후 환불이 가능한가, 상담 전 취소는 가능한가?

• 결제 실패, 취소, 환불, 중복 결제 상황을 어떻게 안내할 것인가?

이 다섯 가지에 답하지 못한 상태에서 러버블에게 "결제 기능 붙여줘"라고 말하면, 겉으로는 버튼이 생겨도 운영이 엉킬 수 있습니다.

처음에는 결제 기능을 러버블 앱 안에 직접 넣지 않아도 됩니다. 무료 사용자라면 특히 그렇습니다. 아주 초기에는 계좌이체, 외부 결제 링크, 예약 플랫폼, 폼 신청 후 개별 안내로도 충분할 수 있습니다. 사람들이 실제로 돈을 내겠다는 신호가 생긴 뒤, 결제 기능을 앱 안으로 가져와도 늦지 않습니다.

자동화 도구는 '보이지 않는 직원'이다

Make와 n8n 같은 자동화 도구는 처음 보면 조금 낯섭니다. 하지만 역할은 단순합니다. 사람이 반복해서 하던 일을 대신 이어주는 도구입니다.

예를 들어 프리랜서 견적 요청 페이지를 운영한다고 해봅시다. 누군가 폼을 제출하면 당신은 보통 이런 일을 합니다. 이메일을 확인합니다. 스프레드시트에 이름과 연락처를 옮겨 적습니다. 고객에게 "문의가 접수되었습니다"라고 답장합니다. 중요한 문의라면 카카오톡이나 슬랙에 알림을 남깁니다. 며칠 뒤 후속 연락을 보냅니다.

처음에는 직접 해도 됩니다. 하루에 한두 건이면 자동화보다 수동 처리가 빠릅니다. 하지만 하루에 10건, 20건이 들어오기 시작하면 이야기가 달라집니다. 이때 자동화 도구가 필요해집니다.

n8n과 러버블을 연결하는 기본 흐름은 비교적 단순합니다. n8n에서 Webhook Trigger를 만들고, 러버블 폼 제출 시 해당 Webhook URL로 JSON 데이터를 POST 요청하게 만들면 됩니다. 그 다음 n8n에서 Google Sheets에 행을 추가하거나, Slack 알림을 보내거나, 이메일을 발송하는 식으로 워크플로를 이어갈 수 있습니다.⁹

Webhook은 초보자에게 이렇게 설명할 수 있습니다. "어떤 일이 생기면 이 주소로 소식을 보내주세요"라는 알림용 문입니다. 러버블 폼이 제출되면 n8n의 문을 두드립니다. n8n은 그 내용을 받아서 다른 도구들에 전달합니다.

Make도 비슷한 역할을 합니다. Make는 시각적으로 흐름을 만들기 쉬워 초보자에게 친숙한 편이고, n8n은 더 자유롭고 개발자 친화적인 자동화에 강점이 있습니다. 무엇이 더 좋다고 단정하기보다, 내가 이해하기 쉬운 쪽을 먼저 쓰면 됩니다.

자동화의 좋은 첫 사례는 거창한 AI 에이전트가 아닙니다. 다음 정도면 충분합니다.

• 문의 폼 제출 → Google Sheets에 자동 기록 → 내 이메일로 알림

• 예약 신청 → 고객에게 확인 메일 발송 → 관리자에게 알림

• 전자책 구매 → 구매자 목록 저장 → 다운로드 안내 메일 발송

• 뉴스레터 신청 → 구독자 목록 추가 → 환영 메일 발송

• 견적 요청 → 내부 관리표에 추가 → 3일 뒤 후속 연락 알림

Google Sheets는 초보자에게 특히 편합니다. 엑셀처럼 볼 수 있고, 필터를 걸 수 있고, 고객 목록을 한눈에 확인할 수 있습니다. n8n 공식 자료도 Google Sheets와 Google Docs를 여러 트리거, 스케줄, Webhook, HTTP Request와 연결해 자동화 흐름을 만들 수 있다고 설명합니다.¹⁰

다만 Google Sheets를 데이터베이스처럼 무리해서 쓰면 안 됩니다. 잠재고객 이름과 문의 상태를 간단히 관리하는 정도는 좋습니다. 하지만 로그인 사용자 권한, 결제 상태, 민감한 개인정보, 대량 데이터, 복잡한 검색이 필요해지면 Supabase 같은 데이터베이스를 쓰는 편이 안전합니다.

개인정보와 보안은 나중 일이 아니다

러버블로 만든 작은 페이지라도 이름, 이메일, 전화번호, 상담 내용을 받는 순간 개인정보를 다루게 됩니다. "나는 작은 부업이라 괜찮겠지"라고 생각하면 위험합니다. 규모가 작아도 고객 정보는 고객 정보입니다.

개인정보보호위원회와 개인정보 포털은 개인정보 보호와 관련한 안내, 자가진단, 기술상담 같은 사업자 지원 서비스를 제공합니다.¹¹ 법률의 세부 적용은 업종과 상황에 따라 달라질 수 있으므로, 실제 서비스를 운영하거나 결제를 받기 전에는 공식 자료와 전문가 조언을 확인하는 습관이 필요합니다.

초보자가 최소한 지켜야 할 원칙은 어렵지 않습니다.

• 필요한 정보만 받는다. 상담에 주민등록번호가 필요하지 않다면 절대 받지 않는다.

• 왜 받는지 알려준다. 문의 응대, 예약 확인, 결제 처리처럼 목적을 분명히 쓴다.

• 얼마나 보관할지 정한다. 영원히 보관하지 말고 보관 기간과 삭제 기준을 정한다.

• 누가 볼 수 있는지 제한한다. 관리자만 봐야 할 정보는 공개 페이지에 노출되지 않게 한다.

• 외부 도구로 보낼 때 조심한다. Google Sheets, 이메일, 자동화 도구로 개인정보가 이동한다면 그 흐름을 알고 있어야 한다.

• 삭제 요청에 대응한다. 고객이 내 정보를 지워달라고 했을 때 어디에서 지워야 하는지 알아야 한다.

API 키 보안도 매우 중요합니다. Stripe Secret Key, Resend API Key, OpenAI API Key 같은 값은 절대 채팅창에 그대로 붙여넣지 마세요. 코드에 직접 넣어도 안 됩니다. GitHub에 올라가도 안 됩니다. 이런 키가 노출되면 누군가 내 계정으로 요청을 보내거나, 비용을 발생시키거나, 고객 데이터에 접근할 수 있습니다.

러버블에 요청할 때는 이렇게 말하는 편이 안전합니다.

Resend API 키는 채팅에 직접 입력하지 않을 것이다. Secrets에 RESEND_API_KEY라는 이름으로 저장된 값을 사용하도록 구현해줘. 프론트엔드 코드에는 이 키가 노출되지 않게 하고, 서버 측 Edge Function에서만 호출해줘.

결제를 다룰 때도 마찬가지입니다. 카드 번호를 내 데이터베이스에 저장하려고 하면 안 됩니다. 결제 정보는 Stripe나 Paddle 같은 결제 전문 서비스가 처리하게 두고, 내 앱에는 결제 성공 여부, 주문 번호, 구독 상태처럼 필요한 정보만 저장하는 것이 기본입니다.

러버블에 계속 만들지, 개발자에게 넘길지 판단하기

프로젝트가 커지면 언젠가 이런 갈림길을 만납니다.

"계속 러버블로 고쳐도 될까?"

"이제 개발자에게 맡겨야 하나?"

"차라리 다른 노코드 도구로 옮기는 게 나을까?"

정답은 하나가 아닙니다. 프로젝트 성격에 따라 다릅니다.

러버블에 계속 맡겨도 되는 경우는 비교적 명확합니다. 페이지 구조 수정, 랜딩 페이지 개선, 간단한 폼, 작은 관리자 화면, Supabase 기반의 단순 데이터 저장, MVP 검증처럼 빠른 반복이 중요한 작업은 러버블과 잘 맞습니다. 특히 아직 고객 반응을 확인하는 단계라면 개발자를 고용하기보다 러버블로 빠르게 고치며 실험하는 편이 낫습니다.

개발자에게 넘기는 것이 좋은 경우도 있습니다. 결제와 개인정보가 핵심인 서비스, 권한 구조가 복잡한 B2B 도구, 여러 사용자가 동시에 쓰는 업무용 시스템, 성능과 보안 점검이 중요한 서비스, 반복 오류가 계속 발생하는 프로젝트라면 개발자의 코드 리뷰와 구조 설계가 필요합니다.

다른 노코드 도구가 더 나은 경우도 있습니다. 예를 들어 디자인 중심의 마케팅 사이트라면 Webflow나 Framer 계열 도구가 더 편할 수 있습니다. 실물 상품 판매가 중심이라면 Shopify 같은 커머스 도구가 더 적합할 수 있습니다. 내부 업무 관리와 스프레드시트형 운영이 중심이라면 Airtable, Softr, Glide 같은 조합이 더 빠를 수 있습니다. 복잡한 자동화가 중심이라면 러버블 안에 모든 것을 넣기보다 Make나 n8n으로 분리하는 편이 유지보수에 좋습니다.

판단 기준을 표로 정리하면 이렇습니다.

초보자가 꼭 기억해야 할 말이 있습니다. "러버블로 만들 수 있다"와 "러버블로 계속 운영하는 것이 최선이다"는 다릅니다. 만들 수는 있지만, 운영과 보안과 유지보수는 또 다른 문제입니다.

개발자에게 넘길 때 준비해야 할 것

개발자에게 넘기는 순간이 오면, 코드를 모른다고 해서 아무것도 준비하지 못하는 것은 아닙니다. 오히려 비개발자가 잘 준비한 문서는 개발자의 시간을 크게 줄여줍니다.

개발자에게 넘기기 전에는 다음 자료를 정리해두면 좋습니다.

• 서비스 한 문장 설명: 누구의 어떤 문제를 해결하는 서비스인지

• 화면 목록: 홈, 로그인, 대시보드, 결제, 관리자 페이지 등

• 사용자 역할: 방문자, 회원, 유료 회원, 관리자 등

• 주요 기능: 각 화면에서 사용자가 할 수 있는 일

• 데이터 목록: 이름, 이메일, 주문, 예약, 결제 상태 등

• 외부 도구 목록: Supabase, Stripe, Resend, n8n, Google Sheets 등

• 환경 변수 이름: STRIPE_SECRET_KEY처럼 이름만 정리하고 실제 값은 공유하지 않기

• 알려진 오류: 언제 어떤 상황에서 문제가 생기는지

• 우선순위: 반드시 고쳐야 할 것과 나중에 해도 되는 것

여기에 GitHub 저장소가 연결되어 있으면 훨씬 좋습니다. 개발자는 코드를 확인하고, 수정하고, 변경 이력을 남길 수 있습니다. 당신은 여전히 코드를 몰라도 됩니다. 대신 무엇을 만들었고, 무엇이 안 되고, 무엇이 중요하며, 어디까지가 이번 작업 범위인지 설명할 수 있어야 합니다.

크레딧을 아끼는 확장 루틴

확장 도구를 붙일 때도 이 책의 원칙은 같습니다. 러버블 안에서 기획부터 길게 대화하지 말고, 외부 AI에서 먼저 정리한 뒤 러버블에는 구현 지시만 넣는 것입니다.

예를 들어 결제 기능을 붙이고 싶다면 바로 러버블에 "결제 붙여줘"라고 하지 마세요. 먼저 ChatGPT나 Gemini에게 이렇게 물어봅니다.

나는 러버블로 만든 전자책 랜딩 페이지를 운영하고 있다. 상품은 PDF 전자책 1개이고 가격은 29,000원이다. 결제 후 구매자에게 다운로드 링크를 이메일로 보내고 싶다. 초보자가 구현하기 전에 정해야 할 결제 흐름, 데이터 항목, 이메일 문구, 환불 안내, 보안 주의사항을 체크리스트로 정리해줘.

그 다음 나온 결과를 다듬어 러버블용 구현 지시서로 바꿉니다.

현재 프로젝트에 전자책 일회성 결제 흐름을 추가해줘. 결제 제공자는 Stripe를 사용할 예정이다. 결제 전 상품명, 가격, 환불 안내를 보여주고, 결제 성공 후 purchases 테이블에 사용자 이메일, 상품명, 결제 상태, 결제 시각을 저장해줘. 결제 성공 페이지에서는 다운로드 안내를 보여주고, 실제 API 키는 Secrets에 저장된 값을 사용해줘. 먼저 구현 계획과 생성할 테이블, Edge Function, 화면 변경 사항을 설명한 뒤 진행해줘.

이렇게 하면 러버블이 해야 할 일이 명확해집니다. 크레딧을 쓰더라도 "무엇을 만들지 같이 고민하는 비용"이 아니라 "정해진 것을 구현하는 비용"으로 쓰게 됩니다.

확장 기능을 붙일 때는 한 번에 하나만 붙이세요. 도메인, 결제, 이메일, 자동화, 관리자 페이지를 한 프롬프트에 모두 넣으면 실패했을 때 원인을 찾기 어렵습니다. 오늘은 도메인, 내일은 이메일, 다음 주는 결제처럼 나눠야 합니다.

특히 무료 사용자라면 더 보수적으로 접근해야 합니다. 아직 유료 플랜이 필요한 기능을 당장 쓰지 못한다면 대체 흐름을 먼저 만드세요. 결제 대신 신청 폼과 수동 안내를 쓰고, 브랜드 이메일 대신 Gmail을 쓰고, 자동화 대신 하루 한 번 수동 정리를 해도 됩니다. 자동화는 반복 업무가 실제로 생긴 뒤 붙여도 늦지 않습니다.

작은 사업형 프로젝트의 현실적인 확장 순서

프리랜서나 1인 사업자 기준으로 가장 현실적인 확장 순서는 다음과 같습니다.

처음에는 러버블로 단일 랜딩 페이지를 만듭니다. 포트폴리오, 서비스 설명, 후기, FAQ, 문의 폼 정도면 충분합니다. 기본 주소로 배포하고 지인, SNS, 커뮤니티에 공유해 반응을 봅니다.

반응이 생기면 도메인을 붙입니다. 고객에게 링크를 보낼 때 더 전문적으로 보이고, 장기적으로 검색과 브랜드 기억에도 유리합니다. 이 단계에서 이메일 주소도 정리합니다. hello@도메인, support@도메인 같은 주소를 쓰면 고객 응대가 훨씬 깔끔해집니다.

문의가 늘어나면 데이터 저장과 자동화를 붙입니다. 처음에는 Supabase나 Google Sheets에 문의를 저장하고, 새 문의가 오면 이메일 알림을 받게 만듭니다. 반복 업무가 많아지면 Make나 n8n으로 흐름을 연결합니다.

돈을 받을 준비가 되면 결제를 붙입니다. 그 전에 상품 설명, 가격, 환불 정책, 제공 방식, 고객 지원 방식을 정리합니다. 결제는 반드시 테스트 모드에서 충분히 확인한 뒤 실제 결제로 전환합니다.

프로젝트가 더 커지면 GitHub와 개발자 협업을 준비합니다. 이때부터는 프롬프트만 잘 쓰는 사람이 아니라, 제품을 운영하는 사람처럼 생각해야 합니다. 기능 요청서, 오류 기록, 고객 피드백, 데이터 구조, 보안 체크리스트를 관리해야 합니다.

이 순서를 한 문장으로 줄이면 이렇습니다.

페이지 → 도메인 → 데이터 저장 → 이메일 → 자동화 → 결제 → GitHub 협업 → 개발자 검토.

물론 프로젝트에 따라 순서는 달라질 수 있습니다. 하지만 초보자에게 중요한 원칙은 변하지 않습니다. 먼저 고객 반응을 확인하고, 그 다음에 확장합니다.

이번 장의 결론

확장 도구는 당신의 프로젝트를 더 진지한 사업 도구로 만들어줍니다. GitHub는 백업과 협업의 기반이 되고, 커스텀 도메인은 신뢰를 만들고, 브랜드 이메일은 고객 경험을 정돈합니다. Stripe와 Paddle은 결제를 가능하게 하고, Resend와 Custom Emails는 안내와 알림을 자동화합니다. Make, n8n, Google Sheets는 반복 업무를 줄여줍니다.

하지만 처음부터 모두 붙일 필요는 없습니다. 오히려 너무 빨리 확장하면 크레딧과 시간이 낭비됩니다. 무료 사용자라면 더욱 작게 시작해야 합니다. 기본 주소로 배포하고, 수동으로 문의를 받고, 고객 반응을 확인한 뒤, 실제로 막히는 부분부터 하나씩 확장하세요.

결제와 개인정보를 다루는 순간부터는 책임도 커집니다. API 키를 채팅에 붙여넣지 말고, 고객 정보를 필요한 만큼만 수집하고, 결제와 환불, 개인정보 처리에 관한 안내를 준비해야 합니다.

러버블은 시작을 빠르게 해주는 도구입니다. GitHub, 도메인, 결제, 이메일, 자동화 도구는 그 시작을 운영 가능한 시스템으로 키우는 도구입니다. 이제 마지막 장에서는 이 모든 흐름을 묶어, 나만의 러버블 제작 시스템을 완성해보겠습니다.

참고

¹Deploy a Lovable site to Netlify

²Lovable FAQ

³Lovable FAQ - API keys and secrets

⁴Set up a custom domain

⁵Send branded emails from your own domain

⁶Connect your app to Resend

⁷Add payments to your app

⁸Set up app payments with Stripe

⁹Lovable + n8n Integration

¹⁰Google Docs and Google Sheets integration

¹¹개인정보 포털