시놀로지 NAS 워드프레스 플러그인 설치 후 느려지는 이유

워드프레스에 플러그인 하나를 설치한 뒤 관리자 페이지가 늦게 열리거나 시놀로지 NAS 전체가 느려지는 경우가 있습니다.

처음에는 플러그인 설치가 원인이라고 생각하기 쉽지만, 실제로는 플러그인이 CPU를 계속 사용하는지, PHP 처리가 길어진 것인지, MariaDB 쿼리가 증가했는지, 디스크 입출력이 몰렸는지를 구분해야 합니다.

백업이나 이미지 최적화 플러그인처럼 설치 직후 대량 작업을 실행하는 경우도 있고, 보안 플러그인처럼 방문할 때마다 데이터베이스에 접속 기록을 남기는 경우도 있습니다. 외부 서버의 응답을 기다리느라 페이지가 느려질 수도 있습니다.

따라서 플러그인을 무작정 삭제하기 전에 어떤 자원이 언제 높아지는지 확인하는 것이 먼저입니다.

플러그인은 워드프레스 기능만 추가하는 것이 아니다

워드프레스 플러그인은 설치된 파일만 차지하는 단순한 확장 프로그램이 아닙니다.

활성화된 플러그인은 페이지가 열릴 때 PHP 코드를 실행하거나 데이터베이스에서 정보를 읽고 쓸 수 있습니다. 예약 작업을 등록하거나 외부 서버와 통신하기도 합니다.

플러그인에 따라 다음과 같은 작업이 추가됩니다.

• 페이지마다 PHP 코드 실행
• MariaDB 데이터 조회 및 기록
• CSS와 JavaScript 파일 추가
• 이미지 변환과 썸네일 생성
• 파일 및 데이터베이스 백업
• 방문자와 로그인 기록 저장
• 보안 검사를 위한 파일 검색
• 외부 API와 라이선스 서버 접속
• WP-Cron 예약 작업 실행
• 캐시 파일 생성과 삭제
• 이메일 및 알림 전송
• 통계 데이터 수집

성능 문제는 설치된 플러그인의 개수보다 각 플러그인이 어떤 작업을 얼마나 자주 실행하는지가 더 중요합니다.

플러그인이 30개여도 단순 기능 위주라면 큰 문제가 없을 수 있지만, 백업·보안·통계·이미지 최적화 플러그인 몇 개가 동시에 작동하면 NAS 부하가 크게 증가할 수 있습니다.

먼저 워드프레스만 느린지 NAS 전체가 느린지 구분한다

플러그인을 설치한 뒤 느려졌다는 느낌만으로는 원인을 정확히 판단하기 어렵습니다.

다음 세 가지 상황을 구분해야 합니다.

느려진 범위	우선 확인할 원인
워드프레스 화면만 느림	PHP, DB 쿼리, 외부 통신, 플러그인 충돌
DSM과 파일 전송도 함께 느림	CPU, 메모리, 디스크 I/O, 백그라운드 작업
관리자 페이지에서만 느림	관리 화면용 플러그인 기능, 업데이트 확인, 통계
방문자 페이지에서만 느림	캐시, 프런트엔드 스크립트, DB 조회
특정 시간에만 느림	예약 백업, 검사, WP-Cron
플러그인 설정 화면만 느림	외부 서버 연결, 라이선스 확인, 대량 데이터 조회

워드프레스 페이지는 느리지만 DSM과 파일 전송은 정상이라면 NAS 하드웨어 전체의 성능 문제라기보다 워드프레스 처리 과정에서 지연될 가능성이 높습니다.

반대로 DSM 로그인, 파일 복사, 다른 패키지까지 동시에 느려진다면 플러그인이 실행한 백그라운드 작업이 NAS 자원을 점유하는지 확인해야 합니다.

플러그인 설치 전후를 비교해야 한다

원인을 찾으려면 플러그인을 설치하기 전 상태와 설치한 후 상태를 비교해야 합니다.

다음 항목을 기록하면 도움이 됩니다.

• 플러그인 설치 날짜와 시간
• 활성화 직후 실행한 초기 설정
• 느려지기 시작한 시점
• 워드프레스 첫 화면 응답 시간
• 관리자 페이지가 열리는 시간
• DSM CPU 사용률
• 메모리와 스왑 사용 상태
• 디스크 사용률과 I/O 대기
• MariaDB와 PHP 프로세스 사용량
• 저장공간 증가 여부

