얼마 전 작은 쇼핑몰 이전 작업을 봤는데, 월 방문자 수는 많지 않은데도 서버호스팅 비용이 꽤 높게 나가고 있었습니다. 막상 로그를 까보니 서버가 부족한 게 아니라 백업 압축 작업이 피크 시간에 돌고 있었고, 이미지 캐시 설정도 빠져 있었습니다. 이런 경우는 생각보다 흔합니다. 트래픽이 문제처럼 보이지만 실제 원인은 설정, 백업, 디스크, DNS 전환 순서인 경우가 더 많습니다.
서버호스팅은 비싼 요금제를 고르는 일이 아닙니다. 내 사이트가 어느 정도의 요청을 처리해야 하고, 장애가 났을 때 어디까지 버틸지 정하는 일에 가깝습니다. 그래서 처음부터 CPU 코어 수만 보는 건 순서가 조금 빗나갑니다. 방문자 수, 동시접속, 페이지 무게, DB 사용량, 백업 방식부터 봐야 합니다.
서버호스팅 사양은 동시접속부터 계산합니다
월 방문자 수만 보고 서버를 고르면 대개 과하게 잡습니다. 중요한 건 동시에 들어오는 사람이 몇 명인지입니다. 예를 들어 월 방문자 3만 명인 블로그라도 하루 평균으로 나누면 1,000명 수준이고, 피크 시간에 50명이 몰릴 수 있습니다. 반대로 월 방문자 1만 명이어도 이벤트 문자 발송 직후 300명이 한꺼번에 들어오면 체감 부하는 훨씬 큽니다.
일반적인 워드프레스 블로그나 회사 소개 사이트라면 캐시가 잘 잡힌 상태에서 저가 VPS 1코어, 메모리 1GB~2GB로도 버티는 구간이 꽤 넓습니다. 다만 관리자 접속이 잦고, 플러그인이 많고, 상품 검색이나 주문 처리처럼 DB 쓰기가 많은 사이트는 메모리 2GB부터 보는 편이 낫습니다. 서버호스팅에서 메모리는 여유가 너무 적으면 바로 장애로 이어집니다. CPU는 순간적으로 치솟고 내려오지만, 메모리는 부족해지면 프로세스가 죽거나 스왑으로 밀려 사이트가 굼떠집니다.
대략적인 기준
- 개인 블로그, 랜딩페이지: 1코어, 메모리 1GB~2GB, 캐시 필수
- 소규모 회사 사이트: 1~2코어, 메모리 2GB, 이미지 최적화 권장
- 소형 쇼핑몰: 2코어, 메모리 4GB부터 시작, DB 백업 시간 분리
- 예약, 결제, 회원 기능 많은 서비스: 웹과 DB 분리 여부를 먼저 검토
이 숫자는 절대값이 아닙니다. 같은 2코어 서버라도 PHP 버전, 웹서버 설정, DB 인덱스, 캐시 유무에 따라 체감 성능이 완전히 달라집니다. 그래도 처음 견적을 잡을 때는 이 정도 선에서 시작하면 불필요한 지출을 많이 줄일 수 있습니다.
트래픽보다 디스크와 백업이 먼저 터집니다
현장에서 자주 보는 장애는 대역폭 초과보다 디스크 100%입니다. 로그가 계속 쌓이고, 백업 파일이 같은 서버 안에 남고, 이미지 원본까지 그대로 보관되면 어느 날 업로드가 안 되거나 DB가 멈춥니다. 운영자는 서버가 죽었다고 느끼지만 실제로는 남은 공간이 0에 가까운 상태입니다.
백업은 꼭 필요하지만 방식이 더 중요합니다. 매일 새벽 전체 압축 백업을 같은 디스크에 만들면, 백업 중 CPU와 디스크 I/O가 같이 올라갑니다. 방문자가 적은 사이트도 이 시간에 관리자 작업이나 검색봇 접근이 겹치면 응답이 느려집니다. 저는 최소한 운영 디스크와 백업 보관 위치는 분리하는 쪽을 권합니다. 같은 서버 안에 백업 하나를 두는 건 빠른 복구용으로는 괜찮지만, 서버 자체가 날아가면 같이 사라집니다.
백업은 이렇게 잡는 편이 안전합니다
- DB는 매일, 파일은 변경량에 따라 주 1~3회
- 백업 파일은 운영 서버 밖에 1개 이상 보관
- 최근 7일, 최근 4주, 최근 3개월처럼 보관 주기 분리
- 복구 테스트를 최소 분기 1회 실행
백업은 만들어졌다는 메시지만 믿으면 안 됩니다. 압축 파일이 깨졌거나, DB 덤프가 중간에 끊겼거나, 문자셋이 맞지 않아 복구 후 글자가 깨지는 경우가 있습니다. 백업 정책을 세웠다면 실제로 새 서버에 올려서 로그인까지 되는지 확인해야 합니다. 백업은 저장이 아니라 복구까지가 작업입니다.
공유호스팅, VPS, 클라우드 서버는 역할이 다릅니다
서버호스팅을 고를 때 공유호스팅을 무조건 낮게 보는 분들이 있습니다. 그런데 방문자 수가 적고 서버 설정을 직접 만질 일이 없다면 공유호스팅이 더 편하고 싸게 먹힙니다. 보안 패치, 메일, 기본 백업, 관리 도구를 업체가 어느 정도 맡아주기 때문입니다. 블로그, 포트폴리오, 작은 회사 사이트는 공유호스팅으로도 충분한 경우가 많습니다.
VPS는 자유도가 올라가는 대신 운영 책임도 같이 옵니다. 방화벽, SSH 접속, 웹서버 설정, DB 튜닝, SSL 갱신, 보안 업데이트를 직접 봐야 합니다. 클라우드 서버는 확장성과 네트워크 구성이 좋지만, 스냅샷, 로드밸런서, 트래픽, 스토리지 비용이 따로 붙을 수 있습니다. 처음 월 비용은 낮아 보여도 부가 항목을 넣으면 예상보다 올라갑니다.
저는 작은 사이트라면 공유호스팅에서 시작해도 된다고 말합니다. 단, PHP 버전 선택, SSL 자동 적용, 백업 다운로드, 트래픽 초과 정책은 확인해야 합니다. VPS로 넘어가는 시점은 명확합니다. 서버 설정을 직접 바꿔야 하거나, 특정 모듈이 필요하거나, DB 부하가 커져 격리가 필요할 때입니다.
이전 작업은 DNS보다 데이터 동기화가 먼저입니다
서버 이전에서 제일 위험한 순간은 DNS를 바꾸는 때가 아닙니다. 새 서버와 기존 서버의 데이터 차이가 벌어지는 시간입니다. 게시판, 쇼핑몰, 예약 사이트는 이전 중에도 글, 주문, 회원 정보가 계속 생깁니다. 이 상태에서 파일만 복사하고 DNS를 넘기면 일부 데이터가 사라진 것처럼 보일 수 있습니다.
이전 절차는 단순하게 잡아야 사고가 적습니다. 먼저 새 서버에 웹서버와 DB 버전을 맞추고, 파일과 DB를 1차 복사합니다. 그다음 테스트 도메인이나 hosts 설정으로 화면, 로그인, 업로드, 결제 모듈, 관리자 기능을 확인합니다. 실제 전환 직전에는 게시판 쓰기나 주문 접수를 잠시 막고 DB를 한 번 더 옮깁니다. 그 뒤 DNS를 바꾸고 로그를 보면서 오류를 확인합니다.
이전 전 확인할 항목
- PHP, Node, Python 등 런타임 버전
- DB 버전과 문자셋
- 업로드 폴더 권한
- SSL 인증서 적용 상태
- 메일 발송 방식과 SPF, DKIM 설정
- 크론 작업과 백업 스케줄
특히 메일은 자주 빠집니다. 사이트는 정상인데 주문 메일이 안 가거나, 비밀번호 재설정 메일이 스팸으로 들어가는 식입니다. 서버호스팅 이전은 화면만 뜨면 끝난 것처럼 보이지만, 운영 입장에서는 알림, 예약 작업, 백업, 로그까지 돌아야 정상입니다.
장애가 나면 업그레이드 전에 로그부터 봅니다
사이트가 느리면 바로 상위 요금제로 올리는 경우가 있습니다. 물론 자원이 부족한 때도 있습니다. 하지만 먼저 봐야 할 건 서버 상태와 로그입니다. CPU가 높은지, 메모리가 부족한지, 디스크가 꽉 찼는지, DB 쿼리가 밀리는지에 따라 처방이 다릅니다. 원인을 모르고 사양만 올리면 비용은 늘고 같은 장애가 다시 옵니다.
확인 순서는 단순합니다. 접속 자체가 안 되면 DNS와 웹서버 프로세스를 봅니다. 접속은 되는데 느리면 CPU, 메모리, DB 연결 수를 봅니다. 특정 페이지만 느리면 애플리케이션 로그와 쿼리 로그를 봅니다. 업로드나 글쓰기만 안 되면 디스크 용량과 폴더 권한을 봅니다. SSL 오류는 인증서 만료일과 중간 인증서 적용 상태를 확인합니다.
서버호스팅은 크게 잡는 것보다 꾸준히 보는 쪽이 운영비를 줄입니다. 작은 서버라도 캐시, 백업 분리, 로그 관리, 보안 업데이트가 잡혀 있으면 오래 갑니다. 반대로 큰 서버도 백업이 같은 디스크에 쌓이고 DB 인덱스가 무너지면 금방 느려집니다. 저는 처음부터 비싼 상품을 고르기보다, 현재 트래픽을 숫자로 보고 한 단계씩 올리는 방식을 더 신뢰합니다. 서버는 겁먹고 사는 장비가 아니라, 기준을 정하고 관리하는 도구에 가깝습니다.
