워드프레스 캐시 플러그인 설정｜중복 방지·오류 복구 순서

워드프레스 캐시 플러그인 설정은 기능을 많이 켜는 작업이 아니라, 사이트의 어느 단계에서 캐시가 이미 동작하는지 확인하고 한 계층씩 검증하는 작업입니다. 서버 캐시와 플러그인 페이지 캐시, CDN 캐시가 겹치면 수정한 글이 보이지 않거나 로그인·장바구니 화면이 다른 사용자에게 잘못 전달될 수 있습니다. 아래 순서는 특정 제품의 권장값을 복사하지 않고 내 사이트에서 안전한 값을 찾는 방법입니다.

먼저 결론: 페이지 캐시 하나부터 시작한다

• 호스팅의 서버·엣지 캐시 제공 여부를 먼저 확인합니다.
• 페이지 캐시 기능은 한 곳만 중심으로 사용합니다.
• 로그아웃 창에서 캐시 적중과 제외 페이지를 확인합니다.
• CSS 축소, 지연 실행과 객체 캐시는 별도 단계로 적용합니다.
• 문제가 생기면 마지막 변경만 끄고 관련 계층의 캐시를 비웁니다.

설치 전에 10분 동안 현재 상태 기록하기

플러그인을 설치하기 전에 호스팅 관리 화면과 고객센터 문서에서 LiteSpeed, Nginx FastCGI, Varnish, 관리형 페이지 캐시 또는 CDN의 전체 페이지 캐시가 켜져 있는지 찾습니다. 이미 HTML을 저장하는 계층이 있다면 플러그인에서는 중복 페이지 캐시를 끄거나 호스팅 권장 플러그인을 선택해야 합니다. 워드프레스 공식 문서도 페이지 캐시, 브라우저 캐시, 객체 캐시와 서버 캐시를 서로 다른 역할로 구분합니다.

변경 전에는 홈, 글 한 개, 검색 또는 문의 페이지를 시크릿 창에서 각각 두 번 열고 응답 시간과 화면을 기록합니다. PageSpeed 점수 한 번만 비교하면 네트워크 변동을 캐시 효과로 오해할 수 있으므로 PageSpeed 점수가 매번 다를 때의 3회 측정법처럼 같은 조건에서 반복 측정하세요.

안전한 설정 순서와 단계별 통과 기준

각 단계 사이에는 캐시를 비우고 시크릿 창과 모바일에서 홈, 글, 메뉴, 검색, 댓글, 문의 폼을 직접 눌러봅니다. 성능 개선값과 오류 유무를 같은 기록표에 적고 다음 단계로 넘어가세요. 자바스크립트 축소와 지연 실행을 동시에 켜면 메뉴가 멈춰도 어느 옵션이 원인인지 구분하기 어렵습니다.

캐시 적중 여부는 로그인 화면이 아닌 방문자 화면에서 본다

관리자 로그인 상태는 페이지 캐시를 우회하는 경우가 많습니다. 브라우저 개발자 도구의 Network에서 문서 요청과 Response Headers를 확인하세요. 플러그인이나 CDN에 따라 HIT, MISS, Age 표시가 다르므로 첫 요청과 두 번째 요청의 변화, HTML의 최신 여부를 함께 봐야 합니다. 헤더가 없다면 플러그인의 디버그 주석이나 호스팅 도구도 확인합니다.

브라우저 캐시의 no-cache는 저장 금지가 아니라 사용 전에 서버에 변경 여부를 확인하라는 의미입니다. 정적 파일의 긴 보관 기간은 파일명이나 버전값이 바뀐다는 전제가 필요합니다. 수정한 이미지가 계속 보이는 경우에는 브라우저·페이지·CDN 캐시를 5분 안에 구분하는 방법을 적용하면 무작정 전체 삭제하는 일을 줄일 수 있습니다.

로그인·장바구니·개인화 페이지는 제외한다