설치 직후에만 느렸다가 시간이 지나면서 정상화된다면 이미지 재생성, 파일 검사, 초기 캐시 생성처럼 일회성 작업이었을 가능성이 있습니다.

반대로 몇 시간이나 며칠이 지나도 계속 느리다면 반복 작업, 플러그인 충돌 또는 데이터베이스 문제가 있을 수 있습니다.

1단계: DSM 리소스 모니터에서 병목을 찾는다

시놀로지 DSM의 리소스 모니터에서는 CPU, 메모리, 디스크, 볼륨, 네트워크 사용 상태를 확인할 수 있습니다.

워드프레스 관리자 페이지를 열거나 문제가 되는 기능을 실행하면서 그래프가 어떻게 변하는지 봅니다.

CPU 사용률이 높을 때

페이지를 열 때마다 CPU 사용률이 급격히 높아진다면 PHP 연산이나 플러그인의 데이터 처리 작업을 의심할 수 있습니다.

다음과 같은 플러그인이 CPU를 많이 사용할 수 있습니다.

• 이미지 압축 및 WebP 변환
• 악성코드와 파일 무결성 검사
• 전체 사이트 백업
• 깨진 링크 검사
• 검색 색인 생성
• 통계 보고서 생성
• 대량 게시물 처리
• 썸네일 재생성

리소스 모니터의 작업 관리자에서 PHP, 웹 서버, MariaDB와 관련된 서비스의 CPU 사용량을 확인합니다.

CPU 사용률이 올라가는 순간과 플러그인 작업 시간이 일치한다면 원인을 좁힐 수 있습니다.

메모리 사용량이 높을 때

메모리가 부족하면 DSM은 저장장치 일부를 스왑 공간으로 사용할 수 있습니다. 이 상태에서는 CPU 사용률이 높지 않아도 워드프레스와 NAS 전체가 느려질 수 있습니다.

다음 항목을 확인합니다.

• 실제 메모리 사용량
• 스왑 사용량
• PHP 프로세스 수
• MariaDB 메모리 사용량
• Container Manager 실행 여부
• 다른 NAS 패키지의 메모리 점유

DSM에서 메모리 사용률이 높게 표시되는 것만으로 부족하다고 단정할 수는 없습니다. 운영체제가 남는 메모리를 캐시로 활용할 수 있기 때문입니다.

실제 판단 기준은 스왑 사용이 지속적으로 발생하는지, 페이지 요청 시 디스크 I/O가 함께 증가하는지입니다.

디스크 사용률과 I/O 대기가 높을 때

CPU가 높지 않은데 NAS 반응이 느리다면 디스크 입출력 병목일 수 있습니다.

백업, 보안 검사, 캐시 생성, 이미지 변환 플러그인은 수많은 파일을 읽고 쓰기 때문에 HDD 기반 NAS에서 체감 속도를 크게 떨어뜨릴 수 있습니다.

특히 다음 작업이 동시에 실행되면 영향을 크게 받을 수 있습니다.

• 워드프레스 전체 백업
• Hyper Backup
• RAID 검사 또는 복구
• S.M.A.R.T. 확장 테스트
• Synology Drive 색인
• 미디어 색인
• Snapshot Replication
• Docker 데이터베이스 작업

이 경우 플러그인만의 문제가 아니라 NAS의 다른 예약 작업과 실행 시간이 겹친 것이 원인일 수 있습니다.

2단계: 플러그인 활성화 전후 속도를 비교한다

가장 직접적인 진단 방법은 의심되는 플러그인을 비활성화한 상태와 활성화한 상태를 비교하는 것입니다.

단, 방문자가 사용하는 운영 사이트에서 바로 테스트하면 기능 중단이나 화면 오류가 발생할 수 있습니다.

가능하면 방문자가 적은 시간에 진행하고, 설정과 데이터베이스를 백업한 뒤 테스트합니다.

비교 순서

1. 현재 관리자 페이지와 일반 페이지의 로딩 상태를 확인합니다.
2. DSM 리소스 모니터를 열어 CPU·메모리·디스크 상태를 기록합니다.
3. 의심되는 플러그인을 비활성화합니다.
4. 캐시를 비운 뒤 같은 페이지를 다시 엽니다.
5. 로딩 시간과 NAS 자원 사용량을 비교합니다.
6. 플러그인을 다시 활성화해 같은 증상이 재현되는지 확인합니다.

