모두
모두콘텐츠
얼마 전 워드프레스 사이트가 느리다며 서버를 올려야겠다는 상담을 받았다. 방문자는 하루 300명 남짓이었다. 확인해 보니 서버 자원은 남아 있었고, 이미지 한 장이 8MB를 넘는 데다 페이지 캐시도 꺼져 있었다. 요금제를 바꾸기 전에 어디서 시간이 쓰이는지부터 봐야 하는 사례였다.
방문자 수보다 실제 전송량을 먼저 계산한다
호스팅 사양을 고를 때 월 방문자 수만 보면 판단이 자주 빗나간다. 한 페이지가 1MB인지 6MB인지에 따라 필요한 전송량이 크게 달라진다. 월 페이지 조회 10만 회에 페이지당 전송량이 평균 1.5MB라면 단순 계산으로 약 150GB가 나간다. 이미지 압축과 캐시를 적용해 평균을 700KB로 낮추면 약 70GB다. 같은 방문자 수인데 전송량은 절반 이하가 된다.
계산은 최근 한 달의 페이지 조회 수에 실제 페이지당 전송량을 곱해 시작한다. 관리 화면이나 서버 통계의 전송량도 함께 확인한다. 검색 로봇, 다운로드 파일, 이미지 요청은 페이지 조회 통계와 다르게 잡힐 수 있기 때문이다. 월말 합계만 보지 말고 게시 직후나 광고 집행 시간의 피크도 살펴야 한다.
동시 접속도 구분해서 봐야 한다. 캐시에 저장된 공개 글을 읽는 방문자 30명과, 장바구니나 관리자 화면처럼 매번 PHP와 데이터베이스를 쓰는 방문자 30명은 서버에 주는 부담이 다르다. 일반적인 소규모 블로그라면 처음부터 VPS를 운영하기보다 캐시와 자동 백업을 제공하는 저가 웹호스팅으로 시작해도 충분한 경우가 많다. 반대로 회원 기능이나 주문 처리가 많다면 하루 방문자가 적어도 동시 작업 수를 기준으로 시험해야 한다.
요금제에서는 CPU 숫자보다 운영 조건을 본다
광고에 적힌 저장 공간과 월 전송량만으로는 워드프레스 운영 품질을 판단하기 어렵다. 실제로는 PHP 버전 선택, 데이터베이스 제공 방식, 메모리 제한, 프로세스 제한, 백업 보관 기간, 복구 방법이 더 중요할 때가 많다. 워드프레스 프로젝트는 현재 PHP 8.3 이상과 MariaDB 10.11 이상 또는 MySQL 8.4 이상, 암호화 연결 지원을 권장한다. 호스팅 화면에 적힌 지원 버전과 실제 계정에 적용된 버전이 같은지도 확인한다.
공유 호스팅에서 자원 제한에 자주 걸리거나 서버 설정을 직접 바꿔야 한다면 VPS를 검토할 차례다. 작은 사이트의 출발점으로는 가상 CPU 1~2개와 메모리 2GB 정도를 잡고, 웹서버·PHP·데이터베이스를 올린 뒤 남는 메모리를 측정하는 편이 낫다. 이 수치는 보장 사양이 아니다. 무거운 편집 도구나 검색 기능을 붙이면 더 필요할 수 있고, 정적 페이지 캐시가 잘 작동하면 적은 자원으로도 버틴다.
VPS 비용에는 월 사용료 외에 운영 시간도 들어간다. 보안 업데이트, 방화벽, 인증서 갱신, 백업 저장소, 장애 알림을 직접 챙겨야 한다. 같은 돈이라면 관리형 웹호스팅이 더 나은 선택인 사이트도 많다. 서버를 만질 자유가 실제로 필요한지 먼저 적어 보면 선택이 쉬워진다.
설치 직후에는 속도보다 복구 경로를 만든다
설치를 마치면 관리자 계정 보호, 자동 갱신 정책, 인증서 갱신 상태, 백업 일정을 먼저 잡는다. 관리자 비밀번호를 길고 고유하게 만들고 가능하면 다중 인증을 켠다. 플러그인은 기능 하나 때문에 여러 개를 겹쳐 넣기 쉽다. 캐시나 보안 기능이 중복되면 충돌이 나기도 하므로 맡은 역할을 확인하고 필요한 것만 남긴다.
백업은 데이터베이스와 파일을 한 세트로 다뤄야 한다. 글과 설정은 주로 데이터베이스에 있고, 업로드 이미지와 테마·플러그인 파일은 별도로 있다. 파일만 내려받아 놓고 복구 준비를 마쳤다고 생각하면 사고가 난다. 워드프레스 운영 문서도 두 부분을 함께 보관하고 최근 백업 여러 개를 서로 다른 위치에 두도록 안내한다.
글을 가끔 올리는 블로그라면 주간 백업을 출발점으로 삼을 수 있다. 매일 주문이나 회원 정보가 쌓인다면 하루 한 번으로도 손실이 클 수 있어 더 촘촘한 주기를 잡아야 한다. 기준은 ‘마지막 백업 이후 사라져도 감당할 수 있는 데이터가 얼마인가’다. 서버 안에만 백업을 두면 디스크 장애나 계정 문제 때 원본과 복사본을 함께 잃는다. 외부 저장소에 복사하고, 백업 파일을 실제로 열어 복원하는 시험까지 해 둔다.
이전은 새 서버에서 확인한 뒤 전환한다
워드프레스 이전은 파일 복사만으로 끝나지 않는다. 기존 서버의 파일과 데이터베이스를 같은 시점의 세트로 확보하고, 새 서버에 복원한 다음 데이터베이스 접속 정보와 파일 권한을 확인한다. 주소가 바뀐다면 글과 설정 안에 남은 이전 주소도 바꿔야 한다. 이때 데이터베이스 파일을 일반 텍스트처럼 일괄 치환하면 저장된 데이터 구조가 깨질 수 있다. 워드프레스용 이전 도구의 미리보기 기능으로 변경 건수를 확인한 뒤 적용하는 편이 안전하다.
방문자가 많은 사이트는 전환 직전에 새 글과 주문을 잠시 멈추고 최종 데이터를 다시 옮겨야 한다. 두 서버에 각각 글이나 주문이 쌓이면 어느 쪽이 최신인지 판단하기 어려워진다. 새 서버에서는 메인 화면만 볼 게 아니라 로그인, 글 작성, 이미지 업로드, 검색, 문의 양식까지 확인한다. 전환 뒤에도 기존 서버와 백업을 일정 기간 보관하면 되돌릴 선택지가 생긴다.
사이트가 멈추면 바뀐 것부터 확인한다
장애가 나면 우선 언제부터, 모든 방문자에게, 모든 페이지에서 발생하는지 좁힌다. 도메인 연결과 인증서 상태를 확인하고, 웹서버가 응답하는지 본다. 그다음 웹서버 오류 기록, PHP 오류 기록, 데이터베이스 연결, 디스크 여유 공간 순으로 확인한다. 502나 503 응답이라면 웹서버 뒤의 PHP 처리 과정과 자원 제한을 먼저 의심할 만하다. 관리자 화면만 느리다면 공개 페이지 캐시가 정상이어도 데이터베이스나 플러그인 문제가 남아 있을 수 있다.
바로 앞에 플러그인 갱신이나 설정 변경이 있었다면 그 변경 내역이 가장 좋은 단서다. 무작정 서버를 재시작하기 전에 오류 기록과 시각을 남겨 두면 재발 원인을 찾기 쉽다. 14년 동안 운영하며 느낀 건 워드프레스에 필요한 첫 투자는 큰 서버가 아니라 측정할 수 있는 설정과 복원해 본 백업이라는 점이다. 그 두 가지가 갖춰진 뒤에야 사양을 올릴 이유도 분명해진다.
