코드 한 줄 직접 짜지 않고 끝낸 Docker 워드프레스 속도 튜닝: Codex 사용 후기

Docker로 운영 중인 워드프레스가 조금 더 빨라졌으면 했다. 목표는 Redis 오브젝트 캐시, 페이지 캐시, 이미지 최적화를 차례로 적용하는 것이었다. 그런데 이 작업에 사용한 Docker 설정, PowerShell 스크립트, PHP 게시 코드 중 내가 직접 작성한 코드는 한 줄도 없다. 나는 원하는 결과와 제한 조건을 설명하고 명령을 실행했으며, 실제 코드는 Codex가 만들었다.

먼저 밝히는 점: Codex가 서버를 마음대로 조작한 것은 아니다. 권한이 필요한 Docker 명령은 내가 직접 실행했고, 출력과 오류를 다시 Codex에 전달했다. Codex는 그 결과를 분석해 다음 스크립트를 만들고 수정했다. 운영 판단과 최종 확인은 사람이 맡고, 조사·코드 작성·반복 작업은 AI와 나눈 방식이다.

왜 Codex로 해보기로 했나

캐시 플러그인 하나만 설치하는 일이라면 관리자 화면에서도 할 수 있다. 하지만 내 서버에는 여러 Docker 서비스가 함께 실행되고 있었다. 이미 다른 Redis도 있었고, 워드프레스와 데이터베이스는 전용 내부 네트워크와 named volume을 사용하고 있었다. 잘못 건드리면 다른 서비스의 포트, 네트워크, 볼륨 또는 Cloudflare Tunnel에 영향을 줄 수 있었다.

그래서 Codex에 단순히 “Redis를 설치해 줘”라고 하지 않았다. 먼저 Compose 전체 구조, 실행 중인 컨테이너, 기존 Redis, 워드프레스 마운트, wp-config.php 위치를 조사하고, 백업 후 한 단계씩 적용하도록 요청했다. 권한이 허용되지 않는 명령은 내가 복사해서 실행할 수 있게 만들어 달라는 조건도 붙였다.

실제로 내가 한 일과 Codex가 한 일

구분	내가 한 일	Codex가 한 일
사전 조사	Docker 명령 실행과 결과 전달	Compose·컨테이너·마운트·네트워크 분석
설계	다른 서비스에 영향이 없어야 한다는 기준 제시	전용 Redis와 DB 인덱스 분리 구조 설계
구현	생성된 스크립트를 한 줄씩 실행	Compose, Dockerfile, PowerShell, PHP 코드 작성
오류 해결	오류 메시지를 생략하지 않고 전달	원인 분석 후 검사와 스크립트 수정
검증	사이트 화면과 관리자 설정 확인	HTTP, Redis 키, 플러그인, UTF-8 자동 검증

체감상 가장 편했던 부분은 긴 명령을 이해해서 다시 작성할 필요가 없었다는 점이다. Codex가 프로젝트 안에 실행용 .ps1 파일을 만들면 나는 다음처럼 한 줄만 실행하고 결과를 전달했다.

.\scripts\enable-redis-object-cache.ps1
.\scripts\enable-w3tc-redis.ps1
.\scripts\install-shortpixel.ps1
.\scripts\verify-cache-tuning.ps1

심지어 지금 읽고 있는 글도 같은 흐름으로 만들었다. Codex가 작업 기록을 재사용 문서와 워드프레스 블록 HTML로 정리하고, UTF-8 게시 스크립트로 기존 글을 업데이트했다. 나는 글이 실제 경험과 다르게 보이지 않도록 방향을 바로잡고 최종 내용을 확인했다.

완성된 캐시 구조

최종 구조는 Redis 하나를 워드프레스 전용 내부 네트워크에 두고 용도별 DB 인덱스를 나누는 방식이다. 호스트에는 6379 포트를 공개하지 않았다. 이미 다른 프로젝트가 사용 중인 Redis와도 네트워크가 분리되어 충돌하지 않는다.

역할	도구	Redis DB
워드프레스 오브젝트 캐시	Redis Object Cache	0
완성된 HTML 페이지 캐시	W3 Total Cache	1
데이터베이스 쿼리 결과 캐시	W3 Total Cache	2
이미지 압축과 WebP·AVIF 준비	ShortPixel	해당 없음

1. 기존 서버부터 조사했다

가장 먼저 실행 중인 컨테이너와 기존 Redis를 확인했다. 이 과정에서 다른 프로젝트가 이미 redis:7-alpine을 사용 중이라는 사실을 찾았다. 새 Redis는 별도 네트워크에 두고 호스트 포트를 열지 않기로 했다.

