Git 흐름이 곧 배포 흐름이 돼
저장소를 Vercel에 연결하면 main push는 production 배포를, PR과 다른 브랜치 push는 고유한 preview 주소를 만들 수 있어. Next.js와 같은 팀이 플랫폼을 운영하므로 프레임워크의 캐시와 이미지, 함수 기본값이 바로 맞물려.
설정 없이 시작하는 운영 기능
- 자동 빌드와 빌드 캐시
- 브랜치·PR별 preview 배포
- Edge 실행 지원
- Edge 이미지 최적화
- 전 세계 캐시에 분산되는 ISR
- 선택해서 켤 수 있는 Web Analytics와 Speed Insights
환경별 설정을 분리해
환경 변수는 dashboard나 CLI에서 production, preview, development 범위로 나눌 수 있어. preview가 staging DB와 sandbox API를 쓰게 만들면 검증이 production 데이터를 건드리지 않아.
push 성공과 서비스 성공은 달라
Git 전송이 끝나도 빌드가 실패하거나 잘못된 환경 변수가 들어갈 수 있어. 배포가 READY가 된 뒤 실제 preview나 production URL에서 핵심 경로와 로그를 확인해야 배포가 끝난 거야.
preview에는 production과 분리된 DB·외부 서비스·분석 키를 연결하고, migration과 seed가 어떤 순서로 적용되는지 정해. 배포마다 commit SHA, 빌드 상태, health URL을 기록한 뒤 핵심 로그인·읽기·변경 흐름을 실제 preview에서 시험해. production 승격 뒤에도 같은 marker가 보이는지 확인해.
자동 배포가 release 판단까지 자동으로 해 주지는 않아. 빌드가 READY여도 잘못된 데이터나 권한 설정으로 기능이 깨질 수 있고, 롤백해도 DB 변경은 돌아가지 않을 수 있어. 코드 배포와 데이터 migration, 기능 노출을 각각 되돌릴 경로로 설계해.
브랜치 preview에서 production과 다른 DB 값을 읽고, 의도적 build 실패·runtime 오류·환경 누락을 각각 만들어 배포 상태와 로그를 확인해. READY가 된 commit SHA를 페이지 marker와 대조하고 production 승격 뒤 핵심 KO·EN 경로가 200인지 실제 URL에서 검사해. 운영 alias가 가리키는 배포의 commit SHA를 확인하고 이전 배포로 되돌리는 절차도 실행해. 되돌릴 수 없는 migration이 있으면 코드 rollback만으로 복구되지 않아.