시놀로지 NAS 워드프레스 전체 진단 순서, 느림·접속 오류 원인 찾는 방법

NAS에서 운영하던 워드프레스에 문제가 생기면 플러그인부터 삭제하거나 워드프레스를 다시 설치하는 경우가 많습니다. 그러나 NAS 워드프레스는 웹사이트 하나만 확인해서는 원인을 찾기 어렵습니다.

접속 과정에는 도메인, 공유기, 방화벽, 역방향 프록시, Web Station 또는 Docker, PHP, 워드프레스, MariaDB, NAS 저장장치가 함께 관여합니다. 이 가운데 한 부분만 문제가 생겨도 방문자에게는 사이트가 느리거나 열리지 않는 것처럼 보입니다.

따라서 NAS 워드프레스 진단의 핵심은 무작정 설정을 변경하는 것이 아니라 다음 세 가지를 확인하는 것입니다.

• 문제가 발생한 정확한 시점
• 문제가 나타나는 범위
• 정상일 때와 달라진 항목

이번 글에서는 접속 불가, 속도 저하, 관리자 페이지 지연, 글 저장 실패, 이미지 오류, 404, 로그인 반복, 저장공간 부족, 업데이트 오류, Docker 자원 충돌까지 하나의 진단 순서로 정리합니다.

NAS 워드프레스의 연결 구조부터 이해하기

브라우저에서 워드프레스 페이지를 열 때 요청은 대체로 다음 순서로 이동합니다.

방문자 브라우저 → 도메인과 DNS → 공유기와 방화벽 → 역방향 프록시 → 웹 서버 → PHP → 워드프레스 → MariaDB → NAS 저장장치

Docker로 워드프레스를 운영한다면 웹 서버 영역에 컨테이너 네트워크, 포트, 볼륨 연결 단계가 추가됩니다.

이 구조를 이해하면 증상만 보고도 확인 범위를 줄일 수 있습니다.

예를 들어 NAS 관리 화면도 느리고 파일 전송도 느리다면 워드프레스보다 NAS 자원이나 저장장치를 먼저 확인해야 합니다. 반대로 DSM과 다른 서비스는 정상인데 워드프레스 관리자 페이지만 느리다면 플러그인, 데이터베이스, 예약 작업을 우선 의심할 수 있습니다.

진단을 시작하기 전에 기록할 내용

설정을 변경하기 전에 현재 상태부터 기록해야 합니다. 기록이 없으면 여러 설정을 변경한 뒤 무엇이 문제를 해결했는지 알 수 없습니다.

문제가 시작된 시점

다음 질문에 답할 수 있도록 날짜와 시간을 적습니다.

• 정확히 언제부터 문제가 발생했는가?
• 갑자기 발생했는가, 점점 느려졌는가?
• 업데이트나 플러그인 설치 직후인가?
• NAS 재부팅이나 정전 이후인가?
• 대용량 백업이나 동기화 작업 이후인가?
• 특정 시간대에만 발생하는가?

발생 시간을 알면 DSM 로그, 웹 서버 로그, PHP 로그, 컨테이너 로그에서 같은 시간대의 기록을 찾을 수 있습니다.

최근 변경 사항

문제가 생기기 직전에 변경한 항목을 확인합니다.

• 워드프레스 코어 업데이트
• 테마 또는 플러그인 업데이트
• PHP 버전 변경
• Web Station 설정 변경
• 인증서 갱신
• 역방향 프록시 수정
• Docker 이미지 업데이트
• 컨테이너 재생성
• MariaDB 업데이트
• 방화벽 또는 공유기 설정 변경
• NAS 볼륨이나 권한 변경

원인은 현재 보이는 오류보다 직전에 수행한 변경 작업에 숨어 있는 경우가 많습니다.

1단계: 증상의 범위를 먼저 구분한다

가장 먼저 확인할 것은 무엇이 느리거나 작동하지 않는지입니다.

