바이브 코딩으로 Cloudflare에서 홈페이지 만들기 완전 가이드 2026

예전 홈페이지 제작 가이드는 Next.js, Vercel, Supabase 조합을 기준으로 설명하는 경우가 많았습니다. 그 조합도 여전히 훌륭하지만, 개인 사이트나 작은 비즈니스 사이트에서는 호스팅, API, DB, 이미지 저장소, 캐시, 도메인, SSL을 한 곳에서 다루는 Cloudflare-first 흐름이 점점 더 편해졌습니다.

이 글의 기준은 현재 사이트와 잘 맞는 Astro + Cloudflare Pages + Functions 구조입니다. 콘텐츠 페이지는 빠르게 정적으로 만들고, 필요한 부분만 Workers, D1, R2, KV로 확장합니다. AI에게는 반복 작업과 설정 초안을 맡기되, 계정 권한과 비밀값은 사람이 통제하는 방식으로 진행합니다.

AI에게 "홈페이지 만들어줘"라고만 말하면 예쁜 첫 화면은 나올 수 있지만 운영 가능한 사이트가 되기는 어렵습니다. 먼저 방문자가 무엇을 해야 하는지 한 문장으로 정해야 합니다. 예를 들어 "내 작업물을 보고 연락하게 한다", "매장 정보를 확인하고 예약하게 한다", "글을 읽고 뉴스레터를 신청하게 한다"처럼 말입니다.

Cloudflare 조합은 이 작은 목표를 빠르게 공개하고, 트래픽이 생기면 기능을 늘리는 방식에 강합니다. 그래서 처음 설계할 때부터 데이터와 파일을 어디에 둘지 가볍게 정해 두면, 나중에 AI가 코드를 늘려도 구조가 흐트러지지 않습니다.

Cloudflare에서 도메인을 관리하면 DNS, SSL, 캐시, 보안 설정을 같은 대시보드에서 확인할 수 있습니다. Pages 프로젝트를 만들고 나면 기본 배포 주소가 생기고, 나중에 커스텀 도메인을 연결해 실제 주소로 공개합니다.

AI에게 DNS 설정을 맡길 때는 계정 화면을 직접 열어 조작하게 하기보다, 현재 레코드 목록을 사람이 확인한 뒤 "어떤 레코드를 추가해야 하는지 계획만 제시해 달라"고 요청하는 편이 안전합니다. 특히 기존 메일, 블로그, 서브도메인을 쓰고 있다면 무심코 지우면 안 됩니다.

Wrangler는 Cloudflare Workers, Pages, D1, R2, KV를 터미널에서 만들고 배포하는 CLI입니다. 바이브 코딩을 제대로 쓰려면 AI가 "어떤 명령을 실행해야 하는지" 설명하고, 사용자가 승인한 명령만 실행되는 루틴을 만드는 것이 좋습니다.

처음에는 로그인과 현재 계정 확인만 해도 충분합니다. 원격 리소스를 만드는 명령은 비용, 이름 충돌, 권한 문제와 연결될 수 있으니 계획을 확인한 뒤 실행합니다.

AI가 Cloudflare 설정까지 도와주는 흐름은 강력합니다. 하지만 "모두 설정해줘"라는 말은 계정 권한, API 토큰, 데이터 삭제, 배포 변경까지 열어 줄 수 있다는 뜻이기도 합니다. 바이브 코딩에서 가장 중요한 습관은 권한을 작업 단위로 작게 나누는 것입니다.

실전에서는 AI에게 계획, 파일 수정, 명령 제안, 오류 분석을 맡깁니다. 실제 Cloudflare 로그인, API 토큰 생성, 결제 정보, 삭제 명령, 운영 DB 마이그레이션은 사람이 확인합니다. 필요한 경우에도 토큰 값 자체를 채팅에 붙여 넣지 않고 환경 변수나 Pages secrets로 저장합니다.

