워드프레스 오류 로그 확인, 플러그인 하나씩 꺼보기 전에 이 3줄부터

사이트가 하얗게 멈췄나요? 플러그인을 하나씩 꺼보는 대신 wp-config.php에 디버그 3줄을 넣고 wp-content 폴더의 debug.log를 여는 게 가장 빠른 길이에요. 워드프레스는 치명적 오류가 나면 기본 설정상 화면에 아무것도 안 띄우고 조용히 멈추도록 되어 있어요. 그래서 화면만 봐서는 영원히 원인을 알 수 없고, 로그를 켜는 순간 문제가 난 파일 경로와 줄 번호까지 그대로 찍힙니다. 관리자 페이지에 못 들어가는 상황이어도 상관없어요. FTP나 호스팅 파일 관리자만 있으면 5분 안에 로그를 켜고 원인을 볼 수 있고, 영어 메시지가 막막하면 그 줄을 그대로 Claude Code에 붙여넣어 해석시키면 됩니다. 아래 순서대로 따라가면 추측 대신 근거로 고칠 수 있어요.

• 플러그인 끄기 전에 로그부터 여는 이유
• 관리자 페이지가 안 열릴 때, 통로부터 만들기
• wp-config.php에 넣는 3줄, 어디에 어떻게
• debug.log가 안 생길 때와 서버 error_log
• 로그 한 줄 분해해서 읽는 법
• 로그를 Claude Code에 붙여넣어 원인 찾기
• 원인 격리: 플러그인 일괄 비활성화부터 복구 모드까지
• 다 끝났으면 반드시 끄기
• 자주 묻는 질문

플러그인 하나씩 꺼보기 전에, 로그부터 여는 이유

백지 화면은 오류가 없는 상태가 아니라, 오류를 화면에 안 보여주도록 막아둔 상태예요. 운영 중인 사이트에서 방문자에게 서버 경로와 코드 내용이 노출되면 위험하니까 PHP의 display_errors가 꺼져 있는 게 정상입니다. 그래서 문제는 있는데 화면은 비어 있는, 가장 답답한 상황이 만들어져요.

이때 플러그인을 하나씩 꺼보는 방식은 최악의 선택은 아니지만 비효율적이에요. 플러그인이 20개면 최대 20번을 껐다 켜야 하고, 그 과정에서 설정이 초기화되는 플러그인도 있어요. 반면 로그는 한 번만 켜면 어느 플러그인의 어느 파일 몇 번째 줄인지를 한 줄로 알려줍니다. 순서를 바꾸는 것만으로 30분 걸릴 일이 5분으로 줄어드는 경우가 많아요.

흔한 오해 하나. 500 내부 서버 오류와 백지 화면은 겉보기가 달라도 원인은 겹칠 때가 많아요. 둘 다 PHP 치명적 오류(Fatal error), 메모리 한도 초과, .htaccess 문법 문제에서 자주 나옵니다. 그래서 증상별로 검색하기보다 로그를 먼저 확보하는 게 답으로 가는 지름길이에요.

관리자 페이지가 안 열릴 때, 파일에 닿는 통로부터 만들기

디버그 플러그인을 추천하는 글이 많지만, 정작 사이트가 멈춘 상황에서는 /wp-admin 자체가 안 열립니다. 그래서 첫 단계는 플러그인 설치가 아니라 파일에 직접 닿는 통로를 여는 거예요. 방법은 두 가지입니다.

첫째, 호스팅 제어판의 파일 관리자예요. 브라우저만 있으면 되고 별도 프로그램을 깔 필요가 없어서 초보자에게 가장 안전합니다. 대부분의 호스팅이 웹 기반 파일 관리자를 제공하고, 파일을 브라우저에서 바로 편집·다운로드할 수 있어요.

둘째, FTP/SFTP 접속이에요. FileZilla 같은 무료 프로그램에 호스팅에서 받은 주소·아이디·비밀번호·포트를 넣으면 됩니다. 접속하면 public_html, www, htdocs 중 하나의 폴더가 보이는데, 그 안에 wp-admin·wp-content·wp-includes 세 폴더와 wp-config.php가 함께 있는 곳이 워드프레스 루트예요.

