요즘 상담을 하다 보면 월 방문자 수만 보고 서버호스팅을 고르려는 경우가 많아졌습니다. 그런데 14년 동안 웹서버와 호스팅 인프라를 굴려보면, 사이트가 죽는 이유는 방문자가 많아서라기보다 동시접속 계산이 틀렸거나 백업과 설정이 허술해서인 경우가 훨씬 많았습니다.
서버호스팅은 월 방문자보다 동시접속으로 봅니다
월 방문자 10만 명이라는 숫자는 커 보이지만, 하루로 나누고 시간대로 다시 나누면 생각보다 작습니다. 예를 들어 월 10만 방문이면 하루 평균 약 3,300명입니다. 피크 시간이 전체의 20퍼센트를 가져간다고 해도 한 시간에 660명 정도입니다. 페이지 체류와 요청 간격을 고려하면 실제 동시접속은 20명 안팎인 경우가 많습니다.
서버 사양은 이 동시접속에서 출발해야 합니다. 워드프레스 같은 PHP 기반 사이트에 캐시가 제대로 걸려 있다면, 작은 VPS나 저가형 웹호스팅으로도 꽤 버팁니다. 반대로 캐시 없이 매 요청마다 데이터베이스를 때리면 방문자가 많지 않아도 CPU가 금방 차오릅니다.
- 일 방문자 1천 명 이하: 일반 웹호스팅이나 저가형 VPS로 충분한 경우가 많습니다.
- 일 방문자 1만 명 전후: 캐시, 이미지 최적화, 데이터베이스 상태를 같이 봐야 합니다.
- 실시간 로그인 사용자 100명 이상: 단순 방문자 수보다 세션, 쿼리, 쓰기 작업을 우선 계산합니다.
- 파일 다운로드나 영상 트래픽 중심: CPU보다 전송량과 스토리지 비용이 먼저 튑니다.
싼 요금제로 충분한 구간이 분명히 있습니다
솔직히 말하면 회사 소개 사이트, 동네 병원 사이트, 작은 쇼핑몰, 개인 블로그는 비싼 서버호스팅이 필요 없는 경우가 많습니다. 월 방문자 수천 명 수준이고 글이나 상품 페이지가 대부분 정적이라면, 캐시 플러그인과 이미지 압축만 해도 체감 속도가 크게 달라집니다.
저는 처음부터 큰 서버를 잡는 방식을 좋아하지 않습니다. CPU 1~2코어, 메모리 1~2GB, SSD 20~50GB로 시작해서 실제 사용량을 봅니다. 평균 CPU가 30퍼센트 아래고 메모리 여유가 30퍼센트 이상이면 굳이 올릴 이유가 없습니다. 트래픽이 늘어날 때 증설하면 됩니다.
다만 저가형을 고를 때 확인할 게 있습니다. 백업 제공 여부, 복원 비용, 트래픽 초과 과금, SSH 접근 가능 여부, SSL 적용 방식입니다. 월 요금이 싸도 복원이 느리거나 백업이 같은 서버 안에만 있으면 장애 때 손쓸 시간이 길어집니다. 싸게 쓰는 것과 위험하게 쓰는 것은 다릅니다.
VPS와 클라우드는 운영 방식이 다릅니다
VPS는 가격 예측이 쉽고 단순합니다. 정해진 CPU, 메모리, 디스크를 월 단위로 쓰는 구조라 블로그나 중소형 서비스에 잘 맞습니다. 운영자가 서버 설정을 직접 잡을 수 있다면 비용 대비 효율이 좋습니다.
클라우드는 유연하지만 손이 더 갑니다. 인스턴스, 디스크, 스냅샷, 로드밸런서, NAT, 트래픽 비용이 따로 붙는 경우가 많습니다. 처음 견적은 작아 보여도 로그, 백업, 외부 전송량이 늘면 예상보다 요금이 커집니다. 그래서 클라우드는 갑자기 트래픽이 튀거나 여러 서버로 나눠야 하는 서비스에 어울립니다.
제가 보는 기준은 단순합니다
- 혼자 운영하는 블로그나 회사 사이트: 관리형 웹호스팅 또는 작은 VPS
- 트래픽은 작지만 설정 자유도가 필요함: VPS
- 피크 트래픽이 자주 튐: 클라우드 또는 오토스케일 구조
- 장애 시간이 바로 매출 손실로 이어짐: 이중화와 외부 백업 우선
서버호스팅 비용을 볼 때는 월 요금만 보면 안 됩니다. 이전 작업 시간, 장애 대응 시간, 백업 복구 시간까지 비용입니다. 운영자가 직접 만질 수 없는 환경이면 저렴해도 나중에 답답해질 수 있습니다.
이전과 백업에서 사고가 가장 많이 납니다
사이트 이전은 파일만 옮기면 끝나는 작업이 아닙니다. 웹 루트, 데이터베이스, 업로드 파일, 환경 변수, 크론 작업, SSL, DNS TTL까지 같이 봐야 합니다. 실제 장애는 이 중 하나가 빠져서 납니다. 특히 도메인 DNS를 바꾼 뒤 예전 서버를 너무 빨리 끄는 실수가 잦습니다.
저는 이전 전날 DNS TTL을 낮추고, 새 서버에 같은 버전의 런타임을 맞춘 뒤, 데이터베이스 덤프와 파일 동기화를 따로 확인합니다. 이전 직전에는 업로드나 주문 같은 쓰기 작업을 잠시 막는 편이 안전합니다. 쇼핑몰이라면 이 시간이 더 중요합니다. 주문 데이터가 두 서버에 갈라지면 복구가 피곤해집니다.
- 백업은 서버 내부 1개만 두지 않습니다.
- 데이터베이스와 업로드 파일은 주기가 달라야 합니다.
- 복원 테스트를 하지 않은 백업은 없는 것과 비슷합니다.
- SSL 인증서 자동 갱신은 이전 후 반드시 확인합니다.
- 이전 후 최소 48시간은 기존 서버를 유지하는 편이 안전합니다.
백업은 많이들 비용으로 보지만, 실제로는 보험보다 운영 절차에 가깝습니다. 삭제, 해킹, 업데이트 실패, 디스크 장애는 예고 없이 옵니다. 복원에 10분 걸리는 구조와 하루 걸리는 구조는 같은 서버호스팅이라고 부르기 어렵습니다.
장애가 났을 때는 순서를 지켜야 빨리 잡힙니다
사이트가 안 열리면 급해서 이것저것 만지게 됩니다. 근데 이때 설정을 여러 개 동시에 바꾸면 원인을 잃어버립니다. 먼저 도메인 해석, 서버 응답, 웹서버 상태, 애플리케이션 로그, 데이터베이스 연결 순서로 봅니다.
브라우저에서 안 열린다고 바로 서버가 죽은 것은 아닙니다. DNS가 꼬였을 수도 있고, SSL 만료일 수도 있고, 방화벽에서 특정 포트가 막혔을 수도 있습니다. 502는 웹서버와 애플리케이션 사이 문제일 때가 많고, 504는 뒤쪽 응답이 늦는 경우가 많습니다. 500은 애플리케이션 로그를 봐야 합니다.
- 도메인이 올바른 서버를 가리키는지 확인합니다.
- 80번과 443번 포트 응답을 봅니다.
- 웹서버 프로세스와 디스크 사용량을 확인합니다.
- 최근 배포, 플러그인 업데이트, 설정 변경 시간을 맞춰 봅니다.
- 데이터베이스 접속 수와 느린 쿼리를 확인합니다.
서버호스팅은 비싼 상품을 고르는 게임이 아닙니다. 내 사이트가 어떤 요청을 얼마나 만들고, 장애가 났을 때 어디까지 직접 볼 수 있으며, 백업에서 얼마나 빨리 돌아올 수 있는지 계산하는 일입니다. 작은 서버로 시작해도 이 기준이 잡혀 있으면 운영이 꽤 단단해집니다. 반대로 큰 서버를 써도 백업과 설정이 허술하면 언젠가 같은 자리에서 멈춥니다. 저는 아직도 새 사이트를 받을 때 사양표보다 백업 위치와 복원 시간을 먼저 묻습니다.