CLOUDFLARE-FIRST GUIDE 2026 Astro + Pages + Workers + D1·R2·KV Vibe Coding 실전 워크플로우

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

처음부터 거대한 서비스를 만들지 않습니다. 호스팅, API, DB, 이미지 저장소, 캐시, 도메인, SSL을 한 곳에서 다루는 Cloudflare-first 흐름으로 공개 페이지를 먼저 빠르게 올리고, 진짜 필요한 기능만 Workers · D1 · Turso · R2 · KV로 하나씩 붙이는 실전 바이블입니다. AI에게는 반복 작업과 설정 초안을 맡기되, 계정 권한과 비밀값은 사람이 통제합니다.

정적 자산 & 프론트

Astro + Pages

정적 파일 무료·무제한급 빠른 배포

데이터·스토리지 분담

D1 · R2 · KV

운영 DB · Egress 무료 파일 · 빠른 플래그

안전한 AI 위임

권한 분리 루프

계획 → 파일 수정 → 로컬 검증 → 배포 승인

CLOUDFLARE EDGE TOPOLOGY — Astro + Pages/Workers + Bindings ● Edge Connected

[읽기 전에] 안전 원칙 & 실행 기준

실제 비밀값, 계정 ID, 결제 정보, 운영 토큰은 절대 채팅에 공개하지 않습니다. 모든 명령 실행 전 package.json, wrangler 설정, 공식 문서를 함께 확인하세요.

1. Pages / Assets 정적 HTML·CSS·이미지를 CDN에서 즉시 응답

2. Functions/Workers 문의 폼, 예약, 웹훅, API를 서버리스 처리

3. D1 + Turso 핵심 메타는 D1, 누적 이벤트 로그는 Turso

4. R2 + KV 원본/첨부파일은 R2, 배너·설정 캐시는 KV

전체 가이드 22개 핵심 섹션 로드맵 19장 완결 구성

Part 1 (01~04p): Cloudflare Stack Map(11종), 새 기준(01), 사이트 범위 및 전환 목표(02·13)
Part 2 (05~07p): 도메인·DNS·SSL(03), Wrangler CLI(04), AI 권한 위임(05), Astro·Functions·비밀값(06~08)
Part 3 (08~11p): D1·Turso 운영 데이터 분담(09), R2 파일·KV 캐시(10~11), 인터랙티브 아키텍처 매퍼
Part 4 (12~16p): 바이브 코딩 루프·검증·배포·품질·운영·트러블슈팅(12~18), 가격·단점·딸깍 프롬프트·철학(19~22)
Part 5 (17~19p): 실무 이점 — 무료·$5 시작점, 워드프레스 없이, D1·CDN·DDoS·원가 도메인·R2, PayPal·요금 알림·분석·보안 메일

02 · CLOUDFLARE STACK MAP

이 글에서 쓰는 Cloudflare · 보완 서비스 11종 한눈에 보기

필수 Cloudflare 서비스와 Turso 같은 보완 서비스를 먼저 구분해 두면 D1, R2, KV, Workers 바인딩 설명이 훨씬 쉽게 읽힙니다

필수 4종 · 데이터/보완 4종 · 확장 3종

필수 코어 4종 & 확장 서비스 3종 Core & Scale

구분	서비스	역할 및 쓰는 곳	핵심 특징
필수	Workers	서버 코드·API 실행 (문의 폼, SSR, 웹훅, 외부 API 중계)	글로벌 엣지 서버리스 런타임. Node 전용 파일시스템 패키지 주의
필수	Static Assets / Pages	정적 사이트 배포 (홈, 소개, 포트폴리오, 칼럼, 매장 안내)	HTML/CSS/JS를 CDN 배포. 기존 Pages 유지, 신규는 Static Assets 검토
필수	Wrangler CLI	생성·설정·배포 리모컨 (로그인, 리소스 생성, 로컬·배포)	AI가 명령을 제안하고 사람이 승인하는 루프의 핵심 도구
필수	Bindings & Secrets	코드와 리소스 연결 (`env.DB`, `env.MEDIA`, 비밀값)	이름 불일치 시 배포 후 런타임에서 깨지므로 표로 엄격 관리
확장	Durable Objects	상태 저장 조정 계층 (채팅방, 협업 편집, 실시간 방, 락)	특정 ID 상태를 단일 객체로 모음. 실시간 기능 필요 시 도입
확장	Queues / Hyperdrive	비동기 작업 큐(메일·후처리) / 외부 Postgres·MySQL 가속	오래 걸리는 작업을 뒤로 넘기거나 Supabase·Neon 연결 시 활용

데이터 · 파일 · 캐시 · 보완 서비스 4종 Data & Storage

구분	서비스	이 글에서 쓰는 곳	핵심 특징 및 운영 포인트
필요 시	D1	문의, 예약, 게시글 메타데이터, 포트폴리오 항목, 작은 CRM	SQLite 계열 서버리스 DB. rows read/write와 인덱스 설계가 비용·성능 직결
운영 보완	Turso	방문 로그, 이벤트 누적, 통계 집계처럼 빠르게 늘어나는 데이터	외부 libSQL/SQLite 계열. 네이티브 바인딩 대신 HTTP/SDK와 secret 관리 필요
필요 시	R2	이미지 원본, 첨부파일, PDF, 다운로드 자료, 백업 파일	S3 호환 오브젝트 저장소. 인터넷 Egress 무료가 강점, 공개/비공개 정책 설계
필요 시	KV	공지 배너, 기능 플래그, 리다이렉트, 읽기 많은 설정값	자주 읽고 가끔 바뀌는 값에 최적. 결과적 일관성이므로 결제·재고 원본은 지양

💡 핵심 구분: 기록·관계가 중요한 운영 데이터는 D1, 누적 로그는 Turso, 파일은 R2, 빠른 설정값은 KV로 역할을 나눕니다.

03 · SECTION 01 — NEW STANDARD (CLOUDFLARE-FIRST)

01 새 기준 — 이전 스택(Next.js·Vercel·Supabase)과 다른 Cloudflare-First 제작 기준

콘텐츠 페이지는 Astro로 빠르게 정적 생성하고, 진짜 필요한 부분만 Workers · D1 · R2 · KV로 하나씩 확장합니다

