워드프레스 관리자 페이지가 느릴 때: 플러그인·DB·Cron·외부 요청 진단 순서

증상 범위를 네 갈래로 나눕니다

느리다는 표현 대신 로그인 8초, 글 목록 12초, 저장 30초처럼 측정하세요. 오류가 시작된 날짜와 직전 업데이트·설치·설정 변경을 적으면 원인 범위를 빠르게 줄일 수 있습니다.

브라우저 문제는 5분 안에 제외할 수 있습니다

1. 시크릿 창에서 같은 관리자 URL을 엽니다.
2. 다른 브라우저 또는 새 프로필에서 비교합니다.
3. 광고 차단, 번역, 비밀번호 관리, 보안 확장 프로그램을 잠시 끕니다.
4. 개발자 도구 Network에서 오래 걸리는 요청을 찾습니다.
5. 콘솔 오류와 반복 요청이 있는지 확인합니다.

시크릿 창에서는 빠르고 일반 창에서만 느리다면 서버보다 확장 프로그램·쿠키·로컬 캐시 가능성이 큽니다. 그래도 사이트 데이터를 지우기 전 로그인 정보와 작업 중인 초안을 보존하세요.

서버 자원과 PHP 오류를 먼저 확인합니다

관리자 요청은 로그인 검증, DB 조회, 플러그인 훅, 외부 통신이 많아 공개 캐시 페이지보다 무거울 수 있습니다. 호스팅 패널이나 모니터링에서 CPU, 메모리, PHP worker, 디스크 I/O, DB 연결 수를 봅니다.

• 특정 시간대에만 느리면 백업·Cron·크롤·공격 트래픽을 확인합니다.
• 저장할 때만 느리면 post save 훅, 외부 전송, 이미지 처리를 봅니다.
• 로그인 직후 느리면 대시보드 위젯과 원격 API 요청을 확인합니다.
• 간헐적 502·504가 있으면 PHP worker와 upstream timeout을 봅니다.
• 디스크가 가득 찼다면 로그·백업·캐시 파일을 먼저 정리합니다.

플러그인은 안전한 환경에서 이분 탐색합니다

운영 사이트에서 모든 플러그인을 한 번에 끄면 결제·보안·폼이 중단될 수 있습니다. 백업과 스테이징을 준비하고, 최근 변경 플러그인과 문제 메뉴에 연결된 플러그인부터 확인하세요.

플러그인이 많다면 절반씩 비활성화해 문제 그룹을 좁히는 이분 탐색이 빠릅니다. 캐시, 보안, SEO, 백업처럼 기능이 겹치는 플러그인은 충돌과 중복 작업을 확인합니다. 비활성화로 빨라졌다고 바로 삭제하지 말고 로그와 요청을 통해 어떤 기능이 지연을 만들었는지 찾으세요.

데이터베이스 autoload와 느린 쿼리를 봅니다

워드프레스는 wp_options의 autoload 항목을 많은 요청에서 함께 불러옵니다. 삭제된 플러그인의 큰 옵션이나 지나치게 큰 캐시가 남으면 관리자 전체가 느려질 수 있습니다. WordPress 공식 성능 문서는 autoload 옵션이 과도하게 커지지 않도록 관리할 것을 안내합니다.

DB를 직접 수정하기 전 백업을 만들고 어떤 플러그인이 값을 쓰는지 확인하세요. 옵션 이름만 보고 임의 삭제하면 라이선스·결제·사이트 설정이 손상될 수 있습니다. Query Monitor나 호스팅 도구로 느린 쿼리, 호출 횟수, 담당 컴포넌트를 먼저 찾습니다.

WP-Cron과 외부 요청 지연을 분리합니다

관리자 페이지를 열 때 밀린 Cron 작업이 실행되거나 플러그인이 라이선스·통계·API 서버에 연결하면 화면이 늦게 끝날 수 있습니다. WP-CLI로 이벤트 목록과 due-now 작업을 확인하고, 외부 요청 시간과 실패 도메인을 로그에 남기세요.

외부 서비스가 느리다고 도메인을 무조건 차단하면 업데이트·결제·보안 조회가 깨질 수 있습니다. 타임아웃, 재시도, 캐시, 비동기 처리 여부를 플러그인 문서와 함께 확인합니다.

Heartbeat와 관리자 Ajax는 원인을 확인한 뒤 조정합니다

Heartbeat API는 자동 저장, 글 잠금, 세션 상태 등 관리자 기능에 사용됩니다. 요청이 많다는 이유만으로 완전히 끄면 편집 충돌과 자동 저장 문제가 생길 수 있습니다. 어떤 화면에서 어떤 플러그인이 admin-ajax.php를 반복 호출하는지 확인한 뒤 빈도 조정이나 기능 수정으로 해결하세요.

서버 업그레이드가 필요한 기준