증상	우선 확인할 영역
DSM과 워드프레스가 모두 느림	CPU, 메모리, 디스크, 볼륨, 백업 작업
워드프레스만 느림	PHP, 플러그인, 테마, MariaDB
관리자 페이지만 느림	플러그인, 예약 작업, 외부 API, 데이터베이스
특정 페이지만 느림	페이지 빌더, 쇼트코드, 쿼리, 대용량 이미지
내부 접속은 되지만 외부 접속 불가	공유기, 방화벽, DNS, 인증서, 역방향 프록시
모든 워드프레스 페이지가 404	고유주소, 웹 서버 규칙, 문서 루트
특정 페이지만 404	슬러그, 페이지 상태, 리라이트 규칙
로그인 화면이 반복됨	쿠키, URL 설정, HTTPS 전달, 캐시
글 저장이 느리거나 실패	REST API, PHP 제한, 보안 플러그인, DB 잠금
이미지가 보이지 않음	파일 경로, 권한, URL, 볼륨 연결
데이터베이스 연결 오류	MariaDB 상태, 계정, 비밀번호, 호스트, 저장공간
재부팅하면 잠시 정상	메모리 누수, 예약 작업, 컨테이너 자원 충돌

증상의 범위를 구분하는 것만으로도 전체 점검 범위를 크게 줄일 수 있습니다.

2단계: 추가 변경을 중단하고 백업 상태를 확인한다

문제가 발생한 상태에서 업데이트, 재설치, 데이터베이스 정리, 권한 변경을 계속하면 원래 원인을 찾기 어려워집니다.

우선 다음 작업을 중단합니다.

• 플러그인과 테마의 추가 업데이트
• 워드프레스 재설치
• MariaDB 데이터베이스 삭제 또는 초기화
• Docker 컨테이너와 볼륨 삭제
• 모든 폴더에 일괄 권한 부여
• 백업 저장소 임의 정리
• 여러 PHP 설정 동시 변경

백업 파일이 존재한다는 사실만 확인해서도 안 됩니다. 백업 날짜, 포함된 데이터, 데이터베이스 덤프 여부, 복구 방법까지 확인해야 합니다.

특히 워드프레스 복구에는 일반적으로 다음 두 가지가 모두 필요합니다.

• wp-content와 업로드 파일을 포함한 워드프레스 파일
• 같은 시점의 MariaDB 데이터베이스

파일과 데이터베이스의 백업 시점이 크게 다르면 복구 후 이미지 누락, 글 불일치, 플러그인 오류가 발생할 수 있습니다.

3단계: NAS 자체 상태를 확인한다

워드프레스 설정을 보기 전에 DSM의 상태부터 확인합니다.

저장공간과 볼륨 상태

다음 항목을 확인합니다.

• 볼륨이 정상 상태인지
• 사용 가능한 공간이 충분한지
• 스토리지 풀이 저하 상태인지
• 디스크 경고나 불량 섹터가 발생했는지
• 파일 시스템 점검 알림이 있는지

볼륨이 가득 차면 단순히 파일 업로드만 실패하는 것이 아닙니다. PHP 세션, 임시파일, 로그, 데이터베이스 기록도 실패할 수 있습니다.

그 결과 글 저장 실패, 로그인 반복, 이미지 처리 오류, 데이터베이스 비정상 종료와 같은 여러 증상이 동시에 나타날 수 있습니다.

CPU와 메모리

DSM 리소스 모니터에서 다음 항목을 관찰합니다.

• CPU 사용률이 장시간 높게 유지되는지
• 메모리 사용량이 계속 증가하는지
• 스왑 사용량이 과도한지
• 특정 프로세스가 자원을 독점하는지
• Docker 컨테이너가 비정상적으로 많은 메모리를 사용하는지

CPU 사용률이 순간적으로 높아지는 것은 정상일 수 있습니다. 문제는 사용자가 거의 없는데도 높은 상태가 지속되거나 페이지 요청 때마다 사용률이 장시간 회복되지 않는 경우입니다.

디스크 사용률과 지연

CPU가 낮다고 NAS가 정상인 것은 아닙니다. 디스크 사용률이 높거나 응답 시간이 길면 PHP와 MariaDB가 파일을 기다리면서 사이트가 느려집니다.