Astro + Pages + Functions

왜 개인·스몰 비즈니스에서 Cloudflare-first가 편해졌는가? 통합 인프라

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

ARCHITECTURE SHIFT — Multi-Vendor vs Cloudflare-First 비교 뷰

이전 다중 플랫폼 조합 • 프론트 배포: Vercel
• DB/스토리지: Supabase
• 도메인/CDN: 별도 관리
→ 계정·과금·권한이 3곳으로 분산

2026 Cloudflare-First 기준 • Astro 정적 빌드 + Pages/Static Assets
• Functions/Workers + D1 + R2 + KV
• 도메인·DNS·SSL·캐시 단일 대시보드
→ 필요한 기능만 점진적으로 연결

핵심 관점: "공개 페이지를 먼저, 기능은 하나씩 붙인다" 4대 역할 분담 원칙

처음부터 거대한 서비스를 만들지 않습니다. 공개 페이지를 먼저 만들고, 진짜 필요한 기능만 Cloudflare 서비스로 하나씩 붙이는 것이 바이브 코딩과 가장 잘 맞습니다.

1. 정적 페이지 → Pages / Static Assets

홈, 소개, 칼럼, 안내 등 읽는 페이지는 정적 HTML로 만들어 CDN에서 가장 빠르게 제공합니다.

2. 문의·예약·작은 API → Pages Functions / Workers

폼 제출, 알림 발송, 검증처럼 서버 처리가 꼭 필요한 지점만 가볍게 서버리스로 붙입니다.

3. 게시글·신청 내역·포트폴리오 → D1

사이트 동작과 밀접한 구조화 데이터는 SQLite 기반 서버리스 DB인 D1에 저장합니다.

4. 이미지·파일은 R2 / 설정·플래그는 KV

용량이 큰 미디어는 R2로 코드 저장소와 분리하고, 자주 읽는 배너·설정값은 KV에 둡니다.

04 · SECTION 02 & 13 — SITE SCOPE & CONVERSION TEMPLATES

02 대상 정하기 & 13 첫 화면 템플릿 — 방문자의 '다음 행동'을 한 문장으로 정의하라

AI에게 "홈페이지 만들어줘"라고만 말하면 예쁜 화면만 나옵니다. 전환 목표에 맞춘 4대 사이트 유형별 필수 설계

전환 목표 우선 설계

유형 01 · 개인 홈페이지

누구인지 5초 안에 전달

단순 자기소개가 아니라 "무엇을 도와줄 수 있는 사람인지"가 첫 화면에 먼저 보여야 합니다.

Personal Hub Layout

[초기 필수 기능]

• 한 줄 가치 제안 & 소개
• 대표 글/칼럼 목록
• 연락처 & 소셜 링크 허브

→ 추후 뉴스레터·자료실 확장

목표: 글을 읽고 뉴스레터·연락 신청

유형 02 · 포트폴리오

대표 작업물을 바로 확인

프로젝트 이미지와 실제 성과 수치가 먼저 보이고, 바로 의뢰·문의로 이어져야 합니다.

Portfolio Showcase

[핵심 전환 흐름]

• 프로젝트 카드 & 상세 과정
• 사용 기술 스택 & 성과 수치
• 하단 즉시 문의 폼 (D1 연동)

→ 고화질 스크린샷은 R2 보관

목표: 내 작업물을 보고 연락하게 한다

유형 03 · 자영업자 사이트

방문 · 예약 · 문의로 직결

모바일 첫 화면에서 전화, 길찾기, 예약, 영업시간을 헤매지 않고 바로 찾게 합니다.

Local Biz Mobile First

[모바일 첫 화면 필수]

• 전화 걸기 & 위치 길찾기 버튼
• 영업시간 · 메뉴판(R2 PDF)
• 예약 폼 · 리뷰 · 자주 묻는 질문

→ 임시 휴무 공지는 KV 배너로

목표: 매장 정보 확인 후 즉시 예약

유형 04 · 작은 웹앱

한 가지 문제를 바로 해결

계산기, 신청 폼, 예약 확인, 간단한 관리자 화면처럼 단일 작업 완결에 집중합니다.

Micro WebApp Flow

[핵심 기능 구성]

• 직관적인 입력 폼 & 계산 UI
• 처리 결과 D1 저장
• 분리된 관리자 확인 라우팅

→ Astro + React 아일랜드 조합

목표: 입력 → 즉시 계산/저장 완료

05 · SECTION 03 & 04 — DOMAIN · DNS · SSL & WRANGLER CLI

03 도메인·DNS·SSL 안정화 & 04 Wrangler CLI 작업 리모컨

기존 메일(MX/TXT) 레코드 보호 원칙과 AI가 제안하고 사람이 승인해 실행하는 Wrangler 터미널 루틴

초반 인프라 안전 수칙

03. 도메인 · DNS · SSL 초반 연결 안정화 DNS 사고 예방

Cloudflare에서 도메인을 관리하면 DNS, SSL, 캐시, 보안을 같은 대시보드에서 확인합니다. AI에게 DNS를 맡길 때는 화면을 직접 조작하게 하지 말고 현재 레코드를 사람이 확인한 뒤 추가할 레코드 계획만 제시하게 하세요.

루트 & 서브도메인 결정: 루트 도메인(example.com)과 www 서브도메인을 모두 쓸지 초반에 정합니다.
기존 메일·인증 레코드 절대 보존: 기존에 사용 중인 MX, TXT, SPF, DKIM 레코드는 메일과 도메인 인증에 연결되어 있으므로 무심코 삭제하면 안 됩니다.
SSL 모드 점검: SSL은 기본값으로 시작하되, 외부 원본 서버가 따로 있다면 SSL 모드를 다시 확인합니다. Universal SSL 알림은 전 플랜에서 발급·갱신·만료를 메일로 받을 수 있습니다.
도메인 구입: Registrar는 레지스트리·ICANN 원가만 청구하고 마크업이 없습니다. TLD마다 금액이 달라 단일 가격으로 적지 않습니다. 자동 갱신이 기본입니다.
임시 주소 선행 QA: 커스텀 도메인으로 공개하기 전에 기본 제공되는 임시 .pages.dev 주소로 먼저 QA를 마칩니다.

