얼마 전 작은 쇼핑몰 이전 작업을 봤는데, 방문자는 하루 800명 정도인데도 8코어 VPS를 쓰고 있었습니다. 느린 원인은 서버 사양이 아니라 이미지 용량, 백업 스크립트, PHP 설정이었습니다. 호스팅 비용은 성능 문제를 돈으로 덮으려고 할 때 빠르게 불어납니다. 반대로 필요한 숫자를 먼저 잡으면 월 몇 천 원짜리 웹호스팅으로도 충분한 구간이 꽤 많습니다.
호스팅은 트래픽보다 동시접속부터 봅니다
많이들 월 방문자 수부터 묻습니다. 물론 중요합니다. 그런데 서버가 실제로 버티는 기준은 순간 동시접속과 요청 처리 시간입니다. 하루 방문자 1만 명이어도 하루 종일 고르게 들어오면 부담이 작고, 10분 동안 몰리면 저가형 VPS도 바로 숨이 찹니다.
대략 계산은 이렇게 잡습니다. 페이지 하나가 평균 1초 안에 처리되고, 피크 시간에 동시에 20명이 본다면 웹서버 입장에서는 초당 20개 안팎의 요청을 상대합니다. 이미지, CSS, JS는 캐시와 CDN으로 빠지게 만들면 실제 PHP나 Node, Python 애플리케이션이 처리해야 하는 요청은 훨씬 줄어듭니다.
- 개인 블로그, 회사 소개 사이트: 월 1만 방문 이하라면 일반 웹호스팅도 충분한 경우가 많습니다.
- 워드프레스 블로그: 글과 이미지 위주면 메모리 1GB VPS보다 관리형 웹호스팅이 더 편할 수 있습니다.
- 쇼핑몰, 예약, 게시판: 동시접속 30명 이상이면 DB 부하와 세션 처리를 따로 봐야 합니다.
- 이벤트 페이지: 평소 트래픽보다 오픈 직후 30분 피크를 기준으로 잡아야 합니다.
저가형 호스팅이 부족한 순간
저가형이 나쁘다는 뜻은 아닙니다. 문제는 어디까지 버티는지 모르고 쓰는 겁니다. 공유 웹호스팅은 CPU와 메모리를 여러 계정이 같이 씁니다. 그래서 내 사이트 코드가 가벼워도 같은 장비의 다른 계정 영향으로 느려질 수 있습니다. 대신 보안 패치, 웹서버 설정, 기본 백업이 서비스에 포함되는 경우가 많아 운영 부담이 작습니다.
VPS는 자유도가 높습니다. nginx, Apache, PHP-FPM, DB 설정을 직접 만질 수 있고, 필요한 모듈도 설치할 수 있습니다. 그런데 그 자유도는 책임도 같이 옵니다. 방화벽, 계정 권한, 자동 업데이트, 로그 로테이션, 백업 복구 테스트까지 운영자가 챙겨야 합니다. 서버를 잘 모르면 월 5천 원 VPS보다 월 1만 원 관리형 호스팅이 실제로는 더 쌉니다.
사양을 숫자로 바꾸는 기준
CPU는 요청 처리량, 메모리는 동시 실행 프로세스와 DB 캐시, 디스크는 용량보다 IOPS가 중요합니다. 워드프레스 기준으로 플러그인이 적고 캐시가 잘 먹으면 1코어 1GB도 운영됩니다. 반대로 빌더 플러그인, 통계 플러그인, 검색 플러그인이 많이 붙으면 방문자 수가 적어도 2GB 메모리가 먼저 필요해집니다.
- 정적 사이트: CDN을 쓰면 서버 사양 영향이 작습니다.
- 워드프레스: 페이지 캐시 적용 여부가 요금제보다 먼저입니다.
- 이미지 많은 사이트: 원본 업로드 제한, 썸네일 생성, WebP 변환이 체감 속도를 좌우합니다.
- DB 쓰기 많은 서비스: CPU보다 디스크 지연과 슬로우 쿼리를 먼저 봅니다.
이전과 백업은 요금제보다 먼저 설계합니다
사이트 장애의 상당수는 트래픽 폭증보다 이전 작업에서 납니다. 파일은 옮겼는데 DB 문자셋이 달라서 글자가 깨지고, 도메인 DNS TTL을 줄이지 않아 반나절 동안 접속자가 양쪽 서버로 갈라지고, SSL 인증서 갱신을 놓쳐 브라우저 경고가 뜹니다. 이런 건 비싼 서버로 옮겨도 그대로 터집니다.
이전 전에는 최소 세 가지를 확인합니다. 첫째, 현재 서버의 웹 루트와 업로드 경로입니다. 둘째, DB 이름, 계정, 문자셋, 테이블 용량입니다. 셋째, 크론 작업과 메일 발송 설정입니다. 특히 예약 발송, 주문 알림, 백업 스크립트는 파일과 DB만 옮긴다고 자동으로 따라오지 않습니다.
- 이전 48시간 전: DNS TTL을 짧게 줄입니다.
- 이전 직전: 파일과 DB를 같은 시점으로 백업합니다.
- 새 서버 점검: 임시 접속으로 로그인, 글쓰기, 결제, 메일 발송을 확인합니다.
- 전환 후: 기존 서버를 최소 3일은 끄지 않습니다.
백업은 보관보다 복구가 더 중요합니다. 백업 파일이 있어도 풀어본 적이 없으면 없는 것과 비슷합니다. 운영 중인 사이트라면 하루 1회 DB 백업, 주 1회 파일 백업 정도가 기본선입니다. 주문이나 예약 데이터가 생기는 사이트는 DB 백업 주기를 더 짧게 잡아야 합니다. 백업 위치도 같은 서버 한 곳에만 두면 디스크 장애 때 같이 사라집니다.
장애가 났을 때 보는 순서
사이트가 안 열리면 많은 분들이 바로 호스팅 업체에 문의합니다. 업체 문의도 필요하지만, 먼저 증상을 나눠야 시간이 줄어듭니다. 접속 자체가 안 되는지, 첫 화면만 느린지, 로그인 후에만 오류가 나는지에 따라 원인이 완전히 다릅니다.
운영자가 바로 볼 수 있는 항목
- 도메인 만료 여부와 DNS 변경 이력
- SSL 인증서 만료일
- 디스크 사용량, 특히 로그와 백업 파일
- DB 접속 가능 여부와 슬로우 쿼리
- 최근 설치한 플러그인, 테마, 배포 코드
디스크 100퍼센트는 흔한 장애 원인입니다. 접속자가 많지 않아도 로그가 계속 쌓이거나 백업 파일이 매일 누적되면 DB가 쓰기를 못 해서 사이트가 멈춥니다. 이때 서버를 업그레이드하면 잠깐 살아날 수는 있지만, 로그 로테이션과 백업 보관 정책을 잡지 않으면 같은 문제가 다시 납니다.
처음 고를 때는 작게 시작해도 됩니다
호스팅은 처음부터 크게 잡는 것보다 옮길 수 있게 만드는 편이 낫습니다. 도메인 관리 계정, SSL 발급 방식, 백업 파일, DB 덤프 절차만 갖춰져 있으면 저가형에서 VPS로 옮기는 일은 어렵지 않습니다. 반대로 업체 전용 빌더에 모든 데이터를 넣고 내보내기 기능이 약하면, 트래픽이 늘었을 때 선택지가 줄어듭니다.
제가 보통 권하는 기준은 단순합니다. 회사 소개, 포트폴리오, 작은 블로그는 저가 웹호스팅이나 정적 호스팅부터 시작합니다. 워드프레스는 캐시 설정을 전제로 관리형 상품을 먼저 봅니다. 쇼핑몰이나 예약 서비스처럼 데이터가 돈과 바로 연결되는 사이트는 백업, DB 성능, 장애 대응 시간을 요금표보다 위에 둡니다.
서버 비용을 아끼는 건 무조건 싼 상품을 고르는 일이 아닙니다. 필요 없는 사양을 빼고, 사고가 날 지점을 미리 줄이는 일에 가깝습니다. 호스팅은 빠른 서버를 사는 문제가 아니라, 내 사이트가 어느 순간에 왜 느려지고 어디까지 버틸지 숫자로 알고 운영하는 문제라고 봅니다.
