Lovable + Supabase, 그리고 프롬프트 엔지니어링을 맛보기 해봤다
이번 실험은 “AI 요약 노트 메이커” 만들기
4주간 바이브코딩 스터디를 결심하면서 내가 세운 목표는 딱 하나였다.
“기획자지만, 이번에는 진짜 내 손으로 서비스를 만들어보자”
회사에서는 보통 기획자로서
요구사항을 정리하고, PRD를 쓰고, 개발자/디자이너와 협업해서 서비스를 만든다.
하지만 실제 코드와 인프라를 만지는 건 늘 다른 사람의 몫이었다.
요즘 같은 시대야 말로 내가 도전해 볼 기회라는 생각이 들었다.
“프롬프트 엔지니어링 = AI랑 잘 대화하는 기술”
바이브코딩 세션에서 제일 먼저 들었던 개념이 프롬프트 엔지니어링이었다.
프롬프트 엔지니어링 : AI와 더 잘 대화하는 기술
단순히 “요약해 줘”가 아니라,
맥락 + 목표 + 제약조건까지 포함해서 AI에게 잘 설명하는 기술.
여기서 특히 기억에 남았던 포인트들:
- 기능이 10개 이상 붙으면, AI도 헷갈려한다
- 그래서 “막 던지는 프롬프트”가 아니라
계속 구체화된 프롬프트로 정제해 나가야 한다 - Chat을 통해 점점 더 구체적인 프롬프트를 만들어서
에이전트(Agent)에게 개발을 시키는 구조가 중요하다
그리고 핵심 문장 하나:
“첫 시도에서 AI가 가장 많이 생각한다.”
첫 프롬프트가 중요한 이유
AI가 결과를 만들 때는 내부적으로 이런 것들을 같이 고려한다.
- Context (이전 대화 맥락)
- System 프롬프트 (AI의 역할 정의)
- User 프롬프트 (내가 직접 입력하는 요구사항)
여기서 Context가 차지하는 비중이 상당히 크다.
이전 맥락이 쌓이면 쌓일수록, 그 양만큼 처리해야 할 것도 많아진다.
그래서 강사님이 했던 말이 계속 머리에 남았다.
“이전 맥락이 없는, 첫 질문에서 잘하는 게 중요하다.”
System, User 프롬프트가 실제로 차지하는 ‘용량’은 생각보다 작다.
그렇기 때문에 첫 프롬프트에 정확한 설계 문서를 던지는 게 훨씬 좋다.
예를 들어,
- “이런 서비스 만들고 싶어요”가 아니라
- 서비스 목표, 타깃 유저, 기능 구조, UX 흐름까지 정리된 PRD를 통째로 던지는 것
그래서 나온 결론:
단순 Chat이 아니라, “PRD를 던지는 게 좋다.”
PRD를 GPT에게 쓰게 하고, 그걸 “지침”으로 쓰기
여기서 재밌었던 부분은
PRD조차 GPT에게 쓰게 할 수 있다는 점.
- 서비스 목표
- 타깃 페르소나
- 핵심 기능
- UX 구조
- 기본 플로우
이걸 대략 말로 설명하면, GPT가 그걸 읽고 PRD 초안을 뽑아준다.
나는 그걸 다듬어서 실제 프로젝트의 “지침”으로 쓰는 것이다.
그리고 이 PRD를 GPT 프로젝트의 Knowledge(지식)에 넣어두고,
이후 프롬프트 엔지니어링의 기반으로 쓰는 방식.
정리하면 흐름은 이렇다.
- GPT에게 PRD 초안을 만들어달라고 요청
- 내가 다듬어서 실제 PRD로 확정
- 이 PRD를 프로젝트의 지침(Knowledge)으로 등록
- 이후 “이 PRD 기준으로 Phase를 쪼개줘”라고 프롬프트
PRD → Phase → UX Guide → Lovable 개발
바이브코딩에서 추천했던 실제 개발 워크플로우는 이렇게 흘렀다.
- PRD 작성
- PRD를 기반으로 Phase(단계) 쪼개기
- 예: Phase 1 – 로그인 기능
- Phase 2 – 글 입력 & 요약
- Phase 3 – 저장 & 조회 화면
- 각 Phase에 대해 Technical Task로 나누기
- UX 관련 내용은 UX Guide로 따로 정리
- PRD + Phase + UX Guide를 합쳐서 Lovable에서 구현
그리고 GPT에게는 이런 식으로 시켰다.
- “이 PRD를 기반으로 Phase를 나눠줘”
- “Phase 1에 대해 필요한 Technical Task를 쪼개줘”
- “각 Task를 Lovable에서 구현할 수 있게 구체적으로 설명해 줘”
디자인도 프롬프트로: UX Pilot & 코드 카피
디자인도 결국 프롬프트의 영역이었다.
- Figma Make 같은 AI 디자인 도구
- 또는 Lovable 내 화면 생성 기능
“이런 구조의 화면을 만들어줘”라고 프롬프트를 던지면,
기본적인 레이아웃과 컴포넌트를 자동으로 만들어준다.
그리고 만약 이게 너무 못생겼다면(?)
shadcn 같은 컴포넌트 라이브러리에서
- Copy code
- Copy prompt
이런 걸 가져다가 Lovable에 붙여 넣는 방식으로 디자인 퀄리티를 끌어올릴 수 있다는 팁도 들었다.
이번 프로젝트의 실제 세팅: Lovable + Supabase 조합
나는 이번 AI 요약 노트 메이커를 만들면서
Lovable를 프런트엔드 툴로, Supabase를 백엔드로 사용했다.
처음부터 이렇게 정리를 해두고 GPT에게 말해줬다.
“Lovable을 써서 개발할 거고, 백엔드는 Supabase에 저장할 거야.”
이걸 말해주는 이유는 간단하다.
- Lovable에는 자체 백엔드인 Lovable Cloud가 있고
- 러버블이 “알아서” 그쪽으로도 연결하려고 할 수 있기 때문
그래서 내가 원하는 기술 스택을 명확히 지정해 주는 것도 프롬프트 엔지니어링의 일부였다.
Supabase는 무료 구간에서도 MVP 단계에서 사용할 데이터 양(대략 수천~만 건 수준)은 충분히 커버된다고 한다.
모니터링도 깔끔하고, DB/인증/스토리지 등 기능도 좋아서
“내 서비스 백엔드”로 쓰기에 딱 좋았다.
왜 Lovable 백엔드에 종속되는 걸 피하고 싶었나
최근 Lovable 업데이트 이후,
프로젝트를 만들다 보면 Lovable이 자동으로 백엔드를 붙여버리는 경우가
많다고 했는데 실제로 진행해 보니 프롬프트에 작성했는데도
Lovable 백엔드를 우선으로 구성해 버렸다.
문제는:
- 한 번 Lovable Cloud 쪽으로 백엔드가 구성되면 구조를 바꾸기가 어렵고,
- 프로젝트가 Lovable 안에 갇힌 느낌이 든다는 것.
Git 연동은 가능하지만,
모든 걸 Lovable 안에서만 세팅하면
“내 코드”라기보다는 “Lovable 프로젝트의 일부”처럼 느껴진다.
그래서:
- 프런트: Lovable
- 백엔드: Supabase (내가 직접 관리)
- 코드 관리: GitHub
이 조합으로 진행하게 됐다.
🐞 버그가 떠도, 이젠 내가 고칠 수 있다
(가 아니고 엄밀히 말하면 러버블한테 고쳐달라고 할 수 있다)
실제로 Lovable + Supabase + Gemini API를 붙이는 과정에서
적어도 한두 개씩은 꼭 버그가 터진다.
(실제로 제미나이 API 엉뚱한 버전을 붙여대서 버그가 얼마나 반복되었는지...)
- API 응답 형식이 바뀌거나
- Supabase insert가 실패하거나
- 화면 상태가 꼬이거나
예전 같았으면 “개발자님…” 하고 도움을 요청했을 텐데,
이번에는 러버블에게 고쳐달라 하고, 러버블이 알려주는 대로 수정하고 다시 시도해 보며 해결했다.
이 경험이 진짜 좋았다.
“아, 나도 버그를 고칠 수 있구나.”
버그를 막막하게 붙들고 있는 게 아니라 도움 받을 수 있다는 자신감도 생기고
몇 번 감각이 생기니까
다음 실험을 상상하는 폭도 훨씬 넓어졌다.
복잡한 기능은 Lovable 말고, GPT 5.1 Codex로 해결하기
실습 중에 들었던 팁 중 하나는 이거였다.
“복잡한 기능이 계속 고쳐지지 않고 에러가 난다면
Lovable만 붙잡지 말고, GPT 5.1 Codex로 해결해라.”
- Codex는 웹 환경에서 동작해서
비개발자도 터미널 없이 코드를 수정할 수 있고 - GitHub와 연결하면
내 코드를 직접 열어서, 오류를 설명해 주고,
수정 방향까지 제안해 준다.
비개발자 입장에서는:
- Lovable에서 개발
- 코드는 GitHub로 연동
- 버그가 풀리지 않으면 Codex 등으로 열어서
“이거 왜 안 돼? 쉽게 설명해 줘 + 어떻게 고치면 돼?”라고 물어보기
이 흐름이 꽤 현실적인 대안처럼 느껴졌다.
그리고 항상 마지막에는 이렇게 생각하기.
“나는 개발자가 아니니까, 모르는 게 당연하다.
대신, AI에게 ‘팩트 체크해 줘’라고 먼저 의심해 보자.”
의심하는 만큼 콘텍스트가 넓어지고,
결국 더 나은 답을 얻을 수 있다는 얘기도 인상 깊었다.
Knowledge 설정: PRD + Phase + UX Guide 합치기
실습에서 배운 또 하나의 포인트:
PRD + Phase + UX Guide 3개를 합쳐서 Knowledge에 넣고, Lovable에서 개발한다.
1차 프롬프트로 PRD, Phase, UX Guide를 만들고 나면
그 뒤에 GPT 프로젝트의 Knowledge 기능을 통해 이 문서들을 넣어준다.
- PRD: 서비스의 목표와 요구사항
- Phase: 기능별 개발 단계
- UX Guide: 화면 구조와 인터랙션 가이드
그리고 나중에는 이것도 까먹지 않도록
마크다운 문서 단위로 쪼개서
- 보안 관련은 security.md
- 디자인 관련은 design.md
- API 구조는 api.md
이런 식으로 나누고,
“이 기능은 design.md 기준으로 봐줘”라고 찍어주는 방식.
결국, GPT에게도 이렇게 말하는 셈이다.
“네가 참고해야 할 지침은 여기 있어.
이 문서를 기준으로 대답해 줘.”
다음 실험: 이제 진짜 아이디어로, 더 밀도 있는 프롬프트로 🚀
이번 AI 요약 노트 메이커는
말 그대로 테스트용 서비스였다.
- Lovable에 익숙해지기 위한 연습
- Supabase를 한 번이라도 붙여보기 위한 실험
- 프롬프트 엔지니어링의 흐름을 몸으로 느껴보기 위한 워밍업
이제 다음 단계에서는
정말 내가 해보고 싶은 아이디어를 PRD로 짜서
처음부터 밀도 있게 만들어볼 생각이다.
그리고 그때는 이렇게 시작하려고 한다.
“첫 번째 프롬프트에서, AI가 가장 많이 생각한다.”
그래서 다음 프로젝트는
- 처음 프롬프트부터 PRD 수준으로 구체적으로 던지고
- 거기서 바로 Phase, UX, Tech Task까지 뽑아낸 뒤
- Lovable + Supabase + GitHub + Codex까지 연결하는
조금 더 진짜 같은 실험을 해볼 예정이다.
'AI 바이브코딩' 카테고리의 다른 글
| 기획자도 Retool 하나로, 작동하는 PoC를 만들다 (0) | 2025.10.31 |
|---|