⚠️ 주의: 기존 블로그·메일·서브도메인이 연결된 도메인은 레코드 삭제 전 반드시 백업하세요.

04. Wrangler CLI — Cloudflare 작업 리모컨 승인 기반 실행

Wrangler는 Workers, Pages, D1, R2, KV를 터미널에서 만들고 배포하는 CLI입니다. AI가 "어떤 명령을 왜 실행해야 하는지" 먼저 설명하고, 사용자가 승인한 명령만 실행하는 루틴을 만드세요.

            # 1. 로그인 계정 및 권한 먼저 확인

            $ npx wrangler whoami

            # 2. 로컬 빌드가 완전히 통과한 뒤에만 원격 배포 실행

            $ npm run build && npx wrangler pages deploy ./dist

이름 규칙 일관성: 프로젝트 이름, DB 이름, 버킷 이름은 나중에 바꾸기 어렵기 때문에 처음부터 짧고 일관되게 정합니다.
비용·충돌 사전 확인: 원격 리소스를 생성하는 명령은 비용, 이름 충돌, 권한 문제와 직결되므로 계획을 먼저 확인합니다.
오류 전달 시 마스킹: 명령 실패 메시지는 AI에게 그대로 전달하되 토큰, 이메일, 내부 계정 ID는 반드시 가리고 전달합니다.

06 · SECTION 05 & 08 — AI PERMISSION & SECRETS GOVERNANCE

05 AI 권한 위임 & 08 비밀값 관리 — "비밀값과 파괴적 명령은 맡기지 않는다"

"모두 설정해줘"는 데이터 삭제와 배포 변경까지 열어줄 수 있습니다. AI와 사람의 역할 경계를 명확히 분리하세요

보안 최우선 수칙

05. AI에게 맡길 일 vs 사람이 직접 통제할 일 최소 권한 원칙

구분	담당 주체	구체적인 작업 범위
AI 위임 가능	AI 코딩 파트너	구조 계획 수립, 코드/설정 파일 수정, 실행할 CLI 명령 제안, 에러 로그 원인 분석
사람 직접 통제	사용자 (승인자)	Cloudflare 로그인, API 토큰 생성, 결제 정보, 리소스 삭제·purge, 운영 DB migration, 프로덕션 배포

최소 권한 토큰: API 토큰은 꼭 필요한 서비스와 계정 범위만 가진 최소 권한으로 생성합니다.
변수명만 공유: AI에게는 실제 토큰 값 대신 CLOUDFLARE_API_TOKEN 같은 변수 이름만 알려줍니다.
작업 후 즉시 정리: 삭제, purge, 원격 migration, production deploy는 실행 전 계획을 먼저 받고, 작업이 끝나면 임시 토큰을 폐기하거나 권한을 줄입니다.

08. 환경 변수·바인딩: local · preview · production 맞추기 3단계 환경 분리

로컬 개발에서는 .env.local로 읽고, 운영 배포에서는 Cloudflare Pages secrets나 Worker secrets에 저장합니다. Git 저장소에는 실제 값이 아닌 변수 이름과 예시만 남깁니다.

            # .env.example (Git 커밋 허용 — 설명과 키 이름만 기록)

            PUBLIC_SITE_URL="https://example.com"

            RESEND_API_KEY="" # 서버 전용: 대시보드/Wrangler secret으로 등록

            TURSO_AUTH_TOKEN="" # 절대 클라이언트에 노출 금지

클라이언트 vs 서버 전용 구분: 브라우저에 노출되는 변수와 서버(Functions/Workers) 전용 변수를 엄격히 분리합니다.
로그 마스킹: 로그에는 요청 본문 전체나 환경 변수 값이 아니라 필요한 상태와 오류 코드만 남깁니다.
유출 시 즉시 폐기: 결제 API, OpenAI API, 이메일 발송 키, Cloudflare 토큰은 한 번이라도 노출되면 즉시 폐기 후 재발급합니다.

07 · SECTION 06 & 07 — ASTRO SKELETON & FUNCTIONS VS WORKERS

06 Astro 콘텐츠 골격 & 07 Functions · Workers 서버 코드 위치 나누기

읽는 페이지는 정적 Astro로 가볍게 만들고, 상호작용 UI는 React 아일랜드로, 백엔드는 위치에 따라 Functions와 Workers로 분담합니다

프론트·서버리스 황금 비율

06. Astro + Cloudflare 배포 골격 아일랜드 아키텍처

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

기존 vs 신규 배포 흐름: 기존 Pages 프로젝트는 Astro 빌드 결과물을 그대로 배포하고, 신규 프로젝트는 Cloudflare가 권장하는 Workers Static Assets 흐름도 함께 검토합니다.
초기 템플릿화: 공통 레이아웃, SEO, OpenGraph, 사이트맵은 처음부터 템플릿화합니다.
정적 자산 경로 정리: 이미지, 폰트, 썸네일 경로는 public 또는 R2 기준으로 일관되게 정리합니다.
관리자 라우팅 분리: 관리자 기능은 공개 페이지와 라우팅을 분리해 보안 및 운영 사고를 줄입니다.

07. Pages Functions vs 독립 Workers 선택 기준 서버 코드 위치 판단표

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

구현할 기능	추천 위치	선택 이유
문의 폼 저장	Pages Functions	페이지와 입력 UI가 바로 붙어 있어 함께 관리하기 편함
이미지 업로드 서명	Pages Functions / Worker	R2 쓰기 권한과 서명 키를 서버 쪽에 안전하게 숨겨야 함
정기 리포트 · 크론	독립 Worker	Cron Triggers 스케줄과 백그라운드 비동기 작업에 적합
공통 API 게이트웨이	독립 Worker	여러 사이트나 프론트엔드 프로젝트에서 공통으로 재사용 가능

08 · SECTION 09 — D1 & TURSO OPERATIONAL DATA DIVISION

09 D1 · Turso 운영 데이터 분담 — 왜 D1 단독이 아니라 Turso를 병용하는가?

D1의 DB당 10GB 한계와 rows 스캔 비용을 방어하기 위해 핵심 메타는 D1에, 누적 이벤트 로그는 Turso로 분리합니다

Free 500MB / Paid 10GB 한계 대비

