
👇 바이브코딩 특강 (구글 미트)

PRD(Product Requirements Document)는 제품 개발 과정에서 가장 중요한 문서 중 하나입니다. 제품의 목표, 기능, 요구사항을 명확하게 정의하고 개발팀과 이해관계자들이 공통의 이해를 가질 수 있도록 돕는 청사진 역할을 합니다.
명확한 소통: 개발팀, 디자이너, PM, 비즈니스 팀 모두가 같은 목표를 바라볼 수 있습니다.
범위 관리: 프로젝트 스코프를 명확히 하여 불필요한 기능 추가를 방지합니다.
의사결정 근거: 개발 과정에서 발생하는 의사결정의 기준점이 됩니다.
리스크 감소: 요구사항을 사전에 명확히 하여 개발 중 발생할 수 있는 오해와 재작업을 최소화합니다.
| 분류 | 설명 | 예시 |
|---|---|---|
| Must-have | 제품 출시를 위해 반드시 필요한 기능 | 로그인, 회원가입, 핵심 비즈니스 로직 |
| Should-have | 사용자 경험을 크게 향상시키는 기능 | 알림 기능, 검색 필터, 프로필 설정 |
| Could-have | 있으면 좋지만 없어도 되는 기능 | 다크모드, 소셜 공유, 고급 통계 |
| Won't-have | 현재 버전에서는 제외하는 기능 | 다국어 지원, AI 추천, 고급 분석 |
graph TD
A[문제 정의] --> B[사용자 조사]
B --> C[요구사항 수집]
C --> D[우선순위 설정]
D --> E[PRD 초안 작성]
E --> F[이해관계자 검토]
F --> G{승인 여부}
G -->|승인| H[최종 PRD 완성]
G -->|수정 필요| E
H --> I[개발 시작]
❌ "빠른 응답 시간"
✅ "페이지 로딩 시간 3초 이내"
기술적 구현보다는 사용자가 얻게 될 가치에 집중해서 작성합니다.
Must-have, Should-have, Could-have로 기능의 중요도를 분류합니다.
플로우차트, 와이어프레임, 모키업을 포함하여 이해도를 높입니다.
| 문서 유형 | 목적 | 작성자 | 주요 독자 |
|---|---|---|---|
| PRD | 제품 요구사항 정의 | PM/PO | 개발팀, 디자이너, QA |
| BRD | 비즈니스 요구사항 정의 | 비즈니스 분석가 | 경영진, PM |
| Technical Spec | 기술적 구현 방법 | 개발자/아키텍트 | 개발팀 |
| User Story | 사용자 관점의 기능 | PM/PO | 개발팀, 디자이너 |
과도한 디테일 지양: 너무 세부적인 내용보다는 핵심 요구사항에 집중합니다.
유연성 확보: 개발 과정에서 발생할 수 있는 변경사항을 고려한 여지를 둡니다.
정기적 업데이트: PRD는 살아있는 문서입니다. 프로젝트 진행에 따라 지속적으로 업데이트해야 합니다.
이해관계자 검토: 작성 후 모든 이해관계자의 검토와 승인을 받아야 합니다.
As a [사용자 유형],
I want [원하는 기능],
So that [달성하고자 하는 목표].
| 사용자 유형 | 원하는 기능 | 목표 |
|---|---|---|
| 신규 사용자 | 간단한 회원가입 | 서비스를 빠르게 시작할 수 있다 |
| 기존 사용자 | 즐겨찾기 기능 | 자주 사용하는 기능에 빠르게 접근할 수 있다 |
| 관리자 | 사용자 통계 대시보드 | 서비스 현황을 한눈에 파악할 수 있다 |
Supabase는 "오픈소스 Firebase 대안"을 목표로 하는 백엔드 개발 플랫폼입니다. PostgreSQL을 기반으로 하여 실시간 데이터베이스, 인증, 스토리지, Edge Functions 등의 기능을 제공하며, 개발자들이 풀스택 애플리케이션을 빠르게 구축할 수 있도록 돕습니다.
| 기능 | Firebase | Supabase |
|---|---|---|
| 데이터베이스 | NoSQL (Firestore) | PostgreSQL (관계형) |
| 쿼리 | 제한적 | 완전한 SQL 지원 |
| 실시간 | ✅ | ✅ |
| 인증 | ✅ | ✅ |
| 스토리지 | ✅ | ✅ |
| 오픈소스 | ❌ | ✅ |
| 가격 | 사용량 기반 | PostgreSQL 크기 기반 |
| 벤더 락인 | 높음 | 낮음 (PostgreSQL) |
Lovable(이전 명칭: GPT Engineer)은 AI를 활용해 자연어 프롬프트만으로 풀스택 웹 애플리케이션을 생성할 수 있는 혁신적인 개발 플랫폼입니다. 복잡한 코딩 없이도 아이디어를 실제 동작하는 웹앱으로 빠르게 구현할 수 있어, 개발자와 비개발자 모두에게 새로운 가능성을 제공합니다.
| 구분 | 전통적 개발 | Lovable |
|---|---|---|
| 개발 시간 | 수주~수개월 | 수분~수시간 |
| 필요 기술 | React, Node.js, DB 등 | 자연어 프롬프트 |
| 초기 설정 | 복잡한 환경 구성 | 즉시 시작 가능 |
| 배포 | 복잡한 설정 필요 | 원클릭 배포 |
| 유지보수 | 직접 코드 수정 | AI 어시스턴트 도움 |
| 협업 | Git, 코드 리뷰 등 | 브라우저 기반 실시간 |
graph TD
A[아이디어 구상] --> B[자연어로 프롬프트 작성]
B --> C[AI가 코드 생성]
C --> D[실시간 미리보기 확인]
D --> E{만족하는가?}
E -->|아니오| F[추가 프롬프트로 수정]
F --> C
E -->|예| G[배포 및 공유]
G --> H[지속적 개선]
할일 관리 앱을 만들어줘. 다음 기능들이 필요해:
1. 할일 추가/편집/삭제
2. 완료 상태 토글
3. 카테고리별 필터링 (업무, 개인, 쇼핑)
4. 우선순위 설정 (높음, 보통, 낮음)
5. 달력 뷰로 날짜별 할일 보기
6. 다크모드 지원
디자인은 모던하고 깔끔하게, 색상은 파란색 계열로 해줘.
할일 앱 만들어줘
| 요소 | 설명 | 예시 |
|---|---|---|
| 핵심 기능 | 앱의 주요 기능을 명확히 나열 | "사용자 등록, 로그인, 게시글 CRUD" |
| UI/UX 요구사항 | 디자인 스타일과 색상 지정 | "미니멀한 디자인, 그린 계열 색상" |
| 사용자 시나리오 | 실제 사용 상황 설명 | "학생이 강의 일정을 관리하는 앱" |
| 데이터 구조 | 필요한 데이터 필드 명시 | "제목, 내용, 작성일, 카테고리" |
// 자동 생성되는 기술 스택
- React 18
- TypeScript
- Tailwind CSS
- Vite (빌드 도구)
- React Router (라우팅)
// 통합 백엔드 솔루션
- Supabase (데이터베이스 & 인증)
- Vercel (호스팅 & 배포)
- 자동 API 생성
- 실시간 데이터 동기화
기존 버튼 컴포넌트를 활용해서 새로운 액션 버튼을 만들어줘.
- 기본 스타일은 유지하되
- 아이콘을 추가하고
- 로딩 상태를 표시할 수 있게 해줘
사용자 프로필 페이지에 다음을 추가해줘:
- 작성한 포스트 목록 표시
- 팔로워/팔로잉 수 표시
- 프로필 이미지 업로드 기능
- 데이터는 Supabase와 실시간 동기화되게 해줘
현재 앱을 모바일에 최적화해줘:
- 네비게이션을 햄버거 메뉴로 변경
- 카드 레이아웃을 세로 스택으로 조정
- 터치 제스처 지원 추가
- 모바일에서 사용성이 좋게 버튼 크기 조정
복잡한 기능이 필요할 때:
1. Lovable로 기본 구조 생성
2. 생성된 코드를 다운로드
3. 로컬에서 추가 개발 진행
4. 필요시 전문 개발자와 협업
graph LR
A[아이디어 정리] --> B[기본 구조 생성]
B --> C[핵심 기능 구현]
C --> D[UI/UX 개선]
D --> E[데이터 연동]
E --> F[테스트 & 배포]
F --> G[피드백 수집]
G --> H[반복 개선]
// 기능 추가 패턴
"[기존 기능]에 [새로운 기능]을 추가해줘. [구체적 요구사항]"
// 디자인 개선 패턴
"[특정 컴포넌트]의 디자인을 [원하는 스타일]로 변경해줘"
// 버그 수정 패턴
"[문제 상황]이 발생하는데, [원하는 동작]이 되도록 수정해줘"
Vercel의 v0를 활용하여 창의적이고 매력적인 랜딩 페이지를 제작합니다. 주제는 자유롭게 선택하되, DB와의 상호작용이 적은 주제를 선택해야 합니다.
주제 선정 과정: '포트폴리오'와 '팀플 관리 서비스'라는 두 가지 주제를 두고 고민했습니다. '포트폴리오'는 랜딩 페이지 생성이라는 주제에 들어맞고 DB와의 상호작용이 적기 때문에 주제에 적합했고, '팀플 관리 서비스'는 현재 기획중인 서비스이기 때문에 제 관심사가 잘 반영된 주제였습니다. 결론적으로 '팀플 관리 서비스'를 주제로 선정하였는데, DB와의 상호작용은 임의의 데이터를 삽입하는 식으로 해결하였습니다.
프롬프트를 만들기 위해 서비스의 개요 및 MVP를 작성하였습니다. (하단 이미지)






바이브 코딩 강좌를 들으면서 가장 크게 느꼈던 점은 바이브 코딩은 다수가 아닌 혼자가 개발하는 방식이라는 것이다. 팀원들 개개인이 코드를 각자 짜고 합치는 기존 프로젝트 방식이 아닌, 하나의 프롬프트에 요구사항을 이어서 계속 작성해서 전체 코드를 완성한다는 점이 다르다.
기획 목록 부분에서 UI 변경작업에 관한 것은 피그마로 재설계 후 러버블에 코드를 요구할 예정이며, 나머지 부분은 기존 화면을 유지하고자 한다.
읽어주셔서 감사합니다.
6주차 회고록으로 다시 찾아오겠습니다 ~~~ !
*본 후기는 [웅진씽크빅X스코프랩스] AI를 활용한 DT 기획자 과정(Blog) 리뷰로 작성 되었습니다.