WordPress를 더 빠르게 만드는 방법 : PHP 메모리와 성능 최적화 기초

 

 

※ 이 글은 운영자가 직접 홈서버를 운영하며 겪은 경험과 WordPress, PHP, Docker 공식 문서를 참고해 작성했습니다. 글의 문장 정리와 구성에는 AI 도구의 도움을 약간 받았지만, 최종적으로는 운영자가 직접 내용을 검토하고 확인했습니다.

WordPress를 더 빠르게 만드는 방법: PHP 메모리와 성능 최적화 기초

도입

어제는 WordPress를 설치한 뒤 가장 먼저 확인해야 할 기본 설정을 살펴봤습니다. 사이트 제목, 시간대, 고유주소, 관리자 이메일처럼 처음에는 작아 보이는 설정들이 실제 운영에서는 꽤 중요한 기준이 된다는 점을 확인했습니다.

이제 기본 설정까지 마쳤다면 다음으로 눈에 들어오는 것은 속도입니다. WordPress 관리자 화면이 조금 무겁게 느껴지거나, 이미지 업로드가 생각보다 느리거나, 플러그인을 설치한 뒤 반응이 둔해지는 경우가 생길 수 있습니다.

저도 처음에는 WordPress가 느리면 서버 성능이 부족한 줄만 알았습니다. Intel N100 홈서버라서 어쩔 수 없는 부분이라고 생각하기 쉬웠죠. 그런데 하나씩 살펴보니 서버 사양만의 문제가 아니었습니다. PHP 메모리, 업로드 제한, 실행 시간, 캐시 설정처럼 기본 환경에서 먼저 확인해야 할 항목들이 있었습니다.

이번 글에서는 복잡한 고급 튜닝보다, WordPress를 조금 더 빠르고 안정적으로 운영하기 위해 먼저 알아두면 좋은 성능 최적화 기초를 정리해보려고 합니다.

WordPress 성능 향상을 위해 PHP 메모리, 업로드 제한, OPcache, Docker 설정을 점검하는 기본 최적화 다이어그램입니다.

※ 다이어그램은 운영 환경 설계를 바탕으로 AI 도구를 활용해 제작했으며, 최종 구성과 내용은 운영자가 직접 검수했습니다.
출처: 디지털 장난감

본문

① WordPress는 왜 느려질까?

WordPress가 느려지는 이유는 하나로 딱 잘라 말하기 어렵습니다. WordPress는 혼자 동작하는 프로그램이 아니라 PHP, MariaDB, 웹서버, 테마, 플러그인, 이미지 파일이 함께 움직이는 구조이기 때문입니다.

예를 들어 방문자가 글 하나를 열면 WordPress는 데이터베이스에서 글 정보를 읽고, 테마 파일을 불러오고, 플러그인 기능을 적용한 뒤, 최종 화면을 만들어 보여줍니다. 이 과정 중 어디 하나가 무거워지면 전체 속도도 함께 느려질 수 있습니다.

요소	역할	느려질 수 있는 이유
PHP	WordPress 실행	메모리 부족, 실행 시간 제한
MariaDB	글과 설정 저장	쿼리 지연, 인덱스 부족
이미지	본문과 썸네일 표시	용량이 크면 로딩 지연
플러그인	기능 추가	과도한 기능과 충돌
테마	화면 구성	무거운 스크립트와 스타일

그래서 WordPress를 빠르게 만들려면 무조건 서버 사양부터 올리기보다, 어떤 부분이 병목이 되는지 먼저 나눠서 보는 것이 좋았습니다. 이번 글에서는 그중에서도 PHP 설정과 기본 캐시를 먼저 살펴보겠습니다.

② PHP 메모리는 어떤 역할을 할까?

WordPress는 PHP로 동작합니다. 그래서 PHP가 사용할 수 있는 메모리와 실행 시간은 WordPress 운영에 직접 영향을 줄 수 있습니다.

memory_limit은 PHP가 한 번에 사용할 수 있는 최대 메모리입니다. 이 값이 너무 낮으면 플러그인을 설치하거나 이미지를 처리하거나 관리자 화면에서 무거운 작업을 할 때 오류가 발생할 수 있습니다.

설정	역할	운영 관점
memory_limit	PHP가 사용할 수 있는 최대 메모리	관리자 화면, 플러그인, 이미지 처리에 영향
upload_max_filesize	업로드 가능한 파일 하나의 최대 크기	이미지와 파일 업로드에 영향
post_max_size	전송 가능한 전체 데이터 크기	파일 업로드와 폼 전송에 영향
max_execution_time	PHP 스크립트 최대 실행 시간	업데이트, 가져오기, 백업 작업에 영향

