정적 사이트 롤백: 잘못 게시한 뒤 이전 버전으로 복원하는 법

정적 사이트 게시 실수는 처음에는 작아 보입니다. 홈은 열리지만 하위 페이지가 404가 됩니다. CSS가 빠져서 모바일 화면만 무너집니다. 이미지나 PDF 경로가 바뀌었습니다. 클라이언트 미리보기 링크에 아직 승인되지 않은 문구가 올라갑니다.

이때 production 위에서 바로 고치기 시작하면 문제가 더 커질 수 있습니다.

공개 링크가 이미 나빠졌다면 먼저 마지막으로 정상 동작하던 버전으로 복원하세요. 방문자가 깨진 화면을 보는 시간을 줄인 뒤, 실패한 게시를 따로 조사하는 편이 정적 사이트에는 더 안전합니다.

모든 수정에 롤백이 필요한 것은 아닙니다

롤백은 일반 편집을 대신하는 기능이 아닙니다. 작은 오타나 영향이 거의 없는 문구라면 수정본을 다시 게시하는 것이 충분할 수 있습니다.

이전 버전으로 복원해야 할 때는 지금 공개된 버전이 이전보다 명확히 나쁘고, 실제 보는 사람에게 영향을 줄 때입니다.

기준은 실무적으로 잡으면 됩니다. 신뢰, 검토, 지원, 채용, 캠페인, 수업 제출에 영향을 주고 있다면 먼저 복원할 가치가 있습니다.

정적 사이트는 공개 상태를 되돌리기 좋습니다

정적 사이트는 HTML, CSS, JavaScript, 이미지, 폰트, PDF 같은 파일 묶음으로 다룰 수 있습니다. 성공한 게시마다 그 상태가 남아 있으면, 이전 버전으로 복원하는 방식과 잘 맞습니다.

서버의 폴더를 직접 덮어쓰는 방식과는 다릅니다. 덮어쓰기 방식에서는 오래된 HTML, 새 JavaScript, 빠진 이미지, 브라우저 캐시가 섞이기 쉽습니다. 버전이 남는 정적 사이트 게시에서는 각 게시가 하나의 완성된 상태여야 합니다.

복원을 위해 남아 있어야 하는 정보는 보통 네 가지입니다.

Cloudflare Pages는 rollback을 이전 production deployment로 되돌리는 기능으로 설명합니다. Vercel의 Instant Rollback도 production domain을 이전 deployment로 다시 가리키는 흐름입니다. Netlify도 이전 deploy를 production으로 다시 게시할 수 있습니다. 제품마다 세부 구현은 다르지만 핵심은 같습니다. 이전 공개 상태가 다시 제공 가능한 대상으로 남아 있어야 합니다.

사고 중에 예전 사이트를 다시 빌드하지 마세요

“예전 ZIP을 찾고, 로컬에서 다시 빌드하고, 다시 업로드한다”가 복구 방법이라면 그것은 롤백이라기보다 긴급 재게시입니다.

그 방법도 통할 수 있습니다. 하지만 가장 침착해야 할 때 새 불확실성을 더합니다.

• 예전 소스가 당시 공개 파일과 다를 수 있습니다.
• 의존 패키지나 빌드 환경이 바뀌었을 수 있습니다.
• 이미지나 PDF가 별도 폴더에 있었을 수 있습니다.
• 담당자가 급하게 잘못된 dist 또는 out 폴더를 고를 수 있습니다.
• 새 업로드가 또 다른 깨진 상태를 만들 수 있습니다.

공개 사고에서 먼저 필요한 것은 다시 만드는 일이 아니라 정상 화면으로 돌아가는 일입니다. 그래서 작은 정적 사이트에도 버전 기록은 단순한 편의 기능이 아닙니다.

복원할지, 앞으로 고쳐서 다시 게시할지

롤백을 긴 토론으로 만들 필요는 없습니다. 몇 가지 질문으로 짧게 판단하세요.

롤백이 항상 정답은 아닙니다. 다만 현재 공개 버전이 직전보다 나쁘다는 점이 분명하다면, 망설이는 시간을 줄이는 것이 중요합니다.

복원 직후 확인할 것

버튼이 성공했다고 해서 끝이 아닙니다. 실제 공개 경험을 확인해야 합니다.

1. 시크릿 창에서 홈을 엽니다.
2. 자주 공유한 하위 페이지를 엽니다.
3. CSS, JavaScript, 이미지, 폰트, PDF, 다운로드를 확인합니다.
4. 커스텀 도메인과 미리보기 공개 링크를 모두 쓴다면 둘 다 봅니다.
5. HTTPS가 정상인지 확인합니다.
6. 최근 방문이나 통계를 보고 요청이 복원된 버전에 닿는지 확인합니다.
7. 팀이나 고객에게 지금 어떤 버전이 공개 중인지 알립니다.