비활성화한 뒤 빨라졌다는 사실만으로 해당 플러그인 자체의 결함이라고 단정하면 안 됩니다. 다른 플러그인이나 테마와의 충돌 때문에 느려졌을 수도 있습니다.

다시 활성화했을 때 동일한 문제가 재현되는지 확인해야 판단의 신뢰도가 높아집니다.

3단계: 관리자 페이지와 방문자 페이지를 나눠서 확인한다

플러그인은 관리자 화면과 일반 방문자 화면에서 서로 다른 작업을 실행할 수 있습니다.

관리자 페이지가 느린 경우

다음 기능을 먼저 의심합니다.

• 플러그인 업데이트 확인
• 라이선스 인증
• 외부 API 호출
• 통계 보고서 생성
• 보안 알림 조회
• 데이터베이스 최적화
• 대시보드 위젯
• 관리자 화면 광고와 공지
• 플러그인 서버와의 통신

관리자 대시보드만 느리고 일반 게시물은 정상이라면 방문자용 캐시를 수정하기보다 관리자 화면에서 실행되는 플러그인 기능을 확인해야 합니다.

방문자 페이지가 느린 경우

다음 항목을 확인합니다.

• 페이지마다 실행되는 데이터베이스 쿼리
• 캐시 미적용
• 외부 폰트와 광고 호출
• 소셜 공유 버튼
• 실시간 방문자 통계
• 관련 글 자동 계산
• 이미지 지연 로딩 충돌
• 여러 개의 CSS와 JavaScript 파일
• 보안 플러그인의 요청 검사

방문자 페이지가 처음 열릴 때만 느리고 두 번째부터 빨라진다면 캐시 생성 과정이나 초기 DB 조회가 원인일 수 있습니다.

모든 접속에서 계속 느리다면 캐시가 작동하지 않거나 외부 통신과 반복 쿼리가 발생할 가능성이 있습니다.

4단계: PHP 프로세스가 오래 점유되는지 확인한다

워드프레스는 대부분의 동적 요청을 PHP가 처리합니다. 플러그인 코드가 복잡하거나 외부 응답을 오래 기다리면 PHP 프로세스 하나가 요청을 장시간 점유합니다.

동시에 여러 요청이 들어오면 사용 가능한 PHP 프로세스가 모두 사용되고 다음 요청은 대기하게 됩니다.

이때 나타날 수 있는 증상은 다음과 같습니다.

• 페이지가 한참 멈춘 뒤 열림
• 관리자 화면의 저장 버튼이 늦게 반응함
• 여러 페이지를 동시에 열면 더 느려짐
• 간헐적으로 502 또는 504 오류가 나타남
• CPU는 높지 않은데 요청이 대기함
• 플러그인 설정 저장이 완료되지 않음

Web Station에서 사용 중인 PHP 프로필과 PHP 버전을 확인합니다. 플러그인이 현재 PHP 버전과 호환되는지도 살펴봐야 합니다.

PHP 메모리 제한을 무조건 높이는 방식은 근본적인 해결책이 아닙니다. 메모리를 과도하게 사용하는 플러그인이 있다면 프로세스당 사용량이 늘어 NAS 전체 메모리 부족을 심화시킬 수 있습니다.

5단계: MariaDB 쿼리가 증가했는지 확인한다

플러그인은 자체 테이블을 만들거나 기존 워드프레스 테이블에 데이터를 저장합니다.

보안, 통계, 검색, 쇼핑몰, 관련 글, 방문 기록 플러그인은 페이지가 열릴 때마다 여러 번 데이터베이스를 조회하거나 기록할 수 있습니다.

다음과 같은 경우 MariaDB 부하를 의심할 수 있습니다.

• 관리자 페이지의 글 목록이 늦게 표시됨
• 게시물을 저장할 때 오래 걸림
• 방문자가 늘면 급격히 느려짐
• MariaDB 프로세스 사용률이 계속 높음
• 플러그인 설치 후 데이터베이스가 빠르게 증가함
• 플러그인을 삭제했는데 전용 테이블이 남아 있음

데이터베이스에서 확인할 항목

• 플러그인이 만든 전용 테이블
• 가장 큰 테이블의 용량
• 방문 및 보안 로그 보존 기간
• 자동으로 삭제되지 않은 임시 데이터
• wp_options 테이블의 자동 로드 데이터
• 반복해서 생성되는 예약 작업 정보
• 게시물 메타데이터 증가