D1의 강점과 명확한 물리적 한계 SQLite 서버리스 DB

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

⚠️ 반드시 알아야 할 D1 공식 한계

D1은 "작은 DB를 많이 두는" 방향의 서비스입니다. Free는 DB당 500MB, Workers Paid는 DB당 10GB이며, 이 10GB 한계는 단일 DB에서 더 늘릴 수 없습니다. 방문 로그·클릭 이벤트·인기 순위 원천 로그까지 모두 D1에 넣으면 비용과 스캔량 관리가 급격히 어려워집니다.

초기 필수 컬럼: created_at, updated_at, status 컬럼을 초반부터 둡니다.
소프트 삭제: 물리적 DELETE 대신 archived나 status 값을 쓰면 실수 복구가 쉽습니다.
인덱스 & 사전 검증: 관리자 검색 컬럼에는 인덱스를 추가하고, 원격 migration 전 로컬/preview에서 먼저 검증합니다.

CDB형 사이트 기준: D1 + Turso 하이브리드 분담 장기 운영 안전 설계

실제 운영 사이트 풋터에 보이는 Turso 병용이 바로 이 때문입니다. Turso는 외부 libSQL/SQLite 계열이라 D1과 SQL 사고방식이 비슷하면서도 누적 통계·로그·이벤트 부담을 완벽히 덜어줍니다.

DATA ROUTING — D1 (Core Meta) vs Turso (Event Logs) Hybrid SQLite

Cloudflare D1 (네이티브 바인딩) • 칼럼·앱 카탈로그·관리자 설정
• 문의 내역·예약 신청·세션
• env.DB로 즉시 접근

Turso / Analytics Engine (보완) • 전체 방문·오늘 방문·인기 앱 순위
• 빠르게 행 수가 늘어나는 원천 로그
• URL·토큰을 Secret 보관 후 HTTP/SDK 연결

※ 참고: Turso의 Embedded Replicas는 현재 문서상 legacy 기능으로 안내되며, 신규 동기화는 Turso Sync 흐름을 권장합니다.

09 · SECTION 10 & 11 — R2 OBJECT STORAGE & KV CONFIG/CACHE

10 R2 이미지·첨부파일 보관 & 11 KV 가벼운 설정·캐시 — 4대 저장소 완벽 비교

파일 원본은 Egress 무료인 R2에, 자주 읽는 공지 배너와 플래그는 KV에 두어 D1과 코드 저장소를 가볍게 유지합니다

D1 · Turso · R2 · KV 역할 분담표

10. R2 — 이미지와 첨부파일 보관 Egress 무료

이그레스: 공식 표기는 전 스토리지 클래스 Egress (data transfer to Internet): Free. Infrequent Access는 이그레스와 별도로 데이터 조회 요금이 있습니다.
접두어 규칙: public/, original/, upload/, backup/ 같은 폴더 규칙을 정합니다.
최적화 & 검증: 업로드 시 WebP·AVIF·썸네일 생성 여부를 정하고, 사용자 파일은 확장자와 MIME 타입을 서버에서 검증합니다.
안전한 접근: 공개 이미지는 CDN 캐시와 연결하고, 비공개 파일은 서명 URL이나 서버 API로 접근하며 삭제 시 확인 단계를 둡니다.

11. KV — 가벼운 설정과 빠른 캐시 읽기 특화

적합한 용도: 공지 노출 여부, 이벤트 배너, 기능 플래그, 외부 API 응답 캐시 등 자주 읽고 가끔 바뀌는 값에 씁니다.
원본 저장 금지: 모든 주문·예약·결제 내역 원본은 D1에 저장하고 KV에는 복사본이나 캐시만 둡니다 (만료 시간·갱신 조건 명시).
네임스페이스 분리: preview와 production namespace를 반드시 분리합니다.

4대 저장소(D1 · Turso · R2 · KV) 운영 분담 총정리표 아키텍처 기준표

저장소	핵심 역할	넣기 좋은 데이터	운영 주의점
D1	Cloudflare 바인딩 운영 핵심 DB	문의, 예약, 사이트 메타, 앱 카탈로그, 관리자 설정, 세션	DB당 크기 한계(10GB)와 rows read/write 비용 확인, 인덱스 없는 전체 스캔 방지
Turso	D1 한계를 보완하는 외부 libSQL DB	방문 로그, 이벤트 누적, 인기 순위 원천 데이터, 사용자별 집계	네이티브 바인딩 아님 → URL·토큰 secret 관리, 네트워크 지연·장애 분리 고려
R2	파일과 큰 바이너리 원본 저장소	이미지 원본, 생성 이미지 결과물, ZIP 다운로드, PDF, 백업 파일	DB에는 파일 경로와 메타데이터만 두고 실제 바이너리 파일은 R2에 분리 보관
KV	빠른 읽기 캐시와 설정 저장소	공지 배너, 기능 플래그, 자주 읽는 인기 목록 캐시, 리다이렉트 맵	결과적 일관성(Eventual Consistency)이므로 예약·결제·원본 로그 저장소로 사용 금지

10 · INTERACTIVE CLOUDFLARE ARCHITECTURE & BINDING STUDIO

실전 시뮬레이터 — 사이트 유형과 기능을 클릭해 최적의 바인딩 설정을 조합해 보세요!

버튼을 누르면 선택한 시나리오에 맞는 Cloudflare 서비스 조합과 wrangler.toml 바인딩 계약이 실시간으로 생성됩니다

직접 클릭해 보는 바인딩 스튜디오

SIMULATOR — Scenario: 포트폴리오 + 문의 폼 + 고화질 작업물 ● Binding Ready

Astro 정적 페이지 + Pages Functions + D1(문의) + R2(포트폴리오 이미지)

작업물 목록은 Astro 정적으로 빠르게 보여주고, 고해상도 이미지와 PDF는 R2(env.MEDIA)에 분리합니다. 고객 문의 폼 제출 시 Pages Functions가 D1(env.DB)에 안전하게 기록합니다.

프론트엔드 Astro Static + React Island

서버리스 API Pages Functions (/functions/api)

데이터베이스 Cloudflare D1 (env.DB)

파일 / 캐시 R2 (env.MEDIA) + KV (env.SITE_FLAGS)

