얼마 전 작은 쇼핑몰을 운영하는 지인이 월 2만 원짜리 웹호스팅에서 바로 고사양 클라우드 서버로 옮기려 한다고 연락을 줬습니다. 접속자가 늘어서 불안하다는 이유였는데, 로그를 보니 하루 방문자는 1,800명 정도였고 피크 시간 동시 접속은 15명 안팎이었습니다. 이 정도면 서버가 부족해서 죽을 구간이 아닙니다. 실제 문제는 백업 플러그인이 낮 시간에 전체 압축을 돌리고, 이미지 원본을 그대로 올려 디스크 입출력이 튀는 쪽에 가까웠습니다.
웹호스팅은 싸다고 무조건 약한 것도 아니고, VPS나 클라우드 서버라고 항상 안정적인 것도 아닙니다. 운영자가 봐야 할 것은 이름이 아니라 계산입니다. 페이지가 얼마나 무거운지, PHP나 Node 같은 실행 환경이 얼마나 오래 붙잡히는지, DB 쿼리가 얼마나 느린지, 장애가 났을 때 되돌릴 백업이 있는지가 먼저입니다.
웹호스팅으로 충분한 구간부터 잡는 방법
개인 블로그, 회사 소개 사이트, 소규모 워드프레스, 랜딩 페이지는 대부분 저가 웹호스팅으로 시작해도 됩니다. 하루 방문자 1,000명 이하이고 글과 이미지 위주의 사이트라면 월 몇 천 원대 상품에서도 버팁니다. 캐시가 켜져 있고 이미지 크기만 적당히 줄여도 체감 차이가 큽니다.
제가 보는 첫 기준은 동시 접속입니다. 방문자 수는 크게 보여도 실제로 같은 순간에 페이지를 여는 사람은 적습니다. 하루 3,000명이 들어와도 피크가 30분에 몰리지 않으면 동시 접속은 10명 아래일 수 있습니다. 반대로 이벤트 페이지처럼 5분 안에 300명이 몰리면 하루 방문자가 적어도 서버는 바로 흔들립니다.
- 개인 블로그: 웹호스팅 기본형, 캐시 사용, 이미지 압축
- 소규모 회사 사이트: 웹호스팅 중간형, SSL 자동 갱신 확인, 주 1회 백업
- 워드프레스 글 중심 사이트: PHP 메모리 256MB 이상, DB 용량 여유 확인
- 예약·결제·회원 기능 사이트: 웹호스팅보다 VPS 검토
웹호스팅에서 흔히 놓치는 제한은 CPU가 아니라 프로세스 수와 초당 요청 제한입니다. 상품 설명에는 저장 공간과 트래픽이 크게 보이지만, 실제 장애는 PHP 프로세스가 꽉 차거나 DB 접속 수가 막혀서 납니다. 그래서 트래픽 무제한이라는 말만 보고 고르면 곤란합니다. 무제한은 보통 회선 사용량 표현이지, 무한한 처리 성능이라는 뜻이 아닙니다.
VPS로 넘어가야 하는 신호
VPS는 자유도가 생기는 대신 관리 책임도 같이 옵니다. 웹호스팅에서는 업체가 웹서버, PHP, DB, 보안 패치 일부를 대신 잡아줍니다. VPS는 방화벽, 패키지 업데이트, 로그 관리, 백업, SSL 갱신까지 직접 챙겨야 합니다. 서버를 만질 사람이 없다면 VPS가 더 위험할 때도 많습니다.
그래도 넘어가야 하는 구간은 분명합니다. 관리자 페이지가 느려지고, 캐시를 켜도 로그인 사용자 요청이 많고, 상품 검색이나 게시판 검색처럼 DB를 많이 쓰는 기능이 있다면 분리된 자원이 필요합니다. 대략 1vCPU, 메모리 1GB VPS는 가벼운 사이트 한두 개를 돌리는 출발점입니다. 워드프레스에 플러그인이 많거나 이미지 리사이징이 잦다면 2GB부터 보는 편이 낫습니다.
제가 현장에서 쓰는 간단한 계산
정적 페이지나 캐시된 페이지는 요청당 자원이 작습니다. 문제는 캐시가 안 되는 요청입니다. 예를 들어 PHP 요청 하나가 평균 300ms 걸리고 동시에 처리 가능한 PHP 워커가 5개라면, 이론상 초당 15건 정도가 상한입니다. 그런데 DB 쿼리가 느려져 요청 시간이 1.5초로 늘면 같은 서버가 초당 3건 수준으로 떨어집니다. 서버 사양을 올리기 전에 느린 요청을 줄이는 게 먼저인 이유입니다.
- 응답 시간이 1초를 자주 넘으면 서버 사양보다 쿼리와 플러그인 확인
- 메모리 사용률이 80% 이상으로 오래 유지되면 VPS 증설 검토
- 스왑 사용이 반복되면 메모리 부족으로 판단
- 디스크 사용률이 85%를 넘으면 백업 실패와 로그 폭주 위험 증가
- DB 접속 오류가 반복되면 동시 접속 제한이나 느린 쿼리 확인
여기서 많이 하는 실수가 있습니다. CPU가 100%였다는 이유만으로 바로 상위 요금제를 결제하는 겁니다. 배치 작업, 백업 압축, 썸네일 생성, 크롤러 유입 때문에 잠깐 튄 것인지 먼저 봐야 합니다. 5분 피크 하나 때문에 매달 비용을 두 배로 올리는 건 운영비가 아깝습니다.
백업 없는 웹호스팅은 싼 게 아닙니다
사이트가 죽는 원인 중 체감상 제일 무서운 건 트래픽보다 복구 불가입니다. 트래픽 장애는 원인을 찾으면 다시 올릴 수 있습니다. 그런데 백업이 없거나 백업 파일이 깨져 있으면 이야기가 달라집니다. 특히 웹호스팅에서 자동 백업을 제공한다고 해도 복원 비용, 보관 기간, DB 포함 여부를 따로 확인해야 합니다.
운영 기준은 단순하게 잡는 게 좋습니다. 파일과 DB를 같이 백업하고, 같은 서버 안에만 두지 않는 것. 매일 바뀌는 쇼핑몰이나 커뮤니티는 하루 1회로 부족할 수 있습니다. 글을 가끔 올리는 블로그는 주 1회도 충분합니다. 중요한 건 주기가 아니라 복원 확인입니다. 백업 파일이 있다는 것과 실제로 복원된다는 것은 다릅니다.
- 블로그: 주 1회 전체 백업, 글 작성 후 수동 백업
- 회사 사이트: 주 1회 파일·DB 백업, 변경 전 별도 보관
- 쇼핑몰: DB 매일 백업, 주문 많은 시간대 피해서 실행
- 회원 서비스: 백업 암호화, 접근 권한 분리, 복원 리허설
저는 이전 작업을 할 때 항상 세 가지를 먼저 받습니다. 현재 파일 전체, DB 덤프, DNS 설정 화면 캡처입니다. 이 세 가지가 있으면 웬만한 이전은 되돌릴 길이 있습니다. 반대로 관리자 비밀번호만 있고 백업이 없으면 작업 난도가 확 올라갑니다. 업체 이전 대행도 결국 이 자료가 있어야 안전하게 움직입니다.
장애가 났을 때 확인하는 순서
장애가 나면 먼저 요금제를 올리고 싶어집니다. 근데 순서를 지켜야 비용을 덜 씁니다. 첫 번째는 DNS입니다. 네임서버가 바뀌었는지, A 레코드가 예전 서버를 보고 있는지, TTL 때문에 반영이 늦는지 확인합니다. 두 번째는 SSL입니다. 인증서 만료나 중간 인증서 문제만으로도 사용자는 사이트가 죽었다고 느낍니다.
세 번째는 웹서버 로그입니다. 500 오류가 많으면 애플리케이션 문제일 가능성이 높고, 502나 504가 많으면 PHP-FPM, 프록시, 백엔드 지연을 봅니다. 403은 권한이나 보안 규칙, 404는 배포 경로나 rewrite 설정이 자주 원인입니다. 로그 없이 화면만 보면 대부분 추측이 됩니다.
운영자가 바로 볼 체크리스트
- 도메인 만료 여부와 네임서버 변경 이력
- SSL 인증서 만료일과 자동 갱신 실패 여부
- 디스크 용량, inode, 로그 파일 폭증
- DB 접속 가능 여부와 느린 쿼리
- 최근 설치한 플러그인, 테마, 배포 파일
- 백업 작업 시간과 서버 부하가 겹쳤는지
웹호스팅 장애 중에는 디스크가 꽉 차서 세션 파일이나 캐시 파일을 못 쓰는 경우도 많습니다. 화면에는 DB 오류처럼 보이는데 실제 원인은 로그 파일이 수십 GB까지 커진 상황일 때가 있습니다. 그래서 용량 모니터링은 고급 기능이 아니라 기본 운영입니다.
요금제는 크게 시작하지 않아도 됩니다
처음부터 큰 서버를 쓰면 마음은 편합니다. 하지만 운영비는 매달 빠져나가고, 관리할 항목도 늘어납니다. 작은 사이트는 웹호스팅에서 시작해서 병목이 보이면 VPS로 옮기는 흐름이 자연스럽습니다. 다만 이전 가능한 구조로 만들어 두어야 합니다. 파일 경로를 과하게 고정하지 않고, DB 백업을 받을 수 있고, DNS 권한을 직접 갖고 있으면 이동이 어렵지 않습니다.
제 기준에서는 월 방문자 1만 명 이하의 정보성 사이트라면 먼저 웹호스팅과 캐시 조합을 봅니다. 이미지가 많으면 CDN이나 이미지 최적화부터 적용합니다. 회원 기능이 많고 관리자 작업이 잦으면 VPS를 검토합니다. 주문, 예약, 강의 수강처럼 돈과 데이터가 오가는 서비스는 백업과 모니터링 비용까지 포함해서 계산합니다.
서버 선택은 비싼 쪽을 고르는 일이 아니라 실패할 지점을 줄이는 일에 가깝습니다. 트래픽은 숫자로 계산할 수 있고, 장애는 순서대로 좁힐 수 있습니다. 웹호스팅으로 충분한 구간에서는 가볍게 운영하고, 넘어갈 신호가 보일 때 서버를 키우는 편이 오래 봤을 때 비용도 덜 들고 사고도 적었습니다.