회원 이름, 주문 상태, 장바구니처럼 사용자마다 달라지는 HTML은 공유 페이지 캐시에서 제외해야 합니다. WooCommerce 공식 문서는 장바구니, 결제와 내 계정 페이지를 캐시하지 않도록 안내합니다. 플러그인이 자동 제외하더라도 실제 로그아웃·일반 회원·관리자 계정으로 각각 확인하고, 장바구니에 상품을 넣은 뒤 새로고침과 수량 변경까지 시험하세요. 쿠키가 있는 방문자만 우회하는 규칙은 플러그인과 CDN 양쪽에서 일치해야 합니다.

객체 캐시는 서버 지원을 확인한 뒤 적용한다

객체 캐시는 완성된 페이지가 아니라 워드프레스가 반복해서 읽는 데이터베이스 결과를 재사용합니다. Redis나 Memcached 서비스가 실제로 실행 중이어야 하며 버튼만 켠다고 영구 객체 캐시가 생기지 않습니다. 연결 상태, 사용 메모리와 적중률을 확인하고 장애 시 객체 캐시를 끈 뒤 사이트가 정상 동작하는지도 시험해야 합니다. 자세한 절차는 워드프레스 Redis 객체 캐시 안전 적용 순서에서 이어서 확인할 수 있습니다.

문제가 생겼을 때 5단계 복구 순서

1. 마지막으로 켠 최적화 옵션 하나를 끕니다.
2. 해당 URL의 페이지 캐시만 먼저 삭제합니다.
3. 변화가 없으면 CDN 캐시와 브라우저 캐시를 구분해 확인합니다.
4. 시크릿 창에서 화면과 메뉴·폼 동작을 다시 시험합니다.
5. 정상이면 원인 옵션 또는 파일을 기록하고 예외 목록을 최소화합니다.

전체 캐시 삭제를 반복하면 원인이 가려지고 많은 페이지가 다시 생성되어 서버 부하가 늘 수 있습니다. 개별 URL 삭제를 우선 사용하세요. 관리자 화면에도 들어갈 수 없다면 호스팅 복구 기능이 필요할 수 있으므로 변경 전 백업과 설정 화면 캡처를 남겨두세요.

TIP

캐시 플러그인을 바꿀 때는 기존 플러그인을 비활성화하기 전에 캐시를 비우고, 삭제 후에도 남을 수 있는 고급 캐시 파일이나 서버 설정은 제품 문서에 따라 확인하세요. 새 플러그인 설치 전 로그아웃 화면이 정상인지 먼저 확인하면 기존 잔여 설정과 새 설정 문제를 구분하기 쉽습니다.

자주 묻는 질문

캐시 플러그인을 두 개 사용하면 더 빨라지나요?

같은 HTML을 저장하는 페이지 캐시 기능은 하나를 중심으로 사용하는 편이 안전합니다. 이미지 최적화처럼 역할이 다른 기능은 함께 쓸 수 있지만 중복 기능은 한쪽에서 꺼야 원인 추적이 쉽습니다.

캐시 삭제가 글과 이미지를 지우나요?

일반적인 캐시 비우기는 재생성 가능한 임시 복사본을 삭제하며 원본 글이나 미디어를 지우지 않습니다. 다만 데이터베이스 정리와 파일 삭제 메뉴는 다른 기능이므로 실행 전 대상과 백업을 확인해야 합니다.

공식 자료

• WordPress 캐시 종류와 역할
• WordPress 성능 최적화 안내
• WooCommerce 캐시 제외 페이지 안내
• MDN HTTP 캐시 설명

마무리

워드프레스 캐시 플러그인의 핵심은 최고 점수용 옵션을 복사하는 것이 아니라 현재 캐시 계층을 확인하고 페이지 캐시부터 한 단계씩 검증하는 것입니다. 제외 페이지, 캐시 적중, 모바일 기능과 복구 절차까지 통과해야 설정이 끝납니다. 변경 전후 기록을 남기면 속도가 실제로 개선됐는지 판단하고 화면 깨짐도 빠르게 되돌릴 수 있습니다.