2026.08.03 / Jun
바이브코딩 18일차에 오신 여러분에게 박수를 보냅니다. 이제 마지막 3일간 여러분의 바이브코딩에 대한 지식과 경험을 최종 정리하고 동료들과 성과를 공유하게 됩니다.
구름 바이브코딩 마지막 3일간은 지난 17일 동안 배운 내용을 하나의 완성된 개인 프로젝트로 증명하는 시간이며, 18~19일차는 개발 자체보다 MVP 완성 → 배포 → 문서화 → 발표의 전체 사이클을 경험의 완성에 초점을 맞춥니다.
최종 3일 수료 프로젝트 개요
이번 개인 프로젝트의 최종 산출물을 다음 5종 세트로 명확하게 정의합니다.
① 기술명세서(SPEC) → ② 작동하는 Web App → ③ GitHub Repository → ④ Vercel 배포 URL → ⑤ 발표자료
즉, 수료 시점에 학습자가 단순히 “바이브코딩을 배웠다”가 아니라,
아이디어를 정의하고 → AI와 SPEC을 만들고 → 구현하고 → GitHub로 관리하고 → 실제 서비스로 배포하고 → 결과를 설명할 수 있다.
라는 경험을 갖게 하는 것이 핵심입니다.
최종 프로젝트 체크리스트
- 프로젝트 이름과 한 줄 설명이 있다.
- 해결하려는 문제가 명확하다.
SPEC.md가 있다.- 핵심 기능 3개 이상이 작동한다.
- API Key가 코드에 노출되지 않았다.
- GitHub Repository에 코드가 올라가 있다.
- README가 작성되어 있다.
- Vercel Production 배포가 완료되었다.
- 다른 사람이 URL을 열어 사용할 수 있다.
- 발표자료가 완성되었다.
- 5분 내 Live Demo가 가능하다.
Day 18. 개인 프로젝트 기획 & MVP Build
목표
아이디어를 빠르게 확정하고 SPEC 기반으로 작동하는 MVP를 만든다.
| 단계 | 권장 시간 | 수행 내용 | 산출물 |
|---|---|---|---|
| 프로젝트 Kick-off | 30분 | 최종 프로젝트 목표/평가기준 설명 | 프로젝트 목표 |
| 아이디어 선정 | 60분 | 개인 업무·관심사 기반 아이디어 발굴 및 범위 축소 | Project Idea |
| SPEC 작성 | 60분 | 사용자, 문제, 기능, 화면, 기술스택 정의 | SPEC.md |
| 프로젝트 Setup | 30분 | Next.js + TypeScript + GitHub 구성 | Repository |
| Core Build | 3시간 | Cursor/AI 활용 핵심 기능 구현 | MVP |
| 테스트/디버깅 | 1시간 | 오류 수정, UX 점검 | MVP v0.8 |
| 중간 리뷰 | 30분 | 서로 데모 및 개선점 확인 | 개선 목록 |
아이디어 선정 기준
프로젝트 아이디어는 멋있는 아이디어보다 이틀 안에 완성 가능한 아이디어를 우선하도록 지도하면 좋겠습니다.
권장 공식은:
나의 업무/관심 분야 + 해결하고 싶은 문제 + AI/API + 간단한 Web UI
예를 들어 교육생의 소속과 관심 분야에 따라 기상 데이터 분석 Agent, 기업 문서 요약 Agent, 회의 Insight Generator, GitHub Repository Analyzer, 업무용 Multi-LLM Assistant, 공공데이터 분석 Dashboard 등으로 발전시킬 수 있습니다.
특히 기능은 처음부터 많게 잡지 않고,
Must Have 3개 + Nice to Have 2개
정도로 제한하는 것이 좋습니다.
Day 19. 완성도 향상 & Deploy & 발표 준비
목표
MVP를 실제 사용할 수 있는 Product 형태로 완성하고 인터넷에 배포한다.
| 단계 | 권장 시간 | 수행 내용 | 산출물 |
|---|---|---|---|
| 전일 결과 Review | 30분 | 기능/오류/미완성 영역 확인 | TODO |
| Build Update | 2시간 | 핵심 기능 완성 및 UI/UX 개선 | v1.0 |
| Test & Debug | 1시간 | 예외처리, 모바일 화면, API 오류 확인 | Stable Build |
| GitHub 정리 | 1시간 | README, SPEC, Screenshot, 사용법 작성 | GitHub Repo |
| Vercel Deploy | 1시간 | 환경변수 설정 및 Production 배포 | Live URL |
| 발표자료 작성 | 1시간 | 프로젝트 Story 구성 | 발표자료 |
| 발표 리허설 | 1시간 | 5분 발표 + Demo 연습 | Final Pitch |
이날 중요한 원칙은 오후부터 신규 기능 개발을 중단하는 것입니다.
프로젝트가 작더라도 정상 작동하고 배포된 상태가, 기능은 많지만 오류가 있는 프로젝트보다 훨씬 좋은 결과물입니다.
GitHub README도 단순 설명이 아니라 작은 Project Portfolio로 만들면 좋습니다.
# Project Name
## 1. 프로젝트 소개
## 2. 해결하려는 문제
## 3. 주요 기능
## 4. Architecture
## 5. Tech Stack
## 6. Screenshots
## 7. Getting Started
## 8. Deployment
## 9. 향후 발전 방향
Day 20. Demo Day & 수료식
마지막 날은 일반적인 교육보다 Mini Demo Day 형태로 운영하는 것을 추천합니다.
발표 구성 — 1인 5~7분
Problem → Idea → Solution → Architecture → Demo → Learning
발표자료도 5~7장 정도면 충분합니다.
| Slide | 내용 |
|---|---|
| 01 | Project Title / 한 줄 소개 |
| 02 | 해결하려는 문제 |
| 03 | 핵심 기능 |
| 04 | Architecture / Tech Stack |
| 05 | Live Demo |
| 06 | 개발 과정과 문제 해결 |
| 07 | 향후 발전 방향 |
여기서 특히 Live Demo를 중심에 두는 것이 좋습니다.
발표자가 실제 Vercel URL을 열고,
Input → AI/API Processing → Result
흐름을 직접 보여주게 하면 지난 20일의 학습 성과가 매우 명확하게 드러납니다.
최종 프로젝트 권장 Architecture
입문자의 최종 프로젝트라면 복잡한 구조보다 다음 정도가 적절합니다.
User
↓
Next.js Web App
↓
UI / Server Component
↓
Server Action / Route Handler
↓
External API / LLM
↓
GPT / Gemini / Claude
↓
Result
필요한 프로젝트만 한 단계 발전시켜:
User
↓
Next.js
↓
Planner / Agent
↓
Tool Registry
├─ LLM
├─ Search API
├─ Public API
└─ Data Processing
↓
Result
구조까지 도전하도록 하면 좋겠습니다.
프로젝트 평가 기준
프로젝트 완성도를 높이기 위한 Self-check Rubric
| 영역 | 비중 | 확인 사항 |
|---|---|---|
| 문제 정의 | 15% | 해결하려는 문제가 명확한가 |
| SPEC | 15% | 기능과 구조가 문서화되었는가 |
| 기능 구현 | 25% | 핵심 기능이 실제 작동하는가 |
| AI/API 활용 | 15% | 적절한 기술을 활용했는가 |
| GitHub/배포 | 15% | Repo와 Vercel 서비스가 존재하는가 |
| 발표/설명 | 15% | 프로젝트를 명확하게 설명하는가 |
문제 정의 → SPEC → AI 협업 → 검증 → 배포 능력 확인