다음 작업이 동시에 실행되는지 확인합니다.

• Hyper Backup
• 스냅샷 생성
• RAID 검사
• 미디어 색인
• Synology Drive 동기화
• 바이러스 검사
• 대용량 다운로드
• 다른 Docker 서비스의 데이터 처리

특정 시간대에만 워드프레스가 느리다면 예약 작업과 시간이 겹치는지 비교해야 합니다.

4단계: 내부 접속과 외부 접속을 비교한다

같은 워드프레스에 내부 IP와 외부 도메인으로 각각 접속해 봅니다.

테스트 결과	의심할 영역
내부와 외부 모두 접속 불가	웹 서버, 컨테이너, PHP, DB, NAS
내부는 정상이고 외부만 불가	DNS, 공유기, 방화벽, 포트, 프록시
내부는 빠르고 외부만 느림	회선, DNS, 인증서, 프록시, 업로드 대역폭
IP 접속은 되고 도메인 접속은 안 됨	DNS, 가상 호스트, 인증서
HTTP는 되고 HTTPS는 안 됨	인증서, HTTPS 포트, 프록시 전달 설정

외부 접속 문제를 워드프레스 플러그인으로 해결하려 하면 원인을 찾기 어렵습니다. 내부 접속이 정상이라면 워드프레스 파일과 데이터베이스는 최소한 요청을 처리하고 있을 가능성이 높습니다.

5단계: Web Station 또는 Docker 상태를 확인한다

NAS 워드프레스는 설치 방식에 따라 점검 항목이 달라집니다.

Web Station 방식

다음 항목을 확인합니다.

• Web Station이 실행 중인지
• 웹 서비스 포털이 올바른 문서 루트를 사용하는지
• 가상 호스트와 도메인 연결이 일치하는지
• 지정된 PHP 프로필이 존재하는지
• PHP 확장 모듈이 활성화되어 있는지
• 웹 폴더와 업로드 폴더의 권한이 유지되는지

업데이트 후 PHP 프로필이 바뀌거나 웹 서비스 포털과 PHP 버전의 연결이 해제되면 빈 화면이나 500 오류가 발생할 수 있습니다.

Docker 또는 Container Manager 방식

다음 항목을 확인합니다.

• 워드프레스 컨테이너가 실행 중인지
• MariaDB 컨테이너가 실행 중인지
• 컨테이너가 반복 재시작되는지
• 포트 연결이 변경되지 않았는지
• 환경변수가 유지되는지
• 워드프레스와 DB가 같은 네트워크에 연결됐는지
• 영구 볼륨이 기존 경로에 연결됐는지

이미지를 업데이트한 뒤 컨테이너를 새로 만들면서 기존 볼륨을 연결하지 않으면 워드프레스가 초기 설치 화면을 표시할 수 있습니다. 이때 기존 데이터가 삭제됐다고 단정하지 말고 기존 볼륨과 데이터베이스가 남아 있는지 먼저 확인해야 합니다.

6단계: 화면에 표시되는 오류를 분류한다

오류 문구와 HTTP 상태 코드는 중요한 단서입니다.

오류 또는 상태	주요 원인
403 Forbidden	권한, 방화벽, 보안 규칙
404 Not Found	고유주소, 리라이트 규칙, 문서 루트
500 Internal Server Error	PHP 오류, 플러그인, 설정 파일
502 Bad Gateway	PHP 또는 컨테이너 응답 실패
504 Gateway Timeout	PHP, DB, 외부 요청의 장시간 지연
데이터베이스 연결 오류	MariaDB 중지, 접속정보 오류, DB 손상
흰 화면	치명적인 PHP 오류, 메모리 부족
설치 화면 표시	DB 연결 대상 또는 볼륨 연결 변경
로그인 화면 반복	쿠키, URL, HTTPS, 캐시 불일치

브라우저에 표시되는 메시지만 보지 말고 개발자 도구의 네트워크 탭에서 실패한 요청의 상태 코드도 확인합니다.

7단계: 워드프레스 내부 상태를 비교한다

