스테이징과 롤백
우아하게 복구하는 출시와 한밤중 패닉으로 변하는 출시를 가르는 두 가지 습관: 변경이 진짜 사용자에게 닿기 전에 안전한 곳에서 테스트하는 것, 그리고 나쁜 배포를 즉시 되돌릴 수 있는 것.
스테이징 환경은 그저 당신 앱의 두 번째 복사본이다 — 같은 코드, 별도의 , 별도의(또는 일회용) 데이터베이스 — 프로덕션 전에 시도해 보는 곳이다. 대부분의 호스트는 이것을 거의 공짜로 만든다: 모든 풀 리퀘스트가 자동으로 자기만의 프리뷰 URL을 받아서, 머지하기 전에 변경을 클릭해 보고 누군가와 공유할 수 있다. 데이터베이스 마이그레이션처럼 쉽게 되돌릴 수 없는 것에 특히 써라.
세 환경을 변경이 올라가는 사다리로 그려보라. 롤백은 프로덕션을 마지막 정상 단으로 곧장 떨어뜨리는 밧줄이다:
개발 ──▶ 스테이징 / 프리뷰 ──▶ 프로덕션
(노트북) (PR 프리뷰 URL) (실제 사용자)
시도 클릭해 확인 라이브
뭐든지 공유 · 검증 ┌──────────────┐
│ deploy #42 │ ◀── 현재 (고장)
├──────────────┤
롤백│ deploy #41 │ ◀── 마지막 정상본
│ ├──────────────┤
└──▶│ deploy #40 │
└──────────────┘
명령 한 번 / 클릭 한 번 = 즉시 되돌리기
롤백은 앱 전체에 대한 당신의 실행 취소 버튼이다. 이 플랫폼들은 이전의 모든 배포를 보관하기 때문에, 마지막 정상 버전으로 돌아가는 것은 보통 명령 하나나 대시보드 클릭 하나다:
# Cloudflare Pages: 정상으로 알려진 빌드를 재배포
wrangler pages deployment list
wrangler pages deployment rollback <DEPLOYMENT_ID>
# Vercel: 이전 배포를 프로덕션으로 승격
vercel rollback <DEPLOYMENT_URL>
이 명령을 필요할 때가 아니라 필요해지기 전에 알아두라. 바이브 코딩 속도의 핵심은 출시가 싸다는 것이다 — 하지만 싼 출시는 출시 취소도 똑같이 쌀 때만 안전하게 느껴진다.