얼마 전 작은 쇼핑몰 서버 이전 상담을 했는데, 월 방문자가 3만 명 정도인데도 8코어 클라우드 서버 견적을 받아온 상태였습니다. 실제 로그를 보니 피크 시간 동시 접속은 25명 안팎이었고, 이미지가 큰 것 말고는 서버 부하가 거의 없었습니다. 이런 경우는 비싼 클라우드보다 작은 VPS나 관리형 웹호스팅이 더 나을 때가 많습니다.
클라우드는 먼저 트래픽보다 동시 접속으로 봅니다
서버 사양을 볼 때 월 방문자 수만 보면 자주 빗나갑니다. 월 10만 방문자라도 하루 종일 고르게 들어오면 작은 서버로 버팁니다. 반대로 이벤트 문자 한 번에 5분 동안 몰리면 월 방문자가 적어도 서버가 버거워집니다.
대략적인 출발점은 이렇게 잡습니다. 회사 소개 사이트, 블로그, 랜딩 페이지처럼 읽기 위주라면 1 vCPU, 메모리 1GB에서 2GB로 시작해도 충분한 경우가 많습니다. 워드프레스에 플러그인이 많고 관리자 접속이 잦다면 2GB는 잡는 편이 낫습니다. 결제, 예약, 게시판처럼 쓰기 작업이 많으면 CPU보다 데이터베이스와 디스크 지연 시간이 먼저 문제를 일으킵니다.
- 월 1만 방문 이하: 저가 웹호스팅이나 1 vCPU급 VPS로 충분한 구간이 많음
- 월 10만 방문 안팎: 캐시 설정이 좋으면 1~2 vCPU, 메모리 2GB급으로 운영 가능
- 동시 접속 100명 이상: 웹서버, 데이터베이스, 캐시를 분리할지 검토할 시점
- 이미지·영상 전송이 많음: 서버 CPU보다 전송량과 스토리지 비용을 먼저 계산
웹호스팅, VPS, 클라우드는 관리 범위가 다릅니다
저가 웹호스팅이 무조건 나쁜 건 아닙니다. 트래픽이 작고 PHP 기반 사이트 하나만 운영한다면 관리형 웹호스팅이 제일 편합니다. 보안 패치, 메일, 백업 기능이 기본으로 묶여 있는 경우도 많아서 운영자가 직접 만질 부분이 적습니다.
VPS는 루트 권한이 필요할 때 고릅니다. Nginx 설정을 바꾸거나, Node.js 앱을 올리거나, 특정 버전의 데이터베이스를 써야 하면 VPS가 편합니다. 대신 운영 책임도 같이 옵니다. 방화벽, SSH 키, 자동 업데이트, 로그 관리, 백업을 직접 챙겨야 합니다.
클라우드 서버는 확장성과 부가 기능이 강점입니다. 로드밸런서, 오브젝트 스토리지, 관리형 데이터베이스, 모니터링을 붙이기 쉽습니다. 근데 작은 사이트에서는 그 장점보다 복잡도가 먼저 올라올 수 있습니다. 월 1만 원짜리 서버로 충분한 사이트에 네트워크, 스토리지, 백업, 전송량 과금이 따로 붙으면 예상보다 비싸지는 일이 흔합니다.
사양보다 먼저 확인할 설정이 있습니다
사이트가 죽는 원인은 트래픽보다 설정인 경우가 꽤 많습니다. PHP 메모리 제한이 너무 낮거나, 데이터베이스 커넥션 제한이 작거나, 이미지 원본을 매번 리사이즈하거나, 캐시가 꺼져 있으면 서버를 키워도 증상이 반복됩니다.
운영 전에 보는 기본 항목
- 웹서버 동시 연결 제한과 타임아웃 값
- PHP-FPM 또는 앱 프로세스 수
- 데이터베이스 최대 커넥션과 슬로우 쿼리
- 디스크 사용량, inode, 백업 파일 누적 여부
- SSL 인증서 자동 갱신과 DNS 레코드 상태
특히 워드프레스는 플러그인 하나가 전체 응답 시간을 망칠 때가 있습니다. 메인 페이지가 0.3초에 열리던 사이트가 통계 플러그인 추가 뒤 2초대로 느려진 사례를 여러 번 봤습니다. 이럴 때 서버를 2배로 키우면 비용만 늘고 원인은 그대로 남습니다.
백업은 스냅샷 하나로 끝내면 위험합니다
클라우드에서 자주 보는 실수가 스냅샷을 백업이라고 믿는 겁니다. 스냅샷은 복구에 유용하지만 같은 계정, 같은 권한, 같은 장애 범위에 묶이는 경우가 많습니다. 계정이 잠기거나 삭제 실수가 나면 같이 사라질 수 있습니다.
운영 사이트는 최소한 파일, 데이터베이스, 설정 파일을 나눠 봐야 합니다. 파일은 이미지와 업로드 자료가 중요하고, 데이터베이스는 주문·회원·게시글 같은 실제 서비스 데이터입니다. Nginx 설정, 환경 변수, cron 설정도 빠지면 복구 시간이 길어집니다.
- 데이터베이스: 하루 1회 이상 자동 덤프, 중요한 서비스는 더 짧은 주기
- 업로드 파일: 변경분 기준으로 외부 스토리지에 보관
- 서버 설정: Git 또는 별도 보관소에 텍스트로 보관
- 복구 테스트: 최소 월 1회는 새 서버에서 실제로 열어보기
백업에서 제일 중요한 건 저장이 아니라 복구입니다. 백업 파일이 있어도 문자셋이 깨지거나, 덤프가 중간에 끊겼거나, 파일 권한이 맞지 않으면 운영 중에는 꽤 피곤해집니다. 테스트 복구를 해본 백업만 믿을 수 있습니다.
이전할 때는 DNS 시간부터 줄입니다
서버 이전은 새 서버를 먼저 만들고, 기존 서버는 그대로 둔 채 검증하는 방식이 안정적입니다. DNS를 바꾼 뒤에야 오류를 찾기 시작하면 사용자가 바로 장애를 겪습니다. 이전 전날 TTL을 300초 정도로 낮춰두면 전환이 훨씬 부드럽습니다.
순서는 단순합니다. 새 서버에 같은 버전의 런타임을 맞추고, 파일과 데이터베이스를 옮긴 뒤, 임시 호스트 설정으로 먼저 접속해 봅니다. 로그인, 결제, 업로드, 메일 발송, 관리자 기능까지 확인합니다. 그 다음 짧은 점검 시간을 잡고 최종 데이터베이스를 다시 옮긴 뒤 DNS를 바꾸는 편이 안전합니다.
장애가 났을 때도 순서가 있습니다. 먼저 DNS가 맞는지 보고, SSL 인증서 만료 여부를 확인합니다. 그 다음 웹서버 에러 로그, 앱 로그, 데이터베이스 연결, 디스크 용량을 봅니다. 서버 CPU가 100%인지부터 보는 사람이 많은데, 실제 현장에서는 디스크 100%, 인증서 만료, DB 비밀번호 변경 같은 단순한 원인이 더 빨리 나옵니다.
클라우드는 좋은 도구입니다. 다만 작은 사이트까지 무조건 클라우드로 올려야 하는 건 아닙니다. 필요한 사양을 동시 접속, 캐시, 데이터베이스, 백업 기준으로 먼저 계산하면 월 비용은 줄고 장애 대응은 오히려 쉬워집니다. 저는 서버를 크게 잡는 것보다 복구 가능한 구조로 작게 시작하는 쪽을 더 신뢰합니다.