수정 방식에도 함정이 있어요. 워드나 한글 같은 문서 프로그램으로 열면 자동 따옴표나 인코딩이 바뀌어 파일이 깨집니다. 메모장, VS Code, 파일 관리자 내장 편집기처럼 순수 텍스트로 저장되는 도구만 쓰세요. 저장 시 인코딩은 UTF-8(BOM 없음)이 안전합니다.

wp-config.php에 넣는 3줄, 어디에 어떻게

워드프레스의 디버그 기능은 상수 세 개로 조절해요. 각각 역할이 다르고, 운영 중인 사이트라면 세 개를 세트로 넣어야 합니다.

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

마지막 @ini_set 줄은 일부 서버에서 WP_DEBUG_DISPLAY만으로 화면 출력이 안 막히는 경우를 대비한 이중 안전장치예요. 넣어두면 손해 볼 일이 없습니다. 로그 파일 위치를 따로 지정하고 싶다면 WP_DEBUG_LOG에 true 대신 절대 경로 문자열을 넣을 수도 있어요.

debug.log가 안 생길 때 확인할 6가지와 서버 error_log

기본 위치는 wp-content/debug.log입니다. 그런데 파일이 안 보인다는 하소연이 정말 많아요. 자주 걸리는 지점은 정해져 있습니다.

1. 오류를 재현하지 않았어요. 문제 페이지를 새로고침해야 첫 줄이 찍힙니다.
2. 기존 WP_DEBUG false 줄을 지우지 않고 아래에 true를 또 넣었어요.
3. 3줄을 stop editing 주석 아래에 넣었어요.
4. wp-content 폴더에 쓰기 권한이 없어요. 권한은 보통 폴더 755, 파일 644가 기준입니다.
5. 캐시 플러그인이나 서버 캐시가 정적 파일을 대신 내보내고 있어 PHP가 아예 실행되지 않았어요.
6. wp-config.php 자체에 구문 오류가 생겼어요. 이 경우 워드프레스가 뜨기도 전에 죽어서 debug.log는 영원히 안 생깁니다.

6번이 특히 함정이에요. 세미콜론을 빠뜨렸거나 따옴표가 깨졌다면 워드프레스 로그가 아니라 서버의 PHP 에러 로그를 봐야 합니다. 이건 워드프레스와 무관하게 웹서버가 남기는 기록이라, 워드프레스가 실행되지 않는 상황에서도 원인을 알려줘요.

정리하면 순서는 이래요. debug.log가 있으면 그걸 먼저 보고, 없으면 서버 error_log를 봅니다. 둘 다 비어 있다면 PHP까지 요청이 도달하지 않은 것이니 .htaccess나 도메인·SSL 설정 쪽을 의심하는 게 맞아요.

로그 한 줄만 분해할 줄 알면 절반은 끝납니다

로그를 열면 영어가 빽빽해서 겁이 나지만, 구조는 늘 똑같아요. 실제로 자주 만나는 형태는 이렇습니다.

[10-Aug-2026 03:12:44 UTC] PHP Fatal error:  Uncaught Error:
Call to undefined function wpx_render() in
/home/example/public_html/wp-content/plugins/sample-slider/init.php:214

심각도는 네 등급으로 나뉘고, 대응 순서가 완전히 달라요. 로그가 수백 줄이어도 Fatal error만 먼저 검색하면 됩니다.

영어가 막막하면, 로그를 Claude Code에 그대로 붙여넣으세요

여기서부터가 비전공자에게 진짜 도움이 되는 구간이에요. 로그 줄을 찾았어도 그게 무슨 뜻인지, 무엇을 고쳐야 하는지는 또 다른 문제니까요. 이때 로그 원문을 AI 코딩 도구에 그대로 넘기면 해석과 다음 행동까지 한 번에 정리됩니다.

중요한 건 질문 방식이에요. 그냥 붙여넣고 고쳐달라고 하면 추측성 답이 돌아옵니다. 상황·환경·원하는 결과를 함께 주는 게 정확도를 크게 올려요.

워드프레스 사이트가 백지 화면으로 멈췄어.
호스팅은 공유호스팅, PHP 8.x, 관리자 페이지 접속 불가 상태야.
아래는 wp-content/debug.log 마지막 30줄이야.
1) 이 오류가 무슨 뜻인지 비전공자가 알아듣게 설명해줘
2) 원인 후보를 가능성 높은 순서로 3개만
3) 각 후보를 확인하는 방법을 파일 경로까지 포함해서 알려줘
4) 코드를 고쳐야 한다면 수정 전 백업 방법도 같이
---
(여기에 로그 붙여넣기)

