서버호스팅 처음 고를 때 과금 없이 맞추는 방법

얼마 전 작은 쇼핑몰을 운영하는 분이 VPS 8코어, 메모리 16GB 상품을 쓰고 있다고 해서 로그를 같이 봤습니다. 하루 방문자는 1,500명 안팎이고 피크 시간 동시접속은 20명 정도였습니다. 실제로는 2코어, 메모리 4GB에서도 충분한 구간이었는데, 장애가 두 번 났다는 이유로 사양만 계속 올린 상태였습니다. 그런데 장애 원인은 서버 성능이 아니라 백업 스크립트가 영업시간에 돌면서 디스크 입출력을 잡아먹은 것이었습니다.

서버호스팅을 고를 때 가장 먼저 봐야 할 것은 이름값이나 월 요금이 아닙니다. 내 사이트가 초당 몇 요청을 처리해야 하는지, 피크 시간에 PHP나 Node 같은 애플리케이션 프로세스가 얼마나 버틸 수 있는지, 데이터베이스가 같은 서버에 있는지부터 계산해야 합니다. 이 계산 없이 큰 서버를 사면 돈은 더 쓰고, 장애 원인은 그대로 남습니다.

서버호스팅 사양은 방문자 수보다 동시접속으로 잡는 방법

월 방문자 10만 명이라는 숫자는 보기에는 커 보이지만 서버 입장에서는 별로 정확한 기준이 아닙니다. 중요한 건 특정 시간에 몇 명이 동시에 접속하고, 한 사람이 몇 개의 요청을 만드는지입니다. 예를 들어 하루 방문자 3,000명 사이트라도 점심시간 30분에 몰리면 순간 부하는 꽤 올라갑니다. 반대로 하루 방문자 1만 명이어도 종일 고르게 들어오면 작은 서버로도 버팁니다.

제가 실무에서 대략 잡는 기준은 이렇습니다. 정적 페이지나 캐시가 잘 먹는 워드프레스 블로그는 동시접속 30명 이하라면 공유 웹호스팅이나 저가 VPS로도 충분한 경우가 많습니다. 동시접속 50~100명 구간부터는 CPU 2코어, 메모리 4GB 정도를 기준으로 보고, 데이터베이스가 같은 서버에 있으면 디스크 성능을 같이 봅니다. 동시접속 200명을 넘기면 서버 한 대 사양보다 캐시, DB 분리, 이미지 최적화, 웹서버 설정을 먼저 손봐야 합니다.

개인 블로그, 회사 소개 사이트: 공유 웹호스팅 또는 1코어 VPS
소규모 쇼핑몰, 예약 페이지: 2코어 4GB VPS부터 검토
회원 기능과 관리자 작업이 많은 사이트: CPU보다 메모리와 DB 응답 시간 확인
이미지 업로드가 많은 서비스: 트래픽보다 스토리지 I/O와 백업 정책 확인

사실 처음부터 클라우드 서버가 무조건 좋은 것도 아닙니다. 클라우드는 확장성과 네트워크 구성이 좋지만, 설정을 직접 책임져야 하는 부분이 많습니다. 운영 경험이 적고 사이트가 단순하다면 관리형 웹호스팅이 더 안정적일 수 있습니다. 싸서가 아니라, 책임 범위가 명확해서 그렇습니다.

웹호스팅, VPS, 클라우드 서버를 구분해서 쓰는 방법

웹호스팅은 한 서버를 여러 계정이 나눠 쓰는 방식입니다. 서버 설정 권한은 적지만, 기본 보안 패치나 웹서버 운영을 업체가 맡는 경우가 많습니다. 트래픽이 작고 표준적인 PHP 사이트라면 이 방식이 제일 편합니다. 단점은 특정 모듈 설치, 웹서버 튜닝, 백그라운드 작업 같은 부분에서 제약이 생긴다는 점입니다.

VPS는 가상 서버 한 대를 빌리는 방식입니다. 루트 권한을 갖고 웹서버, DB, 방화벽을 직접 설정할 수 있습니다. 가격 대비 자유도가 높아서 서버호스팅 입문 구간에서 많이 씁니다. 다만 보안 업데이트, 로그 관리, 백업, 장애 대응을 직접 해야 합니다. 이걸 놓치면 공유 웹호스팅보다 더 위험할 수 있습니다.

클라우드 서버는 VPS와 비슷해 보이지만 네트워크, 스냅샷, 로드밸런서, 오브젝트 스토리지, 모니터링을 조합하기 좋습니다. 트래픽 변동이 크거나 배포 자동화가 필요한 서비스에는 맞습니다. 반대로 회사 소개 사이트 하나 올리면서 로드밸런서와 관리형 DB까지 붙이면 월 비용이 필요 이상으로 커집니다. 솔직히 이런 구간에서는 비싼 아키텍처보다 백업 파일이 제대로 복구되는지가 더 중요합니다.

