워드프레스 ‘영구 객체 캐시를 사용해야 합니다’ 경고, Redis로 해결한 과정

워드프레스 관리자 화면의 도구 → 사이트 상태를 열었더니 “영구 객체 캐시를 사용해야 합니다”라는 권장 사항이 나왔다. 이미 WP Super Cache를 사용하고 있었기에 처음에는 이상하게 느껴졌다. 캐시 플러그인이 있는데 또 다른 캐시가 필요하다는 뜻처럼 보였기 때문이다.

작성·검수 안내
이 글은 운영자의 실제 사용·운영 경험과 작성 당시 확인 가능한 자료를 바탕으로 정리했습니다. AI는 구성과 문장 편집을 보조했으며, 공개 전 사실관계·링크·적용 조건은 운영자가 최종 검토했습니다. 자세한 기준은 콘텐츠 제작·AI 활용 원칙에서 확인할 수 있습니다.

확인해 보니 WP Super Cache와 영구 객체 캐시는 서로 다른 일을 하고 있었다. 기존 페이지 캐시는 그대로 두고, Redis라는 도구와 Redis Object Cache 플러그인을 연결하자 해당 권장 사항이 사라졌다. 이 글은 개념부터 실제 확인 결과까지, 서버 용어에 익숙하지 않은 사람도 흐름을 이해할 수 있도록 정리한 기록이다.

캐시 플러그인이 있는데 왜 경고가 나왔을까?

WP Super Cache는 방문자에게 보여 줄 완성된 페이지를 저장한다. 누군가 같은 글을 다시 열면 워드프레스가 페이지를 처음부터 다시 만들지 않고, 저장해 둔 결과를 빠르게 보여 준다. 이것을 페이지 캐시라고 부른다.

반면 객체 캐시는 워드프레스가 데이터베이스에서 자주 찾는 정보를 저장한다. 글 정보, 메뉴, 사이트 설정과 같이 여러 번 사용하는 내용을 잠시 보관했다가 다시 꺼내 쓴다. 같은 정보가 필요할 때마다 데이터베이스를 반복해서 조회하는 일을 줄여 주는 것이다.

구분	저장하는 내용	주요 역할
페이지 캐시	완성된 웹페이지	일반 방문자에게 페이지를 빠르게 보여 준다
객체 캐시	자주 사용하는 데이터	반복되는 데이터베이스 조회를 줄인다

그러므로 WP Super Cache가 정상적으로 작동하고 있어도 Redis나 Memcached 같은 객체 캐시가 없다면 사이트 상태에 권장 사항이 남을 수 있다. 이번 경고는 WP Super Cache가 실패했다는 뜻이 아니었다.

이번에는 Redis를 사용했다

영구 객체 캐시로 Redis를 선택했다. Redis는 워드프레스가 자주 사용하는 정보를 메모리에 보관했다가 빠르게 돌려주는 프로그램이다. 워드프레스가 같은 정보를 다시 필요로 할 때 데이터베이스를 처음부터 조회하지 않고 Redis에 저장된 값을 사용할 수 있다.

다만 Redis를 설치하는 것만으로 연결이 끝나지는 않는다. 워드프레스를 실행하는 PHP가 Redis와 대화할 수 있어야 하고, 워드프레스 안에서도 둘을 연결할 도구가 필요하다. 이번에는 워드프레스 공식 플러그인 저장소의 Redis Object Cache를 사용했다.

전체 구조는 다음과 같다.

WP Super Cache는 기존처럼 완성된 페이지를 저장한다.
Redis는 워드프레스가 자주 사용하는 데이터를 저장한다.
Redis Object Cache 플러그인이 워드프레스와 Redis를 연결한다.

기존 캐시 플러그인을 지우거나 교체하지 않았다. 둘이 서로 다른 일을 담당하므로 페이지 캐시와 객체 캐시를 함께 사용했다.

변경 전에는 백업부터 준비했다

운영 중인 사이트의 설정을 바꾸는 작업이었으므로 데이터베이스와 주요 설정 파일을 먼저 백업했다. 객체 캐시를 추가한다고 게시물 내용이 직접 바뀌는 것은 아니다. 그래도 워드프레스 설정 파일이나 서버 설정에 오류가 생기면 접속에 영향을 줄 수 있다.

