Redis 객체 캐시 WordPress TTFB 가속 실전 (2026)

WordPress 블로그가 느리면 방문자가 떠납니다. Google/SOASTA Research(2017)는 모바일 페이지 로딩이 1초에서 3초로 늘어나면 이탈 확률이 32% 증가한다고 보고했습니다. 서버 응답(TTFB, Time To First Byte)이 느리면 이후 모든 단계가 함께 늦어집니다. 이 글에서는 VPS에 Redis 객체 캐시를 설치하고 WordPress와 연동해 TTFB를 줄이는 과정을 정리하고, 적용 전후를 직접 측정하는 방법을 안내합니다. 개선 폭은 사이트 구성에 따라 크게 다릅니다.

Redis 객체 캐시로 WordPress TTFB 줄이기 — 설치·연동 실전 가이드 (2026) — 사진: jurvetson / flickr (BY)

WordPress는 왜 느릴까 — DB 조회의 함정

WordPress는 매 페이지 요청마다 데이터베이스 쿼리를 수십 번 실행합니다. 글 본문, 카테고리, 태그, 메타 정보, 사용자 세션까지 전부 DB에서 가져와 PHP로 조립한 뒤 HTML로 내보냅니다. 방문자가 늘수록 DB가 헐떡이고 응답은 느려집니다. 검색 순위도 떨어지고 브라우저 뒤로가기도 누릅니다.

여기서 객체 캐시(object cache)가 필요합니다. 한 번 조회한 데이터를 메모리에 두고, 두 번째 방문자부터는 DB를 거치지 않고 메모리에서 바로 꺼내 줍니다. 그 메모리 저장소로 가장 널리 쓰이는 것이 Redis입니다.

Redis vs Memcached — 왜 Redis인가?

WordPress 객체 캐시 백엔드는 Redis와 Memcached가 양대 산맥입니다. Redis를 선택하는 이유는:

다양한 데이터 구조: 문자열뿐 아니라 리스트·해시·셋·정렬된 셋을 지원합니다. 복잡한 캐시 패턴도 표현 가능합니다.
영속성(persistence): 메모리 데이터를 디스크에 저장할 수 있어 재시작 후에도 캐시가 살아 있습니다.
레플리카(replication): 마스터-슬레이브 구성으로 장애 대비가 됩니다. 트래픽이 커지면 읽기 부하를 분산할 수 있습니다.
클라우드 매니지드 vs 자가 호스팅: ElastiCache/Upstash는 편하지만 비용이 됩니다. VPS에 직접 올리면 월 몇 달러로 끝납니다.

1. Redis 서버 설치 (Ubuntu/Debian VPS)

VPS에 접속해 Redis 서버를 설치합니다. 한 줄이면 끝납니다.

sudo apt update
sudo apt install -y redis-server

설치 후 보안 설정을 합니다. /etc/redis/redis.conf를 엽니다.

# 로컬에서만 접속 허용 (외부 노출 금지)
bind 127.0.0.1

# 비밀번호 설정 (필수)
requirepass your_strong_password_here

# 메모리 한계와 eviction 정책
maxmemory 256mb
maxmemory-policy allkeys-lru

allkeys-lru는 메모리가 가득 차면 가장 오래 안 쓰인 키부터 삭제한다는 뜻입니다. 캐시 용도에 가장 적합한 정책입니다. 설정 후 Redis를 활성화하고 재시작합니다.

sudo systemctl enable redis-server
sudo systemctl restart redis-server
redis-cli -a your_strong_password_here ping
# PONG 이 나오면 정상

2. WordPress에 Redis Object Cache 플러그인 연동

WordPress 관리자에서 Redis Object Cache 플러그인을 설치합니다. (Plugin Name: Redis Object Cache, 저자 Till Krüss). 설치 후 활성화합니다.

다음으로 wp-config.php에 Redis 접속 정보를 추가합니다. /* That's all, stop editing! */ 줄 위에 넣습니다.

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', 'your_strong_password_here');
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

플러그인 설정 페이지(Settings → Redis)에서 Enable Object Cache 버튼을 누릅니다. 상태가 Connected로 바뀌면 성공입니다. 이 순간부터 WordPress의 모든 객체 조회가 Redis를 경유합니다.

3. eviction 정책과 TTL 이해하기

allkeys-lru 정책은 메모리가 꽉 찼을 때 가장 오래 미사용된 키를 삭제합니다. 캐시는 언제든 다시 계산할 수 있는 데이터이므로, LRU 방식이 적절합니다.

WordPress 객체별로 TTL(Time To Live)이 다릅니다. 글 본문은 수정 전까지 캐시가 유효하고, 옵션 값은 alloptions 캐시로 묶여 관리됩니다. 메모리 상태는 다음 명령으로 확인합니다:

redis-cli -a your_password INFO memory
# used_memory_human, maxmemory_human, evicted_keys 확인

redis-cli -a your_password INFO stats
# keyspace_hits / keyspace_misses 비율이 캐시 효율

4. 효과 직접 측정하기 — Redis OFF vs ON

동일한 조건에서 Redis를 끄고 켠 뒤 TTFB를 측정해 비교해 보세요. curl -w로 첫 바이트까지 걸리는 시간을 잴 수 있습니다.

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n"   https://nicepang.co.kr/

측정은 여러 번(예: 10회) 반복해 평균을 내고, 캐시가 채워진 뒤의 값을 비교하세요. 숫자는 사이트 구성·플러그인·서버 사양에 따라 크게 다르므로 남의 수치를 기대치로 삼지 마세요. 기본 원리는 두 번째 요청부터 DB 조회 결과를 메모리에서 재사용한다는 것입니다 — 첫 방문자는 캐시가 비어 있어 DB를 거치고, 이후부터는 메모리에서 응답합니다.

5. 캐시 무효화와 트러블슈팅

글을 발행하거나 수정하면 해당 객체의 캐시가 자동으로 무효화됩니다. 하지만 플러그인 충돌이나 메모리 부족일 때는 수동 flush가 필요합니다:

# Redis 전체 flush (주의: 캐시 전체 삭제)
redis-cli -a your_password FLUSHDB

# 또는 WordPress 관리자에서 Redis Object Cache → Flush Cache

자주 겪는 문제:

Redis 장애 시 자동 폴백: 플러그인이 Redis에 연결하지 못하면 원래 DB 경로로 자동 전환됩니다. 사이트는 느려지지만 죽지는 않습니다.
플러그인 충돌: 일부 캐시 플러그인(W3 Total Cache, WP Rocket의 객체 캐시 옵션)과 충돌할 수 있습니다. 드롭인(droppin) 파일 충돌이 의심되면 wp-content/object-cache.php를 확인합니다.
메모리 부족: VPS RAM이 1GB 이하면 maxmemory를 128-192mb로 줄이세요. swap이 들어가면 역효과입니다.

마무리 — 다음 단계

Redis 객체 캐시를 붙이면 DB 조회가 줄어 서버 응답이 빨라질 수 있습니다. 적용 전후를 직접 측정해 효과를 확인하세요. 다음에는 Ansible playbook으로 이 Redis 설정 자체를 코드로 선언해, 서버가 여러 대여도 한 번에 같은 상태로 만드는 구성 관리 자동화를 다룹니다. VPS 데브옵스 시리즈의 다음 편을 참고하세요.

이 글은 nicepang.co.kr에 실제 적용한 설정을 기준으로 작성했습니다. VPS는 Vultr/DigitalOcean 추천 링크를 설명란에서 확인하세요.