WordPress 블로그가 느리면 방문자가 떠납니다. 구글이 3초 안에 페이지를 열지 않으면 이탈률이 급격히 올라간다고 발표한 만큼, TTFB(Time To First Byte)는 곧 검색 순위와 직결됩니다. 이 글에서는 VPS에 Redis 객체 캐시를 설치하고 WordPress와 연동해 실제 TTFB를 3초에서 0.5초로 줄인 전 과정을 정리합니다. nicepang.co.kr에 직접 적용한 실측 데이터를 포함합니다.
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-lruallkeys-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. 실측 비교 — nicepang.co.kr (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회 평균):
| 상태 | TTFB | Lighthouse Performance |
|---|---|---|
| Redis OFF | ~3.0s | 35-42 |
| Redis ON | ~0.5s | 62-71 |
TTFB가 6배 개선됐고, Lighthouse 점수도 20점 이상 올랐습니다. GTmetrix Waterfall에서도 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 객체 캐시 한 번으로 WordPress TTFB를 6배 줄였습니다. 이제 방문자 이탈이 줄고 검색 순위도 오릅니다. 다음에는 Ansible playbook으로 이 Redis 설정 자체를 코드로 선언해, 서버가 여러 대여도 한 번에 같은 상태로 만드는 구성 관리 자동화를 다룹니다. VPS 데브옵스 시리즈의 다음 편을 참고하세요.
이 글은 nicepang.co.kr에 실제 적용한 설정을 기준으로 작성했습니다. VPS는 Vultr/DigitalOcean 추천 링크를 설명란에서 확인하세요.
