바이브코딩 실전 도전기 3 - 매칭 서비스 데이터베이스 이전

🧱 AI 코딩으로 만든 서비스를, 내 손으로 완전한 데이터베이스로 이전하기

“No-code로 시작했지만, 결국 구조를 이해해야 진짜 내 서비스가 된다.”

프로젝트 소개

Bridgeon (브릿지온)이란? (https://www.bridgeon.kr/)

시니어 전문가와 주니어 창업자를 연결하는 매칭 플랫폼입니다.

핵심 가치

• 경험 많은 시니어의 노하우를 창업 초기 단계의 주니어에게 전달
• 프로젝트 기반 매칭으로 실질적인 협업 지원
• AI 기반 프로필 요약 및 텍스트 정제 기능

주요 사용자

1. 시니어: 경영, 전략, 기술, 마케팅 등 분야의 전문가
2. 주니어: 창업 초기 단계의 기업가 및 프로젝트 리더
3. 관리자: 매칭 관리 및 플랫폼 운영

**

1️⃣ 배경 — 빠르게 만든 MVP, 놓쳐버린 데이터의 주권**

Bridgeon.kr은
시니어 전문가와 주니어 창업가를 연결하는 협력 매칭 플랫폼입니다.
처음 이 서비스를 만들 때 제 목표는 단 하나였습니다.

“아이디어를 빠르게 검증하자.”

그래서 Lovable이라는 AI 기반 no-code 빌더로 단 10시간 만에 MVP를 완성했습니다

• 로그인 / 회원가입
• 프로필 등록
• 프로젝트 게시
• 관리자 매칭 페이지

이 모든 게 하루도 안 돼 돌아갔죠.
정말 마법 같았습니다.

2️⃣ 문제 — “내 데이터가 내 손에 없다는 것”

서비스가 돌아가고 나서 확인해보니,
Lovable은 초기에 Supabase 인스턴스를 독립적으로 제공했지만 이후 통합형 클라우드 구조로 변경되어,
모든 데이터 접근이 플랫폼 내부에서만 가능해졌습니다.

즉, 백엔드 구조를 내 마음대로 바꾸거나 직접 SQL을 실행할 수 없게 된 겁니다.
그때 처음 느꼈습니다.

“데이터가 내 손에 없다는 건,

서비스의 심장이 내 것이 아니라는 뜻이구나.”

3️⃣ 결심 — 내 손으로 데이터베이스를 다시 만들어보자

Bridgeon의 데이터 구조는 단순하지 않았습니다.

• 사용자 프로필 (profiles)
• 프로젝트 (projects)
• 시니어-주니어 매칭 (matchings)
• 후기 (feedbacks)

이 모든 데이터가 관계형 구조로 얽혀 있었습니다.
그래서 결심했습니다.

“Supabase로 완전히 독립 이관하자.

내 손으로 DB를 만들고, 구조를 이해하자.”

4️⃣ 과정 — 듣도 보도 못한 용어들과의 첫 만남

Migration을 시작하자마자
SQL 문법이 아닌 “언어” 자체가 낯설었습니다.

FOREIGN KEY, RLS, ENUM, UUID, TRIGGER, FUNCTION …

Lovable에서는 클릭 한 번으로 끝나던 일들이
Supabase에서는 직접 코드를 써야 했습니다.

모든 작업은 Cursor AI의 지시와 함께 진행했습니다.
AI가 코드를 생성하면, 저는 그걸 읽고 수정하며 진짜 개발자의 작업 과정을 따라 배워갔습니다.

전체 구조

auth.users (Supabase 기본)
    │
    ├─ 1:1 ─> profiles
    │           │
    │           └─ 1:N ─> projects (junior_id)
    │
    ├─ 1:N ─> user_roles
    │
    ├─ 1:N ─> matchings (senior_id)
    │           │
    │           └─ 1:N ─> feedbacks
    │
    └─ 1:N ─> matching_requests (senior_id, junior_id)

projects
    ├─ 1:N ─> matchings
    └─ 1:N ─> matching_requests

5️⃣ AI Edge Function 옮기기

기존에는 Lovable 내부에서 OpenAI API를 직접 호출했지만,
이제는 Supabase의 Edge Functions(Deno 환경) 으로 옮겼습니다.

덕분에 AI 요약 기능이
보안상 안전하게 서버 사이드에서만 실행되도록 개선됐습니다.

6️⃣ 시행착오 — 수십 번의 에러 로그

계속적인 에러 중 한가지 에러가 가장 많이 발생했습니다

원인은 간단했습니다.
profiles를 옮기기 전에 auth.users를 먼저 생성해야 했던 것.
또 CSV에서 배열 데이터를 가져올 때 Lovable 형식 ["A","B"]를 PostgreSQL이 인식하는 {A,B}로 바꿔야 했습니다.

지금 이 문장을 쓰고 있지만 원인을 발견 과 대책은 모두 cursor가 발견하고 대응한 내용입니다. ㅎ

이 모든 과정을 하나하나 수정하며,
점점 “데이터베이스 언어”를 이해하기 시작했습니다.

**7️⃣ 완성 — 진짜 ‘내 것’이 된 시스템

이제 Bridgeon은 완전히 Supabase 기반의 독립형 인프라 위에서 돌아갑니다.

• 데이터 구조 완전 복원
• RLS로 역할별 접근 제어
• AI Edge Function 정상 작동
• Vercel 배포 + 커스텀 도메인 연결

가장 큰 변화는 기술보다 마음가짐이었습니다.

“서비스를 만든다는 건 코드를 짜는 게 아니라,

구조를 이해하고 책임지는 일이라는 것.”

8️⃣ Key Takeaways

🔹 AI 코딩으로 만든 MVP는 빠르지만, 데이터는 여전히 ‘내 것’이 아닐 수 있다.
🔹 DB 이전(Migration)은 기술보다 개념을 이해하는 과정이다.
🔹 Supabase는 작은 팀에게 데이터 통제권을 되돌려준다.

마무리 한 줄

No-code로 시작했지만, 결국 코드를 이해해야

내 서비스를 ‘진짜 내 것’으로 만들 수 있다.

단계구분주요 목적핵심 작업

🔹 전체 진행 순서 개요

사전준비	데이터 백업	기존 Lovable DB의 전체 데이터를 보존	테이블(profiles, user_roles, projects 등) 및 auth.users를 CSV/JSON으로 내보내기
Phase 1	인프라 구축	Supabase 신규 프로젝트 생성 및 연결	프로젝트 생성 → API 키 확인 → .env 설정 → CLI 연동
Phase 2	스키마 구축	새 DB 구조를 직접 정의	manual_bootstrap.sql 실행 → Enum·테이블·함수·RLS 정책 생성
Phase 3	함수 배포	AI 기능을 Supabase Edge Functions로 이전	ai-summarize, ai-refine 함수 코드 수정 및 Secrets 등록 → CLI 배포 및 테스트
Phase 4	데이터 마이그레이션	기존 사용자 및 서비스 데이터를 복원	auth.users → profiles → user_roles → projects 순서로 CSV 임포트 및 검증
Phase 5	테스트 및 검증	마이그레이션 결과 검수	로그인 테스트 → RLS 검증 → 함수 호출 → FK 무결성 및 성능 테스트
완료 후	운영 점검	독립 인프라 안정화	로컬 및 Vercel 환경 점검, 데이터 백업 및 모니터링 설정

 

🔹 주요 작업 상세 요약

🧩  1. 데이터 백업 (Lovable → 로컬)

• Supabase Table Editor에서 각 테이블(profiles, user_roles, projects 등) CSV 내보내기
• Delimiter ; / Header 포함 / UTF-8 형식 유지
• auth.users는 SQL로 직접 쿼리 후 JSON 또는 CSV 저장

⚙️ 2. 인프라 구축

• Supabase 신규 프로젝트 생성 (Region: ap-northeast-2)
• API 키(anon/service_role) 발급 후 로컬 .env 설정
• CLI 연결 및 인증 토큰 등록

🧱 3. 스키마 구축

• pgcrypto 확장 활성화
• Enum(app_role) 및 테이블 6종 직접 생성
  • profiles, user_roles, projects, matchings, matching_requests, feedbacks
• 트리거(handle_new_user), 함수(has_role) 생성
• RLS 정책으로 사용자 접근 제어 정의

🤖 4. 엣지 함수 배포 (AI 기능)

• 기존 Lovable OpenAI 호출 → Supabase Edge Functions(Deno)로 이전
• 환경변수 VITE_GEMINI_API_KEY를 Secrets로 등록

💾 5. 데이터 마이그레이션

1. auth.users 생성 – UUID/이메일 기준으로 INSERT
2. profiles CSV 임포트 – 기존 트리거로 생성된 기본 프로필 삭제 후 덮어쓰기
3. user_roles CSV 임포트 – 역할별 ENUM 매핑 (admin/junior/senior)
4. projects CSV 임포트 – FK(junior_id) 확인 및 삽입
5. 비밀번호 일괄 초기화 – crypt('123456', gen_salt('bf'))로 임시 설정

🧪 6. 테스트 및 검증

• 로컬 실행: npm run dev → http://localhost:8080 접속
• 로그인 / 프로필 / 프로젝트 / 시니어 목록 확인
• RLS 검증 → 본인만 수정 가능 확인
• FK 무결성 테스트 → orphan 데이터 0건 확인
• AI 요약/정제 함수 정상 호출 확인
• 성능 분석: EXPLAIN ANALYZE로 쿼리 최적화 확인