호스팅 요금제 고르는 방법, 트래픽보다 먼저 계산할 것들

처음부터 큰 요금제를 고를 필요는 없습니다

얼마 전 작은 쇼핑몰 이전 상담을 했는데, 월 방문자 3만 명짜리 사이트에 8코어 VPS를 쓰고 있었습니다. 실제로는 피크 시간 동시 접속이 20명 안팎이었고, 이미지 용량만 줄여도 저가형 웹호스팅이나 1코어 VPS로 충분한 구간이었습니다. 이런 경우가 꽤 많습니다. 사이트가 느리면 대부분 트래픽부터 의심하지만, 운영하다 보면 원인은 설정, 캐시, 백업 방식, DB 쿼리, 이미지 원본 노출 같은 쪽에서 더 자주 나옵니다.

호스팅을 고를 때 제일 먼저 볼 것은 광고 문구가 아니라 실제 사용량입니다. 방문자 수만 보면 판단이 흐려집니다. 하루 1만 명이 와도 페이지가 가볍고 캐시가 잘 잡혀 있으면 작은 서버로 버팁니다. 반대로 하루 500명짜리 사이트도 워드프레스 플러그인이 무겁고 관리자 자동 작업이 꼬이면 CPU가 계속 치솟습니다.

트래픽보다 동시 접속을 먼저 잡습니다

서버 사양을 볼 때 월 트래픽 몇 GB 같은 숫자보다 중요한 것은 피크 시간 동시 접속입니다. 대략적인 계산은 단순하게 시작하면 됩니다. 하루 방문자 3,000명이고 특정 시간대에 20%가 몰린다면, 그 시간에 600명이 들어옵니다. 평균 체류 시간이 2분이면 1시간 기준 동시 접속은 대략 20명 수준입니다. 여기에 봇, 관리자 작업, 결제, 검색 기능을 감안해 2~3배 여유를 봅니다.

개인 블로그, 회사 소개 사이트: 공유 웹호스팅 또는 저가 VPS로 충분한 경우가 많습니다.
워드프레스 블로그 월 방문자 5만 명 이하: 캐시 플러그인과 이미지 최적화가 되어 있으면 1~2코어 VPS로도 운영 가능합니다.
작은 쇼핑몰: 상품 수, 검색, 결제 피크, 관리자 엑셀 작업 때문에 방문자 수보다 DB 부하를 더 봐야 합니다.
커뮤니티나 예약 사이트: 글쓰기, 조회수 증가, 알림, 파일 업로드 때문에 CPU보다 DB와 디스크 I/O가 먼저 막히는 경우가 많습니다.

제가 현장에서 자주 쓰는 기준은 이렇습니다. 정적 페이지나 캐시가 잘 먹는 블로그는 메모리 1~2GB도 출발점으로 괜찮습니다. 워드프레스에 플러그인이 많고 관리자 작업이 잦으면 2~4GB를 봅니다. 트래픽이 많아 보여도 캐시 적중률이 높으면 CPU는 의외로 조용합니다. 반대로 캐시 없이 PHP와 DB가 매 요청마다 일하면 작은 이벤트 하나에도 서버가 밀립니다.

웹호스팅, VPS, 클라우드 서버의 선택 기준

웹호스팅은 관리 부담이 적습니다. 서버 보안 패치, 기본 웹서버 설정, 메일 기능까지 업체가 잡아주는 경우가 많습니다. 다만 커스텀 설정이 제한되고, 같은 장비를 여러 계정이 나눠 쓰기 때문에 옆 계정 영향에서 완전히 자유롭지는 않습니다. 초보자나 회사 소개 사이트라면 이 단순함이 장점입니다.

VPS는 가격 대비 자유도가 좋습니다. 웹서버, PHP 버전, DB 설정, 백업 스크립트를 직접 만질 수 있습니다. 대신 운영 책임도 같이 옵니다. 방화벽을 열어놓고, SSH 비밀번호 로그인을 방치하고, 백업을 같은 서버 안에만 두면 싼 요금제가 문제가 아니라 운영 방식이 문제가 됩니다. 솔직히 서버를 직접 만질 자신이 없으면 VPS가 더 비싼 선택이 될 수 있습니다. 장애가 났을 때 복구 시간을 돈으로 내는 셈입니다.

클라우드 서버는 확장성과 부가 기능이 좋습니다. 로드밸런서, 스냅샷, 오브젝트 스토리지, 모니터링을 붙이기 쉽습니다. 그런데 작은 사이트가 처음부터 클라우드 구성으로 가면 비용 구조를 놓치기 쉽습니다. 서버 요금만 보고 시작했다가 트래픽, 스냅샷, 백업 저장소, 로그, 고정 IP 비용이 붙습니다. 운영자가 매달 청구서를 읽을 수 있어야 클라우드가 편합니다.