플러그인과 DB를 정리해도 평상시 CPU·메모리·PHP worker가 지속적으로 한계에 닿고, 실제 업무 트래픽에서 지연이 재현되면 업그레이드를 검토할 수 있습니다. 순간 피크 하나만 보고 상위 요금제로 이동하지 말고 최소 며칠의 자원 추세와 요청 유형을 확인하세요.

변경 후 완료 기준

• 대표 관리자 화면 3~5개의 응답 시간이 안정적으로 줄었습니다.
• 저장·미디어 업로드·예약 발행이 정상 작동합니다.
• 공개 페이지와 관리자 모두 PHP 오류가 없습니다.
• CPU·메모리·DB 지표가 정상 범위로 돌아왔습니다.
• 비활성화한 기능과 롤백 방법을 운영 기록에 남겼습니다.

느리다는 느낌을 요청 시간으로 바꿉니다

관리자 첫 화면, 글 목록, 편집기 저장, 미디어 업로드, 플러그인 화면은 서로 다른 요청을 사용합니다. 개발자 도구의 Network 탭이나 APM에서 가장 오래 걸리는 요청, 서버 대기 시간, 응답 크기, 실패 상태를 기록하세요. 같은 계정·같은 화면을 세 번 측정해 일시적인 네트워크 지연과 반복 병목을 구분합니다.

Query Monitor와 APM은 운영 영향에 맞게 사용합니다

Query Monitor 같은 진단 플러그인은 느린 쿼리, HTTP API 호출, PHP 오류, 훅을 찾는 데 유용합니다. 다만 운영 사이트에 상시 켜 두면 추가 부하와 정보 노출 위험이 생길 수 있으므로 짧은 진단 창이나 스테이징에서 사용하세요. 트래픽이 크거나 간헐적 장애라면 서버 APM과 느린 쿼리 로그가 더 적합할 수 있습니다.

autoload 문제는 크기 하나보다 구성과 사용 빈도를 봅니다

autoload 옵션 전체 크기가 크면 매 요청마다 불필요한 데이터를 읽을 수 있지만 고정 임계값 하나로 장애를 단정하지 마세요. 어떤 옵션이 큰지, 실제로 필요한지, 삭제된 플러그인의 잔재인지 확인합니다. DB를 직접 수정하기 전에 백업하고 플러그인 공식 제거 절차를 우선 사용하세요.

안전한 플러그인 격리 순서를 따릅니다

1. 백업과 유지보수 창을 확보합니다.
2. 스테이징에서 증상을 재현합니다.
3. 최근 변경과 오류 로그를 먼저 확인합니다.
4. 플러그인을 절반씩 비활성화해 범위를 좁힙니다.
5. 원인 후보의 설정·버전·외부 의존성을 검증합니다.
6. 해결 후 원래 기능과 예약 작업을 다시 확인합니다.

운영에서 무작정 전체 비활성화하면 결제·보안·캐시·폼이 동시에 멈출 수 있습니다. 재현 가능한 순서와 롤백 경로가 먼저입니다.

성능 개선 전후를 같은 작업으로 재측정합니다

캐시 적용 전에는 글 목록을, 적용 후에는 편집기 저장을 측정하는 식으로 조건이 바뀌면 효과를 판단할 수 없습니다. 사용자 역할, 화면, 데이터 양, 시간대, 브라우저, 요청 횟수를 고정하고 중앙값과 최악값을 함께 기록하세요. 평균이 좋아져도 간헐적으로 20초가 걸리는 요청이 남아 있으면 운영 문제는 계속될 수 있습니다.

완료로 판단할 수 있는 증거

• 핵심 관리자 작업의 서버 대기 시간이 목표 범위로 줄었습니다.
• PHP 치명적 오류와 느린 DB 쿼리의 원인이 해결됐습니다.
• 플러그인 비활성화로 사라진 기능을 대체하거나 정상 복구했습니다.
• Cron·백업·보안 스캔이 정상 주기로 실행됩니다.
• CPU·메모리·DB 연결 수가 피크 시간에도 여유를 가집니다.
• 일반 관리자 계정에서도 같은 개선을 확인했습니다.

관리자 성능은 방문자 캐시만으로 해결되지 않는 경우가 많습니다. 실제 병목이 DB, 외부 API, PHP 코드, 작업 대기열 중 어디인지 증거로 좁힌 뒤 비용을 투입하세요.

관리자 성능 진단을 더 좁히기

서버 CPU 100% 원인 진단, 호스팅 자원과 실제 사용 가능 용량, 워드프레스 호스팅 선택 기준을 함께 보면 관리자 지연이 애플리케이션 문제인지 자원 한계인지 더 잘 구분할 수 있습니다.

공식 자료와 검증 경로

• WordPress 성능 최적화
• WordPress Heartbeat API
• WordPress 디버깅