홈페이지 화면 깨짐이 발생하면 바로 다시 수정하지 말고, 변경 전 백업의 존재와 복구 책임자를 먼저 확인해야 합니다. 깨진 화면 위에 수정 작업을 이어 가면 정상 상태로 되돌릴 기준이 사라지고, 원인과 책임 범위도 함께 흐려집니다.
이 글에서 다루는 내용
- 화면이 실제로 깨진 것인지 브라우저·기기 문제인지 구분하는 순서
- 수정 전 백업이 있는지와 어느 시점 백업인지 확인하는 방법
- 수정자, 호스팅 관리자, 백업 보관자의 복구 책임을 나누는 기준
- 복구 전에 남겨야 할 화면·수정 기록과 접근 권한 목록
- 정상 복구 뒤 검색엔진에 변경 상태를 다시 알리는 절차
홈페이지 화면 깨짐은 먼저 재현부터 확인합니다
같은 주소를 보고도 담당자 컴퓨터에서만 메뉴가 겹치거나 글자가 밀리는 경우가 있습니다. 이 상태에서 관리자 화면을 열어 저장하면 사이트 자체의 문제와 브라우저 캐시 문제가 섞입니다. 먼저 수정한 페이지 주소, 첫 화면, 모바일 메뉴가 보이는 주소를 각각 기록합니다.
Chrome에서는 깨진 페이지를 열고 새 시크릿 창에서 같은 주소를 다시 엽니다. 이어서 휴대전화의 모바일 데이터 환경과 다른 브라우저에서 같은 화면을 확인합니다. 로그인한 관리자에게만 문제가 보이는지, 방문자에게도 같은 문제가 보이는지 구분해 캡처합니다. 캡처에는 주소창과 화면이 함께 나오도록 남겨야 나중에 확인할 페이지를 특정할 수 있습니다.
이 단계가 필요한 이유는 복구 범위를 정하기 위해서입니다. 특정 페이지의 본문만 깨졌는지, 공통 헤더와 메뉴까지 무너졌는지에 따라 되돌릴 대상이 달라집니다. 화면이 깨진 시각, 마지막 수정자, 수정한 페이지 URL, 사용한 관리자 계정도 한 문서에 모읍니다.
변경 전 백업은 파일과 데이터베이스를 함께 확인합니다
백업이 있다는 말만으로는 복구 기준이 정해지지 않습니다. 홈페이지 화면 깨짐이 콘텐츠 수정 뒤 발생했다면 파일 백업뿐 아니라 수정 전 데이터베이스 백업 시점도 확인해야 합니다. 페이지 내용, 메뉴 설정, 일부 사이트 설정은 데이터베이스에 저장되므로 파일만 되돌린 뒤에도 화면이나 내용이 이전과 다를 수 있습니다.
호스팅 관리 화면에 로그인할 권한이 있다면 백업 메뉴에서 백업 일시, 복원 가능한 대상, 복원 단위를 확인합니다. 화면에는 ‘전체 백업’, ‘파일’, ‘데이터베이스’처럼 구분되어 있을 수 있습니다. 가장 최근 백업이 아니라 문제가 생기기 직전의 정상 시점을 찾고, 그 시점 이후에 발행한 글·문의·신청 데이터가 있는지도 따로 적습니다.
관리자 화면에서 직접 백업을 만들었다면 백업 파일의 저장 위치와 다운로드 가능 여부를 확인합니다. 워드프레스 관리자 기능의 위치와 기본 관리 구조는 워드프레스 공식 문서에서 확인할 수 있습니다. 다만 실제 복원 버튼을 누르기 전에는 현재 상태를 별도 백업으로 한 번 더 남겨야 합니다. 복구 결과가 예상과 다를 때 현재 상태조차 비교할 수 없게 되는 일을 막기 위한 절차입니다.
복구 책임은 수정자와 백업 보관자를 나눠 확인합니다
복구를 요청할 때 “사이트가 깨졌습니다”만 전달하면 작업자가 원인을 추정하며 여러 곳을 열어 보게 됩니다. 수정 작업을 한 사람, 관리자 계정을 가진 사람, 호스팅 백업을 보관하는 사람, 도메인 DNS를 관리하는 사람은 서로 다를 수 있습니다. 각 역할이 다르면 복구 결정권도 한곳에 있지 않습니다.
- 수정자에게는 수정한 날짜, 페이지 URL, 변경한 항목, 저장 또는 배포 시점을 요청합니다.
- 호스팅 관리자에게는 복원 가능한 백업 일시와 파일·데이터베이스 복원 범위를 요청합니다.
- 도메인 관리자에게는 DNS 설정을 최근에 변경했는지와 관리 계정의 소유자를 확인합니다. 카페24를 이용 중이라면 도메인 DNS 연결 안내에서 연결 정보가 어느 계정에 있는지 대조합니다.
- 대표 또는 사이트 소유자는 어느 백업 시점으로 되돌릴지와 복구 뒤 확인할 페이지 목록을 확정합니다.
이 구분은 비용보다 먼저 정리할 내용입니다. 수정자가 원인을 확인할 책임과 백업 보관자가 복원 권한을 가진 사실은 별개입니다. 운영 담당자가 바뀌었거나 만든 업체와 연락이 끊겼다면, 관리자 계정·호스팅 계정·도메인 계정의 명의와 접근 권한부터 목록으로 정리해야 합니다. 업무별 담당과 산출물을 먼저 분리하는 방식은 그룹웨어·ERP 도입 전 업무정리: 진단 산출물 7가지에서도 같은 이유로 다룹니다.
복원 전에는 현재 화면과 변경 기록을 남깁니다
백업 복원은 수정 이후의 데이터를 되돌릴 수 있으므로, 복원 버튼을 누르기 전에 현재 상태를 기록해야 합니다. 첫 화면, 주요 서비스 페이지, 글 목록, 문의 페이지, 모바일 메뉴를 각각 캡처하고 URL을 붙입니다. 오류 문구가 보이면 문구 전체와 발생 화면을 함께 남깁니다.
복원 대상도 한 줄로 명확히 적습니다. 예를 들어 “특정 페이지의 본문 수정 직전 상태로 복원”과 “사이트 전체 파일 및 데이터베이스를 특정 시점으로 복원”은 전혀 다른 작업입니다. 전체 복원 전에 최근 문의나 새 글처럼 되돌아가면 안 되는 내용을 따로 내보내거나 복사해 둡니다.
매달 발행·호스팅·뉴스레터 운영이 한 사람의 기억에만 남아 있으면 이런 확인이 길어집니다. 워프로랩 매니지드 호스팅처럼 운영 기록과 관리 주체를 한 구독 범위에서 정리하는 방식은, 화면 이상이 생겼을 때 수정 이력과 복구 기준을 찾는 시간을 줄이는 데 쓰입니다.
정상 복구 뒤에는 검색 화면도 다시 점검합니다
복구가 끝났다고 작업이 끝난 것은 아닙니다. 시크릿 창과 모바일에서 주요 페이지가 정상으로 보이는지 다시 확인하고, 관리자 로그인 여부에 따라 화면이 달라지지 않는지도 확인합니다. 특히 제목, 본문, 메뉴 링크, 문의 양식, 이미지가 깨진 상태로 남지 않았는지 복구 전 캡처와 비교합니다.
검색 결과에 깨진 제목이나 이전 설명이 보인다면 Google Search Console에서 URL 검사 도구를 열고 해당 페이지 주소를 입력합니다. URL 검사 도움말의 절차에 따라 현재 URL 상태를 확인한 뒤, 페이지가 정상적으로 열리는 것을 확인한 다음 재색인을 요청합니다. 구글의 재크롤링 요청 안내도 이 순서를 설명합니다.
홈페이지 화면 깨짐은 눈에 보이는 부분만 고치는 일이 아니라, 정상 상태의 기준과 복구 책임을 되찾는 일입니다. 수정 전 백업 시점, 작업 이력, 계정 권한을 먼저 확인해야 다음 변경도 통제된 상태에서 진행됩니다.
함께 보면 좋은 글: 주의 요함 경고 복구 뒤 기록 4가지
참고 출처
자주 묻는 질문
화면이 깨졌는데 백업이 없으면 무엇부터 확인해야 하나요?
먼저 수정 작업을 중지하고 현재 화면을 URL별로 캡처합니다.
수정한 사람에게 변경 항목과 작업 시점을 확인합니다.
호스팅 계정에서 자동 백업 보관 여부와 복원 가능한 가장 이른 시점을 확인합니다.
홈페이지 전체를 복원하기 전에 확인할 내용은 무엇인가요?
복원 시점 이후에 발행한 글, 접수된 문의, 변경된 메뉴를 목록으로 적습니다.
파일만 복원하는지 데이터베이스까지 복원하는지 작업 범위를 문장으로 확정합니다.
현재 상태도 별도 백업으로 보관한 뒤 복원을 진행합니다.
복구 후 검색 결과가 이전 내용으로 보이면 바로 재색인을 요청해야 하나요?
먼저 시크릿 창과 모바일에서 복구한 페이지가 정상으로 열리는지 확인합니다.
그 다음 Search Console의 URL 검사에서 해당 주소 상태를 점검합니다.
정상 화면과 내용이 확인된 URL만 재색인 요청 대상으로 정리합니다.