이 웹사이트에 치명적인 오류가 발생했습니다는 무슨 뜻인가요?

페이지를 만드는 도중 PHP에서 치명적 오류가 났고, 흰 화면이 뜨기 전에 WordPress가 그것을 가로챘다는 뜻입니다. 방문자에게 파일 경로나 코드가 노출되지 않도록 일부러 모호하게 표시합니다. 파일명과 줄 번호가 담긴 진짜 오류는 서버의 로그에 기록됩니다.

워드프레스 치명적 오류 로그는 어디에 있나요?

wp-config.php에서 WP_DEBUG와 WP_DEBUG_LOG를 true로 설정했다면 WordPress가 wp-content/debug.log에 기록합니다. 꺼져 있어도 오류는 호스팅의 PHP 오류 로그에 남으며, 보통 호스팅 관리 패널의 로그 또는 오류 로그 항목에서 볼 수 있습니다. 아무것도 기록되지 않았다고 단정하기 전에 두 곳을 모두 확인하세요.

워드프레스 복구 모드 메일이 오지 않는 이유는 뭔가요?

메일은 로그인 계정 주소가 아니라 설정에 등록된 사이트 관리자 이메일로 갑니다. 게다가 방금 죽은 그 PHP가 메일을 보내기 때문에 발송 자체가 실패하는 경우가 많습니다. 공용 호스팅은 SMTP 없이는 외부 메일 발송을 막기도 합니다. 스팸함을 확인한 뒤에는 메일을 포기하고 SFTP로 플러그인을 끄는 쪽이 빠릅니다.

wp-admin에 로그인할 수 없는데 치명적 오류를 어떻게 고치나요?

SFTP나 호스팅 파일 관리자로 접속해 wp-content/plugins 폴더 이름을 plugins-off로 바꾸세요. 모든 플러그인이 한 번에 비활성화되고 대부분 관리자 접속이 살아납니다. 이름을 되돌린 다음 플러그인을 하나씩 다시 켜다 보면 오류가 재현되는 지점에서 범인이 드러납니다.

PHP 버전 업그레이드가 워드프레스 치명적 오류를 일으킬 수 있나요?

네, 가장 흔한 원인 중 하나입니다. 호스팅이 PHP를 자동으로 올리는데, 삭제된 문법을 쓰는 오래된 플러그인이나 테마 코드는 즉시 치명적 오류를 냅니다. 로그에는 보통 wp-content 안의 특정 파일명이 찍힙니다. 호스팅 패널에서 PHP를 되돌려 보면 진단은 확실해지지만 어디까지나 임시방편입니다.

치명적 오류 메시지는 사이트가 해킹당했다는 뜻인가요?

대개는 아닙니다. 압도적 다수는 PHP 버전과 맞지 않는 플러그인·테마 업데이트이거나 메모리 부족입니다. 악성코드도 치명적 오류를 낼 수 있지만 그 경우 로그가 낯선 파일이나 난독화된 코드를 가리킵니다. 침해를 의심하기 전에 먼저 로그를 읽으세요.

이 웹사이트에 치명적인 오류가 발생했습니다: 무슨 뜻이고 어떻게 고치나

이 문구는 페이지를 만드는 도중 PHP에서 치명적 오류가 났고, 그것이 흰 화면으로 번지기 전에 WordPress가 붙잡았다는 뜻입니다. 오류는 실제로 존재하고, 구체적이며, 이미 기록되어 있습니다. 다만 WordPress가 브라우저에 그것을 찍지 않을 뿐입니다. 공개 페이지에 스택 트레이스가 나오면 아무나 파일 경로와 코드를 들여다볼 수 있으니까요.

그래서 해결은 추측이 아닙니다. 실제 오류를 읽고, 거기 적힌 대로 움직이면 됩니다.

실제로 일어난 일

WordPress 5.2부터 코어에 치명적 오류 처리기가 들어 있습니다. 요청 처리 도중 PHP가 죽으면 이 처리기가 끼어들어 크래시 출력을 점잖은 한 줄짜리 안내문으로 바꾸고, 원인이 된 플러그인이나 테마를 알아낼 수 있으면 복구 모드 링크를 담은 메일을 사이트 관리자에게 보내려 시도합니다.

예전의 백색 화면 대신 이 문구가 보이는 이유가 그것입니다. 개선이긴 하지만, 동시에 진단 정보가 기본적으로 감춰진다는 뜻이기도 합니다. 문구는 두세 가지 형태로 나타납니다.