특히 wp-config.php는 워드프레스의 중요한 설정 파일이다. 따옴표나 괄호 하나만 잘못 입력해도 화면에 오류가 나타날 수 있다. 문제가 생겼을 때 바로 이전 상태로 돌아갈 수 있도록 복구용 백업을 준비한 뒤 작업을 시작했다.

아래 명령은 이번 작업처럼 Homebrew로 PHP와 WordPress를 운영하는 macOS 서버를 기준으로 한다. 일반 웹호스팅의 관리자 화면이나 Ubuntu 서버에서는 명령과 파일 위치가 다르다. 명령을 실행하기 전에 자신의 WordPress 설치 폴더와 백업 폴더를 확인해야 한다.

1단계: 설정 파일과 데이터베이스를 먼저 백업한다

다음 예시의 경로와 데이터베이스 이름은 자신의 환경에 맞게 바꾼다. 특히 명령에 비밀번호를 직접 적으면 터미널 기록에 남을 수 있으므로 -p까지만 입력하고, 요청이 나타날 때 비밀번호를 넣는 편이 안전하다.

# 백업 폴더 만들기
mkdir -p "$HOME/wordpress-backup-before-redis"

# WordPress 핵심 설정 파일 백업
cp /path/to/wordpress/wp-config.php \
  "$HOME/wordpress-backup-before-redis/wp-config.php"

# 데이터베이스 백업: 실행 후 비밀번호를 별도로 입력한다
mysqldump -u DB_USER -p DB_NAME > \
  "$HOME/wordpress-backup-before-redis/wordpress.sql"

/path/to/wordpress, DB_USER, DB_NAME은 예시다. 실제 값은 호스팅 관리 화면이나 기존 wp-config.php에서 확인하되, 그 파일에 있는 비밀번호는 글이나 질문 게시판에 복사하지 않는다. 백업 파일이 생성됐는지 ls -lh "$HOME/wordpress-backup-before-redis"로 확인한 다음 진행한다.

Redis가 처음에 시작되지 않았다

먼저 Homebrew로 Redis를 설치하고 로그인 후에도 자동으로 시작되는 서비스로 등록했다.

brew update
brew install redis
brew services start redis

# 서비스 상태와 실제 응답을 각각 확인한다
brew services list
redis-cli ping

정상이면 서비스 목록에서 Redis가 started로 보이고, 마지막 명령의 결과로 PONG이 나온다. 설치 명령이 성공했다는 메시지만 보고 다음 단계로 넘어가면 안 된다. 이번에는 설치를 마친 뒤에도 서비스가 정상적으로 시작되지 않았다.

시작되지 않을 때는 재설치보다 로그를 먼저 본다

Homebrew 기본 경로를 명령으로 구하면 Intel Mac과 Apple Silicon Mac의 경로 차이 때문에 덜 헤맨다. 다음 명령은 Redis 로그의 마지막 80줄과 실제 설정 경로를 확인한다.

tail -n 80 "$(brew --prefix)/var/log/redis.log"
brew --prefix redis
grep -n '^[[:space:]]*loadmodule' "$(brew --prefix)/etc/redis.conf"

원인은 Redis 설정에 현재 서버에는 설치되지 않은 추가 모듈을 불러오라는 내용이 남아 있었기 때문이었다. 그 모듈들은 일반적인 워드프레스 객체 캐시에 필요하지 않았다. 존재하지 않는 파일을 열려고 하다가 Redis가 멈춘 것이었다.

로그에 Can't load module 또는 모듈 파일을 열 수 없다는 오류가 있고, 해당 모듈을 실제로 사용하지 않는 것이 확인된 경우에만 그 loadmodule 줄 앞에 #을 붙여 비활성화한다. 모듈의 용도를 모른다면 무작정 지우지 말고 Redis Stack을 쓰는 구성인지 먼저 확인해야 한다. 수정 후에는 다음 순서로 다시 시작했다.

brew services restart redis
brew services list
redis-cli ping

이번 서버에서는 이 조치 후 PONG이 반환됐다. 이 응답은 Redis 프로세스가 요청을 받고 있다는 뜻이지만, 아직 WordPress가 Redis를 사용한다는 뜻은 아니다.

Redis는 외부 인터넷에 그대로 공개하지 않고 워드프레스가 실행되는 같은 서버 안에서만 접속할 수 있게 유지했다. 보호 모드도 끄지 않았다. 속도 개선 도구를 추가하더라도 외부에 불필요한 접속 통로를 열지 않는 것이 중요하다.

