얼마 전 작은 쇼핑몰 워드프레스가 자꾸 느려진다는 상담을 받았습니다. 월 방문자는 2만 명 정도였고, 운영자는 트래픽이 문제라고 생각하고 있었습니다. 그런데 서버를 열어보니 원인은 트래픽이 아니라 자동 백업 플러그인이었습니다. 매일 새벽 전체 백업을 압축하면서 CPU를 오래 잡고, 같은 시간에 보안 스캔까지 겹치고 있었습니다.
워드프레스는 생각보다 작은 사양에서도 잘 버팁니다. 대신 플러그인, PHP 설정, DB 상태, 백업 방식이 엉키면 방문자가 많지 않아도 금방 느려집니다. 그래서 요금제를 먼저 고르기보다 내 사이트가 실제로 어떤 일을 하는지부터 계산하는 게 맞습니다.
워드프레스는 방문자 수보다 동시접속이 중요합니다
월 방문자 10만 명이라는 숫자는 커 보이지만, 하루로 나누면 약 3,300명입니다. 다시 시간대로 나누면 피크 시간에 몇십 명이 동시에 접속하는 수준일 수 있습니다. 서버 입장에서는 한 달 전체 방문자보다 같은 순간에 PHP 요청이 몇 개나 쌓이는지가 훨씬 중요합니다.
일반적인 블로그형 워드프레스라면 캐시가 잘 걸린다는 전제에서 저가형 웹호스팅으로도 꽤 오래 갑니다. 월 방문자 1만 명 이하, 이미지가 과하지 않고 댓글이나 회원 기능이 없다면 굳이 VPS부터 시작할 이유가 없습니다. 월 방문자 5만 명 안쪽도 페이지 캐시, 이미지 최적화, CDN 정도만 제대로 쓰면 공유 호스팅이나 저가형 매니지드 호스팅으로 충분한 경우가 많습니다.
- 개인 블로그: 월 1만~5만 방문자까지는 저가형 호스팅으로도 가능
- 회사 소개 사이트: 접속 변동이 작으면 CPU보다 백업과 보안 설정이 중요
- 예약·회원 사이트: 방문자 수가 적어도 PHP 실행과 DB 부하를 따로 봐야 함
- 쇼핑몰: 장바구니, 결제, 재고 처리 때문에 캐시만 믿기 어려움
근데 같은 워드프레스라도 쇼핑몰은 다릅니다. 상품 목록은 캐시할 수 있어도 장바구니와 결제 페이지는 매번 동적으로 처리됩니다. 방문자 1만 명짜리 쇼핑몰이 방문자 10만 명짜리 단순 블로그보다 서버를 더 힘들게 만들 수 있습니다.
초보자는 CPU와 메모리를 이렇게 보면 됩니다
호스팅 상품을 보면 디스크 용량과 트래픽만 크게 적혀 있는 경우가 많습니다. 솔직히 워드프레스에서 더 자주 문제가 되는 건 CPU 제한, PHP 메모리, DB 제한입니다. 디스크 10GB를 다 쓰기 전에 플러그인 하나가 PHP 메모리를 먼저 터뜨리는 일이 흔합니다.
일반 블로그 기준으로 PHP 메모리 제한은 최소 128MB, 가능하면 256MB가 편합니다. 관리자 화면에서 페이지 빌더를 쓰거나 우커머스, 다국어 플러그인, 보안 플러그인을 같이 쓰면 128MB는 답답할 수 있습니다. 서버 메모리는 VPS 기준으로 테스트용 1GB, 운영용 최소 2GB, 트래픽이 있거나 우커머스를 쓰면 4GB부터 보는 편이 안전합니다.
- 정적 성격의 블로그: 1 vCPU, 1~2GB 메모리로 시작 가능
- 기업 사이트와 랜딩 페이지 여러 개: 1~2 vCPU, 2GB 메모리 권장
- 우커머스 소형 쇼핑몰: 2 vCPU, 4GB 메모리부터 검토
- 관리자 작업이 많은 사이트: 방문자 수보다 메모리 여유를 우선 확인
여기서 중요한 건 처음부터 큰 서버를 사는 게 아닙니다. 서버가 부족해지는 지점을 관찰할 수 있게 로그와 모니터링을 켜두는 겁니다. CPU가 80% 이상으로 오래 붙어 있는지, 메모리 스왑이 생기는지, DB 쿼리가 밀리는지를 보면 업그레이드 시점이 보입니다.
캐시 설정 하나로 요금제가 달라집니다
워드프레스 속도 문제를 보면 캐시가 빠져 있는 경우가 많습니다. 캐시가 없으면 방문자 한 명이 글 하나를 볼 때마다 PHP가 실행되고 DB에서 글, 옵션, 메뉴, 플러그인 설정을 다시 읽습니다. 반대로 페이지 캐시가 있으면 이미 만들어 둔 HTML을 바로 내보낼 수 있습니다.
블로그나 회사 소개 사이트는 페이지 캐시 효과가 큽니다. 캐시가 제대로 걸리면 같은 사양에서 체감 처리량이 몇 배 차이 납니다. 그래서 저는 새 서버를 잡을 때 먼저 캐시 가능 여부를 봅니다. 로그인 사용자, 장바구니, 개인화 화면이 많은 사이트는 캐시가 제한되니 그만큼 서버 사양을 올려야 합니다.
- 페이지 캐시: 글, 카테고리, 소개 페이지처럼 변동이 적은 화면에 효과적
- 오브젝트 캐시: DB 조회가 많은 사이트에서 효과적
- 브라우저 캐시: 이미지, CSS, JS 재요청을 줄이는 데 필요
- 이미지 최적화: 트래픽 비용과 로딩 시간을 동시에 줄임
그런데 캐시 플러그인을 여러 개 겹쳐 쓰면 오히려 장애가 납니다. 압축, 지연 로딩, CSS 병합 기능이 서로 충돌하면 화면이 깨지거나 관리자 화면이 느려집니다. 하나를 정해서 적용하고, 변경 전후로 모바일 화면과 결제·문의 폼을 꼭 확인하는 방식이 낫습니다.
백업은 용량보다 복구 시간을 기준으로 잡습니다
워드프레스 운영에서 백업은 파일 하나 받아두는 일이 아닙니다. 실제로 중요한 건 복구가 되는지입니다. 장애가 났을 때 백업 파일은 있는데 DB 인코딩이 깨지거나 업로드 폴더가 빠져 있으면 그 백업은 반쪽입니다.
기본은 파일과 DB를 분리해서 보는 겁니다. 워드프레스 파일 중 테마, 플러그인, 업로드 폴더가 중요하고, 글과 설정은 DB에 들어갑니다. 특히 이미지가 많은 사이트는 업로드 폴더가 커지기 때문에 매번 전체 압축 백업을 돌리면 서버에 부담이 됩니다. 변경분 위주로 보관하거나, 백업 시간을 새벽 트래픽이 가장 낮은 시간대로 빼는 게 좋습니다.
- 개인 블로그: 주 1회 전체 백업, 매일 DB 백업이면 충분한 경우가 많음
- 자주 글을 쓰는 사이트: 매일 DB 백업과 주기적 파일 백업 권장
- 쇼핑몰: 주문 데이터 때문에 최소 일 단위, 가능하면 더 짧은 주기 필요
- 운영 서버 내부에만 저장한 백업: 서버 장애 때 같이 사라질 수 있음
사실 백업 정책은 비싼 솔루션보다 습관이 더 중요합니다. 한 달에 한 번이라도 임시 경로에 복구 테스트를 해보면 플러그인 호환성, PHP 버전 문제, DB 계정 문제를 미리 잡을 수 있습니다. 사고가 난 뒤에는 이런 작은 차이가 몇 시간을 갈라놓습니다.
워드프레스 이전 전에는 이 순서로 확인합니다
호스팅을 옮길 때 가장 많이 터지는 부분은 DNS, SSL, PHP 버전입니다. 파일과 DB를 잘 옮겨도 도메인 연결이 꼬이면 사이트가 안 열립니다. SSL 인증서가 새 서버에 적용되지 않았는데 DNS부터 바꾸면 방문자에게 보안 경고가 뜹니다.
이전 작업은 순서를 정해두면 훨씬 덜 위험합니다. 먼저 새 서버에 같은 PHP 버전 또는 호환 가능한 버전을 맞추고, DB를 가져온 뒤 임시 주소나 hosts 파일로 화면을 확인합니다. 그다음 SSL을 준비하고, 마지막에 DNS를 변경합니다. DNS TTL을 미리 낮춰두면 전환 시간이 짧아집니다.
- 이전 전: 현재 PHP 버전, DB 버전, 플러그인 목록 확인
- 이전 중: 파일과 DB 복사 후 관리자 로그인, 글 상세, 이미지 확인
- 전환 직전: SSL 적용, 캐시 비우기, 폼 발송 테스트
- 전환 후: 에러 로그, 404, 관리자 속도, 백업 스케줄 확인
작은 사이트라도 운영 중인 워드프레스라면 바로 DNS부터 바꾸지 않는 게 좋습니다. 새 서버에서 화면이 정상인지 눈으로 보고, 관리자에서 글 저장이 되는지 확인한 다음 넘겨야 합니다. 이 순서만 지켜도 이전 장애의 절반은 줄어듭니다.
워드프레스 호스팅은 비싼 요금제를 고르는 게임이 아닙니다. 내 사이트가 캐시 가능한 구조인지, 동시접속이 얼마나 되는지, 백업이 서버를 얼마나 괴롭히는지 보는 일에 가깝습니다. 처음에는 작게 시작해도 됩니다. 대신 로그를 보고, 백업을 검증하고, 장애가 날 만한 지점을 미리 줄여두는 운영 습관이 있어야 오래 갑니다.
