워드프레스 플러그인 몇 개가 적당한지보다 중요한 것

플러그인을 10개 깔든 30개 깔든, 숫자만 보고 속도를 걱정하는 것은 순서가 틀린 걱정입니다. 검색창에 “워드프레스 플러그인 몇 개가 적당한가요”를 쳐 본 적이 있다면, 답이 “5개”, “10개 이하” 식으로 제각각이라 더 헷갈렸을 겁니다. 개수보다 먼저 봐야 할 것이 뭔지, 지금 설치된 플러그인 목록을 어떤 기준으로 걸러야 하는지를 짚어보겠습니다.

개수를 줄였는데 왜 그대로일까

플러그인을 몇 개 지웠는데 사이트 속도가 달라지지 않았다면, 지운 것들이 애초에 부담이 적은 플러그인이었을 가능성이 큽니다. 플러그인이 느려지는 원인은 설치 개수보다 각 플러그인이 페이지를 불러올 때마다 추가하는 스크립트·스타일 파일의 양, 데이터베이스 쿼리 횟수, 다른 플러그인과 겹치는 기능을 살펴봐야 합니다. 업데이트가 끊긴 상태는 유지관리와 보안 문제로 따로 봐야 합니다. 짧은 코드 몇 줄로 끝나는 플러그인 5개를 깐 사이트보다, 페이지마다 여러 개의 외부 스크립트를 불러오고 쿼리를 많이 던지는 플러그인 1개를 깐 사이트가 더 무거울 수 있습니다.

다만 쿼리 횟수가 많다는 이유만으로 무거운 플러그인이라고 정하기는 어렵습니다. 금방 끝나는 쿼리 여러 개보다 오래 걸리는 쿼리 하나가 더 부담일 수 있고, 스크립트도 다운로드한 양과 실행하는 부담이 다릅니다. 그래서 개수와 함께 쿼리에 걸린 시간, 내려받은 파일의 전송량, HTML 응답을 기다린 시간을 나눠 보는 것이 좋습니다. Query Monitor 공식 안내에서는 쿼리를 담당 플러그인이나 테마별로 묶어 볼 수 있다고 설명합니다.

뭐가 무거운 플러그인인지 어떻게 구분하나

먼저 볼 것은 기능이 겹치는 플러그인입니다. SEO 플러그인 두 개, 캐시 플러그인 두 개, 보안 플러그인 두 개를 같이 켜 둔 경우가 의외로 많은데, 같은 작업을 하는 기능까지 동시에 켜져 있으면 중복 처리로 부담이 쌓일 수 있습니다. 다음으로 볼 것은 비활성 상태로만 남겨 둔 플러그인입니다. 비활성 플러그인은 일반적인 페이지 처리에 실행되지 않으니 속도 개선 효과를 기대하며 지울 대상은 아니지만, 업데이트가 끊긴 채 파일로 남아 있으면 보안 취약점의 통로가 될 수 있어 속도 문제와는 별도로 정리 대상입니다. 마지막으로 볼 것은 실제로 쓰고 있는 활성 플러그인 가운데 유지관리가 소홀한 쪽입니다. 관리자의 플러그인 추가 및 상세 정보 화면에서 마지막 업데이트 시점과 호환성 표시를 보고, 변경 이력과 제작사의 지원 상태까지 함께 살펴보면 유지관리 상태를 판단하는 데 도움이 됩니다.

설치된 목록과 새 플러그인을 찾는 화면은 구분해서 보면 덜 헷갈립니다. 관리자에서 ‘플러그인 → 설치한 플러그인’은 현재 설치된 버전과 활성 상태를 확인하는 곳입니다. ‘플러그인 → 새로 추가’에서 이름을 검색한 뒤 ‘상세 정보’를 열면 마지막 업데이트, 활성 설치 수, 요구 버전과 테스트된 워드프레스 버전 등을 볼 수 있습니다. 메뉴 이름은 버전에 따라 다를 수 있으며, 공식 디렉터리에 없는 유료·외부 배포 플러그인은 제작사 사이트의 변경 이력과 지원 문서를 확인해야 합니다. WordPress 공식 플러그인 추가 화면 안내에도 검색 결과의 업데이트·호환성·상세 정보 경로가 정리돼 있습니다.