# wrangler.toml 런타임 바인딩 계약 예시 (코드의 env 이름과 100% 일치 필수)
name = "my-cloudflare-site"
pages_build_output_dir = "./dist"

[[d1_databases]]
binding = "DB"
database_name = "site-core-db"
database_id = "xxxx-xxxx-xxxx" # local / preview / prod 분리 관리

[[r2_buckets]]
binding = "MEDIA"
bucket_name = "site-public-media"
              

시나리오 & 기능 선택 컨트롤러 Interactive

아래 버튼을 눌러 4가지 사이트 유형과 데이터/스토리지 시나리오별 최적의 Cloudflare 구성을 확인하세요.

① 사이트 유형 시나리오 선택

② 환경 분리 점검 포인트

바인딩 이름 = 런타임 계약: wrangler.toml의 binding = "DB"와 코드의 env.DB가 글자 하나라도 다르면 배포 후 런타임 오류가 발생합니다.
3대 환경 ID 분리: local, preview, production 각각의 database_id와 KV namespace id를 문서 표로 남겨 관리합니다.

11 · SECTION 12 & 14 — VIBE CODING LOOP & LOCAL VERIFICATION

12 바이브 코딩 프롬프트 루프 & 14 로컬 검증 (dev · build · preview 반복)

한 번에 전체 사이트를 시키지 말고 기능 단위로 쪼개어 [계획 → 수정 → 검증] 3단계 루프로 진행합니다

계획 → 파일 수정 → 로컬 검증

❌ 실패하는 한 방 프롬프트 vs ⭕ 기능 단위 3단계 루프 12. 바이브 코딩 루프

❌ 나쁜 지시 (구조 붕괴 위험) "Cloudflare로 예약이랑 게시판이랑 관리자 다 되는 홈페이지 통째로 만들어서 바로 배포해줘!"

⭕ 좋은 지시 (단위 분할 + 범위 통제) "1단계로 홈 화면의 섹션 구조와 수정할 파일 목록만 계획해줘. 기존 공통 레이아웃·버튼·SEO 컴포넌트를 먼저 찾아 재사용하고, 건드리지 말 파일은 유지해줘."

3단계 분리 요청: 첫 번째 요청은 계획만, 두 번째 요청은 파일 수정, 세 번째 요청은 검증으로 나눕니다.
패키지 설치 통제: 새 패키지를 설치하기 전에는 왜 필요한지 먼저 설명하게 합니다.
작업 후 요약 의무화: 작업이 끝나면 변경 파일, 테스트 결과, 남은 위험을 요약하게 합니다.

14. 로컬 검증: dev · build · preview 반복 루틴 배포 전 필수 관문

AI가 코드를 고친 뒤 바로 운영 배포하지 마세요. 특히 Cloudflare 바인딩은 로컬과 원격에서 차이가 날 수 있으므로 어느 환경에서 어떤 값이 주입되는지 표로 관리합니다.

            # Step 1. 개발 서버에서 UI 및 화면 동작 확인

            $ npm run dev

            # Step 2. 정적 산출물(dist)이 오류 없이 만들어지는지 확인

            $ npm run build

            # Step 3. 바인딩이 필요한 API는 Wrangler 로컬/프리뷰로 검증

            $ npx wrangler pages dev ./dist

에러 전달 압축 기술: 오류가 나면 전체 로그를 다 붙이지 말고 ① 처음 실패한 명령, ② 핵심 에러 20줄, ③ 방금 변경한 파일 목록만 AI에게 전달하세요.
Production 배포는 마지막 1회: npm run build와 preview 검증이 모두 끝난 뒤 마지막 한 번만 실행하는 습관을 만듭니다.

12 · SECTION 15 & 16 — DEPLOYMENT PIPELINE & PUBLIC QUALITY

15 배포 흐름 (GitHub vs CLI) & 16 공개 품질 (SEO · 접근성 · 성능 기본값)

한 프로젝트에서 배포 루트를 섞지 않는 원칙과 검색 노출·모바일 가독성을 보장하는 공개 체크리스트

배포 일관성 & SEO 기본기

15. 배포 흐름: GitHub 자동 배포 또는 CLI 중 하나로 통일 배포 루트 단일화

처음 운영하는 분에게는 GitHub 저장소를 연결해 main 브랜치가 자동 배포되게 만드는 흐름이 편합니다. 신규 프로젝트는 Workers Static Assets와 Wrangler 배포 흐름까지 함께 비교하세요.

배포 루트 혼용 금지: GitHub 자동 배포를 쓰면 커밋 중심으로 운영하고, CLI 배포를 쓰면 어느 브랜치와 산출물을 올렸는지 로그를 남깁니다.
Build와 Deploy 분리: AI에게 배포를 맡길 때도 build와 deploy를 분리해 어디서 실패했는지 즉시 알 수 있게 합니다.
배포 설정 명문화: 빌드 명령, 출력 폴더(예: dist), Node 버전, 환경 변수를 배포 설정에 명확히 기록합니다.
Preview → Production 승격: preview 브랜치에서 먼저 확인한 뒤 production 브랜치로 합치고, 커스텀 도메인 연결 후 canonical URL과 사이트맵을 점검합니다.

16. 공개 품질: SEO · 접근성 · 모바일 360px 기본값 검색 색인 & UX

검색에 잘 노출되려면 title, description, canonical, OpenGraph, sitemap, robots, 구조화 데이터를 나중에 붙이지 말고 처음부터 공통 레이아웃과 페이지 템플릿에 내장해야 합니다.

검색 최적화 (SEO)

• 모든 페이지마다 고유한 title과 description 부여
• 색인 요청 전 sitemap과 canonical URL이 실제 공개 도메인 주소를 가리키는지 확인
• 배포 후 OpenGraph 공유 미리보기 점검

접근성 & 모바일 품질

• 버튼은 <button>으로, 이미지에는 의미 있는 대체 텍스트(alt) 부여 (흐릿한 장식 이미지 지양)
• Lighthouse 접근성 경고 확인
• AI에게 "모바일 360px에서 텍스트 겹침을 확인해 달라"고 지시

13 · SECTION 17 & 18 — OPERATIONS HABITS & TROUBLESHOOTING MATRIX

17 운영 습관 (백업·로그·비용) & 18 문제 해결 — 연결 지점부터 하나씩 좁히기

