얼마 전 작은 쇼핑몰 이전 작업을 봤는데, 월 방문자가 3만 명 정도인데도 8코어 서버를 쓰고 있었습니다. 이유를 물어보니 예전에 한 번 사이트가 느려진 뒤로 업체가 권한 상품을 그대로 올렸다고 하더군요. 그런데 로그를 까보니 병목은 CPU가 아니라 이미지 원본 노출과 백업 작업 시간이었습니다. 서버 사양을 올리는 것보다 이미지 리사이즈, 캐시, 백업 시간 조정이 먼저였죠.
클라우드서버는 좋은 도구입니다. 다만 자유도가 높은 만큼 과하게 쓰기도 쉽습니다. 웹호스팅보다 비싸서 좋은 게 아니라, 내가 필요한 CPU, 메모리, 디스크, 트래픽을 직접 잡을 수 있어서 쓰는 겁니다. 그래서 처음부터 큰 요금제를 고르는 방식은 별로 추천하지 않습니다.
클라우드서버가 필요한 구간부터 봐야 합니다
작은 회사 소개 사이트, 포트폴리오, 하루 방문자 수백 명짜리 블로그는 대부분 일반 웹호스팅으로도 충분합니다. PHP 기반 사이트에 DB가 크지 않고, 동시 접속이 10명 안쪽이면 월 몇 천 원짜리 호스팅에서도 버팁니다. 이 구간에서 클라우드서버를 쓰면 성능보다 운영 부담이 먼저 옵니다. 보안 업데이트, 방화벽, 백업, 장애 대응을 직접 봐야 하니까요.
클라우드서버가 필요한 시점은 조금 다릅니다. 배포 환경을 직접 제어해야 하거나, 특정 런타임이 필요하거나, 트래픽이 들쭉날쭉하거나, 웹서버와 DB를 분리할 계획이 있을 때 의미가 있습니다. 예를 들어 Node 기반 서비스, Python API, 예약 발송 작업, 검색 엔진, 별도 캐시 서버가 필요한 경우라면 웹호스팅보다 VPS나 클라우드서버가 맞습니다.
- 일 방문자 1천 명 이하의 단순 소개 사이트: 일반 웹호스팅 검토
- 일 방문자 1만 명 안팎의 블로그나 쇼핑몰: 저사양 VPS부터 검토
- 동시 접속 100명 이상이 자주 발생하는 서비스: CPU와 DB 분리 계획 필요
- 이미지, 영상, 다운로드 파일이 많은 사이트: 서버 사양보다 전송량과 저장소 구조 먼저 확인
사양은 방문자 수보다 동시 접속으로 계산합니다
서버 견적을 낼 때 월 방문자만 보는 경우가 많습니다. 그런데 서버가 힘들어지는 순간은 월 방문자 수가 아니라 같은 시간에 얼마나 몰리느냐입니다. 월 30만 명이 와도 하루 종일 고르게 들어오면 작은 서버로 버틸 수 있고, 월 5만 명이라도 이벤트 문자 한 번에 500명이 동시에 들어오면 바로 느려질 수 있습니다.
대략적인 기준을 잡아보면, 워드프레스나 일반 PHP 사이트 기준으로 동시 접속 20명 안쪽은 1~2코어, 메모리 1~2GB부터 시작해도 됩니다. 캐시가 잘 잡혀 있으면 더 낮아도 됩니다. 동시 접속 50명 전후라면 2코어, 4GB를 먼저 보고, DB 쿼리가 무겁거나 관리자 작업이 많으면 4코어를 봅니다. 동시 접속 100명을 넘기면 이제 단일 서버만 키울지, 웹과 DB를 나눌지 판단해야 합니다.
여기서 조심할 점이 있습니다. CPU 코어를 늘려도 느린 쿼리, 외부 API 지연, PHP 워커 부족, 디스크 I/O 병목은 그대로 남습니다. 실제로 장애 현장을 보면 CPU 사용률은 30퍼센트인데 사이트가 멈춘 경우가 흔합니다. DB 커넥션이 꽉 찼거나, 백업 압축이 디스크를 잡아먹거나, 로그 파일이 파티션을 채운 경우가 더 많습니다.
처음 구성은 작게 시작하고 관측 지표를 붙입니다
처음 클라우드서버를 열 때 제가 자주 잡는 출발점은 2코어, 2GB 또는 2코어, 4GB입니다. 트래픽이 아직 검증되지 않은 신규 사이트라면 1코어, 1GB도 가능하지만, 관리 패널이나 DB까지 같이 얹으면 금방 답답해집니다. 쇼핑몰이나 예약 사이트처럼 관리자가 자주 상품을 올리고 주문을 처리한다면 4GB 쪽이 덜 피곤합니다.
디스크는 용량보다 종류와 백업 방식이 중요합니다. 30GB 디스크에 이미지 20GB를 넣고 같은 서버 안에서 압축 백업을 돌리면 남은 공간이 순식간에 사라집니다. 최소한 운영 데이터와 백업 데이터는 분리하는 편이 낫습니다. DB 백업은 매일, 파일 백업은 변경량에 맞춰 주기를 나누고, 월 1회 정도는 복구 테스트를 해야 합니다. 백업 파일이 있다는 것과 복구가 된다는 것은 완전히 다른 말입니다.
- CPU: 동시 요청과 PHP 워커 수를 기준으로 판단
- 메모리: 웹서버, DB, 캐시, 관리 패널이 같이 쓰는 총량으로 계산
- 디스크: 원본 파일, 로그, 임시 파일, 백업 압축 공간까지 포함
- 트래픽: 페이지 용량 곱하기 방문 수로 월 전송량 추산
비용 비교는 월 요금이 아니라 장애 비용까지 봅니다
클라우드서버 요금표만 보면 월 1만 원 차이가 커 보입니다. 그런데 운영에서는 백업 미설정으로 날아가는 하루가 더 비쌉니다. 쇼핑몰이라면 주문 누락, 광고비 손실, CS 대응까지 붙습니다. 그래서 비용을 줄이려면 무조건 싼 서버가 아니라, 작은 서버에 필요한 안전장치를 붙이는 쪽이 맞습니다.
예를 들어 월 1만 원대 VPS에 자동 스냅샷, 외부 저장소 백업, 기본 모니터링을 붙이면 월 2만~3만 원 선에서도 꽤 안정적인 구성이 나옵니다. 반대로 월 10만 원짜리 서버를 쓰면서 백업이 같은 디스크 안에만 있으면 운영 관점에서는 위험합니다. 서버가 커도 삭제, 랜섬웨어, 계정 탈취, 디스크 장애 앞에서는 별 차이가 없습니다.
저가 서버를 쓸 때는 네트워크 품질과 디스크 성능 편차도 봐야 합니다. 관리자 화면은 빠른데 결제 시간에만 느리거나, 새벽 백업 때 사이트가 버벅이면 대개 I/O가 원인입니다. 모니터링에서 CPU, 메모리만 보지 말고 디스크 사용률, 로드 애버리지, DB slow query, 웹서버 에러 로그를 같이 봐야 합니다.
이전할 때 사고 나는 지점을 먼저 막습니다
클라우드서버 이전은 파일 복사보다 순서가 중요합니다. 먼저 기존 서버에서 파일과 DB 용량을 확인하고, 새 서버에 같은 런타임 버전과 확장 모듈을 맞춥니다. 그다음 테스트 도메인이나 로컬 hosts 설정으로 화면과 관리자 기능을 확인합니다. 이 단계를 건너뛰면 DNS를 바꾼 뒤에야 깨진 이미지를 보게 됩니다.
DNS 변경 전에는 TTL을 낮춰두는 게 좋습니다. 보통 하루 전쯤 짧게 낮춰두면 이전 당일 전파 대기 시간이 줄어듭니다. DB가 계속 변경되는 쇼핑몰은 최종 동기화 시간을 따로 잡아야 합니다. 게시판, 주문, 회원가입이 열려 있는 상태에서 파일만 복사하면 새 서버와 기존 서버 데이터가 갈라집니다.
- 이전 전: 용량, PHP 버전, DB 버전, SSL 상태 확인
- 이전 중: 파일 복사 후 DB 최종 동기화, 관리자 기능 점검
- DNS 변경 후: 에러 로그, 접속 로그, 결제와 메일 발송 확인
- 이전 후: 기존 서버는 바로 삭제하지 말고 며칠 보관
제가 보는 좋은 클라우드서버 선택은 큰 사양을 고르는 일이 아닙니다. 지금 트래픽에서 필요한 만큼만 쓰고, 로그를 보면서 올릴 준비를 해두는 일에 가깝습니다. 서버는 나중에 키우면 되지만, 백업 없이 날아간 데이터는 계산서를 다시 낸다고 돌아오지 않습니다. 그래서 저는 사양표보다 백업표를 먼저 봅니다.
