요즘 상담을 하다 보면 방문자는 하루 2천 명도 안 되는데 클라우드서버부터 크게 잡아야 하는지 묻는 경우가 많아졌습니다. 솔직히 말하면 대부분은 서버가 작아서 죽는 게 아니라, 캐시가 없거나 백업이 없거나 디스크가 꽉 차서 죽습니다. 클라우드서버는 좋은 도구지만, 무조건 큰 요금제가 답은 아닙니다.
클라우드서버는 먼저 용도를 쪼개서 봐야 합니다
블로그, 회사 소개 사이트, 쇼핑몰, 관리자 페이지, 파일 다운로드 서버는 필요한 사양이 다릅니다. 같은 하루 방문자 1만 명이라도 이미지가 많은 사이트와 텍스트 위주 사이트는 부하가 완전히 다릅니다. 그래서 저는 서버를 고를 때 방문자 수보다 페이지 크기, 동시접속, 캐시 적용 여부, 데이터베이스 부하를 먼저 봅니다.
예를 들어 워드프레스 블로그가 캐시를 잘 쓰고 이미지 최적화가 되어 있다면 CPU 1코어, 메모리 1GB급으로도 꽤 버팁니다. 반대로 상품 검색, 회원 로그인, 장바구니, 결제가 계속 붙는 쇼핑몰은 방문자가 적어도 데이터베이스가 먼저 힘들어집니다. 이때는 웹서버보다 DB 메모리와 디스크 IOPS가 더 중요합니다.
트래픽 계산은 월 방문자보다 피크 시간 기준이 맞습니다
월 방문자 10만 명이라는 숫자는 보기 좋지만 서버 산정에는 조금 둔합니다. 중요한 건 몰리는 시간입니다. 하루 방문자 3천 명이라도 점심시간 30분에 절반이 몰리면 체감 부하는 훨씬 큽니다. 저는 대략 피크 시간 요청 수를 잡고, 캐시가 먹히는 요청과 DB까지 가는 요청을 나눠 봅니다.
- 개인 블로그: 캐시 적용 시 1코어, 1~2GB 메모리부터 시작 가능
- 소규모 회사 사이트: 이미지 최적화와 정적 캐시가 있으면 저가형으로 충분한 경우가 많음
- 예약·문의가 있는 사이트: 메모리 2GB 이상, DB 백업과 모니터링 필요
- 소규모 쇼핑몰: 메모리 4GB 이상을 기준으로 보고 DB와 웹을 분리할지 검토
- 파일 다운로드 중심 서비스: CPU보다 전송량, 스토리지 속도, CDN 적용 여부가 중요
근데 여기서 중요한 게 있습니다. 사양을 크게 잡는 것보다 캐시를 제대로 넣는 편이 비용 대비 효과가 훨씬 큽니다. PHP나 Node 애플리케이션이 매 요청마다 DB를 때리는 구조라면 4GB 서버도 금방 버거워집니다. 반대로 정적 캐시가 잘 먹으면 작은 서버도 오래 갑니다.
싼 클라우드서버가 충분한 구간도 분명히 있습니다
운영하다 보면 비싼 서버를 쓰는 것 자체가 안정성이라고 생각하는 분들이 있습니다. 사실 안정성은 요금제보다 구성에서 나옵니다. 자동 재시작, 백업, 모니터링, 로그 관리, 디스크 여유 공간, SSL 갱신 상태가 더 직접적입니다.
하루 방문자 수천 명 이하의 콘텐츠 사이트라면 저가형 클라우드서버에 캐시, 이미지 압축, 기본 보안 설정만 해도 충분한 경우가 많습니다. 특히 정적 페이지나 블로그형 사이트는 CPU를 계속 쓰는 시간이 짧습니다. 서버가 놀고 있는 시간이 훨씬 깁니다. 이런 사이트에 처음부터 고사양 인스턴스를 붙이면 매달 비용만 조용히 새어 나갑니다.
다만 무료나 초저가 서버를 쓸 때는 한계를 알아야 합니다. CPU 사용량 제한, 디스크 성능, 네트워크 전송량, 스냅샷 제공 여부가 약한 경우가 많습니다. 테스트 서버나 랜딩 페이지에는 괜찮지만, 매출이 붙은 운영 서버라면 백업과 복구 시간을 먼저 따져야 합니다.
장애는 대개 설정과 백업에서 시작됩니다
제가 본 장애 중 상당수는 트래픽 폭주가 아니었습니다. 디스크 100퍼센트, 로그 파일 방치, SSL 인증서 만료, DB 비밀번호 변경 후 설정 누락, 방화벽 포트 차단, 백업 파일을 같은 서버에만 둔 경우가 많았습니다. 서버 사양을 올려도 이런 문제는 그대로 터집니다.
클라우드서버 세팅 때 꼭 보는 항목
- 디스크 사용량 알림을 80퍼센트 전후로 설정
- DB와 업로드 파일을 분리해서 백업
- 스냅샷만 믿지 말고 외부 저장소 백업 추가
- SSL 자동 갱신 후 웹서버 재로드 확인
- 방화벽에서 필요한 포트만 열기
- 관리자 접속은 비밀번호보다 키 기반 인증 우선
- 로그 회전 설정으로 디스크 고갈 방지
백업은 있는 것과 복구해 본 것은 다릅니다. 운영자는 백업 파일이 생성되는지만 보면 안 됩니다. 실제로 다른 서버에 풀어서 웹이 뜨는지, DB 문자셋이 깨지지 않는지, 업로드 파일 경로가 맞는지 확인해야 합니다. 저는 최소 분기마다 한 번은 복구 테스트를 권합니다. 사고가 나면 백업 파일을 처음 열어 보는 순간부터 시간이 녹습니다.
처음 고를 때는 작게 시작하고 관측치를 남기면 됩니다
클라우드서버의 장점은 필요할 때 키우기 쉽다는 점입니다. 그래서 처음부터 과하게 잡을 이유가 적습니다. 운영 초기는 1~2주 정도 CPU 사용률, 메모리 사용량, 디스크 I/O, 느린 쿼리, 피크 시간 응답 속도를 보면 됩니다. 이 숫자가 쌓이면 감이 아니라 근거로 증설을 결정할 수 있습니다.
예를 들어 CPU가 평소 10퍼센트인데 피크에만 70퍼센트까지 오른다면 아직 괜찮습니다. 메모리가 계속 90퍼센트 이상이고 스왑을 쓰기 시작하면 증설이나 튜닝이 필요합니다. DB 쿼리 하나가 3초씩 걸리는 상태라면 서버를 키우기 전에 인덱스와 쿼리를 먼저 봐야 합니다. 디스크 I/O가 막히면 CPU를 올려도 체감이 잘 안 좋아집니다.
운영 기준을 잡아 두면 선택이 단순해집니다. 콘텐츠 위주 사이트는 작은 클라우드서버에 캐시와 백업을 단단히 두고 시작합니다. 로그인과 결제가 있는 서비스는 메모리와 DB 안정성을 조금 더 봅니다. 매출이 직접 걸린 사이트는 서버 가격보다 복구 시간과 백업 보관 정책이 더 중요합니다. 저는 서버를 크게 사는 것보다, 작게 시작하되 언제 키울지 숫자로 알 수 있게 만드는 쪽이 더 안정적이라고 봅니다.