설치 수는 많이 쓰인다는 표시이지, 내 사이트에서 가볍게 작동한다는 보장은 아닙니다. 마지막 업데이트가 오래됐다는 이유 하나로 삭제하기보다, 현재 워드프레스·PHP 환경을 지원하는지, 최근 변경 이력에 오류 수정이 있는지, 같은 문제를 다룬 지원 글에 제작사의 대응이 있는지 함께 봅니다. ‘현재 버전에서 테스트되지 않음’도 곧바로 고장났다는 뜻은 아니므로, 필요한 기능이라면 스테이징에서 확인한 뒤 유지 여부를 정하는 쪽이 낫습니다.

기능이 일부만 겹치는 경우에는 이름만 보고 하나를 지우기 어렵습니다. 예를 들어 무료 Autoptimize는 스크립트·스타일 최적화를 담당하고, WP Super Cache는 페이지를 정적 HTML로 저장해 제공하는 역할이 중심입니다. 두 플러그인에 모두 ‘캐시’라는 말이 나온다고 해서 같은 일을 한다고 보기는 어렵습니다. Autoptimize 공식 설명도 페이지 캐시 플러그인과 함께 쓰는 구성을 안내합니다. 이 경우에는 각각 필요한 역할을 맡고 있다면 유지할 근거가 있습니다. Autoptimize 공식 설명, WP Super Cache 공식 설명

반대로 페이지 캐시와 스크립트 최적화를 모두 제공하는 대안으로 바꾼다면 관리할 설정 화면은 줄어들 수 있습니다. 다만 기존의 스크립트 제외 목록, 실행 지연 설정, 캐시 제외 URL이 그대로 옮겨지는 것은 아닙니다. 교체 전에 설정을 내보내거나 화면을 저장하고, 대안에서 같은 예외를 다시 지정한 뒤 메뉴·검색·장바구니처럼 스크립트에 의존하는 기능을 확인해야 합니다. 플러그인 하나를 줄이는 이득과 설정을 다시 맞추는 부담을 함께 보는 이유입니다.

지울 때는 뭘 먼저 보고 어떤 순서로

활성 플러그인 목록을 유지할 것, 더 가벼운 대안으로 바꿀 것, 아예 지울 것 세 묶음으로 나누는 것이 첫 번째 기준입니다. 기능이 겹치는 플러그인은 교체 묶음으로, 안 쓰는 기능인데 켜 둔 플러그인은 삭제 묶음으로 분류합니다. 분류를 끝냈다고 바로 삭제 버튼을 누르는 것은 피하는 쪽이 낫습니다. 삭제한 플러그인이 쓰던 설정값이나 단축코드가 게시물 안에 남아 있으면 화면이 깨질 수 있어, 스테이징 환경에서 하나씩 비활성화한 뒤 페이지가 정상으로 보이는지, 자주 쓰는 기능이 사라지지 않는지 먼저 검증하는 절차가 안전합니다. 개인적으로는 플러그인 10개 중 가벼운 것 2개를 지우는 작업보다, 쿼리와 스크립트를 많이 쓰는 플러그인 1개를 찾아내는 쪽이 사이트를 더 가볍게 만든다고 봅니다.

그 한 개를 찾을 때는 느린 URL 하나를 정하고, 플러그인을 하나씩 껐다가 다시 켜면서 비교하면 됩니다. 여러 개를 동시에 끄면 무엇 때문에 달라졌는지 알기 어렵습니다. 아래처럼 방문자에게 내려가는 파일과 서버에서 처리하는 쿼리를 따로 보면, 가벼운 것 두 개를 지우는 작업보다 부하가 큰 한 개를 찾는다는 판단을 실제로 확인할 수 있습니다.

1. 스테이징의 같은 URL에서 Chrome 개발자 도구를 열고 Network를 선택합니다. 목록을 비운 뒤 새로고침하고, JS·CSS 필터로 요청 수와 전송량을 기록합니다. 요청 주소에 /wp-content/plugins/가 보이면 해당 폴더명을 단서로 삼되, 파일이 합쳐졌거나 외부 서버에서 내려오는 경우에는 주소만으로 담당 플러그인을 단정하지 않습니다.
2. Network에서 HTML 문서 요청을 선택하고 Timing의 ‘Waiting for server response’를 기록합니다. 이 값은 TTFB를 비교하는 단서이며, 데이터베이스 시간만을 뜻하지는 않습니다. 브라우저·화면 크기·네트워크 제한 설정을 같게 유지하고, Disable cache의 체크 상태도 전후에 동일하게 둡니다. 이 옵션은 브라우저 캐시에 관한 것이어서 서버나 CDN의 캐시까지 꺼 주지는 않습니다.
3. 서버 쪽은 스테이징에 Query Monitor를 설치해 관리자 로그인 상태로 같은 URL을 엽니다. 상단 도구 모음의 Query Monitor에서 데이터베이스 쿼리를 담당 구성요소별로 묶어 보고, 후보 플러그인의 쿼리 수와 합산 시간을 기록합니다. 패널 이름은 버전에 따라 다를 수 있습니다. 방문자 Network 기록과 관리자 쿼리 기록은 로그인 조건이 다르므로 별도의 기록으로 비교합니다.
4. 후보 하나를 비활성화한 뒤, 전후 모두 같은 방식으로 서버·CDN 캐시를 비우고 같은 횟수만큼 페이지를 열어 캐시를 준비합니다. 각 조건에서 세 번씩 측정해 중앙값을 비교하면 한 번의 우연한 지연에 덜 흔들립니다. 확인 후 다시 활성화했을 때 수치가 이전 수준으로 돌아오는지도 보면 판단에 도움이 됩니다. Query Monitor는 전후 모두 켠 상태로 비교하고 점검이 끝나면 제거합니다.