# 로컬 주소에만 바인딩되고 보호 모드가 켜졌는지 확인
grep -E '^(bind|protected-mode|port)' "$(brew --prefix)/etc/redis.conf"

같은 서버에서만 사용할 때는 보통 bind 127.0.0.1 ::1, protected-mode yes, port 6379가 확인돼야 한다. Redis를 외부에 공개하기 위해 보호 모드를 끄는 방식은 사용하지 않았다.

워드프레스와 Redis를 연결했다

Redis가 정상적으로 실행된 뒤 PHP가 Redis와 통신할 수 있도록 PhpRedis 확장을 설치했다. Homebrew PHP에서 PECL을 사용할 수 있는 환경이라면 다음 순서로 확인할 수 있다.

# 이미 설치됐는지 먼저 확인
php --ri redis

# "Extension 'redis' not present"라고 나올 때만 설치
pecl install redis

# 설치 후 PHP가 확장을 읽는지 재확인
php --ri redis

마지막 출력에 Redis Support => enabled가 보여야 한다. 웹서버가 이미 실행 중이었다면 PHP 확장 설치 후 웹서버 또는 PHP 서비스를 안전하게 다시 불러와야 한다. 재시작 명령은 Apache, Nginx, PHP-FPM 구성마다 다르므로 호스팅 환경의 명령을 사용한다. CLI에서만 확장이 보이고 WordPress 사이트 상태에서는 보이지 않는다면 웹서버가 사용하는 PHP 버전과 CLI의 PHP 버전이 같은지도 확인한다.

2단계: Redis Object Cache 플러그인을 연결한다

WordPress 관리자 화면에서 플러그인 → 새 플러그인 추가로 이동해 Till Krüss의 Redis Object Cache를 설치했다. 단일 사이트는 일반 활성화, 멀티사이트는 네트워크 관리자에서 네트워크 활성화를 선택한다.

이 워드프레스는 여러 하위 사이트가 함께 연결된 멀티사이트 구성이다. 따라서 플러그인을 하나의 사이트에만 켜지 않고 네트워크 전체에 활성화했다. 단일 워드프레스라면 해당 사이트에서만 활성화하면 된다.

플러그인을 연결하기 전에 wp-config.php의 “그만 편집하세요”라는 주석보다 위쪽에 다음 값을 추가했다. Redis가 WordPress와 같은 서버에 있고 기본 포트를 사용하는 경우의 예시다.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'my-wordpress:' );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );

WP_REDIS_PREFIX는 같은 Redis를 여러 WordPress가 함께 사용할 때 캐시 키가 섞이지 않게 구분하는 값이다. 사이트마다 겹치지 않는 영문 접두사를 사용한다. 호스팅 업체가 Redis 비밀번호, Unix 소켓, 다른 데이터베이스 번호를 제공했다면 업체 안내가 이 예시보다 우선한다.

설정 저장 후 관리자 화면의 설정 → Redis에서 연결 상태를 확인하고 Enable Object Cache를 눌렀다. 이때 플러그인이 wp-content/object-cache.php 드롭인 파일을 만들며, WordPress의 기본 비영구 객체 캐시 대신 Redis를 사용하게 된다.

관리자 화면에 Connected와 Drop-in: Valid가 함께 표시되는지 확인한다. 연결 실패라면 Redis 서비스의 PONG, PHP의 Redis Support => enabled, wp-config.php의 주소·포트 순서로 거슬러 올라가면 원인을 좁히기 쉽다.

‘연결됨’ 표시만 보고 끝내지 않았다

플러그인 화면에 Redis가 연결됐다고 나오는 것만으로는 실제 작동을 확신하기 어렵다. 연결 표시는 있지만 워드프레스가 실제로 값을 저장하지 못하는 상황도 확인할 필요가 있다.

첫 번째 요청에서 테스트 값을 객체 캐시에 저장한 뒤, 별도의 두 번째 요청에서 같은 값을 다시 읽었다. 서로 다른 요청 사이에서도 값이 조회됐다. 단지 한 페이지가 열린 동안만 메모리에 남은 것이 아니라 Redis에 캐시가 실제로 유지되고 있다는 뜻이다.

Redis 안에 워드프레스가 만든 캐시 항목이 생성된 것도 확인했다. 이 과정을 통해 Redis 서버, PHP 연결 기능, 워드프레스 플러그인, 객체 캐시 연결 파일이 모두 이어져 있다는 것을 확인했다.

3단계: 실제 캐시 저장을 두 번의 요청으로 검사한다