데이터베이스 테이블이 크다는 이유만으로 직접 비우거나 삭제하면 안 됩니다. 현재 플러그인이 사용 중인 데이터와 설정이 손상될 수 있습니다.

먼저 해당 플러그인에서 로그 보존 기간, 통계 정리, 데이터 삭제 기능을 제공하는지 확인해야 합니다.

6단계: 외부 서버 통신 지연을 확인한다

일부 플러그인은 워드프레스 페이지가 열릴 때 외부 서버에 요청을 보냅니다.

예를 들면 다음과 같습니다.

• 라이선스 유효성 확인
• 보안 데이터베이스 조회
• 클라우드 백업 서버 연결
• 번역 서비스 호출
• 소셜미디어 정보 가져오기
• 환율·날씨·지도 데이터 요청
• 외부 이미지 최적화
• 광고 또는 분석 서버 연결
• 플러그인 업데이트 확인

외부 서버의 응답이 늦거나 DNS 연결에 문제가 있으면 NAS의 CPU와 메모리는 정상인데 워드프레스 화면만 늦게 열릴 수 있습니다.

외부 통신을 의심할 수 있는 증상

• 특정 플러그인 설정 화면만 느림
• 일정 시간이 지난 뒤 갑자기 페이지가 열림
• 인터넷 연결이 불안정할 때 더 느려짐
• 관리자 화면에서 업데이트 확인이 오래 걸림
• 플러그인의 클라우드 기능을 끄면 빨라짐
• NAS 내부 IP로 접속해도 같은 지연이 발생함

이 경우 NAS 하드웨어를 교체하거나 메모리를 늘려도 효과가 크지 않을 수 있습니다. 플러그인의 외부 연결 기능과 응답 대기 시간을 확인해야 합니다.

7단계: WP-Cron 예약 작업을 확인한다

워드프레스의 WP-Cron은 예약 게시, 업데이트 확인, 임시 데이터 정리와 같은 시간 기반 작업을 실행합니다.

플러그인은 설치 과정에서 자체 예약 작업을 추가할 수 있습니다.

대표적인 작업은 다음과 같습니다.

• 자동 백업
• 악성코드 검사
• 통계 데이터 집계
• 이메일 발송
• 캐시 정리
• 이미지 최적화
• 외부 데이터 동기화
• 오래된 로그 삭제
• 라이선스 확인
• 상품 및 콘텐츠 동기화

WP-Cron은 일반적으로 방문 요청을 계기로 실행됩니다. 밀린 작업이 많거나 플러그인이 짧은 간격으로 무거운 작업을 등록하면 특정 방문자가 페이지를 열 때 작업이 함께 시작될 수 있습니다.

WP-Cron 문제가 의심되는 경우

• 첫 방문 때만 유난히 느림
• 일정 시간마다 CPU 사용률이 올라감
• 관리자 페이지를 열면 백그라운드 작업이 시작됨
• 예약 작업이 지연되었다는 사이트 건강 경고가 표시됨
• 플러그인을 삭제했는데 관련 예약 작업이 남아 있음
• 같은 작업이 중복 등록되어 있음

예약 작업 이름이 낯설다는 이유로 바로 삭제하면 안 됩니다. 워드프레스 코어와 다른 플러그인이 필요한 작업일 수도 있습니다.

어떤 플러그인이 등록한 작업인지와 실행 주기를 먼저 확인해야 합니다.

8단계: 루프백 요청이 실패하는지 확인한다

워드프레스는 예약 작업과 일부 기능을 실행하기 위해 자기 자신의 사이트 주소로 다시 요청을 보내는 루프백 통신을 사용합니다.

시놀로지 NAS에서 다음 설정이 맞지 않으면 루프백 요청이 실패하거나 응답을 오래 기다릴 수 있습니다.

• 워드프레스 사이트 주소
• DNS 설정
• HTTPS 인증서
• 리버스 프록시
• Web Station 포털
• 방화벽
• 외부 접속 도메인
• 보안 플러그인의 접근 제한

워드프레스의 도구 메뉴에 있는 사이트 건강 화면에서 루프백 요청과 예약 작업 관련 경고를 확인할 수 있습니다.

루프백 오류가 나타난다면 단순히 플러그인이 무거운 것이 아니라 플러그인이 시작한 예약 작업이 NAS 내부에서 자기 사이트에 정상적으로 접속하지 못하는 상태일 수 있습니다.