워드프레스에 접속할 수 있다면 사이트 건강 메뉴에서 PHP 버전, REST API, 반복 요청, 예약 작업 등의 경고를 확인합니다.

이후 페이지 유형별로 속도를 비교합니다.

• 메인 화면
• 일반 글
• 이미지가 많은 글
• 검색 결과
• 로그인 화면
• 관리자 대시보드
• 글 편집 화면
• 플러그인 목록

관리자 화면만 느리다면 방문자용 페이지 캐시 때문에 전면 페이지가 빠르게 보일 가능성이 있습니다. 이 경우 실제 문제는 플러그인 업데이트 확인, 외부 라이선스 서버 연결, wp-cron, 데이터베이스 쿼리 등에 있을 수 있습니다.

특정 페이지만 느리다면 해당 페이지에 사용된 페이지 빌더, 쇼트코드, 외부 콘텐츠, 대용량 이미지부터 비교합니다.

8단계: 플러그인과 테마를 분리해서 검사한다

플러그인 문제를 찾을 때는 여러 개를 한꺼번에 삭제하지 않습니다.

안전한 플러그인 확인 순서

1. 최근 설치하거나 업데이트한 플러그인을 확인합니다.
2. 캐시와 보안 플러그인의 설정을 기록합니다.
3. 플러그인을 하나씩 비활성화합니다.
4. 같은 페이지와 같은 기능을 다시 시험합니다.
5. 응답 시간과 오류 로그 변화를 기록합니다.

관리자 페이지에 접속할 수 없다면 워드프레스 플러그인 폴더의 이름을 임시로 변경해 전체 플러그인을 비활성화하는 방법이 있습니다. 다만 폴더를 삭제해서는 안 되며 원래 이름을 반드시 기록해야 합니다.

플러그인을 모두 비활성화해도 증상이 같다면 테마, PHP, 데이터베이스, 웹 서버 쪽으로 점검 범위를 이동합니다.

테마도 같은 방식으로 기본 테마와 비교할 수 있지만 운영 사이트에서는 백업이나 복제 환경을 확보한 뒤 진행하는 것이 안전합니다.

9단계: PHP 상태를 확인한다

PHP 문제는 500 오류, 흰 화면, 저장 실패, 이미지 처리 실패, 관리자 페이지 지연으로 나타날 수 있습니다.

확인할 PHP 항목

• 워드프레스와 호환되는 PHP 버전인지
• 메모리 제한이 지나치게 낮지 않은지
• 최대 실행 시간이 부족하지 않은지
• 업로드 파일 크기 제한이 적절한지
• 필수 PHP 확장이 활성화되어 있는지
• PHP 프로세스가 반복 종료되는지
• 임시 폴더를 사용할 수 있는지

메모리 제한을 무작정 크게 늘리는 것은 해결책이 아닙니다. 특정 플러그인이 비정상적으로 메모리를 사용한다면 제한을 높여도 잠시 뒤 같은 문제가 반복됩니다.

PHP 버전도 운영 사이트에서 바로 여러 번 변경하지 말고 현재 버전과 변경 전 버전을 기록한 뒤 한 번에 하나의 조건만 시험해야 합니다.

10단계: MariaDB와 데이터베이스를 확인한다

페이지가 열리더라도 데이터베이스 응답이 느리면 관리자 화면, 검색, 글 저장 기능이 특히 느려집니다.

데이터베이스 점검 항목

• MariaDB 서비스 또는 컨테이너가 실행 중인지
• 워드프레스의 DB 호스트가 올바른지
• 사용자 이름과 비밀번호가 일치하는지
• 데이터베이스 사용자가 필요한 권한을 가지고 있는지
• DB가 저장된 볼륨에 여유 공간이 있는지
• 테이블 오류 또는 손상 경고가 있는지
• 특정 쿼리가 장시간 실행되는지
• 옵션과 세션 데이터가 과도하게 쌓였는지

플러그인을 삭제해도 해당 플러그인의 데이터베이스 테이블이나 자동 로드 옵션은 남을 수 있습니다. 따라서 플러그인 수가 적다는 사실만으로 데이터베이스가 가볍다고 판단할 수 없습니다.

