얼마 전 작은 예약 사이트 이전 작업을 맡았는데, 기존 업체가 월 방문자 5만 명이라는 이유로 꽤 비싼 클라우드서버 구성을 팔아 둔 상태였습니다. 실제 로그를 보니 피크 시간에도 애플리케이션 요청은 초당 2건 안팎이었고, 병목은 서버 사양이 아니라 캐시 미적용과 백업 파일이 같은 디스크에 쌓이는 구조였습니다. 이런 경우 8 vCPU보다 2 vCPU 서버를 제대로 세팅하는 쪽이 훨씬 낫습니다.
클라우드서버는 방문자 수만 보고 고르면 빗나간다
서버 사양은 월 방문자 수보다 피크 요청량, 평균 응답시간, DB 부하, 파일 전송량을 같이 봐야 합니다. 하루 방문자 1만 명이어도 대부분이 검색 유입으로 흩어져 들어오면 서버는 의외로 조용합니다. 반대로 이벤트 문자 한 번으로 10분 안에 사용자가 몰리면 월 방문자가 적어도 서버가 먼저 버팁니다.
간단히 계산하면 감이 잡힙니다. 하루 방문자 1만 명, 사용자당 페이지뷰 3회, 그중 20퍼센트가 가장 바쁜 2시간에 들어온다고 보면 동적 페이지 요청은 1초에 1건 정도입니다. 이미지와 CSS를 CDN이나 정적 캐시로 빼면 원본 클라우드서버가 직접 처리할 일은 더 줄어듭니다. 이런 사이트에 처음부터 고사양을 넣는 건 비용 대비 효과가 작습니다.
트래픽 규모별로 잡는 현실적인 사양
정적 회사 소개 페이지, 포트폴리오, 단순 랜딩 페이지는 굳이 VPS를 붙잡고 있을 이유가 적습니다. 정적 호스팅이나 오브젝트 스토리지, CDN 조합이면 월 비용이 거의 안 나오거나 아주 낮게 유지됩니다. 서버를 직접 운영할 일이 없으니 보안 업데이트와 장애 대응 부담도 줄어듭니다.
- 개인 블로그나 소형 워드프레스: 1 vCPU, 메모리 1~2GB, SSD 20~40GB부터 시작해도 됩니다. 캐시 플러그인, 이미지 압축, PHP 프로세스 수만 맞추면 월 수만 페이지뷰는 버팁니다.
- 문의형 기업 사이트나 예약 페이지: 2 vCPU, 메모리 2~4GB가 무난합니다. 여기서 중요한 건 CPU보다 폼 저장, 메일 발송, DB 백업이 끊기지 않는 구조입니다.
- 소형 쇼핑몰이나 관리자 사용량이 있는 서비스: 2~4 vCPU, 메모리 4~8GB를 봅니다. 상품 이미지가 많으면 디스크보다 전송량과 캐시 정책을 먼저 확인합니다.
- 피크 이벤트가 있는 서비스: 평소 사양보다 순간 부하 대응이 중요합니다. 로드밸런서, 캐시, 큐, 읽기 전용 페이지 전환 같은 운영 장치를 먼저 설계해야 합니다.
CPU 크레딧 방식의 저가 인스턴스는 짧은 피크에는 좋지만, 지속 부하가 걸리면 성능이 떨어질 수 있습니다. 반대로 항상 조용한 블로그라면 그런 인스턴스도 나쁘지 않습니다. 서버는 체면으로 고르는 장비가 아닙니다. 로그와 숫자에 맞춰 쓰는 소모품에 가깝습니다.
요금제보다 먼저 봐야 할 운영 조건
클라우드서버 비용표를 보면 vCPU와 메모리가 가장 크게 보입니다. 그런데 실제 사고는 디스크, 백업, 네트워크, 보안그룹에서 많이 납니다. 디스크 사용률이 90퍼센트를 넘으면 DB 쓰기가 느려지고, 로그가 계속 쌓이면 어느 날 새벽에 사이트가 멈춥니다. 자동 백업이 있어도 같은 계정, 같은 리전에만 있으면 운영 실수나 계정 문제에 취약합니다.
월 전송량도 계산해야 합니다. 페이지 한 번 열 때 평균 2MB가 내려가고 월 10만 페이지뷰가 나오면 단순 계산으로 200GB입니다. 이미지가 캐시되면 원본 서버 전송량은 줄지만, 캐시가 없으면 클라우드서버 네트워크 비용이 예상보다 커집니다. 요금제가 싸 보여도 초과 전송량 단가가 높으면 전체 비용이 달라집니다.
SSL은 무료 인증서로 충분한 경우가 많습니다. 다만 자동 갱신이 실제로 도는지 확인해야 합니다. 인증서는 비싼 걸 사서 안전해지는 영역이 아니라 만료 전에 갱신되고, 웹서버가 올바른 인증서를 물고 뜨는지가 더 중요합니다. 여러 도메인을 묶어 쓰는 경우에는 갱신 스크립트 권한과 방화벽 80번 포트 허용 여부를 같이 봅니다.
이전과 백업은 서버 사양보다 먼저 준비한다
클라우드서버 이전에서 제일 위험한 순간은 새 서버를 켜는 때가 아니라 DNS를 돌리는 때입니다. 저는 보통 이전 하루 전 TTL을 낮추고, 파일 동기화와 DB 덤프를 한 번 예행으로 돌립니다. 그다음 새 서버에서 웹서버 설정, PHP나 Node 버전, 크론, 업로드 권한, 메일 발송, SSL 자동 갱신까지 확인합니다. 여기서 하나라도 빠지면 서버는 살아 있는데 서비스 기능이 죽어 있는 상태가 됩니다.
백업은 스냅샷 하나로 끝내면 불안합니다. 스냅샷은 서버 전체를 되돌릴 때 편하지만, 특정 테이블이나 업로드 파일 몇 개만 복구할 때는 불편합니다. DB 덤프, 업로드 파일, 설정 파일을 분리해서 보관하고, 최소 월 1회는 복구 테스트를 해봐야 합니다. 백업은 만들어지는 것보다 꺼내 쓸 수 있는지가 더 중요합니다.
- 배포 전: 디스크 여유 공간, DB 덤프 생성, 웹서버 설정 백업을 확인합니다.
- 이전 중: 기존 서버를 바로 끄지 말고 일정 시간 읽기 전용 또는 유지 상태로 둡니다.
- 이전 후: 주문, 문의, 로그인, 파일 업로드, 관리자 페이지, 메일 발송을 실제로 눌러봅니다.
- 운영 중: 백업 실패 알림과 디스크 사용률 알림은 반드시 받도록 둡니다.
장애가 났을 때 보는 순서
사이트가 안 열린다는 연락이 오면 먼저 서버 크기부터 올리고 싶은 마음이 생깁니다. 근데 급할수록 순서를 지켜야 합니다. DNS가 다른 곳을 보고 있는지, 보안그룹에서 80번과 443번이 막혔는지, 웹서버 프로세스가 떠 있는지, 디스크가 가득 찼는지부터 확인합니다. 의외로 여기서 절반 이상 잡힙니다.
그다음은 애플리케이션 로그와 DB 연결입니다. DB 최대 연결 수가 꽉 찼거나 느린 쿼리가 쌓이면 웹서버는 살아 있어도 화면은 늦게 뜹니다. PHP-FPM이나 애플리케이션 워커 수를 너무 크게 잡아 메모리가 먼저 터지는 경우도 있습니다. 동시접속이 늘었다고 무조건 워커를 늘리면 DB가 더 빨리 막힐 수 있습니다.
제가 클라우드서버를 권할 때는 보통 작은 사양으로 시작하고, 모니터링 수치를 보며 올리는 쪽을 선호합니다. 처음부터 큰 서버를 쓰면 문제를 돈으로 덮는 느낌은 들지만, 설정 오류와 백업 부실은 그대로 남습니다. 싼 요금제가 충분한 구간에서는 싸게 쓰는 게 맞습니다. 대신 디스크, 백업, 인증서, 로그, 알림은 싸게 넘기면 안 됩니다. 서버 운영은 큰 장비보다 반복 확인이 오래 버팁니다.
