얼마 전 작은 쇼핑몰 이전을 봐줬는데, 월 방문자가 3만 명도 안 되는 사이트에 4코어 VPS를 권하고 있었다. 실제로는 웹호스팅 저가형에서도 충분했고, 느린 원인은 서버 사양이 아니라 이미지 원본 업로드와 백업 미설정이었다. 이런 경우가 꽤 많다. 서버는 크게 잡으면 마음은 편하지만, 운영비는 매달 빠지고 장애 원인은 그대로 남는다.
웹호스팅은 방문자 수만 보고 고르면 안 된다
웹호스팅을 고를 때 제일 먼저 보는 숫자가 보통 월 방문자 수다. 그런데 서버 입장에서는 월 방문자보다 피크 시간의 동시 접속과 페이지 생성 시간이 더 중요하다. 하루 1만 명이 들어와도 하루 종일 고르게 오면 부담이 작고, 이벤트 문자 한 번에 10분 동안 몰리면 작은 서버는 바로 버벅인다.
대략 계산은 이렇게 잡는다. 한 페이지 요청이 PHP와 DB를 거쳐 0.5초에 끝나고, 동시에 처리할 요청이 20개 정도면 꽤 넉넉한 편이다. 반대로 페이지 하나가 3초씩 걸리면 같은 서버에서도 체감 속도는 확 떨어진다. 그래서 웹호스팅을 올리기 전에 캐시, 이미지 용량, 느린 쿼리부터 확인하는 게 순서다.
- 회사 소개형 사이트: 월 1만~5만 방문자까지는 일반 웹호스팅으로 충분한 경우가 많다.
- 워드프레스 블로그: 캐시가 켜져 있으면 저가형 웹호스팅도 오래 버틴다.
- 게시판·커뮤니티: 로그인, 검색, 댓글이 많아지면 DB 부하를 먼저 본다.
- 쇼핑몰: 결제, 장바구니, 관리자 작업이 겹치므로 단순 방문자 수보다 동시 작업 수가 중요하다.
무료와 저가형이 충분한 구간
솔직히 초기에 무료나 저가 웹호스팅을 쓰는 건 나쁜 선택이 아니다. 트래픽이 작고 정적 페이지가 많고, 장애가 매출로 바로 이어지지 않는 사이트라면 비싼 서버부터 살 필요가 없다. 특히 포트폴리오, 안내 페이지, 소규모 블로그는 월 몇 천 원짜리 웹호스팅으로도 충분히 운영된다.
다만 싼 요금제는 제한이 있다. CPU를 오래 쓰는 작업, 대량 메일 발송, 큰 파일 다운로드, 잦은 백업 압축 같은 작업은 금방 막힌다. 웹호스팅 업체가 표기하는 트래픽 용량은 전송량 기준인 경우가 많아서, 실제 병목은 DB 접속 수나 프로세스 제한에서 먼저 온다.
저가형을 써도 되는 신호
- 하루 방문자가 1천 명 이하이고 피크가 뚜렷하지 않다.
- 페이지 대부분이 글, 이미지, 간단한 폼으로 구성되어 있다.
- 관리자 1~2명이 가끔 접속하는 수준이다.
- 캐시 플러그인이나 서버 캐시를 적용할 수 있다.
- 백업 파일을 같은 계정 안에 오래 쌓아두지 않는다.
반대로 관리자 페이지가 느리고, 검색 한 번에 DB 사용량이 튀고, 업로드 파일이 빠르게 늘어난다면 요금제보다 구조를 먼저 봐야 한다. 용량만 올려도 해결되는 문제인지, DB와 파일 저장 위치를 나눠야 하는 문제인지가 갈린다.
사양은 이렇게 계산하면 덜 흔들린다
웹호스팅 사양을 볼 때는 저장공간, 트래픽, 메모리성 제한, 백업 정책을 나눠서 본다. 저장공간 10GB라고 쓰여 있어도 메일함, 로그, 백업 압축 파일까지 같은 공간을 쓰면 금방 찬다. 장애는 디스크 100%에서 시작되는 경우가 정말 많다.
트래픽은 페이지당 전송량으로 계산하면 감이 온다. 페이지 하나가 이미지 포함 2MB이고 하루 5천 페이지뷰면 하루 약 10GB, 한 달이면 약 300GB다. 그런데 이미지 최적화를 해서 페이지당 700KB로 줄이면 같은 방문자라도 한 달 100GB 안쪽으로 내려간다. 서버를 키우는 것보다 이미지 줄이는 게 더 싸고 확실할 때가 많다.
- 메모리: 워드프레스 기준으로 플러그인이 많으면 512MB 제한에서 막히는 일이 생긴다.
- CPU: 짧게 튀는 건 괜찮지만 이미지 리사이즈, 백업 압축, 검색 인덱싱은 오래 잡아먹는다.
- DB: 접속 수 제한과 슬로우 쿼리가 체감 속도를 좌우한다.
- 디스크: 용량보다 inode 제한, 백업 보관 위치, 로그 증가 속도를 같이 본다.
- 메일: 웹호스팅 메일을 쓰면 발송 제한과 스팸 정책을 확인해야 한다.
운영 기준으로는 평균 사용량보다 피크 사용량을 본다. CPU 평균 20%라도 특정 시간에 100%로 붙으면 방문자는 그 시간만 기억한다. 그래서 이전 전에는 최소 하루 단위 로그를 보고, 가능하면 일주일 피크를 확인한다.
이전과 백업에서 사고가 많이 난다
웹호스팅 장애 상담을 하다 보면 트래픽 폭주보다 이전 작업 중 사고가 더 많다. 파일은 옮겼는데 DB 문자셋이 깨지고, DNS는 바꿨는데 기존 메일 서버 설정을 빼먹고, SSL은 새 서버에 설치하지 않아 브라우저 경고가 뜬다. 이런 건 사양 문제가 아니라 절차 문제다.
이전은 순서를 작게 쪼개야 한다. 먼저 현재 서버에서 파일과 DB를 각각 백업한다. 그다음 새 웹호스팅에 복원하고 임시 주소나 hosts 설정으로 화면을 확인한다. 로그인, 글쓰기, 이미지 업로드, 결제나 문의 폼처럼 쓰기 작업이 있는 기능을 먼저 눌러봐야 한다. 화면 첫 페이지만 뜬다고 끝난 게 아니다.
- 이전 전: 파일, DB, 메일 계정, DNS 레코드, SSL 만료일을 적어둔다.
- 복원 후: 문자셋, 파일 권한, 업로드 경로, 세션 저장 위치를 확인한다.
- DNS 변경 전: 새 서버에서 관리자 기능과 폼 전송을 테스트한다.
- 변경 직후: 접속 로그, 오류 로그, 메일 수신, 인증서 상태를 본다.
- 하루 뒤: 기존 서버에 새 글이나 주문이 남아 있는지 확인하고 종료 일정을 잡는다.
백업은 더 엄격하게 봐야 한다. 같은 웹호스팅 계정 안에 백업 압축 파일 하나 두는 건 백업이 아니라 복사본에 가깝다. 계정이 잠기거나 디스크가 깨지면 같이 사라진다. 운영 사이트라면 최소한 파일과 DB를 분리해서 내려받고, 주기적으로 복원 테스트를 해야 한다.
장애가 났을 때 보는 순서
사이트가 안 열리면 처음부터 업체 탓이나 트래픽 탓으로 가면 시간이 새기 쉽다. 나는 보통 DNS, SSL, 웹서버 응답, 애플리케이션 오류, DB 상태 순서로 본다. 브라우저 화면이 하얗게 보이는지, 인증서 경고가 나는지, 500 오류인지, 접속 자체가 안 되는지에 따라 방향이 다르다.
- 접속 불가: DNS 변경, 네임서버, 방화벽 차단을 먼저 확인한다.
- 보안 경고: SSL 인증서 설치 위치와 도메인 매칭을 본다.
- 500 오류: PHP 버전, 파일 권한, 플러그인 충돌, 오류 로그를 확인한다.
- 느림: DB 쿼리, 이미지 크기, 캐시 상태, 외부 스크립트 지연을 본다.
- 용량 초과: 로그, 백업 압축 파일, 메일함, 임시 파일을 찾아낸다.
웹호스팅은 비싼 요금제를 쓰면 끝나는 서비스가 아니다. 작은 사이트는 작게 시작해도 된다. 대신 백업 위치, 이전 절차, 피크 시간 로그, SSL 갱신 같은 운영 항목을 놓치면 싼 서버든 비싼 서버든 비슷하게 멈춘다. 나는 처음부터 큰 서버를 잡는 것보다, 지금 필요한 만큼 쓰고 언제 옮길지 기준을 정해두는 쪽이 더 실무적이라고 본다.
