얼마 전 워드프레스 사이트가 자꾸 느려진다는 상담을 받았는데, 막상 서버를 보니 트래픽보다 백업 플러그인이 더 큰 문제였습니다. 방문자는 하루 2천 명 정도였고 캐시도 켜져 있었는데, 새벽마다 전체 파일 압축과 데이터베이스 덤프가 겹치면서 메모리를 다 잡아먹고 있었습니다.
워드프레스는 생각보다 작은 서버에서도 잘 돕니다. 다만 조건이 있습니다. 캐시가 제대로 잡혀 있고, 플러그인이 과하지 않고, 백업이 서버 자원을 긁어먹지 않아야 합니다. 서버 요금제를 고를 때 방문자 수만 보고 올리면 돈은 더 쓰는데 장애 원인은 그대로 남는 경우가 많습니다.
워드프레스 사양은 방문자 수보다 요청 수로 봅니다
월 10만 페이지뷰라고 하면 커 보이지만 계산하면 하루 평균 약 3천3백 페이지뷰입니다. 24시간으로 나누면 초당 요청은 아주 낮습니다. 물론 실제 방문은 낮에 몰리니 피크를 10배로 잡아도, 캐시된 블로그 글 중심이면 1 vCPU와 메모리 1GB 안에서도 버티는 경우가 많습니다.
문제는 캐시가 안 되는 요청입니다. 관리자 화면, 장바구니, 결제, 로그인 사용자 페이지는 매번 PHP와 데이터베이스를 거칩니다. 같은 방문자 수라도 단순 블로그와 쇼핑몰의 서버 사양이 달라지는 이유가 여기 있습니다.
- 개인 블로그, 하루 1천 페이지뷰 이하: 저가 웹호스팅이나 1 vCPU, 1GB VPS로 충분한 구간입니다.
- 콘텐츠 사이트, 월 10만 페이지뷰 안팎: 캐시 적용 기준 1~2 vCPU, 1~2GB 메모리부터 봅니다.
- 광고 유입이 몰리는 사이트: CPU보다 웹서버 동시 연결 수와 캐시 적중률을 먼저 봐야 합니다.
- 예약, 멤버십, 쇼핑 기능이 있는 사이트: 2 vCPU, 4GB 메모리 이상에서 시작하는 편이 안정적입니다.
싼 요금제가 충분한 구간이 분명히 있습니다
솔직히 회사 소개 사이트, 작은 병원 사이트, 동네 매장 홈페이지 같은 곳은 비싼 클라우드 서버가 필요 없는 경우가 많습니다. 페이지 수가 적고 글 수정도 자주 없으면 정적 캐시가 거의 다 처리합니다. 이때는 디스크 10GB, 트래픽 월 50~100GB 수준의 저가 호스팅도 남습니다.
다만 저가형을 쓸 때는 약점을 알고 써야 합니다. CPU 사용 시간이 제한되거나, 동시 접속이 잠깐만 튀어도 503 오류가 날 수 있습니다. 백업 보관 기간이 짧거나 복구를 유료로 처리하는 업체도 있습니다. 가격표보다 운영 조건을 봐야 손해를 안 봅니다.
요금제 비교할 때 보는 숫자
- 메모리: 워드프레스 기본은 256MB 제한으로 시작하고, 플러그인이 많으면 512MB 이상이 편합니다.
- PHP 작업 수: 동시 요청을 몇 개까지 처리하는지 봅니다. 이 숫자가 낮으면 CPU가 남아도 대기가 생깁니다.
- 데이터베이스 용량: 글보다 이미지 메타, 리비전, 로그성 테이블이 더 빨리 쌓일 때가 있습니다.
- 스토리지 IOPS: 방문자가 적어도 디스크 입출력이 느리면 관리자 화면이 답답해집니다.
- 백업 정책: 자동 백업 여부보다 실제 복원 버튼이 있는지, 보관 기간이 며칠인지가 더 중요합니다.
캐시와 백업을 먼저 잡으면 서버 업그레이드가 늦어집니다
워드프레스 성능 작업에서 제일 먼저 보는 건 페이지 캐시입니다. 로그인하지 않은 방문자에게 HTML 캐시를 내보내면 PHP 실행과 DB 조회가 크게 줄어듭니다. 그 다음은 이미지 최적화입니다. 원본 사진을 그대로 올리면 서버보다 방문자 회선이 먼저 막힙니다.
백업은 더 조심해야 합니다. 워드프레스 백업 플러그인이 편하긴 한데, 트래픽이 있는 시간에 전체 압축을 돌리면 서버가 순간적으로 멈춘 것처럼 보입니다. 파일 백업과 데이터베이스 백업 시간을 나누고, 보관 위치도 서버 내부 하나에만 두지 않는 게 좋습니다. 같은 서버 안에 백업을 쌓아두면 디스크 장애 때 같이 날아갑니다.
- DB 백업은 매일, 파일 백업은 변경량에 따라 주 1~2회로 나눕니다.
- 업데이트 전에는 테마, 플러그인, 데이터베이스를 함께 백업합니다.
- 복원 테스트를 최소 한 번은 해둡니다. 백업 파일만 있고 복원이 안 되는 경우가 꽤 있습니다.
- 이미지 폴더가 커졌다면 원격 저장소나 별도 스토리지 사용을 검토합니다.
장애가 나면 이 순서로 확인합니다
사이트가 안 뜨면 대부분 바로 서버 재부팅부터 누르는데, 저는 순서를 정해서 봅니다. 재부팅은 원인 기록을 지울 수 있어서 마지막 쪽에 둡니다. 먼저 DNS가 맞는지, SSL 인증서가 만료되지 않았는지, 웹서버가 응답하는지 확인합니다.
그 다음 PHP-FPM 상태와 데이터베이스 연결을 봅니다. 워드프레스 화면에 데이터베이스 연결 오류가 뜨면 DB 서버가 죽은 건지, 계정 비밀번호가 바뀐 건지, 디스크가 꽉 찼는지 나눠야 합니다. 디스크 100%는 생각보다 자주 나옵니다. 백업 파일, 로그 파일, 캐시 파일이 원인인 경우가 많습니다.
현장에서 자주 본 원인
- 플러그인 자동 업데이트 뒤 PHP 버전과 충돌
- SSL 자동 갱신 실패로 브라우저 경고 발생
- 백업 파일 누적으로 디스크가 가득 참
- 관리자 비밀번호 공격으로 로그인 요청 폭증
- 캐시 플러그인 설정 오류로 모바일 화면 깨짐
워드프레스 이전은 속도보다 검증이 중요합니다
서버 이전은 파일을 옮기고 DB를 넣는 작업 자체보다, 옮긴 뒤 확인이 더 중요합니다. PHP 버전, 확장 모듈, 업로드 제한, 퍼머링크, 문자셋이 맞아야 합니다. 특히 오래된 워드프레스는 최신 PHP에서 플러그인이 깨질 수 있어 임시 서버에서 먼저 띄워보는 편이 안전합니다.
이전 전에는 기존 서버에서 용량, DB 크기, PHP 버전, 활성 플러그인 목록을 적어둡니다. 이전 후에는 관리자 로그인, 글 작성, 이미지 업로드, 문의폼, 결제나 예약 기능을 직접 눌러봅니다. 눈으로 첫 화면만 보고 끝내면 며칠 뒤에 고객 문의로 오류를 알게 됩니다.
워드프레스 운영은 큰 서버를 쓰는 게임이 아닙니다. 작은 서버라도 캐시, 백업, 업데이트 순서가 잡혀 있으면 꽤 오래 버팁니다. 반대로 8GB 서버를 써도 백업이 같은 디스크를 채우고 플러그인이 마음대로 업데이트되면 장애는 납니다. 저는 예산이 넉넉해도 처음부터 과한 사양을 잡기보다, 현재 트래픽과 동시접속을 숫자로 보고 한 단계씩 올리는 방식을 더 믿습니다.
