"Given / When / Then" 형식. 예: 빈 입력이면 생성 버튼 비활성화, 성공 시 저장 toast 표시.
PRD 05
검증 방식
브라우저 수동 테스트, 콘솔 에러 0개, 모바일 캡처, README 실행 방법까지 완료 기준으로 적습니다.
PRD 06
GitHub 기준
커밋 단위, 브랜치 이름, PR 설명, 이슈 링크. 처음부터 협업 방식까지 포함합니다.
STEP 07-A · Planning Prompt
Gemini나 Claude에는 기획 산출물을 뽑게 합니다.
복사해서 쓰는 기획 프롬프트
너는 초보자를 돕는 시니어 PM이야.
내 아이디어를 Antigravity로 구현할 수 있게 아래 산출물을 순서대로 만들어줘.
아이디어: [여기에 만들고 싶은 앱]
대상 사용자: [모르면 가정해줘]
제약: 초보자, 1일 안에 MVP, 무료 도구 우선
산출물:
1. 문제 정의: 대상, 현재 불편, 손실, 성공 기준
2. 고객 페르소나 1명
3. IA: 화면 목록, 핵심 기능, 데이터 객체
4. User Journey와 Critical User Journey
5. User Flow: happy path와 edge case
6. 정책 및 PRD: MVP 범위, 데이터/권한 정책, 수용 기준
7. 마지막에 Antigravity에 붙여넣을 실행 프롬프트
좋은 출력인지 확인하는 기준
기능명보다 사용자의 상황과 성공 기준이 먼저 나온다
화면 목록과 데이터 객체가 분리되어 있다
Critical UJ가 1개로 좁혀져 있다
수용 기준이 테스트 가능한 문장이다
마지막 실행 프롬프트에 파일, 검증, 금지사항이 포함된다
STEP 07-B · Execution Prompt
Antigravity에는 "계획부터 검증까지" 명령합니다.
Antigravity 마스터 프롬프트
아래 PRD를 바탕으로 MVP를 구현해줘.
작업 방식:
1. 먼저 Task List와 Implementation Plan을 작성하고 내 승인 전에는 코드 수정하지 마.
2. 파일 구조를 제안하고, 기존 파일을 읽은 뒤 최소 변경으로 구현해.
3. 구현 후 브라우저에서 Critical User Journey를 직접 실행해 검증해.
4. 콘솔 에러, 반응형 390px/1440px, 빈 입력 edge case를 확인해.
5. 마지막에 Code Diff 요약, 실행 방법, 남은 리스크를 README에 정리해.
6. GitHub 커밋 메시지와 PR 본문 초안도 작성해.
PRD:
[Gemini/Claude가 만든 PRD 붙여넣기]
왜 이렇게 시키나
"먼저 Plan"은 초보자의 안전장치입니다
Critical UJ 검증은 말뿐인 완료를 막습니다
콘솔·반응형·edge case는 하네스의 최소 테스트입니다
README와 PR 초안은 GitHub 협업까지 이어줍니다
이 프롬프트는 프로젝트가 커질수록 더 중요해집니다
STEP 08 · Antigravity Work Loop
실행할 때는 5번 루프만 기억하세요.
LOOP 01
Plan 받기
Task List와 Implementation Plan을 먼저 읽고, 틀린 범위는 댓글로 수정.
LOOP 02
작게 승인
한 번에 전체 앱이 아니라 1~2개 화면 단위로 승인. 리스크를 줄입니다.
LOOP 03
Artifact 검토
Diff, Screenshot, Browser Recording을 보고 "진짜 됐는지" 판단.
LOOP 04
댓글로 수정
코드 직접 수정 전, Artifact에 댓글. "버튼 문구를 더 명확히"처럼 구체적으로.
LOOP 05
GitHub 저장
작동 확인 후 commit → push → PR. 다음 실습의 되돌리기 지점이 됩니다.
PRACTICE LADDER · 쉬운 것부터 어려운 것까지
재밌는 프로젝트는 난이도별로 올라갑니다.
LEVEL 1 · 30분
HTML/CSS/JS · 저장 없음
랜덤 명언 카드 생성기
다크/라이트 토글 페이지
포모도로 타이머
MBTI 스타일 퀴즈
프로필 카드 생성기
LEVEL 2 · 1~2시간
localStorage · CRUD
Todo + 태그 + 검색
메모장 SPA
습관 트래커
가계부 CSV 업로드
수업 퀴즈 생성기
LEVEL 3 · 반나절
API · 차트 · 인증
날씨 + 지도 대시보드
유튜브 자막 요약 도구
이미지 갤러리 + 필터
AI 레시피 추천 앱
스터디 플래너 + 통계
LEVEL 4 · 1~3일
Firebase/Supabase · 배포
팀 프로젝트 이슈 트래커
실시간 투표/랭킹 앱
강사용 수업 자료 빌더
예약/문의 CRM
3D 미니 게임 + 리더보드
PART 06 · 실습 프로젝트
작은 문제를 풀어 서비스 MVP로.
포트폴리오는 예쁘지만 문제 해결 연습이 약합니다. 오늘은 강사·학생이 바로 쓸 수 있는
수업자료 퀴즈 생성 서비스를 만들며 기획 → 구현 → 검증 루프를 익힙니다.
PROJECT · 본 수업의 결과물
목표 — "수업자료 퀴즈 생성 서비스".
긴 강의안이나 회의록을 붙여넣으면 핵심 요약, 객관식 퀴즈, 체크리스트를 만들어 저장하는 작은 서비스입니다. 백엔드 없이 시작하고, 나중에 Supabase로 업그레이드합니다.
문제 · 반복 노동
자료 정리 시간이 너무 김
강의자료를 요약하고 퀴즈로 바꾸는 일을 매번 손으로 합니다. 결과 기준도 사람마다 달라집니다.
MVP · 45분
입력 → 생성 → 저장 → 복사
텍스트 입력, 요약/퀴즈 생성, localStorage 저장, 검색, Markdown 복사까지 구현합니다.
난이도 · 입문+
백엔드 없이 시작
처음엔 HTML/CSS/JS와 브라우저 저장소만 사용. DB는 뒤에서 Supabase로 붙입니다.
WORKFLOW · 5 steps
서비스 제작 흐름 — 5단계.
STEP 01
문제 정의
누가, 어떤 자료 정리에 시간을 쓰는지 정의. 성공 기준은 "3분 안에 퀴즈 5개".
STEP 02
IA / UJ
입력 화면, 결과 화면, 저장 목록. Critical UJ는 붙여넣기 → 생성 → 저장 → 복사.
STEP 03
Plan 승인
Antigravity Plan mode에서 Task List와 Implementation Plan을 보고 범위 조정.
STEP 04
구현 + 검증
빈 입력, 짧은 입력, 저장/삭제, 모바일 화면까지 브라우저에서 직접 확인.
STEP 05
GitHub 저장
commit → push → README 정리. 다음 단계에서 Supabase DB로 업그레이드.
UI MOCKUP · Manager View · 첫 프롬프트
서비스는 문제·사용자·검증까지 적습니다.
Antigravity · lesson-kit-builder
Gemini 3 Pro · High
Start a new conversation
수업자료 퀴즈 생성 서비스 MVP를 만들어줘.
문제: 강사/학생이 긴 자료를 요약하고 퀴즈로 바꾸는 시간이 오래 걸림.
사용자: 수업자료를 빠르게 복습 자료로 바꾸고 싶은 입문자.
Critical UJ: 텍스트 붙여넣기 → 생성 → 결과 확인 → 저장 → Markdown 복사.
기능:
- 자료 입력 textarea, 예시 자료 불러오기
- 요약 5줄, 객관식 퀴즈 5개, 실행 체크리스트 생성
- 처음엔 AI API 없이 간단한 규칙 기반으로 동작
- localStorage에 결과 저장, 검색, 삭제
- 빈 입력/짧은 입력/모바일 390px 검증
기술: HTML/CSS/JS만. index.html, style.css, app.js로 분리.
먼저 Plan과 테스트 방법을 보여주고, 내가 승인하면 구현해줘.
@ files/ workflow🌐 BrowserPlan ▾
💡 왜 이 프롬프트가 좋은가: ① 문제와 사용자가 있음 ② Critical UJ가 1개로 좁혀짐 ③ 저장·검색·edge case가 있음 ④ "먼저 Plan"으로 검토 단계를 강제.
UI MOCKUP · Result Preview
결과물은 작지만 실제 서비스처럼 보입니다.
Lesson Kit Builder
수업자료 → 요약 · 퀴즈 · 체크리스트
localStorageNo Backend
INPUT
오늘 수업은 데이터베이스와 스토리지입니다. 데이터베이스는 표로 정보를 저장하고, 스토리지는 이미지와 파일을 저장합니다...
요약 5줄
DB는 표, 스토리지는 파일 저장소. Supabase는 DB·Auth·Storage를 한 번에 제공.
퀴즈 5개
Q1. row와 column의 차이는? Q2. primary key는 왜 필요할까?
체크리스트
□ 테이블 만들기 □ RLS 켜기 □ 저장 버튼 테스트 □ 모바일 확인
저장 목록
DB 입문 · GitHub 개념 · Antigravity Plan mode · Supabase 실습
검색: DB저장 4개Markdown 복사 완료Critical UJ 통과
PROMPT QUALITY · 서비스형 요청
서비스 프롬프트는 예쁜 화면보다 흐름이 먼저입니다.
나쁜 프롬프트
"수업자료 정리 앱 만들어줘"
수업자료 정리 앱 만들어줘. 보기 좋게.
누가 쓰는지 없음
입력·저장 기준 없음
검증할 성공 기준 없음
→
좋은 프롬프트
문제 · 사용자 · Critical UJ · 검증
문제/사용자: 강사·학생의 자료 정리 시간
Critical UJ: 붙여넣기 → 생성 → 저장 → 복사
기술/저장: HTML/CSS/JS, localStorage
검증: 빈 입력, 짧은 입력, 모바일 390px
FAILS · 자주 하는 3가지 실수
초보자가 자주 하는 — 3가지 실수.
남의 시행착오로 — 본인은 같은 함정을 피하세요. "실패담을 미리 듣는 게 가장 빠른 학습".
🪨 너무 짧은 프롬프트
"수업자료 정리 앱 만들어줘"
결과: 입력, 저장, 검증 기준이 없는 빈 화면이 나옵니다. 서비스가 아니라 장식 페이지가 됩니다.
해결: 문제, 사용자, Critical UJ, 저장 방식, edge case를 명시하세요.
⚠️ Agent-driven 모드 + 큰 작업
"기존 폴더 깔끔하게 정리해줘"
결과: 자율 모드 + 모호한 명령 = 실수로 파일 삭제. 휴지통에서 복구하느라 1시간.
해결: 처음에는 무조건 Review-driven. 큰 작업은 명령을 잘게 쪼개세요.
🔓 Browser Subagent + 본인 계정
"내 SNS 자동 댓글 봇 만들어줘"
결과: 비번이 입력되는 모습이 녹화본에 그대로 저장됨. 외부 공유시 노출 위험.
해결: 테스트 계정·더미 데이터로만 시연. 본인 계정 작업은 비번 입력 직전에 Pause.
30 USES · Antigravity로 풀 일상 작업
Antigravity로 — 30가지 일을 풀 수 있습니다.
📚 학습 · 실험 (8개)
01새 라이브러리 사용법 묻기 ("Chart.js로 막대그래프 만드는 법")
02알고리즘 설명 + 시각화 ("이진 탐색 시각화 페이지 만들어줘")
03코드 리뷰 받기 ("이 함수에서 개선할 점 알려줘")
04버그 디버깅 ("이 에러 원인 찾아줘")
05옛 jQuery 코드 → 모던 JS 변환
06API 문서 읽고 요약 (Browser Subagent)
07새 언어 배우기 (Python·Rust·Go 첫 프로젝트)
08코딩 인터뷰 문제 풀이 + 풀이법 설명
🚀 토이 프로젝트 (8개)
09개인 블로그 (마크다운 포스트 + 다크모드)
10가계부 앱 (CSV 업로드 → 자동 분류)
11Pomodoro 타이머 + 통계
12북마크 정리 도구
13QR 코드 생성기
14이미지 압축·리사이즈 도구
15색상 팔레트 추출기
16날씨 대시보드 (OpenWeather API)
⚙️ 자동화 (7개)
17매일 환율 데이터 → CSV 저장 스크립트
18이메일 자동 분류 (Gmail API)
19SNS 정기 포스팅 자동화
20스크래핑 → Notion DB 자동 업데이트
21이미지 폴더 정리 (날짜별 자동 분류)
22PDF에서 표 추출 → Excel
23유튜브 자막 → 요약 글
🎓 학교 · 과제 (7개)
24발표 슬라이드 (HTML로 직접 — 이 슬라이드처럼)
25설문 결과 시각화
26리포트용 인포그래픽
27실험 데이터 그래프 자동화
28플래시카드 학습 앱 (스페이스드 리피티션)
29그룹 프로젝트 진행률 트래커
30졸업작품 데모 사이트 (60분 만에)
PART 07 · GITHUB · DATABASE · SUPABASE · RULES
안전하게, 계속 자라나기.
마지막 파트. GitHub로 되돌릴 수 있는 작업 습관을 만들고, 데이터베이스와 Supabase로 저장 기능을 확장합니다.
Rules·Skills·Harness Engineering으로 Antigravity가 반복 가능하고 검증 가능한 방식으로 일하게 만듭니다.
2026 UPDATE · 3월-5월 흐름
2026년 봄 업데이트의 핵심은 AI에게 일을 맡기되, 권한을 좁히는 것입니다.
초보자에게 중요한 건 버전 번호보다 의미입니다. AI 에이전트가 더 많은 일을 하게 되었고, 그래서 승인·브랜치·비밀키 보호가 더 중요해졌습니다.
ANTIGRAVITY · 2026.03-04
허락표와 작업 경계가 중요해짐
통합 권한 시스템: 파일·터미널·브라우저 행동을 허락표로 관리
Linux sandboxing: AI가 작업할 수 있는 공간을 더 좁힘
MCP 인증·로딩 개선: 외부 도구 연결이 안정화
초보자 의미: AI 직원에게 모든 열쇠를 주지 말고 방마다 허락하기
GITHUB · 2026.03-05
Issue와 PR이 AI 작업 카드가 됨
PR에서 @copilot에게 테스트 수정·리뷰 반영 요청 가능
Copilot App은 브랜치·파일·대화·작업 상태를 세션별로 분리
GitHub MCP secret scanning으로 commit 전 비밀키 검사 가능
초보자 의미: GitHub는 저장소를 넘어 AI 작업 관리판이 됨
SUPABASE · 2026.04-05
DB도 안전 기본값이 강화됨
새 public table의 Data API 자동 노출이 단계적으로 제한
Branching without Git: GitHub 연결 없이 DB 실험 가지 생성
Remote MCP는 OAuth, project scope, read-only 옵션을 제공
초보자 의미: DB도 연습장 branch에서 먼저 실험하기
BEGINNER VIEW · 초딩도 이해하는 비유
Antigravity · GitHub · Supabase는 한 팀입니다.
세 도구를 쉬운 말로 바꾸면
Antigravity시키면 일하는 AI 알바생. 코드를 고치고 브라우저로 확인일꾼
GitHub모든 저장 순간이 남는 온라인 작업 일기장타임머신
Supabase로그인, DB, 파일창고를 빌려주는 온라인 백엔드창고+문지기
Branch원본 공책을 더럽히지 않는 연습장 복사본연습장
MCPAI가 외부 도구에 말을 걸 수 있게 해주는 전화선연결선
RLSDB에서 남의 일기장을 못 보게 막는 문지기 규칙보안문
그래서 작업 순서가 이렇게 됩니다
Gemini나 Claude로 문제와 사용자를 정리합니다
Antigravity Plan mode로 작업 계획을 먼저 받습니다
GitHub branch에서 구현하고 commit으로 저장합니다
Supabase는 branch 또는 테스트 프로젝트에서 DB를 연습합니다
PR에서 변경 내용, 테스트, 남은 위험을 사람에게 보여줍니다
완료 기준을 통과한 뒤에만 main 또는 실제 DB에 반영합니다
PRACTICE · AI에게 열쇠를 주기 전 점검
첫 프로젝트 전에는 권한 체크리스트부터 끝냅니다.
이 실습은 코드보다 먼저 합니다. 안전 설정을 해두면 Antigravity가 빨리 움직여도 사람이 멈출 수 있습니다.
Plan 먼저큰 작업은 바로 수정 금지. Task List와 Implementation Plan을 먼저 검토Plan mode
Workspace 한정AI가 이 프로젝트 폴더 밖의 파일을 만지지 못하게 제한workspace
터미널 승인설치, 삭제, 배포, DB 변경 명령은 사람이 보고 승인Ask
MCP 최소 권한GitHub·Supabase 연결은 필요한 repo/project만 허용scope
읽기 전용 시작처음 연결할 때는 read-only로 구조만 확인하고 쓰기는 나중에read_only
비밀키 금지service role key, 결제 키, AI API 키를 브라우저 코드에 넣지 않기.env
Secret scancommit 전에 GitHub MCP나 GitHub Secret Protection으로 키 노출 검사scan
Branch 실험main과 production DB를 직접 건드리지 않고 연습용 가지에서 작업branch
캡처 증거브라우저 화면, 콘솔 에러 0개, 저장/조회 결과를 PR에 남김artifact
중단 규칙삭제·대량 변경·요금 발생 작업은 무조건 멈추고 질문하게 하기deny
PRACTICE · Issue → Branch → PR
GitHub는 AI 작업을 되돌릴 수 있게 만드는 장치입니다.
실습: 수업자료 서비스에 저장 기능 추가
GitHub에서 lesson-kit-builder repository를 직접 만듭니다
Issue 작성: "생성한 수업자료를 저장하고 다시 불러오기"
Antigravity에게 feat/saved-kits branch에서 작업하라고 지시
구현 후 git status → add → commit → push
PR 본문에 변경 요약, 테스트 결과, 캡처, 남은 위험을 적습니다
리뷰 코멘트가 있으면 Antigravity에게 코멘트별로 반영하게 합니다
Antigravity 지시문
GitHub Issue #1을 기준으로 작업해줘.
규칙:
- main에서 직접 작업하지 말고 feat/saved-kits 브랜치에서만 작업한다.
- 먼저 Plan mode로 변경 파일 목록과 테스트 방법을 제안한다.
- localStorage 저장/조회 기능을 추가한다.
- 브라우저에서 생성 → 저장 → 새로고침 → 다시 조회 Critical UJ를 검증한다.
- 완료 후 git status를 보여주고 commit message를 제안한다.
- PR 본문 초안을 한국어로 작성한다.
PR 본문에는 반드시 포함:
1. 무엇을 바꿨는지
2. 어떤 명령/브라우저 테스트를 했는지
3. 스크린샷 또는 녹화 artifact 위치
4. 아직 Supabase가 붙지 않은 한계
PRACTICE · DB도 연습장에서 먼저
Supabase는 Branch + RLS + MCP로 안전하게 붙입니다.
실습 순서
새 Supabase 프로젝트 또는 개발 branch를 만듭니다
처음 MCP 연결은 project_ref로 프로젝트를 좁히고 read_only=true로 시작합니다
@Supabase
현재 프로젝트의 table 목록과 RLS 상태를 읽어줘.
처음에는 절대 schema를 변경하지 말고 read-only로 확인만 해줘.
그다음 아래 앱을 위한 SQL 계획을 제안해줘.
- 앱: Lesson Kit Builder
- 사용자마다 자기 자료만 저장/조회
- table: profiles, lesson_kits, quiz_questions
- RLS: authenticated 사용자는 자기 user_id row만 접근
- service role key는 브라우저 코드에 금지
출력:
1. table 설계
2. RLS policy 초안
3. 테스트용 sample data
4. 위험한 작업 목록
5. 내가 승인해야 실행할 SQL
GITHUB 101 · 개발자들의 작업 기록장
GitHub는 코드용 Google Drive + 타임머신입니다.
초보자는 먼저 단어를 쉬운 비유로 잡으면 됩니다. Antigravity가 코드를 바꿔도 GitHub가 있으면 이전 상태로 돌아갈 수 있습니다.
RepositoryGitHub에서 직접 만드는 온라인 프로젝트 폴더. 예: 수업자료 서비스 코드를 담는 상자lesson-kit-builder
Branchmain 원본을 망치지 않는 작업용 복사본. 새 기능은 여기서 실험feat/quiz-generator
Commit작업 중간 저장. 게임 저장 슬롯처럼 "여기까지 완료"를 기록git commit -m "feat: add home"
Push내 컴퓨터 저장 기록을 GitHub 온라인 저장소로 업로드git push
Pull Request작업 브랜치를 main에 합쳐도 되는지 확인 요청PR
CloneGitHub 저장소를 내 컴퓨터로 내려받기. 처음 시작할 때 사용git clone URL
PullGitHub의 최신 변경을 내 컴퓨터에 반영git pull
Issue해야 할 일 카드. "모바일에서 버튼 깨짐" 같은 버그 기록#12
GitHub MCPAntigravity가 GitHub의 repo, issue, PR을 읽고 만들게 연결하는 통로@GitHub
ActionsPush나 PR 때 테스트와 배포를 자동 실행하는 로봇CI
GITHUB WORKFLOW · 되돌릴 수 있게 만들기
Repository 만들기 → Branch → Commit → Push.
1. GitHub에서 Repository 직접 만들기
github.com 로그인 → 우상단 + → New repository
이름 입력: lesson-kit-builder
초보자는 Public, 비공개 연습은 Private
로컬에 이미 파일이 있으면 README 체크 해제. 완전 새로 시작이면 README 체크 가능
Create repository 클릭 → GitHub가 원격 저장소 URL을 보여줌
2. Branch는 안전한 작업 복사본
main은 제출용 원본 노트, branch는 연습장입니다. Antigravity가 실수해도 main을 바로 망치지 않게 새 가지에서 작업합니다.
git checkout -b feat/quiz-generator
# 뜻:
# feat = 새 기능
# quiz-generator = 퀴즈 생성 기능 작업
진짜 Git 저장소를 구현하는 게 아닙니다. Repository, Branch, Commit, Issue 개념을 몸으로 익히는 미니 서비스를 만듭니다.
MVP 기능
Repository 만들기: 이름, 설명, 공개/비공개
Branch 만들기: main에서 새 작업 가지 생성
Commit 남기기: 메시지, 변경 파일, 시간 기록
Issue 보드: Todo / Doing / Done 상태 이동
localStorage 저장: 새로고침해도 데이터 유지
왜 백엔드 없이 시작하나
처음엔 개념 학습이 목표라 서버가 필요 없습니다
브라우저 저장소만으로 CRUD 흐름을 이해할 수 있습니다
나중에 데이터가 여러 기기에서 필요해지면 DB를 붙입니다
이 업그레이드 지점이 바로 Supabase 실습입니다
PROMPT · GitHub 개념 앱 만들기
이 프롬프트로 GitHub 개념을 앱으로 익힙니다.
Antigravity 실행 프롬프트
백엔드 없이 GitHub 개념을 연습하는 미니 서비스를 만들어줘.
목표:
- 초보자가 repository, branch, commit, issue를 화면에서 직접 만들어보며 이해한다.
- 실제 Git 명령을 실행하지 않고, 개념을 localStorage 데이터로 시뮬레이션한다.
기능:
1. Repository 생성/선택/삭제
2. Branch 생성: main에서 feat/... 브랜치 만들기
3. Commit 작성: 메시지, 변경 파일명, 설명, 시간 저장
4. Issue 작성: Todo/Doing/Done 보드에서 이동
5. Repository별 commit timeline과 issue 목록 표시
6. 빈 입력, 중복 이름, 삭제 확인 처리
기술:
- HTML/CSS/JS만 사용
- index.html, style.css, app.js 분리
- 먼저 Plan과 데이터 구조를 보여주고 승인 후 구현
- 브라우저에서 Critical UJ를 직접 검증
데이터 구조 예시
Repository
- id
- name
- description
- visibility
- createdAt
Branch
- id
- repoId
- name
- baseBranch
Commit
- id
- repoId
- branchId
- message
- changedFiles[]
- createdAt
Issue
- id
- repoId
- title
- status
DATABASE 101 · 파일에서 DB로
DB는 엑셀 파일이 너무 많아져서 나온 해결책입니다.
처음엔 파일로도 됩니다. 하지만 사람이 많아지고 데이터가 커지면 파일 방식은 금방 한계가 옵니다.
문제 01 · 중복
같은 정보가 여러 파일에 있음
고객 주소가 고객 파일에도, 주문 파일에도 있으면 한 곳만 고쳤을 때 데이터가 엇갈립니다.
문제 02 · 검색
전체 파일을 뒤져야 함
"Daniel이 만든 퀴즈만 보여줘" 같은 요청을 매번 파일 전체 검색으로 처리하면 느립니다.
문제 03 · 동시 수정
두 명이 동시에 저장하면 꼬임
A가 고친 파일을 B가 옛 버전으로 덮어쓰면 작업이 날아갑니다. DB는 이런 충돌을 관리합니다.
그래서 DB는 데이터를 표로 나누고, 연결하고, 빠르게 찾고, 안전하게 저장하는 시스템입니다.
DATABASE WORDS · 초보자 단어장
DB 단어는 엑셀 비유로 잡으면 됩니다.
Table엑셀 시트 하나. 예: 저장된 수업자료 목록lesson_kits
Row가로 한 줄. 저장된 자료 1개id=1
Column세로 항목. 제목, 내용, 생성일 같은 속성title
Primary Key각 row의 주민등록번호 같은 고유 IDid uuid
Foreign Key다른 table의 row를 가리키는 연결고리kit_id
SQLDB에게 묻는 문장. "이 조건의 자료를 보여줘"select *
Join두 table을 연결해 한 번에 보는 것users + kits
Index책 맨 뒤 찾아보기. 검색을 빠르게 함created_at
정규화중복을 줄이기 위해 table을 잘 나누는 설계users / kits
ACID돈, 주문, 저장처럼 꼬이면 안 되는 작업을 안전하게 처리하는 원칙transaction
DATABASE VS STORAGE · 어디에 무엇을 저장하나
DB는 정보 표, Storage는 큰 파일 창고입니다.
Database
작고 검색 가능한 정보
사용자 ID, 제목, 설명, 상태, 생성일
파일의 URL과 소유자 정보
누가 볼 수 있는지 권한 규칙
SQL로 검색, 정렬, 조인
+
Storage
이미지·영상·문서 같은 큰 파일
Bucket: 파일을 담는 큰 창고
Object: 사진 1장, PDF 1개 같은 파일
Key: 파일 이름 또는 경로
CDN: 가까운 곳에서 빠르게 전달
예: 프로필 사진 파일은 Storage에 저장하고, 그 사진 URL과 소유자 ID는 DB에 저장합니다.
SUPABASE 101 · 백엔드 기능 묶음
Supabase는 백엔드 초보자용 올인원 키트입니다.
Firebase처럼 편하게 시작하되, PostgreSQL이라는 강력한 SQL 데이터베이스를 그대로 씁니다.
DatabasePostgreSQL 기반. table, SQL, join, index를 제대로 사용Postgres
Auth이메일 로그인, 소셜 로그인, 사용자 세션 관리auth.users
Storage이미지, 영상, PDF를 bucket/object로 저장buckets
Auto APItable을 만들면 데이터를 넣고 빼는 API가 자동으로 생김REST
RealtimeDB가 바뀌면 연결된 화면에 즉시 반영WebSocket
RLS브라우저에서 DB에 접근할 때 row 단위 권한을 막아주는 핵심 보안policy
Edge Functions비밀키가 필요한 작업, 결제 웹훅, AI API 호출을 서버리스 함수로 처리Deno
profiles
- id uuid references auth.users
- display_name text
lesson_kits
- id uuid primary key
- user_id uuid references auth.users
- title text
- source_text text
- summary text
- checklist jsonb
- created_at timestamptz
quiz_questions
- id uuid primary key
- kit_id uuid references lesson_kits
- question text
- choices jsonb
- answer_index int
초보자 보안 규칙
Supabase URL과 anon key는 브라우저에 있어도 됩니다
단, public table에는 반드시 RLS를 켭니다
사용자는 자기 user_id row만 읽고 쓰게 합니다
service role key는 절대 프론트엔드에 넣지 않습니다
AI API 키는 Edge Function 같은 서버 쪽에 둡니다
PROMPT · DB 붙이기
DB 작업은 Plan mode + RLS 확인이 필수입니다.
Antigravity 업그레이드 프롬프트
현재 localStorage로 저장하는 Lesson Kit Builder를 Supabase 버전으로 업그레이드해줘.
먼저 코드 수정하지 말고 Plan부터 작성해줘.
요구사항:
1. Supabase 클라이언트 설정 파일을 분리한다.
2. lesson_kits, quiz_questions table SQL을 제안한다.
3. RLS를 켜고 "본인 데이터만 읽기/쓰기" policy를 작성한다.
4. 기존 localStorage 저장/읽기 함수를 Supabase CRUD로 교체한다.
5. 로그인 전에는 데모 모드, 로그인 후에는 클라우드 저장 모드로 동작한다.
6. service role key는 절대 브라우저 코드에 넣지 않는다.
7. 브라우저에서 생성 → 저장 → 새로고침 → 다시 조회 Critical UJ를 검증한다.
승인 전 체크
table 이름이 명확한가
user_id가 모든 개인 데이터에 있는가
RLS policy가 select/insert/update/delete별로 있는가
anon key와 service role key를 구분했는가
빈 상태, 로딩, 에러 메시지가 화면에 있는가
삭제 작업 전에 확인 단계가 있는가
RULES · 매번 반복할 지시를 파일로 저장
Rule.md는 에이전트의 작업 규칙입니다.
Antigravity 공식 흐름에서는 전역 규칙은 ~/.gemini/GEMINI.md, 프로젝트 규칙은 .agents/rules/에 둡니다. 팀에서 RULE.md라고 부르더라도 핵심은 같습니다.
초보자용 프로젝트 Rule 예시
# beginner-project-rule
- 항상 한국어로 설명한다.
- 코드 수정 전 먼저 Plan을 제시하고 승인을 기다린다.
- 초보자가 이해할 수 없는 전문 용어는 짧게 풀어쓴다.
- 삭제, 이동, 대량 변경 전에는 반드시 이유와 영향 범위를 묻는다.
- UI는 모바일 390px과 데스크톱 1440px에서 확인한다.
- 완료 보고에는 변경 파일, 테스트 결과, 남은 리스크를 포함한다.
어디에 두나
전역 규칙: ~/.gemini/GEMINI.md
프로젝트 규칙: .agents/rules/code-style-guide.md
워크플로우: .agents/workflows/generate-unit-tests.md
팀에 공유하려면 .agents/ 폴더를 GitHub에 커밋
규칙은 짧고 강하게. 너무 길면 에이전트가 놓칩니다
RULE QUALITY · 길수록 좋은가?
Rule.md는 길수록 좋은 게 아닙니다.
좋은 Rule은 "많은 말"이 아니라 반복 행동을 바꾸는 짧은 기준입니다. 너무 길면 매 작업마다 토큰을 잡아먹고, 중요한 규칙이 묻힙니다.
나쁜 Rule
장문 소설형 규칙
배경 설명이 길고 행동 지시가 흐림
"잘", "예쁘게", "깔끔하게"처럼 판단 기준이 애매함
프로젝트마다 달라지는 내용을 전역 Rule에 넣음
매번 필요 없는 긴 체크리스트를 항상 읽게 함
→
좋은 Rule
짧고 검증 가능한 규칙
한 줄에 행동 1개만 적음
"언제 / 무엇을 / 어떻게"가 보임
항상 지킬 것만 Rule에 둠
긴 절차는 Workflow나 Skill로 분리
RULE EXAMPLES · 바로 넣어도 되는 규칙
초보자에게 좋은 Rule은 안전·검증·설명입니다.
처음 프로젝트에 추천하는 Rules
# beginner-antigravity-rules
## Communication
- 항상 한국어로 설명한다.
- 초보자가 모를 수 있는 개발 용어는 처음 등장할 때 1문장으로 풀어쓴다.
## Planning
- 코드 수정 전 Task List와 Implementation Plan을 먼저 제시한다.
- 큰 작업은 화면/기능 단위로 쪼개고, 한 번에 2개 이상 큰 파일을 바꾸지 않는다.
## Safety
- 삭제, 이동, 대량 포맷팅, 패키지 제거 전에는 반드시 승인을 요청한다.
- 비밀번호, API 키, 토큰, 개인 파일은 읽거나 출력하지 않는다.
## Quality
- 구현 후 Critical User Journey를 브라우저에서 직접 검증한다.
- 완료 보고에는 변경 파일, 테스트 결과, 남은 리스크를 포함한다.
Rule에 넣지 말아야 할 것
한 번만 필요한 작업 지시: 오늘 할 일은 채팅에 입력
긴 PRD 전문: docs/prd.md로 두고 @file로 첨부
긴 테스트 절차: Workflow 또는 Skill로 분리
비밀값: API 키, 토큰, 계정 정보는 절대 Rule에 저장 금지
취향만 있는 문장: "멋있게" 대신 "8px radius, 모바일 우선"처럼 구체화
CONCEPT · Refactoring
리팩토링은 기능은 그대로, 내부를 더 좋게 바꾸는 일입니다.
초보자는 리팩토링을 "다시 만들기"로 오해하기 쉽습니다. 정확히는 사용자가 보는 기능은 유지하면서 코드의 구조, 이름, 중복, 읽기 쉬움을 개선하는 작업입니다.
WHAT
무엇을 바꾸나
긴 함수를 작게 나누기, 중복 코드 합치기, 변수 이름 명확히 하기, 파일 구조 정리, 컴포넌트 분리.
NOT
무엇이 아닌가
새 기능 추가, 디자인 변경, API 바꾸기, DB 구조 변경은 리팩토링이 아니라 기능 변경 또는 구조 변경입니다.
WHY
왜 하나
다음 수정이 쉬워지고, 버그가 줄고, Antigravity가 프로젝트를 더 잘 읽습니다. AI도 읽기 좋은 코드에서 일을 잘합니다.
WHEN
언제 시키나
기능이 작동하는 걸 확인한 뒤. 먼저 테스트/브라우저 검증을 하고, 그 다음 리팩토링을 시킵니다.
PROMPT
Antigravity 지시 예시
"동작은 바꾸지 말고 중복만 줄여줘. 변경 전후 테스트 방법을 먼저 제시하고, Diff를 작게 유지해줘."
RULE
좋은 안전 규칙
"리팩토링 중에는 사용자에게 보이는 기능과 문구를 바꾸지 않는다. 변경 후 기존 Critical UJ를 다시 검증한다."
SKILLS · 필요할 때만 불러오는 전문 패키지
SKILL.md는 자주 쓰는 전문 작업을 패키지로 묶는 방법입니다.
Rules가 항상 켜지는 기본 규칙이라면, Skills는 요청이 맞을 때만 로드되는 전문 매뉴얼입니다. 긴 체크리스트, 템플릿, 스크립트는 Skill로 빼는 게 좋습니다.
---
name: prd-to-antigravity-prompt
description: PRD를 읽고 Antigravity 실행 프롬프트로 변환한다. 문제 정의, 페르소나, IA, UJ, User Flow가 있을 때 사용한다.
---
# PRD to Antigravity Prompt
1. PRD에서 MVP 범위와 제외 범위를 분리한다.
2. Critical UJ를 1개로 좁힌다.
3. 수용 기준을 Given/When/Then으로 바꾼다.
4. Antigravity가 먼저 Plan을 만들도록 실행 프롬프트를 작성한다.
5. 검증 항목에는 브라우저 테스트와 GitHub PR 초안을 포함한다.
HARNESS ENGINEERING · 프롬프트 다음 단계
하네스 엔지니어링은 AI가 일하는 환경을 설계하는 일입니다.
좋은 프롬프트 하나로 끝내는 시대가 아닙니다. 규칙, 컨텍스트, 권한, 테스트, 산출물, 리뷰 루프를 묶어야 에이전트가 프로젝트를 끝냅니다.
WHY HARNESS MATTERS · 왜 중요한가
하네스가 없으면 AI는 답변을 하고, 하네스가 있으면 AI는 프로젝트를 끝냅니다.
프롬프트만 있는 작업
"앱 만들어줘"
계획 없이 바로 파일을 바꿈
테스트 없이 "완료"라고 말함
권한·삭제·외부 접속 위험이 커짐
다음 날 같은 품질이 반복되지 않음
→
하네스가 있는 작업
규칙 + 출력물 + 검증 루프
각 단계의 파일 산출물이 남음
Critical UJ와 테스트가 완료 조건이 됨
Allow/Deny/Ask로 행동 범위를 통제
GitHub PR로 사람이 리뷰할 수 있음
HARNESS TEMPLATE · Antigravity에 적용하기
Antigravity용 하네스는 6단계 파일 산출물로 만듭니다.
하네스 실행 프롬프트 골격
너는 이 프로젝트의 실행 에이전트다.
각 단계는 반드시 파일 산출물을 남기고, 다음 단계는 이전 파일을 읽고 진행한다.
1. Research Agent: docs/01-research.md
2. Architect Agent: docs/02-ia-flow.md
3. Product Agent: docs/03-prd-policy.md
4. Engineer Agent: docs/04-implementation-plan.md
5. QA Agent: docs/05-test-plan.md
6. Reviewer Agent: docs/99-review.md
완료 기준:
- README.md가 모든 문서를 링크한다.
- Critical UJ가 브라우저에서 검증된다.
- 콘솔 에러 0개, 모바일/데스크톱 캡처 포함.
- Reviewer 피드백은 resolved / deferred로 표시한다.
- GitHub PR 본문 초안을 작성한다.
초보자 체크포인트
각 단계마다 "파일로 남겨"라고 말해야 합니다
역할 전환 문장을 명시하면 결과가 덜 섞입니다
완료 기준은 숫자와 파일명으로 적습니다
실행 전에는 Review-driven, Terminal Request Review 권장
큰 프로젝트는 하루 1개 하네스가 아니라 단계별 PR로 쪼갭니다
2026 SOURCES · 최신 업데이트 확인 링크
2026년 3-5월 업데이트는 이 자료 기준으로 반영했습니다.
Antigravity 항목은 Releasebot이 Google 원문 링크를 추적한 업데이트 자료 기준입니다. GitHub와 Supabase는 공식 changelog/docs 기준입니다.