화면에 보이는 것	위치	알 수 있는 것
”이 웹사이트에 치명적인 오류가 발생했습니다.”	로그아웃 상태의 프런트엔드	치명적 오류 발생, 그 이상 정보 없음
같은 문장 + “워드프레스 문제 해결에 대해 더 알아보기”	프런트엔드 또는 wp-admin	같은 오류, WordPress가 안내 문서를 제시
”…사이트 관리자 이메일 수신함에서 안내를 확인하세요.”	프런트엔드	처리기가 복구 메일을 보냈다고 판단한 상태

세 번째가 유용한 경우입니다. WordPress가 크래시의 원인을 특정 플러그인이나 테마로 지목했고, 들어갈 통로를 만들어 주려 했다는 뜻이니까요.

1단계: 복구 모드 메일 확인

WordPress는 복구 링크를 사이트 관리자 이메일 주소, 즉 설정 → 일반에 적힌 주소로 보냅니다. 로그인할 때 쓰는 주소와 다른 경우가 많습니다. 그 수신함과 스팸함을 확인하세요.

메일에는 ?action=enter_recovery_mode로 끝나는 긴 링크가 들어 있습니다. 링크를 열면 복구 모드로 wp-admin에 로그인되고, 문제를 일으킨 플러그인이나 테마가 일시 중지된 채 상단 빨간 알림에 표시됩니다. 거기서 평소처럼 비활성화하면 됩니다.

솔직하게 짚어야 할 점이 둘 있습니다. 첫째, 이 메일은 방금 죽은 바로 그 PHP 프로세스가, 그것도 메일 발송 기능이 아예 없을 수도 있는 서버에서 만들어 냅니다. 발송 실패는 흔하며, 메일이 오지 않았다는 사실 자체는 오류에 대해 아무것도 말해 주지 않습니다. 둘째, 복구 링크는 기본값 기준 하루 정도면 만료됩니다. 수신함에 남아 있는 옛 메일은 이미 쓸모없을 수 있으니, 사이트를 다시 열어 오류를 재현시키고 새 메일을 기다리세요.

메일을 실제로 확인하는 주소로 받고 싶다면 wp-config.php에 직접 지정하면 됩니다.

define( 'RECOVERY_MODE_EMAIL', '[email protected]' );

2단계: 진짜 오류 읽기

망가진 사이트를 5분짜리 작업으로 바꿔 주는 단계입니다. wp-config.php의 편집 중단 안내 줄 위쪽에 다음을 추가하세요.

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

WP_DEBUG_DISPLAY를 false로 두는 것이 핵심입니다. 오류를 디스크에는 기록하되 브라우저에는 내보내지 않으므로, 디버깅하는 동안 방문자에게 경로가 드러나지 않습니다.

망가진 페이지를 한 번 새로 고친 뒤 wp-content/debug.log를 여세요. 마지막 항목은 대략 이런 모양입니다.

PHP Fatal error:  Uncaught Error: Call to undefined function some_plugin_helper()
in /home/user/public_html/wp-content/plugins/some-plugin/includes/render.php:214

파일 경로가 곧 답입니다. wp-content/plugins/ 안을 가리키면 그 플러그인이 원인입니다. wp-content/themes/ 안이면 테마이고, 최근에 functions.php에 붙여 넣은 코드인 경우가 아주 많습니다.

debug.log가 생기지 않는다면 디렉터리에 쓰기 권한이 없거나 보안 플러그인이 로그 위치를 옮긴 것일 수 있습니다. 그럴 때는 호스팅의 PHP 오류 로그를 보세요. 대부분의 관리 패널에 “오류 로그” 또는 “로그” 항목이 있고, 같은 치명적 오류가 시각과 함께 남아 있습니다.

해당 항목을 WordPress 오류 로그 해석기에 붙여 넣으면 PHP식 표현이 실제로 무엇을 의미하는지, 어느 파일부터 봐야 하는지 알려 줍니다.

끝났으면 디버그 관련 줄은 지우세요. 운영 중인 사이트에 WP_DEBUG를 켜 두면 디스크가 차오르고, 어쩌다 WP_DEBUG_DISPLAY가 다시 켜지면 서버 경로가 공개적으로 찍힙니다.

3단계: wp-admin 되찾기

