얼마 전 작은 쇼핑몰 이전을 도와줬는데, 월 방문자가 3만 명 정도인 사이트에 8코어 서버를 권하고 있었다. 막상 로그를 보니 피크 시간 동시 접속은 35명 안팎이었고, 이미지 용량만 줄여도 기존 저가 VPS에서 충분히 버틸 상태였다. 서버호스팅은 비싼 요금제를 고르는 일이 아니라, 내 사이트가 실제로 쓰는 자원을 계산하는 일에 가깝다.
트래픽보다 먼저 봐야 할 숫자
많은 분들이 하루 방문자 수부터 말한다. 물론 중요하다. 그런데 서버 입장에서는 하루 1만 명이 천천히 들어오는지, 10분 동안 2천 명이 몰리는지가 더 크다. 그래서 저는 서버호스팅을 고를 때 월 방문자보다 피크 시간 동시 접속자, 페이지당 요청 수, 이미지와 파일 전송량을 먼저 본다.
예를 들어 블로그형 사이트에서 한 페이지가 HTML, CSS, 스크립트, 이미지까지 합쳐 2MB라고 치자. 하루 5천 페이지뷰면 전송량은 대략 10GB다. 한 달이면 300GB 정도다. 여기에 검색봇, 관리자 접속, 이미지 재요청을 더해 1.3배 정도 여유를 잡으면 월 400GB 안팎이 된다. 이 정도는 고급 서버가 필요한 구간이 아니다.
- 개인 블로그, 회사 소개 사이트: 월 10만 페이지뷰 이하라면 저가 웹호스팅이나 1코어 VPS도 충분한 경우가 많다.
- 워드프레스 콘텐츠 사이트: 캐시 적용 기준으로 1코어 1GB 또는 2GB RAM부터 시작해도 된다.
- 게시판, 커뮤니티: 페이지뷰보다 로그인, 검색, 댓글 작성, DB 쓰기 비율을 더 봐야 한다.
- 쇼핑몰: 상품 이미지, 장바구니, 결제 모듈, 관리자 작업이 겹치는 시간대를 기준으로 잡는 편이 안전하다.
웹호스팅, VPS, 클라우드 서버를 나누는 기준
서버호스팅이라고 다 같은 상품은 아니다. 웹호스팅은 서버 한 대를 여러 사용자가 나눠 쓰는 구조라서 관리가 편하고 싸다. PHP 기반 홈페이지나 작은 워드프레스에는 아직도 현실적인 선택이다. 단점은 서버 설정을 마음대로 바꾸기 어렵고, 같은 장비의 다른 사용자가 자원을 많이 쓰면 영향을 받을 수 있다는 점이다.
VPS는 가상 서버를 한 대 빌리는 방식이다. 웹서버, DB, 캐시, 방화벽 설정을 직접 만질 수 있다. 운영 경험이 있거나, 개발자가 붙어 있는 서비스라면 VPS가 비용 대비 제어권이 좋다. 다만 백업, 보안 업데이트, 장애 대응을 직접 챙겨야 한다. 서버를 빌렸다는 말은 권한도 가져왔지만 책임도 가져왔다는 뜻이다.
클라우드 서버는 증설과 네트워크 구성이 유연하다. 트래픽이 일정하지 않거나, 캠페인 기간에만 접속자가 몰리는 서비스에는 장점이 있다. 그런데 작은 사이트에서 처음부터 복잡한 로드밸런서, 오토스케일링, 관리형 DB를 다 붙이면 월 비용이 생각보다 빨리 커진다. 월 매출이나 장애 손실 비용을 따져보고 필요한 부분만 쓰는 게 낫다.
초기 사양은 이렇게 잡는다
처음 서버를 잡을 때 저는 대개 보수적으로 시작한다. 정적 페이지나 가벼운 회사 사이트는 공유 웹호스팅으로도 충분하다. 워드프레스라면 1코어 1GB RAM은 아주 빠듯하고, 플러그인이 많으면 2GB RAM부터 보는 편이 편하다. DB가 같은 서버에 있고 이미지도 많이 올린다면 디스크 I/O가 병목이 될 수 있으니 SSD 여부를 꼭 본다.
동시 접속 50명 이하의 일반 콘텐츠 사이트라면 2코어 2GB RAM VPS로도 꽤 오래 간다. 캐시 플러그인, 페이지 캐시, 객체 캐시, 이미지 압축이 들어가면 체감 성능이 크게 달라진다. 반대로 캐시가 없고, 첫 화면에서 외부 스크립트와 큰 이미지를 여러 개 부르면 4코어 서버도 답답할 수 있다. 서버 사양보다 페이지 구조가 먼저 망가져 있는 경우가 정말 많다.
간단한 계산식
월 전송량은 페이지 크기 곱하기 페이지뷰로 잡는다. 3MB 페이지가 월 20만 번 열리면 600GB다. 여기에 여유율 30퍼센트를 더하면 약 780GB가 된다. 방문자가 파일을 내려받는 사이트라면 이 계산에 다운로드 용량을 따로 더해야 한다. 영상까지 직접 호스팅한다면 얘기가 완전히 달라진다. 그때는 서버호스팅보다 별도 스토리지와 전송 서비스 조합을 검토하는 게 맞다.
도메인과 SSL은 싸게 해도 운영 절차는 빡빡하게
도메인은 비싼 곳에서 산다고 접속이 빨라지지 않는다. 중요한 건 소유자 이메일, 만료일, 네임서버, DNS 레코드 관리다. 실제 장애 중에는 서버가 멀쩡한데 도메인 만료나 잘못된 DNS 수정 때문에 사이트가 내려간 사례가 많다. A 레코드 하나 잘못 바꾸면 웹도 메일도 같이 흔들릴 수 있다.
SSL도 마찬가지다. 무료 인증서로 충분한 사이트가 많다. 다만 자동 갱신이 되는지, 갱신 실패 알림을 받는지, 서버 이전 때 인증서 경로가 바뀌지 않는지를 확인해야 한다. 인증서 만료는 예고된 장애다. 비용 문제가 아니라 점검표 문제다.
- 도메인 만료 알림은 운영자 개인 메일 하나에만 묶지 않는다.
- DNS 변경 전 기존 레코드를 캡처하거나 파일로 보관한다.
- SSL 자동 갱신은 실제 재시작까지 되는지 확인한다.
- 서버 이전 전 TTL을 낮춰 전환 시간을 줄인다.
백업 없는 서버호스팅은 싼 게 아니다
장애 현장에서 제일 난감한 말은 백업이 있을 줄 알았다는 말이다. 호스팅 업체가 스냅샷을 제공하더라도, 그게 사용자가 복구 가능한 백업인지 확인해야 한다. 스냅샷은 서버 전체를 특정 시점으로 되돌리는 데 유용하지만, 파일 하나나 DB 테이블 하나만 꺼내야 할 때 불편할 수 있다.
운영용 백업은 최소 세 가지를 나눠야 한다. 웹 파일, 데이터베이스, 업로드 파일이다. 워드프레스 기준으로는 테마와 플러그인보다 업로드 폴더와 DB가 더 중요하다. 코드는 다시 받을 수 있지만 고객 글, 주문 기록, 회원 정보는 없어지면 복구가 어렵다.
- DB 백업: 하루 1회 이상, 변경량이 많으면 더 짧게 잡는다.
- 파일 백업: 업로드가 많은 사이트는 증분 백업을 쓴다.
- 보관 위치: 같은 서버 안에만 두지 않는다.
- 복구 테스트: 백업 파일 존재 확인이 아니라 실제 복원까지 해본다.
장애가 나면 업그레이드보다 확인 순서가 먼저다
사이트가 느려지면 바로 서버를 올리는 경우가 많다. 그런데 CPU 사용률이 20퍼센트인데 응답이 느리다면 서버 사양 문제가 아닐 수 있다. DB 쿼리, 외부 API 지연, DNS 문제, PHP 프로세스 부족, 디스크 대기 시간이 원인일 수 있다. 그래서 장애 때는 감으로 움직이면 돈도 시간도 같이 쓴다.
저는 접속 불가가 나오면 먼저 도메인 해석, 서버 응답, 웹서버 상태, 디스크 용량, DB 연결, 최근 배포나 설정 변경 순서로 본다. 디스크가 100퍼센트 차서 로그도 못 쓰는 상황은 생각보다 흔하다. 또 백업 파일이 같은 디스크에 계속 쌓여서 사이트를 멈추게 만드는 경우도 있다.
서버호스팅은 처음부터 큰 장비를 사는 게임이 아니다. 작은 사양으로 시작하되 로그를 보고, 백업을 검증하고, 장애 때 확인할 순서를 문서로 남기는 쪽이 오래 간다. 14년 운영하면서 느낀 건 단순하다. 서버는 대개 트래픽보다 방치된 설정 때문에 먼저 흔들린다.