테이블 복구나 최적화는 데이터베이스 백업을 확보한 뒤 진행해야 합니다. 저장장치 오류가 의심되는 상태에서 무리하게 복구 작업을 반복하면 손상이 커질 수 있습니다.

11단계: 대표적인 증상별로 세부 진단한다

글 저장이 느리거나 실패하는 경우

다음 항목을 확인합니다.

• REST API 요청이 차단되는지
• 보안 플러그인이 저장 요청을 막는지
• PHP 메모리와 실행 시간이 부족한지
• MariaDB가 잠금 상태인지
• 자동 저장과 예약 작업이 겹치는지
• NAS의 디스크 사용률이 높은지

브라우저 개발자 도구에서 저장 요청의 상태 코드와 응답 시간을 확인하면 서버가 늦는지 요청이 차단되는지 구분할 수 있습니다.

이미지가 보이지 않는 경우

이미지 한 개만 문제인지 전체 이미지가 문제인지 먼저 나눕니다.

• 파일이 실제 업로드 폴더에 존재하는지
• 워드프레스에 등록된 URL이 현재 도메인과 일치하는지
• 파일과 폴더 권한이 올바른지
• Docker 볼륨이 기존 업로드 폴더와 연결됐는지
• HTTP 이미지가 HTTPS 페이지에서 차단되는지
• 썸네일 생성에 필요한 PHP 확장이 작동하는지

파일이 존재하지만 브라우저에서 403이 발생하면 권한이나 웹 서버 규칙을 확인합니다. 404가 발생하면 URL과 실제 경로의 불일치 가능성이 큽니다.

특정 페이지에서 404가 발생하는 경우

페이지가 공개 상태인지, 슬러그가 변경됐는지, 휴지통에 들어갔는지부터 확인합니다.

그다음 고유주소 설정을 다시 저장해 리라이트 규칙을 갱신합니다. 그래도 해결되지 않으면 역방향 프록시 경로, 웹 서버 규칙, 플러그인의 사용자 정의 글 유형을 확인합니다.

로그인 화면이 반복되는 경우

로그인 반복은 비밀번호 문제가 아닐 수도 있습니다.

• 브라우저 쿠키 삭제 후 재시험
• 다른 브라우저나 시크릿 창에서 비교
• 워드프레스 주소와 사이트 주소 비교
• HTTP와 HTTPS 혼용 여부 확인
• 역방향 프록시의 HTTPS 전달 설정 확인
• 캐시와 보안 플러그인 비활성화
• NAS 시간과 표준 시간 동기화 상태 확인

내부 IP로 로그인할 때는 정상이고 외부 HTTPS 도메인에서만 반복된다면 프록시, 쿠키, URL 설정을 우선 확인해야 합니다.

12단계: NAS 저장공간이 줄어드는 원인을 찾는다

저장공간 부족은 결과가 아니라 다른 오류를 만드는 원인이 될 수 있습니다.

대표적인 증가 원인은 다음과 같습니다.

• 워드프레스 자동 백업 파일
• 캐시와 임시파일
• 웹 서버와 PHP 로그
• Docker 컨테이너 로그
• 사용하지 않는 Docker 이미지
• 데이터베이스 로그
• Hyper Backup 버전
• 스냅샷
• 휴지통
• 썸네일과 변환 이미지
• 미디어 중복 파일

파일을 무작정 삭제하기 전에 공유 폴더별 사용량과 증가 속도를 비교해야 합니다. Docker 저장공간이 증가한다면 컨테이너 자체보다 로그, 이미지, 볼륨 중 어느 영역이 증가하는지 구분합니다.

백업 저장소는 일반 파일처럼 임의로 삭제하지 말고 해당 백업 프로그램의 보존 정책에서 정리해야 합니다.

13단계: Docker 서비스의 자원 충돌을 확인한다

여러 서비스를 Docker로 운영하면 워드프레스가 정상이어도 다른 컨테이너 때문에 느려질 수 있습니다.