사양보다 백업과 복구 절차가 먼저입니다

사이트가 죽었을 때 제일 난감한 말은 “백업은 있을 겁니다”입니다. 백업은 존재 여부가 아니라 복구 가능 여부로 봐야 합니다. DB 덤프 파일이 깨져 있거나, 업로드 파일은 빠져 있거나, 같은 서버 디스크에만 백업이 있으면 장애 상황에서 쓸 수 없습니다. 특히 랜섬웨어나 계정 침해가 발생하면 같은 서버 안의 백업도 같이 지워지는 일이 있습니다.

DB 백업: 최소 하루 1회, 쇼핑몰이나 예약 사이트는 더 짧은 주기를 잡습니다.
파일 백업: 업로드 이미지, 첨부파일, 테마, 설정 파일을 포함해야 합니다.
보관 위치: 운영 서버와 다른 위치에 둬야 합니다.
복구 테스트: 새 계정이나 임시 서버에 실제로 올려봐야 합니다.
보관 기간: 실수 삭제를 대비해 최근 며칠치만이 아니라 2~4주 구간을 남기는 편이 안전합니다.

이전 작업도 비슷합니다. DNS TTL을 낮추고, 파일을 먼저 복사하고, DB를 동기화한 뒤, 최종 전환 직전에 변경분을 한 번 더 맞춥니다. 그리고 기존 서버를 바로 해지하지 않습니다. 최소 3~7일은 남겨두는 게 좋습니다. 메일, 관리자 경로, 결제 모듈, 이미지 경로, 크론 작업은 이전 후에 자주 빠지는 항목입니다.

장애가 나면 이 순서로 봅니다

장애 대응은 감으로 하면 시간이 길어집니다. 저는 보통 바깥에서 안쪽으로 들어갑니다. 먼저 도메인 연결 상태를 보고, DNS가 정상인지 확인합니다. 그다음 웹서버 응답 코드, SSL 인증서 만료 여부, 서버 CPU와 메모리, 디스크 사용량을 봅니다. 디스크 100%는 생각보다 흔합니다. 로그 파일이나 백업 파일이 쌓여서 DB가 쓰기를 못 하는 경우가 있습니다.

사이트가 아예 안 열림: DNS, 서버 전원 상태, 방화벽, 웹서버 실행 여부를 봅니다.
SSL 오류: 인증서 만료, 중간 인증서 누락, 도메인 불일치를 확인합니다.
간헐적으로 느림: CPU보다 DB slow query, PHP 작업 수, 외부 API 지연을 봅니다.
관리자만 느림: 플러그인, 관리자 통계, 자동 백업, 검색 인덱싱을 의심합니다.
용량 초과: 업로드 파일, 로그, 오래된 백업, 캐시 파일부터 확인합니다.

호스팅 업체를 바꿔야 하는 상황도 있습니다. 반복적인 장애에 설명이 없고, 백업 복구가 늦고, PHP나 DB 버전이 너무 오래됐고, SSL 적용이나 DNS 변경이 불편하면 이전을 검토할 만합니다. 반대로 단순히 광고에서 더 빠르다고 해서 옮기는 것은 별 의미가 없습니다. 현재 병목이 DB인지, 이미지인지, 네트워크인지 확인하지 않으면 새 서버에서도 같은 문제가 납니다.

작게 시작하고 측정하면서 키우는 게 낫습니다

호스팅 비용은 보험처럼 많이 낸다고 무조건 안전해지지 않습니다. 작은 사양이라도 캐시, 백업, 모니터링, 보안 설정이 잡혀 있으면 꽤 오래 버팁니다. 저는 새 사이트라면 먼저 싼 구간에서 시작해 로그를 보고 올리는 쪽을 선호합니다. CPU 사용률, 메모리, 디스크 I/O, 응답 시간, 5xx 오류만 꾸준히 봐도 업그레이드 시점을 꽤 정확히 잡을 수 있습니다.

다만 운영자가 시간을 전혀 쓸 수 없다면 관리형 호스팅이 낫습니다. 직접 서버를 만지는 비용은 월 요금에 안 보이지만 분명히 존재합니다. 밤에 장애 알림을 받고 접속할 사람이 없다면, 그 사이트에는 자유도보다 관리 범위가 더 중요합니다. 호스팅은 제일 비싼 상품을 고르는 일이 아니라, 내 사이트가 실제로 쓰는 자원과 내가 감당할 운영 범위를 맞추는 일에 가깝습니다. 그 균형만 잡아도 불필요한 지출과 큰 사고를 꽤 많이 줄일 수 있습니다.