워드프레스 관리자 화면 오류, 플러그인 충돌일까?
관리자 화면이 열리지 않으면 플러그인 충돌부터 떠올리기 쉽지만, 그 증상 하나로 원인을 정할 수는 없습니다. 글 작성이 멈추거나 사이트 화면까지 깨졌다면 무엇을 건드려야 할지 더 막막해집니다. 지금 보이는 관리자 화면 오류와 플러그인 충돌은 어디까지 연결해서 봐야 할까요?
먼저 짧게 답하면, 충돌인지는 플러그인을 꺼 보았을 때 증상이 달라지는지로 가릅니다. 관리자 화면에 들어갈 수 있으면 플러그인 화면에서 끄고, 들어갈 수 없으면 서버의 wp-content/plugins 폴더 이름을 바꿔서 끕니다. 두 방법은 아래에서 순서대로 적었습니다.
관리자 화면이 안 열리는데 왜?
플러그인 충돌이 생기면 관리자 화면이 열리지 않을 수 있습니다. 하지만 접속 실패만 보고 플러그인을 원인으로 확정해서는 안 됩니다. 관리자 화면은 플러그인만 따로 실행하는 공간이 아니라, 워드프레스와 설치된 기능이 함께 작동하는 공간입니다. 플러그인끼리 같은 기능에 관여하거나 서로 맞지 않는 방식으로 작동하면 화면을 불러오는 과정에 오류가 생길 수 있습니다.
오류가 시작된 시점에 플러그인을 설치하거나 업데이트했다면, 변경한 이름과 시각을 먼저 적어 둡니다. 같은 시점에 다른 설정도 바꿨다면 플러그인 변경만 떼어 원인으로 보기는 어렵습니다. 관리자 화면이 아예 열리지 않는지, 로그인은 되지만 특정 화면에서 멈추는지도 구분해 둡니다. 접속 여부만 적는 것보다 실패한 화면을 특정해야 이후 변경의 영향을 비교할 수 있습니다.
글 작성과 사이트 화면도 달라졌다면
관리자 화면이 열려도 글 작성이 되지 않는 현상은 플러그인 충돌 때 나타날 수 있습니다. 방문자가 보는 사이트 화면이 깨지는 현상도 같은 가능성에 들어갑니다. 글 작성 화면과 사이트 화면은 쓰임이 다르므로, 어느 쪽에 오류가 나타나는지 따로 봐야 합니다. 한쪽이 정상으로 보인다는 이유만으로 다른 쪽의 오류까지 없다고 볼 수는 없습니다.
이 가능성은 워드프레스 공식 문서에도 나옵니다. 문서의 문제 해결 FAQ는 “발행”이나 “임시 저장” 버튼이 동작하지 않을 때 플러그인을 하나씩 비활성화하며 원인을 찾으라고 안내합니다. 둘 이상의 플러그인이 같은 자원(예: 자바스크립트 라이브러리)을 쓰려다 부딪히는 경우가 흔하고, 브라우저 캐시 문제일 수도 있다고 덧붙입니다.
글 작성이 멈춘다면 어느 화면에서 어떤 작업을 할 때 멈추는지 살펴봅니다. 사이트 화면이 깨졌다면 문제가 보이는 페이지를 열어, 관리자 화면에서 보이는 상태와 구분합니다. 오류 메시지가 보인다면 문구를 그대로 남겨 두는 편이 증상을 전할 때 정확합니다. 화면이 중단됐다가 다시 열려도 메시지와 발생 시점은 이후의 변화와 대조할 근거가 됩니다.
오류 메시지가 뜨면 충돌일까?
오류 메시지가 나타나거나 웹사이트가 중단되는 일도 플러그인 충돌의 증상일 수 있습니다. 메시지가 있다는 사실은 오류가 드러난 위치를 알려 주지만, 원인 하나를 지목하지는 않습니다. 사이트가 중단됐다면 관리자 화면과 방문자 화면 가운데 어디까지 열리는지도 구분해야 합니다.
변경 직후 오류가 시작됐고 관리자 화면에 들어갈 수 있다면, 백업해 둔 뒤 해당 플러그인만 꺼서 화면 변화를 봅니다. 여러 플러그인을 한꺼번에 끄면 어떤 변경이 오류에 영향을 줬는지 가리기 어렵습니다. 저라면 사이트 화면까지 중단된 상황에서는 글 작성 테스트보다 방문자 화면이 다시 열리는지를 먼저 보겠습니다. 변경한 플러그인을 꺼도 증상이 그대로라면 다른 원인도 살펴야 하며, 접속 자체가 막혔다면 호스팅 업체에 증상과 변경 시점을 전합니다.
플러그인은 어디서 어떻게 끄나
위에서 “해당 플러그인만 꺼서 본다”고 했는데, 막상 어디서 끄는지 몰라 멈추는 분이 많을 것 같습니다. 관리자 화면에 들어갈 수 있는지에 따라 방법이 갈리므로 나눠서 적습니다. 어느 쪽이든 시작 전에 파일과 데이터베이스를 모두 백업해 두세요. 워드프레스 공식 문서도 업그레이드나 큰 변경 전에는 둘 다 백업하라고 권합니다.
관리자 화면에 들어갈 수 있을 때
- 방문자 화면과 글 작성 화면의 현재 증상을 기록합니다. 오류 문구와 발생 시각도 함께 적습니다.
- 관리자 메뉴의 플러그인 > 설치된 플러그인에서 직전에 설치하거나 업데이트한 플러그인 하나만 비활성화합니다.
- 방문자 화면, 글 작성 화면, 문제가 났던 화면을 다시 열어 증상이 달라졌는지 봅니다.
- 달라지지 않으면 그 플러그인을 다시 켜고, 다음 후보를 하나만 끄는 식으로 반복합니다. 변경한 플러그인이 없다면 공식 문서의 방식대로 전체를 끈 뒤 하나씩 켜는 방법도 있습니다.
하나씩 하는 이유는 앞에서 말한 것과 같습니다. 한꺼번에 끄면 증상이 사라져도 어느 플러그인 때문인지 알 수 없기 때문입니다.
관리자 화면이 열리지 않을 때
이때는 서버에서 직접 끕니다. 워드프레스 공식 문서가 안내하는 방법은 두 가지입니다. 저는 설정이 지워지지 않는 폴더 이름 변경 쪽이 부담이 적다고 봅니다.
- FTP 프로그램이나 호스팅의 파일 관리자로 사이트 폴더의
wp-content를 엽니다. plugins폴더 이름을plugins.hold처럼 바꿉니다. 모든 플러그인이 꺼집니다./wp-admin/에 로그인해 봅니다. 열린다면 플러그인이 원인에 가까운 것입니다. 플러그인이 없다는 안내가 보일 수 있지만 정상입니다.- 폴더 이름을
plugins로 되돌립니다. 이때 플러그인은 모두 꺼진 상태로 남습니다. - 플러그인 화면에서 직전에 변경한 것부터 하나씩 켜면서 어느 시점에 증상이 돌아오는지 봅니다.
특정 플러그인 하나만 의심된다면 wp-content/plugins 안에서 그 플러그인 폴더 이름만 바꾸는 방법도 있습니다. 데이터베이스를 다룰 줄 안다면 phpMyAdmin에서 wp_options 표의 active_plugins 값을 a:0:{}로 바꾸는 방법도 공식 문서에 있습니다. 다만 이 방법은 실수하면 되돌리기 어려우니 호스팅 업체의 도움을 받는 편이 안전합니다.
플러그인을 모두 꺼도 같은 증상이면 테마를 의심합니다. 관리자 화면이 열린다면 기본 테마로 바꿔 보고, 열리지 않는다면 wp-content/themes에서 현재 사용 중인 테마 폴더 이름을 바꾸는 방법이 공식 문서에 있습니다. 폴더 이름을 바꾸면 워드프레스가 기본 테마로 돌아갑니다.
자주 보이는 오류 문구가 뜻하는 것
문구를 그대로 남기라고 한 이유는, 문구마다 가리키는 방향이 조금씩 다르기 때문입니다. 아래는 워드프레스 공식 문서에서 다루는 대표적인 경우입니다.
| 보이는 증상 | 공식 문서가 드는 주된 원인 | 먼저 해볼 것 |
|---|---|---|
| 흰 화면(아무것도 안 보임) | 플러그인 호환성 문제, 테마 문제, PHP 오류나 데이터베이스 오류 | 플러그인 전체 비활성화, 기본 테마 전환, 디버그 로그 확인 |
| 500 Internal Server Error | 손상된 .htaccess가 가장 유력하고, 플러그인·테마·PHP 메모리 한도도 후보 | .htaccess를 .htaccess_old로 바꿔 열리는지 확인 |
| Cannot modify header information – headers already sent | PHP 파일 앞뒤의 공백이나 BOM | 문구에 적힌 파일과 줄 번호(output started at 뒤쪽)를 확인 |
| Briefly unavailable for scheduled maintenance | 자동 업데이트 중 생긴 .maintenance 파일 | 사이트 최상위 폴더의 .maintenance 파일 삭제 |
표에서 보듯 증상 이름만으로 플러그인을 확정할 수는 없습니다. 그래서 “충돌이다”보다 “플러그인을 껐더니 달라졌다”가 판단 근거로 더 믿을 만하다고 생각합니다.
화면에 아무 문구가 없을 때는 debug.log를 봅니다
흰 화면처럼 문구가 안 보일 때는 워드프레스의 디버그 기능으로 오류를 파일에 남길 수 있습니다. wp-config.php에서 /* That's all, stop editing! */ 주석 앞에 아래 세 줄을 넣습니다. 공식 문서는 운영 중인 사이트에서는 권장하지 않고 스테이징이나 백업을 갖춘 상태에서 쓰라고 하니, 확인이 끝나면 지우거나 false로 돌려 두세요.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );WP_DEBUG_DISPLAY를 false로 두면 방문자 화면에 오류가 노출되지 않고, 오류는 wp-content/debug.log에 쌓입니다. 증상을 한 번 재현한 뒤 이 파일의 마지막 부분을 열어 봅니다. 예를 들어 아래와 같은 줄이 있다면(형식을 보여 드리기 위한 예시입니다) 경로 중간의 폴더 이름이 오류가 난 플러그인을 가리킵니다.
PHP Fatal error: Uncaught Error: Call to undefined function example_function() in /wp-content/plugins/example-plugin/main.php:42이 로그 한 줄이 “충돌 같다”는 느낌보다 훨씬 구체적인 단서가 됩니다. 경로에 plugins가 있으면 해당 플러그인부터, themes가 있으면 테마부터 보면 됩니다. 로그에 아무것도 남지 않는다면 서버 설정 쪽 문제일 수 있으니 호스팅 업체에 문의하세요.
플러그인이 아닐 때는 이렇게 갈립니다
변경한 플러그인을 꺼도 그대로라면 아래 순서로 범위를 넓혀 갑니다. 플러그인을 먼저 보는 이유는 가장 쉽게 되돌릴 수 있기 때문입니다.
| 의심 대상 | 확인 방법 | 달라졌다면 |
|---|---|---|
| 플러그인 전체 | plugins 폴더 이름 변경 후 접속 | 플러그인이 원인에 가깝고, 하나씩 켜서 범위를 좁힙니다 |
| 테마 | 기본 테마로 전환 또는 테마 폴더 이름 변경 | 테마 코드나 테마 업데이트를 의심합니다 |
.htaccess | .htaccess_old로 이름 변경 후 접속 | 설정 > 고유주소를 다시 저장해 새 파일을 만듭니다 |
| PHP 메모리 한도 | 디버그 로그의 메모리 부족 문구, 한도 상향 후 재시도 | 공유 호스팅이면 업체에 상향을 요청해야 할 수 있습니다 |
| PHP 오류 또는 DB 오류 | 디버그 로그 확인 | 로그에 나온 파일 경로가 단서가 됩니다 |
플러그인이 너무 많아서 어디부터 꺼야 할지 모르겠다면 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것에서 정리한 기준으로 먼저 후보를 줄여 볼 수 있습니다.
끈 뒤에는 이 세 곳을 확인합니다
플러그인을 껐다고 끝이 아니라, 정말 달라졌는지 같은 조건에서 다시 봐야 합니다. 저는 아래 세 가지가 모두 통과해야 정상이라고 판단하겠습니다.
- 로그인 화면과 대시보드가 오류 없이 열린다.
- 새 글 작성 화면이 열리고, 임시 저장과 미리보기가 동작한다.
- 방문자 화면(메인과 글 하나)이 깨지지 않고 열린다. 로그아웃한 상태나 시크릿 창에서도 확인한다.
시크릿 창을 권하는 이유는 캐시와 로그인 상태의 영향을 줄이기 위해서입니다. 세 곳이 모두 정상으로 돌아왔다면 마지막에 껐던 플러그인이 원인 후보입니다. 그 플러그인의 업데이트나 대체 플러그인을 알아본 뒤, 변경 시각과 결과를 기록해 두세요.
관리자 화면 오류는 플러그인 충돌의 가능한 증상이지만, 변경한 플러그인을 따로 껐을 때 오류가 달라지는지 봐야 원인을 좁힐 수 있습니다.
이 글의 절차는 2026년 10월 11일에 워드프레스 공식 문서를 다시 읽고 정리했습니다. 메뉴 이름과 화면 구성은 워드프레스와 PHP 버전, 호스팅 환경에 따라 다를 수 있습니다. 참고한 문서는 다음과 같습니다.