확인할 자원

• 컨테이너별 CPU 사용률
• 컨테이너별 메모리 사용량
• 재시작 횟수
• 디스크 읽기와 쓰기
• 네트워크 트래픽
• 동일 포트 사용 여부
• 볼륨 경로 중복
• 데이터베이스 연결 수

AI 서비스, 미디어 서버, 다운로드 도구, 사진 인덱싱 작업은 CPU와 메모리뿐 아니라 디스크 입출력을 크게 사용할 수 있습니다.

의심되는 컨테이너를 잠시 중지했을 때 워드프레스 응답 시간이 즉시 개선되는지 비교하면 자원 충돌 여부를 판단할 수 있습니다. 운영에 필수적인 컨테이너는 영향 범위를 확인하지 않고 중지하지 않습니다.

14단계: 로그의 발생 시간을 서로 맞춰 본다

로그는 많이 읽는 것보다 증상이 발생한 시간대의 기록을 비교하는 것이 중요합니다.

우선 확인할 로그

• DSM 시스템 로그
• Web Station 또는 웹 서버 로그
• PHP 오류 로그
• 워드프레스 디버그 로그
• MariaDB 로그
• Docker 컨테이너 로그
• 역방향 프록시 로그
• 공유기 또는 방화벽 로그

오후 3시 10분에 페이지 저장이 실패했다면 모든 로그에서 그 전후 몇 분을 확인합니다.

예를 들어 같은 시간에 다음 기록이 함께 나타난다면 원인을 좁힐 수 있습니다.

• PHP 메모리 부족
• MariaDB 연결 시간 초과
• 컨테이너 강제 종료
• 볼륨 공간 부족
• 디스크 입출력 오류
• 프록시 업스트림 응답 시간 초과

워드프레스 디버그 기능은 원인을 찾는 동안만 사용하고, 방문자 화면에 오류가 직접 표시되지 않도록 구성해야 합니다. 진단이 끝나면 과도한 디버그 기록도 중지합니다.

15단계: 한 번에 하나의 조건만 변경한다

정확한 진단을 위해서는 변경과 검증을 한 쌍으로 진행해야 합니다.

1. 의심 원인 하나를 선택합니다.
2. 현재 설정을 기록합니다.
3. 한 가지 설정만 변경합니다.
4. 동일한 조건으로 다시 시험합니다.
5. 증상과 로그 변화를 기록합니다.
6. 변화가 없으면 원래 설정으로 복구합니다.
7. 다음 후보를 검사합니다.

플러그인 비활성화, PHP 버전 변경, 캐시 삭제, 컨테이너 재시작을 동시에 수행하면 사이트가 정상화돼도 실제 원인을 알 수 없습니다. 원인을 모르면 다음 업데이트 때 같은 문제가 반복됩니다.

15분 안에 진행하는 빠른 진단 순서

장애가 발생했을 때는 다음 순서로 빠르게 상태를 확인할 수 있습니다.

1분에서 3분

• 내부 IP와 외부 도메인 접속 비교
• DSM 접속과 다른 NAS 서비스 상태 확인
• 화면의 오류 문구와 상태 코드 기록

4분에서 6분

• DSM 리소스 모니터에서 CPU, 메모리, 디스크 확인
• 볼륨 여유 공간과 스토리지 상태 확인
• 백업, 동기화, 검사 작업 실행 여부 확인

7분에서 9분

• Web Station 또는 컨테이너 실행 상태 확인
• PHP와 MariaDB 서비스 확인
• 컨테이너 재시작 여부와 로그 확인

10분에서 12분

• 최근 업데이트와 설치 기록 확인
• 문제가 전체 사이트인지 특정 기능인지 구분
• 관리자 화면과 방문자 화면 속도 비교

13분에서 15분

• 같은 시간대의 PHP, 웹 서버, DB 로그 비교
• 가장 가능성이 높은 원인 하나만 시험
• 해결되지 않으면 원상복구 후 다음 후보 확인

증상별 최종 진단표

