Vercel 롤백의 숨겨진 로직: 2시간의 삽질로 배운 교훈
문제의 시작
로컬에서 완벽하게 작동하는 코드를 Vercel에 배포했다. 몇 분 후 “Deployed Successfully” 메시지를 확인했다.
프로덕션 사이트를 열었다. 변경사항이 반영되지 않았다.
“캐시인가?” 하드 리프레시를 했다. 여전히 이전 버전이다.
“뭐지?”
디버깅의 시작
1차 시도: 코드 재확인
로컬과 프로덕션이 다르다면 코드 문제일 것이다. 코드를 다시 확인했다.
문제없다. 로컬에서는 완벽하게 작동한다.
2차 시도: 환경 변수
프로덕션 환경 변수가 잘못되었을 수도 있다. Vercel 대시보드에서 환경 변수를 확인했다.
모두 정상이다.
3차 시도: 재배포
혹시 배포 과정에서 뭔가 잘못되었을까? 재배포를 했다.
“Building… Deployed Successfully!”
프로덕션 확인. 여전히 이전 버전.
4-8차 시도: 계속된 재배포
“이번엔 뭔가 다를 거야.”
코드를 약간 수정하고 재배포. 안 됨. 다른 부분을 수정하고 재배포. 안 됨. 콘솔 로그를 추가하고 재배포. 안 됨. 완전히 다른 접근으로 수정하고 재배포. 안 됨.
2시간이 지났다.
깨달음
Vercel 대시보드를 다시 자세히 봤다.
Deployments:
✅ v13 - Deployed 2m ago
✅ v12 - Deployed 15m ago
✅ v11 - Deployed 30m ago
✅ v10 - Deployed 1h ago
→ v9 - Production (Active)잠깐.
v13까지 배포했는데 왜 v9가 Production인가?
각 배포를 클릭해서 상태를 확인했다:
- v13: Ready (but not Production)
- v12: Ready (but not Production)
- v11: Ready (but not Production)
- v9: Production
모든 최신 배포가 프로덕션이 아니었다.
진짜 원인: 롤백의 숨겨진 로직
타임라인을 재구성했다:
어제:
- v10을 프로덕션에 배포
- 버그 발견
- v9로 롤백 (Promote to Production)
오늘:
- v11 배포 → 자동으로 staging
- v12 배포 → 자동으로 staging
- v13 배포 → 자동으로 staging
Vercel의 로직:
과거 버전으로 수동 롤백을 하면, 시스템은 “의도적인 프로덕션 고정”으로 인식한다. 그 이후의 모든 배포는 자동으로 프로덕션에 적용되지 않고 staging 상태로 남는다. 프로덕션에 적용하려면 명시적으로 “Promote to Production”을 해야 한다.
이것을 몰랐다.
해결
v13 배포를 찾아서 “Promote to Production” 버튼을 클릭했다.
몇 초 후, 모든 변경사항이 프로덕션에 반영되었다.
2시간의 삽질이 끝났다.
왜 이런 로직인가?
처음에는 이해가 안 갔다. “왜 최신 배포가 자동으로 프로덕션이 안 되지?”
하지만 생각해보니 합리적이다.
시나리오:
- 프로덕션에 치명적 버그 발생
- 급하게 과거 버전으로 롤백
- 버그를 수정하고 새 버전 배포
- 근데 수정이 완벽하지 않아서 또 배포
- 여러 번 시도…
이 과정에서 모든 배포가 자동으로 프로덕션에 적용된다면?
각 배포마다 프로덕션이 요동친다. 사용자들은 혼란스럽다. 버그가 반복된다.
Vercel의 접근: 롤백 = “지금은 프로덕션을 안정화하고 싶다”는 신호 → 이후 배포는 staging으로 → 충분히 검증하면 수동으로 Promote
안전장치였다.
배운 점
1. 롤백은 단순한 과거 회귀가 아니다
롤백은 시간을 되돌리는 것이 아니라, 배포 파이프라인의 상태를 변경하는 행위다.
많은 배포 시스템에서 롤백은 이후 동작에 영향을 미친다:
- Vercel: 롤백 후 모든 배포가 staging
- AWS CodeDeploy: 롤백 후 auto-deployment 비활성화
- Kubernetes: rollback 후 새 deployment는 manual approval
- Heroku: 롤백 후 pipeline promotion 필요
2. “Deployed Successfully” ≠ “Production에 적용됨”
배포 시스템은 여러 단계로 구성된다:
- Build
- Deploy
- Promote to Production
“Deployed Successfully”는 Deploy 단계까지만 의미한다.
3. 상태를 제대로 봐야 한다
Vercel 대시보드에서 각 배포의 상태가 표시된다:
- ✅ Production
- 🔵 Preview
- 🟡 Ready (staging, 롤백 후)
나는 “Deployed Successfully”만 보고 안심했다. 상태를 자세히 확인했어야 했다.
4. 로컬-프로덕션 차이의 진짜 원인
“로컬에서는 되는데 프로덕션에서는 안 돼”라는 문제의 원인은 다양하다:
흔한 원인:
- 환경 변수 차이
- 빌드 환경 차이
- 의존성 버전 차이
내 경우:
- 배포 상태 차이 (staging vs production)
코드는 전혀 문제가 없었다.
5. 문서를 읽자
Vercel 문서에는 이 동작이 명확히 설명되어 있다:
“When you rollback to a previous deployment, subsequent deployments will not automatically be promoted to production. You must manually promote them.”
하지만 나는 문서를 자세히 읽지 않았다. 2시간을 낭비했다.
체크리스트 업데이트
이제 배포 후 체크리스트에 이것을 추가했다:
배포 후 확인사항:
- Build 성공 확인
- Deploy 완료 확인
- 배포 상태 확인 (Production? Staging?)
- 최근 롤백 이력 확인
- 필요시 “Promote to Production” 실행
- 프로덕션 사이트에서 직접 확인
- 주요 기능 동작 테스트
특히 롤백 이후에는 더 주의깊게 확인해야 한다.
비슷한 경험들
이 글을 쓰면서 다른 개발자들에게 물어봤다. 비슷한 경험이 많았다:
A 개발자: “AWS CodeDeploy에서 롤백했는데, 다음 배포가 자동으로 안 돼서 한참 헤맸어요. Auto-deployment가 비활성화된 걸 몰랐죠.”
B 개발자: “Kubernetes에서 rollback 하고 나서 새 deployment가 pending 상태로만 있더라고요. Manual approval이 필요한 걸 나중에 알았어요.”
C 개발자: “Heroku pipeline에서 롤백 후에 새 빌드가 production에 자동으로 안 올라갔어요. Promote 버튼을 직접 눌러야 했죠.”
패턴이 보인다. 롤백은 배포 파이프라인에 “수동 모드”를 활성화한다.
결론
2시간의 삽질은 아까운 시간처럼 보였다. 하지만 값진 투자였다.
이제 나는:
- Vercel의 롤백 로직을 이해한다
- 배포 상태를 제대로 확인한다
- “Deployed Successfully”를 맹신하지 않는다
- 롤백 후 더 주의깊게 배포한다
그리고 이 글을 읽는 누군가의 2시간을 절약할 수 있다면, 내 2시간은 충분히 가치있다.