AI가 만든 설정이라도 사람이 이해할 수 있게 문서화하고, 장애 발생 시 DNS·코드·환경변수를 동시에 바꾸지 않습니다

운영 자산 보호 & 빠른 복구

17. 장기 운영을 지키는 4대 습관 유지보수 기준

작은 사이트도 문의 데이터와 이미지가 쌓이면 소중한 운영 자산이 됩니다. D1 스키마 변경 기록, R2 버킷 구조, KV 키 목록, 배포 환경 변수는 반드시 문서로 남겨야 합니다.

DB 마이그레이션 이력화: 운영 DB migration 파일명에는 날짜와 목적을 명확히 남깁니다.
R2 보관 주기 설정: R2 원본 파일은 삭제 정책과 백업 주기를 미리 정해 둡니다.
개인정보·토큰 로그 배제: 운영 로그에는 고객 개인정보와 인증 토큰을 절대 남기지 않습니다.
월간 정기 점검 루틴: 월 1회 사용량(무료 한도/과금), 오류 로그, 검색 노출, 문의 전환율을 점검합니다.

18. 자주 만나는 문제 4대 증상별 진단표 한 번에 하나씩 변경

AI에게 오류를 맡길 때는 "이 문제가 프론트, 빌드, Cloudflare 설정, 런타임 중 어디에 가까운지 먼저 분류해 달라"고 요청하세요. 작은 변경 → 재현 → 검증 → 기록의 반복이 가장 빠릅니다.

발생 증상	가장 먼저 볼 곳	AI에게 전달할 핵심 정보
배포는 됐는데 404	빌드 출력 폴더와 라우팅 설정	빌드 명령, `dist` 폴더 구조, Pages 빌드 출력 설정값
API에서 DB 오류	D1 바인딩 이름 일치 여부	`wrangler` 설정 파일, 해당 함수 파일 코드, 오류 메시지
이미지가 안 보임	R2 공개 경로와 접근 권한	요청 URL, HTTP 응답 상태 코드, R2 버킷 공개/서명 정책
도메인이 안 열림	DNS 레코드와 SSL 인증서 상태	현재 등록된 레코드 종류(CNAME/A), 연결한 Pages 프로젝트명

14 · SECTION 19 — PRICING SENSE & BILLING BOUNDARIES

19 가격 감각 — Cloudflare · Vercel · Supabase를 같은 줄에 놓고 비교하기

"정적 자산 요청(무료·무제한)"과 "Pages Functions 호출(Workers 한도 차감)"의 차이를 이해해야 정확한 비용 계산이 됩니다

과금 기준 완벽 해부

Cloudflare 과금에서 가장 헷갈리는 2대 핵심 포인트 Static vs Functions

포인트 1 · 정적 파일 요청 vs 함수(Functions) 요청

Pages의 정적 asset 요청은 무료·무제한으로 안내되지만, Pages Functions를 호출하는 순간 그 요청은 Workers 요청 한도에 들어갑니다. Free 플랜이라면 하루 100,000건의 Workers 요청을 Pages Functions와 Workers가 함께 나눠 씁니다.

포인트 2 · Workers CPU 시간 한도 (Free vs Paid)

Free는 HTTP 요청당 10ms CPU가 기본 한도이고, Paid(월 $5~)는 기본 30초에서 설정으로 최대 5분까지 올릴 수 있습니다. 단순 네트워크 대기 시간이 전부 CPU로 잡히진 않지만, 이미지 처리나 큰 JSON 가공처럼 연산이 많은 작업은 이 한도를 의식해야 합니다.

D1 과금: rows read/write 및 저장 용량 기준 (데이터 전송 egress 별도 과금 없음, DB당 10GB 한계 유의).
R2 과금: 저장 용량과 Class A/B operation 기준이며 인터넷 egress 무료가 압도적 강점입니다.
KV 과금: Workers Paid 내 read/write/delete/list 및 용량 기준 (읽기 캐시용으로 활용).

플랫폼 3사(Cloudflare · Vercel · Supabase) 선택 기준 현실적인 결론

플랫폼	기본 유료 시작점 및 과금 특징	가장 유리한 프로젝트 유형
Cloudflare	Workers Standard 월 $5 구독 + 요청/CPU/D1/R2/KV 사용량 기반 (정적 요청·R2 egress 무료)	정적 콘텐츠 중심 + 작은 API 홈페이지, 포트폴리오, 자영업 사이트를 싸고 빠르게 공개할 때
Vercel	Vercel Pro 월 $20 (포함 크레딧 제공) + Functions/Blob/Image/Analytics 항목별 사용량	Next.js 중심의 제품이거나 프론트엔드 자동 배포 경험과 팀 프리뷰 협업이 최우선일 때
Supabase	Supabase Pro 월 $25부터 운영 안정성 확보 + DB/Auth/Storage 통합 (egress·용량 초과 확인)	복잡한 Postgres SQL, 로그인/권한(Auth), 실시간(Realtime), 관리자 DB 작업이 핵심일 때

✔ 이 글의 초점: "홈페이지를 싸고 빠르게 공개한 뒤 필요한 기능만 하나씩 붙이는" Cloudflare-first 전략에 집중합니다. 개인·스타트업 실무 수치(무료 한도, R2, PayPal, 알림)는 17~19장에 공식 문서 기준으로 모아 두었습니다.

15 · SECTION 20 & 22 — 7 HONEST CONS & PLATFORM PHILOSOPHY

20 솔직한 단점 7가지 & 22 플랫폼 철학 (통합 제품 Vercel vs 조립 플랫폼 Cloudflare)

Cloudflare는 싸고 강하지만 부품이 잘게 나뉘어 있어 연결(Binding)과 환경 분리를 개발자가 앞단에서 직접 설계해야 합니다

도입 전 반드시 알아야 할 트레이드오프

20. Cloudflare 방식의 솔직한 단점 7가지 연결의 복잡성

