* 이 게시물은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
(워드프레스 해부 ㉜) 디버깅
사이트가 느리거나 이상할 때, 추측 대신 보고 고쳐야 한다. 무기는 두 가지 — 3편에서 켠 WP_DEBUG 로그와 6편에서 깐 Query Monitor다.
Query Monitor는 페이지마다 실행된 DB 쿼리(느린 것·중복된 것), 발동된 훅, 선택된 템플릿, PHP 오류, 그리고 어느 플러그인이 시간을 잡아먹는지까지 다 보여준다. 워드프레스의 X-ray다.
직접 해보기
- 관리자 바의 실행시간 / 쿼리 수(예:
0.4s / 82Q)를 클릭 → 상세 패널. - Queries 패널에서
Time으로 정렬 → 제일 느린 쿼리 찾기. - Queries by Component로 어느 플러그인·테마가 쿼리를 많이 던지는지 확인.
느린 쿼리가 특정 플러그인에서 몰려 나온다면 범인이 잡힌 거다. 쿼리 수가 수백 개면 캐시(18편)가 안 먹고 있을 가능성이 크다.
✅ 확인 — 아무 페이지나 열고 Query Monitor에서 쿼리 수를 확인해 보자. 관리자 화면이 프론트보다 쿼리가 훨씬 많은 게 보통이다. 이 숫자가 이상하게 크면 그게 최적화의 출발점이다.
실무 팁 — Query Monitor에서 제일 먼저 볼 곳은 Queries by Component 패널이다. 어느 플러그인·테마가 느린 쿼리를 만드는지 바로 드러난다. 개별 쿼리가 0.05초를 넘으면 의심하고, 같은 쿼리가 수십 번 반복되면(N+1) 캐싱이나 쿼리 통합을 검토한다. ‘Hooks & Actions’ 패널로 어떤 훅에 뭐가 걸렸는지도 추적할 수 있다.
N+1 쿼리 — 조용한 성능 킬러
목록에서 글마다 메타를 따로 조회하면, 쿼리가 글 수만큼 늘어난다(이른바 N+1). Query Monitor에서 같은 형태의 쿼리가 수십 번 반복되면 바로 이 신호다. update_post_meta_cache나 WP_Query의 사전 로드로 한 번에 가져오게 고치면 쿼리 수가 뚝 떨어진다.
N+1을 코드로 고치는 전형은 이렇다 — 핵심은 루프 전에 한 번에 캐우는 것.
// Before — 글 50개 목록에서 메타 쿼리 50번 (N+1)
foreach ( $posts as $p ) {
echo get_post_meta( $p->ID, 'subtitle', true ); // 매번 쿼리
}
// After — 사전 캐우기 한 번, 루프는 캐시에서
update_post_meta_cache( wp_list_pluck( $posts, 'ID' ) ); // 쿼리 1번
foreach ( $posts as $p ) {
echo get_post_meta( $p->ID, 'subtitle', true ); // 캐시 히트
}
// WP_Query라면 'update_post_meta_cache' => true (기본값)가 이 일을 한다고친 뒤엔 반드시 Query Monitor로 전후 쿼리 수를 대조한다 — 51 → 2처럼 뚝 떨어지는 게 눈으로 보여야 수정이 증명된 것이다.
쿼리 말고도 보는 것들
| 패널 | 무엇을 보나 |
|---|---|
| Queries | 느린·중복 쿼리 |
| Hooks | 발동된 훅과 순서 |
| Template | 선택된 템플릿·후보 |
| Scripts / Styles | 로드된 자원(불필요한 것 색출) |
| HTTP | 외부 API 호출(느린 외부 요청) |
| PHP Errors | 경고·치명 오류 |
운영 사이트엔 상시로 켜두지 마라
Query Monitor는 강력하지만 그 자체로도 약간의 부하를 준다. 관리자에게만 보이긴 해도 내부 정보가 드러날 수 있으니, 운영에서 상시 사용은 피한다. 필요할 때 켜서 보고, 상시 관찰은 스테이징에서 하는 게 안전하다. 로그로만 남기고 싶으면 WP_DEBUG_LOG(3·6편)를 병행한다. ‘보고 고친다’의 무기로는 이만한 게 없다.
문제를 보는 법을 익혔으니, 다음은 워드프레스 속도 최적화 구조다.
🔧 현장에서 — 마지막 에러는 대부분 원인이 아니라 결과다
Redis · Jenkins · Apache · JVM · 프론트 빌드까지 스택이 달라도, 장애는 늘 같은 순서로 좁혔다 — ① 실제 Error 메시지 확보 → ② 최초 Error 위치 확인 → ③ 정상/비정상 환경 차이 비교 → ④ 계층 분리 → ⑤ 가설 → ⑥ 하나씩 검증. 예를 들어 Jenkins가 약 30분 빌드 후 ELIFECYCLE만 남기고 죽었을 때도, 마지막 로그가 아니라 최초 실패(특정 프론트 패키지의 build 실패)를 찾아 분리했다.
교훈 — CI·로그에서 마지막 Error는 원인이 아니라 결과인 경우가 많다. 항상 첫 번째 Error를 찾아라. Query Monitor도 같은 원리로 ‘가장 먼저 튀는 느린 쿼리·경고’부터 본다.
자주 묻는 질문 (FAQ)
Query Monitor로 뭘 볼 수 있나요?
느린 쿼리, 훅, HTTP 요청, PHP 오류, 어떤 템플릿이 선택됐는지까지 봅니다. 성능·버그 추적의 필수 도구입니다.
운영 사이트에 켜둬도 되나요?
관리자에게만 보이지만 약간의 오버헤드가 있어, 문제 진단 시에만 켜는 걸 권합니다.
답글 남기기