관리자 화면 표시만 보지 않고 WordPress가 제공하는 객체 캐시 함수로 값을 저장하고 다시 읽었다. 아래 첫 번째 스크립트는 WordPress가 로드되는 서버 안에서 한 번만 실행하는 진단 예시다. 웹에 공개된 폴더에 파일로 만들지 말고, 서버 터미널의 PHP CLI에서 실행한 뒤 테스트 키를 바로 삭제한다.

cd /path/to/wordpress

# 첫 번째 PHP 요청: 테스트 값 저장
php -r 'require "wp-load.php"; var_export(
  wp_cache_set("redis_check", "saved", "diagnostic", 60)
);'

# 두 번째 PHP 요청: 앞 요청에서 저장한 값 읽기
php -r 'require "wp-load.php"; var_export(
  wp_cache_get("redis_check", "diagnostic")
);'

# 진단 키 삭제
php -r 'require "wp-load.php"; var_export(
  wp_cache_delete("redis_check", "diagnostic")
);'

첫 번째 결과가 true, 두 번째 결과가 'saved'이면 서로 다른 PHP 요청 사이에서도 값이 유지된 것이다. 마지막 삭제 결과까지 확인한다. 두 번째 결과가 false라면 플러그인 화면만 믿지 말고 드롭인, Redis 연결, 캐시 그룹 설정을 다시 살펴본다.

사이트 상태에서 권장 사항이 사라졌다

마지막으로 워드프레스의 사이트 상태 검사를 다시 실행했다. 작업 전에는 권장 개선사항이 두 개였다. 그중 하나가 “영구 객체 캐시를 사용해야 합니다”였다.

Redis 객체 캐시를 적용한 뒤에는 해당 항목이 사라졌다.

Redis 영구 객체 캐시 적용 후 관련 권장사항이 사라진 워드프레스 사이트 상태 — Redis 객체 캐시 적용 후 영구 객체 캐시 권장이 사라지고 별개의 필수 모듈 권장만 남은 상태

Redis 객체 캐시 적용 후 권장 개선사항이 두 개에서 한 개로 줄어든 화면이다.

현재 화면에 남은 “하나 이상의 필수 모듈을 누락했습니다”는 PHP 모듈과 관련된 별도의 권장 사항이다. 영구 객체 캐시가 실패해서 남은 경고가 아니다.

워드프레스 내부 사이트 상태 검사에서도 영구 객체 캐시를 사용 중이라는 정상 결과가 확인됐다. 화면에서 권장 사항이 사라진 것만 본 것이 아니라, 실제 캐시 저장과 사이트 상태 검사까지 함께 확인한 것이다.

다른 사이트도 다시 확인했다

객체 캐시가 연결됐어도 사이트의 다른 기능에 문제가 생겼다면 완료된 작업이라고 보기 어렵다. 메인 사이트와 함께 운영 중인 AI, DB, Crypto, SearchBrief 사이트의 첫 화면을 각각 확인했다.

다섯 개 사이트 모두 정상적으로 열렸고 HTTP 200 응답을 반환했다. 기존 게시물과 예약 글, 테마, 자동발행 일정도 바꾸지 않았다. Redis와 PHP는 Mac이 다시 시작된 뒤에도 자동으로 실행되도록 설정했다.

공유 호스팅이라면 먼저 지원 여부를 확인한다

이번 작업은 Redis와 PHP 확장을 직접 설치할 수 있는 서버에서 진행했다. 일반적인 공유 호스팅은 사용자에게 서버 프로그램 설치 권한을 제공하지 않을 수 있다.

이런 환경에서는 Redis Object Cache 플러그인부터 설치하기보다 호스팅 업체에 다음과 같이 문의하는 것이 좋다.

제 워드프레스 호스팅에서 Redis 또는 영구 객체 캐시를 사용할 수 있나요?

호스팅 업체가 Redis를 지원한다면 접속 주소, 포트, 비밀번호 또는 전용 소켓 경로를 안내할 수 있다. 호스팅 업체가 권장하는 별도의 플러그인이 있을 수도 있다.

Redis가 준비되지 않은 서버에 플러그인만 설치하면 연결 오류가 나타날 수 있다. 매 요청마다 연결을 시도하다가 오히려 사이트가 느려질 수도 있다. 플러그인 설치보다 서버 지원 여부를 먼저 확인해야 하는 이유다.

문제가 생기면 어떻게 되돌릴까?

