워드프레스를 운영하다 보면 500 Internal Server Error나 화이트 스크린(흰색 화면) 같은 오류를 접할 때가 있습니다. 문제를 해결하기 위해서는 먼저 원인을 파악해야 합니다. 워드프레스의 경우 wp-config.php 파일에서 WP_DEBUG를 true로 변경하여 디버그 모드를 활성화하면 PHP 오류나 경고 메시지가 화면에 표시될 수 있습니다. 하지만 디버그 모드를 활성화해도 하얀 화면만 나오거나 아무런 에러 메시지가 표시되지 않는 경우가 있을 수 있습니다.
디버그 모드를 켰음에도 에러 내역을 확인할 수 없거나, 에러 메시지가 표시되더라도 치명적인 오류와 관련된 내용이 없다면, 워드프레스 자체(코어·플러그인·테마)의 문제가 아니라 서버 환경(메모리 제한, PHP 설정, .htaccess, 타임아웃 등) 쪽 문제일 확률이 높습니다.
참고로 클라우드웨이즈를 이용하는 경우에는 해당 애플리케이션 관리 페이지에서 오류 로그와 액세스 로그를 확인할 수 있습니다. (👉 클라우드웨이즈(Cloudways) 워드프레스 오류 로그 확인 방법 참고)
워드프레스 wp-config.php 디버그 모드를 켜도 오류 로그가 표시되지 않는 경우
최근에는 Vultr HestiaCP 환경의 한 워드프레스 블로그에서 Internal Server Error 문제가 발생하여 문제 해결을 맡은 적이 있습니다.
먼저 워드프레스 접속 경로를 파악한 뒤, wp-config.php 파일에서 디버그 모드를 활성화하여 오류 메시지 확인을 시도했습니다. 하지만 화면에는 아무런 에러 메시지가 표시되지 않았고, 오류 로그를 파일로 저장하도록 설정해도 로그 파일 자체가 생성되지 않았습니다.
워드프레스에 문제가 발생하면 보통 오류 로그를 먼저 확인해 원인을 추정합니다. 대개는 치명적인 오류가 발생한 지점을 짐작할 수 있는 메시지가 로그에 남지만, 간혹 아무런 메시지도 남지 않는 경우가 있습니다. 이런 경우에는 단서 자체가 없기 때문에 원인 파악이 쉽지 않고, 문제 해결도 그만큼 막막해질 수밖에 없습니다.
디버그 모드를 활성화했는데도 오류 메시지도, 로그도 전혀 남지 않는다면, 문제가 워드프레스(PHP 코드) 레벨이 아니라 그보다 앞단인 웹 서버 레벨에서 발생하고 있을 가능성이 높습니다.
에러의 발생 위치가 '워드프레스'가 아닌 '웹 서버'인 경우
디버그 모드가 침묵하는 가장 흔하면서도 치명적인 이유는, 애초에 에러가 워드프레스(PHP)에 도달하기도 전에 발생했기 때문일 수 있습니다. 워드프레스의 WP_DEBUG는 플러그인 충돌, 테마 오타, PHP 함수 오류 등 워드프레스 내부의 문제만 잡아낼 수 있습니다.
해당 서버의 액세스 로그를 확인해보니, ClaudeBot이나 SemrushBot 같은 크롤러 봇들이 짧은 시간에 과도하게 접속하면서 서버에 부하를 유발하고 있는 것으로 보였습니다. 이렇게 트래픽이 몰리면 서버의 CPU·메모리 리소스가 고갈되면서 PHP-FPM 워커 프로세스가 요청을 정상적으로 끝맺지 못하고 타임아웃되거나 강제 종료될 수 있습니다. 이 경우 PHP의 에러 핸들러가 개입할 기회조차 없기 때문에, 워드프레스에서 디버그 모드를 활성화해도 아무런 에러 메시지가 표시되지 않았던 것으로 추정되었습니다.
화면 출력 옵션(WP_DEBUG_DISPLAY)
많은 경우 WP_DEBUG만 true로 켜도 대부분의 환경에서는 화면 출력 옵션(WP_DEBUG_DISPLAY)이 true로 설정되어 화면에 에러가 출력됩니다.
define( 'WP_DEBUG', true );운영 중인 사이트에서는 방문자에게 에러 코드가 노출되지 않도록 아래처럼 명시적으로 false로 지정해 화면 노출을 차단하고, 대신 /wp-content/debug.log 파일에 조용히 기록되도록 하는 것이 안전합니다.
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );디버그 모드를 True로 설정했는데도 화면에 에러가 전혀 뜨지 않고 로그 파일도 생성되지 않는다면, 이는 출력 옵션의 문제가 아니라 워드프레스가 해당 설정을 적용할 시점에 도달하기도 전에 문제가 발생했거나, 서버 레벨에서 관련 설정이 강제로 제한되어 있을 가능성을 의심해봐야 합니다.
서버 레벨의 보안 설정(php.ini) 개입
HestiaCP, CyberPanel 등 서버 제어판을 사용하거나 호스팅 업체의 보안 설정이 빡빡한 환경에서는, PHP-FPM 풀(pool) 설정에서 php_admin_value[display_errors] = off 또는 php_admin_flag[display_errors] = off 형태로 에러 출력이 강제로 차단되어 있는 경우가 있습니다.
일반적인 php.ini나 .htaccess 설정이라면 워드프레스가 WP_DEBUG_DISPLAY를 통해 내부적으로 실행하는 ini_set() 호출로 얼마든지 덮어쓸 수 있지만, php_admin_value/php_admin_flag로 지정된 설정은 시스템 레벨로 고정되어 런타임에 어떤 코드로도 변경할 수 없습니다.
따라서 이런 경우 wp-config.php에서 아무리 화면에 에러를 띄우라고 명령해도, 이보다 더 상위 권한을 가진 PHP-FPM 풀 설정이 이를 원천적으로 억제해 버리는 것입니다.
올바른 원인 파악 및 조치 방법
워드프레스 디버그 모드로 원인을 찾을 수 없다면 아래의 순서대로 서버 자체를 점검해 볼 수 있습니다.
- 웹 서버 에러 로그 직접 확인: 워드프레스가 아닌 Nginx나 Apache의 error.log 파일을 확인해야 합니다. (예: /var/log/nginx/domains/내도메인.error.log) 여기에 upstream timed out 같은 메시지가 남아있다면 PHP-FPM 응답 지연으로 인한 타임아웃입니다.
만약 타임아웃 메시지 대신 recv() failed나 Connection reset by peer 같은 메시지가 보인다면, PHP-FPM 워커 프로세스가 예기치 않게 종료되었을 가능성이 있습니다. 이 경우 메모리 부족(OOM)이 원인인지 확인하려면 dmesg 명령어나 /var/log/kern.log(또는 journalctl -k) 같은 커널 로그를 함께 확인해야 합니다. Out of memory: Killed process와 같은 기록이 있다면 서버 리소스(메모리) 문제로 확정할 수 있습니다. - 서버 설정 상향 조정: 제어판이나 SSH를 통해 PHP의 memory_limit, max_execution_time 등을 넉넉하게(예: 512M, 300초) 늘려 서버 리소스를 높여줍니다.
- 악성 봇 트래픽 차단: 에러의 근본적인 원인이 트래픽 과부하라면 서버 사양을 높이는 것만으로는 부족할 수 있습니다. Cloudflare WAF(웹 방화벽) 등을 활용하여 서버 자원을 갉아먹는 불필요한 AI 크롤러나 스크래퍼의 접근을 사전에 차단하는 것을 강구할 수 있습니다.
문제의 사이트에서는 서버 레벨에서 액세스 로그를 확인하고 SSH에서 오류 로그를 표시하도록 하여 문제의 원인을 파악하려고 시도했습니다.
웹 서버 컨트롤 패널을 사용하지 않는 일반적인 리눅스(Ubuntu/Debian, CentOS 등) 환경의 Nginx라면, 기본적으로 다음과 같은 경로에서 접속 로그와 오류 로그 파일을 확인할 수 있습니다.
- 접속 로그: /var/log/nginx/access.log
- 에러 로그: /var/log/nginx/error.log
단, 여러 도메인을 운영 중이라면 이 전역 경로 대신 /etc/nginx/sites-available/ 등에 있는 개별 도메인 설정 파일에 로그 경로가 따로 지정되어 있을 수 있으므로, 해당 설정을 함께 확인하는 것이 좋습니다. (Apache를 사용 중이라면 /var/log/apache2/error.log처럼 경로 자체가 다릅니다.)
헤스티아 CP를 사용하는 경우 다음과 같은 SSH에서 명령어로 최근 에러 로그 50줄이 표시됩니다.
tail -n 50 /var/log/nginx/domains/example.com.error.log
오류 로그와 접속 로그 등을 체크하여 문제의 원인을 파악하여 대응할 수 있습니다. 서버를 직접 운영한다면 원인의 원인을 파악하여 대응하는 것이 쉽지 않을 수 있습니다.
👉 워드프레스 또는 웹호스팅 관련 문제 해결에 어려움을 겪는 경우 여기에서 서비스(유료)를 의뢰하실 수 있습니다.
FAQ (질문과 답변)
Q1. WP_DEBUG를 true로 켜면 사이트 방문자에게도 에러 메시지가 보이나요?
네, WP_DEBUG를 true로 설정하면 WP_DEBUG_DISPLAY의 기본값도 true이기 때문에, 별도로 막아두지 않으면 사이트에 접속하는 모든 방문자에게 에러 메시지가 그대로 노출됩니다. 운영 중인 사이트라면 WP_DEBUG_DISPLAY를 false로, WP_DEBUG_LOG를 true로 설정해서 화면에는 안 보이고 로그 파일에만 기록되도록 하는 것이 안전합니다.
Q2. debug.log 파일은 어디에 생성되나요?
WP_DEBUG_LOG를 true로 설정하면 기본적으로 워드프레스 루트 디렉터리 기준 /wp-content/debug.log 경로에 생성됩니다. 만약 이 경로에 파일이 생성되지 않는다면, wp-content 디렉터리의 쓰기 권한 문제이거나 본문에서 다룬 것처럼 에러가 워드프레스 코드에 도달하기 전(웹 서버 레벨)에 발생하고 있을 가능성을 의심해봐야 합니다.
Q3. 디버그 모드는 문제 해결 후 다시 꺼두어야 하나요?
네, 원인 파악이 끝났다면 WP_DEBUG를 다시 false로 되돌려야 합니다. 디버그 모드를 계속 켜두면 debug.log 파일에 경고성 메시지까지 계속 누적되어 파일 용량이 커질 수 있고, 만약 WP_DEBUG_DISPLAY까지 true로 남아 있다면 보안상으로도 취약해집니다.
Q4. 내 서버가 HestiaCP인지 CyberPanel인지 어떻게 확인하나요?
가장 간단한 방법은 서버 관리자 로그인 페이지 URL이나 포트를 확인하는 것입니다. HestiaCP는 보통 8083 포트, CyberPanel은 8090 포트를 관리 페이지로 사용합니다. 호스팅 업체나 서버를 세팅해준 담당자에게 문의해서 확인하는 방법도 있습니다.
Q5. Cloudflare 없이 크롤러 봇 트래픽을 막을 수 있는 방법은 없나요?
Cloudflare를 사용하지 않는 환경이라면, robots.txt에 특정 봇의 접근을 제한하도록 명시하거나(강제성은 없음), 서버의 .htaccess 또는 Nginx 설정에서 User-Agent 기반으로 특정 봇의 요청을 차단하는 방법, 또는 fail2ban 같은 도구로 과도한 요청 빈도를 보이는 IP를 자동 차단하는 방법을 함께 검토해볼 수 있습니다.
워드프레스 레벨에서는 Wordfence와 같은 보안 플러그인을 설치하여 대응하는 것도 가능합니다.
Q6. 이런 서버 레벨 문제는 워드프레스 초보자도 직접 해결할 수 있나요?
로그 파일을 열어보고 읽는 것 자체는 누구나 가능하지만, PHP-FPM 풀 설정 수정이나 커널 로그 분석, 서버 리소스 상향 조정 등은 SSH 접근 권한과 리눅스 서버에 대한 기본 이해가 필요한 작업입니다. 직접 해결하는 데 어려움을 겪는다면 호스팅 업체의 기술 지원팀에 로그 내용을 캡처해서 문의해 보시기 바랍니다.
참고로 클라우드웨이즈(Cloudways)를 이용하는 경우에는 라이브 채팅을 통해 워드프레스 문제와 서버 문제 모두 문의가 가능합니다. 라이브 챗으로 지원을 요청할 때 한국어로 입력할 수 있고, 질문 맨 위나 맨 끝에 "인간 상담사에게 연력해주세요."라고 추가하면 인간 상담원과 대화가 가능합니다. (상담 내용을 한글로 입력하면 AI가 알아서 양방향 언어로 번역하는 것 같습니다.)
댓글 남기기