클라우드서버 비용 아끼려면 사양부터 이렇게 잡으세요

트래픽보다 먼저 봐야 할 것은 동시접속입니다

얼마 전 작은 쇼핑몰 이전 상담을 받았는데, 월 방문자가 8만 명이라 클라우드서버를 크게 잡아야 한다고 들었다고 하더군요. 그런데 로그를 보니 피크 시간 동시접속은 35명 안팎이었습니다. 이 정도면 2vCPU, 메모리 4GB급에서도 충분히 버틸 수 있는 구간입니다. 문제는 트래픽 숫자만 보고 서버를 고르면 월 2만 원이면 될 일을 10만 원 넘게 쓰게 된다는 겁니다.

서버 사양은 월 방문자 수보다 피크 시간의 요청 수, PHP나 Node 같은 애플리케이션 처리량, DB 쿼리 상태를 같이 봐야 합니다. 단순 회사 소개 사이트와 로그인·검색·주문이 많은 사이트는 같은 방문자 수라도 필요한 사양이 다릅니다. 이미지가 많은 블로그도 캐시가 제대로 잡혀 있으면 생각보다 가볍습니다.

월 방문자 1만 명 이하의 정적·워드프레스 사이트: 1vCPU, 메모리 1~2GB부터 검토
월 방문자 5만~10만 명의 일반 블로그·회사 사이트: 2vCPU, 메모리 2~4GB 구간이 현실적
회원 기능, 장바구니, 검색이 많은 서비스: CPU보다 DB와 디스크 I/O를 먼저 확인
이벤트 페이지처럼 순간 유입이 큰 경우: 서버 증설보다 캐시와 CDN 구성이 먼저

클라우드서버가 좋은 이유는 처음부터 크게 살 필요가 없다는 점입니다. 작게 시작하고 모니터링을 보면서 올리는 방식이 맞습니다. CPU 사용률이 평소 10%인데 혹시 몰라서 8vCPU를 쓰는 건 보험이 아니라 낭비에 가깝습니다.

초기 사양은 보수적으로, 백업은 공격적으로 잡습니다

제가 운영하면서 많이 본 장애는 트래픽 폭주보다 백업 미비였습니다. 서버는 언제든 다시 만들 수 있지만, 데이터는 사라지면 설명할 말이 없습니다. 클라우드서버를 만들 때 사양보다 먼저 정해야 하는 게 백업 주기입니다. 특히 DB가 있는 사이트는 파일 백업만으로는 복구가 안 됩니다.

초기 기준은 이렇게 잡으면 무난합니다. 웹 파일은 하루 1회, DB는 서비스 성격에 따라 하루 1회에서 6시간 1회, 주문이나 예약 데이터가 있으면 더 촘촘하게 잡습니다. 백업 보관 기간은 최소 7일, 가능하면 14일 이상을 둡니다. 중요한 건 같은 서버 안에만 백업을 두지 않는 겁니다. 디스크가 깨지거나 계정이 잠기면 백업도 같이 못 씁니다.

운영 초기에 확인할 기본값

스냅샷과 파일 백업을 구분해서 설정했는지
DB 덤프가 실제로 생성되는지
백업 파일을 다른 저장소로 복사하는지
복구 테스트를 최소 1회 해봤는지
서버 시간대와 로그 시간이 맞는지

스냅샷은 편하지만 만능은 아닙니다. 서버 전체를 특정 시점으로 되돌리는 용도라서, 특정 게시글이나 주문 데이터만 꺼내야 할 때는 불편합니다. 파일 백업, DB 백업, 서버 스냅샷은 역할이 다릅니다. 셋 중 하나만 있으면 된다고 생각하면 사고 때 손이 묶입니다.

클라우드서버 이전은 DNS보다 데이터 동기화가 어렵습니다

서버 이전을 DNS 변경 작업 정도로 보는 경우가 많습니다. 실제로는 DNS보다 데이터 동기화가 더 까다롭습니다. 방문자가 계속 들어오는 사이트라면 이전 도중에도 게시글, 주문, 회원 가입 데이터가 생깁니다. 이 구간을 어떻게 막거나 동기화할지 정하지 않으면 새 서버로 옮긴 뒤 데이터가 일부 빠집니다.