이렇게 물으면 답이 확 달라져요. 원인 후보를 순위로 받으면 확인 순서가 정해지고, 확인 방법을 함께 받으면 무작정 코드부터 바꾸는 사고를 막을 수 있습니다. 로그 전체가 수천 줄이면 마지막 30~50줄만 넘기는 게 오히려 정확해요. 오래된 Notice가 섞이면 판단이 흐려집니다.

원인 격리: 플러그인 일괄 비활성화부터 복구 모드까지

로그가 특정 플러그인을 지목했다면 그다음은 간단해요. 하지만 로그가 코어 파일이나 wp-includes를 가리키면 실제 원인은 다른 곳일 수 있어요. 이럴 때 쓰는 게 원인 격리입니다.

관리자 페이지에 못 들어가도 플러그인을 전부 끌 수 있어요. FTP나 파일 관리자에서 wp-content/plugins 폴더 이름을 plugins-off로 바꾸면 워드프레스가 플러그인을 못 찾아 전부 비활성화됩니다. 사이트가 살아나면 원인은 플러그인 중 하나예요. 이제 폴더 이름을 plugins로 되돌린 뒤, 관리자에서 하나씩 켜면서 다시 멈추는 지점을 찾으면 됩니다.

테마도 같은 방법이 통해요. wp-content/themes에서 현재 쓰는 테마 폴더 이름을 바꾸면 워드프레스가 기본 테마로 자동 전환합니다. 단 기본 테마(Twenty 시리즈) 폴더가 남아 있어야 하니, 평소에 하나쯤은 지우지 말고 두세요.

메모리 부족이 원인일 때는 로그에 Allowed memory size … exhausted 같은 문구가 뜹니다. 이때는 wp-config.php에 define( ‘WP_MEMORY_LIMIT’, ‘256M’ ); 를 추가해보되, 공유호스팅은 서버 상한이 따로 있어 반영이 안 될 수 있어요. 그때는 호스팅에 상향 가능 여부를 문의하는 게 빠릅니다.

또 하나 놓치기 쉬운 게 복구 모드예요. 워드프레스는 치명적 오류가 나면 관리자 이메일로 복구 모드 링크를 보냅니다. 그 링크로 들어가면 문제 플러그인만 비활성화된 상태의 관리자 화면에 접근할 수 있어요. 메일이 안 왔다면 관리자 이메일 주소가 실제로 받는 주소인지, 스팸함에 들어갔는지부터 확인해보세요.

다 끝났으면 반드시 끄기, 여기까지가 한 세트

문제를 고쳤다고 끝이 아니에요. 디버그를 켜둔 채 운영하면 두 가지 문제가 생깁니다. 첫째, debug.log가 계속 커져요. Deprecated 경고가 매 요청마다 쌓이면 며칠 만에 수백 MB가 되고 디스크 용량과 속도를 잡아먹습니다. 둘째, 기본 위치의 로그 파일은 주소만 알면 브라우저로 열릴 수 있어요. 서버 경로와 코드 구조가 그대로 노출되는 셈이라 위험합니다.

그래서 마무리는 세 가지예요. WP_DEBUG를 false로 되돌리고, debug.log 파일을 삭제하고, 만약 디버그를 당분간 유지해야 한다면 웹에서 접근되지 않게 막습니다. Apache 환경이라면 wp-content 폴더에 .htaccess를 만들어 아래를 넣으면 됩니다.

<Files "debug.log">
  Require all denied
</Files>

Nginx라면 .htaccess가 동작하지 않으니 서버 설정에서 해당 파일 요청을 막아야 해요. 직접 손대기 어렵다면 로그를 다 본 즉시 삭제하는 게 가장 확실합니다. 파일을 지워도 문제가 다시 나면 워드프레스가 자동으로 새로 만들어줘요.

재발 방지도 습관의 문제예요. 플러그인·테마·코어 업데이트는 한꺼번에 몰아서 하지 말고 나눠서 하면, 문제가 생겼을 때 범인이 바로 좁혀집니다. 여유가 되면 스테이징(테스트용 복제 사이트)에서 먼저 업데이트해보는 게 가장 안전하고요. 평소 개발 중에는 Query Monitor 같은 도구로 느린 쿼리와 PHP 경고를 미리 잡아두면, 애초에 백지 화면을 만날 일이 줄어들어요.

