워드프레스 admin-ajax.php 느릴 때｜action별 20분 진단

워드프레스 사이트를 점검하다 보면 admin-ajax.php 요청이 반복될 때가 있습니다. 이름에 admin이 들어가지만 관리자 전용 파일은 아닙니다. 검색어 자동 완성, 상품 필터, 장바구니 갱신처럼 화면을 새로 고치지 않고 서버와 데이터를 주고받는 기능도 이 경로를 이용합니다.

따라서 주소만 보고 차단하면 기능이 고장날 수 있습니다. 먼저 어떤 action이 요청되었는지, 어느 스크립트가 호출했는지, 서버 응답을 기다리는 시간이 얼마나 되는지 확인해야 합니다. 아래 순서대로 점검하면 플러그인을 무작정 삭제하지 않고도 병목 범위를 좁힐 수 있습니다.

10초 요약

• admin-ajax.php 요청이 있다는 사실만으로는 오류가 아닙니다.
• Network의 Payload에서 action 값을 먼저 기록합니다.
• Initiator로 요청을 만든 스크립트와 플러그인을 찾습니다.
• Timing의 Waiting(TTFB)이 길면 서버 처리 과정을 추가로 확인합니다.
• 전체 경로를 막지 말고 확인된 기능 하나만 조정한 뒤 다시 측정합니다.

admin-ajax.php는 무엇을 처리할까?

공식 문서에 따르면 AJAX 요청은 wp-admin/admin-ajax.php로 전달되며, 데이터에는 처리 목적을 나타내는 action이 포함됩니다. 로그인 요청은 wp_ajax_액션명, 비로그인 요청은 wp_ajax_nopriv_액션명 훅에 연결될 수 있습니다. 주소가 같아도 action에 따라 실행 코드가 달라집니다.

글 작성 화면의 자동 저장과 공개 페이지의 실시간 검색은 같은 주소로 보일 수 있습니다. 먼저 로그인·로그아웃 상태를 나눠 재현하면 원인 범위를 빠르게 줄일 수 있습니다.

반복 요청 유형 비교

관찰한 현상	가능성이 높은 기능	먼저 확인할 항목
관리자 화면을 열었을 때만 주기적으로 발생	Heartbeat, 자동 저장, 관리자 알림	action과 요청 간격
검색창에 입력할 때마다 발생	실시간 검색·자동 완성	최소 글자 수와 입력 지연
상품 옵션이나 필터를 누를 때 발생	상품 조회·가격·재고 갱신	응답 시간과 DB 쿼리
아무 동작이 없어도 공개 페이지에서 반복	통계, 보안, 채팅, 팝업 모듈	Initiator 스크립트와 호출 주기
로그인 상태에서만 느림	대시보드 위젯·편집 기능	관리자 플러그인과 Heartbeat

20분 안에 호출 주체 찾는 방법

1. Network에서 요청을 재현한다

크롬에서 문제가 나타나는 페이지를 열고 F12를 누른 뒤 Network 탭에서 Fetch/XHR만 표시합니다. 기록을 지우고 검색 입력, 필터 클릭, 페이지 대기처럼 문제가 생기는 동작을 한 번만 재현합니다. 목록에서 admin-ajax.php를 선택하고 시간, 상태 코드, 응답 크기를 적어 둡니다.

2. Payload에서 action을 확인한다

Payload 또는 Form Data의 action 값은 가장 중요한 단서입니다. 바로 보이지 않으면 Query String, 요청 본문과 Content-Type도 확인합니다. action 이름과 플러그인명을 함께 검색하면 소유 모듈을 찾기 쉽습니다.

3. Initiator와 호출 파일을 연결한다

Initiator 탭이나 열에는 요청을 시작한 자바스크립트가 표시됩니다. 파일 경로에 /wp-content/plugins/플러그인명/이 보이면 호출 주체를 특정할 수 있습니다. 압축된 공통 파일만 보일 때는 Initiator 호출 스택을 펼치고, 해당 기능을 끈 전후의 요청 횟수를 비교합니다.

4. Timing에서 브라우저와 서버 지연을 나눈다

Timing의 Waiting(TTFB)은 네트워크 왕복과 서버가 응답을 준비한 시간을 포함합니다. TTFB가 길고 다운로드 시간은 짧다면 서버 처리, 데이터베이스 쿼리, 외부 API 호출을 우선 확인합니다. 반대로 응답 본문이 크고 Content Download가 길다면 반환 데이터의 양도 줄여야 합니다.

5. 로그인 상태와 서버 기록을 교차 확인한다