1. 서비스를 따로 만들고 연결해야 한다: Pages, Workers, D1, R2, KV가 각각 독립 서비스라 "DB는 만들었는데 코드가 못 찾는" 상황을 초보자가 자주 겪습니다.
2. 바인딩 이름이 곧 런타임 계약이다: wrangler의 binding = "DB"와 코드의 env.DB가 다르면 로컬에선 돼도 preview/prod에서 깨집니다.
3. 환경이 세 갈래로 갈라진다: local, preview, production의 database_id, KV namespace id, secret 값이 달라 문서화하지 않으면 AI도 사람도 헷갈립니다.
4. D1은 Postgres가 아니라 SQLite 계열이다: 복잡한 Postgres 확장이나 대형 트랜잭션을 그대로 기대하면 안 되며, DB당 10GB 한계 때문에 로그성 데이터는 Turso 등으로 분리해야 합니다.
5. Pages도 Functions를 쓰면 Workers 과금으로 들어간다: 정적 asset과 동적 API 호출 한도를 분리해 계산해야 합니다.
6. Worker 런타임은 Node 서버와 다르다: Node 전용 패키지, 파일 시스템 접근, 긴 작업, 일부 네이티브 모듈은 그대로 옮기기 어렵습니다.
7. 비용 항목이 쪼개져 있다: 요청/CPU, D1 rows, R2·KV operation이 따로 움직여 계산표 없이 운영하면 감이 흐려집니다.

22. 플랫폼 철학: Vercel vs Cloudflare 통합 제품 vs 조립 플랫폼

Cloudflare가 복잡해 보이는 이유는 같은 일을 어렵게 만들어서가 아니라, Vercel이 뒤에서 숨겨 주는 인프라 결정을 개발자가 더 앞단에서 직접 고르게 하기 때문입니다.

PHILOSOPHY COMPARISON — Integrated Product vs Composable Edge

Vercel: 프레임워크 통합 제품 • 저장소 연결 시 빌드·라우팅·프리뷰·이미지 최적화가 하나로 묶임
• 초반에 코드만 올리면 자동 처리되는 경험

Cloudflare: 엣지 부품 조립 플랫폼 • DNS·CDN·보안 위에 Workers, Static Assets, D1, R2, KV 부품을 배치
• 비용·위치·캐시·런타임을 세밀하게 직접 통제

한 문장으로 정리: Vercel은 프레임워크 앱을 빠르게 배포하는 통합 제품에 가깝고, Cloudflare는 전 세계 네트워크 위의 컴퓨팅·스토리지 부품을 직접 조립하는 개발자 플랫폼에 가깝습니다.

16 · SECTION 21 — COPY-PASTE VIBE CODING PROMPTS & MASTER SHEET

21 딸깍 복사용 프롬프트 & Cloudflare 홈페이지 제작 마스터 치트시트

실제 토큰이나 계정 ID는 절대 넣지 말고 사이트 목표와 기능명만 바꿔 복사해 바로 AI에게 지시하세요!

프롬프트 01 · 초기 설계 & 골격 계획

STEP 1 — PLAN ONLY (코드 수정 전 계획 승인) "Astro + Cloudflare Pages 기준으로 [자영업 매장 소개 및 예약] 사이트를 만들려고 해. 아직 코드는 고치지 말고, 1) 첫 화면 전환 목표에 맞춘 섹션 구조, 2) 정적 페이지와 Pages Functions API 분리안, 3) D1·R2·KV 바인딩 표, 4) 수정할 파일 목록만 먼저 계획해서 표로 보여줘."

핵심 포인트: AI가 바로 배포 명령까지 달리지 못하게 계획 단계를 먼저 끊어줍니다.
전환 목표 명시: 방문자가 첫 화면에서 해야 할 행동을 한 문장으로 지정합니다.

프롬프트 02 · D1 · R2 · KV 기능 구현

STEP 2 — SAFE IMPLEMENTATION (바인딩 & 시크릿 보호) "승인한 계획대로 문의 폼 API를 Pages Functions로 구현해줘. DB 바인딩 이름은 `env.DB`(D1), 첨부 이미지는 `env.MEDIA`(R2)를 사용하고, created_at·updated_at·status 컬럼을 포함해줘. 실제 토큰이나 비밀값은 코드에 넣지 말고 `.env.example`과 `wrangler` 설정 예시만 작성해줘."

핵심 포인트: 바인딩 이름(`env.DB`, `env.MEDIA`)을 명확히 지정해 런타임 불일치를 예방합니다.
비밀값 차단: 실제 API 키 대신 변수명만 쓰도록 강제합니다.

프롬프트 03 · 로컬 검증 & 배포전 QA

STEP 3 — VERIFY & QA (배포 명령 자동 실행 금지) "방금 수정한 파일 목록과 요약을 정리해줘. 원격 리소스 생성이나 production deploy 명령은 직접 실행하지 말고, 내가 로컬에서 `npm run dev`, `npm run build`, preview 순서로 검증할 명령어와 모바일 360px 텍스트 겹침·SEO(title, canonical, sitemap) 체크리스트만 알려줘."

핵심 포인트: 로컬 빌드와 프리뷰 검증을 거친 후 사람이 마지막에 배포를 승인합니다.
공개 품질 점검: 모바일 360px 화면과 SEO 메타데이터를 함께 검증합니다.

17 · BENEFITS — COST · NO WORDPRESS · MANY SITES

실무 이점 ① — 홈페이지는 무료로 시작하고, 워드프레스 없이 여러 사이트를 둠

정적 요청은 무료·무제한임. 동적 호출만 Workers 한도를 씀. 금액은 공식 문서에 있는 것만 적음

개인·스타트업 공통

홈페이지 비용 — Free로 시작할 때와 월 $5가 시작점일 때 Workers · Pages

정적 홈: Pages·Workers의 정적 asset 요청은 무료·무제한임. 파일만 올리는 홈페이지는 Workers Free($0)로 시작함.
동적 호출: Pages Functions와 Workers 요청은 Free에서 하루 100,000건을 같이 씀. UTC 자정에 리셋되고, 넘으면 에러 1027이 남.
Paid 시작점: Workers Paid는 계정당 최소 월 $5임. 월 1,000만 요청이 포함되고, 추가 100만 건당 $0.30임. 이 플랜은 데이터 전송(egress)·대역폭 추가 요금이 없음.
Pages Free 한도: 월 500빌드, 동시 빌드 1개, 사이트당 파일 20,000개, 파일당 25MiB임. 존 Free 플랜은 월 $0이고 CDN·Universal SSL·언미터드 DDoS가 포함됨.

