얼마 전 작은 쇼핑몰 홈페이지가 자꾸 느려진다는 상담을 받았는데, 서버 스펙은 생각보다 높았고 문제는 캐시 설정과 백업 작업 시간이었습니다. 운영을 오래 하다 보면 이런 일이 꽤 많습니다. 방문자가 폭증해서 죽는 사이트보다, 이미지 원본을 그대로 올리거나 새벽 백업이 디스크를 꽉 채워서 멈추는 홈페이지가 더 자주 보입니다.
홈페이지 서버를 고를 때 처음부터 비싼 클라우드나 고사양 VPS를 잡을 필요는 없습니다. 먼저 하루 방문자, 피크 시간대 동시접속, 페이지 용량, 관리자 작업 빈도를 숫자로 잡아야 합니다. 이 계산 없이 요금제 이름만 보고 고르면 대개 과하게 쓰거나, 반대로 백업 공간이 부족해서 사고가 납니다.
홈페이지 트래픽을 먼저 숫자로 바꾸기
서버 사양은 월 방문자 수보다 피크 시간 동시접속이 더 중요합니다. 월 3만 명이 들어와도 하루 종일 고르게 퍼지면 아주 작은 서버로도 버팁니다. 반대로 이벤트 문자 한 번 보냈을 때 10분 안에 500명이 몰리면 저가형 웹호스팅은 바로 한계가 보입니다.
간단하게는 이렇게 계산합니다. 하루 방문자 1,000명, 방문자당 4페이지, 피크 시간에 전체의 20%가 몰린다고 보면 피크 1시간 페이지뷰는 800회입니다. 페이지 하나가 평균 2MB라면 피크 시간 전송량은 약 1.6GB입니다. 이 정도는 이미지 최적화와 캐시가 되어 있으면 저가형 웹호스팅이나 1코어 VPS에서도 충분히 감당합니다.
- 회사 소개형 홈페이지: 월 1만 방문 이하, 웹호스팅으로 충분한 경우가 많음
- 블로그형 홈페이지: 월 10만 방문 전후, 캐시 적용 시 1~2코어 VPS로 시작 가능
- 쇼핑몰형 홈페이지: 방문자보다 결제, 재고, 검색 쿼리 부하를 먼저 봐야 함
- 예약·신청형 홈페이지: 특정 시간대 접속 쏠림을 기준으로 잡아야 함
사실 홈페이지는 CPU보다 디스크 입출력과 PHP, DB 설정에서 먼저 막힐 때가 많습니다. 특히 워드프레스처럼 플러그인이 많은 구조는 방문자 100명보다 관리자 화면에서 상품 1,000개를 수정하는 작업이 더 무겁게 느껴질 수 있습니다.
웹호스팅, VPS, 클라우드 서버를 고르는 기준
웹호스팅은 관리 부담이 적습니다. 서버 보안 패치, 기본 웹서버 설정, 메일 설정을 업체가 어느 정도 맡아줍니다. 대신 프로세스 수, 동시접속, DB 제한, 백업 방식이 고정되어 있습니다. 홈페이지가 단순하고 관리자도 한두 명이면 이쪽이 현실적입니다.
VPS는 비용 대비 자유도가 좋습니다. 1코어 1GB 메모리도 정적 페이지나 가벼운 블로그에는 충분합니다. 다만 운영자가 업데이트, 방화벽, 로그 관리, 백업을 직접 챙겨야 합니다. 저는 트래픽이 애매하게 늘어난 홈페이지라면 2코어 2GB 메모리, SSD 40GB 정도를 첫 기준으로 잡는 편입니다. 여기에 캐시와 이미지 압축을 제대로 넣으면 생각보다 오래 버팁니다.
클라우드 서버는 확장과 장애 대응에는 좋지만, 초보자가 쓰기엔 비용 구조가 복잡합니다. 서버 요금만 보는 게 아니라 스토리지, 스냅샷, 로드밸런서, 트래픽 전송 비용까지 봐야 합니다. 홈페이지 하나 올리려고 시작했다가 부가 서비스가 붙으면서 월 비용이 3배가 되는 경우도 봤습니다.
제가 보는 최소 시작점
- 랜딩 페이지 1~5개: 일반 웹호스팅 또는 정적 호스팅
- 워드프레스 블로그: 1코어 1GB, 캐시 필수
- 소규모 쇼핑몰: 2코어 4GB, DB 백업 분리 권장
- 광고 집행 홈페이지: 피크 동시접속 기준으로 테스트 후 증설
근데 숫자만 믿으면 안 됩니다. 같은 2코어 서버라도 디스크 성능, 가상화 밀도, DB 설정에 따라 체감이 크게 다릅니다. 그래서 새 서버를 잡으면 바로 운영에 넣지 말고, 실제 페이지 20~30개를 열어보면서 응답 시간을 확인하는 게 좋습니다.
홈페이지가 죽는 흔한 원인은 설정과 백업
제가 본 장애 중 상당수는 트래픽보다 운영 습관에서 나왔습니다. 예를 들어 백업 파일을 같은 서버 같은 디스크에 계속 쌓아두면, 어느 날 디스크 사용률이 100%가 됩니다. 그 순간 DB가 쓰기를 못 하고 로그인, 주문, 게시글 저장이 줄줄이 실패합니다.
백업은 최소한 원본 서버와 다른 위치에 있어야 의미가 있습니다. 매일 전체 백업만 돌리는 것도 비효율적입니다. 파일은 주 1회 전체, DB는 매일, 변경이 많은 쇼핑몰은 DB를 하루 2~4회 정도로 나누는 방식이 낫습니다. 보관 기간은 7일, 14일, 30일 중 비용과 복구 필요성을 보고 정하면 됩니다.
- 디스크 사용률은 80%를 넘기기 전에 알림을 걸 것
- 백업 파일은 같은 서버에만 두지 말 것
- 복구 테스트 없이 백업 성공 메시지만 믿지 말 것
- 이미지 원본 업로드 제한을 둘 것
- 관리자 페이지 접근 제한을 걸 것
SSL도 의외로 자주 사고가 납니다. 자동 갱신이 실패했는데 아무도 모르고 있다가 브라우저 경고가 뜨는 식입니다. 인증서 만료 알림은 서버 안에만 두지 말고 외부 모니터링이나 캘린더 알림으로 한 번 더 잡아두는 편이 안전합니다.
이전할 때는 DNS보다 데이터 순서가 먼저
홈페이지 이전은 파일 복사부터 하면 꼬입니다. 먼저 현재 서버의 PHP 버전, DB 버전, 확장 모듈, 문자셋, 업로드 경로를 확인해야 합니다. 특히 오래된 홈페이지는 특정 PHP 버전에 묶여 있는 경우가 많습니다. 새 서버가 더 최신이라도 코드가 바로 동작한다는 보장은 없습니다.
제가 쓰는 순서는 단순합니다. 새 서버 세팅, 파일 복사, DB 가져오기, 임시 접속 테스트, 관리자 기능 확인, 메일 발송 확인, DNS 전환, 이전 서버 보관입니다. 여기서 중요한 건 이전 서버를 바로 끄지 않는 겁니다. 최소 3~7일은 살려둬야 누락 파일이나 DNS 캐시 문제에 대응할 수 있습니다.
DNS TTL은 전환 하루 전쯤 낮춰두면 좋습니다. 300초 정도로 낮춰두면 전환 후 되돌리기도 편합니다. 다만 이미 TTL이 길게 잡혀 있었다면 바로 효과가 나지 않습니다. 그래서 이전 작업은 당일에 급하게 시작하면 안 됩니다.
장애가 났을 때 보는 순서
- 브라우저 오류가 SSL, DNS, 서버 응답 중 어디에 가까운지 확인
- 서버 디스크 사용률과 메모리 부족 여부 확인
- 웹서버와 DB 프로세스 상태 확인
- 최근 변경된 플러그인, 테마, 배포 파일 확인
- 백업에서 복구할지 설정을 되돌릴지 판단
홈페이지 운영은 큰 기술보다 기본값을 의심하는 습관이 더 중요합니다. 방문자가 늘면 서버를 키우면 되지만, 백업이 없거나 복구가 안 되는 구조는 돈을 더 써도 바로 해결되지 않습니다. 처음에는 작게 시작해도 됩니다. 대신 트래픽, 디스크, 백업, SSL 만료일 정도는 숫자로 보고 있어야 합니다. 그 정도만 지켜도 과한 요금제 없이 안정적으로 운영되는 홈페이지가 훨씬 많습니다.