시크릿 창의 비로그인 상태와 관리자 로그인 상태에서 같은 동작을 비교합니다. 한 action만 유독 느리다면 Query Monitor로 느린 플러그인과 쿼리를 찾는 방법을 이용해 요청 처리 중 발생한 쿼리와 외부 HTTP 호출을 살펴봅니다. DB 대기 시간이 길면 MySQL 슬로우 쿼리 로그 분석으로 이어서 확인합니다.

원인별 안전한 해결 방법

확인된 원인	우선 적용할 조치	검증할 기능
키를 누를 때마다 검색 요청	최소 입력 글자 수와 debounce 지연 설정	검색 결과와 모바일 입력
사용하지 않는 페이지에서도 스크립트 로드	필요한 페이지에서만 조건부 로드	팝업·폼·장바구니
짧은 간격의 주기 요청	플러그인 설정에서 간격을 단계적으로 늘림	알림·상태 갱신 정확도
action 내부의 느린 DB 조회	쿼리 범위·인덱스·반환 행 수 점검	필터와 페이지 이동 결과
외부 API 응답 대기	타임아웃, 결과 캐시 또는 백그라운드 처리	실패 시 대체 동작

Heartbeat action이 원인이라면 요청을 완전히 끄기보다 편집 화면의 자동 저장과 잠금 기능을 고려해 간격을 조정해야 합니다. 자세한 기준은 워드프레스 Heartbeat API 최적화 방법에서 확인할 수 있습니다.

하면 안 되는 설정

• 보안 규칙이나 서버 설정에서 admin-ajax.php 전체를 차단하지 않습니다.
• POST 응답을 일반 페이지처럼 일괄 캐시하지 않습니다.
• action 이름만 보고 관련 코드를 임의로 삭제하지 않습니다.
• 여러 플러그인을 동시에 끄고 결과가 좋아졌다고 판단하지 않습니다.
• 관리자 로그인 상태만 측정하고 일반 방문자 결과를 생략하지 않습니다.

TIP

조정 전후를 비교할 때는 같은 페이지, 같은 로그인 상태, 같은 동작으로 세 번씩 측정하세요. action별 요청 횟수와 중간값을 기록하면 일시적인 서버 변동을 개선 효과로 오해하는 일을 줄일 수 있습니다. 한 번에 하나만 바꾸는 것도 중요합니다.

5분 재측정 기록표

1. 테스트 페이지와 로그인 상태를 기록합니다.
2. action 이름, Initiator 파일, 1분당 요청 횟수를 적습니다.
3. 세 번 측정한 TTFB의 중간값을 남깁니다.
4. 확인된 기능 하나만 조정하고 캐시를 비웁니다.
5. 같은 동작을 반복해 요청 수와 응답 시간을 비교합니다.
6. 검색·폼·장바구니·자동 저장 등 관련 기능이 정상인지 확인합니다.
7. 4xx·5xx 오류나 콘솔 오류가 생기면 즉시 원래 설정으로 되돌립니다.

자주 묻는 질문

admin-ajax.php가 보이면 해킹인가요?

아닙니다. 워드프레스와 플러그인이 정상 기능을 처리할 때도 사용합니다. 다만 비정상적으로 많은 요청, 알 수 없는 action, 반복되는 4xx·5xx 상태가 보이면 보안 로그와 접근 로그를 추가로 확인하세요.

action 값만 알면 원인 플러그인을 확정할 수 있나요?

좋은 단서지만 그것만으로 확정하지는 않습니다. Initiator 파일 경로, 로그인 여부, 기능을 끈 전후의 요청 변화까지 일치해야 안전하게 판단할 수 있습니다.

캐시 플러그인으로 해결할 수 있나요?

로그인 상태나 사용자별 결과를 반환하는 AJAX POST 요청은 일반 페이지 캐시만으로 해결되지 않는 경우가 많습니다. 호출 횟수, 쿼리, 외부 API처럼 실제 action 내부의 병목을 먼저 확인하세요.

공식 자료

• WordPress Plugin Handbook: AJAX
• WordPress: 로그인 AJAX action 훅
• WordPress: 비로그인 AJAX action 훅
• Chrome DevTools: Network 기능 참고 자료

마무리

admin-ajax.php 최적화의 핵심은 파일을 막는 것이 아니라 느린 action과 호출 주체를 분리하는 것입니다. Payload에서 action을 찾고, Initiator로 스크립트를 연결한 뒤, Timing과 서버 기록으로 지연 구간을 확인하세요. 기능 하나만 조정하고 같은 조건에서 재측정하면 사이트 기능을 지키면서 반복 요청과 응답 시간을 줄일 수 있습니다.