얼마 전 작은 쇼핑몰을 이전해 달라는 요청을 받았는데, 월 방문자가 3만 명 정도인 사이트에 8코어 서버가 물려 있었습니다. CPU 사용률은 평소 5%도 안 됐고, 실제 병목은 디스크 백업이 한 달째 실패하고 있었다는 점이었습니다. 클라우드서버를 고를 때 이런 일이 꽤 자주 생깁니다. 서버가 느리면 무조건 큰 사양을 사야 한다고 생각하기 쉬운데, 현장에서는 트래픽보다 설정, 캐시, 백업, 장애 대응 절차가 더 큰 차이를 만듭니다.
클라우드서버는 트래픽보다 동시접속으로 잡는 게 맞습니다
방문자 수만 보고 클라우드서버 사양을 정하면 거의 틀립니다. 하루 방문자 1만 명이라고 해도 사용자가 오전 9시에 몰리는 사이트와 하루 종일 고르게 들어오는 사이트는 필요한 사양이 다릅니다. 저는 보통 동시접속, 페이지 크기, 캐시 여부, 데이터베이스 부하를 먼저 봅니다.
예를 들어 회사 소개 사이트처럼 정적 페이지가 많고 이미지 최적화가 되어 있다면 1코어, 메모리 1GB 서버로도 월 수만 방문자를 버티는 경우가 많습니다. 반대로 게시판 검색, 관리자 통계, 주문 처리처럼 데이터베이스를 계속 두드리는 구조라면 방문자가 적어도 메모리 2GB 이상이 편합니다.
- 개인 블로그나 랜딩 페이지: 1코어, 메모리 1GB, SSD 20GB부터 시작
- 작은 회사 홈페이지와 게시판: 1~2코어, 메모리 2GB, SSD 40GB 권장
- 소규모 쇼핑몰이나 예약 사이트: 2코어, 메모리 4GB, DB 분리 여부 검토
- 동시접속 100명 이상 서비스: 웹, DB, 캐시 분리와 모니터링부터 설계
여기서 중요한 건 처음부터 크게 잡지 않는 겁니다. 클라우드서버의 장점은 사양을 올리기 쉽다는 데 있습니다. 처음부터 비싼 요금제를 쓰는 것보다, 실제 CPU와 메모리 사용률을 1~2주 보고 올리는 편이 비용도 덜 나가고 판단도 정확합니다.
초기 비용을 낮추려면 무료보다 복구 가능성을 봐야 합니다
무료나 저가 클라우드서버가 무조건 나쁜 건 아닙니다. 테스트 서버, 개인 블로그, 포트폴리오, 사내 도구 정도라면 저가형으로 충분한 구간이 많습니다. 근데 운영 서버라면 무료 여부보다 스냅샷, 백업, 콘솔 접속, 방화벽 설정, 장애 공지가 더 중요합니다.
제가 본 장애 중에는 서버비를 아끼다가 터진 사고보다, 백업이 되는 줄 알고 있다가 복구 시점에 파일이 비어 있어서 터진 사고가 훨씬 많았습니다. 백업은 설정했다는 사실보다 복원해 봤다는 사실이 중요합니다. 최소 한 번은 새 서버에 백업을 풀어서 웹과 DB가 정상으로 뜨는지 확인해야 합니다.
월 비용 계산은 이렇게 잡으면 됩니다
작은 사이트라면 서버 요금만 보면 안 됩니다. 디스크, 트래픽 초과, 스냅샷, 공인 IP, 로드밸런서, 백업 저장 공간이 붙으면 생각보다 금액이 달라집니다. 특히 이미지가 많은 사이트는 서버 CPU보다 트래픽 비용이 먼저 올라갑니다.
- 서버 기본료: CPU, 메모리, 디스크 기준으로 계산
- 트래픽 비용: 이미지, 첨부파일, 동영상이 많으면 별도 확인
- 백업 비용: 스냅샷 보관 기간과 개수 기준으로 계산
- 운영 비용: 장애 대응, 보안 업데이트, 인증서 갱신 시간 포함
월 1만 원대 서버도 제대로 캐시하고 이미지 용량만 줄이면 꽤 오래 갑니다. 반대로 캐시 없이 모든 요청을 PHP와 DB가 처리하게 두면 월 10만 원짜리 서버도 금방 답답해집니다. 서버 사양보다 구조가 먼저라는 말은 실무에서 정말 자주 맞습니다.
이전 작업은 서버보다 순서가 중요합니다
클라우드서버로 이전할 때 제일 위험한 순간은 파일을 복사하는 시간이 아닙니다. DNS 변경, DB 동기화, SSL 인증서, 권한 설정, 업로드 경로가 엇갈리는 순간입니다. 특히 쇼핑몰이나 예약 사이트처럼 데이터가 계속 바뀌는 사이트는 이전 중 주문 데이터가 갈라질 수 있습니다.
제가 쓰는 순서는 단순합니다. 먼저 새 서버에 같은 버전의 웹서버, PHP, DB를 맞춥니다. 그다음 파일과 DB를 복사하고, hosts 설정이나 임시 접속 방식으로 새 서버에서 화면을 확인합니다. 여기서 관리자 로그인, 이미지 업로드, 메일 발송, 결제 콜백 같은 기능을 확인한 뒤 트래픽이 적은 시간에 DNS를 넘깁니다.
- 이전 전: 서버 버전, DB 버전, 디스크 용량 확인
- 복사 후: 파일 권한, 업로드 폴더, 캐시 폴더 확인
- 전환 전: SSL 인증서, 리다이렉트, 관리자 로그인 확인
- 전환 후: 에러 로그, 접속 로그, DB 연결 수 확인
DNS 전환 후에도 기존 서버는 바로 지우지 않는 게 좋습니다. 최소 2~3일은 보관해야 합니다. 일부 사용자는 예전 서버로 접속할 수 있고, 빠진 파일이나 예전 로그가 필요할 수도 있습니다. 비용 몇 천 원 아끼려다가 복구 근거를 잃는 경우를 많이 봤습니다.
장애가 났을 때는 큰 것부터 보지 않습니다
사이트가 죽으면 CPU부터 올리는 분들이 있습니다. 그런데 실제로는 디스크 100%, DB 커넥션 고갈, 인증서 만료, 방화벽 오픈 누락, 로그 파일 폭증 같은 원인이 더 흔합니다. 클라우드서버 장애 대응은 비싼 기능을 붙이는 것보다 확인 순서가 중요합니다.
제가 현장에서 먼저 보는 순서
- 서버가 켜져 있는지, 콘솔 접속이 되는지 확인
- 디스크 사용률과 inode 사용량 확인
- 웹서버와 DB 프로세스 상태 확인
- 최근 배포, 플러그인 업데이트, 설정 변경 이력 확인
- 에러 로그에서 같은 메시지가 반복되는지 확인
- 외부 방화벽과 서버 내부 방화벽 규칙 확인
이 순서대로 보면 원인을 빨리 좁힐 수 있습니다. 특히 디스크가 꽉 차면 DB가 쓰기를 못 하고, 세션 저장도 꼬이고, 로그도 못 남기는 상태가 됩니다. 화면에는 단순한 500 에러처럼 보이지만 내부에서는 여러 문제가 동시에 터진 것처럼 보입니다.
클라우드서버 운영에서 모니터링은 거창할 필요 없습니다. CPU, 메모리, 디스크, 트래픽, 응답 코드 정도만 봐도 초반 사고는 많이 줄어듭니다. 알림은 너무 많이 걸면 결국 안 보게 됩니다. 디스크 80%, 메모리 지속 사용률, 5xx 에러 증가처럼 실제 조치가 필요한 지표부터 걸어두는 편이 낫습니다.
처음 세팅할 때 꼭 챙길 것들
초기 세팅은 한 번 놓치면 나중에 귀찮아집니다. 저는 새 클라우드서버를 만들면 방화벽, SSH 포트 정책, 관리자 계정, 자동 업데이트 범위, 시간대, 로그 보관 기간, 백업 스케줄을 먼저 봅니다. 웹서비스 설치는 그다음입니다.
- SSH 접속은 키 기반으로 제한하고 비밀번호 로그인은 끄기
- 웹, SSH, DB 포트 중 외부 공개가 필요한 것만 열기
- DB는 가능하면 외부 직접 접속을 막기
- 스냅샷과 파일 백업을 같은 저장소에만 두지 않기
- 인증서 자동 갱신이 실제로 동작하는지 확인
- 관리자 페이지 접근 제한이나 2단계 인증 적용
클라우드서버는 잘 쓰면 작은 비용으로도 안정적인 운영이 가능합니다. 다만 아무 설정 없이 서버만 띄워 놓으면 웹호스팅보다 더 위험해질 수 있습니다. 웹호스팅은 업체가 기본 보안을 어느 정도 막아주지만, VPS나 클라우드서버는 운영자가 직접 챙겨야 할 영역이 많습니다.
처음 운영하는 사이트라면 너무 멋진 구조를 만들려고 하지 않아도 됩니다. 1~2코어 서버에서 시작하고, 백업을 검증하고, 로그를 보고, 병목이 확인될 때 사양을 올리면 됩니다. 서버는 크게 사는 사람이 잘 운영하는 게 아니라, 필요한 만큼 쓰고 복구 가능한 상태를 유지하는 사람이 오래 버팁니다.
