얼마 전 작은 쇼핑몰 이전 작업을 봤는데, 월 방문자가 많아서 죽은 사이트가 아니었습니다. PHP 작업자 수는 기본값 그대로였고, 백업은 같은 서버 안에만 쌓여 있었고, 이미지 리사이즈 작업이 점심시간마다 몰리면서 응답이 밀렸습니다. 서버호스팅을 고를 때 이런 부분을 빼고 CPU와 메모리만 올리면 돈은 더 쓰는데 장애 원인은 그대로 남습니다.
서버호스팅은 방문자 수보다 동시접속으로 봐야 합니다
월 방문자 10만 명이라는 숫자는 생각보다 판단에 덜 도움이 됩니다. 실제 서버가 버텨야 하는 건 특정 시간대에 동시에 들어오는 요청입니다. 예를 들어 하루 방문자 3천 명인 사이트라도 대부분이 오전 10시부터 11시 사이에 몰리면 체감 부하는 월 방문자 10만 명짜리 블로그보다 높을 수 있습니다.
대략적인 출발점은 이렇게 잡습니다. 일반적인 워드프레스나 PHP 기반 사이트에서 캐시가 잘 잡혀 있고 상품 검색 같은 무거운 기능이 적다면 1코어, 메모리 1GB VPS로도 하루 수천 방문자는 처리합니다. 반대로 로그인 사용자, 장바구니, 관리자 통계, 실시간 검색이 많으면 같은 방문자 수라도 2코어, 메모리 2GB 이상을 봐야 합니다.
- 정적 블로그, 회사 소개 사이트: 저가 웹호스팅이나 1GB급 VPS로 충분한 경우가 많습니다.
- 워드프레스 블로그, 소규모 쇼핑몰: 캐시 적용 기준 1~2코어, 메모리 1~2GB부터 계산합니다.
- 동시 주문, 예약, 회원 기능이 많은 사이트: 데이터베이스와 웹서버를 나눌 여지를 처음부터 봅니다.
- 이미지 업로드와 변환이 많은 서비스: CPU보다 디스크 성능과 작업 큐가 먼저 막히는 경우가 잦습니다.
싼 요금제가 충분한 구간이 분명히 있습니다
솔직히 말하면 처음부터 클라우드 서버를 크게 잡을 필요가 없는 사이트가 많습니다. 하루 방문자 500명 이하의 회사 소개 사이트, 랜딩 페이지, 포트폴리오라면 안정적인 웹호스팅으로도 운영이 됩니다. 관리자 화면이 느리지 않고, 백업을 밖으로 빼고, SSL 갱신이 자동이면 굳이 비싼 인스턴스를 쓸 이유가 없습니다.
서버호스팅 비용을 비교할 때는 월 요금만 보지 말고 트래픽 단가, 스냅샷 비용, 백업 보관 기간, 장애 대응 범위를 같이 봐야 합니다. 월 5천 원짜리 상품이 월 2만 원짜리보다 나을 때도 있습니다. 반대로 저렴해 보여도 트래픽 초과 비용이 크거나 백업 복구를 직접 해야 하면 운영 비용은 금방 올라갑니다.
요금제 비교할 때 보는 숫자
- 메모리: PHP, Node, 데이터베이스, 캐시가 같이 돌면 1GB는 금방 찹니다.
- 디스크: 용량보다 IOPS와 스냅샷 가능 여부가 중요합니다.
- 트래픽: 월 제공량보다 피크 시간 제한과 초과 과금 방식을 봅니다.
- 백업: 같은 서버 안 저장은 백업이 아니라 복사본에 가깝습니다.
- 관리 범위: 보안 패치, 장애 확인, 복구 대행이 포함되는지 확인합니다.
장애는 설정 기본값에서 많이 납니다
운영을 오래 해보면 서버가 작아서 죽는 경우보다 설정이 맞지 않아 죽는 경우가 더 자주 보입니다. 웹서버 keepalive가 과하게 길거나, PHP-FPM worker가 너무 적거나, 데이터베이스 연결 수가 작은데 애플리케이션은 재시도를 반복하는 식입니다. 이런 장애는 서버를 2배로 키워도 잠깐 나아졌다가 다시 터집니다.
워드프레스 기준으로는 캐시 플러그인 하나만 제대로 잡아도 서버 부하가 크게 줄어듭니다. 로그인하지 않은 방문자에게 매번 PHP와 데이터베이스를 태우는 구조라면 방문자 100명도 버겁고, 정적 캐시가 잘 먹으면 같은 서버에서 몇 배를 더 받습니다. 근데 장바구니, 결제, 마이페이지처럼 캐시하면 안 되는 화면은 따로 봐야 합니다.
장애가 났을 때 먼저 보는 순서
- 서버 응답이 없는지, 애플리케이션만 느린지 나눕니다.
- CPU, 메모리, 디스크 사용률을 같은 시간대 로그와 맞춰 봅니다.
- 웹서버 에러 로그에서 502, 504, 연결 초과가 반복되는지 봅니다.
- 데이터베이스 slow query와 잠금 대기 시간을 확인합니다.
- 최근 배포, 플러그인 변경, 인증서 갱신 실패 여부를 확인합니다.
이전과 백업은 요금제 선택보다 먼저 잡습니다
서버호스팅 이전에서 제일 위험한 순간은 파일 복사가 아닙니다. DNS 전환, 데이터베이스 동기화, SSL 발급, 메일 설정 확인이 겹치는 시간이 위험합니다. 특히 쇼핑몰이나 예약 사이트는 이전 중에 주문 데이터가 양쪽 서버로 갈라지면 복구가 피곤해집니다.
이전 전에는 현재 서버의 파일, 데이터베이스, 설정 파일을 따로 받아야 합니다. 가능하면 새 서버에서 먼저 복구 테스트를 하고, 관리자 로그인과 주문 테스트까지 끝낸 뒤 전환합니다. DNS TTL은 미리 낮춰두고, 전환 후 최소 하루는 구서버 로그를 같이 봅니다. 여기서 성급하게 구서버를 지우면 빠진 이미지나 누락된 첨부파일을 찾기 어려워집니다.
운영 기준으로 권하는 백업 방식
- 파일과 데이터베이스를 분리해서 백업합니다.
- 백업 파일은 서버 밖 저장소에 보관합니다.
- 최소 하루 1회 자동 백업, 중요한 사이트는 변경 직전 수동 백업을 둡니다.
- 복구 테스트를 분기마다 한 번은 실제로 해봅니다.
- 백업 성공 알림보다 복구 가능 여부를 더 중요하게 봅니다.
처음 선택은 작게, 커질 때 옮길 수 있게
서버호스팅은 처음부터 큰 서버를 사는 게임이 아닙니다. 작게 시작하되 로그를 남기고, 백업을 밖으로 빼고, 언제든 이전할 수 있게 구성하는 쪽이 운영에서는 훨씬 유리합니다. 회사 소개 사이트와 작은 블로그는 저가 상품으로 충분한 경우가 많고, 돈을 더 써야 하는 지점은 대체로 트래픽보다 데이터베이스, 캐시 예외 화면, 백업 복구 시간에서 드러납니다.
제가 현장에서 보는 좋은 선택은 화려한 상품명이 아니라 설명 가능한 사양입니다. 왜 1GB면 되는지, 왜 2코어가 필요한지, 백업에서 몇 시간 안에 돌아올 수 있는지 말할 수 있으면 됩니다. 서버호스팅은 싸게 쓰는 것보다 작게 실패할 수 있게 만드는 쪽이 오래 갑니다.
