워드프레스 백스크린(White Screen of Death) 완벽 해설

백스크린(White Screen of Death)은 눈에 보이지 않는 PHP 치명적 오류입니다. 워드프레스가 렌더링 도중 복구할 수 없는 오류에 부딪혀 PHP가 멈췄고, 운영 서버에서는 오류 표시가 꺼져 있기 때문에 원인이 출력되는 대신 빈 페이지가 돌아온 것입니다. 이 문제의 해결은 추측으로 하는 경우가 거의 없습니다. 디버그 로그를 켜고 wp-content/debug.log를 연 뒤, 마지막 fatal 줄을 읽으면 됩니다. 그 줄에는 문제가 발생한 정확한 파일 — 거의 항상 플러그인이나 테마 — 이 적혀 있고, 그 한 줄이 곧 수리의 전부입니다.

화면이 왜 비어 있나

PHP에는 display_errors라는 설정이 있습니다. 개발 환경에서는 보통 켜져 있어서, 치명적 오류가 발생하면 스택 트레이스가 화면에 출력됩니다. 하지만 실제 호스팅 서버에서는 기본적으로 꺼져 있습니다. 파일 경로와 오류를 방문자에게 노출하는 것은 보안 문제이기 때문입니다. 그래서 치명적 오류가 발생하면 — 더 이상 존재하지 않는 함수 호출, 로드되지 않은 클래스, 플러그인 업데이트 속 문법 오류 등 — PHP는 그대로 죽어버리고 아무것도 보내지 않습니다. 브라우저는 빈 문서를 렌더링합니다. 그것이 바로 “백스크린”입니다.

워드프레스 5.2부터는 이런 오류를 잡아내려고 시도하는 치명적 오류 핸들러(WP_Fatal_Error_Handler)가 있습니다. 이것이 제대로 동작하면 빈 페이지 대신 “이 웹사이트에 치명적인 오류가 있습니다”라는 메시지가 뜨고, 관리자 이메일 주소로 실제 오류 내용과 복구 모드(Recovery Mode) 링크가 담긴 메일이 발송되는 경우가 많습니다. 완전히 빈 화면이 뜬다면 대개는 이 핸들러가 실행되기도 전에 오류가 발생했다는 뜻입니다. 파싱/문법 오류(컴파일 시점에 걸림), 망가진 must-use 플러그인, 또는 활성 테마의 functions.php 안에서 발생한 치명적 오류 같은 경우죠. 어느 쪽이든 원인은 어딘가에 기록되어 있습니다. 그 기록을 켜기만 하면 됩니다.

순서대로 해결하기

1. 로그를 켠다. SFTP로 wp-config.php를 편집해서 /* That's all, stop editing! */ 줄 위에 다음을 추가합니다.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WP_DEBUG_DISPLAY를 false로 두면 오류가 공개 페이지에 노출되지 않고, WP_DEBUG_LOG가 오류를 wp-content/debug.log에 기록합니다. 새 기록이 생성되도록 문제가 발생한 페이지를 한 번 새로고침하세요.

2. 마지막 fatal을 읽는다. wp-content/debug.log를 열고 맨 아래를 봅니다.

tail -n 30 wp-content/debug.log

다음과 같은 줄을 찾으면 됩니다.

[14-Jul-2026 09:12:44 UTC] PHP Fatal error:  Uncaught Error: Call to undefined function wc_get_product() in /var/www/html/wp-content/plugins/some-addon/includes/class-widget.php:88

경로가 범인을 지목합니다. plugins/some-addon, 그게 답입니다. 트레이스가 길거나 메시지가 알쏭달쏭하다면(Allowed memory size exhausted, Cannot redeclare, 처음 보는 클래스 이름 등), 우리의 오류 로그 디코더에 붙여넣으세요. 잡음을 걷어내고, 경로가 가리키는 플러그인이나 테마가 무엇인지 알려주며, 해당 오류 유형이 무슨 뜻인지 설명해 줍니다.

3. 지목된 구성 요소를 비활성화한다. /wp-admin에 접근할 수 없으니 SFTP로 처리합니다. 문제가 된 플러그인 폴더 이름을 바꾸세요. 예: some-addon → some-addon.off. 워드프레스는 찾을 수 없는 폴더는 로드하지 못하므로 해당 플러그인을 비활성화하고 사이트가 되살아납니다. 로그가 테마를 가리킨다면, 활성 테마 폴더 이름을 바꿔 기본 테마로 전환하세요. 워드프레스가 기본 내장 테마인 twentytwentysomething으로 대체됩니다.

4. 로그가 기록되지 않는다면, wp-content에 쓰기 권한이 없거나 오류가 서버 수준에서 발생한 것입니다. 대신 호스트의 PHP 오류 로그를 확인하세요.

find . -name "error_log" -newermt "-1 hour"

같은 정보, 다른 파일입니다. cPanel/Apache 환경은 사이트 루트나 문제가 발생한 디렉터리에 error_log를 남기는 경우가 많습니다.

하지 말아야 할 것

메모리 한도부터 올리지 마세요. 온라인에서 가장 흔히 반복되는 조언이 WP_MEMORY_LIMIT를 256M나 512M로 올리라는 것입니다. 이건 로그에 실제로 Allowed memory size of N bytes exhausted라고 적혀 있을 때만 WSOD를 해결합니다. 오류가 Call to undefined function이라면 메모리를 늘려도 아무 소용이 없습니다. 무작정 설정 하나를 바꿨을 뿐 화면은 여전히 하얗습니다. 로그를 먼저 읽고, 메모리가 명시된 문제일 때만 메모리를 올리세요.

캐시를 비우고 진단을 끝냈다고 여기지 마세요. 백스크린은 어떤 HTML도 만들어지기 전에 서버에서 PHP가 죽는 현상입니다. 오래된 캐시 자산이 빈 문서를 만들 수는 없습니다. (망가진 캐싱 플러그인은 만들 수 있습니다 — 하지만 그 경우 로그가 해당 플러그인을 지목합니다. 바로 그게 핵심입니다.)

워드프레스 코어를 편집하거나 재설치하지 마세요. 치명적 오류가 wp-includes나 wp-admin에 있는 경우는 거의 없습니다. 로그가 가리키는 플러그인이나 테마에 있습니다. 코어 재설치는 느리고 위험하며, 아직 확인하지도 않은 증상을 붙잡고 씨름하는 일입니다.

모든 플러그인을 껐다가 하나씩 무작정 다시 켜지 마세요. 이분 탐색이 통하긴 하지만 느린 길입니다. 로그는 한 단계로 정확한 폴더를 알려줍니다. “전부 끄기” 방식은 읽을 수 있는 오류가 전혀 없을 때만 꺼내 드세요.

운영 환경에서 display_errors를 켠 채 두지 마세요. 사이트가 돌아오면 디버그 정의를 제거하거나(또는 WP_DEBUG를 다시 false로 설정) 하세요. 방문자에게 출력되는 오류는 당신의 경로를 노출합니다.

그래도 막혔다면?

로그가 플러그인을 지목했는데 비활성화해도 화면이 되돌아오지 않는다면, 첫 번째 오류 밑에 두 번째 치명적 오류가 깔려 있는 것입니다. 로그를 다시 켜고 새로운 마지막 줄을 읽으세요. 치명적 오류는 겹겹이 쌓입니다. 메시지 자체가 벽처럼 느껴진다면, 오류 로그 디코더에 넣어 오류 유형과 파일 경로를 대신 해석하게 하세요. 백스크린은 로그가 꺼져 있는 동안에만 미스터리로 남습니다.