DAY 08바이브코딩 · 최종 완성 · 공개 · 제출
최종 프로젝트 완성 — 다듬기 · 공개 · 제출 · 피드백
오늘은 새 기능을 만드는 날이 아니라 지금까지 만든 것을 완성하는 날입니다. 화면을 다듬고 최종 점검한 뒤, GitHub Pages로 누구나 볼 수 있게 공개하고 주소를 학원 카페에 제출합니다. 강사 피드백을 받아 바로 고쳐서 다시 반영하는 것까지가 오늘의 마무리입니다.
1.수업 구성 · 오늘 진행 방식
화면 다듬기 + 최종 점검 + GitHub Pages 공개 + 카페 제출 + 피드백 반영 (발표는 하지 않습니다)
누구나 열어 볼 수 있는 완성본 주소를 제출하고, 피드백을 받아 한 번 더 고치기
오늘의 흐름
마지막 날 가장 흔한 실수
"마지막 날이니까 기능 하나만 더 넣어 볼까?" → 예상 못한 오류 → 잘 되던 기능까지 망가짐 → 제출 시간까지 고치기만 하다 끝남. 오늘은 더 많이 만드는 날이 아니라, 만든 것을 완성하는 날입니다.
2.STEP 01~02. 상태 점검 · 새 기능 추가 멈추기
현재 상태 점검하기
CLAUDE.md에 "기능 추가 멈추기" 규칙 넣기
새 기능 추가 멈추기
마무리 단계에서 새 기능 추가를 멈추고 지금 있는 기능을 안정시키는 것. 기능의 개수보다 제대로 작동하는 것이 중요합니다. 개발자들은 이것을 Feature Freeze(기능 동결)라고 부릅니다.
대화마다 말하지 않고 CLAUDE.md에 적어 두면, 오늘 나누는 모든 대화에서 자동으로 지켜집니다. DAY 05에서 배운 하네스 활용입니다.
3.디자인 다듬기, 이렇게 말해도 돼요 — 디자이너 용어 대신 우리말로
DAY 07에서 화면 배치를 우리말로 요청했듯이, 디자인을 다듬을 때도 마찬가지입니다. 예전에는 디자이너 · 개발자들이 쓰는 용어를 알아야 했지만, 지금은 어떻게 보이기를 원하는지 우리말로 구체적으로 말하면 AI가 알아서 처리합니다.
"Typography 정리하고 Visual Hierarchy 살려줘. Card는 Border Radius 12px에 Shadow 약하게, 버튼은 Hover에 Transition 넣어줘."
"글꼴을 두 가지로 줄이고, 중요한 제목일수록 크게 해줘. 카드 모서리를 조금 둥글게 하고 그림자는 연하게, 버튼은 마우스를 올리면 색이 부드럽게 진해지게 해줘."
| 디자이너 · 개발자들은 | 무슨 뜻인가요? | 우리는 이렇게 말해요 |
|---|---|---|
| Typography | 글꼴 · 크기 · 굵기 · 줄 간격을 일정하게 정리하기 | "글꼴은 제목용 하나, 본문용 하나만 써줘." |
| Visual Hierarchy | 중요한 것일수록 크고 굵고 눈에 띄게. 첫 화면 5초 안에 무엇을 하는 곳인지 보여야 함 | "첫 화면 제목 → 행동 버튼 → Section 제목 → 본문 순서로 크기 차이를 분명하게 해줘." |
| Border Radius | 모서리의 둥근 정도. 작으면 단정, 크면 부드러운 느낌 | "카드와 버튼의 모서리 둥글기를 똑같이 맞춰줘." |
| Shadow | 요소를 배경과 구분해 주는 그림자 | "카드 그림자를 더 연하게 해줘." |
| Hover · Transition | 마우스를 올렸을 때 바뀌는 모습 · 그 변화가 부드럽게 이어지는 것 | "버튼에 마우스를 올리면 색이 부드럽게 진해지게 해줘." |
| QA | 공개 전에 처음 온 사람의 눈으로 모두 확인하기 | "공개 전에 최종 점검해줘." |
| Feature Freeze | 마무리 단계에서 새 기능 추가 멈추기 | "이제 새 기능은 넣지 말고 다듬기만 해줘." |
왼쪽 용어는 외우지 않아도 됩니다. AI가 답에서 "Shadow를 줄였어요"처럼 말하면 "그림자를 연하게 했구나" 하고 알아보면 충분합니다.
버튼 색이 조금 진해짐, Card가 살짝 올라옴, 메뉴 글자 색이 바뀜
Card가 지나치게 커짐, 버튼이 크게 흔들림, 주변 배치까지 밀려남
4.STEP 03. 화면 다듬기 — 글자 · 일관성 · 마우스 효과
한 번에 모두 바꾸지 않고 하나씩 요청 → 확인합니다. 마음에 안 들면 "방금 바꾼 것을 되돌려줘"라고 하면 됩니다.
5.STEP 04. 임시 콘텐츠 정리 · 최종 점검
최종 점검
공개하기 전에 기능 · 화면 · 내용을 처음 방문한 사람의 눈으로 하나씩 확인하는 것. 디자인을 많이 고친 날이라 잘 되던 기능이 망가지지 않았는지도 다시 봅니다. 개발자들은 이것을 QA(품질 점검)라고 부릅니다.
① 스킬로 먼저 점검하기
/site-checkDAY 05에 만든 점검 스킬이 깨진 링크 · 이미지, 휴대폰 화면 넘침, Secret Key, 임시 글을 한 번에 확인합니다. 스킬이 없다면 "공개 전에 깨진 링크, 깨진 이미지, 휴대폰 화면 넘침, 임시 글이 있는지 점검해줘"라고 요청하세요.
② 직접 눌러 보며 확인하기 — AI가 아니라 내가 합니다
□ 메뉴바 항목을 모두 눌러 봤다
□ 행동 버튼이 다음 행동으로 이어진다
□ 입력창 → 보내기 → Supabase에 저장된다
□ (로그인이 있다면) 가입 · 로그인 · 로그아웃
□ 내용이 너무 넓게 퍼지지 않는다
□ Card 크기 · 간격이 일정하다
□ 사진이 찌그러지지 않는다
□ 가로로 밀리는 곳이 없다
□ 글씨가 너무 작지 않다
□ 버튼을 손가락으로 누르기 편하다
문제가 보이면 DAY 07에서 배운 오류 요청 구조(문제가 생긴 기능 → 내가 한 행동 → 기대한 결과 → 실제 결과 → 고칠 범위)로 요청합니다.
6.GitHub Pages란? — 최종 제출은 왜 GitHub Pages일까
2교시
GitHub Pages
GitHub Repository에 저장한 HTML · CSS · JavaScript 파일을 무료로 인터넷에 공개해 주는 호스팅입니다. DAY 02부터 계속 Push해 온 그 Repository를 설정 한 번으로 사이트로 바꿀 수 있습니다. SSL도 자동으로 적용됩니다.
| 카페24 AI SPACE (DAY 05~07) | GitHub Pages (DAY 08) | |
|---|---|---|
| 배포 방법 | MCP로 연결해서 "배포해줘"라고 말하기 | Git으로 Push하면 자동 반영 |
| 비용 · 기간 | 무료 체험 14일, 이후 유료 | 공개 Repository는 무료로 계속 |
| 할 수 있는 일 | 웹사이트 + 서버에서 돌아가는 프로그램 · 자체 Database | HTML · CSS · JavaScript 파일로 된 사이트만. Database와 로그인은 Supabase가 담당 |
| 잘 맞는 경우 | 서버 기능이 필요한 실제 서비스 운영 | 포트폴리오 · 소개 사이트를 오래 공개 |
AI SPACE는 체험이 끝나면 사이트가 멈춥니다. 피드백을 받고, 수업이 끝난 뒤에도 포트폴리오로 계속 보여 주려면 오래 유지되는 주소가 필요하므로 최종 제출은 GitHub Pages로 합니다.
7.STEP 05. 공개 전 안전 점검 — 비밀 정보 · 경로 · 공개 설정
GitHub Pages로 공개하면 사이트뿐 아니라 Repository의 모든 파일을 누구나 볼 수 있게 됩니다. 공개 버튼을 누르기 전에 아래를 꼭 확인합니다.
Supabase Secret Key, 비밀번호, 내 전화번호 · 주소 같은 개인정보가 코드나 md 파일에 없는지 확인합니다. Publishable Key는 공개되어도 되는 키입니다 (DAY 04).
GitHub Pages는 Repository 맨 위 폴더의 index.html을 첫 화면으로 엽니다.
GitHub Pages 주소는 아이디.github.io/저장소이름/처럼 폴더 안에 있습니다. /images/a.jpg처럼 /로 시작하는 경로는 사진이 깨집니다. images/a.jpg처럼 써야 합니다.
Windows에서는 Photo.JPG와 photo.jpg를 같은 파일로 보지만, 서버는 다른 파일로 봅니다. 내 컴퓨터에선 보이던 사진이 공개 후 깨지는 흔한 원인입니다.
Repository를 Public(공개)으로 바꾸기
무료 계정은 Public Repository만 GitHub Pages를 쓸 수 있습니다. DAY 02에서 Private으로 만들었다면 위 점검을 마친 뒤 바꿉니다.
GitHub의 Repository → Settings → 맨 아래 Danger Zone → Change visibility → Public. (메뉴 위치는 바뀔 수 있습니다)
8.STEP 06. GitHub Pages로 공개하기
먼저 오늘 고친 내용을 모두 Commit → Push해서 GitHub에 올려 둡니다. GitHub Pages는 GitHub에 올라간 파일로 사이트를 만듭니다.
https://내GitHub아이디.github.io/저장소이름/이 주소가 오늘 제출할 최종 주소입니다. 메모장에 복사해 두세요.
공개된 주소에서 다시 확인하기
로그인 기능이 있다면 — Supabase → Authentication → URL Configuration의 Site URL을 GitHub Pages 주소로 바꿔 두세요. 비밀번호 찾기 메일 같은 링크가 이 주소로 연결됩니다. 이메일 · 비밀번호 로그인 자체는 바꾸지 않아도 작동합니다.
9.STEP 07. 학원 카페에 제출하기
학원 카페의 제출 게시판에 아래 양식으로 글을 올립니다. 강사가 주소로 들어가 직접 사이트를 써 보고 댓글로 피드백을 드립니다. 피드백 받고 싶은 부분을 구체적으로 적을수록 도움이 되는 답을 받을 수 있습니다.
"피드백 부탁드립니다."
"휴대폰에서 신청 입력창이 너무 길어 보이는데, 칸을 줄이는 게 나을지 봐 주세요."
10.STEP 08. 피드백 반영하기 — 고치고, Push하고, 알리기
피드백은 끝이 아니라 다음 수정의 출발점입니다. GitHub Pages는 Push하면 자동으로 다시 공개되므로, 같은 주소에서 바로 고친 결과를 보여 줄 수 있습니다.
피드백이 여러 개면 한 번에 하나씩 고치고 확인합니다. 주소를 다시 열었는데 바뀌지 않았다면, 브라우저가 예전 화면을 기억(캐시)하고 있는 것이니 Ctrl + F5(Mac은 Cmd + Shift + R)로 강력 새로고침하세요.
핵심 — 만들고 → 공개하고 → 의견을 받고 → 고치는 것. 실제 웹사이트도 이렇게 계속 나아집니다.
11.AI SPACE 체험 정리하기
DAY 05에 시작한 카페24 AI SPACE 무료 체험은 곧 끝납니다. 카드를 등록하지 않았기 때문에 그냥 두어도 돈이 나가지 않습니다.
체험 기간이 끝나면 AI SPACE에 올린 사이트가 멈추고, 일정 기간이 지나면 데이터가 지워집니다. 프로젝트 원본은 내 컴퓨터와 GitHub에 있으니 걱정하지 않아도 됩니다.
유료로 바꿀 수 있습니다 (출시 기준 가장 낮은 요금제가 월 4,900원부터). 서버 프로그램이나 자체 Database가 필요한 서비스를 만들고 싶을 때 고려해 보세요. 요금과 조건은 바뀔 수 있으니 카페24 안내를 확인하세요.
12.8일 과정 되돌아보기 · 혼자 계속 만들기
수업이 끝난 뒤 혼자 해 볼 다음 도전
13.최종 체크리스트
□ 꼭 필요한 기능이 모두 작동한다
□ 임시 글 · 사진이 남아 있지 않다
□ PC · 휴대폰 점검을 마쳤다
□ Secret Key · 개인정보가 없다
□ GitHub Pages 주소가 열린다
□ 휴대폰으로도 확인했다
□ 학원 카페에 양식대로 제출했다
□ 피드백을 반영하고 Push했다
□ 댓글로 반영했다고 알렸다
마지막 저장 — □ Stage → Commit(메시지 예: "최종 프로젝트 완성 · 피드백 반영") → Push까지 했나요? 방법이 기억나지 않으면 DAY 03의 Git 저장 과정을 참고하세요.