홈페이지, 포트폴리오, 칼럼, 매장 소개처럼 읽는 페이지가 많은 사이트는 Astro가 가볍습니다. 기본은 정적 HTML로 만들고, 검색, 계산기, 관리자 일부처럼 동작이 필요한 곳에만 React 컴포넌트를 섬처럼 붙일 수 있습니다.

기존 Cloudflare Pages 프로젝트라면 Astro 빌드 결과물을 그대로 배포하기 좋습니다. 신규 프로젝트라면 Cloudflare가 권장하는 Workers Static Assets 흐름도 함께 검토하세요. 어느 쪽이든 API가 필요해지면 functions 폴더 또는 Workers 쪽으로 확장할 수 있어, 처음부터 백엔드 서버를 크게 운영하지 않아도 됩니다.

문의 폼처럼 페이지와 붙어 있는 API는 Pages Functions가 편합니다. 반대로 여러 사이트에서 공통으로 쓰는 API, 예약 알림, 크론 작업, 외부 웹훅 처리처럼 독립적인 기능은 Workers로 분리하는 편이 깔끔합니다.

AI에게 구현을 맡길 때도 "이 기능은 페이지 근처 API인지, 독립 Worker인지 먼저 판단해 달라"고 시키면 폴더 구조가 덜 흐트러집니다. 작은 사이트에서는 처음에 Pages Functions로 시작하고, 반복 작업이 많아질 때 Worker로 떼어내도 늦지 않습니다.

로컬 개발에서는 .env.local 같은 파일로 값을 읽고, 운영 배포에서는 Cloudflare Pages secrets나 Worker secrets에 저장합니다. 저장소에 올라가는 설정 파일에는 실제 값이 아니라 변수 이름과 예시만 남깁니다.

AI에게 오류를 보여줄 때도 환경 변수 값이 로그에 찍히지 않았는지 먼저 확인합니다. 특히 결제 API, OpenAI API, 이메일 발송 키, Cloudflare 토큰은 한 번 유출되면 바로 폐기하고 다시 만들어야 합니다.

D1은 SQLite 기반의 Cloudflare 서버리스 데이터베이스입니다. Worker나 Pages Function에서 env.DB처럼 네이티브 바인딩으로 바로 접근하므로, 문의, 예약 신청, 포트폴리오 항목, 공지, 관리자 메모처럼 사이트 동작과 가까운 관계형 데이터에 잘 맞습니다.

다만 D1은 "작은 데이터베이스를 많이 두는" 방향으로 설계된 서비스입니다. 공식 한계 기준으로 Free는 DB당 500MB, Workers Paid는 DB당 10GB이며, 이 10GB 한계는 개별 DB에서 더 늘릴 수 없습니다. 방문 로그, 클릭 이벤트, 인기 순위 원천 로그처럼 행 수가 빠르게 늘어나는 데이터까지 모두 D1에 넣으면 비용과 스캔량 관리가 어려워집니다.

실제 운영 사이트 풋터에 보이는 Turso 병용은 그래서 중요한 단서입니다. Turso는 libSQL/SQLite 계열이라 D1과 사고방식이 비슷하지만 Cloudflare 외부 DB입니다. D1에는 사이트 핵심 메타와 작은 운영 데이터를 두고, Turso에는 누적 통계·로그·이벤트처럼 커지는 데이터를 분리하면 D1의 10GB 한계와 rows read/write 압박을 줄일 수 있습니다.

단, Turso의 Embedded Replicas는 현재 문서상 legacy 기능으로 안내되고 새 동기화 프로젝트는 Turso Sync 흐름을 보라고 되어 있습니다. Workers에서 Turso를 쓸 때도 Cloudflare 바인딩처럼 자동 연결되는 것이 아니라 URL과 토큰을 secret으로 관리하고 HTTP/SDK로 접근해야 하므로, 보완 DB라는 위치를 분명히 잡아야 합니다.

R2는 이미지, 문서, 다운로드 파일처럼 앱 코드와 분리해야 하는 파일에 적합합니다. 포트폴리오 스크린샷, 메뉴판 PDF, 고객 업로드 첨부파일, 칼럼용 원본 이미지를 R2에 두면 코드 저장소가 무거워지지 않습니다.

