얼마 전 작은 쇼핑몰 이전을 봐줬는데, 하루 방문자 2천 명 정도인 사이트에 클라우드 서버 4코어 상품을 쓰고 있었습니다. 실제로는 웹호스팅 저가형에 캐시만 제대로 잡아도 충분한 규모였습니다. 서버가 느렸던 이유도 사양 부족이 아니라 이미지 원본 업로드, 백업 미설정, PHP 메모리 제한 값이었습니다.
웹호스팅을 고를 때 제일 많이 하는 실수는 월 방문자 수만 보는 겁니다. 운영에서는 트래픽 총량보다 동시에 몇 명이 붙는지, 한 페이지가 서버에서 얼마나 무거운지, 장애가 났을 때 복구할 백업이 있는지가 더 중요합니다.
웹호스팅은 어디까지 버티는가
일반적인 회사 소개 사이트, 병원·학원 안내 사이트, 소규모 블로그는 웹호스팅으로 오래 갑니다. 하루 방문자 500명 이하, 피크 시간 동시접속 5명 안팎이면 굳이 VPS부터 갈 이유가 없습니다. 워드프레스라도 캐시 플러그인과 이미지 리사이즈만 적용하면 저가형 상품에서 버티는 경우가 많습니다.
조금 더 현실적인 기준을 잡아보면 이렇습니다. HTML 위주 사이트는 훨씬 가볍고, 워드프레스나 게시판은 플러그인과 쿼리 수에 따라 차이가 큽니다.
- 하루 방문자 300명 이하: 기본 웹호스팅으로 충분한 경우가 많음
- 하루 방문자 1천 명 전후: 캐시, 이미지 최적화, 백업 정책을 먼저 확인
- 동시접속 20명 이상 반복: VPS나 클라우드 서버 검토
- 주문·예약·로그인 트래픽이 많음: 단순 방문자 수보다 DB 부하를 먼저 봄
사실 사이트가 죽는 시점은 방문자 수가 예쁘게 늘 때보다 특정 시간에 몰릴 때입니다. 광고를 태웠거나, 문자 발송을 했거나, 입시·이벤트처럼 정해진 시간에 사람이 몰리면 저가형 웹호스팅의 CPU 제한에 먼저 걸립니다.
요금제보다 먼저 계산할 값
저는 새 사이트를 받을 때 대충 세 가지를 봅니다. 평균 페이지 용량, 피크 동시접속, 관리자 작업 패턴입니다. 페이지 하나가 5MB인데 하루 1천 페이지뷰면 전송량만 하루 5GB입니다. 한 달이면 150GB 가까이 됩니다. 반대로 페이지가 800KB면 같은 방문자라도 부담이 훨씬 적습니다.
동시접속은 더 중요합니다. 하루 2천 명 방문이라도 12시간 동안 고르게 오면 부담이 작습니다. 그런데 점심시간 10분에 300명이 몰리면 얘기가 달라집니다. 웹호스팅 업체들이 CPU 사용률, 프로세스 수, DB 접속 수를 제한하는 이유가 여기에 있습니다.
간단한 산식
대략 이렇게 계산하면 됩니다. 월 페이지뷰에 평균 페이지 용량을 곱하면 필요한 전송량이 나옵니다. 여기에 이미지 캐시 실패, 관리자 업로드, 검색봇 접근을 생각해서 30% 정도 여유를 둡니다.
- 월 3만 페이지뷰 × 평균 1MB = 월 30GB 전송량
- 월 10만 페이지뷰 × 평균 1.5MB = 월 150GB 전송량
- 월 30만 페이지뷰 이상이면 캐시 구조와 서버 분리를 같이 검토
여기서 중요한 건 비싼 서버가 아니라 가벼운 페이지입니다. 이미지 하나를 4MB로 올려놓고 서버만 올리면 비용은 계속 늘어납니다. 썸네일 생성, WebP 변환, 브라우저 캐시 설정이 먼저입니다.
웹호스팅에서 VPS로 넘어갈 신호
웹호스팅은 편합니다. 보안 패치, 메일, PHP 설정, DB 생성 같은 기본 작업을 업체 관리 화면에서 처리할 수 있습니다. 대신 자유도가 낮고, 장애 원인을 깊게 추적하기 어렵습니다. 서버 로그 접근이 제한되는 곳도 많습니다.
다음 상황이면 VPS나 클라우드 서버를 검토할 만합니다. 다만 이때도 무조건 큰 사양으로 시작할 필요는 없습니다. 1코어 1GB 또는 2GB 메모리로 시작해서 모니터링을 붙이는 쪽이 낫습니다.
- CPU 제한으로 503 오류가 반복됨
- DB 접속 수 제한에 자주 걸림
- 예약, 결제, 회원 기능 때문에 피크 부하가 뚜렷함
- 서버 로그와 웹 방화벽 정책을 직접 다뤄야 함
- 크론, 큐, Redis 같은 별도 프로세스가 필요함
근데 VPS는 직접 운영 책임이 따라옵니다. 보안 업데이트, SSH 접근 제한, 방화벽, 백업, 장애 알림을 직접 챙겨야 합니다. 이걸 안 할 거면 웹호스팅이 더 안전할 수 있습니다. 싼 서버를 직접 운영하다가 백업 없이 날리는 사고를 꽤 많이 봤습니다.
이전과 백업에서 사고가 난다
웹호스팅 이전은 파일만 옮기면 끝난다고 생각하기 쉽습니다. 실제로는 DB 문자셋, PHP 버전, 업로드 경로, SSL 인증서, 도메인 DNS 전파 시간이 같이 걸립니다. 특히 오래된 사이트는 PHP 버전 차이로 관리자 화면이 바로 깨질 수 있습니다.
이전 전에는 최소한 다음 항목을 확인합니다. 운영 중인 사이트라면 새 서버에 먼저 복사하고, 임시 주소나 hosts 설정으로 화면을 확인한 뒤 DNS를 바꾸는 방식이 안전합니다.
- 파일 전체 백업과 DB 덤프를 같은 날짜로 맞춤
- PHP 버전, 확장 모듈, 업로드 용량 제한 확인
- DB 문자셋과 테이블 손상 여부 확인
- SSL 인증서 발급 가능 여부 확인
- DNS TTL을 이전 하루 전 낮춰둠
백업은 있어 보이는 것과 복구 가능한 것이 다릅니다. 압축 파일만 쌓아두고 복구 테스트를 한 번도 안 하면 사고 때 거의 도움이 안 됩니다. 월 1회라도 다른 위치에 복원해보면 백업 정책의 빈틈이 바로 보입니다.
장애가 났을 때 보는 순서
사이트가 안 뜨면 먼저 서버를 키우고 싶어집니다. 하지만 순서를 틀리면 돈만 쓰고 원인은 그대로 남습니다. 저는 보통 DNS, SSL, 웹서버, PHP, DB, 디스크 순서로 봅니다.
- 도메인이 맞는 IP를 가리키는지 확인
- SSL 인증서 만료나 혼합 콘텐츠 문제가 있는지 확인
- 웹서버 오류 코드가 403, 404, 500, 502, 503 중 무엇인지 확인
- PHP 오류 로그에서 플러그인 충돌이나 메모리 초과를 확인
- DB 접속 정보, 접속 수, 느린 쿼리를 확인
- 디스크 용량과 inode 부족 여부를 확인
500 오류는 코드나 PHP 설정 문제인 경우가 많고, 502는 PHP-FPM이나 프록시 연결 문제일 때가 많습니다. 503은 리소스 제한이나 점검 모드일 수 있습니다. 오류 코드만 제대로 읽어도 불필요한 서버 증설을 많이 줄일 수 있습니다.
웹호스팅은 초보자용 상품이 아니라 관리 범위를 줄여주는 상품에 가깝습니다. 방문자 규모가 작고 기능이 단순하면 웹호스팅이 비용과 운영 안정성 면에서 더 나은 선택일 때가 많습니다. 서버 사양은 자존심으로 고르는 게 아니라 숫자로 고르는 겁니다. 저는 아직도 작은 사이트에는 작은 요금제를 먼저 권합니다. 대신 백업과 복구 테스트만큼은 작게 보지 않습니다.
