워드프레스는 전 세계적으로 가장 많이 사용되는 CMS 중 하나이지만, 관리자 페이지(특히 post-new.php와 같은 글 작성 화면)가 느려지는 문제를 경험하는 경우가 많다. 이러한 지연은 단순히 서버 성능 부족 때문이 아니라, 워드프레스의 구조적 특성과 플러그인, 데이터베이스 설계 방식이 복합적으로 작용한 결과다.
1. PHP-FPM과 서버 풀의 상태
워드프레스는 대부분 PHP-FPM을 통해 동작한다. post-new.php 요청은 단순한 페이지 로딩 이상의 작업을 포함한다. 에디터 초기화, 각종 플러그인 기능 호출, AJAX 요청 준비 등이 동시에 발생한다. PHP-FPM 풀에서 max_children 값이 낮거나, 슬로우 로그에 많은 요청이 기록된다면 이는 곧 풀 포화 상태를 의미한다. 이런 상황에서는 요청이 대기열에 쌓이고, 결과적으로 관리자가 페이지를 여는 순간 응답 지연이 발생한다. 풀 크기 조정, pm.max_requests 최적화, 슬로우 로그 분석은 기본적인 대응책이다.
2. wp_options 테이블의 비대화
워드프레스의 wp_options 테이블은 사이트 전역에서 사용되는 옵션 값을 저장한다. 문제는 수많은 플러그인이 여기에 데이터를 쌓는다는 점이다. 특히 autoload = 'yes'로 지정된 값은 매 요청 시 무조건 메모리로 로드된다. 이 값이 수 MB를 넘어서면 관리자 페이지가 열릴 때마다 불필요한 대량의 데이터가 함께 읽히게 된다. 결과는 명확하다. 페이지 로딩 지연이다. 이를 해결하기 위해서는 autoload가 불필요하게 지정된 항목을 정리하거나, 임시 데이터(transient)를 주기적으로 비우는 작업이 필요하다.
3. 플러그인과 블록 에디터의 무거움
현대 워드프레스의 블록 에디터는 확장성과 유연성이 뛰어나지만, 동시에 무겁다. 거기에 SEO, 페이지 빌더, 보안 모듈 등 플러그인들이 에디터 로딩 과정에 개입하면서 리소스를 추가로 소비한다. 특정 플러그인이 관리자 화면에서 불필요하게 많은 AJAX 요청을 발생시키기도 한다. 이 문제는 브라우저 개발자도구에서 네트워크 탭을 확인하면 쉽게 드러난다. 관리자 페이지를 열 때 수십 개의 AJAX 요청이 연속적으로 실행된다면 그중 일부는 반드시 병목을 유발한다. 해결은 단순하다. 플러그인을 하나씩 비활성화하면서 병목을 일으키는 범인을 찾아내는 것이다.
4. admin-ajax와 REST API의 남용
워드프레스는 admin-ajax.php와 REST API를 통해 실시간 처리를 수행한다. 문제는 많은 플러그인이 이 경로를 남용한다는 것이다. 방문자 카운트, 실시간 보안 점검, 라이브 편집 미리보기 등이 모두 여기에 의존한다. 관리자가 글 작성 화면을 열었을 때 브라우저가 반복적으로 admin-ajax.php를 호출한다면, 그 순간 서버는 수많은 작은 요청을 병렬로 처리해야 한다. Nginx의 fastcgi 버퍼와 PHP-FPM 타임아웃 값을 올려주는 것도 도움이 되지만, 가장 확실한 방법은 불필요한 호출을 줄이는 것이다.
5. 캐시와 세션 관리의 부재
프론트엔드 페이지는 캐시 플러그인을 통해 속도를 크게 개선할 수 있다. 하지만 관리자 페이지는 대부분 캐시가 적용되지 않는다. 여기서 필요한 것은 오브젝트 캐시다. Redis 같은 인메모리 캐시를 붙이면 get_option, get_post_meta 같은 반복 쿼리가 즉시 응답할 수 있다. 또한 PHP Opcache를 활성화하면 PHP 코드 파싱 비용을 줄여 관리자 페이지의 체감 속도를 개선할 수 있다.
6. 워드프레스 크론과 Heartbeat 제어
워드프레스는 크론 작업을 페이지 로딩 시점에 실행하는 독특한 구조를 가진다. 관리자가 접속할 때마다 예약된 크론이 실행되면, 백그라운드에서 의도치 않은 부하가 발생할 수 있다. 이를 방지하기 위해 wp-config.php에서 내부 크론을 끄고, 시스템 크론으로 주기적 실행을 맡기는 것이 이상적이다. 또한 워드프레스 Heartbeat API는 자동 저장과 실시간 협업에 쓰이지만, 과도하게 짧은 주기로 동작하면 관리자 페이지의 지연을 심화시킨다. 이를 60초 이상으로 조정하면 체감 성능이 크게 좋아진다.
7. 인프라 레벨의 고려 사항
Nginx 레이어에서의 버퍼 크기 조정, fastcgi 타임아웃 연장, 커널 파라미터 튜닝은 관리자 페이지 성능에 직간접적인 영향을 준다. 동시에 DB 서버의 쿼리 캐시, 인덱스 최적화, 디스크 I/O 성능도 무시할 수 없다. 글 작성 화면이 느리다는 것은 단순히 PHP 한두 줄이 늦는 문제가 아니라, 서버 스택 전체가 동시에 반응하는 과정에서의 작은 병목이 누적된 결과다.
결론
워드프레스 관리자 페이지가 느려지는 문제는 하나의 원인으로 귀결되지 않는다. PHP-FPM 풀 관리, 데이터베이스 옵션 테이블의 최적화, 플러그인과 AJAX 호출의 통제, 캐시 계층 도입, 크론 관리 등 모든 요소가 얽혀 있다. 따라서 체계적인 모니터링과 단계별 점검이 필요하다. 이를 통해 단순히 “빠르게 만드는 것”을 넘어, 예측 가능한 성능을 유지하는 것이 가능하다.
답글 남기기