홈페이지가 느린 이유를 트래픽으로만 보면 계산이 틀어집니다
얼마 전 작은 병원 홈페이지 이전 상담을 했는데, 업체 견적서에는 클라우드 서버 4코어 8GB가 들어가 있었습니다. 월 방문자는 2만 명 정도였고, 피크 시간 동시 접속은 많아야 20명 안팎이었습니다. 실제로는 저가형 웹호스팅이나 1코어 1GB VPS로도 충분한 규모였죠. 문제는 서버 사양이 아니라 이미지 용량, 백업 방식, PHP 버전, 캐시 설정이었습니다.
홈페이지 서버를 고를 때 제일 많이 하는 실수가 월 방문자 수만 보는 겁니다. 월 10만 방문자라고 해도 하루에 고르게 들어오면 별일 없습니다. 반대로 월 방문자는 적어도 광고 문자 발송 직후 5분 동안 300명이 몰리면 서버가 버벅일 수 있습니다. 그래서 저는 항상 세 가지를 먼저 봅니다. 동시 접속, 페이지 무게, 관리자 작업입니다.
보통 회사 소개형 홈페이지는 한 페이지가 2~5MB 사이입니다. 이미지가 많은 병원, 펜션, 인테리어 사이트는 10MB를 넘기도 합니다. 그런데 텍스트와 이미지 몇 장뿐인 사이트에 4코어 서버를 붙이는 건 낭비에 가깝습니다. 서버는 큰 걸 쓰면 안정적인 게 아니라, 병목이 어디인지 맞춰서 잡아야 안정적입니다.
홈페이지 유형별로 필요한 사양을 잡는 방법
간단한 홍보용 홈페이지라면 기준을 낮게 잡아도 됩니다. 하루 방문자 1천 명 이하, 동시 접속 10명 이하, 워드프레스 플러그인이 많지 않은 구조라면 일반 웹호스팅으로도 충분합니다. 월 몇 천 원대 요금제에서도 버티는 경우가 많습니다. 다만 자동 백업과 SSL 적용 여부는 꼭 확인해야 합니다.
워드프레스 기반 홈페이지는 조금 다르게 봐야 합니다. 같은 방문자 수라도 테마와 플러그인에 따라 자원 사용량이 크게 달라집니다. 페이지 빌더, 예약 플러그인, 다국어 플러그인, 보안 플러그인이 겹치면 첫 화면 하나를 여는 데 PHP 프로세스가 오래 붙잡힙니다. 이 경우 방문자가 적어도 1코어 1GB VPS보다 2GB 메모리 구성이 편할 때가 있습니다.
쇼핑몰이나 예약 기능이 있는 홈페이지는 데이터베이스 부하가 생깁니다. 장바구니, 주문, 회원 로그인, 쿠폰, 재고 처리처럼 쓰기 작업이 많아지면 단순 캐시만으로 해결되지 않습니다. 월 방문자보다 피크 시간 주문 수를 봐야 합니다. 예를 들어 동시에 30명이 상품 상세를 보고, 5명이 결제 단계에 들어가는 정도라면 2코어 4GB부터 보는 게 운영상 편합니다.
- 회사 소개형 홈페이지: 웹호스팅 또는 1코어 1GB VPS
- 워드프레스 블로그형 홈페이지: 1코어 1~2GB VPS
- 이미지 많은 포트폴리오 홈페이지: 저장공간과 전송량 우선 확인
- 예약·회원 기능이 있는 홈페이지: 2코어 4GB 이상 검토
- 쇼핑몰형 홈페이지: DB 백업, 결제 장애 대응, 캐시 예외 설정까지 함께 검토
요금제 비교는 CPU보다 전송량과 백업을 먼저 봅니다
초보자 입장에서는 CPU, 메모리 숫자가 제일 눈에 들어옵니다. 그런데 실제 장애 현장에서는 전송량 제한, inode 제한, 백업 미비 때문에 문제가 나는 경우가 많습니다. 특히 이미지 많은 홈페이지는 CPU보다 월 전송량을 먼저 씁니다. 5MB짜리 페이지를 하루 1천 명이 보면 하루 5GB, 한 달이면 150GB입니다. 여기에 검색봇과 관리자 접속, 이미지 재요청까지 붙으면 여유분이 필요합니다.
웹호스팅에서 흔한 함정은 저장공간은 넉넉한데 파일 개수 제한이 낮은 경우입니다. 워드프레스는 썸네일을 여러 크기로 만들기 때문에 이미지 1장을 올려도 실제 파일은 여러 개 생깁니다. 몇 년 운영한 홈페이지가 갑자기 업로드 오류를 내는 이유가 디스크 용량이 아니라 파일 개수 제한인 경우도 봤습니다.
백업은 더 중요합니다. 홈페이지 운영에서 서버가 느린 건 불편한 정도지만, 백업이 없으면 사고입니다. 최소한 하루 1회 자동 백업, 7일 이상 보관, 다른 저장소 분리 여부를 봐야 합니다. 같은 서버 안에 백업 파일을 두는 건 반쪽짜리입니다. 서버 디스크가 깨지거나 계정이 잠기면 원본과 백업을 같이 잃습니다.
SSL도 무료 인증서로 충분한 경우가 많습니다. 일반 홈페이지, 블로그, 문의 폼 정도라면 유료 SSL을 꼭 살 필요는 없습니다. 다만 자동 갱신이 되는지, 만료 전에 알림이 오는지, 중간 인증서 설정이 정상인지가 더 중요합니다. SSL 장애는 사이트가 완전히 죽은 것처럼 보이기 때문에 생각보다 민원이 큽니다.
이전 작업은 파일 복사가 아니라 순서 싸움입니다
홈페이지 이전을 쉽게 보는 분들이 많습니다. 파일 내려받고 새 서버에 올리면 끝이라고 생각하죠. 근데 실무에서는 순서가 틀어지면 꽤 피곤해집니다. 특히 도메인 DNS 변경, 데이터베이스 덤프, 업로드 경로, 문자셋, PHP 버전이 얽히면 화면은 뜨는데 로그인만 안 되는 상황이 나옵니다.
이전 전에는 현재 서버 정보를 먼저 적어둡니다. PHP 버전, 데이터베이스 버전, 웹서버 종류, 디스크 사용량, 도메인 DNS 관리 위치, SSL 발급 방식, cron 작업 여부 정도는 확인해야 합니다. 워드프레스라면 플러그인 목록과 업로드 폴더 용량도 봅니다. 이걸 안 보고 옮기면 새 서버에서 오류가 났을 때 원인을 찾느라 시간을 씁니다.
DNS TTL은 이전 하루 전쯤 낮춰두는 게 좋습니다. 3600초나 300초 정도로 낮춰두면 실제 전환 시 대기 시간이 줄어듭니다. 이전 당일에는 먼저 새 서버에 파일과 DB를 복원하고, 임시 도메인이나 hosts 설정으로 화면을 확인한 뒤 DNS를 바꾸는 순서가 안정적입니다. 운영 중 주문이나 게시글이 들어오는 사이트라면 최종 덤프 시점도 따로 잡아야 합니다.
- 이전 전: 서버 버전, 용량, DNS 위치, SSL 방식 확인
- 이전 중: 새 서버에서 먼저 복원 후 화면 점검
- 전환 직전: DB 변경이 생기는 게시판·주문 기능 잠시 제한
- 전환 후: 로그인, 문의 폼, 이미지, 결제, 관리자 업로드 확인
홈페이지 장애가 났을 때 확인하는 순서
장애가 나면 대부분 서버부터 재부팅하려고 합니다. 솔직히 재부팅으로 풀리는 경우도 있습니다. 하지만 원인을 모르고 재부팅만 반복하면 다음에도 같은 시간에 또 죽습니다. 저는 먼저 도메인, SSL, 웹서버, DB, 디스크 순서로 봅니다. 이 순서가 빠릅니다.
사이트가 아예 안 열리면 도메인 만료나 DNS 문제를 먼저 봅니다. 생각보다 도메인 연장 누락이 많습니다. 브라우저에 보안 경고가 뜨면 SSL 만료나 인증서 체인 문제일 가능성이 큽니다. 흰 화면이 뜨면 PHP 오류, 500 오류가 뜨면 웹서버나 애플리케이션 로그, 데이터베이스 연결 오류가 뜨면 DB 계정과 서비스 상태를 봅니다.
관리자 페이지는 열리는데 글 저장이 안 되거나 이미지 업로드가 안 되면 디스크 용량과 파일 권한을 봐야 합니다. 용량이 100% 차면 DB도 멈추고 세션도 깨집니다. 백업 파일이 같은 계정 안에 계속 쌓여서 용량을 다 먹는 경우가 꽤 많습니다. 자동 백업을 켰다고 안심했는데, 그 백업 때문에 홈페이지가 멈추는 상황도 실제로 있습니다.
트래픽 폭증이 원인이라면 로그에 흔적이 남습니다. 특정 이미지나 특정 글만 과하게 호출되는지, 검색봇이 몰렸는지, 공격성 요청이 반복되는지 봐야 합니다. 단순 방문자 증가라면 캐시와 이미지 최적화로 해결되는 경우가 많고, 공격성 요청이라면 차단 규칙이나 웹방화벽 설정이 먼저입니다. 서버 증설은 그다음에 해도 늦지 않습니다.
처음부터 비싼 서버를 쓰지 않아도 됩니다
홈페이지 운영에서 좋은 선택은 큰 서버가 아니라 설명 가능한 서버입니다. 왜 이 요금제를 쓰는지, 어느 정도 트래픽까지 버티는지, 백업은 어디에 있는지, 장애가 나면 무엇부터 볼지 말할 수 있어야 합니다. 이 네 가지가 없으면 비싼 서버를 써도 불안합니다.
처음 만드는 홈페이지라면 작게 시작해도 됩니다. 회사 소개, 상담 신청, 블로그 글 몇 개 정도라면 저가형 웹호스팅으로 충분한 구간이 많습니다. 대신 이미지 용량을 줄이고, 자동 백업을 켜고, SSL 자동 갱신을 확인하고, 관리자 비밀번호와 플러그인 업데이트를 관리해야 합니다. 비용을 아낄 곳과 아끼면 안 되는 곳을 구분하는 게 운영입니다.
제 경험상 홈페이지가 오래 버티는 기준은 서버 스펙표보다 운영 습관에 가깝습니다. 백업을 복원해본 적 있는지, 장애 확인 순서를 적어뒀는지, 만료일을 놓치지 않는지, 필요할 때 사양을 올릴 수 있는 구조인지가 더 큽니다. 서버는 나중에 키울 수 있지만, 잃어버린 데이터와 놓친 만료일은 되돌리기 어렵습니다.
