얼마 전 작은 쇼핑몰 이전을 봐줬는데, 하루 방문자가 3천 명 정도인데도 월 8만 원대 서버를 쓰고 있었습니다. 막상 로그를 보니 피크 시간 동시접속은 18명 안팎이었고, 이미지도 외부 저장소가 아니라 웹호스팅 안에 그냥 놓여 있더군요. 이런 경우 서버를 키우는 것보다 캐시, 백업, 파일 구조를 먼저 손보는 쪽이 훨씬 낫습니다.
웹호스팅을 고를 때 제일 많이 틀리는 부분이 월 방문자 수만 보고 사양을 잡는 겁니다. 방문자 수는 방향을 잡는 지표일 뿐이고, 실제 장애는 짧은 시간에 요청이 몰릴 때 납니다. 특히 워드프레스, 그누보드, 쇼핑몰 솔루션처럼 PHP와 데이터베이스를 같이 쓰는 사이트는 동시접속, 페이지당 쿼리 수, 이미지 용량이 체감 성능을 갈라놓습니다.
웹호스팅이 충분한 구간부터 확인하기
개인 블로그, 회사 소개 페이지, 랜딩 페이지, 소규모 포트폴리오라면 대부분 일반 웹호스팅으로 충분합니다. 하루 방문자 500명 이하, 피크 시간 동시접속 5명 이하, 게시글과 이미지가 아주 많지 않은 사이트는 비싼 VPS부터 볼 필요가 없습니다. 월 1천 원에서 5천 원대 공유 웹호스팅으로도 느리지 않게 운영되는 사례가 많습니다.
단, 같은 방문자 500명이라도 조건이 다르면 이야기가 달라집니다. 첫 화면에 4MB짜리 이미지가 여러 장 있고, 플러그인 20개가 매 요청마다 데이터베이스를 두드리면 싼 호스팅이 버티기 어렵습니다. 반대로 정적 페이지 위주이고 이미지가 압축되어 있으면 하루 방문자 2천 명도 조용히 지나갑니다. 트래픽 숫자보다 요청의 무게가 더 중요합니다.
- 하루 방문자 300명 이하: 기본형 웹호스팅으로 시작해도 무난합니다.
- 하루 방문자 1천 명 안팎: 캐시 적용 여부와 데이터베이스 제한을 같이 봐야 합니다.
- 하루 방문자 5천 명 이상: 피크 시간 로그를 보고 VPS나 클라우드 전환을 검토합니다.
- 회원 로그인, 장바구니, 예약 기능이 많다면 방문자 수보다 동시 요청을 먼저 계산합니다.
동시접속 기준으로 사양 잡는 방법
제가 현장에서 대략 잡는 계산은 이렇습니다. 피크 10분 동안 방문자가 300명이고, 한 사람이 평균 4페이지를 본다면 10분 동안 1천200페이지 요청이 생깁니다. 초당으로 나누면 평균 2요청 정도입니다. 평균만 보면 작아 보이지만 실제로는 특정 분에 몰리므로 여기에 3배 정도 여유를 둡니다. 그러면 초당 6요청을 안정적으로 처리할 수 있는 구성이 필요합니다.
정적 HTML이나 캐시된 페이지는 초당 수십 요청도 가볍게 처리합니다. 문제는 로그인 사용자, 검색, 관리자 화면, 장바구니처럼 매번 PHP와 데이터베이스를 타는 요청입니다. 이 요청이 초당 5개만 꾸준히 들어와도 저가형 공유 호스팅에서는 응답이 느려질 수 있습니다. 그래서 워드프레스라면 페이지 캐시를 켠 상태의 속도와 캐시가 우회되는 화면의 속도를 따로 봐야 합니다.
메모리와 CPU보다 먼저 보는 항목
초보자가 VPS를 보면 CPU 코어와 메모리부터 비교합니다. 물론 중요합니다. 그런데 운영 중에는 디스크 입출력, 데이터베이스 동시 연결 수, 프로세스 제한, 백업 방식이 더 먼저 발목을 잡는 경우가 많습니다. 공유 웹호스팅은 겉으로 사양이 비슷해도 계정당 실행 제한이 다릅니다. 같은 2GB 저장 공간이라도 데이터베이스 용량, 파일 개수 제한, 일일 전송량 정책이 다르면 실제 사용감이 완전히 달라집니다.
운영 14년 동안 본 장애 중 상당수는 CPU가 모자라서가 아니었습니다. 로그 파일이 쌓여 디스크가 찼거나, 자동 백업이 같은 계정 안에 저장되어 용량을 밀어냈거나, PHP 버전 변경 후 플러그인이 죽은 경우가 많았습니다. 서버를 크게 잡아도 이런 부분을 안 보면 똑같이 멈춥니다.
이전할 때 사고 나는 지점
웹호스팅 이전은 파일을 옮기고 데이터베이스를 가져오면 끝이라고 생각하기 쉽습니다. 실제로는 문자셋, PHP 버전, 경로, 파일 권한, 예약 작업, 메일 설정까지 확인해야 합니다. 특히 오래된 사이트는 소스 안에 절대 경로가 박혀 있거나, 예전 확장 함수에 의존하는 코드가 남아 있습니다. 새 서버에서 첫 화면은 뜨는데 결제나 문의 폼만 죽는 일이 여기서 나옵니다.
이전 전에는 현재 서버에서 세 가지를 반드시 봅니다. 첫째, PHP와 데이터베이스 버전입니다. 둘째, 전체 파일 용량과 데이터베이스 용량입니다. 셋째, 실제로 쓰는 도메인, 서브도메인, 메일 계정 목록입니다. 이 셋을 안 보고 옮기면 작업 중간에 빠진 항목이 나옵니다.
- 이전 1일 전: 원본 파일과 데이터베이스를 각각 별도 보관합니다.
- 이전 직전: 게시판, 주문, 회원가입처럼 데이터가 변하는 기능을 잠시 막습니다.
- 이전 후: 관리자 로그인, 첨부파일 업로드, 메일 발송, 결제 테스트를 순서대로 확인합니다.
- 전환 후 24시간: 예전 서버를 바로 해지하지 말고 로그와 누락 파일을 대조합니다.
백업은 자동보다 복구가 기준입니다
호스팅 업체가 자동 백업을 제공한다고 해서 안심하면 안 됩니다. 자동 백업은 사고가 난 뒤에 복구가 되는지까지 확인해야 의미가 있습니다. 같은 계정 안에 백업 파일을 쌓는 방식이면 랜섬웨어, 계정 삭제, 용량 초과 상황에서 같이 날아갈 수 있습니다. 저는 최소한 파일 백업 1개, 데이터베이스 백업 1개를 운영 서버와 다른 위치에 두는 방식을 권합니다.
백업 주기도 사이트 성격에 맞춰야 합니다. 회사 소개 페이지는 주 1회로도 충분한 경우가 많습니다. 게시판, 쇼핑몰, 예약 사이트는 하루 1회로 부족할 수 있습니다. 주문 데이터가 1시간에 수십 건 생긴다면 데이터베이스만 더 짧게 가져가는 방식이 맞습니다. 중요한 건 백업 파일이 있다는 사실이 아니라, 어느 시점으로 몇 분 안에 되돌릴 수 있는지입니다.
장애가 났을 때 보는 순서
사이트가 느리거나 안 뜰 때는 브라우저 새로고침을 반복하기보다 순서를 정해 확인하는 게 빠릅니다. 먼저 내 회선 문제인지 다른 환경에서도 같은지 봅니다. 그다음 도메인 연결, SSL 인증서, 웹서버 응답, 데이터베이스 연결, 디스크 용량 순서로 좁혀 갑니다. 갑자기 500 오류가 나오면 소스 수정, PHP 버전 변경, 플러그인 업데이트 기록을 먼저 봅니다. 403 오류면 권한과 보안 정책을 봐야 하고, 접속 자체가 안 되면 도메인이나 서버 상태부터 확인합니다.
- 느림: 이미지 용량, 캐시, 데이터베이스 쿼리, 외부 스크립트를 봅니다.
- 500 오류: PHP 로그와 최근 변경 파일을 확인합니다.
- 접속 불가: 도메인 설정, SSL 상태, 서버 응답을 순서대로 봅니다.
- 용량 초과: 로그, 백업 파일, 첨부파일 증가량을 먼저 지웁니다.
비싼 서버가 답이 아닌 경우가 많습니다
웹호스팅에서 VPS나 클라우드 서버로 넘어가야 하는 순간은 분명히 있습니다. 관리자 권한이 필요하거나, 특정 서버 모듈을 설치해야 하거나, 공유 환경의 프로세스 제한을 자주 넘는다면 전환하는 게 맞습니다. 다만 운영자가 서버 보안, 패치, 백업, 모니터링을 직접 챙길 수 있어야 합니다. 관리 경험 없이 VPS로 옮기면 성능 문제는 줄어도 보안과 백업 문제가 새로 생깁니다.
처음부터 큰 서버를 쓰는 건 마음은 편하지만 비용 대비 효과가 낮을 때가 많습니다. 저는 보통 현재 트래픽, 피크 동시접속, 데이터베이스 크기, 이미지 용량, 백업 보관량을 먼저 적어 놓고 거기에 맞춰 고릅니다. 무료나 저가형으로 충분한 구간이면 그렇게 시작해도 됩니다. 돈을 아낀 만큼 백업과 모니터링에 조금만 신경 쓰는 쪽이 실제 운영에서는 더 오래 버팁니다.
