모두
모두콘텐츠
요즘 상담을 받다 보면 클라우드 서버를 처음 쓰는 분들이 생각보다 큰 사양부터 고르는 경우가 많습니다. 방문자는 하루 2천 명인데 4코어 16GB 메모리 서버를 잡아놓고, 정작 백업은 같은 디스크 안에만 두는 식입니다. 14년 동안 웹서버와 호스팅 인프라를 운영하면서 느낀 건 단순합니다. 사이트가 멈추는 원인은 트래픽 폭증보다 설정 실수, 디스크 부족, 백업 부재가 훨씬 많습니다.
클라우드는 좋은 도구입니다. 필요한 만큼 늘리고 줄일 수 있고, 장애 대응 옵션도 많습니다. 그런데 그만큼 과금 항목도 잘게 쪼개져 있습니다. 서버 요금만 보고 시작했다가 트래픽, 스토리지, 스냅샷, 로드밸런서, 공인 IP 비용에서 예상보다 많이 나오는 경우가 있습니다. 그래서 처음부터 “좋은 서버”를 고르기보다 “내 사이트가 실제로 필요한 서버”를 계산해야 합니다.
클라우드 서버는 방문자 수보다 동시접속부터 봐야 합니다
웹사이트 사양을 잡을 때 하루 방문자 수만 보면 판단이 흐려집니다. 하루 1만 명이 들어와도 24시간 고르게 분산되면 부담이 크지 않습니다. 반대로 하루 2천 명이어도 특정 시간 10분에 몰리면 작은 서버가 버거울 수 있습니다. 그래서 저는 보통 동시접속, 페이지 생성 방식, 캐시 적용 여부를 먼저 봅니다.
예를 들어 워드프레스 블로그 기준으로 정적 캐시가 잘 걸려 있고 이미지가 외부 스토리지나 CDN으로 빠져 있다면 1코어 1GB 또는 2GB 메모리 서버로도 꽤 버팁니다. 하루 방문자 3천~5천 명 수준의 콘텐츠 사이트라면 무조건 비싼 클라우드 인스턴스로 갈 이유가 없습니다. 반면 로그인 사용자가 많고, 검색 기능이 무겁고, 관리자 화면에서 주문·예약 처리가 계속 발생하는 사이트는 같은 방문자 수라도 CPU와 DB 부하가 다르게 나옵니다.
- 개인 블로그, 회사 소개 사이트: 1코어, 1~2GB 메모리부터 시작 가능
- 콘텐츠가 많은 워드프레스: 2코어, 2~4GB 메모리 권장
- 쇼핑몰, 예약 사이트: 웹서버와 DB 분리 여부 검토
- 광고 집행으로 순간 유입이 있는 사이트: 캐시, CDN, 오토스케일보다 먼저 병목 확인
근데 여기서 중요한 게 있습니다. 사양이 낮아도 설정이 잘 되어 있으면 오래 버티고, 사양이 높아도 PHP 워커 수나 DB 커넥션이 엉망이면 금방 막힙니다. 클라우드는 만능이 아니라 조절 가능한 서버입니다.
싼 요금제로 충분한 구간이 분명히 있습니다
처음 시작하는 사이트라면 월 몇만 원짜리 클라우드 서버보다 일반 웹호스팅이 더 나은 경우도 많습니다. 특히 트래픽이 적고 서버 설정을 직접 만질 일이 없다면 관리형 웹호스팅이 운영 부담을 줄여줍니다. SSL, 백업, 메일, 기본 보안 설정까지 포함된 상품이면 초반에는 꽤 합리적입니다.
클라우드가 필요한 순간은 보통 명확합니다. 특정 버전의 런타임이 필요하거나, 루트 권한으로 서버 설정을 바꿔야 하거나, 트래픽 패턴이 들쭉날쭉해서 자원을 유연하게 조정해야 할 때입니다. 그냥 “요즘은 클라우드가 대세”라는 이유만으로 옮기면 운영 책임만 늘어납니다.
실제로 작은 회사 홈페이지를 VPS로 옮겨달라는 요청을 받은 적이 있습니다. 하루 방문자는 300명 정도였고, 문의 폼과 공지사항 외에는 기능이 거의 없었습니다. 확인해보니 기존 웹호스팅에서 느렸던 이유는 서버 사양이 아니라 이미지 원본을 그대로 올린 것과 캐시 미사용이었습니다. 이미지 압축하고 캐시 플러그인 설정하니 이전 없이 해결됐습니다. 이런 경우 클라우드 이전은 비용과 관리 포인트만 늘리는 선택입니다.
서버 비용은 CPU보다 디스크와 트래픽에서 새는 경우가 많습니다
클라우드 견적을 볼 때 많은 분들이 vCPU와 메모리만 봅니다. 그런데 실제 청구서를 보면 스토리지, 스냅샷, 아웃바운드 트래픽, 로드밸런서, 백업 보관 비용이 붙습니다. 특히 이미지가 많은 사이트는 트래픽 비용을 따로 계산해야 합니다.
대략 페이지 하나가 2MB이고 하루 1만 페이지뷰가 나온다면 하루 전송량은 20GB 수준입니다. 한 달이면 600GB입니다. 여기에 검색 봇, 관리자 접속, 이미지 재요청, 캐시 미스까지 포함하면 더 올라갑니다. 이미지 최적화 없이 클라우드로 옮긴 사이트가 서버 사양은 낮은데 트래픽 비용만 커지는 일이 흔합니다.
디스크도 비슷합니다. 웹서버 안에 업로드 파일, DB 백업, 로그, 스냅샷을 모두 쌓아두면 어느 날 갑자기 디스크 100%가 됩니다. 사이트가 느려지는 정도로 끝나면 다행이고, DB가 쓰기 실패를 내면 복구가 번거로워집니다. 그래서 저는 작은 서버라도 로그 보관 기간, 백업 위치, 스냅샷 주기를 먼저 정합니다.
- 접속 로그는 보관 기간을 정하고 압축 또는 삭제
- DB 백업은 서버 내부와 외부 저장소를 분리
- 스냅샷은 복구용이지 장기 보관소가 아님
- 이미지는 압축하고 가능하면 CDN 적용
- 디스크 사용률 80% 전에 알림 설정
이전할 때는 새 서버보다 되돌아갈 길이 먼저입니다
클라우드 이전 작업에서 가장 위험한 순간은 DNS를 바꾸는 시점입니다. 새 서버가 잘 떠 있는 것처럼 보여도 실제 사용자 환경에서는 로그인, 결제, 파일 업로드, 메일 발송 같은 부분에서 문제가 나올 수 있습니다. 그래서 이전 전에는 되돌릴 수 있는 상태를 만들어야 합니다.
제가 보통 잡는 순서는 이렇습니다. 먼저 기존 서버의 파일과 DB를 백업합니다. 그다음 새 서버에 같은 런타임 버전과 확장 모듈을 맞춥니다. 사이트를 복사한 뒤 임시 접속 방식으로 화면과 기능을 확인합니다. DNS TTL은 이전 하루 전쯤 낮춰둡니다. 실제 전환은 방문자가 적은 시간대에 하고, 전환 후에는 오류 로그와 DB 쓰기 상태를 봅니다.
솔직히 서버 이전은 명령어 몇 줄보다 체크리스트가 더 중요합니다. PHP 버전 하나만 달라도 플러그인이 깨질 수 있고, 파일 권한이 다르면 이미지 업로드가 안 됩니다. SSL 인증서는 자동 갱신까지 확인해야 합니다. 인증서가 오늘은 정상이어도 90일 뒤 갱신 실패로 장애가 나는 경우가 있습니다.
장애가 나면 클라우드 콘솔보다 기본 확인이 먼저입니다
사이트가 느리거나 열리지 않을 때 바로 서버를 키우는 분들이 있습니다. 그런데 현장에서는 원인이 아주 기본적인 곳에 있는 경우가 많습니다. 디스크가 꽉 찼는지, 웹서버 프로세스가 살아 있는지, DB 접속이 되는지, DNS가 제대로 향하는지부터 봐야 합니다.
예를 들어 502 오류는 서버 사양 부족일 수도 있지만 PHP-FPM이 죽었거나 워커가 꽉 찬 상태일 수 있습니다. 504 오류는 백엔드 응답 지연이 원인인 경우가 많고, DB 쿼리나 외부 API 대기 시간이 문제일 수 있습니다. SSL 오류는 인증서 만료, 체인 누락, 도메인 불일치에서 자주 납니다. 이런 건 클라우드 인스턴스를 한 단계 올려도 해결되지 않습니다.
- 1단계: DNS가 올바른 서버를 가리키는지 확인
- 2단계: 웹서버, PHP, DB 프로세스 상태 확인
- 3단계: 디스크 사용률과 inode 확인
- 4단계: 최근 배포, 플러그인 변경, 인증서 갱신 이력 확인
- 5단계: 접근 로그와 오류 로그에서 반복 패턴 확인
클라우드 운영은 비싼 장비를 쓰는 일이 아니라 변수들을 작게 만드는 일에 가깝습니다. 처음부터 크게 잡은 서버보다, 적정 사양에 백업과 알림이 제대로 붙은 서버가 오래 갑니다. 트래픽이 늘면 그때 수치를 보고 올리면 됩니다. 운영자는 겁먹고 돈을 쓰는 사람보다, 어디가 병목인지 차분히 확인하는 사람이 비용도 장애도 덜 만납니다.
