공식 문서 검토 · LPKit 편집팀 · 운영 사이트 재현 안 함 ·
플러그인 업데이트 직후 예약한 유지보수로 인해 잠시 사용할 수 없습니다 또는 Briefly unavailable for scheduled maintenance가 계속 보이면 플러그인 폴더나 파일 권한부터 바꾸지 마세요. 진행 중인 업데이트인지, WordPress core의 .maintenance 파일인지, 별도 유지보수 플러그인·호스팅 화면인지 먼저 구분해야 합니다.
가장 먼저 할 일
업데이트를 시작한 시각과 플러그인 이름을 기록하고, 작업이 아직 진행 중일 수 있으면 기다리세요. WordPress core는 루트의 .maintenance 파일에 담긴 시각이 10분보다 오래되지 않았을 때 유지보수 모드로 판단합니다.
업데이트가 중단되거나 실패한 것이 확인됐고 정확한 WordPress 기본 문구가 남았다면, FTP나 호스팅 파일 관리자로 WordPress 루트에 있는 .maintenance 파일 하나만 확인합니다. 파일이 없거나 화면이 다르거나 같은 현상이 되풀이되면 다른 파일을 지우지 말고 오류 문구와 업데이트 대상을 호스팅·플러그인 공식 지원에 전달하세요.
이 글에서 바로 찾기
이 글은 설치형 WordPress에서 플러그인 업데이트 직후 공개 사이트와 관리자 화면이 유지보수 문구로 막힌 사람을 위한 복구 안내입니다. 운영 사이트에서 업데이트 실패를 만들거나 파일을 삭제해 재현하지 않았으며, 2026년 8월 18일에 다시 확인한 WordPress 공식 문서와 core 코드 참조를 근거로 설명합니다.
업데이트 전 복구 기준이 없다면 워드프레스 파일과 데이터베이스 백업에서 완전 백업의 범위를 먼저 확인하세요. 아직 플러그인을 고르는 단계라면 워드프레스 플러그인 선택 체크리스트가 이 글보다 먼저입니다.
1. 화면 문구와 시작 시각부터 기록하세요
먼저 새로고침을 반복하지 말고 현재 화면을 캡처하거나 문구를 그대로 적습니다. 아래 상태는 해결 경로가 다릅니다.
| 지금 보이는 상태 | 우선 판단 | 이 글에서 할 일 |
|---|---|---|
| 플러그인 업데이트 직후 WordPress 기본 유지보수 문구가 보임 | core 업데이트 작업이 진행 중이거나 중단됐을 수 있음 | 시작 시각·플러그인·오류 문구를 기록하고 진행 여부 확인 |
| 로고·연락처·카운트다운이 있는 별도 안내 화면 | 유지보수 플러그인, 테마, 호스팅 또는 캐시가 만든 화면일 수 있음 | .maintenance를 원인으로 단정하지 말고 화면 소유자 확인 |
치명적인 오류, 500, 빈 화면, 데이터베이스 연결 오류 |
유지보수 파일과 다른 장애 | 정확한 오류 문구를 보존하고 해당 오류의 공식 지원 경로로 이동 |
| 공개 화면은 열리지만 관리자만 안 열림 | 로그인·권한·보안·관리자 경로 문제일 수 있음 | 유지보수 모드 해제 절차를 적용하지 않음 |
WordPress 공식 Common WordPress errors는 업데이트 뒤 기본 유지보수 문구가 남는 경우 루트의 .maintenance 파일이 제대로 제거되지 않았을 수 있다고 설명합니다. 반대로 화면이 브랜드 디자인이거나 문구가 다르다는 사실만으로 원인을 확정할 수는 없습니다.
다음 다섯 항목을 적어 두세요.
- 업데이트를 누르거나 자동 업데이트 알림을 받은 시각
- 플러그인의 정확한 이름과 업데이트 전·목표 버전
- 화면에 나온 문구 전체와 HTTP 오류가 있다면 그 번호
- 공개 화면과
/wp-admin/중 막힌 범위 - 호스팅 제어판·이메일·WordPress 알림에 남은 실패 문구
비밀번호, 2단계 인증 코드, API 키, 데이터베이스 접속 정보는 캡처와 지원 요청에서 가립니다.
2. 업데이트가 진행 중일 수 있으면 먼저 기다리세요
WordPress core의 WP_Upgrader::maintenance_mode()는 업데이트를 시작할 때 WordPress 루트에 .maintenance 파일을 만들고, 정상 종료 단계에서 이 파일을 지웁니다. wp_is_maintenance_mode()는 파일 안의 $upgrading 시각이 10분보다 오래되지 않았을 때 유지보수 모드를 활성 상태로 판단합니다.
따라서 업데이트를 누른 직후에는 파일을 바로 지우지 마세요. 파일 복사나 압축 해제가 진행 중인데 유지보수 표시만 먼저 없애면 방문자가 작업 중인 사이트에 접근할 수 있습니다.
다만 10분은 모든 사이트가 반드시 정상화되는 보장 시간이 아닙니다. core 코드가 한 번 생성된 유지보수 파일을 판정하는 기준입니다. 10분이 훨씬 지난 뒤에도 같은 화면이 계속되면 다음 가능성을 함께 봐야 합니다.
- 백그라운드 업데이트가 반복되며 파일 시각이 새로 쓰이고 있음
- 화면이 WordPress core가 아니라 플러그인·호스팅이 만든 유지보수 페이지임
- 프록시나 캐시가 이전 응답을 보여 줌
- 서버 시각·파일 내용·업데이트 프로세스를 현재 사용자에게서 확인할 수 없음
진행 여부를 확인할 수 없다면 추측해서 파일을 지우지 말고 호스팅 지원에 “현재 업데이트 프로세스가 끝났는지”부터 물어보세요.
3. 중단이 확인되면 .maintenance 파일 하나만 처리하세요
업데이트가 멈췄거나 실패한 것이 확인됐고 WordPress 기본 유지보수 문구가 남았다면, 공식 문서는 FTP로 WordPress 디렉터리의 .maintenance 파일을 삭제하라고 안내합니다. 호스팅 파일 관리자를 쓰는 경우에도 대상은 같습니다.
- 현재 사이트의 파일과 데이터베이스 백업 시각, 복원 담당자를 확인합니다.
- FTP 또는 호스팅 파일 관리자로 현재 사이트의 WordPress 루트를 엽니다.
wp-admin,wp-content,wp-includes,wp-config.php가 있는 같은 위치인지 확인합니다.- 점으로 시작하는 숨김 파일 표시를 켜고 파일명이 정확히
.maintenance인지 확인합니다. - 작업 이력이 필요하면 이 파일을 먼저 내려받거나
.maintenance.lpkit-hold-20260818처럼 이름을 바꿔 복구 가능하게 둡니다. - 공개 화면과
/wp-admin/을 다시 열어 유지보수 문구가 사라졌는지 확인합니다.
5번의 “먼저 내려받거나 이름을 바꾸기”는 WordPress의 필수 규칙이 아니라, 삭제를 되돌릴 수 있게 만드는 LPKit 운영 권장사항입니다. 공식 문서의 직접 조치는 .maintenance 삭제입니다.
아래 항목은 이 단계에서 건드리지 마세요.
wp-content/plugins안의 플러그인 폴더 전체maintenance.php,wp-config.php,.htaccess- 파일·폴더 권한을
777로 바꾸는 작업 - 데이터베이스 옵션과 자동 업데이트 설정
- 같은 업데이트 버튼을 오류 원인 확인 없이 반복해서 누르는 작업
여러 WordPress가 같은 호스팅 계정에 있으면 다른 사이트의 루트를 열 수 있습니다. 도메인과 문서 루트 매핑을 모르면 파일을 변경하지 말고 호스팅에 확인하세요.
4. 화면이 돌아오면 업데이트 성공 여부를 따로 확인하세요
유지보수 문구가 사라진 것은 업데이트가 성공했다는 증거가 아닙니다. WordPress 공식 Manage Plugins 문서에 따라 관리자에서 현재 플러그인 버전과 업데이트 알림을 다시 확인하세요.
아래 순서로 기록합니다.
플러그인 > 설치한 플러그인에서 대상 플러그인이 활성 상태인지 확인- 현재 버전이 업데이트 목표 버전인지, 아직 업데이트 알림이 남았는지 확인
알림판 > 업데이트에서 실패 또는 재시도 안내 확인- 로그아웃한 창에서 홈, 글 한 편, 문의·결제처럼 중요한 기능을 직접 확인
- 플러그인의 핵심 기능과 관리자 설정 화면을 한 번 확인
- 오류 로그나 호스팅 이벤트 기록에 같은 시각의 실패 원인이 있는지 확인
워드프레스 관리자 화면 보는 법에서 알림판·플러그인·설정의 위치를 먼저 익힐 수 있습니다.
플러그인이 이전 버전으로 남았거나 업데이트 알림이 계속 보이면 같은 작업을 즉시 반복하지 마세요. 백업·호환 조건·정확한 오류 문구를 갖춘 뒤 플러그인 제작자 또는 호스팅의 공식 안내에 따라 다음 조치를 정합니다.
5. 파일이 없거나 화면이 되풀이되면 원인 소유자를 찾으세요
WordPress 루트에 .maintenance가 없는데 화면이 남아 있거나, 파일을 처리한 뒤 곧바로 같은 화면이 돌아오면 단일 잔여 파일만의 문제로 끝내지 않습니다.
| 확인 결과 | 다음 책임자 | 전달할 것 |
|---|---|---|
| 특정 플러그인 업데이트에서만 재발 | 해당 플러그인의 공식 지원 | 플러그인 이름·이전/목표 버전·정확한 오류·재발 시각 |
| 여러 플러그인·core·테마 업데이트에서 반복 | 호스팅 또는 서버 관리자 | 파일 시스템 접근·용량·권한·프로세스 로그 확인 요청 |
.maintenance 없이 브랜드 유지보수 화면 |
유지보수 플러그인·테마·호스팅 화면 소유자 | 화면 캡처·URL·켜진 시각·관리자 접근 여부 |
| 기본 문구가 사라진 뒤 치명적 오류나 500 발생 | 플러그인 제작자와 호스팅 | 새 오류 문구·로그·백업 시각·변경한 파일 한 개 |
| 관리자 권한이나 파일 접근 권한이 없음 | 사이트 소유자 또는 계약상 운영 담당자 | 관찰 기록만 전달하고 권한 공유·우회 금지 |
WordPress core의 일반 오류 문서는 자동 업데이트가 연결 문제, 인터넷 연결, 파일 권한 때문에 실패할 수 있다고 예시를 듭니다. 하지만 현재 사이트의 실제 원인은 로그와 환경을 보지 않고 확정할 수 없습니다. 메모리 부족, 디스크 부족, 권한 오류, 플러그인 결함 중 하나라고 추측해 설정부터 바꾸지 마세요.
6. 다음 업데이트 전에는 복구 기준을 먼저 만드세요
WordPress 공식 Updating WordPress와 Manage Plugins 문서는 업데이트 전에 현재 백업을 준비하라고 안내합니다. 일반적인 전체 복구에는 파일과 데이터베이스가 모두 필요합니다.
다음 업데이트 전 체크리스트를 채우세요.
업데이트 대상과 현재/목표 버전:
공식 변경 기록과 호환 조건:
파일 백업 시각과 위치:
데이터베이스 백업 시각과 위치:
복원 담당자와 복원 방법:
업데이트 시작 예정 시각:
확인할 공개 페이지와 핵심 기능:
실패 시 연락할 플러그인·호스팅 공식 지원:
백업 파일이 존재한다는 사실과 실제로 복원할 수 있다는 것은 다릅니다. 운영 사이트라면 복원 담당자와 방법을 함께 정하고, 가능하면 staging에서 업데이트와 핵심 기능을 먼저 확인하세요. staging 사용은 WordPress core의 의무가 아니라 운영 위험을 낮추기 위한 LPKit 권장사항입니다.
7. 지원 요청에는 이 내용을 보내세요
아래 요청문을 복사해 민감정보 없이 채우세요.
사이트 주소:
문제 발생 시각과 시간대:
업데이트 대상 플러그인:
업데이트 전 버전 / 목표 버전 / 현재 표시 버전:
수동 업데이트 / 자동 업데이트 여부:
화면의 정확한 문구와 HTTP 상태:
공개 화면 / wp-admin 영향 범위:
.maintenance 확인 결과: 있음 / 없음 / 확인 권한 없음
내가 변경한 항목: 없음 / .maintenance 이름 변경 또는 삭제
파일+데이터베이스 백업 시각:
오류 로그의 같은 시각 항목:
요청: 업데이트 프로세스 종료 여부, 실패 원인, 안전한 재시도 또는 복원 경로 확인
관리자 비밀번호, FTP·SSH 비밀번호, 2단계 인증 코드, API 키, 전체 wp-config.php를 보내지 마세요. WordPress core 동작이 불명확하면 WordPress.org Support Forums에 정확한 문구와 환경을 공개 가능한 범위에서 묻고, 상용 플러그인은 제작사의 공식 지원 계정으로 문의합니다.