얼마 전 작은 쇼핑몰을 운영하는 지인이 호스팅을 바꾸겠다고 연락을 줬습니다. 방문자는 하루 800명 정도인데 월 10만 원대 서버를 권유받았다고 하더군요. 로그를 보니 실제 피크 시간 동시접속은 12명 안팎이었습니다. 이런 경우는 비싼 VPS보다 기본 웹호스팅에 캐시와 백업만 제대로 잡아도 충분합니다.
호스팅을 고를 때 많은 분이 월 방문자 수부터 봅니다. 그런데 서버 입장에서는 한 달 방문자보다 지금 동시에 몇 명이 요청을 보내는지가 더 중요합니다. 하루 1만 명이 와도 고르게 퍼지면 버팁니다. 반대로 하루 500명짜리 사이트도 문자 발송, 광고 집행, 방송 노출처럼 특정 10분에 몰리면 쉽게 죽습니다.
호스팅은 월 방문자보다 동시접속으로 봐야 합니다
대략적인 계산은 단순하게 시작하면 됩니다. 하루 방문자 수를 24시간으로 나누면 평균이 나오지만, 실제 사이트는 평균대로 움직이지 않습니다. 보통 피크 시간에는 평균의 5배에서 20배까지 몰립니다. 블로그나 회사 소개 사이트는 5배 정도로 잡아도 되고, 쇼핑몰·예약·이벤트 페이지는 10배 이상으로 보는 편이 안전합니다.
예를 들어 하루 방문자 3,000명인 블로그가 있습니다. 페이지뷰가 방문자당 2회라면 하루 요청 기준 페이지뷰는 6,000회입니다. 이를 시간당 평균으로 나누면 250회 정도지만, 저녁 피크에 10배가 몰리면 시간당 2,500회입니다. 초당으로 보면 0.7페이지 요청 정도라서 정적 캐시가 잘 잡힌 워드프레스라면 저가 웹호스팅도 버틸 수 있습니다.
반대로 상품 상세 페이지마다 외부 API를 부르고, 이미지 원본이 크고, 관리자 페이지에서 엑셀 다운로드까지 자주 돌리는 사이트라면 숫자가 작아도 부담이 큽니다. 호스팅 사양은 방문자 수만 보고 고르면 틀리고, 페이지 생성 비용까지 같이 봐야 합니다.
트래픽 구간별로 적당한 선택지가 다릅니다
처음부터 클라우드 서버를 쓰는 게 항상 좋은 선택은 아닙니다. 운영 경험이 없으면 서버 권한이 넓어진 만큼 사고 지점도 늘어납니다. 웹서버 설정, 방화벽, PHP 버전, 데이터베이스 백업, 인증서 갱신을 직접 챙겨야 합니다. 작은 사이트라면 관리형 웹호스팅이 더 안정적인 경우가 많습니다.
- 하루 방문자 1,000명 이하의 블로그·회사 소개 사이트: 일반 웹호스팅, 무료 SSL, 자동 백업 제공 여부를 먼저 봅니다.
- 하루 방문자 1,000~10,000명 수준의 콘텐츠 사이트: 캐시 플러그인, 이미지 최적화, 트래픽 제한 정책을 같이 확인합니다.
- 동시접속 50명 이상이 자주 나오는 커뮤니티·쇼핑몰: VPS나 클라우드 서버를 검토하되, 데이터베이스 분리보다 먼저 쿼리와 캐시를 봅니다.
- 이벤트성 유입이 있는 사이트: 평소 사양보다 CDN, 정적 페이지 전환, 대기 화면 같은 우회 구조가 더 중요합니다.
저는 새 사이트를 만들 때 월 1만 원 안팎의 웹호스팅으로 시작하는 경우가 많습니다. 단, 조건이 있습니다. 자동 백업이 있고, SSL 적용이 어렵지 않고, PHP와 데이터베이스 버전이 너무 오래되지 않아야 합니다. 싸다고 무조건 좋은 건 아니지만, 작은 사이트에 과한 서버를 붙이는 것도 운영비 낭비입니다.
싼 호스팅을 써도 되는 사이트와 아닌 사이트
저가 호스팅이 잘 맞는 사이트는 구조가 단순합니다. 회사 소개, 포트폴리오, 개인 블로그, 랜딩 페이지, 자료실 정도가 그렇습니다. 이런 사이트는 정적 파일 비중이 높고 로그인 사용자가 많지 않습니다. 이미지 용량만 줄이고 캐시를 켜도 서버가 할 일이 크게 줄어듭니다.
반대로 회원 로그인, 장바구니, 실시간 예약, 게시판 알림, 외부 결제 연동이 많은 사이트는 조금 다르게 봐야 합니다. 캐시하기 어려운 페이지가 많고, 데이터베이스 쓰기 작업도 늘어납니다. 이 구간에서는 CPU 코어 수보다 디스크 I/O, 데이터베이스 응답 시간, 백업 복구 속도가 실제 체감에 더 크게 작용합니다.
호스팅 업체가 말하는 트래픽 용량도 그대로 믿으면 안 됩니다. 월 트래픽 100GB라고 적혀 있어도 초당 처리량, CPU 제한, 프로세스 제한이 따로 걸려 있으면 피크 때 막힐 수 있습니다. 약관에 CPU 과점유 제한이 있으면 평소에는 조용하다가 특정 글이 검색에 걸린 날 계정이 제한될 수도 있습니다.
이전하기 전에 백업과 복구 시간을 먼저 확인합니다
사이트 이전에서 사고가 나는 지점은 대개 파일 복사가 아닙니다. 데이터베이스 문자셋, PHP 버전 차이, 업로드 경로, 캐시 파일, DNS 전파 시간에서 문제가 생깁니다. 특히 오래된 워드프레스나 그누보드 계열은 PHP 버전이 올라가면서 플러그인 오류가 나는 경우가 많습니다.
이전 전에는 최소 세 가지를 확인합니다. 첫째, 파일 전체 백업입니다. 둘째, 데이터베이스 덤프입니다. 셋째, 복구 테스트입니다. 백업 파일이 있다는 것과 복구가 된다는 것은 완전히 다른 이야기입니다. 압축 파일이 깨져 있거나 데이터베이스 용량이 커서 웹 관리자 화면에서 복원이 안 되는 경우도 흔합니다.
- 이전 전날 전체 백업을 받고, 이전 직전 데이터베이스를 한 번 더 받습니다.
- 새 서버에는 먼저 임시 주소나 hosts 설정으로 접속해 화면과 로그인을 확인합니다.
- DNS 변경은 방문자가 적은 시간에 진행하고, 기존 서버는 최소 48시간 유지합니다.
- 메일을 같은 도메인으로 쓰는 경우 MX 설정을 따로 확인합니다.
개인적으로는 백업 주기보다 복구 시간을 더 중요하게 봅니다. 하루 한 번 백업이 있어도 복원에 반나절 걸리면 작은 쇼핑몰에는 치명적입니다. 장애가 났을 때 버튼 한 번으로 특정 시점 복구가 되는지, 아니면 고객센터에 요청해야 하는지 확인해야 합니다.
장애가 났을 때는 순서를 정해놓고 봐야 합니다
사이트가 안 열린다는 연락을 받으면 먼저 서버를 만지고 싶어집니다. 그런데 순서 없이 건드리면 원인을 더 흐립니다. 저는 항상 바깥에서 안쪽으로 봅니다. 도메인 응답, SSL 인증서, 웹서버 응답 코드, 애플리케이션 로그, 데이터베이스 연결 순서입니다.
브라우저에 흰 화면만 나온다면 PHP 오류일 가능성이 있고, 502나 504가 보이면 웹서버와 PHP 처리기 사이가 막혔을 수 있습니다. 데이터베이스 연결 오류라면 DB 계정, 비밀번호, 소켓, 용량 초과를 봅니다. 접속이 아예 안 되면 DNS, 방화벽, 서버 중지 여부부터 보는 게 빠릅니다.
트래픽 폭주로 보이는 장애도 실제로는 로그 파일이 디스크를 다 채운 경우가 많습니다. 디스크 사용률이 100%가 되면 세션 저장, 캐시 생성, 데이터베이스 쓰기가 같이 망가집니다. 그래서 저가 호스팅이든 VPS든 디스크 용량 알림은 꼭 필요합니다.
- 먼저 내 회선 문제가 아닌지 다른 네트워크에서 접속을 확인합니다.
- 도메인과 SSL 만료일을 봅니다.
- 서버 디스크 사용률과 최근 로그 증가량을 확인합니다.
- 최근 수정한 플러그인, 테마, 배포 파일을 되짚습니다.
- 복구 전에는 현재 상태를 한 번 더 백업합니다.
호스팅은 비싼 요금제를 고르는 일이 아니라 내 사이트의 병목을 계산하는 일에 가깝습니다. 작은 사이트는 작은 사양으로도 오래 갑니다. 대신 백업, 복구, 로그 확인, DNS 변경 절차를 가볍게 보면 안 됩니다. 운영을 오래 해보면 서버는 대개 갑자기 배신하지 않습니다. 사람이 확인하지 않은 설정이 조용히 쌓이다가 어느 날 드러날 뿐입니다.