공개 이미지라면 CDN 캐시와 경로 규칙을 함께 설계하고, 비공개 파일이라면 서명 URL이나 서버 API를 통해 접근하게 합니다. AI에게는 버킷 이름과 폴더 규칙만 알려 주고 실제 접근 키는 secrets로 처리하게 합니다.

KV는 자주 읽고 가끔 바뀌는 값에 잘 맞습니다. 공지 노출 여부, 이벤트 배너, 기능 플래그, 외부 API 응답 캐시, 사이트 설정 같은 값은 D1보다 KV가 단순할 때가 많습니다.

다만 KV를 데이터베이스처럼 모든 주문, 예약, 결제 내역에 쓰는 것은 피하는 편이 좋습니다. 기록성과 관계가 중요한 데이터는 D1, 파일은 R2, 빠른 설정값은 KV처럼 역할을 나누면 AI가 코드를 확장할 때도 판단이 쉬워집니다.

바이브 코딩의 장점은 속도지만, 한 번에 너무 많이 맡기면 구조가 금방 흐려집니다. "전체 사이트를 만들어줘"보다 "홈 화면의 섹션 구조를 잡아줘", "문의 폼을 D1에 저장해줘", "R2 이미지 업로드 API를 설계해줘"처럼 단위를 나누면 결과가 안정적입니다.

AI에게 매번 목표, 수정 범위, 건드리지 말 파일, 실행 가능한 명령, 검증 방법을 알려 주세요. 그러면 사람은 기획과 승인에 집중하고, AI는 반복 구현과 오류 수정을 빠르게 맡을 수 있습니다.

개인 홈페이지는 자기소개가 아니라 "무엇을 도와줄 수 있는 사람인지"가 먼저 보여야 합니다. 포트폴리오는 프로젝트 이미지와 성과가 먼저고, 자영업자 사이트는 전화, 길찾기, 예약, 영업시간이 먼저입니다.

AI에게 디자인을 맡길 때도 예쁜 문장보다 사용자의 다음 행동을 명시하는 것이 좋습니다. "모바일 첫 화면에서 전화 버튼과 위치 버튼이 보여야 한다"처럼 구체적으로 말하면 결과물이 훨씬 실제 사이트에 가까워집니다.

AI가 코드를 고친 뒤에는 바로 배포하지 말고 로컬에서 dev 서버로 화면을 보고, build로 정적 산출물이 만들어지는지 확인하고, 가능하면 preview 환경까지 확인합니다. 특히 Cloudflare 바인딩은 로컬과 원격에서 차이가 날 수 있으므로, 어떤 값이 어느 환경에서 주입되는지 표로 남겨 두면 좋습니다.

오류가 나면 전체 로그를 다 붙이지 말고 처음 실패한 명령, 핵심 에러 20줄, 변경한 파일 목록을 AI에게 전달하세요. 그 정도면 대부분의 문제는 원인을 좁힐 수 있습니다.

처음 운영하는 사람에게는 GitHub 저장소를 Cloudflare에 연결해 main 브랜치가 배포되게 만드는 흐름이 편합니다. 기존 Pages 프로젝트는 Pages 설정을 그대로 쓰고, 새로 시작하는 프로젝트는 Workers Static Assets와 Wrangler 배포 흐름까지 함께 비교하면 현재 Cloudflare 방향과 더 잘 맞습니다.

중요한 것은 한 프로젝트에서 배포 루트를 섞지 않는 것입니다. GitHub 자동 배포를 쓰면 커밋 중심으로 운영하고, CLI 배포를 쓰면 어느 브랜치와 산출물을 올렸는지 로그를 남기세요. AI에게 배포를 맡길 때도 build와 deploy를 분리해 실패 지점을 알 수 있게 해야 합니다.

홈페이지가 검색에 나오려면 title, description, canonical, OpenGraph, sitemap, robots, 구조화 데이터가 필요합니다. 이 요소들은 나중에 한 번에 붙이는 것보다 공통 레이아웃과 페이지 템플릿에 넣어 두는 편이 낫습니다.