Network의 요청·전송량·Timing 확인 방법은 Chrome 개발자 도구 공식 안내에서, 플러그인별 쿼리 구분은 Query Monitor 공식 안내에서 확인할 수 있습니다. 요청 수가 줄었다고 스크립트 실행 부담까지 같은 비율로 줄었다고 보지는 않습니다. 파일은 줄었는데 화면의 반응이 그대로라면 개발자 도구의 Performance 기록으로 실행 시간을 더 살펴볼 필요가 있습니다.

측정 대상과 조건(예시)	비활성화 전 중앙값	후보 하나 비활성화 후 중앙값	판단할 내용
로그아웃 게시글, 서버 페이지 캐시 준비 후, 브라우저 캐시 비활성화	JS·CSS 24건 / 620KB TTFB 180ms	JS·CSS 16건 / 340KB TTFB 175ms	파일 부담은 줄었지만 HTML 응답 차이는 작습니다.
관리자 로그인, 같은 게시글, 페이지 캐시 우회 확인, Query Monitor 사용	전체 쿼리 95건 / 합산 120ms	전체 쿼리 62건 / 합산 55ms	서버 쿼리 부담이 줄어든 후보입니다. 담당 구성요소별 기록으로 원인을 좁힙니다.

이 예시처럼 캐시가 적용된 게시글에서는 서버 응답 차이가 작아도, 캐시를 우회하는 로그인 화면에서는 쿼리 차이가 드러날 수 있습니다. WP Super Cache 공식 설명도 로그인 여부 등에 따라 정적 캐시 제공 대상이 달라진다고 안내합니다. 장바구니·결제 화면은 사용하는 쇼핑몰과 캐시 설정에서 제외 여부를 따로 확인해야 합니다. 일반 게시글이 빨라졌다는 이유만으로 결제 화면도 빨라졌다고 판단하지 않는 이유입니다. WP Super Cache의 캐시 제공 조건

전후 차이가 세 번 측정하는 동안의 흔들림보다 작다면 속도 때문에 교체할 근거는 아직 약합니다. 필요한 기능이 사라진 경우에도 빨라진 숫자만 보고 삭제를 결정하기 어렵습니다. 이미지 요청은 줄었는데 화면이 여전히 늦는 경우에는 워드프레스 이미지 최적화 후 느릴 때 확인하는 방법처럼 HTML 응답과 화면이 그려지는 시간을 나눠 보면 다음 점검 대상을 정하기 쉽습니다.

삭제할 플러그인을 정했다면 비활성화 상태에서 하루 이상 두고 오류 로그를 지켜보되, 실제 사용하는 기능과 예약 작업의 실행 주기까지 확인한 뒤 지우는 것이 그대로 복구가 어려운 상황을 피하는 방법입니다.

하루는 모든 기능이 정상이라는 기준이 아닙니다. 일주일마다 백업하는 사이트라면 하루 동안 백업 오류가 없었다는 사실만으로는 부족합니다. 먼저 해당 플러그인의 설정에서 예약 주기와 다음 실행 시각을 확인하고, 제공되는 실행 기록에서 마지막 작업이 성공했는지 봅니다. 워드프레스의 기본 WP-Cron은 예약 시각이 됐다고 독립적으로 실행되는 방식이 아니라 페이지 요청 때 실행 기회를 얻으므로, 방문이 적은 스테이징에서는 작업이 늦을 수 있습니다. 별도 서버 예약 작업을 쓰는 환경은 그 설정과 실행 기록도 함께 확인해야 합니다. WordPress 공식 WP-Cron 설명