docker ps --no-trunc --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}\t{{.Networks}}\t{{.Status}}"
docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}\t{{.Networks}}\t{{.Status}}"
docker inspect <wordpress-container> --format '{{json .Mounts}}'
docker inspect <wordpress-container> --format '{{json .NetworkSettings.Networks}}'

워드프레스 본체는 /var/www/html named volume에 있었고 테마만 호스트에서 bind mount된 구조였다. 따라서 wp-config.php는 호스트의 파일을 추측해서 수정하지 않고 실제 컨테이너 볼륨 안의 파일을 먼저 백업했다.

2. 전용 Redis를 추가했다

Codex가 기존 네이밍 규칙과 네트워크 이름에 맞춰 Compose를 수정했다. Redis 메모리는 256MB로 제한하고, 공간이 부족하면 오래 사용하지 않은 키부터 제거하는 allkeys-lru 정책을 적용했다.

redis:
  image: redis:7-alpine
  container_name: myblog-redis
  restart: unless-stopped
  command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
  volumes:
    - myblog_redis_data:/data
  networks:
    - internal
  healthcheck:
    test: ["CMD", "redis-cli", "ping"]
    interval: 10s
    timeout: 5s
    retries: 5

redis-cli ping은 PONG을 반환했고, 메모리 제한과 정책도 실제 Redis 설정값으로 다시 확인했다.

3. Redis Object Cache를 연결했다

워드프레스 컨테이너에는 WP-CLI가 없었다. Codex는 본체에 도구를 억지로 설치하는 대신 같은 볼륨과 네트워크를 사용하는 일회용 WP-CLI 컨테이너를 이용하는 스크립트를 만들었다. wp-config.php에는 다음 설정이 들어갔다.

define('WP_REDIS_HOST', 'myblog-redis');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE', true);

별도 DB 상수를 지정하지 않은 Redis Object Cache는 기본 DB 0을 사용한다. 플러그인 설치와 활성화, drop-in 생성까지 자동으로 진행한 뒤 wp redis status에서 Status: Connected, Drop-in: Valid, Ping: PONG을 확인했다.

4. W3 Total Cache를 Redis에 연결했다

페이지 캐시는 Redis DB 1, 데이터베이스 캐시는 DB 2로 분리했다. W3 Total Cache의 Object Cache는 끈 상태로 유지했다. 이미 Redis Object Cache 플러그인이 object-cache.php를 관리하고 있기 때문에 두 플러그인이 같은 drop-in을 놓고 충돌하지 않도록 한 것이다.

Page Cache: Redis, DB ID 1
Database Cache: Redis, DB ID 2
W3TC Object Cache: 비활성화
Redis Object Cache: DB ID 0에서 계속 사용

여기서 W3 Total Cache가 Redis를 확실히 인식하도록 WordPress PHP 이미지에 PhpRedis 확장도 추가했다. 데이터 볼륨은 그대로 둔 채 애플리케이션 컨테이너만 다시 빌드하고 재생성했다.

오류가 계속 났을 때 오히려 Codex가 유용했다

작업이 처음부터 한 번에 성공한 것은 아니다. 오히려 실제 후기로 남기고 싶은 부분은 여기다.

PowerShell 줄바꿈 문제: 긴 명령을 복사하는 과정에서 경로가 끊겨 grep: /: Is a directory 오류가 났다. 이후 긴 한 줄 명령 대신 재실행 가능한 스크립트 파일로 바꿨다.
PhpRedis 검사 오판: 확장은 실제로 로드됐지만 검사 코드의 따옴표와 출력 처리 때문에 실패로 판정됐다. Codex가 검사 방법을 단순화해 실제 모듈 상태를 구분했다.
Redis DB 2가 계속 0: 홈페이지가 페이지 캐시에서 바로 반환되어 데이터베이스 캐시를 거치지 않았기 때문이다. REST API 요청으로 페이지 캐시를 우회하자 DB 2에 키 3개가 생성됐다.
잘못된 공개 주소: 게시물 주소가 blog.hongzi.us로 만들어졌다. Compose와 .env는 정상이었지만 기존 wp-config.php 상수가 남아 있었다. 백업 후 WP_HOME과 WP_SITEURL을 실제 주소인 hongzi.us로 교정했다.
한글 제목 깨짐: PowerShell에서 한글을 WP-CLI 인자로 직접 넘길 때 인코딩이 깨졌다. UTF-8 파일을 컨테이너에 읽기 전용으로 마운트하고, 저장 결과를 Base64와 SHA-256으로 검증하는 게시 방식으로 바꿨다.

오류가 날 때마다 내가 한 일은 출력 전체를 다시 붙여 넣는 것이었다. Codex는 성공한 척 넘어가지 않고 원인을 좁히는 진단 스크립트를 먼저 만들었다. 운영 서버 작업에서는 코드를 빨리 생성하는 능력보다 이 반복 과정이 더 유용하게 느껴졌다.

