파괴적 작업의 세 가지 안전 게이트
배포할 때 A 기능만 변경했다고 생각했지만, 실제 diff에는 지난주 B 디버깅 중의 임시 변경이 섞여 들어가서 반제품 코드가 프로덕션에 들어갔습니다. 데이터베이스, 설정, 배포 같은 불가역 작업은 실행 전에 반드시 게이트를 설치해야 합니다. 아래 두 가지 연습은 모두 직접 조작할 수 있습니다.
핵심 원칙: 불가역 작업의 안전은 게이트에서 옵니다. 백업은 데이터 손실을 막고, 롤백 방안은 복구 불가를 막고, diff 검토는 문제 있는 배포를 막습니다 - 세 가지 게이트 모두 실행 전에 설치됩니다.
데이터베이스 변경 전 백업
백업은 프로젝트 루트 디렉토리 backups/에 타임스탬프를 포함한 이름으로 저장합니다. 백업 없이 migrate, drop, alter, delete 작업은 실행할 수 없습니다. 비용은 명령어 한 줄이지만, 걸리는 것은 전체 데이터베이스입니다.
불가역 작업 전 롤백 방안 수립
롤백 방안은 세 가지를 답해야 합니다: 작업 전 상태로 어떻게 복원하는가, 어떤 백업 파일이 필요한가, 예상 복원 시간. 이 세 가지를 답하지 못하면 작업을 충분히 생각하지 않은 것입니다.
배포 전 diff 검토
「내가 무엇을 변경했다고 생각했는가」와 「실제로 무엇을 변경했는가」를 분리해서 비교합니다. SubAgent가 독립적으로 diff와 Release Notes의 차이를 분석하고, 위험이 발견되면 배포를 중단합니다.
당신은 이번 배포의 reviewer입니다. Release Notes에는 한 가지만 적혀 있지만 실제 diff에는 7개의 파일이 있습니다. 각 파일의 변경 사항이 「예상대로」인지 「위험 존재」인지 판단하고 모두 표시한 후 검토 보고서를 생성하세요.
✨ 다크 모드 추가: 설정에서 어두운 인터페이스로 전환 가능 — 장시간 사용 시 눈이 피로하지 않습니다.
작업 유형을 선택하고 통과해야 할 게이트를 하나씩 체크한 후 실행해보세요. 빠뜨린 항목이 있으면 그에 해당하는 결과를 볼 수 있습니다.
백업 명령어 (SQLite 예시)
# 데이터베이스 구조 또는 데이터와 관련된 모든 변경은 실행 전 반드시 백업 필요
cp database.db backups/database_$(date +%Y%m%d_%H%M%S).db백업 파일 명명 형식: {원본파일명}_{YYYYMMDD_HHMMSS}.db, 프로젝트 루트 backups/ 디렉토리에 통일하여 저장.
배포 채널
- 코드 배포, 버전 배포, 서버 배포는 반드시 GitHub를 통해야 합니다
- 서버는
git pull또는 CI/CD 파이프라인으로 코드를 가져옵니다 - 긴급 핫픽스는 예외 가능하나 사후에 반드시 commit으로 동기화해야 합니다
- 사용자가 명확히 확인하기 전까지 태그 생성, push, 배포는 모두 금지됩니다
자격증명 관리
- 모든 자격증명은 환경 변수 또는 secrets를 통해 관리합니다
- 코드 또는 설정 파일에 하드코딩하는 것은 금지됩니다
- 키가 한번 git 히스토리에 들어가면 영구 유출된 것으로, 폐기하고 재발급해야 합니다
설계 의도: Release Notes는 예상 변경 사항을 설명하지만 실제 commit에는 관계없는 조정이나 실수로 인한 삭제가 섞여 들어갈 수 있습니다. 정규 팀은 CI/CD와 PR review로 이 문제를 막지만, 독립 개발자는 종종 review를 건너뛰고 직접 push합니다. diff 검토 규칙은 SubAgent를 reviewer로 활용하는 것과 같습니다.
제출물: 위험 검토 보고서. ① 테스트 저장소에 배포 주제와 무관한 변경을 의도적으로 혼입하고(예: 기존 함수의 로직 수정), ② 주제 기능만 설명하는 Release Notes를 작성한 후 AI에게 「전체 diff 가져오기 → 파일별 비교 → 분류 처리」 세 단계로 검토를 요청합니다. ③ AI가 혼입된 변경 사항을 발견하고 배포를 중단할 수 있는지 확인하고, 위험 보고서를 프로세스 템플릿으로 보관합니다.
출처: 오픈소스 저장소 itshen/xs_vibe_rules의 rule-opensource.mdc 6장 6.4/6.5 「데이터베이스 백업 및 롤백 방안」, 10장 「배포 및 환경」.