접근성은 복잡한 규칙처럼 보이지만 기본은 분명합니다. 버튼은 버튼으로 만들고, 이미지에는 대체 텍스트를 두고, 색 대비를 지키고, 모바일에서 글자가 겹치지 않게 만듭니다. AI에게도 "모바일 360px에서 텍스트 겹침을 확인해 달라"고 지시하면 좋습니다.

작은 사이트도 문의 데이터와 이미지가 쌓이면 운영 자산이 됩니다. D1 스키마 변경 기록, R2 버킷 구조, KV 키 목록, 배포 환경 변수는 문서로 남겨야 합니다. AI가 만든 설정이라도 사람이 이해할 수 있어야 유지보수가 됩니다.

비용은 서비스별 무료 한도와 실제 사용량에 따라 달라집니다. 정확한 한도와 과금 조건은 Cloudflare 대시보드와 공식 문서를 기준으로 확인하고, 알림이나 사용량 점검 루틴을 만들어 두세요.

Cloudflare 기반 사이트에서 초보자가 자주 만나는 문제는 빌드 산출물 경로, 바인딩 이름 불일치, 환경 변수 누락, CORS, 캐시, DNS 전파 지연입니다. AI에게 오류를 맡길 때는 "이 문제가 프론트, 빌드, Cloudflare 설정, 런타임 중 어디에 가까운지 먼저 분류해 달라"고 요청하세요.

문제를 고칠 때는 한 번에 하나씩 바꿉니다. DNS와 코드와 환경 변수를 동시에 바꾸면 무엇이 해결했는지 알 수 없습니다. 작은 변경, 재현, 검증, 기록의 반복이 장기적으로 가장 빠릅니다.

가격 비교는 "어디가 무조건 싸다"로 끝내면 위험합니다. Cloudflare는 Pages, Workers, D1, R2, KV가 각각 사용량 기준으로 움직이고, Vercel은 프론트 배포와 Next.js 경험이 강하며, Supabase는 Postgres, Auth, Storage, Realtime이 한 제품 경험으로 묶여 있습니다.

개인 홈페이지, 포트폴리오, 자영업자 소개 사이트처럼 정적 페이지가 많고 API가 작다면 Cloudflare가 매우 유리할 가능성이 큽니다. 반대로 로그인, 권한, 실시간 기능, 복잡한 SQL, 관리자 DB 작업이 많다면 Supabase의 통합 경험이 더 빠를 수 있고, Next.js 중심의 제품이라면 Vercel이 배포 경험에서 가장 단순할 수 있습니다.

Cloudflare에서 특히 헷갈리는 지점은 "정적 자산 요청"과 "함수 요청"이 다르게 계산된다는 점입니다. Pages의 정적 asset 요청은 무료·무제한으로 안내되지만, Pages Functions를 호출하는 순간 그 요청은 Workers 요청 한도에 들어갑니다. Free라면 하루 100,000 Workers 요청을 Pages Functions와 Workers가 함께 나눠 쓰는 식입니다.

Workers CPU도 무료와 유료를 구분해야 합니다. Free는 HTTP 요청당 10ms CPU가 기본 한도이고, Paid는 기본 30초에서 설정으로 최대 5분까지 올릴 수 있습니다. 네트워크 대기 시간 전체가 CPU로 잡히는 것은 아니지만, 이미지 처리나 큰 JSON 가공처럼 실제 계산이 많은 작업은 이 한도를 의식해야 합니다.

Cloudflare 방식의 가장 큰 단점은 "서비스가 잘게 나뉘어 있다"는 점입니다. Pages 프로젝트, Worker, D1 데이터베이스, R2 버킷, KV namespace를 각각 만들고, 그 리소스를 wrangler 설정의 binding으로 코드에 연결해야 합니다.

이 구조는 익숙해지면 깔끔하지만 처음에는 Vercel이나 Supabase보다 덜 친절하게 느껴질 수 있습니다. 특히 AI가 파일은 잘 고쳐도 Cloudflare 대시보드의 실제 리소스 ID와 로컬 설정의 바인딩 이름을 자동으로 완벽히 맞춰 주지는 못합니다.

