바이브 코딩 데이터베이스 종류와 선택 기준: Supabase부터 Turso까지 | DB 완벽 가이드
목록으로최초 발행: 2025년 12월 30일 오후 09:23|최종 수정: 2025년 12월 31일 오전 01:18
바이브 코딩 데이터베이스 종류와 선택 기준: Supabase부터 Turso까지 | DB 완벽 가이드
"Supabase 월 25달러, 프로젝트 하나 추가할 때마다 10달러... 사이드 프로젝트 1 + 1 만 돌려도 월 5만원이 넘어간다."
바이브 코딩으로 첫 번째 앱을 완성하고 나면 반드시 마주치는 현실입니다. AI가 "Supabase 연결해서 로그인 기능 만들어줘"라고 하면 뚝딱 만들어주니까 처음에는 편하게 썼는데, 프로젝트가 늘어날수록 청구서도 함께 늘어납니다. 환율 1,500원 기준으로 계산하면 Supabase Pro 플랜 월 25달러는 약 37,500원, 추가 프로젝트당 10달러는 15,000원입니다. 아직 1원도 벌지 못한 MVP 단계에서 이 비용은 꽤 부담스럽습니다.
더 답답한 건 대안을 찾으려 해도 정보가 없다는 것입니다. "Turso가 좋다더라", "D1이 싸다더라", "Neon이 빠르다더라"... 이름은 들어봤는데, 각각 뭐가 다르고 내 상황에 뭐가 맞는지 판단하기가 어렵습니다. 게다가 바이브 코딩 도구마다 지원하는 데이터베이스가 다르고, 어떤 건 인증 기능이 없고, 어떤 건 오프라인에서도 된다고 하는데... 결국 "그냥 Supabase 쓰자"로 돌아오게 됩니다.
이 문서는 그 악순환을 끊기 위해 작성되었습니다. 데이터베이스가 뭔지 모르는 완전 초보자부터, Supabase 비용이 부담되어 Turso로 갈아타려는 분, 글로벌 서비스를 위해 엣지 데이터베이스를 고민하는 분까지 모두가 읽고 바로 결정할 수 있도록 정리했습니다. 프로그래밍 경험이 전혀 없어도 이해할 수 있게 모든 전문 용어를 풀어서 설명했고, 2025년 12월 기준 최신 가격과 기능 정보를 반영했습니다.
1. 데이터베이스가 도대체 뭔가요
1) 데이터베이스는 앱의 기억 장치입니다
앱을 사람에 비유하면, 화면(프론트엔드)은 얼굴이고, 데이터베이스는 뇌입니다. 얼굴이 아무리 예뻐도 기억을 못 하면 쓸모가 없습니다. 회원가입을 했는데 다음에 로그인이 안 되거나, 글을 썼는데 새로고침하면 사라지거나, 장바구니에 담았는데 결제할 때 비어있으면 그 앱은 아무도 쓰지 않습니다. 데이터베이스는 이런 모든 정보를 저장하고, 필요할 때 꺼내주는 역할을 합니다.
쉽게 말해 엑셀 파일이라고 생각하면 됩니다. 엑셀에서 각 시트가 하나의 "테이블"이고, 행(가로줄)이 하나의 데이터 항목이며, 열(세로줄)이 각 항목의 속성입니다. 예를 들어 "회원" 테이블이라면, 한 행에 한 명의 회원 정보가 들어가고, 열에는 이름, 이메일, 가입일, 비밀번호(암호화된 형태) 같은 정보가 들어갑니다. "게시글" 테이블에는 제목, 내용, 작성자, 작성일 같은 열이 있겠죠.
2) 관계형 데이터베이스 vs NoSQL 데이터베이스
데이터베이스는 크게 두 종류로 나뉩니다. 관계형 데이터베이스(SQL)와 비관계형 데이터베이스(NoSQL)입니다.
관계형 데이터베이스는 엑셀처럼 행과 열로 데이터를 정리하고, 테이블끼리 "관계"를 맺을 수 있습니다. 예를 들어 "회원" 테이블과 "게시글" 테이블이 있을 때, 게시글 테이블에 "작성자_ID"라는 열을 만들어서 회원 테이블의 ID와 연결하면, "홍길동이 쓴 게시글 목록"을 쉽게 조회할 수 있습니다. PostgreSQL, MySQL, SQLite가 대표적인 관계형 데이터베이스입니다. Supabase는 PostgreSQL 기반이고, Turso는 SQLite 기반입니다.
NoSQL 데이터베이스는 더 유연한 구조를 가집니다. JSON이라는 형식으로 데이터를 저장하는데, 마치 메모장에 자유롭게 적는 것처럼 각 데이터마다 다른 형태를 가질 수 있습니다. Firebase의 Firestore, MongoDB가 대표적입니다. 빠르게 개발할 수 있지만, 데이터 간의 복잡한 관계를 다루기가 어렵습니다.
바이브 코딩에서는 관계형 데이터베이스가 더 유리합니다. AI 도구들이 SQL 문법을 이미 잘 학습하고 있어서, "홍길동의 모든 게시글과 각 게시글의 댓글 수를 조회해줘"라고 하면 정확한 코드를 만들어주기 때문입니다.
3) 서버리스 데이터베이스란
예전에는 데이터베이스를 쓰려면 서버 컴퓨터를 사거나 빌려서, 직접 데이터베이스 소프트웨어를 설치하고, 보안 설정을 하고, 백업을 구성하고, 24시간 모니터링해야 했습니다. 이게 너무 복잡하고 비싸서 개인 개발자나 스타트업은 앱을 만들기가 어려웠습니다.
서버리스 데이터베이스는 이 모든 걸 서비스 회사가 대신 해줍니다. 사용자는 API 키 하나만 받아서 연결하면 끝입니다. 마치 은행에 돈을 맡기면 금고 관리, 보안, 이자 계산을 은행이 알아서 해주는 것과 같습니다. Supabase, Turso, Firebase, Neon, Cloudflare D1 모두 서버리스 데이터베이스입니다.
"서버리스"라는 이름이 오해를 불러일으킬 수 있는데, 서버가 없는 게 아니라 "서버 관리를 내가 안 해도 된다"는 뜻입니다. 실제로는 아마존, 구글, 클라우드플레어 같은 회사의 거대한 데이터센터에서 서버가 돌아가고 있고, 그 비용을 여러 사용자가 나눠 내는 구조입니다.
4) 사용한 만큼 내는 요금 구조
서버리스 데이터베이스의 또 다른 장점은 요금 구조입니다. 전통적인 서버는 사용하든 안 하든 24시간 비용이 나갔지만, 서버리스는 실제로 사용한 만큼만 냅니다. 마치 전기요금처럼요. 앱을 아무도 안 쓰면 비용이 거의 0원이고, 갑자기 사용자가 몰려도 자동으로 처리 능력이 늘어납니다(그리고 비용도 늘어납니다).
이 구조 덕분에 "일단 만들어보고, 사람들이 쓰면 그때 돈 내자"가 가능해졌습니다. 대부분의 서버리스 데이터베이스는 무료 티어를 제공해서, 사이드 프로젝트나 MVP 단계에서는 돈 한 푼 안 내고도 실제 서비스를 운영할 수 있습니다.
2. 주요 데이터베이스 서비스 완전 정리
1) Supabase: 바이브 코딩의 국민 데이터베이스
Supabase(수파베이스)는 현재 바이브 코딩 생태계에서 가장 널리 쓰이는 데이터베이스 서비스입니다. Bolt.new, Lovable, v0 같은 주요 AI 코딩 도구들이 기본(Default)으로 채택하고 있어서, "Supabase 연결해줘"라고 하면 버튼 하나로 연결됩니다.
Supabase는 단순한 데이터베이스가 아니라 "올인원 백엔드 플랫폼"입니다. PostgreSQL 데이터베이스 위에 인증(Auth), 파일 저장소(Storage), 실시간 통신(Realtime), 서버 함수(Edge Functions)를 얹어서 제공합니다. 앱을 만들 때 필요한 백엔드 기능 대부분이 한 곳에 있습니다.
핵심 기능을 하나씩 살펴보면, 먼저 인증(Auth)입니다. 이메일/비밀번호 로그인, 구글/깃허브/카카오 같은 소셜 로그인, 전화번호 인증, 매직 링크(이메일로 로그인 링크 보내기) 등을 코드 몇 줄로 구현할 수 있습니다. Row Level Security(RLS)라는 기능과 연동하면 "홍길동은 홍길동의 데이터만 볼 수 있다"는 보안 규칙을 데이터베이스 레벨에서 강제할 수 있습니다.
파일 저장소(Storage)는 사용자가 업로드하는 이미지, 동영상, 문서 같은 파일을 저장하는 공간입니다. CDN이 붙어 있어서 전 세계 어디서 접속해도 빠르게 파일을 불러올 수 있고, 이미지 리사이징 기능도 있어서 썸네일을 자동으로 만들 수 있습니다.
실시간(Realtime)은 채팅앱이나 협업 도구처럼 데이터가 바뀌면 즉시 화면에 반영되어야 하는 기능을 만들 때 씁니다. 데이터베이스에 새 데이터가 들어오면 연결된 모든 사용자에게 자동으로 알려줍니다.
Edge Functions는 서버에서 실행되는 코드를 만들 수 있는 기능입니다. 결제 처리, 이메일 발송, 외부 API 호출처럼 브라우저에서 직접 하면 안 되는 작업을 처리합니다.
Supabase 가격은 무료(Free) 플랜에서 500MB 데이터베이스, 1GB 파일 저장소, 월 50,000 활성 사용자(MAU), 500,000 Edge Function 호출을 제공합니다. 단, 7일 동안 아무도 접속하지 않으면 프로젝트가 일시 중지됩니다. Pro 플랜은 월 25달러(약 37,500원)로, 8GB 데이터베이스, 100GB 파일 저장소, 100,000 MAU, 무제한 프로젝트 활성 상태를 제공합니다. 추가 프로젝트당 10달러(약 15,000원)입니다.
2) Turso: 비용 걱정 없는 SQLite 클라우드
Turso(터소)는 libSQL이라는 SQLite의 오픈소스 버전을 기반으로 한 엣지 데이터베이스입니다. Supabase 비용이 부담되는 인디 해커들 사이에서 급부상하고 있습니다.
Turso의 가장 큰 장점은 압도적인 무료 티어입니다. 무료 플랜에서 9GB 저장 공간, 월 5억 행(row) 읽기, 월 1,000만 행 쓰기, 최대 500개 데이터베이스를 제공합니다. Supabase 무료의 500MB와 비교하면 18배나 많은 저장 공간입니다. 게다가 프로젝트를 여러 개 만들어도 추가 비용이 없습니다.
또 다른 강점은 "엣지"에서 실행된다는 점입니다. 엣지란 사용자와 가장 가까운 서버를 뜻합니다. Turso는 전 세계 여러 지역에 데이터베이스 복제본을 두고, 각 사용자는 가장 가까운 복제본에서 데이터를 읽습니다. 한국 사용자는 도쿄나 서울 근처 서버에서, 미국 사용자는 미국 서버에서 데이터를 가져오니까 훨씬 빠릅니다.
임베디드 레플리카(Embedded Replica)는 Turso만의 독특한 기능입니다. 클라우드에 있는 데이터베이스의 복사본을 앱이 실행되는 서버나 기기에 직접 저장합니다. 데이터를 읽을 때 인터넷을 통해 클라우드까지 갈 필요 없이 로컬에서 바로 읽으니까 마이크로초(백만분의 1초) 수준의 속도가 나옵니다. 읽기 작업이 많은 앱에서 엄청난 성능 향상을 기대할 수 있습니다.
2025년 3월에는 오프라인 동기화(Offline Sync) 기능도 베타로 출시되었습니다. 인터넷 연결 없이도 로컬 데이터베이스에 데이터를 저장하고, 나중에 인터넷이 연결되면 자동으로 클라우드와 동기화됩니다. 지하철에서 쓰는 메모 앱, 인터넷이 불안정한 현장에서 쓰는 업무 앱을 만들 때 유용합니다.
Turso는 MCP(Model Context Protocol)를 지원해서 Claude, ChatGPT 같은 AI와 직접 연동할 수 있습니다. AI가 데이터베이스 스키마를 이해하고, SQL을 생성하고, 직접 실행까지 할 수 있습니다. 바이브 코딩과 궁합이 좋습니다.
단점은 인증(Auth) 기능이 없다는 것입니다. Turso는 순수한 데이터베이스만 제공하기 때문에, 회원가입/로그인 기능은 Clerk, Kinde, Auth0 같은 별도 서비스를 연동해야 합니다. Supabase의 올인원 편리함에 비하면 설정이 한 단계 더 필요합니다. 파일 저장소도 없어서 Cloudflare R2나 AWS S3 같은 별도 서비스가 필요합니다.
Turso 가격은 무료(Starter) 플랜에서 9GB 저장 공간, 월 5억 읽기, 월 1,000만 쓰기, 500개 데이터베이스입니다. Scaler 플랜은 월 29달러(약 43,500원)로, 24GB 저장 공간, 월 1,000억 읽기, 월 1억 쓰기, 10,000개 데이터베이스입니다.
3) Cloudflare D1: 초저가 SQLite
Cloudflare D1은 Cloudflare가 만든 SQLite 기반 서버리스 데이터베이스입니다. Cloudflare Workers(서버리스 함수)와 함께 쓰도록 설계되어서, 이미 Cloudflare 생태계를 쓰고 있다면 추가 설정 없이 바로 연결됩니다.
D1의 장점은 극강의 가성비입니다. Workers 유료 플랜(월 5달러)에 포함된 D1 무료 사용량만으로도 웬만한 사이드 프로젝트는 충분합니다. 무료 사용량은 5GB 저장 공간, 월 250억 읽기, 월 5,000만 쓰기입니다. 특히 읽기 작업이 많은 앱이라면 비용이 거의 들지 않습니다.
Cloudflare의 글로벌 네트워크 위에서 실행되기 때문에 속도도 빠릅니다. Cloudflare Workers와 같은 데이터센터에서 실행되니까 네트워크 지연이 거의 없습니다.
단점도 있습니다. 가장 큰 문제는 트랜잭션을 지원하지 않는다는 점입니다. 트랜잭션은 여러 작업을 하나로 묶어서 "모두 성공하거나 모두 실패"하게 만드는 기능입니다. 예를 들어 송금 기능에서 A 계좌에서 돈을 빼고 B 계좌에 돈을 넣는 두 작업은 반드시 함께 성공하거나 함께 실패해야 합니다. 중간에 하나만 실패하면 돈이 사라지거나 두 배가 되니까요. D1은 이걸 지원하지 않아서, 복잡한 비즈니스 로직이 필요한 앱에는 부적합합니다.
또한 단일 쿼리에 변수를 100개까지만 사용할 수 있고, 데이터베이스 내보내기가 복잡해서 나중에 다른 서비스로 옮기기 어렵습니다. 간단한 블로그, 포트폴리오, 랜딩 페이지의 폼 데이터 저장 정도에는 충분하지만, 본격적인 서비스에는 Turso가 더 나은 선택입니다.
4) Neon: 서버리스 PostgreSQL
Neon(네온)은 PostgreSQL을 서버리스로 제공하는 서비스입니다. Supabase와 같은 PostgreSQL 기반이지만, Supabase처럼 인증/저장소/실시간 기능은 제공하지 않고 순수하게 데이터베이스만 제공합니다.
Neon의 가장 독특한 기능은 브랜칭(Branching)입니다. Git에서 코드를 브랜치로 나누듯이, 데이터베이스도 브랜치로 나눌 수 있습니다. 현재 운영 중인 데이터베이스를 그대로 복사해서 "개발용 브랜치"를 만들고, 거기서 마음껏 실험한 다음, 문제가 없으면 운영에 반영하는 식입니다. 실험하다가 데이터가 망가져도 원본은 안전합니다.
Scale to Zero 기능도 있습니다. 사용자가 없을 때는 컴퓨팅 자원을 완전히 끄고, 요청이 들어오면 다시 켭니다. 트래픽이 적은 사이드 프로젝트에서 비용을 크게 줄일 수 있습니다. Supabase 무료 티어처럼 7일 미사용시 정지되는 것과 달리, Neon은 정지되지 않고 그냥 비용이 0원이 됩니다.
Vercel과의 연동이 특히 잘 되어 있습니다. Vercel에서 Next.js 프로젝트를 배포할 때 Neon 데이터베이스를 클릭 몇 번으로 연결할 수 있고, 프리뷰 배포마다 별도의 데이터베이스 브랜치를 자동으로 만들어줍니다.
Neon 가격은 무료 플랜에서 0.5GB 저장 공간, 월 190 컴퓨팅 시간을 제공합니다. Launch 플랜은 월 19달러(약 28,500원)로, 10GB 저장 공간, 월 300 컴퓨팅 시간입니다.
5) Firebase: 구글의 올인원 백엔드
Firebase(파이어베이스)는 구글이 운영하는 백엔드 플랫폼입니다. 바이브 코딩이 유행하기 전부터 모바일 앱 개발자들에게 인기 있었고, 지금도 많이 쓰입니다.
Firebase의 데이터베이스인 Firestore는 NoSQL 방식입니다. JSON 형태로 데이터를 저장하기 때문에 구조가 유연하고, 빠르게 개발할 수 있습니다. 실시간 동기화가 기본 내장이라 채팅앱 같은 걸 만들기 쉽습니다. 인증, 저장소, 호스팅, 푸시 알림, 애널리틱스까지 앱 개발에 필요한 거의 모든 게 있습니다. 구글 인프라 위에서 돌아가니까 안정성도 뛰어납니다.
문제는 NoSQL의 한계입니다. "이 게시글을 쓴 사용자의 다른 게시글 목록"처럼 데이터 간의 관계를 조회하려면 코드가 복잡해집니다. SQL에서는 한 줄이면 될 쿼리가 Firestore에서는 여러 번의 요청과 클라이언트 사이드 조합이 필요합니다. AI 도구들도 SQL을 더 잘 이해하기 때문에, 바이브 코딩에서는 Firebase보다 Supabase나 Turso가 더 적합합니다.
또 다른 문제는 비용 예측이 어렵다는 점입니다. Firebase는 읽기/쓰기 횟수, 저장 용량, 네트워크 전송량 등 여러 기준으로 과금하는데, 코드를 잘못 짜면 예상치 못한 대량 요청이 발생해서 갑자기 큰 비용이 청구될 수 있습니다. "Firebase 요금 폭탄"으로 검색하면 관련 사례가 많이 나옵니다.
Firebase는 오픈소스가 아니라서 나중에 다른 서비스로 옮기기도 어렵습니다(벤더 락인). 이미 Firebase로 만든 앱이 있거나, 모바일 앱에서 푸시 알림 같은 Firebase 전용 기능이 필요한 게 아니라면, 새 프로젝트에서는 Supabase를 추천합니다.
6) MongoDB Atlas: 유연한 문서형 데이터베이스
MongoDB(몽고디비)는 JSON과 유사한 문서 형태로 데이터를 저장하는 NoSQL 데이터베이스입니다. MongoDB Atlas는 MongoDB를 클라우드에서 쉽게 사용할 수 있게 해주는 서비스입니다.
MongoDB의 장점은 스키마가 유연하다는 것입니다. 관계형 데이터베이스에서는 테이블을 만들 때 열(컬럼)을 미리 정의해야 하고, 모든 행이 같은 구조를 가져야 합니다. MongoDB에서는 각 문서(데이터 항목)가 다른 구조를 가질 수 있습니다. "이 상품에는 색상 옵션이 있고, 저 상품에는 사이즈 옵션이 있다"처럼 데이터마다 다른 속성을 자유롭게 추가할 수 있습니다.
초기 개발 단계에서 데이터 구조가 자주 바뀔 때 유용합니다. "일단 저장하고, 나중에 구조를 정리하자"가 가능하니까요. 벡터 검색 기능도 지원해서 AI 앱을 만들 때 활용할 수 있습니다.
단점은 복잡한 관계 조회가 어렵다는 것입니다. PostgreSQL이나 MySQL에서 JOIN 한 번이면 되는 쿼리가 MongoDB에서는 여러 단계가 필요합니다. 바이브 코딩 도구들이 MongoDB 쿼리를 생성하는 정확도도 SQL에 비해 떨어집니다.
7) PlanetScale: MySQL 서버리스 (참고용)
PlanetScale은 MySQL 기반 서버리스 데이터베이스로 한때 인기가 많았지만, 2024년에 무료 티어를 폐지해서 개인 개발자에게는 추천하기 어려워졌습니다. 최소 월 39달러(약 58,500원)부터 시작합니다. 이미 MySQL에 익숙하고 기업 프로젝트를 진행 중이라면 고려해볼 만하지만, 바이브 코딩 입문자에게는 Supabase나 Turso가 훨씬 낫습니다.
3. 핵심 비교: Supabase vs Turso vs D1 vs Neon
1) 가격 비교 (2025년 12월 기준)
무료 플랜을 기준으로 비교하면, 저장 공간은 Turso가 9GB로 가장 넉넉하고, Cloudflare D1이 5GB, Supabase가 500MB, Neon이 500MB입니다. 읽기 제한은 D1이 월 250억 행으로 가장 많고(Workers 유료 플랜 기준), Turso가 월 5억 행, Supabase와 Neon은 직접적인 행 수 제한보다는 컴퓨팅 시간이나 대역폭으로 제한합니다.
유료 플랜 최저가는 Cloudflare D1이 월 5달러(Workers 플랜에 포함), Neon이 월 19달러, Supabase가 월 25달러, Turso가 월 5.99달러입니다. 다만 포함된 사용량과 기능이 다르기 때문에 단순 가격 비교는 의미가 없고, 자신의 사용 패턴에 맞춰 계산해야 합니다.
추가 프로젝트 비용에서 가장 큰 차이가 납니다. Supabase는 Pro 플랜에서 추가 프로젝트당 월 10달러가 붙지만, Turso, D1, Neon은 무료 플랜에서도 여러 데이터베이스를 만들 수 있고 추가 비용이 없습니다. 사이드 프로젝트를 여러 개 운영하는 분들에게 이 차이가 큽니다.
2) 기능 비교
인증(Auth) 기능은 Supabase만 내장되어 있습니다. Turso, D1, Neon은 모두 Clerk, Auth0 같은 외부 서비스를 연동해야 합니다. 바이브 코딩 초보자에게는 Supabase의 올인원 구성이 훨씬 편합니다.
파일 저장소도 Supabase만 내장입니다. 나머지는 Cloudflare R2, AWS S3, Uploadthing 같은 별도 서비스가 필요합니다.
실시간(Realtime) 기능은 Supabase가 내장하고 있고, Firebase도 내장입니다. Turso는 임베디드 레플리카의 동기화 기능이 있지만 Supabase의 실시간 구독과는 다릅니다.
벡터 검색은 Supabase(pgvector 확장), Turso(네이티브 지원), MongoDB Atlas가 지원합니다. AI 앱, 유사 문서 검색, 추천 시스템을 만들 때 필요한 기능입니다.
오프라인 동기화는 Turso만 지원합니다(베타). 인터넷 없이 로컬에 저장하고 나중에 동기화하는 기능입니다.
3) 바이브 코딩 도구 연동
Bolt.new, Lovable은 Supabase를 기본 지원합니다. 버튼 하나로 연결되고, AI가 Supabase API를 잘 이해해서 코드 생성 정확도가 높습니다. Turso, Neon도 연결할 수 있지만 수동 설정이 필요합니다.
Cursor, Windsurf 같은 AI 코딩 에디터에서는 모든 데이터베이스를 비슷하게 쓸 수 있습니다. 연결 문자열만 넣어주면 됩니다. Turso는 MCP를 지원해서 AI가 데이터베이스 구조를 직접 파악하고 쿼리를 실행할 수 있습니다.
4) 속도 비교
Vercel의 벤치마크에 따르면, 엣지 환경에서 Turso가 Supabase보다 약 20배 빠른 응답 시간을 보여줍니다. 이는 Turso의 임베디드 레플리카가 애플리케이션과 같은 위치에서 실행되기 때문입니다. D1도 Cloudflare Workers와 같은 데이터센터에서 실행되면 매우 빠릅니다.
다만 이 차이가 체감될 정도인지는 앱의 성격에 따라 다릅니다. 블로그나 대시보드처럼 1초에 한 번 데이터를 읽는 앱에서는 50ms든 5ms든 사용자가 차이를 못 느낍니다. 하지만 한 페이지에서 수십 번 데이터베이스를 조회하는 복잡한 앱이라면 차이가 쌓여서 체감됩니다.
4. 상황별 데이터베이스 선택 가이드
1) "바이브 코딩 처음이에요. 뭘 써야 하나요?"
Supabase를 쓰세요. 이유는 간단합니다. Bolt.new나 Lovable에서 "Supabase 연결해줘"라고 하면 버튼 하나로 끝납니다. 회원가입, 로그인, 파일 업로드까지 AI가 알아서 코드를 짜줍니다. 데이터베이스가 뭔지, SQL이 뭔지 몰라도 일단 작동하는 앱을 만들 수 있습니다.
무료 500MB가 적어 보여도, 텍스트 위주의 앱이라면 생각보다 오래 갑니다. 사용자 1,000명이 각각 게시글 10개씩 쓴다고 해도 수십 MB 수준입니다. 이미지나 동영상은 저장소에 따로 저장되고, 데이터베이스에는 파일 경로만 저장되니까요.
일단 Supabase로 첫 번째 앱을 완성하고, 바이브 코딩에 익숙해진 다음에 비용 최적화가 필요하면 그때 Turso로 갈아타도 늦지 않습니다.
2) "사이드 프로젝트가 여러 개인데 비용이 부담돼요"
Turso로 가세요. Supabase Pro 플랜에서 프로젝트 하나 추가할 때마다 월 10달러가 붙지만, Turso는 무료 플랜에서 500개까지 데이터베이스를 만들 수 있고 추가 비용이 없습니다. 9GB 무료 저장 공간도 사이드 프로젝트 여러 개를 돌리기에 충분합니다.
인증 기능이 없어서 Clerk 같은 외부 서비스를 연동해야 하는데, Clerk 무료 플랜이 월 10,000 활성 사용자까지 지원하니까 사이드 프로젝트에는 충분합니다. 바이브 코딩 도구에서 "Clerk와 Turso로 로그인 기능 만들어줘"라고 하면 대부분 작동하는 코드를 만들어줍니다.
3) "글로벌 서비스를 만들 거예요. 해외에서도 빨라야 해요"
Turso가 최적입니다. Turso는 전 세계 수십 개 리전에 데이터베이스 복제본을 배치할 수 있어서, 한국 사용자는 도쿄 서버에서, 미국 사용자는 미국 서버에서 데이터를 읽습니다. 임베디드 레플리카를 쓰면 서버와 데이터베이스가 같은 위치에서 실행되어 네트워크 지연이 거의 없습니다.
Supabase도 여러 리전을 지원하지만, 데이터베이스는 하나의 리전에만 있고 전 세계 사용자가 그 리전으로 접속합니다. 아시아에 데이터베이스를 두면 미국 사용자가 느리고, 미국에 두면 아시아 사용자가 느립니다.
4) "오프라인에서도 작동하는 앱을 만들고 싶어요"
Turso의 오프라인 동기화(Offline Sync)가 정확히 이 용도입니다. 지하철에서 쓰는 메모 앱, 인터넷이 안 되는 현장에서 쓰는 업무 앱, 비행기 안에서 쓰는 독서 앱 등을 만들 수 있습니다. 인터넷 없이 로컬 SQLite에 데이터를 저장하고, 연결되면 클라우드와 자동 동기화됩니다.
다만 2025년 현재 베타 버전이라서 프로덕션 서비스에는 아직 권장되지 않습니다. 데이터 손실 가능성이 있으니 중요한 데이터는 별도 백업이 필요합니다.
5) "Cloudflare Workers를 이미 쓰고 있어요"
D1을 먼저 고려해보세요. 같은 Cloudflare 생태계 안에서 설정이 간단하고, 네트워크 지연 없이 빠르게 데이터를 읽을 수 있습니다. 월 5달러 Workers 플랜에 D1 사용량이 넉넉하게 포함되어 있어서 추가 비용도 거의 없습니다.
다만 트랜잭션이 필요하거나 복잡한 쿼리가 많다면 D1의 제약에 부딪힐 수 있습니다. 그런 경우 Turso가 더 나은 선택입니다. Turso도 Cloudflare Workers와 잘 연동됩니다.
6) "Next.js + Vercel로 개발하고 있어요"
Neon이 Vercel과 궁합이 좋습니다. Vercel 대시보드에서 클릭 몇 번으로 Neon 데이터베이스를 연결할 수 있고, 프리뷰 배포마다 별도의 데이터베이스 브랜치가 자동으로 만들어집니다. 브랜치 기능은 개발/테스트/운영 환경을 분리할 때 유용합니다.
하지만 Supabase나 Turso도 Vercel과 잘 작동하니까, 인증이나 저장소가 필요하면 Supabase, 비용 절감이 필요하면 Turso를 선택해도 됩니다.
5. 바이브 코딩 시 데이터베이스 보안 체크리스트
AI가 만들어주는 코드는 편리하지만 보안에 구멍이 있을 수 있습니다. 실제 사용자를 받기 전에 반드시 확인해야 할 사항들입니다.
1) API 키가 브라우저에 노출되지 않았는지 확인하기
API 키는 데이터베이스에 접속하기 위한 비밀번호 같은 것입니다. Supabase를 예로 들면, anon key(익명 키)는 브라우저에 노출되어도 괜찮게 설계되어 있습니다. Row Level Security(RLS)가 켜져 있으면 anon key로는 허용된 데이터만 접근할 수 있기 때문입니다.
하지만 service_role key(서비스 역할 키)는 절대 브라우저에서 보이면 안 됩니다. 이 키는 RLS를 무시하고 모든 데이터에 접근할 수 있어서, 노출되면 누구나 모든 데이터를 보고 삭제할 수 있습니다.
AI가 만든 코드에서 service_role key가 프론트엔드 코드에 하드코딩되어 있는지 확인하세요. 환경 변수 파일(.env)을 사용해서 키를 코드와 분리하고, 민감한 키는 서버 사이드(Edge Functions, API Routes)에서만 사용하도록 AI에게 명확히 요청해야 합니다.
2) Row Level Security(RLS)가 켜져 있는지 확인하기
Supabase를 쓴다면 RLS를 반드시 활성화해야 합니다. RLS가 꺼져 있으면 anon key만 알면 다른 사용자의 데이터도 볼 수 있습니다. "회원 A의 일기장을 회원 B가 읽는" 상황이 발생할 수 있습니다.
가장 기본적인 RLS 정책은 "사용자는 자신의 데이터만 읽고 쓸 수 있다"입니다. 테이블에 user_id 열을 만들고, 현재 로그인한 사용자의 ID와 일치하는 행만 접근할 수 있게 설정합니다.
AI에게 "이 테이블에 RLS 정책 추가해줘. 로그인한 사용자는 자신의 데이터만 볼 수 있어야 해"라고 요청하면 올바른 코드를 만들어줍니다. 설정 후에는 테스트 계정 두 개를 만들어서 서로의 데이터가 보이지 않는지 직접 확인하세요.
3) 사용자 입력값을 검증하기
사용자가 입력하는 모든 정보는 믿으면 안 됩니다. 이메일 칸에 이상한 코드를 넣어서 데이터베이스를 공격하는 SQL 인젝션, 스크립트를 넣어서 다른 사용자의 브라우저에서 실행시키는 XSS 공격 등이 실제로 일어납니다.
이메일 형식이 맞는지, 숫자를 넣어야 하는 곳에 문자가 들어오지는 않는지, 너무 긴 텍스트가 들어오지는 않는지 검증하는 코드가 필요합니다. AI가 만든 코드에 이런 검증 로직이 빠져 있는 경우가 많으니, 서비스 공개 전에 모든 입력 폼을 점검하세요.
4) 에러 메시지가 기술적 정보를 노출하지 않는지 확인하기
오류가 발생했을 때 "데이터베이스 연결 실패: postgres://user:password@host:5432/db" 같은 메시지가 사용자에게 보이면 안 됩니다. 공격자에게 시스템 구조를 알려주는 셈이 됩니다. 사용자에게는 "일시적인 오류가 발생했습니다. 잠시 후 다시 시도해주세요" 같은 일반적인 메시지만 보여주고, 상세한 에러 내용은 서버 로그에만 기록해야 합니다. AI가 만든 코드는 종종 개발 편의를 위해 상세한 에러 메시지를 그대로 반환하니까, 프로덕션 배포 전에 반드시 수정하세요.
5) 브라우저 개발자 도구로 직접 테스트하기
크롬에서 F12를 누르면 개발자 도구가 열립니다. "Network" 탭에서 앱이 서버와 주고받는 모든 요청을 볼 수 있습니다. 여기서 API 키나 비밀번호 같은 민감한 정보가 노출되지 않는지 확인하세요. "Application" 탭에서 로컬 스토리지나 쿠키에 민감한 정보가 평문으로 저장되어 있지 않은지도 확인하세요.
또한 테스트 계정 두 개를 만들어서 A 계정으로 로그인한 상태에서 B 계정의 데이터 URL을 직접 입력해보세요. 접근이 차단되어야 정상입니다. 입력 칸에 <script>alert('XSS')</script> 같은 코드를 넣어봐서 실행되는지도 테스트하세요.
6. Turso 심화: Limbo 프로젝트와 버그 바운티
1) SQLite를 Rust로 다시 만드는 Limbo 프로젝트
Turso는 단순히 SQLite를 클라우드에 올린 것에 그치지 않고, SQLite 전체를 Rust 언어로 처음부터 다시 작성하는 야심찬 프로젝트를 진행 중입니다. 프로젝트 이름은 Limbo(림보)입니다.
왜 이런 일을 할까요? SQLite는 C 언어로 작성되어 있고, 20년 넘게 세 명의 핵심 개발자만 유지보수합니다. 외부 기여를 받지 않고, 테스트 코드도 공개하지 않습니다. 이 덕분에 엄청난 안정성을 자랑하지만, 새로운 기능을 추가하거나 현대적인 환경에 맞게 개선하기가 어렵습니다.
Turso는 libSQL이라는 SQLite 포크를 만들어서 벡터 검색 같은 기능을 추가했지만, 근본적인 한계가 있었습니다. SQLite가 동기식(synchronous)으로 설계되어 있어서 비동기(asynchronous) 처리가 어렵고, C 언어 특성상 메모리 안전성 문제가 발생할 수 있습니다.
Limbo는 이런 한계를 극복하기 위해 시작되었습니다. Rust 언어는 메모리 안전성을 컴파일러 수준에서 보장하고, 비동기 처리에 강합니다. Limbo는 SQLite와 파일 형식, SQL 문법에서 100% 호환되면서도 완전한 비동기 I/O, 웹 브라우저에서 직접 실행(WebAssembly), 더 나은 성능을 목표로 합니다.
2) 결정론적 시뮬레이션 테스트(DST)로 신뢰성 확보
SQLite가 "세계에서 가장 안정적인 소프트웨어"로 불리는 이유는 엄청난 양의 테스트 때문입니다. Limbo는 이에 대응하기 위해 결정론적 시뮬레이션 테스트(Deterministic Simulation Testing, DST)를 도입했습니다.
DST는 TigerBeetle이라는 금융 데이터베이스 프로젝트에서 유명해진 테스트 방식입니다. 핵심 아이디어는 "수년간의 실행을 시뮬레이터에서 빠르게 돌려보자"입니다. 실제 환경에서는 수년이 걸려야 발생하는 희귀한 버그도, 시뮬레이터에서는 몇 시간 만에 찾아낼 수 있습니다.
더 중요한 것은 "결정론적"이라는 점입니다. 버그가 발견되면 같은 조건으로 100% 동일하게 재현할 수 있습니다. 실제 환경에서 "가끔 발생하는데 재현이 안 되는" 버그는 디버깅이 악몽이지만, DST에서 발견된 버그는 바로 원인을 찾을 수 있습니다.
Turso는 자체 DST 프레임워크를 개발했고, 추가로 Antithesis라는 회사와 파트너십을 맺었습니다. Antithesis는 결정론적 하이퍼바이저를 제공해서 운영체제 수준의 장애(디스크 부분 쓰기, 네트워크 끊김 등)까지 시뮬레이션할 수 있습니다. 실제로 Antithesis를 통해 io_uring(리눅스의 비동기 I/O API) 구현에서 부분 쓰기 관련 버그를 발견했다고 합니다.
3) 1,000달러 버그 바운티 프로그램
Turso는 DST의 버그 발견 능력에 대한 자신감을 바탕으로 버그 바운티 프로그램을 운영합니다. 데이터 손실이나 데이터 손상으로 이어지는 버그를 찾으면 1,000달러(약 150만원)의 상금을 받을 수 있습니다.
참여 방식은 다음과 같습니다. 먼저 Turso CLI를 로컬에서 빌드하고 개발 환경을 설정합니다. GitHub 저장소의 simulator 디렉토리에서 DST 프레임워크의 구조를 파악합니다. 기존 시뮬레이터가 발견하지 못했던 새로운 데이터 손상 버그를 노출시킬 수 있도록 시뮬레이터를 개선합니다. 개선 내용을 PR(Pull Request)로 제출하고, PR이 합쳐지면 800달러를 받습니다. 해당 버그를 직접 수정하는 PR까지 합쳐지면 추가로 200달러를 받습니다.
참여 조건이 있습니다. 버그는 최신 릴리스 버전에 존재해야 하고, 기본적으로 활성화된 기능에서 발생해야 합니다. 실험적(experimental) 기능이나 별도로 활성화해야 하는 기능의 버그는 대상이 아닙니다. 데이터 손상 버그란 "미래의 패치로도 복구할 수 없는 방식으로 데이터가 손실되는 버그"를 말합니다.
이 프로그램은 Rust와 데이터베이스 내부 구조에 대한 지식이 필요해서 바이브 코딩 초보자에게는 적합하지 않습니다. 하지만 시스템 프로그래밍에 관심 있는 개발자에게는 Turso 내부를 배우면서 상금도 받을 수 있는 좋은 기회입니다. 질문이 있으면 Turso Discord 서버에서 커뮤니티와 소통할 수 있습니다.
7. 실전 마이그레이션 가이드
1) Supabase에서 Turso로 옮기기
Supabase(PostgreSQL)에서 Turso(SQLite)로 옮기는 것은 가능하지만 몇 가지 주의점이 있습니다. 두 데이터베이스는 SQL 문법이 대부분 호환되지만, PostgreSQL 전용 기능(JSONB 타입의 고급 쿼리, 배열 타입, 일부 날짜 함수 등)을 사용했다면 수정이 필요합니다.
마이그레이션 순서는 다음과 같습니다. 먼저 Supabase에서 데이터를 CSV나 SQL로 내보냅니다. Turso에서 새 데이터베이스를 만들고 스키마(테이블 구조)를 생성합니다. 데이터를 가져옵니다. 앱 코드에서 데이터베이스 연결 문자열을 Turso로 변경합니다. Supabase Auth를 사용했다면 Clerk 같은 외부 인증 서비스로 교체합니다. Supabase Storage를 사용했다면 Cloudflare R2나 Uploadthing으로 교체합니다.
가장 까다로운 부분은 인증과 저장소입니다. 기존 사용자의 비밀번호 해시를 그대로 옮기기 어려울 수 있어서, 기존 사용자에게 비밀번호 재설정을 요청해야 할 수도 있습니다. 소셜 로그인을 사용했다면 Clerk에서 같은 소셜 프로바이더를 설정하면 됩니다.
2) Firebase에서 Supabase로 옮기기
Firebase(Firestore, NoSQL)에서 Supabase(PostgreSQL, 관계형)로 옮기는 것은 더 큰 작업입니다. 데이터 저장 방식 자체가 다르기 때문에 데이터 구조를 완전히 재설계해야 합니다.
Firestore에서는 컬렉션(collection) 안에 문서(document)가 있고, 문서 안에 또 서브컬렉션이 있는 중첩 구조를 많이 씁니다. 예를 들어 users/{userId}/posts/{postId} 같은 경로로 데이터를 저장합니다. PostgreSQL에서는 users 테이블과 posts 테이블을 따로 만들고, posts 테이블에 user_id 열을 추가해서 관계를 표현합니다.
마이그레이션 순서는 다음과 같습니다. 먼저 Firestore의 데이터 구조를 분석해서 PostgreSQL 스키마를 설계합니다. Firestore에서 데이터를 JSON으로 내보냅니다. 변환 스크립트를 작성해서 JSON 데이터를 PostgreSQL 형식으로 변환합니다. Supabase에 데이터를 가져옵니다. 앱 코드에서 Firestore SDK 호출을 Supabase SDK 호출로 교체합니다. Firebase Auth를 Supabase Auth로, Firebase Storage를 Supabase Storage로 교체합니다.
이 작업은 앱 규모에 따라 며칠에서 몇 주가 걸릴 수 있습니다. 새 프로젝트를 시작한다면 처음부터 Supabase를 선택하는 것이 낫습니다.
3) 같은 PostgreSQL 끼리 옮기기 (Supabase ↔ Neon)
Supabase와 Neon은 둘 다 PostgreSQL이라서 마이그레이션이 비교적 쉽습니다. pg_dump 명령어로 데이터베이스 전체를 SQL 파일로 내보내고, 새 서비스에서 가져오면 됩니다.
단, Supabase의 인증/저장소/실시간 기능은 PostgreSQL 위에 얹어진 것이라서 함께 옮겨지지 않습니다. Neon으로 옮기면 이 기능들을 별도 서비스로 대체해야 합니다.
8. 바이브 코더를 위한 데이터베이스 종합 비교표 (2025년 12월 최신)
1) 핵심 스펙 한눈에 비교
| 항목 | Supabase | Turso | Cloudflare D1 | Neon | Firebase | MongoDB Atlas |
|---|---|---|---|---|---|---|
| 기반 기술 | PostgreSQL | libSQL (SQLite 포크) | SQLite | PostgreSQL | Firestore (NoSQL) | MongoDB (NoSQL) |
| 데이터 모델 | 관계형 (SQL) | 관계형 (SQL) | 관계형 (SQL) | 관계형 (SQL) | 문서형 (NoSQL) | 문서형 (NoSQL) |
| 오픈소스 | ✅ 예 | ✅ 예 | ❌ 아니오 | ✅ 예 | ❌ 아니오 | ✅❌ |
| 셀프 호스팅 | ✅ 가능 | ✅ 가능 | ❌ 불가 | ❌ 불가 | ❌ 불가 | ✅ 가능 |
2) 무료 플랜 상세 비교 (2025년 12월 공식 가격 기준)
| 항목 | Supabase | Turso | Cloudflare D1 | Neon | Firebase | MongoDB Atlas |
|---|---|---|---|---|---|---|
| 저장 공간 | 500MB | 5GB | 5GB | 500MB | 1GB (Firestore) | 512MB |
| 데이터베이스/프로젝트 수 | 2개 | 100개 | 무제한 | 100개 | 무제한 | 1개 |
| 읽기 제한 | 무제한* | 월 5억 행 | 일 500만 행 | 월 190 CU-시간* | 일 5만 읽기 | 무제한* |
| 쓰기 제한 | 무제한* | 월 1천만 행 | 일 10만 행 | 월 190 CU-시간* | 일 2만 쓰기 | 무제한* |
| 휴면 정책 | ⚠️ 7일 미사용시 정지 | ❌ 없음 | ❌ 없음 | ❌ 없음 (Scale to Zero) | ❌ 없음 | ❌ 없음 |
| 인증 MAU | 50,000명 | ❌ 별도 필요 | ❌ 별도 필요 | ❌ 별도 필요 | 50,000명 | ❌ 별도 필요 |
| 파일 저장소 | 1GB | ❌ 별도 필요 | ❌ 별도 필요 | ❌ 별도 필요 | 5GB | ❌ 별도 필요 |
*컴퓨팅 시간/대역폭/공유 리소스 기준 제한
3) 유료 플랜 최저가 비교
| 항목 | Supabase Pro | Turso Developer | D1 (Workers Paid) | Neon Launch | Firebase Blaze | MongoDB Flex |
|---|---|---|---|---|---|---|
| 월 비용 | $25 (≈37,500원) | $5.99 (≈9,000원) ⭐ | $5 (≈7,500원) ⭐ | $19~ (종량제) | 종량제 | $0.011/시간~ |
| 저장 공간 | 8GB (+$0.125/GB) | 9GB (+$0.75/GB) | 5GB 포함 (+$0.75/GB) | 종량제 ($0.35/GB-월) | 종량제 | 최대 5GB |
| 추가 프로젝트 | ⚠️ +$10/개 | ✅ 무료 (무제한) | ✅ 무료 | ✅ 무료 | ✅ 무료 | - |
| 컴퓨트 크레딧 | $10 포함 | - | - | - | - | - |
4) 초과 사용 요금 비교
| 항목 | Supabase | Turso | Cloudflare D1 | Neon | Firebase |
|---|---|---|---|---|---|
| 추가 저장소 | $0.125/GB | $0.75/GB | $0.75/GB | $0.35/GB-월 | $0.026/GB |
| 추가 읽기 | $0.09/GB (egress) | $1/10억 행 | $0.001/백만 행 | $0.106/CU-시간 | $0.06/10만 읽기 |
| 추가 쓰기 | - | $1/백만 행 | $1/백만 행 | (컴퓨트에 포함) | $0.18/10만 쓰기 |
| 추가 MAU | $0.00325/MAU | - | - | - | Google Cloud 요금 |
5) 내장 기능 비교
| 기능 | Supabase | Turso | D1 | Neon | Firebase | MongoDB |
|---|---|---|---|---|---|---|
| 인증 (Auth) | ✅ 내장 ⭐ | ❌ 외부 필요 | ❌ 외부 필요 | ❌ 외부 필요 | ✅ 내장 | ❌ 외부 필요 |
| 파일 저장소 | ✅ 내장 ⭐ | ❌ 외부 필요 | ❌ 외부 필요 | ❌ 외부 필요 | ✅ 내장 | ❌ 외부 필요 |
| 실시간 (Realtime) | ✅ 내장 | ⚠️ 제한적 | ❌ 없음 | ❌ 없음 | ✅ 내장 | ✅ Change Streams |
| Edge Functions | ✅ 내장 | ❌ 없음 | ✅ Workers | ❌ 없음 | ✅ Cloud Functions | ❌ 없음 |
| 벡터 검색 (AI) | ✅ pgvector | ✅ 네이티브 ⭐ | ❌ 없음 | ✅ pgvector | ❌ 없음 | ✅ Atlas Vector |
| 트랜잭션 | ✅ 완전 지원 | ✅ 완전 지원 | ❌ 미지원 ⚠️ | ✅ 완전 지원 | ⚠️ 제한적 | ✅ 지원 |
| 브랜칭 (DB 복사본) | ❌ 없음 | ❌ 없음 | ❌ 없음 | ✅ 지원 ⭐ | ❌ 없음 | ❌ 없음 |
| 오프라인 동기화 | ❌ 없음 | ✅ 베타 ⭐ | ❌ 없음 | ❌ 없음 | ✅ 지원 | ✅ Realm Sync |
| 임베디드 레플리카 | ❌ 없음 | ✅ 지원 ⭐ | ❌ 없음 | ❌ 없음 | ❌ 없음 | ❌ 없음 |
| Point-in-Time 복구 | 7일 (Pro) | 10일 (Developer) | ❌ 없음 | ✅ 지원 | ❌ 없음 | ✅ 지원 |
6) 바이브 코딩 도구 연동성
| 항목 | Supabase | Turso | D1 | Neon | Firebase | MongoDB |
|---|---|---|---|---|---|---|
| Bolt.new 연동 | ✅ 1클릭 ⭐ | ⚠️ 수동 설정 | ⚠️ 수동 설정 | ⚠️ 수동 설정 | ⚠️ 수동 설정 | ⚠️ 수동 설정 |
| Lovable 연동 | ✅ 1클릭 ⭐ | ⚠️ 수동 설정 | ⚠️ 수동 설정 | ⚠️ 수동 설정 | ⚠️ 수동 설정 | ⚠️ 수동 설정 |
| MCP 지원 | ✅ 지원 | ✅ 지원 ⭐ | ❌ 없음 | ⚠️ 제한적 | ❌ 없음 | ⚠️ 제한적 |
| AI 코드 생성 정확도 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| 초보자 진입 장벽 | 낮음 ⭐ | 중간 | 중간 | 중간 | 낮음 | 중간 |
7) 성능 및 인프라 비교
| 항목 | Supabase | Turso | D1 | Neon | Firebase | MongoDB |
|---|---|---|---|---|---|---|
| 글로벌 분산 | 단일 리전 | ✅ 다중 리전 ⭐ | ✅ 다중 리전 | 단일 리전 | ✅ 다중 리전 | ✅ 다중 리전 |
| 엣지 실행 | ❌ | ✅ 지원 ⭐ | ✅ 지원 | ❌ | ❌ | ❌ |
| 읽기 속도 | 보통 | 매우 빠름 ⭐ | 빠름 | 보통 | 빠름 | 빠름 |
| Cold Start | ⚠️ 있음 (무료) | ❌ 없음 | ❌ 없음 | Scale to Zero | ❌ 없음 | ❌ 없음 |
| 최대 동시 연결 | 60~500 (플랜별) | 높음 | 높음 | 60~500 (플랜별) | 200K | 500+ |
| SLA 가용성 | - | - | - | 99.95% (Scale) | - | 99.995% |
8) 사이드 프로젝트 3개 운영 시 월 예상 비용
| 시나리오 | Supabase | Turso | D1 | Neon |
|---|---|---|---|---|
| 무료 플랜으로 | ❌ 불가 (2개 제한) | ✅ $0 ⭐ | ✅ $0 | ✅ $0 |
| 유료 플랜으로 | $25 + $20 = $45 | $5.99 ⭐ | $5 ⭐ | 종량제 |
| 한국 원화 환산 | ≈67,500원 | ≈9,000원 | ≈7,500원 | 사용량 따라 |
9) 상황별 추천 요약표
| 상황 | 1순위 | 2순위 | 핵심 이유 |
|---|---|---|---|
| 바이브 코딩 입문 | Supabase | Firebase | 올인원, 1클릭 연동, AI 정확도 최고 |
| 비용 최소화 | Turso | D1 | 월 $5.99에 무제한 DB, 9GB 저장 |
| 사이드 프로젝트 다수 | Turso | D1 | 무료 100개 DB, 추가 비용 없음 |
| 글로벌 서비스 | Turso | D1 | 엣지 분산, 임베디드 레플리카 |
| 오프라인 앱 | Turso | Firebase | 오프라인 동기화 지원 |
| Next.js + Vercel | Neon | Supabase | Vercel 네이티브 연동, 브랜칭 |
| Cloudflare 생태계 | D1 | Turso | Workers와 동일 네트워크 |
| 복잡한 데이터 관계 | Supabase | Neon | PostgreSQL 고급 기능 |
| 실시간 채팅/협업 | Supabase | Firebase | 내장 Realtime 기능 |
| AI/RAG 앱 | Supabase | Turso | 벡터 검색 + 풀스택 |
| 엔터프라이즈 | MongoDB | Supabase | SLA, HIPAA, SOC2 |
10) 선택 플로우차트
11) 인증 서비스 조합 가이드 (Turso/D1/Neon 사용 시)
| 인증 서비스 | 무료 MAU | 유료 시작가 | 특징 |
|---|---|---|---|
| Clerk | 10,000명 | $25/월 | 가장 인기, UI 컴포넌트 제공, 바이브코딩 호환 최고 |
| Kinde | 10,500명 | $25/월 | 간편한 설정, 빠른 연동 |
| Auth0 | 7,500명 | $23/월 | 엔터프라이즈급, 커스터마이징 |
| Lucia | 무제한 | 무료 (셀프) | 오픈소스, 직접 구현 필요 |
| Better Auth | 무제한 | 무료 (셀프) | 최신, TypeScript 친화적 |
12) 마이그레이션 난이도 매트릭스
| From ↓ / To → | Supabase | Turso | D1 | Neon | Firebase | MongoDB |
|---|---|---|---|---|---|---|
| Supabase | - | ⚠️ 중간 | ⚠️ 중간 | ✅ 쉬움 | ❌ 어려움 | ❌ 어려움 |
| Turso | ⚠️ 중간 | - | ✅ 쉬움 | ⚠️ 중간 | ❌ 어려움 | ❌ 어려움 |
| D1 | ⚠️ 중간 | ✅ 쉬움 | - | ⚠️ 중간 | ❌ 어려움 | ❌ 어려움 |
| Neon | ✅ 쉬움 | ⚠️ 중간 | ⚠️ 중간 | - | ❌ 어려움 | ❌ 어려움 |
| Firebase | ❌ 어려움 | ❌ 어려움 | ❌ 어려움 | ❌ 어려움 | - | ⚠️ 중간 |
| MongoDB | ❌ 어려움 | ❌ 어려움 | ❌ 어려움 | ❌ 어려움 | ⚠️ 중간 | - |
난이도: ✅ 쉬움 (몇 시간) | ⚠️ 중간 (며칠) | ❌ 어려움 (몇 주, 재설계 필요)
13) 최종 종합 점수표 (5점 만점)
| 평가 항목 | Supabase | Turso | D1 | Neon | Firebase | MongoDB |
|---|---|---|---|---|---|---|
| 초보자 친화성 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 무료 플랜 가성비 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| 유료 플랜 가성비 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| 기능 완성도 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| 성능/속도 | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| 확장성 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| 이식성 (탈출 용이) | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐ |
| 종합 점수 | 4.0 | 3.9 | 3.3 | 3.4 | 3.3 | 3.3 |
14) 핵심 결론 요약
| 질문 | 답변 |
|---|---|
| "처음 시작하는데 뭘 써야 하나요?" | Supabase - 버튼 하나로 연결, 모든 기능 내장 |
| "Supabase 비용이 부담돼요" | Turso - 월 $5.99로 무제한 DB, 9GB 저장 |
| "무료로 사이드 프로젝트 여러 개 돌리고 싶어요" | Turso - 무료로 100개 DB 생성 가능 |
| "전 세계 사용자에게 빠른 속도가 중요해요" | Turso - 엣지 분산 + 임베디드 레플리카 |
| "Cloudflare 생태계를 쓰고 있어요" | D1 - 같은 네트워크에서 최고 성능 |
| "Next.js + Vercel로 개발해요" | Neon - 브랜칭 + Vercel 네이티브 연동 |
| "나중에 다른 DB로 옮길 수 있어야 해요" | PostgreSQL 계열 (Supabase, Neon) |
💡 추천 로드맵:
- 입문 → Supabase로 시작 (올인원, 쉬움)
- 성장 → 비용 부담 시 Turso로 전환 (월 $5.99)
- 스케일 → 필요에 따라 엔터프라이즈 플랜 또는 전문 서비스
9. 자주 묻는 질문 (FAQ)
Q: 바이브 코딩 완전 초보인데 어떤 데이터베이스를 써야 하나요?
A: Supabase를 쓰세요. Bolt.new나 Lovable에서 버튼 하나로 연결되고, 회원가입, 로그인, 파일 업로드까지 AI가 알아서 코드를 만들어줍니다. 데이터베이스나 SQL을 전혀 몰라도 일단 작동하는 앱을 만들 수 있습니다. 무료 500MB로 시작해서 바이브 코딩에 익숙해진 다음, 필요하면 다른 서비스로 갈아타도 됩니다.
Q: Supabase 무료 500MB로 얼마나 버틸 수 있나요?
A: 텍스트 위주의 앱이라면 생각보다 오래 갑니다. 사용자 정보, 게시글, 댓글 같은 텍스트 데이터는 용량을 많이 차지하지 않습니다. 사용자 1,000명이 각각 게시글 100개씩 써도 수십 MB 수준입니다. 이미지나 동영상은 Storage에 저장되고 데이터베이스에는 URL만 저장되니까요. 다만 벡터 임베딩을 저장하거나, 로그 데이터를 쌓거나, 대량의 JSON 데이터를 저장하면 금방 찰 수 있습니다.
Q: Turso는 인증 기능이 없는데 어떻게 로그인을 구현하나요?
A: Clerk, Kinde, Auth0, Lucia 같은 외부 인증 서비스와 함께 사용합니다. 가장 인기 있는 조합은 Turso + Clerk입니다. Clerk 무료 플랜은 월 10,000 활성 사용자까지 지원해서 사이드 프로젝트에 충분합니다. 바이브 코딩 도구에서 "Clerk와 Turso로 로그인 기능 구현해줘"라고 요청하면 대부분 작동하는 코드를 만들어줍니다. Supabase의 올인원 편리함에 비하면 설정이 한 단계 더 필요하지만, 비용 절감 효과가 큽니다.
Q: Firebase에서 Supabase로 옮기고 싶은데 가능한가요?
A: 가능하지만 상당한 작업이 필요합니다. Firebase Firestore는 NoSQL이고 Supabase는 PostgreSQL이라서 데이터 저장 방식 자체가 다릅니다. Firestore의 중첩된 컬렉션 구조를 PostgreSQL의 테이블과 관계로 재설계해야 합니다. 인증, 저장소, Cloud Functions도 각각 Supabase의 대응 기능으로 마이그레이션해야 합니다. 앱 규모에 따라 며칠에서 몇 주가 걸릴 수 있습니다. 새 프로젝트라면 처음부터 Supabase로 시작하는 것이 훨씬 낫습니다.
Q: Turso의 오프라인 동기화를 프로덕션에서 써도 되나요?
A: 2025년 12월 현재 오프라인 동기화(Offline Sync)는 공개 베타 상태입니다. Turso 공식 문서에서도 "베타 품질이며 아직 프로덕션 사용을 권장하지 않는다"고 명시하고 있습니다. 베타 기간에는 데이터 내구성(durability)이 보장되지 않아서 데이터 손실 가능성이 있습니다. 테스트 환경이나 데이터 손실이 치명적이지 않은 서비스에서는 충분히 사용해볼 만하지만, 중요한 데이터를 다루는 서비스라면 정식 출시를 기다리거나 별도의 백업 전략을 마련하세요.
Q: AI가 만든 데이터베이스 코드가 안전한지 어떻게 확인하나요?
A: 서비스 공개 전에 네 가지를 확인하세요. 첫째, 브라우저 개발자 도구(F12)의 Network 탭에서 API 키가 노출되지 않는지 확인합니다. Supabase의 service_role key는 절대 노출되면 안 됩니다. 둘째, Supabase를 쓴다면 Row Level Security(RLS)가 켜져 있는지 확인합니다. 셋째, 테스트 계정 두 개를 만들어서 A 계정으로 로그인했을 때 B 계정의 데이터가 보이는지 테스트합니다. 넷째, 입력 칸에 이상한 문자나 스크립트를 넣어봐서 앱이 이상하게 동작하지 않는지 확인합니다.
Q: 데이터베이스를 나중에 다른 서비스로 옮길 수 있나요?
A: 같은 종류끼리는 비교적 쉽습니다. PostgreSQL 기반(Supabase, Neon) 사이에서는 pg_dump로 내보내고 가져오면 됩니다. SQLite 기반(Turso, D1) 사이에서도 SQLite 파일을 내보내고 가져올 수 있습니다. 하지만 PostgreSQL에서 SQLite로, 또는 NoSQL에서 관계형으로 옮기는 것은 데이터 구조 재설계가 필요해서 큰 작업입니다. 처음 선택할 때 너무 고민하기보다는 일단 시작하고, 정말 필요해지면 그때 마이그레이션하는 것을 추천합니다.
Q: 무료 플랜만으로 실제 서비스를 운영할 수 있나요?
A: 소규모 서비스라면 가능합니다. 특히 Turso 무료 플랜은 9GB 저장 공간, 월 5억 읽기로 상당히 넉넉합니다. 개인 블로그, 포트폴리오, 소규모 커뮤니티, 유틸리티 앱 정도는 충분히 운영할 수 있습니다. 다만 Supabase 무료 플랜은 7일 미사용 시 프로젝트가 일시 중지되고, 기술 지원도 제한적입니다. 실제 사용자를 받는 서비스라면 저렴한 유료 플랜이라도 업그레이드하는 것이 마음 편합니다.
10. 마무리
바이브 코딩 시대에 데이터베이스 선택은 더 이상 전문가만의 영역이 아닙니다. 서버리스 데이터베이스 덕분에 서버 관리 지식 없이도 실제 서비스를 운영할 수 있고, 무료 플랜으로 시작해서 성장에 따라 확장할 수 있습니다.
핵심 요약:
-
완전 초보자는 Supabase로 시작하세요. Bolt.new, Lovable에서 버튼 하나로 연결되고, 인증/저장소/실시간 기능이 모두 포함되어 있습니다.
-
비용을 최소화하고 싶다면 Turso를 고려하세요. 무료 9GB 저장 공간, 프로젝트 추가 비용 없음, MCP로 AI 연동이 쉽습니다. 인증은 Clerk 같은 외부 서비스와 함께 사용합니다.
-
글로벌 서비스를 만든다면 Turso의 엣지 기능과 임베디드 레플리카가 최적입니다. 전 세계 어디서 접속해도 빠른 응답 속도를 제공합니다.
-
Cloudflare Workers를 이미 쓰고 있다면 D1도 좋은 선택입니다. 단, 트랜잭션이 필요하면 Turso가 낫습니다.
-
PostgreSQL 기반(Supabase, Neon)을 선택하면 나중에 마이그레이션이 쉽습니다.
-
AI가 만든 코드의 보안 구멍을 반드시 직접 점검하세요. API 키 노출, RLS 미설정, 입력값 미검증이 가장 흔한 문제입니다.
데이터베이스 선택에 너무 오래 고민하지 마세요. 처음에는 Supabase로 시작해서 바이브 코딩에 익숙해지고, 비용이나 성능 최적화가 필요해지면 그때 Turso로 전환하는 로드맵을 추천합니다. 가장 중요한 것은 빨리 시작해서 실제 사용자의 반응을 확인하는 것입니다. 데이터베이스는 나중에 바꿀 수 있지만, 좋은 아이디어를 실행하지 않고 흘려보내는 시간은 되돌릴 수 없습니다.
