요즘 클라우드 서버 견적을 봐달라는 요청이 많아졌습니다. 얼마 전에도 하루 방문자 3천 명 정도 되는 워드프레스 사이트에 8코어 16GB 서버를 쓰고 있는 경우를 봤습니다. 운영자는 느려질까 봐 불안해서 올렸다고 했는데, 실제 병목은 서버 사양이 아니라 이미지 원본 용량과 백업 플러그인 동작 시간이었습니다.
클라우드는 좋은 도구입니다. 그런데 좋은 도구라고 해서 무조건 크게 잡을 필요는 없습니다. 서버는 트래픽, 동시접속, DB 사용량, 백업 방식, 장애 복구 기준을 보고 고르는 게 맞습니다. 이름이 클라우드라서 자동으로 안전해지는 것도 아니고, 비싼 요금제라고 장애가 사라지는 것도 아닙니다.
클라우드 서버는 사양보다 사용 패턴부터 봐야 합니다
처음 서버를 고를 때 가장 많이 하는 실수가 월 방문자 수만 보는 겁니다. 월 10만 명 방문자가 있다고 해도 하루에 고르게 들어오면 부담이 크지 않습니다. 반대로 월 방문자는 적어도 특정 시간에 몰리면 작은 서버가 바로 버벅입니다.
제가 먼저 보는 값은 대략 네 가지입니다. 피크 시간 동시접속, 페이지당 평균 요청 수, DB 쿼리 무게, 관리자 작업 패턴입니다. 쇼핑몰처럼 로그인과 장바구니가 많은 사이트는 단순 블로그보다 같은 방문자 수에서도 서버를 더 씁니다. 반면 정적 페이지 위주의 회사 소개 사이트는 아주 작은 사양으로도 오래 버팁니다.
- 일 방문자 1천 명 이하 블로그: 1vCPU, 1GB 메모리도 충분한 경우가 많음
- 일 방문자 5천 명 안팎 워드프레스: 2vCPU, 2GB 메모리부터 확인
- 동시접속 100명 이상 커뮤니티: CPU보다 DB와 캐시 구조를 먼저 점검
- 이미지·파일 다운로드가 많은 사이트: 서버 사양보다 트래픽 요금과 스토리지 I/O 확인
물론 이건 출발점입니다. PHP, Node, Java, DB가 같은 서버에 있는지에 따라 달라집니다. 그래도 처음부터 8GB, 16GB로 올리는 것보다 작은 사양에서 모니터링하면서 올리는 편이 비용 면에서 훨씬 낫습니다.
초기 사양은 작게 잡고 지표로 올리는 게 안전합니다
클라우드의 장점은 필요할 때 사양을 올리기 쉽다는 점입니다. 그래서 처음부터 크게 잡는 방식은 클라우드답지 않습니다. 저는 운영 초기에 CPU 사용률, 메모리 사용량, 디스크 I/O, 네트워크 전송량을 최소 1주일은 봅니다. 광고 집행이나 이벤트가 있다면 그 기간은 따로 봐야 합니다.
CPU가 80%를 자주 넘는다고 바로 코어를 늘릴 필요는 없습니다. 짧은 피크인지, 백업 시간대인지, 검색 엔진 봇이 몰린 건지 봐야 합니다. 실제로 새벽 3시에 CPU가 치솟는 서버를 보면 백업 압축이 원인인 경우가 많습니다. 방문자는 자고 있는데 서버 혼자 열심히 압축 파일을 만들고 있는 겁니다.
메모리는 조금 다릅니다. 리눅스는 캐시 때문에 메모리를 많이 쓰는 것처럼 보일 수 있습니다. 그래서 단순 사용률보다 스왑 발생 여부를 봐야 합니다. 스왑이 계속 생기면 체감 속도가 확 떨어집니다. 이때는 메모리를 늘리거나, DB 설정과 PHP 워커 수를 줄여야 합니다.
제가 자주 쓰는 시작 기준
- 가벼운 랜딩 페이지: 1vCPU, 1GB 메모리, 정적 캐시 적용
- 일반 워드프레스 블로그: 1~2vCPU, 2GB 메모리, 페이지 캐시 필수
- 작은 쇼핑몰: 2vCPU, 4GB 메모리, DB 백업 분리 권장
- 업무용 관리자 페이지: 사용 시간대와 배치 작업 시간을 분리해서 산정
싼 요금제가 나쁘다는 인식도 있는데, 사실 저가 클라우드나 VPS로 충분한 구간이 꽤 넓습니다. 문제는 싼 서버를 쓰는 게 아니라, 백업 없이 쓰거나 장애 알림 없이 쓰는 겁니다. 그게 진짜 위험합니다.
장애는 트래픽보다 설정에서 더 자주 납니다
사이트가 죽었다고 연락이 오면 다들 트래픽 폭증부터 의심합니다. 그런데 현장에서 보면 원인은 훨씬 평범합니다. 디스크가 꽉 찼거나, SSL 인증서 자동 갱신이 실패했거나, 방화벽에서 필요한 포트를 막았거나, DB 비밀번호를 바꾼 뒤 애플리케이션 설정을 안 바꾼 경우가 많습니다.
클라우드 서버도 결국 리눅스 서버입니다. 보안 그룹, 방화벽, SSH 키, 웹서버 설정, DB 접속 권한이 맞아야 정상으로 돕니다. 관리형 서비스가 아니면 운영 책임은 사용자에게 남습니다. 콘솔 화면이 예쁘다고 운영 난도가 사라지는 건 아닙니다.
- 디스크 사용률 90% 이상: 로그와 백업 파일부터 확인
- 사이트 접속 불가: DNS, 보안 그룹, 웹서버 프로세스 순서로 확인
- 간헐적 502 오류: PHP-FPM, 프록시 타임아웃, 메모리 부족 확인
- SSL 오류: 인증서 만료일과 자동 갱신 로그 확인
- DB 접속 오류: 계정 권한, 비밀번호, 내부 IP 변경 여부 확인
저는 장애 대응 순서를 문서로 남겨두는 편을 권합니다. 머릿속으로만 알고 있으면 새벽 장애 때 꼭 빠뜨립니다. 특히 클라우드 콘솔에서 인스턴스 재시작 버튼부터 누르는 습관은 위험합니다. 원인을 못 본 상태에서 재시작하면 로그가 흩어지고, 같은 문제가 다시 납니다.
백업은 스냅샷 하나로 끝내면 안 됩니다
클라우드 업체마다 스냅샷 기능이 있습니다. 편합니다. 하지만 스냅샷만 믿으면 곤란합니다. 스냅샷은 서버 전체 시점 복구에는 좋지만, 특정 글 하나나 DB 테이블 일부를 되돌릴 때는 불편합니다. 그리고 같은 계정, 같은 리전에만 있으면 계정 잠금이나 운영자 실수에 취약합니다.
제가 선호하는 방식은 3단계입니다. 첫째, DB는 매일 논리 백업을 남깁니다. 둘째, 파일은 변경분 기준으로 따로 보관합니다. 셋째, 서버 스냅샷은 큰 변경 전과 주기 백업으로 씁니다. 이 셋이 같이 있어야 복구 선택지가 생깁니다.
최소 백업 기준
- DB 백업: 하루 1회 이상, 보관 기간 7~30일
- 파일 백업: 업로드 파일과 설정 파일을 분리해서 보관
- 스냅샷: 업데이트 전, 서버 이전 전, 월 1회 이상
- 복구 테스트: 최소 분기 1회는 별도 서버에서 확인
백업은 만들어지는 것보다 복구되는 게 중요합니다. 백업 파일이 있어도 압축이 깨져 있거나 DB 문자셋이 맞지 않으면 실제 복구 때 시간이 길어집니다. 운영자는 백업 성공 알림보다 복구 테스트 결과를 더 믿어야 합니다.
클라우드 비용은 서버 요금만 보면 틀립니다
클라우드 견적을 볼 때 월 서버 요금만 비교하면 나중에 계산이 어긋납니다. 트래픽, 스냅샷, 블록 스토리지, 로드밸런서, 공인 IP, 관리형 DB 비용이 따로 붙는 경우가 많습니다. 작은 사이트는 서버보다 백업 스토리지와 트래픽 비용이 더 신경 쓰일 때도 있습니다.
예를 들어 월 서버 요금이 낮아 보여도 아웃바운드 트래픽 과금이 세면 이미지 많은 사이트에서 비용이 튈 수 있습니다. 반대로 방문자는 많지 않은데 DB 안정성이 중요한 업무 시스템이면 관리형 DB가 더 나은 선택일 수 있습니다. 비용은 단순히 싸고 비싼 문제가 아니라, 내가 직접 운영할 범위와 업체에 맡길 범위를 나누는 문제입니다.
처음 시작하는 블로그나 회사 사이트라면 작은 클라우드 서버에 캐시, 자동 백업, 장애 알림을 붙이는 조합이 현실적입니다. 트래픽이 늘면 서버 증설보다 CDN, 이미지 최적화, DB 분리 순서로 보는 게 좋습니다. 실제 운영에서는 서버 한 대를 크게 키우는 것보다 병목을 줄이는 쪽이 오래 갑니다.
클라우드는 비싸게 쓰면 편해지는 구간이 있지만, 작게 잘 쓰면 비용 대비 성능이 아주 좋습니다. 저는 새 사이트라면 먼저 작은 사양으로 시작하고, 숫자를 보고 올리는 쪽을 권합니다. 운영은 감으로 하는 일이 아니라 기록을 보고 조정하는 일에 가깝습니다.
