워드프레스 OPcache·PHP-FPM 최적화｜20분 서버 진단

2026년 8월 7일 읽는 시간 약 7분

워드프레스 공개 페이지와 관리자 화면이 모두 느린데 캐시 플러그인을 바꿔도 차이가 없다면 PHP 실행 구간을 확인할 차례입니다. OPcache는 PHP 파일을 매 요청마다 다시 해석하는 작업을 줄이고, PHP-FPM은 동시에 들어온 PHP 요청을 작업자 프로세스에 배분합니다. 둘은 역할이 다르므로 활성화 여부만 보거나 작업자 수부터 늘리면 원인을 놓치기 쉽습니다.

이 글은 고정 권장값 대신 20분 동안 캐시 상태, FPM 대기와 메모리를 기록해 조정할 구간을 판단하는 방법을 설명합니다.

요청이 OPcache PHP-FPM 워드프레스를 거쳐 응답되는 처리 흐름

먼저 구분할 두 가지 병목

구분	OPcache 문제 신호	PHP-FPM 문제 신호
역할	미리 컴파일한 PHP 바이트코드 저장	PHP 요청을 처리할 작업자 관리
살펴볼 값	활성화, 사용·여유 메모리, 캐시된 스크립트, hit rate, 재시작 횟수	활성 작업자, 유휴 작업자, 대기열, 최대 작업자 도달, slowlog
의심 상황	캐시가 가득 차거나 재시작이 반복됨	동시 요청 때 대기가 늘고 max children 경고가 발생함
잘못된 대응	상태 확인 없이 메모리만 크게 설정	프로세스별 메모리를 재지 않고 작업자만 증가

OPcache 메모리 캐시 재시작과 PHP-FPM 작업자 대기열 점검 신호

OPcache는 미리 컴파일한 PHP 바이트코드를 공유 메모리에 보관합니다. 완성된 HTML을 저장하는 페이지 캐시와는 다른 단계입니다.

20분 진단 순서

1. 같은 URL의 첫 요청과 반복 요청 비교

로그아웃 상태에서 캐시 대상 글 하나와 캐시되지 않는 관리자 요청을 각각 여러 번 확인합니다. 첫 요청만 느리고 반복 요청이 빨라지면 페이지 캐시 영향이 큽니다. 매번 서버 응답이 느리다면 PHP·데이터베이스 또는 외부 요청을 더 살펴야 합니다. 먼저 워드프레스 TTFB 점검 방법으로 브라우저 대기 시간과 서버 처리 구간을 분리하세요.

2. OPcache 상태를 읽기 전용으로 확인

호스팅 제어판의 PHP 정보나 서버 관리 화면에서 OPcache 활성화 여부를 확인합니다. 직접 관리하는 서버라면 제한된 관리자 환경에서 opcache_get_status(false)가 제공하는 메모리 사용량, 통계, 재시작 정보를 확인할 수 있습니다. 이 상태 정보에는 서버 내부 경로가 포함될 수 있으므로 결과를 공개 웹페이지에 출력하지 마세요.

여유 메모리가 거의 없거나 캐시가 가득 찬 상태에서 oom_restarts·hash_restarts가 증가할 때 용량 조정을 검토합니다. hit rate만 보지 말고 배포 시각과 측정 기간도 기록하세요.

3. PHP-FPM 포화 여부 확인

느려진 시각의 FPM 상태와 오류 로그에서 대기 요청과 max children reached 경고를 찾습니다. 이 경고와 502·504 또는 TTFB 상승이 같은 시간대에 반복되면 작업자 부족을 의심합니다. 대기열 없이 특정 요청만 길다면 플러그인, 쿼리나 외부 API를 먼저 확인하세요.

서버 권한이 없다면 Query Monitor로 느린 플러그인과 쿼리 찾기부터 진행하세요.

4. 작업자 한 개의 실제 메모리 측정