• 로그는 호스팅 관리 화면의 사이트별 ‘로그’, ‘오류 로그’, ‘PHP 오류 로그’ 항목부터 찾아봅니다. 이름과 저장 위치는 업체에 따라 다르므로 보이지 않으면 호스팅 도움말에서 확인합니다. 비활성화 시각과 기능을 테스트한 시각을 기록해 그 시간대의 새 오류를 살펴보면 기존 오류와 구분하기 쉽습니다.
• 스테이징에서 추가 기록이 필요하면 wp-config.php의 기존 설정을 확인한 뒤 WP_DEBUG와 WP_DEBUG_LOG를 켜고, WP_DEBUG_DISPLAY는 끄는 구성을 사용합니다. 기본 로그 위치는 wp-content/debug.log이며 다른 경로로 지정할 수도 있습니다. 로그에는 민감한 정보가 들어갈 수 있으므로 외부 접근을 막고, 점검 후 디버깅 설정과 로그를 정리합니다. WordPress 공식 디버깅 안내
• 오류가 없더라도 게시글의 단축코드·블록, 모바일 메뉴, 검색, 로그인·비밀번호 재설정, 문의 양식 제출과 메일 도착을 확인합니다. 쇼핑몰이라면 스테이징에서 결제사의 테스트 모드로 장바구니·쿠폰·결제·주문 상태 변경·알림 메일까지 살펴봅니다. 백업·예약 발행·외부 서비스 동기화는 해당 작업 주기에 맞춰 성공 기록을 확인해야 합니다.
• 비활성화 전에는 데이터베이스와 파일을 함께 백업하고 복원 방법을 확인해 둡니다. 설정 내보내기와 설치 버전 기록도 남깁니다. 문제가 생기면 먼저 같은 플러그인을 재활성화하고 캐시를 갱신한 뒤 실패했던 기능을 다시 시험합니다. 삭제 과정에서 설정이나 데이터가 지워졌다면 재설치만으로 돌아오지 않을 수 있어 백업 복원이 필요합니다. WordPress 공식 백업 안내

캐시나 스크립트 최적화 플러그인은 비활성화한 뒤에도 기존 HTML 캐시가 이전 파일을 가리킬 수 있습니다. Autoptimize 공식 FAQ도 최적화 파일을 지울 때 페이지 캐시에 남은 참조를 주의하라고 설명합니다. 그래서 비활성화 직후 화면이 깨졌다면 서버·CDN의 페이지 캐시를 갱신한 뒤에도 같은 문제가 생기는지 확인해야 합니다. Autoptimize 공식 FAQ의 캐시 삭제 안내

실제 운영 사이트에 적용할 때도 스테이징에서 확인한 순서대로 하나씩 바꾸는 편이 좋습니다. 주문이 들어오는 사이트라면 오래된 데이터베이스 백업을 복원할 때 그 이후 주문이 사라질 수 있으므로, 복원 범위와 최신 주문 보존 방법을 먼저 정해야 합니다. 결국 지울 개수보다 중요한 것은 필요한 기능을 남기면서 어느 부담이 줄었는지 확인하고, 문제가 생겼을 때 돌아갈 방법을 갖춰 두는 것입니다.

문서 확인일: 2026년 10월 10일. 이번 보강에서는 업데이트 정보 확인 경로, 측정 도구, 로그·예약 작업·백업 절차를 공식 문서로 확인했습니다. 특정 운영 사이트의 워드프레스·PHP 버전이나 호스팅 환경에서 직접 검증한 결과는 아니며, 표의 수치는 설명용 예시입니다. 실제 적용에서는 설치 버전과 캐시 구성에 따라 화면과 결과가 달라질 수 있습니다.

참고한 자료: Plugin troubleshooting procedure, Managing WordPress Plugins Properly: Deactivate, Delete, and Keep Secure

위 두 링크는 원문에 있던 참고 자료입니다. 특정 분류 방식이 업계 권고라는 주장과 평균 40퍼센트 감소 수치에 대응하는 조사 대상·집계 방법·원문 위치를 확인할 수 없어 해당 문장은 삭제했습니다. 보강한 관리 절차의 근거는 각 설명 뒤에 연결한 공식 문서에서 확인할 수 있습니다.

• 워드프레스 사이트 느릴 때 이미지를 살펴보는 이유
• 평균 게재순위 떨어지 이유 위기일까? 노출수 증가가 진짜 변수
• 워드프레스 카테고리 개수와 SEO 최적화 설정