# 바이브코딩 1도 모르는 초보자의 웹사이트 시행착오기

- 작성자: [새벽](https://community.clauders.ai/member/imported-member-9CAbZ7I2eN)
- 공간: [사장님의 AI 시간 벌기](https://community.clauders.ai/owner-time)
- 게시: 2026-10-07
- 연재: [사장님의 AI 시간 벌기](https://community.clauders.ai/series/owner-time) 3/3편
- 태그: #사업장자동화
- 주소: https://community.clauders.ai/owner-time/post/%EB%B0%94%EC%9D%B4%EB%B8%8C%EC%BD%94%EB%94%A9-1%EB%8F%84-%EB%AA%A8%EB%A5%B4%EB%8A%94-%EC%B4%88%EB%B3%B4%EC%9E%90%EC%9D%98-%EC%9B%B9%EC%82%AC%EC%9D%B4%ED%8A%B8-%EC%8B%9C%ED%96%89%EC%B0%A9%EC%98%A4%EA%B8%B0-6073a7a5-a26f-81de-bb09-d0fd5768a287

---

## **📝 한줄 요약**

코딩을 전혀 제가 Codex와 Claude (+ Aside) 로 3주 만에 영어 병원 웹사이트 50페이지와 블로그 원고 24편을 만들었지만, **큰 그림 없이 여기저기 손대다 보니 아직 검색에 공개된 페이지는 0개**입니다. 이 글은 그 3주 동안의 시행착오 기록입니다.

## **🙋 저는 이런 사람이에요**

- 코딩 경험은 0입니다. 터미널, Git, 데이터베이스라는 단어도 이번에 처음 배웠어요.

## **🎯 이런 분들께 도움돼요**

- 바이브코딩으로 가게·회사 홈페이지를 직접 만들어 보려는 비개발자
- 직원과 함께 2~3명 이상이 동시에 웹사이트를 만드는 상황 (제가 이 상황이 뭔가 힘들었습니다. 용평에서 혼자 하면서 다른 멘토님들의 조언을 받을때는 뭔가 천국 같았는데….회사에 복귀해서 한계정을 맥북과 데스크탑 윈도우로 동시에 2명 이상이 작업하니까…github의 개념을 모르는 상태에서 작업하다보니 멘붕이 왔습니다..)
- Codex, Claude Code, Claude 채팅 등 AI 여러 개를 함께 쓰다가 파일이 꼬인 분
- Firebase, Supabase 같은 이름을 듣고 "나도 바꿔야 하나?" 고민 중인 분

## **🛠️ 사용한 도구**

**도구**

**맡은 일**

Codex (맥 데스크톱 앱)

웹사이트 코드, 관리자 화면, 예약 기능, 배포

Claude 채팅 (프로젝트 기능)

메뉴·URL 설계, 블로그 원고, 가격 조사, FAQ

Firebase

처음엔 전부(호스팅·로그인·데이터·사진), 지금은 호스팅·로그인·사진

Supabase

9/28부터 예약·관리자 데이터

GitHub (Private 저장소)

컴퓨터 사이 파일 보관함

맥북 + Windows PC

회사 컴퓨터에서 디자인을 하면서 두 대에서 번갈아 작업

## **📅 3주간 한 일 (최신순)**

**날짜**

**한 일**

10/7

GitHub 업로드 성공. Windows에서 한 디자인을 비교해 보니 충돌 파일 62개

10/5

"다른 컴퓨터에서도 이어서 하고 싶다" → GitHub 업로드가 안전장치에 막힘

10/1~10/6

Windows PC에서 로고·의사 사진·글꼴·Before & After 작업 (ZIP 사본에서)

9/29

운영 사이트에서 테스트 예약 1건 저장 성공.

9/28

관리자 편집 패널 노출 문제 발견 → 새벽 3시부터 밤 12시까지 Firebase→Supabase 이전

9/26~9/27

블로그 원고 24편, 가격 페이지, Treatments 메뉴 8그룹. 글 16편 업로드(비공개)

9/24~9/25

Claude 프로젝트 시작. URL 최종표

9/21~9/23

글꼴 시안, 메뉴별 URL 정리, 개발 명세서(Spec Kit), 자격 페이지

9/19~9/20

Firebase로 사이트 첫 업로드. 예약 신청서, 동의 항목, 예약 가능 시간 관리

9/18

Codex에 "영어 사이트 분석" 처음 요청

숫자로 보면 Codex 대화창 11개에 메시지 1,221개(제가 보낸 것만 316개), Claude 프로젝트 문서 111개가 쌓였어요.

## **😫 시행착오 1 — 큰 그림 없이 오가다 보니 하나도 끝나지 않았다**

**3주 동안 만든 건 많은데, "완성"이라고 부를 수 있는 건 없었어요.** 하루는 디자인, 다음 날은 관리자 화면, 그다음은 블로그 글을 하다가 다시 디자인으로 돌아갔거든요.

실제로 있었던 일을 모아 보면 이렇습니다.

- **디자인을 세 번 했어요.** 9/21 글꼴 시안 8개, 9/26 Claude가 정리한 색·글꼴 기준, 10/1~10/6 Windows에서 또 새 글꼴·로고. 세 번 모두 다른 글꼴을 골랐어요.
- **메뉴와 주소(URL)를 여러 번 바꿨어요.** /skin-concerns/ → /concerns/, 블로그는 /blog/ → /journal/ → 다시 /blog/. 주소가 바뀔 때마다 이미 쓴 글의 내부 링크도 같이 고쳐야 했어요.
- **블로그 글을 먼저 썼는데, 글이 가리킬 페이지가 없었어요.** "GLT™ 원리", "통증 관리" 같은 설명 페이지가 아직 없어서, 24편의 글에 임시 링크 표시(link:glt)를 넣어 두었어요.
- **관리자 화면을 먼저 만들었어요.** 디자인 편집, 예약 관리, 기사·영상 관리 화면까지 만들었지만, 아직 완성도가 낮아서, 정작 실제 고객 예약은 0건이었어요.

그 결과 웹사이트에는 50개 페이지가 올라가 있지만, **검색엔진이 읽을 수 있게 공개(index)한 페이지는 0개**예요. 모든 페이지가 "검토 전"이라 비공개(noindex) 상태로 멈춰 있습니다. GEO가 목표였는데, 검색에 나오는 단계까지 간 페이지가 하나도 없는 거예요.

**돌아보면 이 순서가 맞았어요.**

1. 목표 페이지 1개를 정한다 (예: 특정 피부관리 페이지)
2. 메뉴·URL을 한 번에 확정하고 더 바꾸지 않는다
3. 디자인 기준(색·글꼴·로고)을 한 번 정한다
4. 그 페이지 1개를 끝까지 만들고, 검토하고, 검색에 공개한다
5. 같은 틀로 다음 페이지를 늘린다
6. 예약·관리자·회원가입은 방문자가 생긴 다음에 만든다 ⇒ 사실 이부분이 pain point 라는걸 용평 워케이션에서 확인을 하면서, 예약 관리자 페이지를 급하게 만들었는데요. 다른 부분이 완성도가 떨어져서 결국 아직 활용을 못하고 있습니다. ..

## **😫 시행착오 2 — 테스트 예약 5개뿐인데 데이터베이스 이사가 하루 종일 걸렸다**

**9월 28일 새벽 3시에 시작해 밤 12시에 끝났어요. 그날 제가 Codex에 보낸 메시지만 88개입니다.** 옮긴 고객 데이터는 0건이었는데도요.

### **왜 바꿨나**

그날 새벽, Claude가 우리 사이트를 점검하다가 문제를 하나 찾았어요. 관리자용 편집 버튼(색·글꼴·메뉴 추가)이 공개 페이지 안에 들어 있고, 화면에서만 가려져 있었거든요. 진열장 안에 관리자 열쇠를 두고 커튼으로 가려 둔 것과 같아요. 실제로 외부인이 저장할 수는 없었지만, 이 일로 "관리자 구조를 제대로 다시 짜자"는 마음이 커졌고, 그 김에 데이터베이스도 Supabase로 "최대한 빨리" 옮기기로 했어요.

## Firebase와 Supabase 비교

항목

Firebase

Supabase

데이터 저장

Firestore: 문서·컬렉션 방식

PostgreSQL: 표·행·열 방식

잘 맞는 경우

빠르게 시작하는 앱, 실시간 기능, Google 도구 연동

서로 연결된 자료, SQL 검색, 관계·조건이 많은 데이터

장점

Auth·데이터베이스·저장공간·Functions를 한 생태계에서 사용하기 편함

관계형 데이터와 SQL을 쓰기 쉽고, 데이터 연결과 트랜잭션을 명확히 설계할 수 있음

주의점

관계가 많은 자료는 중복 저장이나 규칙 관리가 복잡해질 수 있음

표 구조와 RLS 권한 규칙을 제대로 설계해야 함

이전 작업

현재 사이트에서 이미 사용 중

기존 Firebase 코드와 규칙을 Supabase 방식으로 바꾸고 시험해야 함

비용·운영

사용량과 기능에 따라 달라짐

요금제와 사용량에 따라 다르며, 무료 프로젝트의 운영·백업 조건도 확인해야 함

Aside에게 물어본 결과 저의 웹사이트 기준으로는, 예약·고객·일정·상태 이력처럼 서로 연결된 자료를 표와 SQL로 관리하고 싶다면 Supabase가 잘 맞다고 하더라구요. 그래서 급하게 바꾸게 되었습니다 ㄷㄷ반면 Firebase 로그인, Hosting, YouTube 서버 기능은 이미 쓰고 있으므로 그대로 두고 데이터베이스만 단계적으로 바꾸는 계획이 정리돼 있습니다.

Supabase로 이전의 장점은 데이터 구조를 관계형으로 명확히 관리할 수 있다는 것이고, 대가는 코드·권한 규칙을 다시 만들고 충분히 시험해야 한다는 점이라고 하네요… 지금 뭔가 대가를 치로 있는 느낌입니다…

Codex의 처음 예상은 **4~7 근무일**이었는데, 범위를 줄여서 하루에 끝냈어요. 로그인·사진·유튜브 연동·호스팅은 Firebase에 두고, **데이터만** 옮기기로 한 거예요. 테스트 예약·고객 자료는 아예 옮기지 않았어요.

### **데이터가 거의 없는데 왜 하루가 걸렸나**

Firebase에 있던 자료는 문서 34개뿐이었고, 그중 실제로 옮긴 건 병원 기본정보 1, 치료 분류 9, 의사 2, 디자인 설정 1개가 전부예요. **시간이 걸린 건 짐이 아니라 새 집의 자물쇠·배선·경보기를 다시 다는 일**이었어요.

**시간이 든 일**

**쉽게 말하면**

표 13개와 보안 규칙 31개를 새로 작성

"고객은 자기 예약만, 관리자는 전부" 같은 자물쇠를 하나씩 다시 단 것

예약 저장을 한 번에 처리하는 기능

고객정보·동의·예약·중복 방지(30초)·일요일/휴일 체크를 동시에 저장하고, 하나라도 실패하면 전부 취소

Firebase 로그인을 Supabase가 믿게 연결

다른 건물 출입증을 우리 건물에서도 쓸 수 있게 등록. 이를 위해 Firebase에 작은 서버 기능을 하나 더 배포

관리자 계정 연결, 실시간 알림 6개 표

원장 계정만 관리자로 등록, 예약이 들어오면 화면이 바로 바뀌게

사이트가 데이터를 부르는 코드 전부 교체

메뉴·예약·관리자·기사·영상 기능의 연결선을 모두 새 주소로

테스트 111개 → 131개, 되돌리기(롤백) 계획

이사 후 고장 나면 어떻게 되돌아갈지까지 준비

여기에 **제가 직접 해야 하는 단계에서 자꾸 멈춘 것**도 컸어요.

- Supabase 가입과 프로젝트 생성 (여기부터 "조직이 뭐예요?" 수준이었어요)
- 터미널에서 직접 로그인 — AI는 비밀번호를 대신 입력할 수 없어서 멈췄어요
- Supabase 화면에서 Firebase 연결 설정, Firebase에 [localhost](http://localhost) 허용 추가
- 설정 파일을 못 읽는 버그 때문에 시험 화면이 안 뜨던 문제
- 관리자 계정 연결 버튼 클릭, 마지막 배포 승인

단계마다 "이게 무슨 뜻이에요?"를 물어보고 답을 이해하는 시간까지 더하면, 하루는 오히려 빠른 편이었어요.

## **😫 시행착오 3 — 컴퓨터 2대, AI 2개가 각자 다른 파일을 들고 있었다**

**같은 웹사이트가 맥북, Windows PC, Claude 프로젝트 세 곳에 서로 다른 버전으로 있었어요.** 일주일동안 아무도 몰랐고요.

- **Claude에서 쓴 원고를 Codex 폴더로 손으로 옮겼어요.** 복사를 까먹은 문서도 있었고, 109개 문서를 하나씩 대조해 보니 빠졌거나 옛 버전인 파일이 12개였어요.
- **Windows PC에는 GitHub에서 ZIP으로 받은 사본을 썼어요.** ZIP에는 변경 기록(.git)이 없어서, 거기서 한 디자인 작업을 나중에 합치려니 맥북과 양쪽에서 바뀐 파일이 65개, 그중 자동으로 안 합쳐지는 파일이 62개였어요.
- **맥북 작업을 GitHub에 올리지 않고 있었어요.** 288개 파일이 맥북에만 있었고, 올리려고 하자 Codex의 안전장치가 "저장소가 공개인지 비공개인지 모른다"며 막았어요. Private로 확인하고 승인한 뒤에야 올라갔어요.
- **폴더 이름도 달랐어요.** 맥북은 영어 웹사이트 260919, Windows는 skin-clinic-main. 알고 보니 이름은 상관없고, 같은 GitHub 주소에 연결돼 있는지가 중요했어요.

지금은 이 규칙 하나로 정리했어요.

**끝내면 넣고(push), 시작하면 꺼낸다(pull). 한 폴더에서는 한 번에 AI 하나만.**

- GitHub = 인터넷 위의 공용 사물함. 다른 컴퓨터에서는 ZIP이 아니라 복제(clone)로 받는다.
- Claude 프로젝트 = 인터넷 위의 공책. 같은 계정이면 어느 컴퓨터에서나 보인다.
- Claude에게 "저장할 때마다 코드 폴더에도 같이 저장해줘"라고 규칙을 정해 두었다.

## **✅ 지금 상태 (After)**

**항목**

**시작 전**

**지금**

웹사이트

없음

공개 페이지 50개 운영 중 (검색 비공개)

블로그

없음

원고 24편(영문+한글 검토본), 그중 16편 업로드

예약

DM·전화

웹 예약 신청 → 관리자 화면 (테스트 1건 성공)

자동 테스트

없음

149개 (코드를 고칠 때마다 자동 점검)

검색에 공개된 페이지

0

**여전히 0**

## **🤔 남은 고민 1 — Firebase와 Supabase, 계속 써야할까?**

지금은 이렇게 나눠져 있어요.

**역할**

**어디에**

웹페이지를 보여주는 곳(호스팅)

Firebase

로그인 (Google 로그인, 예약자 익명 확인)

Firebase

사진 파일, 유튜브 연동

Firebase

예약·고객·메뉴·관리자 데이터

Supabase

**제 결론: 당분간 이대로 두고, 회원가입을 만드는 시점에 로그인까지 Supabase로 한 번에 옮기기로 했어요.**

- **호스팅은 어차피 Supabase로 못 옮겨요.** Supabase는 데이터베이스 서비스라 웹페이지를 보여주는 기능이 없어요. 완전한 "한쪽 일원화"는 처음부터 불가능했어요.
- **로그인을 또 옮기면 또 하루가 들어요.** 지금 원장 1명만 로그인하는 상황에서는 얻는 게 없어요.
- **양쪽 데이터베이스 사용의 비용:** 관리 화면 2개, 청구서 2개, 그리고 두 서비스를 잇는 연결고리가 고장 나면 관리자 로그인이 막힘 수 있어요.
- **꼭 바꿔야 할 것:** Supabase 무료 플랜은[1주일 동안 쓰지 않으면 멈추고 백업이 없어요](https://supabase.com/pricing). 실제 고객 예약을 받기 전에는 Pro 플랜(월 $25부터, 매일 백업 7일 보관)으로 올려야 해요.

## **🔐 남은 고민 2 — 나중에 회원가입을 넣으면 보안은?**

**저의 웹사이트의 회원정보는 건강·시술 정보와 연결되기 쉬워서, 일반 쇼핑몰보다 한 단계 더 조심해야 해요.** 만들기 전에 챗쥐피티가 알려준대로, 이 순서로 점검하려고 해요.

1. **정말 회원가입이 필요한지부터 정한다.** 지금 예약은 회원가입 없이도 됩니다. "내 예약 보기"만 필요하면 이메일 링크로 충분할 수 있어요. 안 모으는 정보는 새지 않아요.
2. **비밀번호를 직접 만들지 않는다.** Supabase Auth의 Google·Apple 로그인이나 이메일 링크 로그인을 쓴다. 로그인을 만드는 이 시점에 Firebase 로그인을 Supabase로 옮긴다.
3. **표마다 "본인 행만" 자물쇠(RLS)를 건다.** 지금도 13개 표 모두 켜져 있고, 로그인 없이 예약·고객 표를 열면 거절(401)되는 것까지 확인했어요. 회원 표도 같은 원칙으로.
4. **회원과 관리자를 완전히 나눈다.** 관리자 권한은 별도 관리자 표에 등록된 계정만. 관리자 계정에는 2단계 인증을 켠다.
5. **가입 화면에 로봇 방지를 단다.** Supabase Auth는[hCaptcha와 Cloudflare Turnstile](https://supabase.com/docs/guides/auth/auth-captcha)을 지원해요.
6. **비밀 키는 브라우저에 절대 넣지 않는다.** 지금 우리 사이트도 공개용 키만 쓰고, 서버 비밀 키가 들어간 흔적이 없는지 배포 때마다 검사해요.
7. **개인정보 처리방침·동의서를 함께 고친다.** 무엇을 얼마나 보관하고 언제 지우는지 정하고, 공개 전에 전문가 검토를 받는다.
8. **Pro 플랜으로 올려 매일 백업을 켠다.**

## **💬 이 과정에서 배운 AI 활용 팁**

1. **시작 전에 "완성"의 뜻을 정하세요.** 저한테 완성은 "검색에 나오는 페이지"였는데, 이걸 정하지 않아서 3주 내내 만들기만 했어요.
2. **한 번에 하나만.** 디자인을 하다가 블로그를 쓰면, AI는 기꺼이 따라오지만 제 머릿속이 못 따라가요.
3. **"숙제 목록" 문서를 하나 두세요.** 원장인 제가 주어야 할 자료(사진, 진료시간, 가격)가 33개였어요. AI가 기다리는 건 코드가 아니라 나예요.
4. **큰 결정은 이유를 한 줄 적어 두세요.** Firebase→Supabase처럼 이유를 잊으면 "양다리를 계속할까?" 같은 다음 결정도 어려워져요.
5. **AI에게 "예상 시간"을 꼭 물어보세요.** Codex는 Supabase 이전을 4~7일로 예상했고, 그 답을 듣고 범위를 "데이터만"으로 줄여서 하루에 끝냈어요.
6. **"나는 코딩 모르는 초등학생이야, 비유로 설명해줘"는 최고의 프롬프트예요.** CSS는 "진열장 커튼", Supabase는 "서류함", GitHub은 "공용 사물함"으로 이해했어요.
7. **AI의 안전장치를 귀찮아하지 마세요.** 배포·DB 변경·업로드 전에 매번 승인을 묻는 게 답답했지만, 덕분에 실제 사이트를 한 번도 망가뜨리지 않았어요.
8. **AI가 여럿이면 "인계서"로 대화하게 하세요.** Codex와 Claude가 같은 폴더에 작업 기록(핸드오프 문서)을 남기게 했더니, 다음 날 어느 쪽이든 이어서 일할 수 있었어요.

## **🚀 앞으로의 계획**

1. Windows에서 한 디자인 중 쓸 것만 골라 맥북 버전에 합치기
2. 특정 주제 페이지 1개를 검토하고 검색에 공개하기 (첫 번째 "진짜 완성")
3. Google Search Console, Bing Webmaster Tools 등록
4. 실제 예약을 받기 전 Supabase Pro 플랜으로 전환
5. 회원가입은 위 보안 체크리스트를 통과한 뒤에
6. 반복되는 블로그 작성을 Claude 스킬로 자동화

## **📋 재사용 가능한 프롬프트**

**작업 시작할 때 (Codex·Claude Code 공통)**

작업 시작 전에 git status를 확인하고, 깨끗하면 GitHub에서 최신 버전을 받아줘(git pull).

변경이 있으면 받지 말고 먼저 나한테 알려줘.

**작업 끝낼 때**

오늘 바뀐 파일을 확인하고, 비밀 정보가 없는지 본 다음 커밋해서 GitHub에 push해줘.

배포는 하지 마. push 성공했는지 알려줘.

**큰 결정을 내리기 전에**

나는 코딩을 모르는 초등학생이야. [하려는 일]을 하려고 하는데,

장점·단점, 예상 시간, 내가 직접 해야 할 일, 되돌리는 방법을 비유로 설명해줘.

그리고 이 결정의 이유를 한 줄로 작업 기록에 남겨줘.

**하루를 마무리할 때**

오늘 한 일, 남은 일, 내가 결정해야 할 것을 인계 문서로 남겨줘.

다음에 다른 AI나 다른 컴퓨터에서도 이어서 할 수 있게.

바이브코딩은 AI가 코드를 대신 써 주지만, **순서를 정하고 끝을 내는 건 여전히 사람의 일**이었어요. 저처럼 시작하시는 분들은 저보다 빨리 첫 페이지를 검색에 올리시길 바라요.

**앞으로 추가 계획**

1차 목표: 웹사이트 제작이 어느정도 마무리가 되면, 기존의 인스타그램 & 틱톡 & 카카오톡의 메세지로 고객과 소통하는것을 웹사이트의 내용을 학습한 챗봇이 대신 영어 메세지로 답변하게 만드는게 목표입니다. 여기서 챗봇은 절대로 본인이 모르는 대답은 하면 안됩니다. 무조건 웹사이트의 내용, 또는 제가 학습시킨 내용만을 답변해야하고, 모르는 답변은 ‘사람’이 해야하는게 중요할것 같습니다.

2차 목표: 같은 방식으로 음성 챗봇을 영어와 한국어로 할수 있다면 좋겠어요.

3차 목표: 고객님이 내원시 각 단계별로 체류 시간과 어떤 피부관리를 했는지 기록을 해서 당일에 레포트로 드리고 싶어요. 예를 들어 상담실에서 상담 ㅇㅇ시 ㅇㅇ분~ ㅇㅇ시 ㅇㅇ분, 특정 피부고민을 주제로 상담을 했꼬, 어떤 피부관리를 받기로 했다. 그 다음에 피부관리실에서 A B C 3가지 피부관리를 받았고 관리시간은 ㅇㅇ시 ㅇㅇ분까지이다. 상담실, 피부관리실 별로 QR 코드를 찍어서 시간을 기록하게 하고, 상담 내용 음성을 텍스트로 바꿔주는 기능을 쓰면 가능할것 같기도 한대요. 과거에는 Gemini 한테 음성을 분석하게 하면 10분 이내는 빨리 끝나는데, 50분 이상은 오래 걸리고 무료 버전으로 안되더라구요. 현재는 음성을 텍스트로 바꾸는 방법이 더 다양한것 같아서, 상담시 실시간으로 텍스트로 대화를 기록하고, 상담이 끝나면 바로 요약해주는 레포트를 고객님께 만들고 싶어요.

4차 목표: 스터디장님처럼 직원분들의 출퇴근 시간 관리, 급여 관리, to do list 인계장을 만들고 싶구요. 또한 특정 시간대에 관리실 3개에 3분의 고객님이 동시에 있을경우, 각각 고객님의 진행 상황을 관리실 밖에서도 알수 있게 하고 싶어요. 그래서 3차 목표에 QR코드로 직원들이 관리 시작과 끝날때 찍게 하면 어떨까라는 생각을 하게 되었어요. 프라이버시가 중요한 공간이라 밖에서는 안에서 무슨 상황인지 파악을 못하는게 조금 답답한 요소이기 때문입니다.