pm.max_children은 동시 요청 수의 상한입니다. 운영체제, 웹서버, 데이터베이스와 Redis 몫을 제외하고 피크 시간대의 작업자별 메모리를 측정하세요. 평균값만 쓰면 무거운 관리자 요청이 겹칠 때 메모리가 부족할 수 있습니다.

프로세스 관리 방식 선택 기준

방식	동작	검토할 환경
`dynamic`	최소·최대 유휴 작업자 범위에서 수를 조절	방문이 꾸준하고 응답 준비 시간을 줄이고 싶은 사이트
`ondemand`	요청이 올 때 작업자를 생성하고 유휴 시 종료	트래픽이 드물거나 여러 작은 사이트가 메모리를 나눠 쓰는 서버
`static`	고정된 수의 작업자를 유지	부하와 메모리를 예측하며 관리하는 전용 환경

어떤 방식이 항상 더 빠른 것은 아닙니다. 트래픽 패턴과 메모리 예산을 기준으로 선택하세요.

변경 전후 기록표

측정 시각과 같은 테스트 URL
캐시 HIT·MISS 및 TTFB 중앙값
OPcache 사용·여유 메모리와 재시작 횟수
FPM 활성·유휴 작업자와 대기열
최대 작업자 도달 경고와 502·504 발생 시각
서버 전체 여유 메모리와 스왑 사용 여부
변경한 항목 하나와 이전 값

한 번에 하나만 바꾸고 같은 URL로 다시 측정합니다. 설정 문법을 검사하고 공개 글·로그인·글 저장 같은 핵심 경로를 확인하세요. 간헐적 장애는 느려진 시각과 로그를 맞추는 점검법도 참고합니다.

TIP

opcache.validate_timestamps를 끄면 변경된 PHP 파일이 자동으로 반영되지 않을 수 있습니다. 코드 배포 때 캐시 무효화가 보장되는 운영 절차가 없다면 속도만 보고 비활성화하지 마세요. 워드프레스 코어·테마·플러그인 업데이트 후 이전 코드가 남는 문제를 만들 수 있습니다.

상태 페이지와 FPM status 경로는 공개하지 마세요. 공유 호스팅은 OPcache 재시작, PHP 작업자 한도 도달, 같은 시각의 메모리 부족·502 기록을 고객센터에 문의하세요.

자주 묻는 질문

OPcache를 켜면 캐시 플러그인은 필요 없나요?

아닙니다. OPcache는 PHP 바이트코드를, 페이지 캐시는 완성된 HTML을 저장합니다. 서로 다른 실행 구간을 줄이므로 대체 관계가 아닙니다.

max children 경고가 보이면 바로 값을 올려도 되나요?

먼저 그 시각의 대기열, TTFB, 502·504와 서버 여유 메모리를 함께 확인해야 합니다. 느린 요청 하나가 작업자를 오래 점유한 경우라면 원인 플러그인이나 쿼리를 고치는 편이 안전합니다.

공유 호스팅에서도 점검할 수 있나요?

서버 설정은 바꾸지 못해도 PHP 정보, 사이트 상태, 느려진 시각과 URL을 기록할 수 있습니다. 이 자료를 바탕으로 호스팅 업체에 OPcache와 PHP 작업자 상태를 확인해 달라고 요청하세요.

공식 참고 자료

핵심은 숫자를 크게 만드는 것이 아니라 느려진 시각의 근거를 남기는 것입니다. OPcache의 캐시 포화와 FPM의 요청 대기를 분리하고, 메모리 여유를 확인한 뒤 한 항목씩 바꾸면 속도 개선과 장애 예방을 함께 할 수 있습니다.

깨비

SJSBiz 운영자 깨비입니다. Windows, 워드프레스, 웹 서버와 데이터베이스에서 발생하는 문제를 공식 문서와 재현 가능한 점검 절차를 바탕으로 정리합니다. 직접 확인하지 않은 내용을 사용 후기처럼 표현하지 않으며, 테스트 환경과 버전·확인 날짜·주의사항을 가능한 범위에서 공개하고 오류 제보가 확인되면 내용을 수정합니다.

함께 보면 좋은 글

첫 댓글을 남겨보세요.