9단계: 보안 플러그인의 검사 범위를 확인한다

보안 플러그인은 NAS 워드프레스에서 큰 부하를 만들기 쉬운 유형입니다.

전체 파일 검사 기능이 활성화되면 워드프레스 폴더에 있는 수많은 파일을 읽고 해시값을 계산하거나 외부 악성코드 정보와 비교할 수 있습니다.

특히 워드프레스 폴더 안에 다음 파일이 함께 있으면 검사 시간이 길어질 수 있습니다.

• 오래된 사이트 복사본
• 대용량 백업 파일
• 캐시 파일
• 로그 파일
• 압축 파일
• 업로드 이미지 원본
• 테스트 사이트

보안 검사 대상에 백업 폴더와 캐시 폴더까지 포함되면 디스크 사용률이 장시간 높아질 수 있습니다.

점검할 항목

• 전체 검사 실행 주기
• 검사 대상 폴더
• 백업과 캐시 폴더 포함 여부
• 접속 로그 보존 기간
• 실시간 트래픽 기록 기능
• 모든 요청에 대한 방화벽 검사
• 로그인 시도 기록량
• 검사 결과의 데이터베이스 저장 방식

보안 기능을 모두 끄기보다 검사 주기와 범위를 NAS 성능에 맞게 조절하는 것이 중요합니다.

10단계: 백업 플러그인이 다른 NAS 작업과 겹치는지 확인한다

백업 플러그인은 파일 읽기, 압축, 데이터베이스 내보내기, 원격 전송을 동시에 수행할 수 있습니다.

이 과정에서는 CPU, 메모리, 디스크와 네트워크가 모두 사용됩니다.

같은 시간에 Hyper Backup이나 Snapshot Replication까지 실행되면 NAS 응답이 크게 느려질 수 있습니다.

백업 중 나타날 수 있는 증상

• DSM 파일 목록이 늦게 표시됨
• 워드프레스 페이지가 간헐적으로 멈춤
• 디스크 소음과 사용률이 증가함
• 네트워크 업로드 속도가 높아짐
• PHP 처리 시간이 길어짐
• 502 또는 504 오류가 나타남
• 백업이 끝나면 다시 정상화됨

이 경우 백업 플러그인을 삭제할 필요는 없습니다. 워드프레스 백업과 NAS 시스템 백업의 실행 시간이 겹치지 않도록 조정하는 것이 먼저입니다.

11단계: 이미지 최적화 플러그인의 초기 작업을 확인한다

이미지 최적화 플러그인은 설치 후 기존 미디어 파일을 일괄 압축하거나 WebP·AVIF 파일을 생성할 수 있습니다.

게시물이 많고 이미지가 수천 장이라면 초기 변환 작업이 몇 시간 또는 며칠 동안 이어질 수 있습니다.

이때 다음 현상이 나타날 수 있습니다.

• CPU 사용률 증가
• 디스크 읽기·쓰기 증가
• uploads 폴더 용량 증가
• 관리자 페이지 지연
• 썸네일 재생성
• PHP 프로세스 장시간 실행
• 외부 변환 서버로 네트워크 전송

플러그인 설치 직후에만 느려졌다면 현재 일괄 최적화 작업이 실행 중인지 확인합니다.

원본 보관 옵션이 활성화되어 있다면 변환된 이미지와 원본이 함께 저장되어 저장공간도 증가할 수 있습니다.

12단계: 캐시 플러그인이 오히려 느리게 만드는 경우

캐시 플러그인은 일반적으로 방문자 페이지를 빠르게 만들지만 설정이나 환경이 맞지 않으면 반대 결과가 나타날 수 있습니다.

다음과 같은 문제가 발생할 수 있습니다.

• 여러 캐시 플러그인을 동시에 사용함
• 페이지 캐시가 매번 삭제됨
• 캐시 생성 작업이 반복됨
• 관리자 페이지까지 잘못 캐시됨
• 객체 캐시 서버가 불안정함
• 데이터베이스 캐시가 디스크 I/O를 증가시킴
• HTML·CSS·JavaScript 최적화 기능이 충돌함
• 리버스 프록시 캐시와 중복됨

캐시 플러그인을 설치한 직후 느려졌다면 기능을 모두 활성화하기보다 페이지 캐시부터 하나씩 적용하면서 비교해야 합니다.

