워드프레스 관리자 화면이 느릴 때 먼저 확인할 것
워드프레스 관리자 화면이 느릴 때 캐시 플러그인부터 설치하면 점검 대상만 늘어날 수 있습니다. 최근 플러그인을 설치하거나 업데이트했다면, 그 변경이 관리자 영역에도 영향을 주는지 살펴볼 만합니다. 방문자 화면은 괜찮은데 글 편집과 메뉴 이동만 느리다면 어디부터 손대야 할까요?
이 글의 공식 문서 내용은 2026년 10월 10일에 다시 확인했습니다. 글 안의 응답 시간과 요청 수는 이해를 돕기 위한 예시이고, 제 사이트에서 잰 값이 아닙니다. 메뉴 이름은 워드프레스 버전과 언어 설정에 따라 조금 다를 수 있습니다.
관리자 화면에서도 플러그인이 실행됩니다
일부 플러그인은 방문자에게 보이는 페이지뿐 아니라 관리자 영역에서도 실행되며 리소스를 사용합니다. 관리자 화면에서 실행되는 작업이 늘면 메뉴 이동이나 글 편집이 느려지는 원인 후보가 됩니다. 방문자 화면을 빠르게 만드는 캐시 설정만 바꿔서는 관리자 영역의 작업량이 줄지 않습니다.
관리자 영역에서 어떤 방식으로 일이 늘어나는지 감을 잡아 두면 점검이 쉬워집니다. 워드프레스 핸드북의 Heartbeat API 문서에 따르면, Heartbeat는 브라우저가 15초에서 120초 사이 간격으로 서버에 신호를 보내고 응답을 받는 방식입니다. 서버에서는 admin-ajax 핸들러가 이 요청을 받아 처리합니다. 플러그인이 이 요청에 자기 데이터를 얹거나 응답을 가공하면, 화면을 열어 둔 동안 요청이 반복될 때마다 그 작업이 서버에서 실행됩니다.
실제로 요청이 많은지는 브라우저 개발자 도구에서 볼 수 있습니다.
- 글 편집 화면을 열고 F12로 개발자 도구를 연 뒤 Network 탭으로 갑니다.
- Network 탭의 필터에
admin-ajax를 입력하고, 페이지를 새로고침한 뒤 편집 화면을 5분 정도 그대로 둡니다. - 요청이 몇 번 찍혔는지, 각 요청의 소요 시간(Time)이 몇 ms인지 적어 둡니다. 요청 하나가 수백 ms 이상 걸리거나, 특정 시점에 요청이 몰린다면 그 시점에 도는 작업을 의심해 볼 수 있습니다.
이 숫자는 뒤에서 플러그인을 하나씩 꺼 볼 때 비교 기준이 되기 때문에 먼저 적어 두시길 권합니다.
플러그인이 몇 개인지가 궁금하셨다면 워드프레스 플러그인 몇 개가 적당한지보다 중요한 것에서 개수보다 먼저 볼 기준을 정리해 두었습니다.
관리자 화면에 들어갈 수 있다면 최근 설치하거나 업데이트한 플러그인부터 살펴보십시오. 변경 시점과 느려지기 시작한 시점이 가깝다면 시험할 대상을 좁힐 수 있습니다. 설치된 플러그인 전체를 한꺼번에 끄면 어느 변경이 영향을 줬는지 가리기 어렵습니다.
기본 플러그인 목록에는 설치일이나 마지막 업데이트 날짜를 보여 주는 열이 없습니다. 그래서 저는 아래 세 곳을 함께 봅니다.
- 플러그인 > 설치된 플러그인: 업데이트가 있는 플러그인은 항목 아래에 안내가 표시됩니다. 최근에 비활성화한 항목은 상단 필터의 ‘최근 활성화됨’에서 따로 볼 수 있습니다.
- FTP 또는 호스팅 파일 관리자: wp-content/plugins 폴더를 수정 날짜순으로 정렬하면 최근 바뀐 플러그인이 위로 옵니다.
- 도구 > 사이트 건강 > 정보: 활성·비활성 플러그인의 버전을 한눈에 볼 수 있습니다. Site Health 문서에 따르면 이 화면에는 정보를 클립보드로 복사하는 기능도 있으니, 시험 전 상태를 기록해 두는 데 쓸 만합니다.
최근 바꾼 플러그인은 꺼 봅니다
저라면 관리자 화면이 느린 상황에서는 새 캐시 설정을 더하기보다 최근 바꾼 플러그인 1개를 시험하겠습니다. 플러그인 목록에서 최근 설치하거나 업데이트한 대상을 골라, 현재 설정을 적어 둔 뒤 비활성화합니다. 비활성화는 실행을 멈추는 조치이며, 플러그인 파일을 제거하는 삭제와는 다릅니다. 해당 플러그인이 맡던 기능은 시험하는 동안 방문자 화면에서도 멈출 수 있습니다.
설정을 적어 두라고 한 이유는, 플러그인에 따라 다시 켰을 때 옵션이 그대로 남는지가 다르기 때문입니다. 설정 화면을 캡처해 두거나 옵션 값을 메모장에 옮겨 두면 충분합니다. 비활성화는 보통 설정을 지우지 않지만, 삭제 단계에서 데이터를 함께 지우는 플러그인도 있어 이 기록이 도움이 됩니다.
비활성화한 뒤에 관리자 화면이 아예 열리지 않거나 오류 화면이 뜨는 경우도 있습니다. 이럴 때는 FTP나 호스팅 파일 관리자에서 wp-content 폴더의 plugins 폴더 이름을 plugins.hold처럼 바꿉니다. 워드프레스 FAQ Troubleshooting 문서가 소개하는 방법으로, 이렇게 하면 모든 플러그인이 꺼진 상태로 관리자에 로그인할 수 있습니다. 로그인한 뒤 폴더 이름을 plugins로 되돌리면 플러그인 설정은 보존되고, 플러그인은 모두 비활성화된 상태로 남아 하나씩 다시 켤 수 있습니다. 같은 문서에는 phpMyAdmin에서 wp_options 테이블의 active_plugins 값을 a:0:{}로 바꾸는 방법도 있지만, 데이터베이스를 직접 만지는 작업이라 파일 이름 변경이 안 될 때 쓰시길 권합니다.
같은 관리자 화면을 다시 열어 메뉴 이동이나 편집 화면의 반응이 달라졌는지 살펴보십시오. 개선됐다면 비활성화한 플러그인이 원인 후보이므로, 다시 켜기 전에 맡고 있던 기능을 점검합니다. 차이가 없다면 그 플러그인을 다시 켜고, 최근 바꾼 다른 플러그인을 하나씩 시험합니다. 변경 뒤마다 같은 화면을 비교하면 여러 조치의 효과가 뒤섞이지 않습니다.
“반응이 달라졌는지”를 느낌으로만 보면 판단이 흔들리기 쉽습니다. 그래서 앞에서 연 Network 탭에서 같은 편집 화면을 같은 조건(같은 글, 같은 브라우저, 캐시 비우기 상태)으로 열고 아래 값을 비교합니다. 숫자는 이렇게 기록할 수 있다는 예시입니다.
| 시험 단계 (예시) | 편집 화면 Finish (예시) | admin-ajax 요청 수, 5분 (예시) | 가장 느린 요청 (예시) |
|---|---|---|---|
| 변경 전 (기준) | 약 6.2초 | 12회 | 약 900ms |
| 플러그인 A 비활성화 | 약 6.0초 | 11회 | 약 880ms |
| 플러그인 B 비활성화 | 약 2.8초 | 5회 | 약 240ms |
이 예시에서는 B를 껐을 때만 시간과 요청이 함께 줄었으므로 B를 원인 후보로 봅니다. 반면 A처럼 몇 퍼센트 차이는 같은 조건에서 반복해도 흔들릴 수 있어 원인이라고 보기 어렵습니다. 저는 같은 화면을 2~3번 열어 보고 값이 비슷하게 나오는지 확인한 뒤 판단하길 권합니다. 서버 응답 시간(TTFB)에는 web.dev가 제시하는 대략적인 기준이 있습니다. 0.8초 이하면 좋음, 1.8초 초과면 나쁨으로 보며, 이는 방문자 화면 기준의 가이드라서 관리자 화면에 그대로 적용할 값은 아닙니다. 관리자 화면에서는 위 표처럼 전후 변화량을 보는 편이 더 쓸모 있습니다.
어떤 플러그인이 관리자에서 부담이 되는지는 종류별로 확인할 지점이 다릅니다. 아래 표는 특정 제품의 측정 결과가 아니라 점검할 때 먼저 떠올릴 관점을 정리한 것이며, 실제 영향은 플러그인과 설정에 따라 달라집니다.
| 플러그인 유형 | 관리자에서 확인할 점 | 끄기 전에 알아 둘 점 |
|---|---|---|
| 백업 | 백업이 예약된 시각에 관리자가 느려지는지, 설정이 파일·DB를 얼마나 포함하는지 | 끄는 동안 백업이 멈추므로 시험 전에 수동 백업을 한 번 받아 둡니다. |
| 보안 스캔 | 대시보드를 열 때마다 검사나 외부 조회를 하는지, 실시간 감시 옵션이 켜져 있는지 | 끄는 동안 보호 기능이 멈추므로 짧게 시험하고 바로 켭니다. |
| 페이지 빌더 | 편집 화면에서 불러오는 스크립트 양, 편집기에서만 느린지 | 끄면 빌더로 만든 글이 깨져 보일 수 있습니다. |
| 통계·SEO 대시보드 위젯 | 대시보드 첫 화면에 위젯이 많은지, 외부 서비스 호출이 있는지 | 위젯 표시 옵션만 꺼도 비교할 수 있는지 먼저 봅니다. |
일반적인 절차가 잘 통하지 않는 경우도 있습니다. 최근 바꾼 플러그인을 다 꺼 봐도 숫자가 그대로라면 원인이 플러그인이 아닐 수 있습니다. 호스팅 쪽 자원이 부족한 경우이거나, 여러 플러그인이 조금씩 부담을 나눠 가진 경우가 이에 해당합니다. 이때는 아래 호스팅 문의 단계로 넘어가는 편이 낫습니다.
그대로 느리다면 관리 상태를 봅니다
최근 변경한 플러그인을 꺼도 반응이 같다면 워드프레스 업데이트 상태를 살펴보십시오. 업데이트가 남아 있다면 백업을 준비한 뒤, 해당 업데이트 안내에 맞춰 진행합니다. 업데이트 점검은 최근 플러그인 변경을 시험하는 일과 다른 갈래입니다.
업데이트 현황은 대시보드 > 업데이트에서 워드프레스 본체, 플러그인, 테마를 한 번에 볼 수 있습니다. 도구 > 사이트 건강의 상태 탭에도 업데이트가 밀린 플러그인이 있으면 ‘플러그인 업데이트 대기’ 같은 항목이 표시됩니다. 같은 문서에서 오래된 PHP 버전도 성능과 보안 면에서 갱신이 필요한 항목으로 소개합니다. 업데이트가 속도와 이어질 수 있는 이유는 새 버전에 버그 수정이나 성능 개선이 담길 수 있기 때문입니다. 다만 모든 업데이트가 그렇지는 않으니 업데이트 전에 플러그인의 변경 내역을 읽어 보십시오.
백업은 파일(특히 wp-content)과 데이터베이스를 함께 받아 두는 것을 뜻합니다. 워드프레스 문서도 업그레이드 전에는 파일과 데이터베이스를 모두 백업하라고 안내합니다.
사용하지 않는 플러그인도 목록에서 가려냅니다. 비활성화한 플러그인은 실행을 멈춰도 파일이 남으므로 삭제 여부를 따로 결정해야 합니다. 사용하지 않거나 더 이상 업데이트를 지원하지 않는 플러그인은 제거가 권장됩니다. 삭제할 대상은 맡던 기능과 보존할 설정·데이터를 살펴보고 백업한 뒤 정하십시오.
이 권장은 제 개인 의견만은 아닙니다. 워드프레스 공식 문서의 WordPress Housekeeping은 플러그인을 정기적으로 점검해 오래되거나 필요 없는 것은 비활성화한 뒤 삭제하라고 안내합니다. 삭제 전에는 플러그인의 readme나 상세 정보에서 제거 방법을 확인하라는 내용도 있습니다. 같은 문서는 플러그인 업데이트를 3~6개월마다 확인하라고 하는데, 이 글에서는 속도가 문제일 때의 순서를 말씀드린 것이고 평소 관리 주기는 문서를 참고하시면 됩니다.
업데이트와 플러그인 관리 상태를 살핀 뒤에도 느리다면, 호스팅 업체에 관리자 화면의 증상과 시험한 조치를 전하십시오. 방문자 화면도 함께 느린지 알려 주면 관리자 영역에만 나타나는 현상과 구분하는 데 도움이 됩니다.
문의할 때는 앞에서 적어 둔 전후 숫자(편집 화면 로드 시간, admin-ajax 요청 수)와 시험한 플러그인 이름을 함께 보내면 답을 받기 쉽습니다. 반대로 방문자 화면이 느린 쪽이라면 이미지부터 보는 것이 순서이니, 이미지 최적화 후 느릴 때 확인하는 방법을 참고하십시오.
관리자 화면이 느릴 때는 최근 변경한 플러그인을 하나씩 비활성화해 반응을 살피는 것이 첫 조치입니다. 변화가 없다면 워드프레스 업데이트 상태와 사용하지 않는 플러그인의 관리 상태를 살펴보십시오.
