워드프레스 디버그 로그 위치: debug.log는 어디 있고 어떻게 옮기나
wp-content에서 debug.log를 찾고, 방문자가 내려받지 못하도록 웹 루트 밖으로 옮기고, 파일이 비어 있게 만드는 WP_DEBUG 설정을 바로잡는 방법.
게시됨
WordPress는 기본적으로 디버그 로그를 wp-content/debug.log에 씁니다. 디스크상 절대 경로로는 /path/to/your/site/wp-content/debug.log입니다. 이 파일은 무언가 실제로 기록되기 전에는 존재하지 않으며, wp-config.php에서 WP_DEBUG가 true이고 WP_DEBUG_LOG가 켜져 있을 때만 기록됩니다. 그리고 이 기본 위치는 실제로 보안 문제입니다. 대부분의 호스팅에서 누구든 브라우저로 그 파일을 가져갈 수 있기 때문입니다.
상수 세 개와 각각의 역할
셋 다 wp-config.php의 /* That's all, stop editing! Happy blogging. */ 줄 위에 넣어야 합니다. 그 줄 아래에 추가한 것은 WordPress가 이미 구동을 마친 뒤에 실행되므로 무시됩니다.
| 상수 | 기본값 | 하는 일 |
|---|---|---|
WP_DEBUG | false | 주 스위치. PHP 오류 보고 수준을 높여 알림, 경고, 지원 중단 안내를 표시합니다. 이것 없이는 아래 어느 것도 동작하지 않습니다. |
WP_DEBUG_LOG | false | 오류를 파일로 보냅니다. true면 wp-content/debug.log. 문자열을 주면 기록할 파일 경로로 취급됩니다. |
WP_DEBUG_DISPLAY | true | 오류를 페이지 HTML에 찍어 모든 방문자에게 보이게 합니다. |
사람들이 틀리는 부분은 이 의존 관계입니다. WP_DEBUG_LOG는 WordPress 구동 코드의 WP_DEBUG 분기 안에서 읽힙니다. WP_DEBUG가 false면 WP_DEBUG_LOG를 true로 둬도 아무 일도 일어나지 않습니다. 파일도, 오류도, 경고도 없습니다. WP_DEBUG_LOG를 넣었는데 로그가 생기지 않았다면 WP_DEBUG부터 확인하세요.
운영 사이트에서 잘 동작하는 설정은 이렇습니다.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );WP_DEBUG가 파일 위쪽에 이미 정의되어 있다면(대개 false로 있습니다), define()을 하나 더 추가하지 말고 그 줄을 고치세요. 같은 상수를 두 번 정의하면 PHP 경고가 나고, 표시가 켜진 사이트에서는 그 경고가 페이지 맨 위에 그대로 박힙니다.
운영 환경에서 WP_DEBUG_DISPLAY를 false로 둬야 하는 이유
표시가 켜져 있으면 PHP 오류가 HTML 응답에 그대로 출력됩니다. 테마에서 나온 지원 중단 알림 하나가 서버의 절대 파일 경로를 모든 방문자에게 찍어 줍니다. 데이터베이스 오류는 테이블 이름과 쿼리 조각을 찍습니다. 더 나쁜 건, 헤더 전송 전에 출력이 나가면 리다이렉트가 깨지고, 깨끗한 JSON을 기대하는 REST와 AJAX 응답이 깨지며, 사람들이 플러그인 탓으로 돌리는 그 흰 화면이 만들어질 수 있다는 점입니다.
알아 둘 만한 미묘한 점 하나. WP_DEBUG_DISPLAY를 null로 두는 것은 false와 다릅니다. null은 PHP의 display_errors 설정을 건드리지 말고 서버 설정을 그대로 따르라는 뜻입니다. false는 능동적으로 끕니다. 운영 사이트에서는 false를 쓰고, 위의 ini_set 줄을 이중 안전장치로 함께 넣으세요. 플러그인이 요청 처리 중간에 display_errors를 다시 켤 수도 있기 때문입니다.
기본 위치는 외부에서 그냥 받아 갈 수 있다
wp-content/debug.log는 웹 루트 안에 있습니다. 기본 WordPress 설치에는 이 파일에 대한 직접 요청을 막는 장치가 없습니다. 일반적인 Apache나 nginx 구성에서 https://yoursite.com/wp-content/debug.log는 파일을 평문으로 돌려줍니다. 디버그 로그에는 서버 절대 경로, 플러그인과 테마의 내부 구조, 실제 쿼리문이 담긴 데이터베이스 오류, 때로는 실패한 함수에 넘어간 값까지 들어 있습니다. URL을 찍어 보는 누구에게나 공짜 정찰 자료이고, 자동화 스캐너가 가장 먼저 시도하는 URL 중 하나입니다.
대응 방법은 두 가지인데, 더 나은 쪽은 로그를 옮기는 것입니다.
경로를 지정해 로그 옮기기
WordPress 5.1부터 WP_DEBUG_LOG는 불리언 대신 문자열 파일 경로를 받습니다. 문서 루트 바깥 어딘가를 가리키게 하세요.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/youruser/logs/wp-errors.log' );
define( 'WP_DEBUG_DISPLAY', false );이 경로에는 규칙이 셋 있습니다. 절대 경로를 쓰세요. 상대 경로는 PHP의 작업 디렉터리를 기준으로 해석되는데, 그 값은 요청마다 서버마다 달라서 파일이 어디로 갔는지 놓치게 됩니다. 디렉터리는 이미 존재해야 합니다. PHP는 디렉터리를 만들어 주지 않고, 파일을 열지 못하면 조용히 실패합니다. 그리고 그 디렉터리는 PHP 사용자가 쓸 수 있어야 하는데, 공용 호스팅에서는 SFTP로 로그인하는 계정과 같지 않습니다.
호스팅이 웹 루트 안으로 활동을 제한해 그 위에 쓸 곳이 없다면, 기본 경로를 유지하고 서버 단에서 접근을 막으세요. Apache라면,
<Files "debug.log">
Require all denied
</Files>이건 루트가 아니라 wp-content 안의 .htaccess 파일에 넣어야 합니다. 고유주소를 저장할 때 WordPress가 루트 .htaccess를 다시 쓰면서 추가한 내용을 날려 버릴 수 있기 때문입니다. nginx에서는 .htaccess가 아예 동작하지 않으니 서버 설정에 location 블록이 필요하고, 관리형 호스팅이라면 대개 지원팀에 요청해야 합니다.
차단으로 얻는 것에 대해서는 솔직해집시다. 파일은 여전히 웹 서버가 서비스하는 디렉터리 안 디스크에 있습니다. 어느 플러그인의 경로 탐색 취약점 하나면 여전히 읽힐 수 있습니다. 웹 루트 밖으로 옮기는 쪽이 더 강한 해법입니다.
파일 읽기와 실시간 추적
SSH를 쓸 수 있다면 버그를 재현하면서 실시간으로 지켜보세요.
tail -f wp-content/debug.log다른 탭에서 오류를 재현하면 새 줄이 기록되는 대로 나타납니다. 최근에 일어난 것만 보거나 특정 플러그인만 걸러 보려면,
tail -n 100 wp-content/debug.log
grep -i 'plugin-slug' wp-content/debug.log | tail -n 50PHP는 파일 끝에 덧붙이므로 아래에서 위로 읽으세요. 각 항목의 시각은 UTC 기준이라 WordPress 시간대 설정과 맞지 않습니다. 그것 때문에 옛날 항목을 보고 있다고 착각하지 마세요.
WP-CLI를 쓰면 파일을 직접 손대지 않고 상수를 켜고 끌 수 있습니다.
wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw--raw 플래그가 중요합니다. 없으면 불리언이 아니라 "true"라는 문자열로 기록됩니다. 경로 형태로 넣을 때는 따옴표 붙은 문자열로 기록되도록 --raw를 빼세요.
SSH가 없다면 SFTP로 파일을 내려받거나 호스팅 파일 관리자에서 여세요. 로그를 wp-admin 안에서 보여 주는 플러그인은 완전히 신뢰하는 게 아니라면 피하는 편이 낫습니다. 서버 내부 정보로 가득한 파일에 대한 읽기 권한을 플러그인에 넘기는 일이니까요.
내 환경에 맞는 wp-config 블록을, 안전한 웹 루트 밖 경로와 거기에 맞는 서버 규칙까지 통째로 받고 싶다면 WordPress 디버그 로그 생성기가 만들어 줍니다.
다 썼으면 끄기
WordPress 코어는 debug.log를 회전시키거나 비워 주지 않습니다. 페이지를 열 때마다 알림이 뜨는 사이트라면 파일은 한없이 커져 디스크를 채우고, 애초에 쫓던 버그보다 더 심하게 사이트를 내려앉힙니다. 로깅을 켜고, 문제를 재현하고, 로그를 읽고, WP_DEBUG를 다시 false로 되돌리세요.
파일을 지우지 않고 비우려면,
: > wp-content/debug.log로그가 계속 비어 있을 때
다음을 순서대로 짚으세요. WP_DEBUG가 false인 경우 — 단연 가장 흔한 원인이고, 나머지 전부를 조용히 무력화합니다. 상수가 wp-config.php의 “편집 중단” 줄 아래에 있는 경우. 파일 권한 — PHP가 wp-content나 지정한 사용자 디렉터리에 쓰지 못하는 경우. wp-config 로딩이 끝나기 전에 난 치명적 오류 — 설정 파일 자체의 문법 오류 같은 것은 너무 이른 시점이라 WordPress 로깅이 잡지 못하며, 서버의 자체 PHP 오류 로그로 갑니다. 호스팅이 덮어쓰는 경우 — 일부 관리형 플랫폼은 PHP의 error_log 설정을 고정해 두거나 로그를 자체 대시보드로 보냅니다. 이 경우 상수는 제대로 설정된 것이고 출력이 다른 곳에 있을 뿐입니다. 설정이 잘못됐다고 단정하기 전에 호스팅의 로그 뷰어를 확인하세요.
FAQ
질문
워드프레스 디버그 로그는 어디에 있나요?
기본값은 wp-content 폴더 바로 안의 wp-content/debug.log입니다. WordPress는 오류가 실제로 기록될 때만 파일을 만들기 때문에, wp-content에 파일이 없다고 해서 로깅이 고장 난 것은 아닙니다. WP_DEBUG_LOG에 true 대신 파일 경로를 지정했다면 로그는 그 경로에 쓰입니다.
wp-content에 debug.log 파일이 없는 이유는 뭔가요?
흔한 이유가 셋입니다. WP_DEBUG가 false여서 WP_DEBUG_LOG와 무관하게 로깅이 아예 켜지지 않은 경우. 아직 아무 오류도 나지 않아 파일이 만들어지지 않은 경우. 또는 파일 권한 때문에 PHP가 wp-content에 쓰지 못하는 경우입니다. 상수를 먼저 확인하고 그다음 권한을 보세요.
제 워드프레스 debug.log를 아무나 내려받을 수 있나요?
대개 그렇습니다. wp-content/debug.log는 웹 루트 안에 있고 이를 막는 접근 규칙이 없어서, 해당 URL로 요청하면 파일이 그대로 반환되는 경우가 많습니다. 디버그 로그에는 서버 절대 경로, 데이터베이스 오류, 쿼리 조각이 예사로 담깁니다. 로그를 웹 루트 밖으로 옮기거나 서버 설정에서 차단하세요.
WP_DEBUG_LOG와 WP_DEBUG_DISPLAY는 어떻게 다른가요?
WP_DEBUG_LOG는 오류를 파일에 기록합니다. WP_DEBUG_DISPLAY는 오류를 페이지 HTML에 찍어 방문자가 읽을 수 있게 만듭니다. 운영 중인 사이트라면 기록은 켜고 표시는 꺼야 합니다. 두 상수 모두 WP_DEBUG가 true가 아니면 완전히 무시되는데, 이 단계를 놓치는 사람이 가장 많습니다.
워드프레스 디버그 로그는 어떻게 읽나요?
SSH를 쓸 수 있다면 로그 경로에 tail -f를 걸어 두고 문제를 재현하면서 새 항목이 쌓이는 것을 실시간으로 보세요. SSH가 없다면 SFTP로 파일을 내려받거나 호스팅 파일 관리자에서 열면 됩니다. PHP는 새 항목을 파일 끝에 덧붙이므로 아래에서 위로 읽으세요.
WP_DEBUG를 켜면 운영 사이트가 느려지나요?
약간 느려지지만, 더 큰 위험은 디스크입니다. 트래픽 많은 사이트에서 로그가 장황해지면 debug.log가 기가바이트 단위로 불어나 디스크를 채우고 사이트를 내려앉힙니다. 켜고, 버그를 재현하고, 로그를 읽고, 다시 끄세요. WordPress 코어는 그 파일을 대신 회전시키거나 비워 주지 않습니다.