얼마 전 작은 쇼핑몰 이전을 봐줬는데, 월 방문자는 2만 명 정도인데도 클라우드 서버를 두 대 쓰고 있었습니다. 막상 장애 원인을 보니 서버 성능이 아니라 PHP 버전, 디스크 용량 경고, 자동 백업 누락이 겹친 문제였습니다. 웹호스팅은 무조건 비싼 쪽으로 가면 편할 것 같지만, 실제 운영에서는 필요한 사양을 계산하고 복구 절차를 잡아두는 쪽이 훨씬 안전합니다.
웹호스팅은 트래픽보다 사용 패턴부터 봅니다
요금제를 볼 때 가장 먼저 보는 숫자는 월 방문자보다 페이지뷰, 페이지 크기, 동시접속입니다. 방문자 1만 명이어도 글만 읽고 나가는 블로그와 이미지가 많은 쇼핑몰은 필요한 자원이 다릅니다. 평균 페이지 크기가 2MB이고 월 페이지뷰가 3만이면 전송량은 대략 60GB입니다. 여기에 관리자 업로드, 검색봇, 이미지 원본 요청까지 붙으니 20~30% 정도 여유를 둡니다.
동시접속은 더 현실적으로 봐야 합니다. 하루 1만 페이지뷰라도 24시간 고르게 들어오면 부담이 작습니다. 그런데 광고 집행이나 방송 노출처럼 10분 안에 몰리면 상황이 달라집니다. 일반 블로그, 회사 소개 사이트, 예약 없는 소규모 쇼핑몰은 대부분 저가 웹호스팅으로도 충분한 구간이 많습니다. 반대로 로그인, 장바구니, 결제, 검색이 많은 사이트는 같은 방문자 수라도 서버 부하가 빨리 올라갑니다.
- 개인 블로그: 월 1만~5만 페이지뷰면 저가 웹호스팅으로 시작해도 무난한 경우가 많습니다.
- 회사 소개 사이트: 이미지 최적화만 되어 있으면 트래픽보다 도메인, SSL, 백업 관리가 더 중요합니다.
- 소규모 쇼핑몰: 상품 이미지와 결제 모듈 때문에 PHP 메모리, DB 제한, 백업 주기를 꼭 봐야 합니다.
- 예약·강의·커뮤니티: 동시 로그인과 DB 쓰기 작업이 많아 VPS나 관리형 클라우드를 검토할 수 있습니다.
요금제 표에서 꼭 봐야 할 항목
웹호스팅 업체의 표에는 용량, 트래픽, DB, 이메일, SSL 같은 항목이 나옵니다. 여기서 디스크 용량만 보고 고르면 사고가 납니다. 이미지 5GB를 올리는 사이트보다 로그와 백업이 쌓이는 사이트가 더 빨리 멈추기도 합니다. 디스크가 90%를 넘으면 업로드 실패, 세션 오류, DB 쓰기 실패가 같이 터질 수 있습니다.
CPU와 메모리는 표시 방식이 제각각입니다
공유 웹호스팅은 CPU 코어 수를 명확히 주지 않는 경우가 많습니다. 대신 프로세스 제한, 동시 접속 제한, PHP 메모리 제한, 실행 시간 제한으로 관리합니다. 워드프레스 기준으로 플러그인이 많고 페이지 빌더를 쓰면 PHP 메모리 128MB는 빠듯할 수 있습니다. 관리 화면이 느리고 저장 중 오류가 난다면 트래픽보다 메모리 제한을 먼저 의심합니다.
DB 용량과 백업 보관일을 같이 봅니다
DB 용량 500MB는 작은 블로그에는 넉넉하지만, 주문 이력과 로그가 쌓이는 쇼핑몰에는 생각보다 금방 찹니다. 자동 백업이 있어도 보관일이 3일인지 7일인지, 사용자가 직접 내려받을 수 있는지, 복원 요청에 비용이 붙는지 확인해야 합니다. 운영 경험상 장애 때 가장 비싼 건 서버 요금이 아니라 복원할 데이터가 없는 상황입니다.
무료·저가 웹호스팅이 충분한 구간
솔직히 처음부터 VPS나 클라우드 서버를 잡을 필요가 없는 사이트가 많습니다. 회사 소개, 포트폴리오, 지역 매장 안내, 글 위주의 블로그는 월 몇 천 원대 웹호스팅으로 시작해도 됩니다. SSL 자동 발급, PHP 버전 선택, 기본 백업, FTP 또는 파일 관리자, DB 접속 정보만 안정적으로 제공되면 출발선으로는 충분합니다.
다만 무료 호스팅은 운영 사이트에는 조심스럽습니다. 광고 삽입, 느린 응답, 제한된 백업, 갑작스러운 정책 변경이 있을 수 있습니다. 테스트나 임시 페이지에는 괜찮지만, 검색 유입을 쌓는 블로그라면 최소한 유료 저가형이 낫습니다. 비용을 아끼려면 서버 등급을 낮추는 것보다 이미지 용량을 줄이고 캐시를 켜는 편이 효과가 큽니다.
- 이미지는 업로드 전에 긴 변 기준 1600px 안팎으로 줄입니다.
- 동영상은 직접 올리지 말고 외부 플랫폼 임베드로 처리합니다.
- 캐시 플러그인은 하나만 쓰고, 기능이 겹치는 플러그인은 줄입니다.
- 관리자 계정, DB, 파일 백업을 따로 내려받는 날짜를 정해둡니다.
이전할 때는 DNS보다 백업 검증이 먼저입니다
사이트 이전에서 많이 터지는 지점은 DNS 변경이 아닙니다. 백업 파일이 깨졌거나 DB 문자셋이 맞지 않거나 업로드 경로가 바뀌는 쪽입니다. 이전 전에는 파일 전체, DB 덤프, 환경 정보 세 가지를 확보합니다. PHP 버전, DB 버전, 문자셋, 업로드 제한, SSL 상태까지 적어두면 복구 속도가 빨라집니다.
운영 중인 사이트라면 바로 네임서버를 바꾸지 말고 임시 주소나 hosts 설정으로 새 서버에서 먼저 확인합니다. 로그인, 글쓰기, 이미지 업로드, 결제, 문의 폼, 검색 기능을 눌러봐야 합니다. 첫 화면만 뜬다고 이전이 끝난 게 아닙니다. 특히 워드프레스는 고유주소 설정, 캐시 경로, 플러그인 라이선스, 보안 플러그인 차단 때문에 관리자 화면에서만 문제가 보이는 경우가 있습니다.
장애가 나면 이 순서로 봅니다
사이트가 안 뜨면 먼저 증상을 나눕니다. 전체가 안 뜨는지, 관리자만 안 되는지, 특정 게시글만 오류인지에 따라 확인 순서가 달라집니다. 급할수록 요금제 업그레이드 버튼부터 누르기 쉬운데, 실제로는 디스크 초과나 SSL 만료처럼 간단한 원인이 많습니다.
- 도메인 만료와 DNS 변경 이력을 확인합니다.
- SSL 인증서 상태와 만료일을 확인합니다.
- 호스팅 관리자에서 디스크, 트래픽, DB 용량 초과 여부를 봅니다.
- 최근 수정한 플러그인, 테마, PHP 버전을 되돌릴 수 있는지 확인합니다.
- 에러 로그에서 500, 503, 메모리 부족, 권한 오류 문구를 찾습니다.
웹호스팅은 큰 장비를 고르는 게임이 아닙니다. 내 사이트가 언제, 어떤 방식으로 자원을 쓰는지 보고 그보다 조금 여유 있는 상품을 고르면 됩니다. 저는 처음 운영하는 사이트라면 저가형으로 시작하되, 백업을 직접 확인하고 이전 절차를 문서로 남기는 쪽을 권합니다. 서버는 돈을 쓰면 올릴 수 있지만, 사라진 데이터는 돈을 써도 돌아오지 않는 경우가 있습니다.