증상	첫 번째 확인	두 번째 확인	결정 기준
사이트 전체가 느림	NAS 자원	PHP·DB	DSM도 느리면 NAS부터 조치
관리자만 느림	플러그인	예약 작업·DB	플러그인 중단 후 개선 여부
외부에서만 접속 불가	DNS·공유기	프록시·인증서	내부 접속 결과와 비교
500 오류	PHP 로그	플러그인·테마	치명적 오류가 발생한 파일 확인
502·504 오류	PHP·컨테이너	DB·디스크	업스트림 중 어느 서비스가 지연되는지 확인
DB 연결 오류	MariaDB 상태	DB 설정·볼륨	DB 접속 자체가 가능한지 확인
이미지 오류	실제 파일	URL·권한·볼륨	상태 코드가 403인지 404인지 확인
로그인 반복	쿠키·URL	HTTPS 프록시	내부와 외부 로그인 비교
글 저장 실패	REST API	PHP·DB	저장 요청의 상태 코드 확인
재부팅 후 잠시 정상	메모리	예약 작업·로그	시간이 지나며 자원이 다시 증가하는지 확인
용량이 계속 감소	폴더별 사용량	백업·로그·Docker	일정 시간 간격으로 증가량 비교
업데이트 후 오류	변경된 구성요소	PHP 호환성	이전 버전에서 정상인지 비교

복구를 선택해야 하는 시점

모든 오류를 현재 환경에서 직접 수정해야 하는 것은 아닙니다. 다음 조건에 해당하면 검증된 백업으로 복구하는 편이 안전할 수 있습니다.

• 업데이트 직전 백업이 정상적으로 존재하는 경우
• 여러 플러그인과 PHP 설정이 동시에 변경된 경우
• 운영 중단 시간이 길어지고 있는 경우
• 테스트 환경에서는 백업 복구가 정상적으로 완료된 경우
• 변경 사항을 하나씩 되돌리는 시간이 복구 시간보다 긴 경우

그러나 백업 파일이 있다는 이유만으로 운영 환경에 즉시 덮어쓰면 안 됩니다. 가능하다면 별도의 폴더, 임시 도메인, 복제 컨테이너에서 먼저 복구합니다.

복구 후에는 다음 항목을 확인합니다.

• 메인 페이지와 글 페이지
• 관리자 로그인
• 최근 글과 댓글
• 이미지와 첨부파일
• 고유주소
• 플러그인 기능
• 데이터베이스 문자와 한글 표시
• HTTPS와 외부 접속
• 예약 작업과 백업 기능

직접 작업을 중단해야 하는 상황

다음 상황에서는 플러그인이나 워드프레스 설정을 계속 변경하지 않는 것이 좋습니다.

• 스토리지 풀이 저하 또는 충돌 상태인 경우
• 디스크 입출력 오류가 반복되는 경우
• MariaDB 테이블 손상이 확인된 경우
• 사용할 수 있는 검증된 백업이 없는 경우
• 컨테이너의 영구 볼륨 위치를 알 수 없는 경우
• 파일 소유권과 권한 구조를 확인하기 어려운 경우
• 메모리 부족으로 서비스가 반복 종료되는 경우
• 복구 작업이 기존 백업까지 덮어쓸 가능성이 있는 경우

이때는 현재 볼륨과 데이터베이스를 보존하고 추가 쓰기 작업을 최소화해야 합니다.

NAS 워드프레스 진단에서 자주 하는 실수

오류가 발생하자마자 재설치한다

재설치는 설정 오류나 저장장치 문제를 해결하지 못할 수 있습니다. 오히려 기존 파일과 데이터베이스의 연결 관계를 더 복잡하게 만듭니다.

권한을 무조건 넓게 설정한다

모든 파일과 폴더에 광범위한 쓰기 권한을 부여하면 일시적으로 문제가 해결된 것처럼 보일 수 있지만 보안 위험이 커집니다. 필요한 사용자와 서비스에 필요한 범위만 부여해야 합니다.

캐시를 삭제하고 해결됐다고 판단한다

