
얼마 전 워드프레스 사이트가 느리다며 VPS를 올려야 하느냐는 질문을 받았다. 서버를 보니 메모리는 남아 있었고, 특정 플러그인이 방문할 때마다 무거운 데이터베이스 조회를 반복하고 있었다. 요금제를 올리기 전에 어디서 시간이 쓰이는지 확인해야 하는 이유다.
방문자 수를 초당 요청으로 바꿔 보기
하루 방문자 수만으로 서버 사양을 고르기는 어렵다. 같은 1만 명이어도 하루 종일 고르게 들어오는 사이트와 점심시간에 몰리는 사이트의 부담은 다르다. 우선 하루 페이지 조회 수를 잡고, 접속이 몰리는 시간을 가정해 초당 페이지 요청 수로 바꾼다.
예를 들어 하루 1만 페이지 조회가 8시간에 집중된다면 평균은 초당 약 0.35페이지다. 가장 바쁜 시간에 평균의 3배가 들어온다고 잡아도 초당 약 1페이지다. 이 수치는 이미지나 화면 구성 파일까지 합친 요청 수가 아니다. 워드프레스가 실제로 페이지를 만들어야 하는 횟수를 가늠하기 위한 출발점이다.
여기서 캐시가 크게 갈린다. 방문자에게 같은 글 화면을 저장해 전달하면 PHP와 데이터베이스가 매번 일할 필요가 없다. 반면 로그인 화면, 장바구니, 개인별로 달라지는 페이지는 같은 방식으로 캐시하기 어렵다. 하루 조회 수가 적어도 동시 편집자가 많거나 예약·주문 기능이 있으면 서버 부담은 달라진다.
서버 로그와 호스팅 관리 화면에서 바쁜 시간대의 요청 수, CPU 사용률, 메모리 사용량, 응답 시간을 함께 본다. 응답 시간이 늘 때 CPU도 꽉 차는지, 메모리가 모자라 디스크를 쓰는지 확인하면 증설이 필요한지 판단하기 쉽다. 측정값 없이 월 방문자 수만 보고 고가 요금제를 고를 필요는 없다.
공유 호스팅과 VPS를 고르는 기준
글과 사진 위주의 작은 사이트라면 공유 호스팅부터 시작해도 된다. 방문이 드물고 관리자가 한두 명인 블로그에는 서버 운영 시간을 아껴 주는 편이 더 큰 장점일 수 있다. 다만 같은 상품명이라도 CPU 사용 제한, 동시 처리 제한, 저장 공간과 백업 제공 범위는 업체마다 다르다. 월 요금과 함께 이 조건을 확인해야 한다.
VPS는 서버 설정과 작업 스케줄을 직접 다뤄야 하거나, 공유 호스팅의 제한에 실제로 걸릴 때 검토한다. 처음부터 큰 사양이 필요한 것은 아니다. 데이터베이스까지 한 서버에 두는 소규모 사이트라면 메모리 2GB 안팎을 출발점으로 삼을 수 있지만, 설치한 플러그인과 방문 패턴에 따라 부족할 수도 남을 수도 있다. 서버 운영체제 업데이트, 방화벽, 백업, 장애 대응도 직접 맡는다는 비용을 같이 계산한다.
저장 공간은 현재 파일 크기만 보고 고르면 곤란하다. 업로드 이미지 8GB와 데이터베이스 2GB를 쓰는 사이트라면 합계 10GB에 딱 맞춰 잡을 수 없다. 업데이트용 임시 파일, 로그, 이전 작업 공간을 더하고 여유를 둔다. 백업을 같은 서버에 보관한다면 그 공간도 별도로 필요하다. 다만 같은 서버의 백업만으로는 서버 자체가 손상됐을 때 복구하기 어렵다.
설치 전에 확인할 설정과 백업
워드프레스 공식 요구 사항은 PHP 8.3 이상, MariaDB 10.11 이상 또는 MySQL 8.0 이상, HTTPS를 권장한다. 호스팅 상품에 ‘워드프레스 지원’이라고 쓰여 있어도 실제 제공 버전을 확인하는 편이 낫다. 오래된 PHP가 아직 동작한다는 말과 계속 운영하기에 적절하다는 말은 다르다.
백업은 파일과 데이터베이스를 한 세트로 취급한다. 글과 설정은 데이터베이스에 있고, 이미지·테마·플러그인 파일은 서버 저장 공간에 있다. 파일만 내려받으면 글이 빠지고, 데이터베이스만 저장하면 이미지가 빠질 수 있다. 변경 직전 두 항목을 비슷한 시점에 저장하고, 서버 밖에도 사본을 둔다.
운영 중에는 백업 주기를 게시 빈도에 맞춘다. 하루에 글을 여러 개 올린다면 주 1회 백업으로는 복구 시 잃는 작업이 많다. 반대로 거의 바뀌지 않는 소개 사이트라면 매일 전체 백업이 꼭 필요한 것은 아니다. 더 중요한 검사는 복원이다. 별도 공간에서 파일을 올리고 데이터베이스를 가져온 뒤 글, 이미지, 관리자 로그인이 정상인지 한 번 확인해야 백업을 믿을 수 있다.
이전과 장애 때 확인하는 순서
사이트를 옮길 때는 새 서버의 PHP·데이터베이스 버전과 저장 공간을 먼저 확인한다. 기존 사이트의 파일과 데이터베이스를 백업한 다음 새 서버에 복원하고, 주소를 전환하기 전에 주요 글과 이미지, 로그인, 문의 양식을 시험한다. 판매 기능이 있다면 주문과 결제 흐름도 확인한다. 주소 전환 직전에는 새 글이나 주문이 이전 서버에만 남지 않도록 변경 시간을 짧게 잡아야 한다.
장애가 나면 먼저 모든 방문자에게 같은 증상이 나는지 확인한다. 사이트 전체가 열리지 않으면 도메인 연결, SSL 인증서 상태, 서버 응답 순으로 본다. 첫 화면은 뜨는데 일부 글만 오류가 나면 최근 바꾼 플러그인·테마와 서버 오류 기록을 확인한다. 화면이 느리다면 CPU·메모리·디스크 용량을 보고, 특정 시간에만 느린지 로그와 대조한다. 원인을 찾기 전에 여러 설정을 한꺼번에 바꾸면 어느 변경이 효과가 있었는지 알기 어렵다.
제가 운영 현장에서 먼저 챙기는 것은 가장 큰 서버가 아니라 복원 가능한 백업과 바쁜 시간의 측정값이다. 작은 요금제로도 충분한 사이트가 많다. 수치가 한계에 닿았을 때 올리면 되고, 그전에는 설정을 바로잡는 일이 대개 더 빠르다.