객체 캐시 적용 후 워드프레스가 열리지 않거나 Redis 연결 오류가 반복될 때는 Redis 서버만 멈추고 기다리면 안 된다. 워드프레스가 계속 Redis에 연결을 시도하며 더 느려지거나 오류가 나타날 수 있다.

일반적인 복구 순서는 다음과 같다.

워드프레스의 객체 캐시 연결 파일을 해제한다.
설정 파일에 추가한 Redis 연결 내용을 제거한다.
Redis Object Cache 플러그인을 비활성화한다.
사이트와 관리자 화면이 다시 열리는지 확인한다.
Redis와 PHP의 오류 기록을 확인해 원인을 찾는다.

관리자 화면에 접속할 수 있다면 설정 → Redis → Disable Object Cache를 먼저 사용한다. 관리자 화면도 열리지 않는 긴급 상황이라면 백업을 확인한 뒤 서버에서 드롭인 파일의 이름을 바꿔 WordPress가 읽지 못하게 할 수 있다.

cd /path/to/wordpress

# 파일이 존재하는지 확인한 뒤 비활성화용 이름으로 변경
ls -l wp-content/object-cache.php
mv wp-content/object-cache.php wp-content/object-cache.php.disabled

# 사이트가 정상화된 뒤 Redis 서비스를 멈춰야 할 때
brew services stop redis

그다음 wp-config.php에 추가한 WP_REDIS_* 항목을 제거하거나 주석 처리하고 플러그인을 비활성화한다. 원인을 고친 뒤 다시 연결할 때는 플러그인이 새 드롭인을 만들도록 관리자 화면의 Enable Object Cache를 사용한다. 플러그인 폴더나 데이터베이스를 먼저 삭제하는 식으로 복구하지 않는다.

설정 전에 만들어 둔 백업이 있다면 문제 발생 시 이전 상태로 돌아가기 훨씬 수월하다. 속도 권장 항목 하나를 없애려다가 사이트 안정성을 해치지 않도록 백업과 복구 순서를 함께 생각해야 한다.

실제 해결 순서를 다시 정리하면

이번에 진행한 작업을 짧게 정리하면 다음과 같다.

데이터베이스와 주요 설정 파일을 백업했다.
Redis 서버와 PHP의 Redis 연결 기능을 준비했다.
Redis 시작 오류의 원인을 로그에서 찾고 불필요한 설정만 정리했다.
Redis Object Cache 플러그인을 멀티사이트 전체에 활성화했다.
서로 다른 요청 사이에서도 캐시 값이 유지되는지 검사했다.
다섯 개 사이트의 정상 응답과 기존 글·예약·자동발행 상태를 확인했다.
사이트 상태에서 영구 객체 캐시 권장 사항이 사라졌는지 다시 확인했다.

워드프레스의 성능 최적화 문서도 페이지 캐시와 영구 객체 캐시를 서로 다른 최적화 방법으로 설명한다. 단순히 ‘캐시 플러그인이 있다’는 사실만으로는 어떤 부분이 캐시되고 있는지 알 수 없다. 자신의 캐시 플러그인이 페이지와 객체 중 어느 쪽을 담당하는지 확인할 필요가 있다.

마무리

이번 문제에서 가장 헷갈렸던 부분은 이미 캐시 플러그인을 사용하고 있는데도 왜 영구 객체 캐시 권장이 나오는지였다.

원인은 WP Super Cache와 Redis Object Cache가 다른 일을 하기 때문이었다. WP Super Cache는 완성된 페이지를 저장하고, Redis Object Cache는 워드프레스가 자주 조회하는 데이터를 저장한다. 둘은 경쟁하는 플러그인이 아니라 서로 다른 부분을 보완하는 구성이었다.

Redis와 워드프레스를 연결한 뒤 영구 객체 캐시가 실제로 값을 저장하고 다시 불러오는지 검사했다. 모든 사이트의 정상 응답을 확인했고, 사이트 상태에서도 관련 권장 사항이 사라졌다.

처음에는 영구 객체 캐시라는 이름이 어렵게 보였지만, 핵심은 ‘워드프레스가 반복해서 찾는 정보를 다음에 더 빠르게 다시 사용하도록 저장하는 기능’이다. 서버에 Redis를 설치할 수 있는 권한이 없다면 플러그인부터 설치하지 말고 호스팅 업체에 지원 여부를 먼저 확인하는 것이 안전하다.