얼마 전 작은 쇼핑몰 이전 상담을 했는데, 하루 방문자 3천 명짜리 사이트에 8코어 VPS와 별도 DB 서버 견적이 올라와 있었습니다. 숫자만 보면 멋있지만 실제 로그를 보니 피크 시간 동시접속은 25명 안팎이었고, 이미지가 큰 상품 상세 몇 개 때문에 느려지는 상황이었습니다. 이런 경우 서버호스팅은 크게 사는 것보다 정확히 계산해서 작게 시작하는 쪽이 낫습니다.
서버가 죽는 이유를 트래픽 하나로 몰아가면 돈을 쓰고도 같은 장애가 반복됩니다. 실제 운영에서는 PHP 메모리 제한, DB 커넥션, 백업 디스크 부족, SSL 갱신 실패, 방화벽 설정 실수 같은 쪽에서 사고가 더 자주 납니다. 그래서 저는 서버호스팅을 고를 때 요금제 이름보다 동시접속, 요청 수, 저장공간 증가량, 백업 복구 시간을 먼저 봅니다.
서버호스팅 사양은 방문자 수가 아니라 동시접속으로 본다
하루 방문자 1만 명이라는 말은 생각보다 느슨한 숫자입니다. 방문자가 24시간 고르게 들어오면 서버 입장에서는 부담이 크지 않습니다. 반대로 행사 문자 발송 직후 10분 동안 몰리면 하루 방문자가 적어도 서버는 버거워집니다. 그래서 먼저 피크 시간 동시접속을 잡아야 합니다.
간단히 계산하면 이렇습니다. 한 사용자가 사이트에 머무는 시간이 평균 3분이고, 피크 1시간 방문자가 600명이라면 평균 동시접속은 30명입니다. 여기에 검색봇, 관리자 작업, 순간 몰림을 감안해서 2~3배 여유를 둡니다. 그러면 설계 기준은 동시접속 60~90명 정도가 됩니다.
- 회사 소개, 병원, 학원, 포트폴리오 사이트: 1코어, 메모리 1~2GB로 시작 가능
- 워드프레스 블로그, 콘텐츠 사이트: 2코어, 메모리 2~4GB 권장
- 소형 쇼핑몰, 예약 페이지: 2~4코어, 메모리 4~8GB부터 검토
- 동시접속 200명 이상, 결제나 검색이 많은 서비스: 웹과 DB 분리 검토
물론 숫자는 코드 품질과 캐시 구조에 따라 달라집니다. 정적 페이지가 대부분이면 아주 싼 서버호스팅으로도 오래 버팁니다. 반대로 플러그인 많은 워드프레스는 방문자 수가 적어도 관리자 화면에서 CPU가 튈 수 있습니다. 서버 사양만 올리기 전에 캐시, 이미지 용량, DB 인덱스부터 보는 게 맞습니다.
웹호스팅, VPS, 클라우드 서버를 나누는 기준
웹호스팅은 관리 부담이 적고 가격이 낮습니다. 트래픽이 적고 서버 설정을 직접 만질 일이 없다면 여전히 좋은 선택입니다. 개인 블로그, 작은 회사 홈페이지, 랜딩 페이지는 월 몇 천 원짜리 상품으로도 충분한 경우가 많습니다. 근데 SSH 접근, 별도 데몬, 커스텀 런타임, 배치 작업이 필요하면 웹호스팅이 답답해집니다.
VPS는 운영 자유도가 높습니다. Nginx, Apache, PHP 버전, Node, Redis, 방화벽, 백업 스크립트를 직접 구성할 수 있습니다. 대신 운영 책임도 같이 옵니다. 보안 업데이트를 미루거나 SSH 포트를 아무렇게나 열어두면 저렴한 VPS가 비싼 사고로 바뀝니다.
클라우드 서버는 확장성과 부가 기능이 장점입니다. 로드밸런서, 스냅샷, 오브젝트 스토리지, 모니터링을 붙이기 쉽습니다. 다만 처음부터 클라우드라는 이유로 비싼 구조를 만들 필요는 없습니다. 월 트래픽이 수십 GB이고 동시접속이 50명 안쪽인 사이트라면 VPS 한 대에 캐시와 백업만 잘 잡아도 안정적으로 운영됩니다.
제가 현장에서 쓰는 선택 기준
- 설정 변경이 거의 없고 트래픽이 작다: 일반 웹호스팅
- 서버 설정을 직접 해야 하고 비용을 낮춰야 한다: VPS
- 일시적 트래픽 급증, 자동 확장, 세밀한 권한 관리가 필요하다: 클라우드 서버
- 장애 시간이 매출에 바로 영향을 준다: 이중화와 외부 백업 우선
요금제 비교는 트래픽과 저장공간 증가량으로 환산한다
서버호스팅 요금제를 볼 때 CPU와 메모리만 비교하면 놓치는 게 많습니다. 이미지가 많은 사이트는 트래픽 비용과 디스크가 먼저 찹니다. 게시판이나 쇼핑몰은 첨부파일, 로그, 백업 파일이 예상보다 빨리 늘어납니다.
예를 들어 한 페이지 평균 용량이 3MB이고 하루 페이지뷰가 2만이면 하루 전송량은 약 60GB입니다. 한 달이면 단순 계산으로 1.8TB입니다. 캐시 적중률과 이미지 최적화를 반영하면 줄어들 수 있지만, 이런 사이트에 월 트래픽 500GB 상품을 넣으면 중간에 제한이 걸릴 가능성이 큽니다.
저장공간도 비슷합니다. 상품 이미지가 하루 500MB씩 늘고, DB 백업이 하루 2GB씩 쌓이면 한 달에 75GB 이상이 필요합니다. 여기에 원본 이미지, 로그, 스냅샷을 같이 두면 100GB 디스크는 금방 답답해집니다. 그래서 저는 운영 디스크와 백업 저장소를 같은 공간으로 보지 않습니다. 같은 서버 안에 백업을 두는 건 삭제 실수나 디스크 장애 앞에서 약합니다.
- 트래픽: 평균 페이지 용량 × 월 페이지뷰로 계산
- 디스크: 현재 용량 + 월 증가량 × 6개월 기준으로 계산
- 백업: DB, 업로드 파일, 설정 파일을 분리해서 보관
- 복구 시간: 백업 존재보다 실제 복원 소요 시간이 더 중요
이전 작업은 백업보다 복구 테스트가 먼저다
서버 이전에서 가장 많이 터지는 지점은 파일 복사가 아닙니다. PHP 확장 모듈이 빠졌거나, DB 문자셋이 달라졌거나, 업로드 경로 권한이 달라져서 조용히 오류가 납니다. SSL 인증서와 리다이렉트 규칙도 자주 빠집니다. 겉으로 첫 화면만 뜬다고 이전이 끝난 게 아닙니다.
이전 전에는 현재 서버의 PHP 버전, 웹서버 종류, DB 버전, 크론 작업, 메일 발송 방식, SSL 상태, 방화벽 규칙을 적어둡니다. 새 서버에서는 임시 주소나 로컬 hosts 설정으로 먼저 접속해보고 로그인, 결제, 검색, 파일 업로드, 관리자 기능을 확인합니다. 특히 쇼핑몰은 장바구니와 결제 콜백까지 봐야 합니다.
DNS 전환은 TTL을 낮춰두면 부담이 줄어듭니다. 전환 직후에는 이전 서버와 새 서버에 트래픽이 섞여 들어올 수 있으니 게시판, 주문, 회원가입처럼 쓰기 작업이 있는 사이트는 잠깐 점검 모드를 쓰는 편이 안전합니다. 운영 중단이 어렵다면 DB 쓰기 방향을 명확히 정하고, 전환 시간대를 로그가 적은 새벽으로 잡습니다.
장애가 났을 때는 큰 것보다 작은 것부터 본다
사이트가 안 열린다고 바로 서버호스팅 업체 장애부터 의심하면 시간이 늘어집니다. 저는 먼저 범위를 좁힙니다. 내 PC만 안 되는지, 모바일망에서도 안 되는지, 서버까지 ping이 가는지, 웹서버 프로세스가 살아 있는지, 디스크가 꽉 찼는지 순서로 봅니다. 사실 디스크 100% 때문에 DB가 멈추는 경우가 꽤 많습니다.
- 접속 불가: DNS, 방화벽, 웹서버 상태 확인
- 느림: CPU, 메모리, DB 쿼리, 외부 API 응답 시간 확인
- 간헐적 오류: 웹서버 로그와 애플리케이션 로그 시간대 대조
- 업로드 실패: 디스크 용량, 권한, 임시 디렉터리 확인
- SSL 오류: 인증서 만료일, 중간 인증서, 자동 갱신 작업 확인
모니터링은 거창할 필요 없습니다. 서버 부하, 디스크 사용률, 메모리, 웹 응답 코드, SSL 만료일 알림만 있어도 초반 사고는 많이 줄어듭니다. 무료 도구와 기본 로그만으로도 충분한 구간이 많습니다. 처음부터 복잡한 관제 시스템을 붙이는 것보다 알림을 실제로 보는 사람이 있는지가 더 중요합니다.
서버호스팅은 비싼 상품을 고르면 마음이 편해 보이지만, 운영에서는 계산한 숫자와 반복 가능한 절차가 더 오래 갑니다. 작은 서버라도 백업이 분리되어 있고, 복구 테스트를 해봤고, 장애 때 볼 순서가 적혀 있으면 웬만한 사이트는 꽤 안정적으로 버팁니다. 저는 아직도 새 사이트를 올릴 때 큰 사양부터 권하지 않습니다. 필요한 만큼 시작해서 로그를 보고 올리는 방식이 비용도 낮고 사고도 덜 납니다.
