워드프레스 업데이트 후 관리자 메뉴만 작동하지 않을 때 확인할 순서
업데이트 직후 워드프레스 사이트는 정상적으로 열리는데 관리자 화면의 특정 버튼이나 메뉴만 작동하지 않는 경우가 있습니다. 블록 편집기가 빈 화면으로 표시되거나, 설정 저장 버튼이 계속 로딩 상태에 머물고, 미디어 선택 창이 열리지 않는 식입니다.
이런 증상은 서버 전체가 멈춘 것과는 다릅니다. 관리자 페이지를 생성하는 PHP 처리는 정상이어도, 화면 안에서 동작을 담당하는 JavaScript 파일이 오래된 상태이거나 오류를 내면 일부 기능만 고장 날 수 있습니다. 따라서 워드프레스를 곧바로 다시 설치하기보다 캐시와 정적 파일, 플러그인, API 요청을 낮은 위험 순서대로 점검하는 편이 효율적입니다.
관리자 화면만 부분적으로 멈추는 구조적 이유
워드프레스 관리자 화면은 서버에서 HTML을 만들어 보내는 PHP와 브라우저에서 상호작용을 처리하는 JavaScript가 함께 작동합니다. 블록 편집기, 미디어 라이브러리, 설정 저장, 동적 목록처럼 사용자의 입력에 즉시 반응해야 하는 기능은 JavaScript와 REST API 요청에 크게 의존합니다.
업데이트 과정에서 워드프레스 Core 파일은 새 버전으로 바뀌었지만 브라우저나 캐시 플러그인, CDN에 이전 JavaScript가 남아 있으면 서로 다른 버전의 파일이 조합될 수 있습니다. 이때 기본 관리자 페이지는 열리지만 특정 함수가 실행되지 않거나, 서버에 보내는 요청이 실패해 버튼이 반응하지 않는 현상이 나타납니다.
플러그인이 관리자 화면에 추가한 JavaScript 또는 PHP 코드가 새 워드프레스 버전과 맞지 않는 경우도 있습니다. 이 문제는 사이트 전체를 중단시키지 않고 특정 플러그인 설정 화면이나 편집기에서만 발생할 수 있습니다. 그러므로 “관리자에 로그인할 수 있다”는 사실만으로 업데이트가 완전히 정상이라고 보기는 어렵습니다.
가장 먼저 브라우저와 캐시 계층을 나눠서 확인하기
첫 단계는 브라우저의 영향을 배제하는 것입니다. 관리자 페이지를 일반 새로고침한 뒤 문제가 계속되면 강력 새로고침을 시도하고, 필요하다면 해당 사이트의 캐시를 삭제한 후 다시 접속합니다. 시크릿 또는 프라이빗 브라우징 창에서 같은 관리자 기능을 실행해 보는 방법도 유용합니다.
일반 창에서는 문제가 생기지만 시크릿 창에서는 정상이라면 서버보다 기존 브라우저 캐시나 확장 프로그램을 의심할 수 있습니다. 이 경우 모든 설정을 바꾸기보다 확장 프로그램을 잠시 비활성화하거나 다른 브라우저에서 동일한 동작을 비교하는 편이 원인 파악에 도움이 됩니다.
브라우저 캐시를 지워도 변화가 없다면 워드프레스 캐시 플러그인을 확인합니다. 다음과 같은 최적화 기능이 활성화되어 있다면 업데이트 전 생성된 파일이 계속 제공될 수 있습니다.
- JavaScript 축소 및 결합
- JavaScript 실행 지연
- CSS 축소 및 최적화
- 페이지 캐시
우선 전체 캐시를 비운 다음 관리자 화면을 다시 확인합니다. 그래도 문제가 남으면 최적화 기능을 한꺼번에 모두 변경하지 말고 하나씩 임시로 해제하면서 어떤 설정에서 증상이 사라지는지 비교해야 합니다. 원인을 찾은 뒤에는 단순히 기능을 계속 꺼두기보다 충돌을 일으킨 파일 제외 설정이나 최적화 방식 변경이 가능한지 확인하는 것이 좋습니다.
CDN을 사용하는 경우에는 세 번째 캐시도 점검하기
사이트가 CDN을 사용한다면 파일 전달 경로는 대략 워드프레스 서버, CDN, 사용자 브라우저 순서가 됩니다. 서버에서 새 JavaScript와 CSS를 배포했더라도 CDN에 이전 정적 파일이 남아 있으면 방문자는 계속 과거 버전을 받을 수 있습니다.
워드프레스 업데이트 직후 문제가 시작됐다면 CDN 캐시를 비우고 관리자 페이지를 다시 열어 봅니다. 특히 JavaScript나 CSS를 CDN에서 직접 제공하도록 구성한 경우에는 해당 정적 파일이 실제로 새 버전으로 갱신되었는지 확인해야 합니다.
| 계층 | 이 계층이 원인일 때 단서 | 비우는 방법 |
|---|---|---|
| 브라우저 | 시크릿 창에서는 정상 | 강력 새로고침, 사이트 캐시 삭제 |
| 확장 프로그램 | 다른 브라우저에서는 정상 | 일시 비활성화 후 비교 |
| 워드프레스 캐시 플러그인 | JS 축소·결합·지연을 끄면 정상 | 전체 캐시 비우기, 최적화 항목별 해제 |
| CDN | 서버에는 새 파일, 브라우저에는 옛 파일 | CDN 캐시 퍼지 후 정적 파일 갱신 확인 |
캐시를 삭제한 뒤 문제가 사라졌다면 어느 계층의 캐시가 원인이었는지 기록해 두는 것이 좋습니다. 다음 업데이트 때 브라우저 캐시만 비우고 CDN 캐시를 놓치는 식의 반복을 줄일 수 있기 때문입니다.
플러그인과 테마 충돌은 삭제보다 비활성화로 좁힌다
캐시를 정리해도 문제가 계속된다면 플러그인 충돌을 확인합니다. 업데이트 직후 문제가 발생했다면 최근에 변경된 플러그인과 오랫동안 업데이트되지 않은 플러그인을 우선 살펴볼 수 있습니다. 관리자 화면에 JavaScript를 추가하는 플러그인, 편집기 확장 기능, 보안·캐시 관련 플러그인은 특히 해당 화면의 동작에 영향을 줄 수 있습니다.
대표적인 증상은 다음과 같습니다. 버튼을 눌러도 아무 반응이 없거나, 설정 저장이 끝나지 않고, 블록 편집기가 빈 화면으로 나타나며, 미디어 선택 창이 열리지 않을 수 있습니다. 특정 플러그인의 관리자 화면에서만 오류가 난다면 해당 플러그인을 우선적인 조사 대상으로 볼 근거가 생깁니다.
원인 확인을 위해 플러그인을 바로 삭제할 필요는 없습니다. 먼저 백업 상태를 확인한 뒤 하나씩 비활성화하고 문제가 사라지는지 비교합니다. 비활성화와 삭제는 다릅니다. 일부 플러그인은 삭제 과정에서 설정이나 관련 데이터를 정리할 수 있으므로 운영 사이트에서 원인도 모른 채 전부 삭제하는 것은 위험합니다.
가능하다면 스테이징 환경에서 워드프레스 Core, 테마, 플러그인을 조합해 충돌 여부를 확인합니다. 플러그인 비활성화로 문제가 해결됐다면 현재 워드프레스 버전과의 호환성, 최근 업데이트 내역, 대체 플러그인 유무를 함께 검토해야 합니다. 테마의 사용자 정의 코드도 관리자 화면에 영향을 줄 수 있으므로 플러그인만 원인이라고 단정해서는 안 됩니다.
개발자 도구로 화면 오류와 요청 실패를 구분하기
Console: 새로 발생한 오류만 본다
추측만으로 범위를 줄이기 어렵다면 Chrome 등 브라우저의 개발자 도구를 엽니다. 관리자 페이지에서 문제가 되는 동작을 다시 실행하면서 Console 영역에 새로 표시되는 JavaScript 오류를 확인합니다.
오류 메시지에 특정 플러그인의 JavaScript 파일 이름이나 경로가 반복해서 나타난다면 해당 플러그인을 의심할 수 있습니다. 다만 콘솔에 표시되는 모든 빨간색 메시지가 현재 문제의 원인은 아닙니다. 기존부터 있던 경고나 브라우저 확장 프로그램이 만든 오류가 함께 보일 수 있으므로, 페이지를 새로고침한 뒤 문제가 되는 버튼을 눌렀을 때 새로 발생한 메시지에 집중해야 합니다.
Network: 실패한 요청의 상태 코드
Console에서 단서가 부족하면 Network 탭을 확인합니다. 관리자 페이지를 새로고침한 뒤 실패한 요청이 있는지 보고, 문제가 발생하는 동작을 다시 실행합니다. 상태 코드에 따라 조사 방향이 달라집니다.
- 404 Not Found: 필요한 JavaScript나 기타 리소스를 찾지 못하는 상황일 수 있습니다.
- 403 Forbidden: 보안 플러그인, 서버 설정, 방화벽 또는 WAF가 요청을 차단했을 가능성이 있습니다.
- 500 Internal Server Error: 요청을 처리하는 서버 측 PHP나 기타 처리 과정에 문제가 있을 수 있습니다.
화면이 멈췄다는 결과만 보는 것보다 어떤 파일과 요청에서 실패했는지를 확인하면 캐시 문제인지, 플러그인 코드 문제인지, 서버 문제인지 구분하기가 훨씬 쉬워집니다.
REST API와 PHP 로그까지 확인해야 하는 경우
최근 워드프레스 관리자 기능은 REST API를 통해 데이터를 읽고 저장하는 경우가 많습니다. 일반 페이지는 정상적으로 열리는데 REST API 요청이 보안 플러그인, 서버 방화벽, WAF 또는 사용자 정의 코드에 의해 차단되면 편집기나 설정 화면의 일부 기능만 작동하지 않을 수 있습니다.
관리자 화면의 도구 → 사이트 건강에서 REST API 관련 오류가 감지되는지 확인합니다. 오류가 있다면 보안 플러그인을 무조건 끄기보다 어떤 요청과 규칙이 차단되었는지 먼저 확인해야 합니다. 정상적인 워드프레스 요청만 필요한 범위에서 허용하는 방식이 안전합니다.
JavaScript 문제처럼 보여도 실제 원인은 서버의 PHP 오류일 수 있습니다. 브라우저가 서버에 데이터를 요청했지만 PHP에서 예외가 발생하면 사용자는 버튼이 작동하지 않는 것으로 인식하게 됩니다. 이때는 서버의 PHP 오류 로그나 워드프레스 디버그 로그를 확인합니다.
WP_DEBUG와 관련된 디버깅 기능을 사용할 수 있지만 운영 사이트에서 오류를 방문자 화면에 그대로 표시하는 것은 피해야 합니다. 서버 경로와 내부 설정 같은 정보가 노출될 수 있으므로 운영 환경에서는 오류를 화면 대신 로그에 기록하는 방식으로 조사하는 편이 안전합니다.
Core 재설치 전 백업과 확인 순서
업데이트 중 연결이 끊겼거나 서버 문제로 일부 파일이 정상적으로 교체되지 않았을 가능성도 있습니다. 다만 브라우저 캐시, 최적화 설정, CDN, 플러그인, API, 로그를 확인하기 전에 Core 재설치부터 진행하는 것은 권장하기 어렵습니다.
관리자 화면에서 현재 워드프레스 버전을 확인하고, 필요한 경우 백업 후 동일 버전의 Core 파일을 다시 설치하는 방법을 검토할 수 있습니다. 이 과정에서는 데이터베이스와 사이트 파일을 복구할 수 있는지 먼저 확인해야 합니다. Core 파일을 직접 수정한 사이트라면 재설치 과정에서 변경 내용이 사라질 수 있으므로 별도로 보존해야 합니다. 원칙적으로 기능 추가는 Core 직접 수정 대신 테마, 자식 테마 또는 플러그인을 이용하는 편이 안전합니다.
실제 점검 순서는 다음처럼 작은 변경부터 시작하는 것이 좋습니다. 브라우저 캐시와 확장 프로그램을 확인하고, 워드프레스 캐시와 JavaScript 최적화를 점검한 뒤 CDN 캐시를 비웁니다. 이후 플러그인과 테마를 비활성화 방식으로 비교하고, Console과 Network의 오류를 확인합니다. 그 다음 사이트 건강의 REST API 상태와 PHP 로그를 살펴본 뒤에도 원인이 남을 때 Core 파일 상태를 검토합니다.
문제가 해결된 뒤에는 어떤 조치로 증상이 사라졌는지 기록합니다. JavaScript 지연 기능을 끈 뒤 해결됐다면 해당 설정을 그대로 방치하기보다 충돌 파일을 제외할 수 있는지 확인하고, 플러그인 비활성화가 원인이었다면 호환성 정보를 점검합니다. 업데이트 전 데이터베이스와 사이트 파일 백업을 준비하고, 플러그인과 사용자 정의 코드가 많은 사이트는 운영 환경에 적용하기 전에 스테이징에서 먼저 테스트하면 같은 문제의 영향 범위를 줄일 수 있습니다.