캐시 파일을 지운 직후 첫 방문은 캐시를 새로 생성하므로 평소보다 느릴 수 있습니다. 첫 번째 요청과 캐시가 생성된 뒤 두 번째 요청을 구분해서 비교해야 합니다.

플러그인 충돌인지 플러그인 자체 부하인지 구분하는 방법

플러그인을 하나 비활성화했더니 빨라졌다고 해서 해당 플러그인만의 문제라고 단정할 수는 없습니다.

두 플러그인이 같은 기능을 동시에 수행하면서 충돌할 수 있기 때문입니다.

예를 들면 다음과 같습니다.

• 캐시 플러그인 두 개
• 이미지 최적화 플러그인 두 개
• 보안 방화벽 플러그인과 로그인 제한 플러그인
• 리디렉션 플러그인과 SSL 플러그인
• 백업 플러그인과 파일 검사 플러그인
• 통계 플러그인과 접속 기록 플러그인

판단 방법

1. 의심되는 플러그인을 비활성화합니다.
2. 사이트 속도와 자원 사용량을 확인합니다.
3. 다른 유사 기능 플러그인을 확인합니다.
4. 의심되는 플러그인만 단독으로 활성화해 봅니다.
5. 다른 플러그인을 하나씩 추가하며 증상을 재현합니다.

플러그인 단독 사용에서는 정상인데 특정 플러그인을 함께 활성화했을 때 느려진다면 기능 중복이나 충돌일 가능성이 높습니다.

관리자 페이지에 들어갈 수 없을 때 플러그인 끄는 방법

플러그인을 설치한 직후 관리자 페이지가 열리지 않거나 심하게 느려졌다면 File Station을 이용해 해당 플러그인을 비활성화할 수 있습니다.

일반적인 플러그인 경로는 다음과 같습니다.

wp-content/plugins

문제가 발생한 플러그인의 폴더 이름을 임시로 변경합니다.

plugin-name
plugin-name-disabled

워드프레스는 기존 경로에서 플러그인 파일을 찾지 못하면 해당 플러그인을 비활성 상태로 처리합니다.

전체 플러그인을 테스트해야 한다면 plugins 폴더 자체의 이름을 임시로 변경할 수도 있습니다.

plugins
plugins-disabled

로그인이 가능해지면 원래 이름으로 되돌린 뒤 플러그인을 하나씩 활성화하면서 원인을 찾습니다.

플러그인 폴더를 바로 삭제하면 설정 확인과 복구가 어려워질 수 있으므로 먼저 이름만 변경하는 것이 안전합니다.

증상별 원인 판단표

확인 결과	가능성이 높은 원인	다음 점검
CPU가 계속 높음	이미지 변환, 보안 검사, 백업	실행 중인 작업과 프로세스 확인
CPU는 낮지만 페이지가 늦음	외부 API, DB 대기, PHP 프로세스 부족	관리자 화면과 외부 통신 확인
메모리와 스왑이 증가함	플러그인 메모리 과다 사용	PHP와 MariaDB 프로세스 비교
디스크 사용률이 높음	파일 검사, 백업, 캐시 생성	NAS 예약 작업과 실행 시간 비교
관리자 페이지에서만 느림	통계, 업데이트, 라이선스 확인	대시보드 기능과 외부 요청 확인
특정 시간마다 느림	WP-Cron 또는 예약 백업	예약 작업 주기 확인
방문자가 늘면 느림	페이지별 DB 조회와 PHP 처리	캐시 적용과 쿼리 수 확인
플러그인 비활성화 후 정상	해당 플러그인 또는 충돌	단독 활성화로 재현 확인
플러그인을 삭제해도 느림	남은 예약 작업이나 DB 테이블	플러그인 잔여 데이터 확인
NAS 전체가 느림	CPU·메모리·디스크 자원 부족	DSM 리소스 모니터 확인

가장 효율적인 진단 순서

플러그인 설치 후 NAS가 느려졌다면 다음 순서로 확인하는 것이 좋습니다.