자주 묻는 질문

debug.log 파일이 정말 안 생기는데 어떻게 하나요?

오류를 다시 재현했는지부터 확인하세요. 그다음은 기존 define(‘WP_DEBUG’, false); 줄이 아래쪽에 남아 있는지, 3줄을 stop editing 주석 위에 넣었는지, wp-content 폴더 권한이 755인지를 순서대로 봅니다. 그래도 없으면 워드프레스가 실행되기 전에 죽은 것이니 호스팅 제어판의 서버 error_log를 확인하세요.

디버그 모드를 켜둔 채로 계속 운영해도 되나요?

권장하지 않아요. 로그 파일이 무한정 커지고, 기본 위치의 로그가 외부에서 열릴 수 있습니다. 꼭 유지해야 한다면 WP_DEBUG_DISPLAY를 false로 두고, 로그 파일을 웹 공개 폴더 밖으로 옮기거나 접근을 차단한 뒤 주기적으로 비우세요.

Fatal error와 Warning은 뭐가 다른가요?

Fatal error는 실행이 그 자리에서 멈추는 오류라 백지 화면·500 오류의 직접 원인입니다. Warning은 문제가 있어도 계속 실행되는 등급이라 사이트는 뜨고 일부 기능만 어긋나요. 급한 상황이면 Fatal error만 먼저 찾으면 됩니다.

관리자 페이지에 아예 못 들어가는데 방법이 없나요?

있습니다. FTP나 호스팅 파일 관리자로 wp-content/plugins 폴더 이름을 바꾸면 모든 플러그인이 한 번에 비활성화돼요. 대개 이것만으로 관리자 화면이 열립니다. 관리자 이메일로 온 복구 모드 링크를 이용하는 방법도 함께 확인해보세요.

로그를 AI에게 보여줘도 괜찮을까요?

서버 계정명·데이터베이스 정보·API 키가 담긴 부분만 가리면 괜찮아요. 경로의 계정명을 user 같은 일반 문자열로 바꾸고, 필요한 마지막 30~50줄만 넘기는 걸 권합니다. 받은 수정안은 백업 후 적용하고, 한 번에 하나씩만 반영하세요.

참고자료

• WordPress 공식 디버깅 문서 — WP_DEBUG 계열 상수의 정확한 정의와 사용법
• WordPress 문제 해결 FAQ — 백지 화면·500 오류 등 대표 증상별 대응
• 사이트 상태(Site Health) 문서 — PHP 버전·권한 등 환경 점검 항목 안내
• PHP 공식 오류 설정 매뉴얼 — display_errors·log_errors·error_reporting 설정 기준

화면이 하얗게 멈췄을 때 가장 손해 보는 선택은 플러그인을 하나씩 꺼보며 시간을 태우는 거예요. wp-config.php에 세 줄을 넣고 wp-content/debug.log를 여는 데 걸리는 시간은 5분 남짓이고, 그 파일 한 줄에 문제가 난 폴더와 줄 번호가 다 들어 있습니다. 영어가 막막해도 괜찮아요. 계정명만 가린 뒤 로그를 Claude Code에 붙여넣고 원인 후보를 순서대로 물으면, 무엇을 확인하고 무엇을 만지지 말아야 할지가 정리됩니다. 순서를 다시 짚으면 이래요. 파일 접근 통로 확보 → 백업 → 디버그 3줄 → 오류 재현 → 로그 읽기 → 원인 격리 → 디버그 끄고 로그 삭제. 이 흐름 하나만 몸에 익혀두면 다음에 사이트가 멈춰도 당황하지 않고 근거부터 확보할 수 있어요. 오늘 안 멈췄더라도 미리 한 번 켜보고 로그가 어디에 생기는지 눈으로 확인해두는 걸 권합니다.

함께 보면 좋은 글

• 워드프레스 플러그인 설치와 오류 해결 순서
• 워드프레스 보안 설정, 설치 직후 그대로 두면 어떻게 될까?
• 워드프레스 이미지 업로드 오류, 비전공자가 직접 고친 해결법 7가지