바이브 코딩! 시니어 비개발자 도전기

Vibepix 개발 과정 (www.vibepix.kr)

PublishDate: 2025년 9월 21일 오후 3:10

구글 나노바나나 라는 기술이 유튜브에서 많은 언급이 되면서 그동안 관심이 있던 이미지의 일관성 유지에 탁월한 성능이라는 소식을 듣고 나도 실험을 해보고 싶어졌다. 이렇게 단순히 기능 테스트 정도로 시작했던 것이 구글 AI 스튜디오의 빌더 기능으로 이미지 생성기를 쉽게 만들어 볼 수 있었고 욕심이 생겨 프론트 페이지를 만들고 이를 웹에 배포하고 도메인을 연결하는 것까지 해보게 됐다

개발은 구글 AI 스튜디오 빌더 이용

프론트와 백엔드 개발은 Lovable

데이터베이스는 Supabase (Lovable에 연동되어 있음) - 배포도 할 수 있지만 계속 유료 서비스 이용해야 하는 조건이 있어서 무료가 가능한 Vercel로 배포를 진행

배포는 Vercel

그리고 일부 코드 수정 등은 CURSOR에 github 프로제트를 연동해서 Lovable과 동시에 작업을 했다.

1. 구글 ai스튜디오 빌더를 이용

나노바나나 기능을 활용한 이미지 생성기 를 심플하게 제작함

기능에 점점 욕심나고 제대로 구현하고 싶어 지면서 프런트 개발도 하고 싶어졌다

그런데 프런트를 구글 제미나이에서 만들기는 왠지 만족스럽지 못할 듯하여

기존에 내가 사용하던 lovable 서비스를 이용하기로 하고 서비스를 열었다

2. 개발 소스코드를 이전하기 (구글 > Lovable )

구글 제미나이에서 개발한 소스코드를 어떻게 Lovable로 옮겨와야 할지 처음에는 간단하게 생각했다 파일업로드가 있을 것이고 그럼 소스코드를 파일업로드 하면 되지 않을까 라는 단순한 생각이었다. 그런데 소스코드를 직접 업로드할 수는 없었다.

그래서 이런저런 고민과 시도를 해보다 불현듯 구글 제미나이 빌더에 github 아이콘을 발견했다. 그렇다면 github를 매개로 파일을 이용할 수 있지 않을까라고 생각하고 우선 구글제미나이에 연결된 깃허브 계정에 들어가 봤다. 파일이 있었다. 이젠 이걸 Lovable로 옮겨야 하는데…. 화면을 보니 Lovable에 깃허브 아이콘이 보였다. 연동이 된다는 의미였다. 바로 깃허브 해당 프로젝트에 연결을 했다. 그렇게 드디어 파일을 연결할 수 있었다.

3. Lovable를 이용한 개발 (프런트와 백앤드)

Lovable로 연결한 후에는 또다시 여러 가지 이슈가 발생했다.

처음에는 구글 제미나이로 개발한 소스들은 아무래도 여러 가지 구글 제미나이 만의 형식을 가진 코드인지 Lovable에게 코드 리뷰를 해보라구 했더니 여러가지 출동이나 부족한 부분을 지적했고 이를 수정했다.

3-1. 이미지 생성 기능

파일 연결은 성공했고 프리뷰 화면이 보이는 것을 확인한 후 큰 고비를 넘긴 기분이었다.

그런데 가장 중요한 기능인 이미지 생성이 되지 않았다. 기본적으로는 소스 코드 내에 해당 프로그램에 필요한 key를 입력해 놓는 파일(. env.local) 이 있나 본데 Lovable이 계속 구글 API키가 없어서 이미지 생성을 못한다고 에러 메시지를 연달아 내뱉고 있었다. Lovable에게 물었다. “네가 키를 너한테 알려줄 테니 네가 필요한 폴더를 만들어 거기에 입력하라고 “ 그런데 직접 알려주지 말고 자신들의 별도로 이런 중요정보를 받은 과정이 있으니 입력하라고 해서 그렇게 입력을 했다. 그런데 제기랄 안된다.

