요즘 상담을 하다 보면 방문자 수만 보고 서버를 고르는 경우가 많아졌다. 14년 동안 웹서버와 호스팅 인프라를 운영하면서 본 장애는 대부분 트래픽 폭증보다 설정 누락, 백업 부재, 이전 실수에서 시작됐다. 그래서 저는 웹호스팅을 고를 때 제일 먼저 요금제 이름을 보지 않는다. 페이지 용량, 동시접속, PHP나 Node 같은 실행 환경, DB 사용량, 백업 방식부터 계산한다.
방문자 수보다 동시접속을 먼저 잡는 방법
일 방문자 1만 명이라는 숫자는 생각보다 서버 사양을 직접 말해주지 않는다. 24시간 고르게 들어오면 분당 7명 수준이지만, 점심시간 30분에 몰리면 완전히 다른 문제가 된다. 웹호스팅에서 중요한 건 순간 동시접속과 요청 수다.
예를 들어 워드프레스 블로그가 페이지 캐시를 쓰고 있고, 이미지가 최적화되어 있으며, 글 위주로 운영된다면 하루 3천~1만 방문자까지도 저가 웹호스팅으로 버티는 경우가 많다. 반대로 캐시 없이 플러그인 30개가 붙어 있고, 메인 화면에서 DB 쿼리를 많이 치면 방문자가 500명이어도 느려질 수 있다.
- 개인 블로그, 회사 소개 사이트: 일반 웹호스팅으로 충분한 경우가 많다.
- 워드프레스 중형 블로그: 캐시 적용 전제라면 저가 VPS보다 관리형 웹호스팅이 나을 때도 있다.
- 로그인 회원제, 게시판, 예약 기능: DB 부하를 따로 봐야 한다.
- 이벤트 페이지, 광고 유입 페이지: 순간 접속이 몰리므로 캐시와 CDN 설정이 먼저다.
동시접속을 대략 잡을 때는 체류 시간도 같이 본다. 평균 체류가 2분이고 1시간에 600명이 들어오면 단순 계산으로 평균 동시접속은 20명이다. 여기에 피크 계수 3~5배를 붙이면 60~100명 정도를 기준으로 보면 된다. 이 계산 없이 비싼 서버부터 계약하면 돈은 더 내는데 병목은 그대로 남는 일이 생긴다.
웹호스팅, VPS, 클라우드 서버를 나누는 기준
웹호스팅은 서버 관리를 업체가 많이 대신해주는 구조다. 계정 하나 받고 파일 올리고 DB 만들면 바로 운영할 수 있다. 단점은 커널, 웹서버 세부 설정, 백그라운드 프로세스, 특수 모듈 설치에 제약이 있다는 점이다. 그래서 단순 사이트에는 좋고, 커스텀 서비스에는 답답할 수 있다.
VPS는 작은 독립 서버를 빌리는 느낌이다. Nginx, Apache, PHP-FPM, MySQL, 방화벽을 직접 만진다. 자유도는 올라가지만 보안 업데이트, 로그 관리, 장애 대응도 직접 해야 한다. 서버 운영 경험이 없는데 가격만 보고 VPS로 가면 백업도 없이 루트 계정 하나로 몇 달 버티다가 사고가 난다.
클라우드 서버는 확장성과 부가 기능이 강하다. 로드밸런서, 오브젝트 스토리지, 스냅샷, 관리형 DB를 붙일 수 있다. 다만 작은 블로그 하나 운영하는 데 처음부터 클라우드 구성을 크게 잡을 필요는 없다. 월 몇 천 원짜리 웹호스팅으로 충분한 구간이 분명히 있다.
제가 잡는 대략적인 기준
- 정적 페이지, 회사 소개, 포트폴리오: 저가 웹호스팅 또는 정적 호스팅
- 일 방문자 1만 이하의 캐시 적용 블로그: 웹호스팅 우선 검토
- 특정 모듈, 배치 작업, 서버 설정이 필요한 서비스: VPS
- 피크 트래픽이 크고 무중단 배포가 필요한 서비스: 클라우드 서버
- 개인정보, 결제, 내부 관리자 기능이 있는 서비스: 백업과 접근제어 비용까지 포함해서 산정
여기서 중요한 건 싼 요금제를 무조건 쓰자는 얘기가 아니다. 필요한 구간에서는 돈을 써야 한다. 다만 서버 사양보다 애플리케이션 구조가 먼저인 경우가 많다. 이미지 5MB짜리 20장을 메인에 올려놓고 CPU를 올리는 건 순서가 맞지 않다.
요금제 비교할 때 꼭 봐야 할 항목
웹호스팅 요금표에는 저장공간, 트래픽, DB 용량, 이메일 계정, SSL 지원 같은 항목이 나온다. 여기서 저장공간만 크게 보고 고르면 실수하기 쉽다. 실제 운영에서 먼저 부족해지는 건 보통 트래픽, inode 수, DB 용량, 프로세스 제한이다.
이미지가 많은 사이트라면 저장공간보다 월 트래픽을 본다. 페이지 한 번 열 때 3MB를 내려주고 하루 3천 명이 보면 하루 9GB, 한 달이면 270GB다. 압축과 이미지 변환을 하면 이 숫자는 크게 줄어든다. 그래서 서버 업그레이드 전에 이미지 최적화가 먼저다.
- 트래픽: 월 단위인지 일 단위인지 확인한다.
- DB 용량: 게시글보다 로그성 데이터와 플러그인 테이블이 빨리 커진다.
- PHP 메모리 제한: 워드프레스 관리자 화면 속도에 직접 영향을 준다.
- 동시 프로세스 제한: 접속이 몰릴 때 503 오류로 보일 수 있다.
- 백업 보관 기간: 1일치인지 7일치인지 차이가 크다.
- SSL 자동 갱신: 수동 갱신이면 만료 사고가 생각보다 자주 난다.
업체가 적어놓은 무제한이라는 말도 조심해서 봐야 한다. 대부분 공정 사용 기준이 있고 CPU 사용량이나 파일 개수 제한이 따로 있다. 무제한 트래픽이라고 해서 무거운 동영상 파일을 계속 뿌려도 된다는 뜻은 아니다.
이전과 백업에서 사고가 가장 많이 난다
웹호스팅 이전은 파일만 옮기는 작업이 아니다. 소스, 업로드 파일, DB, DNS, SSL, 메일, 크론, 환경변수까지 같이 움직인다. 실제 사고는 여기서 많이 난다. 특히 DNS 변경 직후에는 예전 서버와 새 서버로 접속이 섞일 수 있어서, 게시판이나 주문 기능이 있는 사이트는 이전 시간대를 잘 잡아야 한다.
제가 현장에서 쓰는 순서는 단순하다. 먼저 기존 서버의 파일과 DB를 따로 백업한다. 새 서버에 복원하고 임시 주소나 hosts 설정으로 화면과 관리자 기능을 확인한다. 그다음 SSL을 붙이고, 메일 사용 여부를 확인하고, 마지막에 DNS를 바꾼다. DNS를 먼저 바꾸고 나서 화면이 깨진 걸 발견하면 복구가 훨씬 피곤해진다.
- 이전 전: 파일, DB, 설정값, 메일 계정 목록을 확보한다.
- 이전 중: 새 서버에서 로그인, 글쓰기, 이미지 업로드, 검색 기능을 확인한다.
- DNS 변경: 낮은 TTL로 줄여둔 뒤 트래픽 적은 시간에 바꾼다.
- 이전 후: 예전 서버를 바로 지우지 말고 며칠 보관한다.
- 백업 검증: 백업 파일이 있다는 사실보다 복원이 되는지가 중요하다.
백업은 자동으로 만든다고 끝난 게 아니다. 압축 파일이 깨졌거나 DB 덤프가 중간에 끊겨 있는 경우도 봤다. 최소 한 달에 한 번은 작은 테스트 환경에 복원해보는 게 좋다. 운영 서버에 장애가 난 날 처음 복원을 시도하면 판단이 급해지고 실수가 늘어난다.
장애가 났을 때 확인 순서
사이트가 안 열린다고 바로 서버 사양을 올릴 필요는 없다. 먼저 증상을 나눠야 한다. 브라우저에서 접속 자체가 안 되는지, 500 오류인지, 502나 503인지, 관리자만 느린지에 따라 원인이 다르다. 이 구분만 해도 시간을 꽤 줄일 수 있다.
- 접속 불가: 도메인 DNS, 네임서버, 방화벽, 서버 전원 상태를 본다.
- SSL 오류: 인증서 만료, 중간 인증서, 강제 전환 설정을 확인한다.
- 500 오류: 애플리케이션 로그와 최근 수정 파일을 먼저 본다.
- 502 오류: 웹서버와 PHP-FPM 또는 백엔드 프로세스 연결을 확인한다.
- 503 오류: 동시 프로세스 제한, 점검 모드, 리소스 제한을 의심한다.
- 느림: DB 쿼리, 외부 API 대기, 이미지 용량, 캐시 미적용을 본다.
장애 때 제일 위험한 행동은 여러 설정을 한꺼번에 바꾸는 것이다. PHP 버전 바꾸고, 플러그인 끄고, DNS 바꾸고, 캐시 삭제까지 한 번에 하면 무엇이 원인이었는지 알 수 없다. 하나 바꾸고 확인하는 식으로 가야 한다. 조금 답답해도 그게 빠르다.
웹호스팅은 작고 싼 서비스처럼 보이지만 운영 원리는 대형 서비스와 크게 다르지 않다. 트래픽을 숫자로 보고, 백업을 복원 기준으로 보고, 장애를 증상별로 나누면 불필요한 업그레이드를 꽤 줄일 수 있다. 저는 아직도 작은 사이트에는 작은 요금제를 권한다. 대신 백업과 이전 절차만큼은 작은 사이트라고 대충 넘기지 않는다.
