정적 웹과 동적 웹의 경계

프로그램 카드와 설명만 보여 주면 static site입니다. 관리자 login, 고객 문의 저장, 프로그램 등록, 설치 파일 upload, 결제 확인이 들어가면 dynamic backend가 필요합니다. 이 기능을 localStorage나 예시 data로 속이면 실제 운영에서 바로 문제가 납니다.

UIPages/Assets고객·관리자 화면
APIWorker권한·검증·logic
DATAD1 + R2정보와 파일

역할을 나누는 기준

Resource저장 대상예시 binding
D1program, inquiry, customer, order, licenseDB
R2대표 이미지, screenshot, EXE, ZIPFILES
SecretTelegram token, session secret, payment keyTELEGRAM_BOT_TOKEN
Workerlogin, CRUD, download grant, webhooksrc/worker.js

Database schema 기본

admins
admin_sessions
programs
program_versions
inquiries
customers
orders
payments
licenses
download_grants
audit_logs

schema 생성은 여러 번 실행해도 안전한 idempotent migration으로 만들고, production에 적용하기 전 preview Database에서 test합니다.

관리자 기능의 최소 보안

  • 비밀번호는 PBKDF2/Argon2/bcrypt 같은 검증된 hash
  • session cookie는 HttpOnly, Secure, SameSite
  • POST·PATCH·DELETE는 origin/CSRF 검사
  • login과 문의 form rate limit
  • R2 bucket은 기본 private
  • download는 raw file URL 대신 만료·횟수 제한 token
  • 모든 관리자 변경을 audit log에 기록

프로그램 설치 파일을 Pages에 넣지 않는 이유

Cloudflare Pages는 단일 asset 크기 제한이 있으므로 큰 EXE·ZIP을 repository와 Pages asset에 넣는 방식은 오래가지 못합니다. 프로그램 설치 파일은 R2 같은 object storage에 두고 Worker가 권한을 확인한 뒤 전달해야 합니다.

배포 완료 전 자동 test

  1. /api/health에서 database·storage 상태 확인
  2. 최초 관리자 계정 생성
  3. logout 후 다시 login
  4. program 생성·수정·공개
  5. 문의 저장과 관리자 목록 확인
  6. 파일 upload 후 private object 확인
  7. download grant 만료·횟수 제한 확인
화면만 보고 완료 금지

관리자 page가 열리는 것과 관리자 기능이 저장되는 것은 다릅니다. API test와 D1/R2 binding 검사가 통과해야 완료입니다.

공식 참고: Cloudflare Pages/Functions bindings ↗ · Cloudflare Secrets ↗

ADVERTISEMENT

AdSense 승인 후 광고가 표시될 자리입니다.

이전 guide← GitHub·Cloudflare·Vercel·Netlify 공식 연결 링크와 선택 기준