먼저 완성 구조부터
프로그램 판매·관리 웹에서 말하는 server는 별도 Windows Server PC를 하나 사는 뜻이 아닙니다. Cloudflare에서는 공개 화면은 Pages가 전달하고, 저장·로그인·문의·upload 같은 backend logic은 Pages Functions 또는 Worker가 실행합니다. data는 D1, 큰 프로그램 파일은 R2에 둡니다.
오늘 이 구조로 프로그램 판매·관리 웹의 GitHub 자동배포와 Cloudflare backend resource를 연결했습니다. 이 글은 그 실제 작업 순서를 독자용 가상 값으로 바꿔 정리한 것입니다.
오늘 실제로 진행한 순서
- GitHub에 빈 repository를 만들고
mainbranch를 준비 - ChatGPT의 GitHub 연결에서 현재 제공된 write action을 확인
- AI가 기존 repository에 source file·branch·commit을 작성
- Cloudflare Pages에서 GitHub repository를 처음 한 번 승인·연결
main을 production branch로 지정해 자동 배포 연결- 관리자·문의 저장용 D1 Database를 만들고 binding 이름을
DB로 연결 - 이미지·EXE·ZIP용 private R2 bucket을 만들고 binding 이름을
FILES로 연결 - Telegram Bot token 같은 민감값은 source가 아니라 Secret으로 등록
/api/health, 관리자 login, CRUD, upload, 문의 저장을 실제 확인- 그다음부터는 GitHub production branch가 바뀌면 Cloudflare가 자동 재배포
GitHub app을 연결했다고 모든 action이 생기는 것은 아닙니다. create_repository가 없으면 새 repository 생성은 계정 소유자가 한 번 처리하고, create_file·create_commit·update_ref 같은 write action이 있으면 그다음 source 작업은 AI가 이어갈 수 있습니다.
정적 웹과 server가 필요한 웹 구분
| 기능 | Pages만 | Functions/Worker + D1/R2 |
|---|---|---|
| 프로그램 소개 카드 | 가능 | 선택 |
| 상세 설명·공지 | 가능 | 선택 |
| 관리자 login | 불충분 | 필요 |
| 프로그램 등록·수정 | 불충분 | D1 필요 |
| EXE·ZIP upload | 부적합 | private R2 권장 |
| 구매 문의 저장 | 불충분 | D1 + Worker |
| Telegram 자동 알림 | 불충분 | Worker + Secret |
| 결제·license | 불충분 | server-side 검증 필요 |
GitHub 자동배포를 유지하는 Dashboard 설정
GitHub push마다 자동으로 다시 배포하려면 Pages project를 Git integration으로 만드는 방식이 가장 단순합니다.
- Cloudflare → Workers 및 Pages → 애플리케이션 만들기 → Pages
- Git에 연결 → GitHub 승인 → 본인 repository 선택
- Production branch는
main - 순수 HTML이면 output directory는 실제
index.html이 있는 folder, 이 guide 예시는public - project 생성 후 Settings/Bindings에서 D1
DB, R2FILES연결 - Variables and Secrets에서 Telegram token·session secret 같은 비밀값 등록
처음부터 GitHub 자동배포가 목표라면 Git integration project로 시작합니다. 별도 Direct Upload project를 만든 뒤 같은 project를 Git integration으로 바꾸는 흐름에 의존하지 않습니다.
server resource를 빠르게 만드는 Wrangler 명령
Cloudflare CLI인 Wrangler를 사용하면 D1, R2, Secret을 command로 만들 수 있습니다. 아래 이름은 모두 가상 예시이므로 본인 project 이름으로 바꿉니다.
npx wrangler login
# Pages project를 CLI-only 방식으로 만들 때
npx wrangler pages project create sample-program-store --production-branch main
# Database
npx wrangler d1 create sample-program-store-db
# 프로그램 파일 저장소
npx wrangler r2 bucket create sample-program-store-files
# Pages Secret — 실행 후 값은 terminal prompt에서 입력
npx wrangler pages secret put TELEGRAM_BOT_TOKEN --project-name sample-program-store단, GitHub 자동배포 project를 원한다면 Pages project 자체는 위 Dashboard의 Git integration으로 연결하고, Wrangler 명령은 D1·R2·Secret 생성/관리용으로 사용하는 편이 이해하기 쉽습니다. D1과 R2를 만든 뒤에는 Pages Functions가 사용할 수 있도록 binding을 연결합니다.
Cloudflare 공식: Pages Git integration ↗ · Pages Wrangler commands ↗ · D1 commands ↗ · R2 commands ↗
Telegram까지 붙이는 위치
Telegram Bot token은 JavaScript source나 GitHub repository에 넣지 않습니다. Cloudflare Secret으로 저장하고 Functions/Worker에서만 읽습니다.
TELEGRAM_BOT_TOKEN = Secret
TELEGRAM_CHAT_ID = Secret 또는 비공개 environment variable
문의 form
→ Worker API
→ D1 inquiries 저장
→ Telegram Bot API 알림
→ 관리자 페이지에서 같은 문의 확인Telegram 전송이 실패해도 문의 Database 저장까지 같이 rollback할지, 문의는 저장하고 알림만 retry할지는 business rule로 명시합니다. 일반적으로 고객 문의 자체는 보존하고 Telegram 알림 실패를 별도 log/retry하는 편이 안전합니다.
배포 완료라고 말하기 전 검사
- production URL이 200으로 열림
- Cloudflare deployment commit SHA와 GitHub production commit이 일치
/api/health에서 backend 상태 확인- D1
DBbinding 실제 query 성공 - R2
FILESupload/read/delete 권한 검사 - 관리자 login → program 생성 → 수정 → 공개가 실제 저장됨
- 문의 form → D1 저장 → Telegram 알림 확인
- Secret이 GitHub file·build log·브라우저 JavaScript에 노출되지 않음
- 큰 프로그램 파일은 public Git repository에 직접 넣지 않음
- rollback할 이전 commit/deployment 기록
최초 연결 후에는 자동입니다
즉, 처음 계정 승인·Git 연결·D1/R2/Secret binding만 끝나면 일상적인 웹 수정은 GitHub source 수정 → commit → Cloudflare 자동 재배포로 반복됩니다.
“server를 만들었다”의 완료 기준은 Cloudflare resource 이름이 생긴 것이 아니라, 실제 production URL에서 login·Database·upload·알림까지 끝까지 통과한 상태입니다.