출처: Workers pricing·limits, Pages functions pricing·limits, plans/free

워드프레스 없이, 사이트는 수십 개까지 한도 확인

CMS 불필요: 워드프레스를 설치하지 않고 정적 사이트를 Pages에 올린 뒤, 폼·API만 Functions 또는 Workers에 붙임.
Pages 프로젝트: 계정당 100개임. 이 한도는 보통 올려 주지 않음. 커스텀 도메인은 Free 기준 프로젝트당 100개임.
Workers 개수: Free 100개, Paid 500개임. Pages 프로젝트 한도와 따로 셈.
도메인 추가 속도: 10분에 최대 25개임. 도메인이 50개를 넘고 대기 중이 활성보다 많으면 추가가 막힘. 수십 개 운영은 이 한도 안에서 가능함. 존 개수의 고정 상한 숫자는 공식 한도 표에 없음.

출처: Pages limits, Workers limits, Fundamentals — add multiple sites

18 · BENEFITS — D1 · CDN CACHE · DDOS · REGISTRAR · R2

실무 이점 ② — DB·CDN 캐시·DDoS·원가 도메인·R2 이그레스

R2는 인터넷으로 나가는 이그레스 요금이 없음. 도메인은 마크업 없는 원가이고, 단일 달러 가격은 적지 않음

공식 문구만

DB · 캐시 · DDoS Free에도 있음

DB (D1): Workers Free·Paid 모두 D1이 있음. Free는 DB 10개, 저장 합계 5GB, DB당 500MB, 읽기 500만 행/일, 쓰기 10만 행/일임. D1 데이터 전송(egress) 요금은 없음.
캐시: Free 존에 CDN 캐시가 포함됨. Cache Rules는 Free 10개임. 기본은 확장자 기준 정적 파일이고, HTML·JSON은 기본으로 캐시하지 않음.
DDoS: 전 플랜에 L3–L7 표준 언미터드 DDoS와 HTTP DDoS 보호가 있음. 제품 안내는 공격 트래픽 급증에 대한 종량 과금이 없다고 함.
곁가지: 새 존에는 Free Managed Ruleset이 자동 배포됨(Log4j, Shellshock, 흔한 워드프레스 익스플로잇). Free WAF는 커스텀 룰과 레이트 리밋 1개, 유출 자격 증명 검사 1필드를 포함함. Universal SSL도 Free에 있음.

출처: D1 pricing, Cache plans·default behavior, DDoS docs, WAF managed rules, plans

도메인 원가 · R2 이그레스 없음 과금 경계

도메인: Registrar는 등록·갱신을 원가로 팔고, 레지스트리와 ICANN에 내는 돈만 청구함. 마크업과 surprise fee가 없음. 자동 갱신이 기본이고 갱신가도 레지스트리 list price임.
가격표: 확장자마다 금액이 다름. 이 슬라이드에는 .com 같은 단일 가격을 적지 않음. 현재 표는 pricing.registrar.cloudflare.com 임.
R2 이그레스: 공식 표는 Egress (data transfer to Internet) = Free 임. 어떤 스토리지 클래스든 이그레스 대역폭 요금이 없음. How R2 works도 “no egress fees”라고 함.
R2 무료 구간: Standard만 해당. 월 10GB-month, Class A 100만 요청, Class B 1,000만 요청, 이그레스 무료임. Infrequent Access는 이그레스는 무료이나 데이터 조회(processing)가 GB당 $0.01임.

출처: Registrar overview, R2 pricing, R2 how-it-works

19 · BENEFITS — PAYPAL · BUDGET ALERTS · ANALYTICS · MAIL

실무 이점 ③ — PayPal·요금 알림·트래픽 분석·보안 메일

요금 알림은 메일을 보내지만 사용을 멈추지는 않음. PHP 전용 공격 메일은 공식 목록에서 확인하지 못함

확인된 알림만

결제 · 폭탄 요금 알림 · 트래픽 기록 Billing · Analytics

PayPal: 결제 수단에 카드(Visa, Mastercard, Amex, Discover, UnionPay)와 PayPal이 있음. Apple Pay, Google Pay, Link도 안내됨. 카드 전체 번호와 PayPal 비밀번호는 Cloudflare가 보관하지 않음.
예산 알림: Pay-as-you-go 계정은 Billing > Billable Usage에서 달러 임계값을 정함. 이번 청구 기간 사용액이 넘으면 수신 메일로 1통이 감. 사용을 멈추거나 상한을 걸지는 않음. 금액의 정본은 월 인보이스임.
제품별 사용 알림: 바이트·요청처럼 제품 단위로 보내는 Usage notification은 Professional 이상임. Free 존만 쓰는 계정은 이 메일의 포함 대상이 아님.
트래픽 분석: Zone Analytics는 전 플랜이 최소 최근 30일을 봄. Free는 요청·대역폭·순방문자·국가를 보여 줌. 가입 직후 Free는 지표가 최대 24시간 늦을 수 있음. Web Analytics 주간 요약 메일은 전 플랜임. Security Analytics 존 화면은 Free도 최대 31일임.

출처: Billing profile, Budget alerts, Usage-based billing, Zone analytics, Web Analytics notifications, Security Analytics

도메인 이후 메일 — 있는 것과 없는 것 전 플랜 vs 유료

HTTP DDoS 알림: 전 플랜. 초당 100요청을 넘는 HTTP 공격을 완화하면 알림이 감.
Universal SSL 알림: 전 플랜. 인증서 검증·발급·갱신·만료를 메일로 받음.
Security Insights: 전 플랜. 원하는 인사이트를 골라 메일로 받음. Free 스캔 주기는 7일마다이고, 온디맨드 스캔도 가능함. 내용은 설정 점검(TLS, DNS, WAF 미배포 등)이지 PHP 공격 로그가 아님.
확인 못 한 항목: 도메인 등록 직후 PHP 취약점이나 이상 공격을 자동으로 짚어 보내는 전용 메일은 공식 알림 목록에 없음. WAF Security Events 스파이크 메일은 Business·Enterprise만 해당함.

출처: Notifications — HTTP DDoS, Universal SSL, Security Insights, WAF availability. Security Center get started

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