5. ShortPixel로 이미지 최적화를 준비했다

마지막으로 ShortPixel Image Optimizer를 설치하고 활성화했다. 플러그인 설치는 Codex가 만든 스크립트로 끝냈지만 API 키 발급과 압축 정책 선택은 내가 직접 했다. 외부 서비스의 계정과 결제 가능성이 걸린 설정까지 AI가 임의로 진행하지 않도록 경계를 나눈 것이다.

기존 이미지가 많다면 Bulk 최적화 전에 예상 사용량과 원본 백업 옵션을 먼저 확인하는 편이 안전하다. 손실 압축, WebP·AVIF 생성, CDN 사용 여부도 처음부터 전부 켜기보다 대표 이미지 몇 장으로 품질을 확인한 뒤 확대하는 것이 좋다.

최종 검증 결과

WordPress, MariaDB, Redis 컨테이너가 정상 실행
Redis 응답 PONG 및 allkeys-lru 확인
PhpRedis 확장 로드 확인
Redis Object Cache가 Connected·Valid 상태
DB 0 오브젝트 캐시 키 생성 확인
DB 1 페이지 캐시 키 생성 확인
DB 2 데이터베이스 캐시 키 생성 확인
홈과 게시물 모두 HTTP 200 응답
ShortPixel 설치·활성화 및 API 설정 완료

Codex를 써보며 느낀 장점

내 환경을 기준으로 코드를 만든다. 인터넷의 일반 예제를 그대로 복사하지 않고 실제 컨테이너 이름, 네트워크, 볼륨 구조에 맞췄다.
반복 가능한 파일이 남는다. 채팅에서 끝나는 명령이 아니라 다음 워드프레스에도 수정해 사용할 문서와 스크립트가 남았다.
오류 메시지를 다음 행동으로 바꾼다. 내가 모든 도구의 문법을 몰라도 전체 출력을 주면 원인을 좁히고 검사 코드를 수정했다.
운영 안전 조건을 계속 기억한다. 백업, 전용 네트워크, 비공개 Redis 포트, DB 인덱스 분리, HTTP 200 검사를 작업 전후에 유지했다.

그래도 사람이 해야 하는 일

“코드를 한 줄도 직접 짜지 않았다”와 “아무것도 하지 않았다”는 같은 말이 아니다. 어떤 서버를 바꿀지, 허용할 범위가 어디까지인지, 오류가 났을 때 계속 진행할지, 외부 API 키와 비용을 어떻게 관리할지는 내가 결정해야 했다. 생성된 명령도 대상 컨테이너와 백업 여부를 보고 실행했다.

Codex는 한 번의 마법 같은 명령으로 모든 것을 끝내는 도구라기보다, 로그를 읽고 코드를 계속 고쳐 주는 기술 파트너에 가까웠다. 특히 운영 환경에서는 “천천히, 한 단계씩, 검증하고 다음으로”라고 요구한 것이 결과적으로 가장 빠른 방법이었다.

비슷하게 해보고 싶다면

목표뿐 아니라 건드리면 안 되는 서비스와 파일을 함께 알려준다.
먼저 조사하고 백업한 뒤 변경하도록 명시한다.
권한이 필요한 명령은 한 번에 하나씩 실행한다.
오류 메시지를 요약하지 말고 처음부터 끝까지 전달한다.
“설치 성공”에서 끝내지 말고 Redis 키, HTTP 상태, 플러그인 상태를 실제로 검증한다.
다시 사용할 수 있도록 마지막에 문서와 스크립트로 정리한다.

이번 작업으로 얻은 것은 빨라진 워드프레스 하나만이 아니다. 다음 서버에서도 반복할 수 있는 속도 튜닝 문서, 검증 스크립트, 게시 자동화 방식이 함께 남았다. 내가 코드를 직접 작성하지 않았다는 사실을 숨기기보다, 사람과 Codex가 각각 무엇을 맡았는지 솔직하게 남기는 편이 이 글을 읽는 사람에게도 더 도움이 된다고 생각한다.

참고 자료

이 글은 2026년 7월 30일부터 31일까지 진행한 실제 홈서버 작업 기록을 바탕으로 작성했다. 플러그인과 이미지 버전, 서비스 정책은 적용 시점의 공식 문서를 다시 확인해야 한다.

실제 설정 방법이 궁금하다면

Redis Compose 구성, PhpRedis 설치, W3 Total Cache의 DB 분리, ShortPixel 설정과 검증 명령은 아래 기술 가이드에 단계별로 정리해 두었다.

Docker 워드프레스 속도 튜닝: Redis 캐시와 이미지 최적화 →