제가 쓰는 절차는 단순합니다. 먼저 새 클라우드서버를 만들고 웹서버, PHP나 런타임, DB 버전을 기존 서버와 최대한 맞춥니다. 그다음 파일과 DB를 복사하고, 임시 접속으로 화면과 기능을 확인합니다. 문제가 없으면 기존 사이트를 짧게 점검 모드로 전환하고 마지막 DB를 다시 옮깁니다. 이후 DNS를 바꿉니다.

이전 전후로 꼭 보는 항목

웹서버 설정의 업로드 용량, 실행 시간, 리라이트 규칙
DB 문자셋과 타임존
SSL 인증서 발급 상태
메일 발송 서버와 SPF, DKIM 설정
크론 작업과 배치 스크립트
이미지 업로드 경로와 권한

근데 의외로 SSL보다 메일에서 많이 걸립니다. 사이트는 잘 뜨는데 회원가입 메일, 주문 알림, 비밀번호 재설정 메일이 안 나가는 식입니다. 클라우드서버는 기본으로 메일 포트가 제한되는 경우도 있고, 발송 평판 문제도 있습니다. 메일은 외부 발송 서비스를 쓰는 편이 관리가 편할 때가 많습니다.

장애가 났을 때는 큰 것부터 보지 않습니다

사이트가 안 뜨면 다들 서버가 죽었다고 생각합니다. 사실 현장에서는 작은 설정 하나가 원인인 경우가 많습니다. 디스크 100%, SSL 만료, DB 접속 정보 변경, 방화벽 포트 누락, DNS 레코드 오타 같은 것들입니다. 그래서 장애 대응은 추측보다 순서가 중요합니다.

먼저 도메인이 올바른 서버를 보고 있는지 확인합니다. 그다음 서버 접속 가능 여부, 웹서버 실행 상태, 방화벽, 디스크 용량, DB 상태를 순서대로 봅니다. 애플리케이션 로그는 그 다음입니다. 처음부터 코드부터 뒤지면 시간을 잃습니다. 인프라 문제는 바깥에서 안쪽으로 좁혀가는 게 빠릅니다.

도메인 연결: A 레코드와 변경 전파 상태 확인
서버 상태: CPU, 메모리, 디스크, 네트워크 확인
웹서버: Nginx 또는 Apache 실행 여부와 설정 오류 확인
DB: 접속 가능 여부, 슬로우 쿼리, 용량 확인
SSL: 인증서 만료일과 자동 갱신 실패 여부 확인

클라우드서버의 장점은 장애 때 새 인스턴스를 빨리 만들 수 있다는 점입니다. 하지만 백업과 설정 문서가 없으면 새 서버를 만들어도 복구가 늦습니다. 서버 사양표보다 중요한 게 운영 메모입니다. 어느 포트를 열었는지, 인증서는 어디서 갱신하는지, 배포는 어떤 계정으로 하는지 정도는 따로 적어둬야 합니다.

비싼 서버보다 잘 맞는 서버가 오래 갑니다

초보자가 클라우드서버를 고를 때 가장 많이 하는 실수는 처음부터 완벽한 사양을 찾으려는 겁니다. 운영에서는 완벽한 첫 선택보다 조정 가능한 구조가 더 중요합니다. 모니터링을 달고, 백업을 분리하고, 캐시를 켜고, 필요할 때 한 단계씩 올리면 됩니다.

개인 블로그나 작은 회사 사이트라면 무료 티어, 저가 VPS, 작은 클라우드서버로도 충분한 경우가 많습니다. 반대로 매출이 바로 걸린 쇼핑몰이나 예약 서비스라면 월 서버비 몇 만 원보다 백업, 모니터링, 복구 절차에 비용을 쓰는 게 맞습니다. 서버는 빠른 것도 중요하지만, 문제가 생겼을 때 어디까지 되돌릴 수 있는지가 더 중요합니다.

저라면 처음부터 큰 요금제를 권하지 않습니다. 현재 트래픽과 피크 동시접속을 보고 작은 사양으로 시작한 뒤, 2주 정도 CPU·메모리·디스크 I/O·DB 상태를 봅니다. 그 데이터로 올릴지 유지할지 판단합니다. 감으로 고른 서버보다 숫자로 고른 작은 서버가 더 안정적인 경우를 정말 많이 봤습니다.