그러다니 기능을 일단 확인하자고 제안을 하는 Lovable AI 그래서 생성 시마다 api 키를 입력하는 방식을 제안하길로 웃기지 말라고 거절했다. 그러더니 다음과 같이 제안을 해왔다.

3-2. Supabase에 구글 API 입력 (백엔드 연결)

직접 로컬 파일에 중요한 KEY정보를 입력하는 것이 분명 문제가 있을 것 같아 Lovable이 제시하는 Lovable이 기본적으로 연동을 지원하는 Supabase 사이트에 해당 프로젝트 설정 페이즈를 둘러봤다. 그런데 쉽게 찾을 수는 없었다.
그런데 “edge functions”라는 메뉴가 왠지 키 값을 입력하는 곳 갔아 일단 입력해 봤다.
성공이다. ㅎㅎㅎ 아래 이미지처럼 제미나이 API키를 원래 파일에 있는 이름으로 동일하게 적고 키값을 저장했다.

 

그런데 재미있는 건 이렇게 기능적인 부분을 먼저 정상화하고 나니 Lovable이 이제 백엔드 설정을 하라고 하면서 SUPABASE와 연결을 진행하라고 안내했다. ㅎㅎ 난 벌써 했는데

여기까지로 드디어 프런트와 백엔드까지 구글 나노바나나 이미지 생성 API를 이용하기 위한 웹앱을 구글에서 Lovable로 이전을 성공했다.

3-3. 기능 고도화

이제 정말 제대로 된 서비스처럼 사이트를 만들고 싶어졌다. 그래서 다음과 같이 요청했다

💡