서버호스팅에서 자주 터지는 지점은 백업과 디스크

장애 문의를 받다 보면 CPU 100%보다 디스크 문제를 더 자주 봅니다. 로그가 쌓여서 파티션이 꽉 차거나, 백업 파일이 같은 서버 안에만 있거나, 이미지 썸네일 생성 작업이 몰리면서 응답이 늦어지는 식입니다. 서버 사양표에는 CPU와 메모리가 크게 보이지만, 운영에서는 디스크 여유 공간과 백업 위치가 훨씬 현실적인 변수입니다.

백업은 최소한 세 가지를 나눠 봐야 합니다. 웹 소스, 업로드 파일, 데이터베이스입니다. 워드프레스라면 테마와 플러그인보다 업로드 폴더와 DB가 더 중요합니다. 소스는 다시 받을 수 있어도 주문 내역이나 회원 데이터는 복구하지 못하면 바로 사고가 됩니다.

DB 백업: 하루 1회 이상, 트래픽 많은 서비스는 더 짧게
파일 백업: 업로드 변경량 기준으로 주기 설정
보관 위치: 운영 서버와 다른 저장소에 최소 1벌
복구 테스트: 백업 성공 로그만 믿지 말고 실제 복원 확인

근데 많은 사이트가 백업은 있다고 말하면서 복구 시간은 모릅니다. 20GB짜리 압축 파일 하나가 있다고 해서 안전한 게 아닙니다. 압축 해제에 얼마나 걸리는지, DB import 중 문자셋 오류가 나는지, 업로드 파일 권한이 맞는지까지 봐야 합니다. 백업은 만들어지는 순간보다 돌아오는 순간이 더 중요합니다.

이전 작업은 DNS보다 데이터 변경을 먼저 막아야 합니다

서버 이전을 할 때 초보자가 가장 많이 놓치는 부분이 데이터 변경입니다. 파일을 새 서버로 복사하고 DNS를 바꾸면 끝이라고 생각하기 쉽습니다. 그런데 쇼핑몰이나 게시판은 이전 중에도 주문, 글, 댓글, 회원가입이 계속 생깁니다. 이 상태에서 옮기면 새 서버와 기존 서버의 DB가 갈라집니다.

제가 쓰는 순서는 단순합니다. 먼저 새 서버에 같은 런타임 버전과 확장 모듈을 맞춥니다. 그다음 파일을 옮기고 DB를 복원합니다. 테스트용 임시 접속으로 로그인, 글쓰기, 결제 전 단계, 관리자 페이지를 확인합니다. 마지막에 기존 사이트를 점검 모드로 잠깐 막고 DB를 한 번 더 떠서 새 서버에 반영합니다. 그 뒤 DNS를 바꾸는 편이 안전합니다.

DNS 전파 시간도 생각해야 합니다. TTL을 미리 낮춰두지 않으면 일부 사용자는 한동안 기존 서버로 접속합니다. 그래서 이전 당일에 기존 서버를 바로 끄면 안 됩니다. 최소 하루 정도는 기존 서버를 유지하면서 접속 로그를 봐야 합니다. 이전이 끝났다고 생각한 뒤에도 옛 서버에 요청이 들어오는 경우가 꽤 있습니다.

장애가 났을 때는 사양 증설보다 확인 순서가 먼저입니다

사이트가 느려지면 바로 서버를 키우고 싶어집니다. 하지만 운영자는 순서를 지켜야 합니다. 먼저 접속 자체가 안 되는지, 특정 페이지가 느린지, 관리자만 느린지 구분합니다. 그다음 CPU, 메모리, 디스크 사용량, 네트워크, 웹서버 에러 로그, DB slow query를 봅니다. 이 순서만 지켜도 엉뚱한 비용을 줄일 수 있습니다.

접속 불가: DNS, 방화벽, 웹서버 프로세스 확인
간헐적 느림: DB 락, 외부 API, 백업 작업 시간 확인
이미지만 느림: 스토리지 I/O, 썸네일 생성, 캐시 헤더 확인
관리자만 느림: 플러그인, 통계 쿼리, 세션 저장 방식 확인

서버호스팅은 좋은 장비를 고르는 일처럼 보이지만, 실제 운영에서는 맞는 크기로 시작하고 관찰하면서 조정하는 일이 더 많습니다. 처음부터 큰 서버를 쓰는 것보다 로그를 남기고, 백업을 검증하고, 장애 때 볼 순서를 정해두는 쪽이 훨씬 오래 갑니다. 작은 서버로도 충분한 구간은 분명히 있고, 그 돈은 모니터링과 백업에 쓰는 편이 낫다고 봅니다.