캐시 삭제 후 잠시 빨라졌다면 원인이 사라진 것이 아니라 캐시가 다시 쌓일 때까지 증상이 감춰진 것일 수 있습니다. 캐시 크기와 생성 속도도 함께 확인해야 합니다.

재부팅만 반복한다

재부팅 후 정상화되는 것은 중요한 진단 단서입니다. 메모리 누수, 프로세스 누적, 예약 작업, 컨테이너 충돌 가능성을 조사해야 합니다.

로그 전체를 처음부터 읽는다

로그는 발생 시간을 기준으로 좁혀야 합니다. 관련 없는 수천 줄을 읽는 것보다 오류가 재현된 시각의 전후 기록을 비교하는 편이 정확합니다.

자주 묻는 질문

NAS 워드프레스가 느리면 플러그인부터 꺼야 하나요?

DSM과 다른 NAS 서비스가 정상인지 먼저 확인해야 합니다. NAS 전체가 느리다면 플러그인을 꺼도 근본적인 문제가 해결되지 않습니다. 워드프레스만 느린 것이 확인된 뒤 최근 변경한 플러그인부터 하나씩 검사하는 것이 좋습니다.

CPU 사용률이 낮은데 사이트가 느릴 수 있나요?

가능합니다. 디스크 입출력 지연, 스왑 사용, 데이터베이스 잠금, 외부 API 응답 지연 때문에 CPU 사용률이 낮아도 페이지가 느릴 수 있습니다.

로그에 오류가 없으면 서버 문제는 아닌가요?

그렇지 않습니다. 필요한 로그가 활성화되지 않았거나 다른 계층에서 오류가 발생했을 수 있습니다. 웹 서버, PHP, 워드프레스, MariaDB, Docker 로그를 함께 비교해야 합니다.

Docker 컨테이너를 다시 만들면 데이터가 삭제되나요?

데이터가 영구 볼륨에 저장되어 있고 새 컨테이너에 같은 볼륨을 정확히 연결하면 유지될 수 있습니다. 그러나 볼륨 연결을 확인하지 않고 컨테이너나 볼륨을 삭제하면 데이터 손실이 발생할 수 있습니다.

백업이 있으면 바로 복구해도 되나요?

먼저 백업에 워드프레스 파일과 데이터베이스가 모두 포함됐는지 확인해야 합니다. 가능하다면 별도의 환경에 시험 복구한 뒤 운영 사이트에 적용하는 것이 안전합니다.

원인을 찾았는데도 시간이 지나면 다시 느려집니다

예약 작업, 로그 증가, 캐시 누적, 컨테이너 메모리 증가처럼 시간에 따라 다시 발생하는 문제일 수 있습니다. 재부팅 직후와 몇 시간 후의 자원 사용량을 비교해야 합니다.

마무리

NAS 워드프레스 문제는 특정 플러그인 하나만의 문제라고 단정하기 어렵습니다. 네트워크, 웹 서버, PHP, 워드프레스, 데이터베이스, Docker, 저장장치가 서로 연결되어 있기 때문입니다.

가장 효율적인 진단 순서는 다음과 같습니다.

1. 발생 시점과 최근 변경 사항을 기록합니다.
2. 전체 장애인지 특정 기능의 문제인지 구분합니다.
3. NAS의 볼륨과 자원 상태를 확인합니다.
4. 내부 접속과 외부 접속을 비교합니다.
5. Web Station 또는 Docker 상태를 확인합니다.
6. PHP와 MariaDB를 점검합니다.
7. 플러그인과 테마를 하나씩 분리합니다.
8. 같은 시간대의 로그를 비교합니다.
9. 한 번에 하나의 조건만 변경합니다.
10. 위험 신호가 있다면 작업을 중단하고 백업과 복구 가능성을 먼저 확인합니다.

이 순서를 따르면 문제가 NAS에 있는지, 워드프레스에 있는지, 네트워크나 Docker에 있는지를 단계적으로 좁힐 수 있습니다. 중요한 것은 많은 설정을 빠르게 바꾸는 것이 아니라 관찰하고, 측정하고, 비교한 뒤 하나씩 제외하는 것입니다.