바이브 코딩에서 편의성은 "좋은 프롬프트를 매번 새로 쓰지 않는 것"에서 나옵니다. 아래 프롬프트는 바로 복사해 쓰되, 실제 토큰이나 계정 ID는 넣지 말고 사이트 목표와 기능명만 바꿔 주세요.

중요한 점은 AI가 바로 배포 명령까지 달리지 않게 만드는 것입니다. 계획, 파일 수정, 로컬 검증, 원격 리소스 생성, production 배포를 분리하면 사고 가능성이 크게 줄어듭니다.

Vercel은 개발자가 느끼는 첫 경험을 "저장소를 연결하면 프레임워크를 알아서 배포해 주는 서비스"에 가깝게 설계했습니다. Next.js를 만든 회사답게 빌드, 라우팅, preview URL, 서버 함수, 이미지 최적화, 환경 변수, 협업 흐름이 하나의 제품 경험으로 묶여 있습니다. 그래서 초반에는 코드만 올리면 많은 일이 자동으로 처리되는 느낌이 납니다.

Cloudflare는 출발점이 다릅니다. Cloudflare는 DNS, CDN, 보안, 엣지 네트워크 위에 Workers, Static Assets, D1, R2, KV 같은 작은 인프라 부품을 올려 둔 플랫폼입니다. 따라서 "이 사이트의 정적 파일은 어디에 둘까", "문의 데이터는 D1에 둘까", "이미지는 R2에 둘까", "읽기 많은 설정은 KV가 맞을까"를 개발자가 코드와 설정으로 표현해야 합니다.

즉 Cloudflare가 복잡해 보이는 이유는 같은 일을 더 어렵게 만들어서가 아니라, Vercel이 숨겨 주는 인프라 결정을 개발자가 더 앞단에서 직접 고르게 하기 때문입니다. 이 선택권은 비용과 위치, 캐시, 런타임을 세밀하게 잡을 수 있다는 장점으로 돌아오지만, 초반에는 리소스 생성, 권한, 바인딩, 환경 분리 때문에 번거롭게 느껴집니다.

Cloudflare만으로 사이트를 운영한다는 말은 단일 제품 하나를 켠다는 뜻이 아닙니다. Workers는 계산을 담당하고, Static Assets 또는 Pages는 정적 파일을 서빙하고, D1은 관계형 데이터를 저장하고, R2는 파일을 보관하고, KV는 읽기 많은 작은 설정을 빠르게 내려줍니다. 여기에 실시간 상태가 필요하면 Durable Objects, 오래 걸리는 후처리가 필요하면 Queues, 외부 Postgres/MySQL 연결이 필요하면 Hyperdrive를 더합니다.

이 조합은 개인 홈페이지나 포트폴리오처럼 정적 페이지가 많은 사이트에서 특히 좋습니다. 먼저 Astro로 HTML 중심 화면을 만들고, 문의 폼 하나만 Worker 함수로 처리하며, 문의 내역은 D1에 넣고, 이미지 원본은 R2에 두면 됩니다. 방문자가 늘어나도 대부분의 페이지는 CDN과 정적 자산으로 빠르게 나가고, 동적 요청만 필요한 만큼 비용이 붙습니다.

여기에 도메인·DNS·SSL·WAF·캐시·봇 방어·미디어 변환·분석까지 붙으면 운영 그림이 완성됩니다. Vercel이나 Supabase가 한 제품 안에서 많은 판단을 숨겨 주는 쪽이라면, Cloudflare는 이 주변 계층까지 한 네트워크 안에서 직접 조립하는 쪽입니다.

반대로 "로그인 사용자 수가 많고, 권한이 복잡하고, Postgres 확장 기능을 많이 쓰고, 관리자 SQL 작업이 많다"면 Supabase 같은 통합 백엔드가 더 빠를 수 있습니다. Cloudflare-only는 모든 경우의 정답이 아니라, 작은 공개 사이트를 빠르게 만들고 필요한 만큼만 서버 기능을 붙이는 전략에 특히 잘 맞는 선택지입니다.