1. 워드프레스만 느린지 DSM 전체가 느린지 구분합니다.
2. DSM 리소스 모니터에서 CPU·메모리·디스크 사용량을 확인합니다.
3. 느려진 시간과 플러그인 작업 시간을 비교합니다.
4. 관리자 페이지와 일반 페이지의 속도를 각각 확인합니다.
5. 의심되는 플러그인을 비활성화해 전후 차이를 비교합니다.
6. 다시 활성화했을 때 같은 증상이 재현되는지 확인합니다.
7. WP-Cron 예약 작업과 사이트 건강 경고를 확인합니다.
8. 백업·보안·이미지 변환 작업이 실행 중인지 살펴봅니다.
9. MariaDB 테이블과 로그 증가 여부를 확인합니다.
10. 외부 API와 라이선스 서버 통신 여부를 확인합니다.
11. 유사 기능을 수행하는 다른 플러그인이 있는지 확인합니다.
12. 원인을 확인한 뒤 설정 조정, 교체 또는 삭제를 결정합니다.

바로 플러그인을 삭제하면 안 되는 이유

플러그인을 삭제한다고 모든 데이터와 작업이 자동으로 사라지는 것은 아닙니다.

플러그인에 따라 다음 항목이 남을 수 있습니다.

• 데이터베이스 전용 테이블
• wp_options 설정값
• 예약된 WP-Cron 작업
• 캐시 파일
• 백업 파일
• 로그 파일
• uploads 안의 플러그인 데이터
• 외부 서비스 연결 정보

특히 백업이나 보안 플러그인을 삭제하기 전에 해당 플러그인이 만든 백업 파일과 로그의 위치를 확인해야 합니다.

삭제 후에도 NAS가 계속 느리다면 플러그인이 남긴 예약 작업이나 데이터가 원인일 수 있습니다.

피해야 할 해결 방법

플러그인을 한꺼번에 모두 삭제하지 않는다

문제는 일시적으로 사라질 수 있지만 어떤 플러그인이 원인이었는지 확인하기 어려워집니다. 비활성화와 재활성화를 통해 원인을 좁히는 것이 좋습니다.

PHP 메모리만 무조건 높이지 않는다

PHP 메모리 제한을 높이면 한 번의 요청은 완료될 수 있지만 동시에 실행되는 프로세스가 NAS 메모리를 더 많이 사용할 수 있습니다.

캐시 플러그인을 여러 개 설치하지 않는다

서로 다른 캐시가 중복으로 작동하면 파일 생성과 삭제가 반복되거나 화면 오류가 발생할 수 있습니다.

데이터베이스 테이블을 임의로 삭제하지 않는다

플러그인 이름과 비슷한 테이블이라도 다른 기능과 연결되어 있을 수 있습니다. 데이터베이스 백업과 사용 여부 확인이 먼저입니다.

운영 중인 사이트에서 바로 대량 검사를 실행하지 않는다

악성코드 검사, 이미지 재생성, 전체 백업은 방문자가 적은 시간에 실행하는 것이 좋습니다.

플러그인 개수만으로 성능을 판단하지 않는다

플러그인 20개가 설치되었다는 사실보다 페이지 요청마다 어떤 작업을 실행하고 얼마나 많은 데이터를 처리하는지가 중요합니다.

플러그인을 계속 사용할지 판단하는 기준

성능 문제가 확인되었다고 모든 플러그인을 제거할 필요는 없습니다.

다음 기준으로 유지 여부를 판단할 수 있습니다.

유지해도 되는 경우

• 초기 작업이 끝난 뒤 성능이 정상으로 돌아옴
• 실행 시간을 조정하면 문제가 사라짐
• 로그나 데이터 보존 기간을 줄일 수 있음
• 검사 대상과 기능 범위를 제한할 수 있음
• 사이트 운영에 반드시 필요한 기능임
• 다른 플러그인과의 충돌을 해결할 수 있음

교체를 고려할 경우

• 단순 기능인데 페이지마다 무거운 작업을 실행함
• 외부 서버 응답에 따라 관리자 페이지가 멈춤
• 데이터베이스와 로그가 계속 증가함
• NAS 사양에서 정상 운영이 어려움
• 비슷한 기능의 더 가벼운 대안이 있음
• 개발과 업데이트가 장기간 중단됨

삭제를 고려할 경우

• 현재 사용하지 않는 기능임
• 다른 플러그인과 기능이 중복됨
• 비활성화하면 속도가 명확히 개선됨
• 반복 오류와 과도한 자원 사용이 계속됨
• 설정을 조절해도 성능 문제가 재현됨

느려짐을 예방하는 플러그인 운영 방법

한 번에 하나씩 설치한다