자 이제 기능을 완성했으니 회원가입 기능(이메일 가입- 이름, 이메일, 연락처 필수입력)과 마이페이지 기능을 만들고 관리자 페이지 경로를 만들어 회원관리기능(회원정보 검색 수정 삭제 기능, 통계기능 - 전체, 기간별, 회원별 생성이미지개수, api 호출수 등 통계 기능 등을 구축하려고 하는데 바로 개발을 하지 말고 우선 이런 기능을 개발하기 위해 현제 코드에서 어떻게 계획을 수립하고 어느 순서로 할지 차근차근 계획부터 세워보세요

이렇게 요청을 하고 나니 내 요청을 기준으로 더 필요한 기능이나 확인해야 할 사항 등을 구체적으로 알려준다. 그래서 그 내용을 자세히 살펴보고 추가할 것과 삭제할 것을 정리해서 다시 요청을 했다.

💡

추가로 향후 구글로그인 기능도 추가할 예정이니 이점을 감안하고 회원도 유료회원과 무료회원으로 구분하여 이미지 생성개수 제한, 생성이미지 다운로드 제한 등의 기능의 제한을 둘 예정이니 이점들을 고려해서 구축 계획을 다시 수립하세요

그래서 다음과 같이 개발 계획을 제시받았다.

• 개발 계획 상세
• 좋아요! “이메일 회원가입 + 구글 로그인(향후) + 무료/유료 회원 구분 + 이미지 생성/다운로드 제한 + 마이페이지 + 관리자 페이지(회원관리/통계)”까지 고려한 실행 계획을 아래와 같이 정리했습니다. 지금은 설계/계획 단계이며, 구현은 다음 단계에서 진행하겠습니다.

  요약(핵심 결정)

  • 인증: Supabase 이메일/비밀번호 + (향후) Google OAuth
  • 프로필/권한: profiles(이름/이메일/연락처/멤버십), user_roles(관리자), has_role 함수로 RLS 안전하게
  • 멤버십/제한: 멤버십 등급 enum(예: free, pro), 월별 이미지 생성/다운로드 제한. 기준은 generation_logs로 집계
  • 스토리지: ‘generated’ 비공개 버킷에 결과 이미지 저장, 클라이언트는 서명 URL(Edge Function)로만 접근
  • 로깅: Edge Function에서 “생성/다운로드” 이벤트 기록, 기간별/회원별/전체 통계는 이 로그 기반
  • 결제: 원오프(크레디트·기간형) vs 구독 중 선택 필요. 계획은 두 옵션을 모두 수용하도록 설계
  • 현재 코드 상태 간단 점검
  • Supabase 연결 완료 (client.ts OK)
  • 이미지 생성은 Edge Function generate-image를 통해 수행
  • 데이터베이스 테이블/스토리지/로그 구조는 아직 없음
  • 프런트엔드 라우팅은 단일 페이지 기반(React Router 설치는 되어 있음)
  • 구축 아키텍처(상세)

  1. 인증 및 프로필

  • 이메일 가입: 이름/연락처 필수 입력 → 회원가입 폼에서 수집 후 profiles에 저장
  • Google 로그인(향후): supabase.auth.signInWithOAuth({ provider: 'google' }) 버튼 추가
    • 주의: Supabase 대시보드에서 Google Provider 설정 필요(사이트/리디렉션 URL 포함)
  • 세션 관리: supabase.auth.onAuthStateChange로 user/session 상태 유지 (가이드 준수)
  • Redirect 설정: signUp 시 emailRedirectTo 반드시 설정

  1. 데이터베이스 스키마

  • enums
    • app_role: 'admin' | 'moderator' | 'user' (권한용)
    • membership_tier: 'free' | 'pro' | 'enterprise' (확장성 고려)
  • tables
    • profiles
      • id uuid PK (auth.users.id 참조 on delete cascade)
      • name text not null
      • email text not null (중복 방지 unique 권장)
      • phone text not null
      • membership membership_tier not null default 'free'
      • created_at, updated_at
      • RLS: 본인만 select/update 가능, admin은 전체 접근(has_role 사용)
    • user_roles
      • id uuid pk
      • user_id uuid references auth.users(id)
      • role app_role not null
      • unique(user_id, role)
      • RLS + has_role() 함수로 admin 권한 판별
    • generated_images
      • id uuid pk
      • user_id uuid
      • storage_path text (예: userId/yyyymmdd/uuid.webp)
      • width, height, aspect_ratio, variation_option, prompt_snippet(50자)
      • created_at
      • RLS: 본인만 접근, admin은 전체
    • generation_logs
      • id uuid pk
      • user_id uuid
      • action text check in ('generate', 'download', 'api_call')
      • images_count int (generate 시 생성된 이미지 수)
      • tokens_used int/null, request_id text/null
      • created_at
      • RLS: 본인만 select, admin 전체
    • memberships (선택)
      • 결제/구독을 명확히 추적하려면 별도 테이블로 기간형 멤버십 보관
      • id, user_id, tier, status(active/canceled), start_at, end_at
      • RLS: 본인 select, admin 전체
  • functions
    • has_role(user_id, role) SECURITY DEFINER (가이드 제공된 패턴 사용)
  • storage
    • 버킷: generated (public=false)
    • 이미지는 Edge Function이 업로드
    • 다운로드는 항상 “서명 URL”을 별도 Edge Function 통해 생성(다운로드 제한/로그 기록)

  1. 제한/쿼터 전략

  • 기준: “월별” 또는 “최근 N일” 단위 제한. 기본은 달(月) 단위 권장
  • 제한 항목:
    • 이미지 생성 수(월간): free/pro 각각 다른 한도
    • 이미지 다운로드 수(월간): free/pro 각각 다른 한도
    • API 호출 수(선택): generate 호출 자체도 로깅해 보호
  • 계산 방식:
    • Edge Function이 호출 시 generation_logs에서 user_id + 기간 필터로 합계 계산 → 허용/차단
    • 다운로더도 Edge Function(get-download-url)로 통제하여 로그 기록 및 한도 체크
  • 기본값(예시, 추후 확정 필요):
    • Free: 월 생성 50장, 월 다운로드 50장
    • Pro: 월 생성 1,000장, 월 다운로드 1,000장 (또는 무제한)
  • 초과 시: 429 또는 400 에러로 사용자 친화적 메시지 반환

  1. Edge Functions 설계

  • generate-image (기존 확장)
    1. 인증 확인 → user_id 획득
    2. 현재 멤버십 tiers 및 로그 기반 사용량 집계 → 생성 제한 체크
    3. Gemini 호출 → 결과 이미지 생성
    4. Supabase Storage 'generated'에 업로드(서비스 롤 키 사용)
    5. generated_images insert + generation_logs insert(action='generate', images_count=n)
    6. 응답: 썸네일용 미리 보기 URL 또는 key 목록 반환(클라이언트는 다운로드 Edge Function 통해 받음)
  • get-download-url (신규)
    • 입력: image_id 또는 storage_path
      1. 인증 확인 → 소유자 확인(admin 예외 허용
      2. 다운로드 제한 체크(월간)
      3. signed URL 발급(유효기간 짧게: 예 10분)
      4. generation_logs insert(action='download', images_count=1)
      5. URL 반환
  • create-payment (선택)
    • 원오프 결제(크레디트·기간형) 또는 구독 결제 중 택일 → Stripe Checkout 세션 생성
    • 결제 성공 후 memberships/프로필 tier 업데이트 방안(웹훅 없이 검증용 verify-payment 함수 추가 가능)
  • 주의: 모든 함수에 CORS/로그/에러 메시지 표준화

  1. RLS/보안

  • 모든 테이블 RLS 활성화
  • profiles: 본인 select/update, admin 전권
  • generated_images, generation_logs: 본인 데이터만 접근, admin 전권
  • user_roles: admin만 접근(또는 본인이 가진 역할만 조회), has_role로 판별
  • 스토리지 버킷은 비공개, 직접 접근 금지. 다운로드는 get-download-url을 통해서만
  • Edge Function은 서비스 롤 키로 DB/스토리지 작업 → RLS 우회 가능, 대신 소유자/경로 검증은 함수에서 수행

  1. 프런트엔드(라우팅/화면)

  • /auth: 로그인/회원가입(이름/이메일/연락처/비밀번호), Google 로그인 버튼
    • 가입 완료 후 profiles insert/update
    • 리디렉션 URL 올바르게 설정
  • /my (마이페이지)
    • 내 프로필 보기/수정(이름/연락처)
    • 내 멤버십/이용한도/남은 량 표시(월간 카운터)
    • 생성 이력 리스트(썸네일), 다운로드 버튼(→ get-download-url 호출)
    • 업그레이드(결제) CTA
  • /admin (관리자)
    • 회원 관리: 검색(이름/이메일/연락처), 보기/수정/삭제, 멤버십 변경, 강제 리셋 등
    • 통계: 전체/기간별/회원별
      • 총 생성 이미지 수, 총 다운로드 수, API 호출 수
      • 일/주/월 차트
    • 이미지/로그 상세 조회(필요시)
  • 상단 네비: 로그인 상태, 마이페이지, 관리자(권한 있을 때만), 로그아웃

  1. 결제(선택: 사용자 결정 필요)

  • 옵션 A: 원오프(크레디트/기간형)
    • 예: Pro 30일권(즉시 시작, 기간 종료 시 free로 롤백)
    • 구현 간단, Stripe Checkout mode: 'payment'
  • 옵션 B: 정기 구독
    • Stripe Billing 사용, 결제/해지/갱신 자동화
    • 멤버십 상태 동기화 로직 필요(웹훅 or 검증 함수)
  • 두 경우 모두: 성공 후 memberships/프로필 membership 업데이트 + 제한치 상향

  1. 개발 순서(마일스톤)

  • M1. DB/스토리지 설계 및 마이그레이션
    • enums, profiles, user_roles(+has_role), generated_images, generation_logs, memberships(선택), storage 버킷
    • RLS/정책/시드(admin 부여)
  • M2. 인증 UI(/auth)
    • 이메일 회원가입(이름/연락처 필수), 로그인, 세션처리, Google 버튼(UI만)
  • M3. Edge Functions 고도화
    • generate-image에 제한 체크/저장/로깅 추가
    • get-download-url 신설(다운로드 제한/로깅/서명 URL)
  • M4. 마이페이지(/my)
    • 프로필 수정, 내 사용량/히스토리/다운로드
  • M5. 관리자(/admin)
    • 회원 CRUD/검색, 멤버십 변경, 통계(차트)
  • M6. 결제(선택)
    • create-payment(원오프) 또는 구독 플로우(요구사항에 따라)
  • M7. Google 로그인 연결
    • Supabase 대시보드 설정 마친 뒤 테스트/오류처리
  • M8. QA/모니터링
    • 에러 메시지/로깅/경곗값 테스트(한도 직전/초과)
    • Edge Function 로그/대시보드 점검

  1. 통계 산출 방법

  • generation_logs를 기반으로 SQL 집계
    • 전체/기간별/회원별 images_count 합계
    • action='api_call'로 호출수 집계 가능
    • 일자별 그룹핑으로 차트 데이터 생성
  • 필요시 뷰(view) 추가(성능 최적화는 추후 고려)

  1. 운영/보안 체크리스트

  • Supabase Authentication URL 설정(redirect/site URL)
  • Edge Functions 비공개 비밀키(이미 세팅됨) 유지
  • 스토리지 비공개 유지 + 서명 URL 만료시간 짧게
  • 이미지/로그 보존기간 정책 협의(개인정보 최소 수집/보관)
  • 대용량 이미지 처리/실패 재시도/타임아웃 처리

그 외 추가적인 질문을 하기에 답변을 한 후 바로 개발 시작을 하도록 지시했다.

그러데 여기서 한 가지 중요한 부분은 초기 개발 계획을 AI가 제시할 때 자세히 꼼꼼히 읽어보고 수정할 것과 추가할 것을 바로 이때 체크 해야 한 다는 것이다. 만약 이후에 중요한 데이터베이스 관련 수정이나 권한 관련 수정 등을 하게 될 경우 큰 곤란을 겪을지도 모른다. (내가 그랬다 ㅎㅎ)

프런트 페이지 생성이 필요하여 이때 추가로 내가 디자인하고 싶었던 다른 사이트의 주소를 제공하고 해당 사이트이 디자인 컨셉으로 프론트 페이지 디자인을 하도록 요청했다.

아래 이미지 첫 결과물이다. 원래 내가 원했던 디자인과는 너무 동떨어졌다.

몇 차례 실경이 끝에 내 의도대로 디자인을 만들어 줬다.

그다음에는 다른 영역의 콘텐츠를 어떤 ui로 할 것인지 대화를 하면서 다음과 같이 서비스 특징을 한눈에 보여주는 콘텐츠를 만들었다.

이렇게 다른 영역도 하나둘 만들어 프런트 페이지를 완성했다.

이메일 인증 기능 - supabase 연결로 별다른 조치 업이 자동으로 연결됨

그 외에도 회원의 종류 그리고 가입 시 무료 크레디트 제공 숫자에 관련된 오류 등등 오류를 수정해 나갔다.

공통 헤더와 풋터 적용, 헤더 프로핑 메뉴의 하위메뉴들 확정

3-4. 관리자 페이지

관리자 페이지는 기본적인 기능을 갖춘 일반적인 ui였는데 이걸 좌측에 사이드바 메뉴가 있는 형태로 바꾸고 싶었다.

그래서 요청을 했고 처음에는 문제가 없어 보였다. (이 문제가 아주 큰 난관의 시초였다.)

• 이미지 생성 페이지 디자인과 UI 수정 - 이런 수정이 더 어렵다 AI로 수정하는 것이
• 베타 서비스 기능 추가 - 정식 서비스 전이여서 결제 기능을 비활성화하고 베타 서비스에 필요한 기능을 추가했다.
• 수정, 삭제 등의 액션 시 경고창 필수적으로 보여주기
• 통계기능 고도화 - 회원 가입, 접속과 활동, 구독이나 결제 관련 통계 등
• 관리자 페이지 ui를 shadcn ui 컴포넌트로 수정
• 관리자 페이지에 기능을 추가 수정하는 과정에 레이아웃에 문제가 생겨 처음에는 헤더가 가려지는 상황이 두 번째는 헤더에 바디영역이 가려주는 상황이 세 번째로는 헤더와 사이트바 사이에 긴 공간이 생겨서 사이드바 메뉴가 한참 아래로 내려가 있는 상황이 벌어지는 등 추가 수정에 따른 데이터베이스에 문제도 있지만 프런트에도 많은 영향이 있는 것이 분명하다. 이 인터페이스 문제가 며칠을 끄는 큰 문제가 되기도 했다. 결구 이문제는 직접 해결하지 못하고 개발자에게 물어봐 css 코드에 한 가지 조치를 취하는 것으로 쉽게 마무리 됐지만 역시 비개발자가 아무리 AI가 잘한다고는 하나 분명 코드를 보는 눈 정도는 있어야 하지 않을까 생각했다.

3-5. 정책 수정

처음에 확실히 기획을 하지 않으면 데이터베이스를 수정해야 하는 문제가 있어서 수정도 복잡하고 에러의 확률이 높다. 그래서 특히 회원종류, 비밀번호조건, 결제와 관련된 정책(유료, 무료 정책 ) , 구독 플랜 정책, 관리자의 권한과 기능, 관리자 페이지 기능(회원 정보/ 크레디트 조회, 수정, 삭제 등 CRUD )등은 처음부터 철저히 고민하고 초기에 확정 짓는 것이 좋다.

4. 보안 이슈

사실 비 개발자로 사이트 개발 시 보안까지 신경 쓰기란 정말 어렵다. 그런데 Lovable이 사용하면서 다른 서비스와 비교해 특징 중 하나가 바로 보안 관련 알람과 경고 등이 친절히 제공된다는 것이다. 그리고 수시로 소스 수정할 때마다 보안 이슈가 있는 사항을 경고로 알려주기 때문에 신경을 쓰게 된다.

이런 맥락에서 사실 회원가입 시 비밀번호 체계는 별로 고민 안 했는데 비밀번호 체계가 너무 단순하여 해킹 염려가 된다는 경고 메시지를 확인하고 8자리 이상, 대, 소, 특수문자 포함 조건으로 수정하게 되었다.

5. 브랜드와 로고

사이트 이름과 로고를 역시 AI로 만들었다. 이미지는 chat GPT가 만들어 줌

"VibePix”  c

www.vibepix.kr

6. 배포와 도메인 연결

이제 사이트 배포를 해야 하는 상황이 됐다.  배포는 사실 Lovable 사이트를 이용하면 쉽게 도메인까지 연결하여 작업은 끝낼 수 있다. 그런데 한 가지 걸리는 부분이 이 배포 서비스를 사용하려면 Lovable에 유료 서비스를 계속 유지해야 하는 점이었다.  매달 25달러를 사용하기에는 부담스럽고 그럼 어떻게 해야 할까  무료 배포서비스 Vercel이 생각났다.  github에 연결하여 몇 번 사용해 본 경험이 있어서 바로 vercel로 가서 github 프로젝트를 연결했다. 그리고 내가 보유 중인 도메인과 연결 작업을 마치니 드디어 배포가 끝났다. 트래픽이 많이 지지 않는 이상 일단 무료로 사용을 할 수 있다 

7. 롤백 (이전 버전으로 돌아가기)

이 프로젝트를 하면서 제일 어려운 고비 중에 하나가 어떤 문제 인지 갑자기 관리자 페이지 아주 초기 수정전 페이지로 돌아가고 거기에 데이터도 연동이 안 되는 상황이 벌어졌다. 난감했다. 지금까지 며칠을 노력했는데 완전 초기 상태로 돌아가버리다니….. 그리고 나는 그 원인을 알 도리가 없었다.

그래서 방법을 고민하다가 Lovable 보다 아무래도 cursor로 클로드를 사용해 코드를 보면 뭔가 원인을 찾을 수 있지 않을까 싶었다. 그래서 무작정 커서를 켜서 github에 해당 프로젝트를 파일을 연결했다. 그리고 코드 리뷰를 요청했다. 한두 가지 이슈가 있었지만 가장 큰 문제인 어드민 페이지 접속 자체가 안 되는 문제가 가장 컸다.

커서를 통해 이 문제 해결을 위한 조언을 물었다. 답변은 커서가 도울 수는 없고 데이터베이스 에디터에서 직접 어떤 소스를 입력하는 절차를 몇 가지 하라는 것이었다.

난감했다. 데이터베이스는 자동으로 연결된 supabase에 자동세팅된 상태 그 외에는 어떻게 하는지 모르는데 …. 커서에게 아주 자세히 설명을 요청했다 그리고 한번 설명대로 진행해 봤다.

SQL Editor에 들어가 소스를 입력하고 run 시키고 이런 작업을 몇 단계 한 것 같다. 그리고 다시 커서로 돌아가 커서가 시킨 대로 진행했다고 하니 해결이 됐다는 메시지를 받았다. ^^ 뭐라고 할까 시원했다 정말 머리가 개운해지면서 ㅎㅎ

어떤 이유인지 데이터베이스에 관리자 역할을 부여하는 뭔가가 지워진 듯했다. 이 작업은 관리자 역할을 부여하는 어떤 설정 같았다. 그런데 그것으로 끝나는 게 아니었다. 관리자 페이지의 버전이 완전 초기 버젼이여서 이것을 어떻게 할지 난감했다. 그래서 예전에 개발자들과 일할때 롤백 이런걸 들었던 기억이 있어서 github에 가서 업데이트 내역을 확인했다. 그리고 정말 겁도 없이 몇십분 이전 버젼으로 돌아가는 버튼을 클릭했다. 흐ㅡ 그런데 여러 버젼으로 돌아가고 다시 취소하고 하는 과정을 몇차례 진행했지만 한참을 진행해도 제대로 정상적인 버젼이 되지 않았다

마지막이란 심정으로 아예 몇 시간 이전 버젼으로 롤백을 시켰다. 어 그런데 가장 큰 문제였던 관리자 페이지의 디자인과 데이터 연결은 정상화 됐다. 물론 몇시간 사이 수정했던 여러 가지 기능이나 화면등은 다시 예전 버전이 되어 있었기 때문에 다시 작업을 해야 했다. 하지만 중요한 걸 살렸기에 그 정도 막일은 감수해야 했다.

이렇게 개발에 개도 모르는 내가 별의별 과정을 거쳐 기능을 개발하고 프런트와 백엔드를 연결하고 이를 다시 웹에 배포하고 도메인을 연결하는데 까지 성공할 수 있었다.

이 과정에서 구글 제미나이, Lovable, github, Vercel 등 여러 가지 도구들을 이용하면서 정말 혼자 할 수 있는 방법은 마련되어 있다는 사실을 확인했다. 하지만 나처럼 막무가내로 계획 없이 진행하는 것은 추천하고 싶지 않다.

계획을 잘 세워 과정 중에 시행착오를 줄이는 것이 가장 현명한 방법이고 비용도 줄일 수 있는 방법이다. 내경우 구글 제미나이는 비용이 들지 않았고 Lovable은 한 달 치 25달 토큰 다 사용해서 추가로 50달러 인가 결제해서 다 소진을 했다. 그런데 그마저 완성하기 전에 소진을 다해서 다시 curcor에 클로드를 연결해서 클로드를 사용했고 추가로 cursor까지 유료 사용을 했기 때문에 비용을 계산하면 75불에서 최대 105달러까지 사용한 것 같다

배포는 무료로 진행했고 도메인은 구매를 했다.