이 값들은 무조건 크게 잡는 것이 정답은 아닙니다. 하지만 기본값이 너무 낮으면 실제 운영 중에 불편함을 겪을 수 있습니다. 특히 이미지가 많은 블로그나 플러그인을 여러 개 사용하는 WordPress라면 한 번쯤 확인해볼 만한 항목입니다.

③ 이미지 업로드가 안 되는 이유

WordPress를 운영하다 보면 이미지가 올라가지 않거나, 업로드 제한에 걸리는 경우가 있습니다. 이때 가장 먼저 확인할 값은 upload_max_filesize와 post_max_size입니다.

예를 들어 upload_max_filesize가 2M으로 설정되어 있다면 5MB 이미지를 올릴 수 없습니다. 그런데 upload_max_filesize만 늘렸다고 항상 해결되는 것도 아닙니다. post_max_size가 더 작게 잡혀 있으면 전체 전송 크기 제한에 걸릴 수 있기 때문입니다.

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 60

이런 설정은 예시일 뿐입니다. 실제 값은 서버 메모리, 이미지 크기, 운영 목적에 맞춰 조정해야 합니다. 중요한 것은 이미지 업로드 문제가 생겼을 때 어디부터 확인해야 하는지 아는 것이었습니다.

④ OPcache는 왜 WordPress를 빠르게 만들까?

OPcache는 PHP 성능을 이야기할 때 자주 나오는 기능입니다. 처음에는 이름부터 조금 어렵게 느껴졌습니다. 하지만 아주 단순하게 생각하면, 자주 쓰는 PHP 코드를 매번 새로 해석하지 않도록 도와주는 캐시 기능에 가깝습니다.

비유하자면 자주 보는 책을 매번 책장 깊숙한 곳에서 꺼내는 대신, 책상 위에 올려두는 것과 비슷합니다. WordPress는 PHP 파일을 계속 실행해야 하기 때문에, OPcache가 활성화되어 있으면 반복 작업을 줄이는 데 도움이 될 수 있습니다.

• OPcache: PHP 코드를 캐시해 반복 처리 부담을 줄이는 기능
• Object Cache: 데이터베이스 조회 결과 등을 캐시하는 방식
• Redis: Object Cache를 구성할 때 자주 언급되는 별도 캐시 저장소

이번 글에서는 Redis까지 깊게 들어가지는 않겠습니다. 지금 단계에서는 OPcache가 PHP 실행 부담을 줄이는 기본 캐시라는 점만 이해해도 충분하다고 생각했습니다.

⑤ Docker에서는 어디에서 설정할까?

Docker로 WordPress를 운영할 때는 PHP 설정을 어디에서 바꿔야 하는지도 헷갈릴 수 있습니다. 서버에 직접 설치한 WordPress라면 php.ini를 찾아 수정하면 되지만, Docker 환경에서는 컨테이너 구조를 함께 생각해야 합니다.

대표적인 방법은 사용자 정의 php.ini 파일을 만들어 컨테이너에 연결하거나, Dockerfile로 이미지를 커스터마이징하는 방식입니다. 처음에는 간단히 설정 파일을 마운트하는 방식부터 이해하는 편이 좋았습니다.

services:
  wordpress:
    image: wordpress:latest
    volumes:
      - ./wordpress_data:/var/www/html
      - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini

그리고 uploads.ini에는 이런 값을 넣을 수 있습니다.

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 60

설정을 바꾼 뒤에는 컨테이너를 다시 시작해야 적용되는 경우가 많습니다. 그래서 변경 전에는 현재 설정을 기록해두고, 변경 후에는 실제로 적용됐는지 확인하는 습관이 필요했습니다.

⑥ 무조건 메모리를 크게 주면 될까?

성능 최적화를 생각하다 보면 메모리를 크게 주면 무조건 빨라질 것 같다는 생각이 듭니다. 예를 들어 128M보다 512M가 좋아 보이고, 512M보다 1024M가 더 좋아 보일 수 있습니다.

하지만 실제 운영에서는 무조건 크게 주는 것이 답은 아니었습니다. 서버 전체 메모리는 한정되어 있고, WordPress 외에도 MariaDB나 다른 컨테이너가 함께 동작할 수 있기 때문입니다. 특히 Intel N100 홈서버처럼 여러 서비스를 함께 운영하는 환경에서는 균형이 더 중요했습니다.

• 먼저 현재 증상을 확인합니다.
• 이미지 업로드 문제인지, 관리자 화면 문제인지 구분합니다.
• PHP 로그와 WordPress 상태를 확인합니다.
• 필요한 값만 단계적으로 조정합니다.
• 변경 후 실제 체감과 로그를 다시 확인합니다.

