배포 후 운영·백업·rollback·모니터링 최종 지침

production을 보호하는 규칙

main은 production 전용
기능은 feature/*, 수리는 fix/* branch
preview URL에서 검사 후 merge
배포 직전 정상 commit SHA 기록
긴급 시 이전 deployment 또는 revert commit으로 rollback

무엇을 backup해야 하나

대상	방법	주기
source code	GitHub repository와 release tag	모든 변경
D1 data	export/backup script, schema migration 보관	운영 중요도에 따라 매일·매주
R2 file	versioning 또는 별도 backup bucket	새 release 등록 시
Secret 목록	값이 아닌 이름·용도·재발급 절차 문서화	구성 변경 시
domain/DNS	record export와 screenshot	변경 전후

최소 모니터링

홈 URL 200 확인
/api/health 상태 확인
최근 deployment 실패 알림
login 실패·문의 spam·download 오류 log
D1/R2 사용량과 free limit 확인
SSL/domain 만료·DNS 변경 확인

release 기록

Version: 1.2.0
Commit: abc1234
Deployment: production URL
Database migration: 003_add_orders.sql
Changed: program upload, inquiry filter
Rollback: revert abc1234 또는 deployment 1.1.9 복원

이 기록이 있으면 “어제는 됐는데 오늘 안 됨” 문제를 빠르게 추적할 수 있습니다.

무료 운영에서 놓치기 쉬운 한도

Pages build 횟수, Worker request, D1 read/write, R2 storage·operation, 단일 파일 크기 같은 한도는 바뀔 수 있습니다. 숫자를 code에 박아 두지 말고 공식 limits page를 운영 checklist에서 정기 확인합니다.

AI에게 운영까지 맡길 때 추가할 문장

배포 후 운영까지 포함하라. 각 release마다 version, commit SHA, deployment URL, migration, rollback 절차를 기록하라. production 변경 전 backup 상태를 확인하고 preview에서 smoke test를 통과시켜라. 사용량 한도와 최근 실패 log를 점검하고, 실제 URL과 API health를 확인한 뒤 운영 보고서를 작성하라.

최종 완료 보고 형식

완료 상태: 성공/부분 성공/실패
GitHub: owner/repo @ commit
Preview URL:
Production URL:
Tests:
Database/Storage:
Secrets configured:
Rollback:
남은 사용자 작업:

한방배포의 마지막 원칙

새 기능을 빨리 넣는 것보다, 실제 주소·data·rollback을 함께 확인할 수 있는 상태가 더 중요합니다.