2026년 1월 16일 Cloudflare는 Astro 웹 프레임워크를 만든 The Astro Technology Company가 Cloudflare에 합류한다고 발표했습니다. Cloudflare 공식 글은 Astro를 빠른 콘텐츠 중심 웹사이트를 만드는 프레임워크로 설명하고, Cloudflare의 개발자 문서, 웹사이트, 랜딩 페이지, 블로그 같은 콘텐츠 영역에서도 Astro를 사용한다고 밝힙니다.

공식 발표에서 확인되는 것은 Astro 팀이 Cloudflare에 합류했다는 사실과 Astro가 오픈소스·MIT 라이선스·플랫폼 중립성을 유지한다는 점입니다. 거래 금액, 지분 구조, 세부 인수 조건은 공개되지 않았으므로 본문에서도 이를 추정하지 않는 편이 정확합니다.

이 인수가 중요한 이유는 프레임워크와 인프라의 궁합 때문입니다. Astro는 기본적으로 HTML을 많이 만들고 필요한 부분만 island로 하이드레이션합니다. Cloudflare는 전 세계 네트워크에서 정적 자산과 Worker 코드를 가까운 곳에서 실행합니다. 그래서 "글과 소개 페이지는 정적으로 빠르게, 문의와 관리자 기능만 동적으로"라는 이 글의 전략과 잘 맞습니다.

Cloudflare는 신규 프로젝트에 Workers Static Assets를 권장하고 있으며, Astro의 Cloudflare 어댑터도 Astro 6 흐름에서 Cloudflare 런타임과 바인딩 접근을 더 직접적으로 다룹니다. Astro 6의 새 개발 서버는 Vite Environments API를 활용해 로컬 dev 서버가 배포 런타임과 같은 API를 쓰도록 만드는 방향입니다. 즉 로컬에서 workerd, D1, KV, Durable Objects 같은 Cloudflare 문맥을 더 가깝게 재현할 수 있습니다.

경쟁 구도도 단순한 Astro 대 Next.js로 보면 좁습니다. 데이터 중심 React 앱은 Next.js와 React Router 계열이 강하고, 콘텐츠 중심 정적 사이트는 Hugo·Eleventy·Astro가 경쟁하며, island 철학으로는 Fresh·Qwik 같은 선택지도 있습니다. Cloudflare가 Hono 같은 도구도 후원하고 여러 프레임워크 어댑터를 제공한다는 점을 보면, Astro 합류는 전체 프레임워크 락인이라기보다 콘텐츠 중심 사이트의 기본 경로를 확보한 사건에 가깝습니다.

Cloudflare 서비스와 Wrangler 명령은 계속 업데이트됩니다. 그래서 이 글의 명령은 실전 흐름을 이해하기 위한 기준으로 보고, 실제 실행 전에는 공식 문서와 현재 프로젝트의 package.json, wrangler 설정을 함께 확인해야 합니다.

좋은 바이브 코딩은 AI에게 모든 결정을 넘기는 일이 아닙니다. 좋은 질문으로 작업을 작게 나누고, 민감한 권한은 사람이 잡고, 반복 구현과 검증을 AI에게 맡기는 협업 방식입니다. 그렇게 하면 개인 홈페이지든 포트폴리오든 작은 매장 사이트든 훨씬 빠르게 실제 공개까지 갈 수 있습니다.

D1은 Cloudflare Workers와 가장 자연스럽게 붙는 SQL DB이지만, "내 PC의 SQLite 파일처럼 계속 열어 보고 원격과 자동 동기화되는 DB"라고 생각하면 금방 막힙니다. Wrangler 로컬 개발의 D1은 production 원격 D1과 분리된 로컬 전용 상태이고, 원격 운영 데이터에 접근하려면 의도적으로 remote 흐름을 써야 합니다.

