개요
WordPress 관리 화면에서 플러그인을 업데이트해도 업데이트 알림이 사라지지 않고 계속 반복되는 문제를 처리한 기록입니다. 업데이트는 성공했다고 표시되는데 화면을 새로고침하면 같은 플러그인의 업데이트 알림이 다시 떠 있었습니다.
처음에는 Kubernetes로 이전하면서 생긴 파일 권한이나 스토리지 문제로 의심했습니다. 확인해 보니 서로 무관한 두 가지 원인이 겹쳐 있었고, 두 번째 원인은 이쪽 환경 문제가 아니라 배포된 플러그인 패키지 자체의 문제였습니다. 같은 증상을 겪는 경우 진단 순서를 줄일 수 있도록 정리합니다.
환경
| 구성 요소 | 내용 |
|---|---|
| 플랫폼 | Kubernetes 자체 관리형 클러스터 |
| 애플리케이션 | WordPress (Apache + PHP 8.4, 커스텀 이미지) |
| 스토리지 | Rook CephFS (RWX), /var/www/html 전체 마운트 |
| 변경 전 리소스 | request 100m / 256Mi, limit 500m / 512Mi |
| 변경 전 PHP | memory_limit = 128M (이전 서버에서 그대로 승계) |
원인 ① — 업데이트 작업을 버틸 리소스 여유분 부족
먼저 파드의 실제 사용량을 확인했습니다.
kubectl top pod -n wordpress-system
아무 작업도 하지 않는 유휴 상태에서 이미 330~390Mi를 사용하고 있었습니다. 활성화된 플러그인이 여러 개인데 지속형 오브젝트 캐시를 쓰지 않는 구성이라 기본 사용량 자체가 높은 상태였습니다. 그런데 메모리 limit은 512Mi였습니다.
플러그인 업데이트는 순간적으로 부하가 몰리는 작업입니다. ZipArchive로 압축을 풀고 Plugin_Upgrader가 파일을 교체하는 동안 메모리와 CPU를 함께 사용합니다. 남은 여유가 120Mi 남짓인 상태에서는 이 작업을 안정적으로 끝내기 어렵습니다. 실제로 업데이트를 시도한 시점에 무관한 정적 자원 요청이 503으로 실패한 것이 같은 시간대에 관측되었습니다.
PHP 쪽도 이전 서버에서 memory_limit = 128M을 그대로 가져온 상태였습니다. 컨테이너의 cgroup 제한과 별개로 PHP 프로세스 자체가 자기 한도에 먼저 걸릴 수 있는 값입니다.
양쪽을 함께 올렸습니다.
# docker/wordpress/php-custom.ini memory_limit = 256M
# manifests/wordpress/wordpress.yaml
resources:
requests:
cpu: 150m
memory: 384Mi
limits:
cpu: "1"
memory: 1Gi
PHP 설정이 이미지에 포함되어 있어 이미지를 다시 빌드해 태그를 올린 뒤 배포했습니다. 이후 업데이트 도중 503이 발생하는 현상은 사라졌습니다.
원인 ② — 업스트림 패키지의 버전 헤더 불일치
리소스를 확보한 뒤 업데이트는 깨끗하게 완료되었습니다. 그런데도 업데이트 알림은 여전히 다시 나타났습니다.
여기서부터는 이쪽 환경 문제가 아니었습니다. WordPress가 설치된 플러그인의 버전을 어디에서 읽는지 확인하면 원인이 드러납니다. WordPress 코어는 플러그인 메인 PHP 파일 상단의 헤더 주석에 적힌 Version: 값을 설치된 버전으로 인식합니다. readme.txt의 Stable tag가 아닙니다.
설치된 파일의 헤더와 readme.txt를 직접 비교했습니다.
# 플러그인 메인 파일의 헤더 확인 grep -m1 "Version:" wp-content/plugins/<plugin-dir>/<plugin>.php # Version: 2.11.2 ← 설치된 버전으로 인식되는 값 # 같은 패키지의 readme.txt grep -m1 "Stable tag:" wp-content/plugins/<plugin-dir>/readme.txt # Stable tag: 2.12.0 ← 배포 저장소가 최신으로 인식하는 값
공식 배포 zip 안에서 두 값이 어긋나 있었습니다. 릴리스를 내면서 readme.txt의 Stable tag는 올렸는데 플러그인 파일의 헤더 주석은 이전 버전 문자열이 그대로 남아 있는 상태였습니다.
이 경우 알림은 구조적으로 사라질 수 없습니다. WordPress는 저장소가 알려주는 최신 버전과 헤더에서 읽은 설치 버전을 비교하는데, 업데이트를 아무리 반복해도 같은 헤더 문자열이 다시 설치되므로 두 값은 영원히 불일치합니다. 업데이트가 실패한 것이 아니라 성공해도 상태가 갱신되지 않는 것입니다.
공식 릴리스 내용으로 파일을 교체한 뒤 헤더의 버전 문자열만 실제 릴리스 버전에 맞게 직접 수정해 해소했습니다. 동작에는 영향이 없고 WordPress가 비교하는 문자열만 맞추는 일회성 조치입니다. 이 사례는 2026년 8월 시점에 특정 플러그인에서 관측한 것으로, 이후 배포본에서는 수정되었을 수 있습니다.
진단 순서
같은 증상을 만났을 때 확인 순서를 정리하면 다음과 같습니다.
| 단계 | 확인 내용 | 해당하면 |
|---|---|---|
| 1 | kubectl top pod으로 유휴 사용량과 limit 사이 여유분 |
리소스 상향 |
| 2 | 업데이트 시점 전후의 503·타임아웃 로그 | 리소스 상향 |
| 3 | 설치된 플러그인의 헤더 Version: vs readme.txt의 Stable tag |
업스트림 패키징 문제 |
| 4 | 파일 소유자·권한, 스토리지 쓰기 가능 여부 | 권한 문제 |
1~2단계가 정상인데 알림이 계속 반복된다면 3단계를 먼저 보시기를 권합니다. 권한이나 스토리지를 의심하며 시간을 쓰기 쉬운 지점인데, 헤더 한 줄만 비교하면 바로 판별됩니다.
결과 확인
# 파드 리소스 반영 확인
kubectl get deploy -n wordpress-system wordpress \
-o jsonpath='{.spec.template.spec.containers[0].resources}'
# 적용된 PHP memory_limit 확인
kubectl exec -n wordpress-system deploy/wordpress -- php -i | grep memory_limit
# 유휴 사용량과 limit 사이 여유분 재확인
kubectl top pod -n wordpress-system
리소스 상향 후 유휴 사용량 대비 여유가 확보되었고, 헤더 수정 후 관리 화면의 업데이트 알림이 더 이상 나타나지 않는 것을 확인했습니다.
정리
이전 작업에서 승계한 리소스 설정은 한 번 점검할 가치가 있습니다. 기존 서버에서 문제없이 돌던 값이라도 컨테이너 환경에서는 limit이 곧 하드 제한이라 여유분의 의미가 달라집니다. 특히 유휴 상태 사용량이 limit의 70%를 넘고 있다면 순간 부하를 견딜 여지가 거의 없는 상태입니다.
그리고 모든 증상이 내 환경 탓은 아닙니다. 이번처럼 배포된 패키지 자체의 메타데이터가 어긋난 경우, 인프라를 아무리 고쳐도 증상은 사라지지 않습니다. 재현되는 문제를 계속 자기 쪽에서만 찾고 있다면 업스트림이 보내온 것을 직접 열어보는 단계를 진단 순서에 넣어두는 편이 좋습니다.
참고
관련 포스트:
- Preserving the Real Client IP Behind Traefik: externalTrafficPolicy and mod_remoteip — 같은 WordPress 워크로드에서 처리한 또 다른 운영 이슈
- Migrating WordPress from a Standalone LAMP Server to Kubernetes with Traefik — 이 워크로드의 이전 과정과 초기 리소스 설정
- Enabling GitLab Container Registry over HTTPS with a Custom TLS Certificate — 커스텀 이미지를 재빌드해 배포하는 경로
- Kubernetes MariaDB Resource Limits and Health Probes — 같은 클러스터에서 리소스 한도를 조정한 다른 사례
참고 문서: WordPress — Plugin Header Requirements · Kubernetes — Managing Resources for Containers · PHP — memory_limit