성능 최적화는 숫자를 크게 만드는 작업이 아니라, 현재 환경에 맞게 필요한 값을 찾는 과정에 가까웠습니다.

운영노트

아래 표는 WordPress 성능 최적화를 위해 먼저 확인할 수 있는 PHP 기본 설정입니다. 실제 권장값은 서버 사양, 플러그인 수, 이미지 사용량, 운영 목적에 따라 달라질 수 있습니다.

확인 항목	예시 값	운영 판단
memory_limit	256M	플러그인과 관리자 작업량에 따라 조정
upload_max_filesize	64M	이미지 업로드 크기에 맞게 조정
post_max_size	64M	업로드 제한과 함께 확인
max_execution_time	60	업데이트와 가져오기 작업에 영향
OPcache	활성 권장	PHP 반복 실행 부담 감소
이미지 용량	WEBP 압축	페이지 로딩 속도에 직접 영향

에디터의 해석노트

WordPress 성능은 서버 사양만으로 결정되는 줄 알았습니다. 그런데 하나씩 살펴보니 PHP 설정만 조금 바꿔도 체감이 달라질 수 있는 부분들이 있었습니다.

특히 이미지 업로드 제한이나 PHP 메모리처럼 평소에는 잘 보이지 않는 값들이 실제 운영에서는 꽤 자주 영향을 줄 수 있었습니다. 사이트가 느릴 때 무조건 플러그인부터 의심하기보다, 기본 실행 환경을 먼저 확인해야겠다는 생각이 들었습니다.

앞으로는 성능이 아쉬울 때 서버를 바꾸거나 설정을 크게 올리기보다, 현재 상태를 먼저 확인하고 필요한 값만 조금씩 조정하는 방식으로 운영해보려고 합니다.

참고 링크 (References)

1. PHP Runtime Configuration
2. PHP OPcache Manual
3. WordPress Performance
4. WordPress Official Docker Image
5. Docker Compose Documentation

트러블슈팅

문제: WordPress가 느리거나 이미지 업로드, 플러그인 설치 과정에서 오류가 발생함

WordPress를 운영하다 보면 관리자 화면이 느려지거나, 이미지 업로드가 실패하거나, 플러그인 설치 중 메모리 관련 오류가 나타날 수 있습니다. 이때는 WordPress 화면만 보지 말고 PHP 설정과 컨테이너 로그를 함께 확인하는 것이 좋습니다.

확인: PHP 메모리, 업로드 제한, 실행 시간, OPcache, 컨테이너 로그를 순서대로 점검

# WordPress 컨테이너 상태 확인
docker compose ps

# WordPress 로그 확인
docker compose logs wordpress --tail=100

# 설정 파일 마운트 후 컨테이너 재시작
docker compose restart wordpress

원인: PHP 메모리 부족, 업로드 제한값 부족, 실행 시간 제한, 이미지 용량 과다, 플러그인 충돌, 설정 파일 미적용

해결: memory_limit, upload_max_filesize, post_max_size, max_execution_time 값을 확인하고, Docker 환경에서는 설정 파일이 컨테이너에 제대로 마운트되었는지 점검합니다.

• 이미지 업로드 실패: upload_max_filesize와 post_max_size를 함께 확인합니다.
• 메모리 부족 오류: memory_limit 값을 확인합니다.
• 설정 미적용: 컨테이너를 재시작하고 설정 파일 경로를 확인합니다.
• 관리자 화면 느림: 플러그인 수, 이미지 용량, PHP 설정을 함께 확인합니다.
• 타임아웃: max_execution_time과 서버 리소스를 점검합니다.

이번 단계에서는 값을 한 번에 크게 바꾸기보다, 작은 설정을 하나씩 바꿔보고 실제로 어떤 차이가 있는지 확인하는 편이 더 안전하다고 느꼈습니다.

마무리

WordPress를 더 빠르게 만드는 방법을 살펴보면서, 성능 최적화가 특별한 기술 하나로 끝나는 일이 아니라는 걸 알게 됐습니다. PHP 메모리, 업로드 제한, 실행 시간, OPcache, 이미지 용량처럼 기본 환경을 차례대로 확인하는 과정에 더 가까웠습니다.

서버 사양을 높이면 어느 정도 도움이 될 수는 있습니다. 하지만 현재 설정을 모른 채 무작정 값을 크게 주는 방식은 좋은 운영이라고 보기 어려웠습니다. 특히 홈서버처럼 여러 서비스를 함께 운영하는 환경에서는 필요한 만큼만 조정하는 균형이 중요했습니다.

다음 글에서는 실제 홈서버 운영 관점에서 WordPress와 MariaDB의 로그를 어떻게 확인하고 관리할 수 있는지 살펴보겠습니다.