도메인 설정을 같이 만졌다면 DNS와 인증서도 확인하세요. 정적 파일 복원은 잘못된 DNS 레코드나 인증서 문제를 고치지 않습니다. DeployPages에는 공개 전후 확인을 위한 DNS 조회와 SSL 확인 도구가 있습니다.

롤백으로 해결되지 않는 것

이전 버전으로 복원하는 것은 기본적으로 정적 공개 상태를 되돌리는 일입니다. 사이트 바깥의 모든 의존성이 함께 돌아가지는 않습니다.

이 경계가 중요합니다. 롤백은 프런트엔드와 정적 자산 사고에는 강합니다. 그러나 사이트와 연결된 모든 시스템을 되돌리는 전체 사고 대응 기능은 아닙니다.

업로드, Git, CLI 모두 원칙은 같습니다

정적 사이트가 production에 올라가는 길은 여러 가지입니다. 브라우저 업로드, Git 기반 게시, CLI 게시 모두 복구 원칙은 같습니다.

브라우저 업로드

HTML 폴더, AI 생성 웹사이트, 온라인 포트폴리오, PDF, 일회성 랜딩 페이지, 클라이언트 미리보기는 브라우저 업로드로 시작하는 일이 많습니다.

이 방식에서 위험한 점은 이전 버전이 담당자의 다운로드 폴더에만 남는 경우입니다. 게시 기록이 있으면 이전 상태가 개인 PC가 아니라 프로젝트 안에 남습니다.

Git 기반 게시

Git 기록은 유용합니다. 하지만 Git 커밋과 실제로 공개된 파일은 항상 같은 것이 아닙니다. 나중에 같은 커밋을 다시 빌드해도 의존성, 설정, 환경 값 때문에 출력이 달라질 수 있습니다.

그래서 정적 사이트에서도 성공한 게시 자체를 복원 대상으로 남겨 두는 것이 좋습니다.

CLI 게시

CLI 게시에는 반복성이 있습니다. 그래도 반복 가능하다는 말이 무위험이라는 뜻은 아닙니다. 빌드는 성공했지만 경로, 이미지, PDF, 문구, 모바일 레이아웃이 잘못된 상태로 나갈 수 있습니다.

반복해서 게시할 수 있는 것과 빠르게 되돌릴 수 있는 것은 다른 안전장치입니다.

DeployPages에서의 위치

DeployPages는 production 폴더를 손으로 계속 덮어쓰는 방식보다, 정적 사이트를 버전 있는 공개 상태로 다루는 흐름에 가깝습니다.

처음에는 HTML 파일, 폴더, ZIP, PDF, AI 생성 웹사이트, 프레임워크의 정적 출력물을 업로드해 공개 링크를 만들 수 있습니다. 이후 같은 프로젝트에서 이전 버전으로 복원, 통계, 커스텀 도메인, 비밀번호 보호, CLI 배포로 확장할 수 있습니다.

중요한 생각은 단순합니다. 의미 있는 업데이트마다 돌아갈 길을 남겨야 합니다. 새 업로드가 공개 URL을 깨뜨렸을 때, 방문자를 기다리게 하며 어제의 사이트를 다시 조립할 필요가 없어야 합니다.

게시 전 정해 둘 간단한 절차

다음 정도의 절차만 있어도 사고 때 훨씬 덜 흔들립니다.

화려한 절차가 아닙니다. 하지만 공개 페이지가 깨졌을 때는 단순한 절차가 가장 도움이 됩니다.

언제 롤백이 필수가 되는가

내일 지울 임시 미리보기라면 롤백이 없어도 큰 문제가 아닐 수 있습니다.

하지만 다음 중 하나라도 해당하면 이전 버전으로 복원할 수 있어야 합니다.

• 커스텀 도메인을 사용합니다.
• 고객, 채용 담당자, 교수자, 광고 방문자에게 이미 링크를 보냈습니다.
• 여러 사람이 같은 프로젝트를 업데이트합니다.
• 포트폴리오, 이력서, 캠페인, 문의, 지원 문서에 영향을 줍니다.
• AI 생성 결과물이나 외주 산출물을 공개 전에 검토합니다.
• 업데이트가 잦아져 ZIP 파일 수동 관리가 믿기 어려워졌습니다.

정적 사이트가 실제 업무의 일부가 되면 게시도 일방통행이어서는 안 됩니다. 되돌릴 수 있어야, 더 자주 고치고도 덜 불안합니다.

참고

• Cloudflare Pages rollbacks
• Vercel Instant Rollback
• Netlify manage deploys
• DeployPages 이전 버전으로 복원