여러 플러그인을 동시에 설치하면 어떤 플러그인이 성능 문제를 일으켰는지 찾기 어렵습니다.

설치 직후 예약 작업을 확인한다

백업, 보안 검사, 이미지 최적화 플러그인은 활성화 직후 자동 작업을 시작할 수 있습니다.

유사 기능을 중복 설치하지 않는다

캐시, 보안, 통계, 이미지 최적화 기능은 하나의 플러그인이 여러 기능을 포함하는 경우가 많습니다.

정기적으로 로그와 데이터베이스를 확인한다

설치 파일 크기가 작아도 로그와 데이터베이스가 계속 증가할 수 있습니다.

NAS의 다른 예약 작업과 시간을 분리한다

워드프레스 백업과 Hyper Backup, 보안 검사와 S.M.A.R.T. 테스트가 같은 시간에 실행되지 않도록 조정합니다.

리소스 모니터의 사용 기록을 활성화한다

실시간 화면만 보면 문제가 발생한 시간을 놓칠 수 있습니다. 사용 기록을 남기면 플러그인 작업 시간과 자원 사용량을 비교하기 쉽습니다.

자주 묻는 질문

플러그인이 많으면 무조건 워드프레스가 느려지나요?

그렇지 않습니다. 플러그인 개수보다 각 플러그인이 페이지마다 실행하는 PHP 코드, 데이터베이스 쿼리, 외부 요청과 예약 작업의 양이 더 중요합니다.

플러그인을 비활성화했는데도 NAS가 계속 느린 이유는 무엇인가요?

이미 시작된 백업이나 이미지 변환 작업이 남아 있거나, 플러그인이 등록한 예약 작업·데이터베이스·로그 파일이 계속 영향을 줄 수 있습니다. NAS의 다른 패키지 작업과 겹쳤을 가능성도 확인해야 합니다.

CPU 사용률이 높지 않은데 워드프레스가 느릴 수 있나요?

가능합니다. 외부 서버 응답, MariaDB 쿼리, 디스크 I/O, PHP 프로세스 대기 또는 DNS 연결이 원인이라면 CPU 사용률은 높지 않아도 페이지가 늦게 열릴 수 있습니다.

캐시 플러그인을 설치했는데 왜 더 느려졌나요?

초기 캐시 생성, 잘못된 설정, 다른 캐시 기능과의 중복, 캐시 파일 정리 실패가 원인일 수 있습니다. 캐시 삭제 직후 첫 요청과 캐시 생성 후 요청을 구분해 비교해야 합니다.

보안 플러그인은 NAS 성능에 부담을 주나요?

전체 파일 검사, 실시간 요청 검사, 접속 기록과 악성코드 비교 기능은 CPU·디스크·데이터베이스를 사용할 수 있습니다. 검사 범위와 실행 시간을 NAS 성능에 맞게 조절해야 합니다.

플러그인 폴더를 삭제하면 데이터도 모두 삭제되나요?

아닙니다. 데이터베이스 테이블, 설정, 로그, 캐시, 백업 파일과 예약 작업이 남을 수 있습니다. 삭제 전 플러그인의 데이터 보관 방식을 확인해야 합니다.

마무리

시놀로지 NAS에서 워드프레스 플러그인을 설치한 뒤 느려졌다면 플러그인 수부터 줄이기보다 CPU·메모리·디스크·PHP·MariaDB·외부 통신 중 어디에서 지연이 발생하는지 확인하는 것이 중요합니다.

DSM과 파일 전송까지 함께 느리다면 NAS 자원 점유를 먼저 확인하고, 워드프레스 화면만 느리다면 PHP 처리, 데이터베이스 쿼리, WP-Cron과 외부 API 요청을 살펴봐야 합니다.

특정 시간에만 느려진다면 백업, 보안 검사, 이미지 최적화 같은 예약 작업일 가능성이 높습니다. 플러그인을 비활성화했을 때 빨라지고 다시 활성화했을 때 같은 증상이 재현되는지도 확인해야 합니다.

원인을 확인하지 않은 채 플러그인을 삭제하거나 PHP 메모리를 높이면 문제가 잠시 가려질 수는 있어도 근본적인 해결이 되지 않습니다.

설치 전후의 속도와 NAS 자원 사용량을 같은 조건에서 비교하면 플러그인 자체의 부하인지, 다른 플러그인과의 충돌인지, NAS의 다른 작업과 겹친 문제인지 구분할 수 있습니다.