공식 문서도 로컬 개발 세션이 production 데이터를 기본으로 보지 않는다고 설명합니다. 그래서 바이브 코딩으로 작업할 때는 AI에게 "D1 명령은 항상 `--local` 또는 `--remote`를 명시하라"고 지시하는 편이 안전합니다. 같은 database_name을 쓰더라도 로컬과 원격은 내용물이 다를 수 있습니다.

로컬과 원격 사이의 이동도 "동기화"라기보다 export/import 스냅샷에 가깝습니다. 원격을 SQL 파일로 내보내고 로컬에 적용하거나, 로컬 덤프를 원격에 적용할 수는 있지만, 양쪽에서 동시에 바뀐 값을 자동으로 충돌 해결해 주지는 않습니다. 운영 DB에 적용할 때는 백업, dry-run, 적용 범위 확인이 먼저입니다.

또 하나의 현실적인 불편은 원격 D1을 표준 SQLite GUI처럼 바로 열기 어렵다는 점입니다. Cloudflare 대시보드 콘솔, Wrangler 명령, HTTP API, 별도 프록시나 커뮤니티 도구를 써야 합니다. 로컬 `.wrangler` 아래의 SQLite 파일을 GUI로 볼 수는 있지만, 그것은 운영 DB가 아니라 로컬 개발 상태입니다.

상시 수집·크롤링·방문 로그처럼 행이 계속 쌓이는 워크로드도 D1 단독으로 밀어 넣기 전에 멈춰 봐야 합니다. D1은 rows read/write 단위로 비용과 무료 한도가 움직이고, DB당 10GB 한계도 있습니다. 문의·예약·사이트 메타처럼 작고 중요한 데이터에는 좋지만, 원시 로그와 장기 통계는 Turso, Analytics Engine, R2 아카이브 같은 별도 경로가 더 안전할 때가 많습니다.

Turso는 D1의 모든 대체재라기보다 D1이 불편한 지점을 보완하는 SQLite/libSQL 계열 선택지로 이해하면 쉽습니다. 특히 로컬 데스크톱에서 상시 수집기를 돌리고, 그 데이터를 GUI로 확인하면서, 사이트의 Workers API에서도 같은 원격 DB를 읽어야 하는 경우에 빛납니다.

Turso 임베디드 레플리카는 로컬 파일과 원격 primary를 연결합니다. 읽기는 로컬 파일에서 처리되고, 기본 쓰기는 원격 primary로 전송된 뒤 성공하면 로컬 파일에 반영됩니다. 그래서 내가 방금 쓴 값은 바로 읽을 수 있고, 다른 PC나 Workers가 쓴 값은 `client.sync()` 또는 `syncInterval`을 통해 로컬로 가져옵니다.

이 구조 덕분에 데탑 수집기는 빠르게 로컬 DB를 읽고, 원격 Turso에는 사이트에서 볼 수 있는 최신 운영 데이터가 쌓입니다. 다만 Turso 문서는 embedded replicas를 기존 libSQL 기반 기능으로 설명하면서, 새 sync 프로젝트에는 Turso Sync를 검토하라고 안내합니다. 따라서 새 프로젝트에서는 공식 문서의 현재 권장 경로를 함께 확인해야 합니다.

Cloudflare Workers에서는 임베디드 레플리카를 그대로 쓸 수 없습니다. Workers는 지속 파일 시스템이 없기 때문입니다. 사이트 측 코드는 `@libsql/client/web`로 Turso 원격 URL에 연결하고, `TURSO_DATABASE_URL`, `TURSO_AUTH_TOKEN`은 Wrangler secret으로 넣습니다. 이 차이를 모르면 로컬 수집기 코드를 Worker에 그대로 붙였다가 런타임에서 깨질 수 있습니다.

운영 분담은 단순하게 잡는 것이 좋습니다. D1에는 문의, 예약, 앱 카탈로그, 사이트 설정처럼 Worker와 가까워야 하는 핵심 데이터를 둡니다. Turso에는 방문 로그, 이벤트, 크롤링 결과, 원천 통계처럼 로컬 분석과 누적 행 증가가 중요한 데이터를 둡니다. R2는 파일, KV는 캐시와 설정입니다.