wp-admin까지 죽었고 복구 메일도 오지 않았다면, 파일 단위에서 모든 플러그인을 꺼 버리세요. SFTP(또는 호스팅 파일 관리자)로 접속해 폴더 이름 하나만 바꾸면 됩니다.

mv wp-content/plugins wp-content/plugins-off

WordPress가 플러그인을 찾지 못하니 전부 비활성화되고, 관리자 접속은 거의 언제나 돌아옵니다. 그다음에는,

폴더 이름을 다시 plugins로 되돌립니다. WordPress가 이미 비활성 상태로 기록했으므로 전부 꺼진 채 유지됩니다.
플러그인을 하나씩 다시 켜면서 매번 프런트엔드를 열어 봅니다.
오류를 되살리는 그 플러그인이 범인입니다.

플러그인을 다 껐는데도 사이트가 여전히 망가져 있다면 테마가 용의자입니다. wp-content/themes/에서 활성 테마 폴더의 이름을 바꾸면, 기본 테마가 설치되어 있는 경우 WordPress가 그쪽으로 넘어갑니다.

알아 둘 만한 원인 세 가지

치명적 오류를 내는 플러그인·테마 업데이트. 압도적으로 흔합니다. 로그가 파일명을 그대로 알려 줍니다. 해당 플러그인만 이전 버전으로 되돌리거나, 비활성 상태로 두고 로그 한 줄을 첨부해 개발자에게 문의하세요.

PHP 버전 불일치. 호스팅은 정해진 일정에 따라, 때로는 별다른 예고 없이 PHP를 올립니다. 옛 PHP를 전제로 쓰인 코드는 새 버전에서 아예 파싱되지 않기도 합니다. 내 쪽에서는 아무것도 바꾸지 않았는데 한꺼번에 망가졌다면 이 경우입니다. 호스팅 패널에서 PHP를 마이너 버전 하나 되돌려 보는 것은 유효한 진단이지만, 해결이 아니라 시간 벌기로 여기세요. 오래된 PHP 버전은 보안 패치를 받지 못합니다.

메모리 부족. 로그에 “Allowed memory size of X bytes exhausted”가 찍힙니다. wp-config.php에서 한도를 올리는 것은 타당합니다.

define( 'WP_MEMORY_LIMIT', '256M' );

다만 이것이 무엇을 하는지는 솔직히 알고 있어야 합니다. 천장을 치울 뿐, 페이지 하나 그리는 데 256MB를 먹어 치운 그 무언가는 그대로입니다. 한도를 계속 올려야 한다면 실제 문제는 따로 있습니다. 대개 임포트 작업, 페이지 빌더, 또는 형편없이 짜인 쿼리입니다.

무시해도 되는 조언들

“그냥 메모리 한도를 올려라.” 로그에 실제로 메모리 부족이 찍혔을 때만 의미가 있습니다. 그렇지 않다면 아무것도 바뀌지 않고, 오류를 읽지 않았다는 사실만 가려 줍니다.

“WordPress 코어를 재설치해라.” 코어 파일이 원인인 경우는 드물고, 파일을 갈아엎는 시간이면 로그 한 줄을 읽고도 남습니다.

“치명적 오류 처리기를 꺼라.” 그것을 끄는 상수가 있긴 합니다. 결과는 가로채진 오류 대신 날것의 오류가 공개 사이트에 그대로 찍히는 것이고, 방문자에게 파일 경로가 노출됩니다. 대신 WP_DEBUG_DISPLAY를 끈 채 WP_DEBUG_LOG를 쓰세요. 정보는 같고 노출은 없습니다.

“캐시를 비워라.” 치명적 오류는 캐시 플러그인이 무언가를 내보내기 전에 PHP 단계에서 발생합니다. 오류 페이지가 캐시되어 제공되고 있다면, 캐시 비우기는 원인을 고친 다음에 도움이 됩니다. 고치는 대신이 될 수는 없습니다.

그래도 안 될 때

로그가 wp-content 안이 아니라 코어 파일을 가리킨다면, 코어가 손상됐다기보다 앞서 로드된 플러그인이 코어가 기대하는 상태를 망가뜨렸을 가능성이 큽니다. 폴더 이름 바꾸기로 전부 끄고, 사이트가 깨끗하게 뜨는지 확인한 뒤, 플러그인을 하나씩 되살리세요. 오류가 돌아오기 직전에 켠 그 플러그인이 로그 한 줄과 함께 신고할 대상입니다.