시놀로지 NAS 워드프레스 오류 로그로 원인 찾기, debug.log 읽는 순서
시놀로지 NAS에서 워드프레스에 오류가 발생하면 검색창에 화면에 나타난 문구를 그대로 입력해 해결 방법을 찾는 경우가 많습니다.
하지만 같은 500 오류나 흰 화면이라도 실제 원인은 플러그인, 테마, PHP, MariaDB, Web Station, 리버스 프록시 또는 Docker 가운데 하나일 수 있습니다.
화면에 표시되는 오류는 결과일 뿐입니다.
실제 원인을 찾으려면 문제가 발생한 시간에 어떤 서비스가 어떤 파일에서 오류를 기록했는지 확인해야 합니다.
시놀로지 NAS에서는 워드프레스 debug.log만 확인해서는 부족할 수 있습니다. 워드프레스가 실행되기 전에 PHP나 웹 서버에서 요청이 중단되면 debug.log에 아무것도 남지 않을 수 있기 때문입니다.
따라서 워드프레스 → PHP·웹 서버 → MariaDB → 리버스 프록시 → Docker → DSM 순서로 로그 범위를 넓히는 것이 중요합니다.
로그는 오류를 고치는 답안지가 아니다
로그에는 오류 문구, 발생 시간, 파일 경로와 처리 결과가 기록됩니다.
그러나 로그에 마지막으로 표시된 파일이 항상 근본 원인은 아닙니다.
예를 들어 플러그인 A가 잘못된 데이터를 전달하고 플러그인 B에서 해당 데이터를 처리하다 오류가 발생하면 로그에는 플러그인 B의 파일이 표시될 수 있습니다.
로그를 볼 때는 다음 질문을 함께 사용해야 합니다.
- 문제가 발생한 정확한 시간은 언제인가
- 사용자가 어떤 작업을 했는가
- 첫 번째로 기록된 오류는 무엇인가
- 같은 오류가 몇 번 반복됐는가
- 플러그인·테마·PHP 중 어느 경로가 표시됐는가
- 오류 직전에 업데이트나 설정 변경이 있었는가
- 워드프레스와 NAS 로그의 시간이 일치하는가
- 오류가 발생한 뒤 나타난 후속 메시지는 무엇인가
로그 한 줄만 떼어 보는 것보다 오류 발생 전후의 흐름을 함께 읽어야 합니다.
먼저 어떤 로그를 확인할지 결정한다
증상에 따라 우선 확인할 로그가 달라집니다.
| 나타나는 증상 | 먼저 확인할 로그 |
|---|---|
| 치명적인 오류, 흰 화면 | 워드프레스 debug.log, PHP 오류 로그 |
| 500 Internal Server Error | PHP, Web Station, 웹 서버 |
| DB 연결 오류 | MariaDB, 워드프레스 설정 |
| 502 Bad Gateway | 리버스 프록시, 웹 서버, PHP |
| 504 Gateway Timeout | PHP 처리 시간, DB, 외부 연결 |
| 플러그인 설치 후 오류 | debug.log, 해당 플러그인 로그 |
| 관리자 페이지만 느림 | PHP, DB 쿼리, 외부 요청 |
| 글 저장 실패 | PHP, REST API, DB, 권한 |
| 이미지 업로드 실패 | PHP, 파일 권한, 저장공간 |
| Docker 컨테이너 재시작 | Container Manager 컨테이너 로그 |
| NAS 전체가 느림 | DSM 로그 센터, 리소스 모니터 |
| 외부에서만 접속 실패 | 리버스 프록시, 방화벽, 인증서 |
| 파일 삭제·이동 원인 확인 | DSM 로그 센터와 File Station 기록 |
1단계: 오류 발생 시간을 정확하게 기록한다
로그에서 원인을 찾으려면 먼저 오류가 발생한 시간을 알아야 합니다.
사이트를 새로고침하면서 현재 시간을 초 단위까지 기록합니다.
예를 들면 다음과 같습니다.
2026-09-14 10:32:18
관리자 글 저장 버튼 클릭 후 500 오류 발생그다음 로그에서 해당 시간 전후의 기록을 확인합니다.
시간 기록이 중요한 이유
로그 파일에는 하루 동안 수백 개 또는 수천 개의 메시지가 쌓일 수 있습니다.
오류 시간을 모르면 오래된 오류나 이미 해결된 문제를 현재 원인으로 잘못 판단할 수 있습니다.
시간대 차이도 확인한다
워드프레스, PHP, MariaDB, Docker 컨테이너와 DSM이 서로 다른 시간대를 사용하면 같은 사건이 다른 시간으로 기록될 수 있습니다.
예를 들어 DSM과 워드프레스는 한국 시간인데 Docker 컨테이너는 UTC를 사용할 수 있습니다.
로그 시간이 정확히 일치하지 않는다면 다음 항목을 확인합니다.
- DSM 시간대
- 워드프레스 시간대
- PHP 시간대
- Docker 컨테이너의
TZ - MariaDB 시간대
- 로그 파일에 표시된 UTC 여부
로그를 비교할 때 시간대 차이를 고려하지 않으면 서로 다른 사건으로 오해할 수 있습니다.
2단계: 오류를 재현하면서 로그를 확인한다
오류가 언제 발생했는지 모른다면 같은 작업을 다시 실행해 재현할 수 있는지 확인합니다.
예를 들면 다음과 같습니다.
- 오류 로그의 현재 마지막 줄을 확인합니다.
- 워드프레스에서 문제가 발생하는 작업을 실행합니다.
- 페이지를 한 번만 새로고침합니다.
- 로그 파일의 새로 추가된 부분을 확인합니다.
- 같은 오류가 다시 기록되는지 봅니다.
여러 번 새로고침하면 같은 메시지가 반복해서 쌓여 첫 번째 오류를 찾기 어려워질 수 있습니다.
로그 확인을 위해 결제, 회원 가입, 파일 삭제처럼 실제 데이터가 변경되는 작업을 반복해서 실행해서도 안 됩니다.
가능하면 복사된 테스트 환경이나 영향이 적은 조건에서 재현합니다.
3단계: 워드프레스 debug.log를 활성화한다
워드프레스에서 PHP 오류와 경고를 기록하려면 wp-config.php의 디버그 설정을 사용할 수 있습니다.
파일을 수정하기 전에는 원본 wp-config.php를 별도로 백업합니다.
다음 설정을 wp-config.php의 편집 종료 안내 문구보다 위쪽에 추가하거나 기존 값을 확인합니다.
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);각 설정의 역할은 다릅니다.
| 설정 | 역할 |
|---|---|
WP_DEBUG | 워드프레스 디버그 모드 활성화 |
WP_DEBUG_LOG | 오류를 로그 파일로 기록 |
WP_DEBUG_DISPLAY | 방문자 화면의 오류 표시 여부 |
display_errors | PHP 오류의 화면 표시 제어 |
운영 사이트에서는 오류 내용을 방문자 화면에 그대로 표시하지 않는 것이 좋습니다.
오류 메시지에는 서버 경로, 플러그인 이름, DB 관련 정보와 내부 구조가 포함될 수 있기 때문입니다.
4단계: debug.log 위치를 확인한다
기본적인 워드프레스 디버그 로그는 다음 위치에 생성됩니다.
wp-content/debug.log파일이 생성되지 않는다면 다음 항목을 확인합니다.
WP_DEBUG가true인가WP_DEBUG_LOG가true인가- 같은 설정이 아래쪽에서 다시 선언됐는가
wp-content에 쓰기 권한이 있는가- 다른 경로로 로그를 지정했는가
- 오류가 워드프레스 실행 전에 발생했는가
- PHP 자체 로그에만 기록되는 오류인가
WP_DEBUG_LOG는 WP_DEBUG가 비활성화된 상태에서는 기대한 대로 작동하지 않을 수 있습니다.
사용자 지정 로그 경로
로그를 웹 문서 루트 밖에 저장하도록 별도 경로를 지정할 수도 있습니다.
define('WP_DEBUG_LOG', '/volume1/private-logs/wordpress-errors.log');실제 경로는 NAS 환경에 맞게 정해야 하며, Web Station이 해당 위치에 로그를 쓸 수 있는 권한이 있어야 합니다.
경로가 잘못됐거나 쓰기 권한이 없으면 로그가 생성되지 않습니다.
5단계: 로그를 외부에 공개하지 않는다
wp-content/debug.log가 웹을 통해 직접 열리는 환경이라면 보안 문제가 될 수 있습니다.
로그에는 다음 정보가 포함될 수 있습니다.
- NAS 내부 파일 경로
- 플러그인과 테마 이름
- PHP 구조
- 데이터베이스 테이블 이름
- 외부 API 오류
- 이메일 주소
- 요청 주소
- 사용자 입력 일부
- 인증과 세션 관련 단서
따라서 운영 환경에서는 로그를 문서 루트 밖에 저장하거나 외부에서 접근할 수 없도록 제한해야 합니다.
로그 확인을 위해 디버그 기능을 켰다면 진단이 끝난 뒤 비활성화 상태도 다시 확인합니다.
6단계: 로그의 심각도부터 구분한다
워드프레스와 PHP 로그에는 여러 종류의 메시지가 기록됩니다.
모든 메시지가 사이트 장애를 의미하는 것은 아닙니다.
| 로그 유형 | 의미 | 우선순위 |
|---|---|---|
| Fatal error | 실행을 중단시킨 치명적 오류 | 매우 높음 |
| Parse error | PHP 문법 해석 실패 | 매우 높음 |
| Uncaught Error | 처리되지 않은 예외·오류 | 매우 높음 |
| Warning | 실행 중 경고 | 증상과 시간 비교 |
| Notice | 잘못된 사용이나 참고 사항 | 낮음 |
| Deprecated | 향후 제거될 오래된 기능 사용 | 즉시 장애는 아닐 수 있음 |
| Database error | DB 쿼리·테이블·연결 오류 | 높음 |
| Permission denied | 파일 또는 폴더 권한 거부 | 높음 |
| Timeout | 처리나 연결 시간 초과 | 높음 |
| Out of memory | 메모리 부족 | 매우 높음 |
Deprecated 메시지가 많다고 해서 현재 500 오류의 직접 원인이라고 단정할 수는 없습니다.
반대로 Fatal error, Parse error, 메모리 부족과 DB 오류는 페이지 실행을 중단시킬 수 있으므로 우선 확인해야 합니다.
7단계: 첫 번째 오류와 후속 오류를 구분한다
하나의 문제가 여러 오류를 연속으로 만들 수 있습니다.
예를 들어 MariaDB 연결이 끊어지면 다음과 같은 순서로 메시지가 나타날 수 있습니다.
- 데이터베이스 연결 실패
- 워드프레스 옵션을 읽지 못함
- 플러그인 설정값이 비어 있음
- PHP 경고 발생
- 최종적으로 500 오류 표시
이때 마지막 PHP 경고만 수정해도 데이터베이스 연결 문제는 해결되지 않습니다.
로그를 읽을 때는 오류 시점의 첫 번째 의미 있는 메시지를 찾는 것이 중요합니다.
첫 번째 원인을 찾는 방법
- 오류가 시작되기 전 정상 기록을 찾습니다.
- 바로 다음에 나타난 첫 오류를 확인합니다.
- 같은 요청에서 연속된 오류인지 봅니다.
- 마지막 오류보다 처음 실패한 서비스에 집중합니다.
- 새로고침으로 추가된 로그만 비교합니다.
8단계: 파일 경로로 원인 범위를 좁힌다
로그에 표시된 파일 경로는 어느 구성 요소에서 오류가 드러났는지 알려줍니다.
플러그인 경로
wp-content/plugins/plugin-name/해당 플러그인 또는 다른 플러그인과의 충돌을 의심할 수 있습니다.
테마 경로
wp-content/themes/theme-name/활성 테마, 자식 테마 또는 functions.php를 확인합니다.
워드프레스 코어 경로
wp-admin/
wp-includes/코어 파일에서 오류가 표시됐다고 워드프레스 자체가 원인이라고 단정하면 안 됩니다.
플러그인이나 테마가 잘못된 값을 코어 함수에 전달했을 수 있습니다.
uploads 경로
wp-content/uploads/업로드 폴더에서 PHP 파일이 실행되거나 알 수 없는 코드가 발견된다면 정상적인 미디어 파일인지 확인해야 합니다.
캐시 경로
wp-content/cache/캐시 생성 실패, 파일 권한 또는 저장공간 문제일 수 있습니다.
9단계: 자주 나타나는 PHP 오류를 해석한다
Allowed memory size exhausted
Allowed memory size of ... bytes exhaustedPHP가 허용된 메모리를 모두 사용했다는 의미입니다.
확인할 항목은 다음과 같습니다.
- 어떤 플러그인이나 테마 경로에서 발생했는가
- 특정 작업에서만 발생하는가
- 반복 쿼리나 무한 처리가 있는가
- PHP 메모리 제한
- 컨테이너 메모리 제한
- NAS 전체 메모리와 스왑
메모리 제한을 무조건 높이기 전에 어떤 작업이 메모리를 사용했는지 확인해야 합니다.
Maximum execution time exceeded
Maximum execution time of ... seconds exceededPHP 작업이 제한 시간 안에 완료되지 않았다는 의미입니다.
원인 후보는 다음과 같습니다.
- 대용량 이미지 처리
- 전체 사이트 백업
- 외부 API 응답 지연
- 느린 DB 쿼리
- 파일 검사
- 플러그인의 반복 처리
Call to undefined function
Call to undefined function필요한 PHP 확장 모듈이 없거나 플러그인·테마가 현재 환경에서 존재하지 않는 함수를 호출했을 수 있습니다.
Web Station의 PHP 프로필과 활성 확장 모듈을 확인합니다.
Permission denied
Permission denied파일이나 폴더에 필요한 접근 권한이 없는 상태입니다.
경로와 실행 주체를 확인한 뒤 필요한 범위만 권한을 조정합니다.
Failed to open stream
Failed to open stream파일 누락, 잘못된 경로, 권한 또는 외부 연결 실패일 수 있습니다.
오류 문구 뒤에 표시되는 이유를 함께 확인해야 합니다.
Headers already sent
Cannot modify header information
Headers already sent출력이 시작된 뒤 쿠키나 리디렉션 헤더를 보내려고 했을 때 나타날 수 있습니다.
로그에 표시된 output started at 뒤의 파일과 줄을 먼저 확인합니다.
Syntax error 또는 Parse error
PHP 문법이 잘못되어 파일을 해석할 수 없는 상태입니다.
최근 수정한 wp-config.php, 테마의 functions.php, 코드 스니펫과 사용자 정의 플러그인을 확인합니다.
10단계: MariaDB 관련 오류를 구분한다
워드프레스 로그에 DB 관련 메시지가 나타났다고 해서 DB가 손상됐다고 단정하면 안 됩니다.
연결 오류
다음 항목을 확인합니다.
- MariaDB 패키지 또는 컨테이너 실행 상태
- DB 이름
- DB 사용자
- 비밀번호
- DB 호스트
- 포트
- 소켓
- 사용자 권한
테이블이 없다는 오류
다음 원인을 의심할 수 있습니다.
- DB 복구가 불완전함
- 플러그인 설치가 중단됨
- 잘못된 DB에 연결됨
- 테이블 접두사가 다름
- 업데이트 중 DB 구조 변경 실패
쿼리 오류
로그에 SQL 문이 표시될 수 있습니다.
이때 SQL 문을 그대로 다시 실행하기보다 어느 플러그인이나 기능이 해당 쿼리를 만들었는지 먼저 확인합니다.
연결이 끊어졌다는 오류
NAS 자원 부족, MariaDB 재시작, 너무 긴 쿼리 또는 컨테이너 네트워크 문제를 확인합니다.
11단계: debug.log가 비어 있으면 확인 범위를 넓힌다
화면에는 500 또는 502 오류가 나타나는데 debug.log가 비어 있을 수 있습니다.
이 경우 다음 가능성을 확인합니다.
- PHP가 워드프레스까지 실행하지 못함
- Web Station에서 요청이 차단됨
- PHP 프로필이 잘못 연결됨
- 문서 루트가 잘못됨
- 파일 접근 권한이 없음
- 리버스 프록시가 백엔드에 연결하지 못함
- 컨테이너가 중지됨
- 로그 경로에 쓰기 권한이 없음
워드프레스 로그가 없다는 사실도 중요한 단서입니다.
debug.log에 기록되기 전에 요청이 실패했다면 PHP·Web Station, 프록시 또는 Docker 로그를 확인해야 합니다.
12단계: Web Station과 PHP 로그를 확인한다
Web Station 방식으로 워드프레스를 운영한다면 사이트에 연결된 웹 서비스와 PHP 프로필을 확인합니다.
확인할 항목
- Web Station 실행 상태
- 워드프레스 문서 루트
- 백엔드 웹 서버
- PHP 프로필
- PHP 버전
- 활성 확장 모듈
- 웹 서비스 상태
- 파일 권한
PHP 오류 기록에는 워드프레스가 debug.log를 만들기 전에 발생한 오류가 남을 수 있습니다.
특히 다음 상황에서는 PHP와 웹 서버 로그가 중요합니다.
- 500 오류
- PHP 파일 다운로드
- 빈 화면
- PHP 프로필 변경 후 오류
- 확장 모듈 누락
- 최대 실행 시간 초과
- 업로드 크기 초과
로그 위치와 제공 범위는 DSM, Web Station과 PHP 패키지 구성에 따라 다를 수 있습니다.
13단계: 502와 504는 프록시 로그를 함께 본다
리버스 프록시를 사용하는 경우 브라우저에는 502 또는 504만 표시되고 워드프레스 debug.log에는 아무것도 남지 않을 수 있습니다.
502 Bad Gateway
프록시가 뒤쪽 웹 서비스나 컨테이너에서 정상 응답을 받지 못한 경우를 우선 확인합니다.
- 백엔드 서비스 중지
- 잘못된 목적지 포트
- 컨테이너 재시작
- PHP 서비스 오류
- 연결 거부
- Web Station 포털 충돌
504 Gateway Timeout
프록시가 백엔드의 응답을 기다렸지만 제한 시간 안에 받지 못한 경우를 확인합니다.
- PHP 장시간 처리
- 느린 DB 쿼리
- 외부 API 지연
- 백업과 이미지 처리
- 디스크 I/O 병목
- 컨테이너 자원 부족
직접 내부 주소로 접속하면 정상인데 도메인으로 접속할 때만 오류가 발생한다면 프록시와 외부 접속 경로를 먼저 확인합니다.
14단계: Docker 컨테이너 로그를 확인한다
Container Manager로 워드프레스를 운영한다면 워드프레스, MariaDB와 리버스 프록시 컨테이너의 로그를 각각 확인해야 합니다.
워드프레스 컨테이너
- PHP 오류
- 파일 권한
- 플러그인 오류
- 웹 서버 시작 실패
- 환경변수 오류
MariaDB 컨테이너
- 인증 실패
- DB 초기화 오류
- 테이블 문제
- 저장공간 부족
- 강제 종료
- 재시작
- 데이터 볼륨 권한
리버스 프록시 컨테이너
- 백엔드 연결 거부
- 잘못된 호스트 이름
- 포트 오류
- 인증서 문제
- 시간 초과
로그에 아무것도 나타나지 않는 경우
요청이 해당 컨테이너까지 도착하지 않았거나 현재 로깅 방식이 다른 위치로 전송하고 있을 수 있습니다.
리버스 프록시와 컨테이너 네트워크부터 확인합니다.
15단계: 컨테이너 로그 크기도 확인한다
Docker의 기본 로깅 방식에서는 컨테이너 출력이 파일 형태로 계속 누적될 수 있습니다.
오류가 반복되면 로그 자체가 저장공간과 디스크 I/O를 많이 사용할 수 있습니다.
로그 폭증의 징후
- 같은 문구가 초 단위로 반복됨
- 컨테이너가 계속 재시작됨
- DB 연결이 반복 실패함
- 외부 서비스 연결 재시도가 계속됨
- NAS 저장공간이 빠르게 줄어듦
- 오류 이후 디스크 사용률이 높아짐
로그를 직접 찾아 임의로 삭제하기보다 Container Manager와 Docker의 정식 로그 관리 방식을 사용하는 것이 안전합니다.
컨테이너 로그 파일은 Docker가 관리하므로 외부 도구로 직접 수정하면 예상하지 못한 문제가 발생할 수 있습니다.
Compose 로그 회전 예시
환경에서 지원된다면 컨테이너별 로그 크기와 보관 개수를 제한할 수 있습니다.
services:
wordpress:
logging:
driver: json-file
options:
max-size: "10m"
max-file: "3"현재 컨테이너의 로깅 드라이버와 Container Manager의 지원 여부를 확인한 뒤 적용해야 합니다.
로그 제한은 저장공간 부족을 예방하는 설정이며, 반복 오류 자체를 해결하는 설정은 아닙니다.
16단계: DSM 로그 센터에서 시스템 변화를 확인한다
DSM 로그 센터에서는 NAS에서 발생한 시스템 이벤트와 서비스 기록을 검색하고 필터링할 수 있습니다.
워드프레스 오류가 발생한 시간 전후로 다음 내용이 있었는지 확인합니다.
- NAS 재부팅
- 패키지 시작과 중지
- 로그인 실패
- IP 차단
- 방화벽 변화
- 인증서 갱신
- 저장공간 경고
- 디스크 오류
- 공유 폴더 권한 변경
- 파일 삭제와 이동
- 백업 작업 실패
DSM 로그가 중요한 경우
- 워드프레스와 DSM이 동시에 느려짐
- MariaDB가 갑자기 중지됨
- 컨테이너가 재시작됨
- 파일 권한이 달라짐
- 저장공간 부족 경고 발생
- 외부 접속만 차단됨
- 패키지 업데이트 후 오류 발생
워드프레스 로그에는 NAS 재부팅이나 볼륨 오류가 직접 기록되지 않을 수 있습니다. 같은 시간의 DSM 이벤트를 대조해야 전체 원인을 찾을 수 있습니다.
17단계: 로그와 리소스 사용량을 함께 비교한다
오류 로그만으로는 자원 부족을 확정하기 어려울 수 있습니다.
다음과 같은 경우 DSM 리소스 모니터의 기록을 함께 확인합니다.
- 시간 초과 오류
- DB 연결이 간헐적으로 끊어짐
- 컨테이너가 강제 종료됨
- 사이트가 특정 시간에만 느려짐
- 백업 중 오류 발생
- 로그가 대량으로 기록됨
비교할 항목
- CPU 사용률
- 메모리
- 스왑
- 디스크 사용률
- I/O 대기
- 네트워크 송수신
- 프로세스별 자원 사용
- 컨테이너별 자원 사용
예를 들어 504 오류가 발생한 시간에 디스크 사용률이 높고 Hyper Backup이 실행 중이었다면 PHP 코드보다 디스크 지연을 우선 의심할 수 있습니다.
18단계: 로그에서 개인정보와 인증 정보를 보호한다
오류 분석을 위해 로그를 다른 사람에게 전달할 때는 민감한 정보를 제거해야 합니다.
다음 정보가 포함되지 않았는지 확인합니다.
- 관리자 이메일
- 사용자 이름
- 내부 IP와 공인 IP
- 절대 파일 경로
- 데이터베이스 이름
- DB 사용자
- API 키
- 인증 토큰
- 쿠키와 세션
- 요청 본문
- 개인이 작성한 내용
- 백업 경로
오류 한 줄만 보내기보다 민감한 정보를 가린 뒤 오류 발생 시간 전후의 관련 범위를 제공하는 것이 진단에 더 유용합니다.
원인별 로그 판단표
| 로그에서 확인한 내용 | 가능성이 높은 원인 | 다음 점검 |
|---|---|---|
Fatal error와 플러그인 경로 | 플러그인 코드·호환성 | 해당 플러그인 비활성화 |
Fatal error와 테마 경로 | 테마·자식 테마 | 기본 테마와 비교 |
Allowed memory size exhausted | PHP 메모리 또는 반복 처리 | 발생 작업과 메모리 확인 |
Maximum execution time | 장시간 작업·외부 지연 | DB·API·백업 확인 |
Permission denied | 파일·폴더 권한 | 경로와 실행 계정 확인 |
Call to undefined function | PHP 확장·버전·코드 | PHP 프로필 확인 |
| DB 테이블 없음 | 복원·업데이트 실패 | DB와 접두사 확인 |
| DB 연결 거부 | MariaDB·계정·네트워크 | DB 실행과 접속 정보 확인 |
Connection refused | 서비스 중지·포트 오류 | 백엔드와 컨테이너 상태 |
Timeout | 처리 지연·자원 부족 | 리소스 사용량 비교 |
| 같은 오류 무한 반복 | 재시도 설정·루프 | 최초 오류부터 확인 |
| debug.log에 기록 없음 | 워드프레스 이전 단계 실패 | PHP·Web Station·프록시 |
| 컨테이너 재시작 반복 | 앱 오류·OOM | 종료 원인과 메모리 확인 |
가장 효율적인 로그 진단 순서
- 오류가 발생한 정확한 시간을 기록합니다.
- 오류를 한 번만 재현합니다.
- 화면에 표시된 오류 코드와 문구를 저장합니다.
- 워드프레스
debug.log의 새로 추가된 내용을 확인합니다. - Fatal·Parse·DB·메모리 오류를 먼저 찾습니다.
- 첫 번째 오류와 뒤따른 오류를 구분합니다.
- 파일 경로로 플러그인·테마·코어를 나눕니다.
- 로그가 비어 있다면 PHP와 Web Station을 확인합니다.
- 502·504라면 리버스 프록시 로그를 확인합니다.
- Docker 환경이라면 WordPress·DB·프록시 로그를 나눠 봅니다.
- DSM 로그 센터에서 같은 시간의 시스템 이벤트를 확인합니다.
- 리소스 모니터에서 CPU·메모리·디스크를 대조합니다.
- 가장 가능성이 높은 원인을 하나만 변경해 테스트합니다.
- 같은 오류가 다시 발생하는지 확인합니다.
- 진단 후 디버그 설정과 로그 크기를 정리합니다.
로그를 볼 때 피해야 할 실수
마지막 줄만 보고 원인을 단정하지 않는다
마지막 메시지는 앞선 오류에서 파생된 결과일 수 있습니다.
오래된 오류를 현재 문제로 판단하지 않는다
파일 수정 시간과 오류 발생 시간을 반드시 비교합니다.
Warning과 Deprecated를 모두 치명적 오류로 생각하지 않는다
사이트 실행을 실제로 중단시킨 메시지를 먼저 찾아야 합니다.
오류 문구를 그대로 사이트에 표시하지 않는다
서버 구조와 파일 경로가 방문자에게 노출될 수 있습니다.
로그 파일만 삭제하고 끝내지 않는다
반복 오류를 해결하지 않으면 로그가 다시 쌓입니다.
컨테이너 로그 파일을 직접 수정하지 않는다
Docker의 로그 관리 구조가 손상될 수 있습니다.
여러 플러그인을 동시에 비활성화하지 않는다
사이트가 정상화돼도 어느 플러그인이 원인이었는지 알 수 없습니다.
진단이 끝난 뒤 디버그 모드를 방치하지 않는다
로그가 계속 증가하고 민감한 정보가 기록될 수 있습니다.
로그를 오래 쌓아두지 않는 관리 방법
디버그 기능은 필요한 기간에만 사용한다
운영 사이트에서 상시 디버깅이 필요한지 검토합니다.
로그 보존 기간과 크기를 정한다
워드프레스, Docker와 DSM 로그가 무제한 증가하지 않도록 관리 기준을 만듭니다.
로그 파일 크기를 정기적으로 확인한다
오류가 없어 보이더라도 동일한 경고가 반복되면 수GB까지 커질 수 있습니다.
알림이 필요한 오류를 구분한다
DSM 로그 센터에서 저장공간, 디스크, 로그인과 서비스 중지 같은 중요한 이벤트에 대한 알림을 설정할 수 있습니다.
시간대를 통일한다
DSM, 워드프레스, PHP와 Docker의 시간대를 맞추면 여러 로그를 비교하기 쉬워집니다.
문제 발생 전후의 변경 사항을 기록한다
플러그인 업데이트, PHP 변경과 컨테이너 재구성 시간을 기록하면 로그 원인을 찾는 시간이 줄어듭니다.
자주 묻는 질문
debug.log가 만들어지지 않는 이유는 무엇인가요?
WP_DEBUG 또는 WP_DEBUG_LOG가 비활성화됐거나 wp-content 쓰기 권한이 없을 수 있습니다. 워드프레스가 실행되기 전에 PHP나 웹 서버에서 요청이 실패한 경우에도 생성되지 않을 수 있습니다.
debug.log의 Warning을 모두 해결해야 하나요?
경고 내용에 따라 다릅니다. 현재 장애가 발생한 시간과 일치하는지 확인하고 Fatal error, DB 오류와 메모리 부족처럼 실행을 중단시키는 메시지를 먼저 확인합니다.
오류 경로에 wp-includes가 보이면 워드프레스 코어 문제인가요?
반드시 그렇지는 않습니다. 플러그인이나 테마가 잘못된 값을 코어 함수에 전달해 코어 파일에서 오류가 드러날 수 있습니다.
500 오류인데 debug.log가 비어 있으면 어디를 봐야 하나요?
PHP 오류 기록, Web Station 웹 서비스, PHP 프로필과 파일 권한을 확인합니다.
502 오류는 워드프레스 로그에서 찾을 수 있나요?
백엔드 서비스에 요청이 도달하지 않았다면 워드프레스 로그에 남지 않을 수 있습니다. 리버스 프록시와 웹 서버, 컨테이너 상태를 확인해야 합니다.
Docker 로그가 계속 커지는 이유는 무엇인가요?
컨테이너가 같은 오류를 반복하거나 로그 회전이 설정되지 않았을 수 있습니다. 로그 크기를 제한하는 것과 함께 반복되는 첫 오류를 해결해야 합니다.
로그 파일을 삭제해도 되나요?
원인 확인과 필요한 기록 보관이 끝난 뒤 정식 방법으로 정리할 수 있습니다. 실행 중인 Docker 로그 파일을 File Station에서 직접 수정하거나 삭제하는 것은 피해야 합니다.
오류 로그를 다른 사람에게 보내도 되나요?
개인정보, IP 주소, 서버 경로, DB 정보, API 키, 토큰과 쿠키를 제거한 뒤 필요한 시간 범위만 전달하는 것이 좋습니다.
문제를 해결한 뒤 WP_DEBUG를 꺼야 하나요?
운영 사이트에서는 진단이 끝난 뒤 디버그 모드와 로그 설정을 다시 점검해야 합니다. 계속 켜두면 로그 용량과 정보 노출 위험이 증가할 수 있습니다.
마무리
시놀로지 NAS 워드프레스 오류 로그를 확인할 때 가장 중요한 것은 오류 문구 자체보다 언제, 어떤 작업을 했을 때, 어느 서비스에서 처음 실패했는지 찾는 것입니다.
먼저 오류 시간을 기록하고 같은 문제를 한 번만 재현한 뒤 wp-content/debug.log에 새로 추가된 내용을 확인합니다.
Fatal error, Parse error, 데이터베이스 오류, 메모리 부족과 시간 초과 메시지를 우선 살펴보고 파일 경로를 통해 플러그인, 테마와 워드프레스 코어를 구분합니다.
워드프레스 로그가 비어 있다면 오류가 없다는 뜻이 아닙니다. 요청이 워드프레스까지 도달하지 못했을 수 있으므로 PHP, Web Station, 리버스 프록시와 Docker 로그로 확인 범위를 넓혀야 합니다.
또한 DSM 로그 센터에서 같은 시간에 NAS 재부팅, 패키지 중지, 저장공간 부족과 디스크 오류가 있었는지도 확인해야 합니다.
로그의 마지막 줄만 고치기보다 첫 번째 실패와 그 뒤에 발생한 후속 오류를 구분하면 실제 원인을 더 정확하게 찾을 수 있습니다.
IT왕세자
댓글 0
첫 댓글을 남겨보세요.