요즘 이전 상담을 받다 보면, 월 방문자 3만 명짜리 워드프레스 사이트에 8코어 서버를 권하는 견적을 아직도 봅니다. 실제로는 설정만 바로 잡아도 1코어 1GB 메모리에서 버티는 사이트가 적지 않습니다. 서버가 느린 이유가 항상 사양 부족은 아닙니다. 캐시가 꺼져 있거나, 백업이 피크 시간에 돌거나, 이미지 원본을 그대로 뿌리는 경우가 더 흔합니다.
클라우드서버는 트래픽보다 동시접속으로 봐야 합니다
방문자 수만 보고 서버를 고르면 대체로 과하게 잡습니다. 월 10만 방문자라고 해도 하루로 나누면 3천 명 정도고, 시간대가 고르게 퍼지면 순간 부하는 작습니다. 중요한 건 동시에 몇 명이 페이지를 열고, 한 요청이 서버를 몇 초 붙잡고 있느냐입니다.
간단하게 계산하면 됩니다. 초당 요청 수는 동시접속자 수를 평균 응답 시간으로 나눈 값에 가깝습니다. 동시접속 20명, 평균 응답 시간 0.5초면 초당 40요청을 처리해야 합니다. 그런데 페이지 캐시가 켜져 있으면 이 중 상당수는 PHP나 DB까지 가지 않습니다. 같은 트래픽이어도 캐시 유무에 따라 필요한 사양이 완전히 달라집니다.
- 개인 블로그, 회사 소개 사이트: vCPU 1개, 메모리 1GB부터 시작 가능
- 워드프레스에 플러그인이 많은 사이트: vCPU 1~2개, 메모리 2GB 권장
- 게시판·예약·로그인 기능이 있는 서비스: vCPU 2개, 메모리 4GB부터 보는 편이 안전
- 이미지 업로드가 많고 관리자가 여러 명인 사이트: 디스크 I/O와 백업 공간을 먼저 확인
처음부터 큰 서버를 사지 않아도 되는 구간
클라우드서버의 장점은 나중에 키울 수 있다는 겁니다. 그래서 처음부터 넉넉하게 잡는다는 말이 항상 좋은 선택은 아닙니다. 특히 블로그나 랜딩페이지처럼 읽기 요청이 대부분인 사이트는 캐시와 이미지 최적화가 사양보다 더 큰 영향을 줍니다.
월 방문자 1만 명 이하라면 대부분 저가형 VPS나 가장 작은 클라우드서버로도 충분합니다. 월 5만 명까지도 정적 캐시, 압축, 이미지 리사이즈가 제대로 되어 있으면 1~2GB 메모리로 운영되는 경우가 많습니다. 반대로 방문자는 적어도 검색, 통계, 실시간 채팅, 무거운 관리자 화면이 붙으면 4GB가 먼저 필요할 수 있습니다.
제가 보는 기준은 간단합니다. CPU 사용률이 평소 30퍼센트 아래인데도 느리면 서버 증설 전에 웹서버 설정, DB 쿼리, 캐시 적중률을 먼저 봅니다. 메모리 여유가 거의 없고 스왑이 계속 발생하면 그때는 증설이 맞습니다. 디스크 사용률이 80퍼센트를 넘으면 장애 전조로 봐야 합니다. 로그와 백업이 쌓이다가 새벽에 사이트가 죽는 경우가 생각보다 많습니다.
운영에서 사고 나는 지점은 사양표 밖에 있습니다
클라우드서버 견적서에는 보통 vCPU, 메모리, 디스크, 트래픽만 보입니다. 그런데 실제 장애는 방화벽, 백업, DNS, 인증서 갱신, 권한 설정에서 더 많이 납니다. 특히 서버 이전할 때는 파일만 옮기고 DB 문자셋, 업로드 권한, 크론 작업을 놓치는 일이 많습니다.
이전할 때 최소 확인할 항목
- 웹 루트 경로와 업로드 디렉터리 권한
- DB 버전, 문자셋, 타임존 설정
- 메일 발송 방식과 SPF, DKIM 같은 인증 설정
- SSL 인증서 자동 갱신 여부
- 예약 작업, 백업 스크립트, 로그 회전 설정
- 방화벽에서 80, 443, SSH 포트만 필요한 만큼 열렸는지
서버 이전은 속도보다 검증 순서가 중요합니다. 새 서버에 먼저 복제하고, 임시 접근으로 페이지와 관리자 기능을 확인한 뒤, DNS 전환 시간을 짧게 잡습니다. TTL을 미리 낮춰두면 전환 후 꼬이는 시간이 줄어듭니다. 그래도 최소 하루는 양쪽 서버 로그를 같이 봐야 합니다. 결제나 게시글 작성처럼 데이터가 바뀌는 기능이 있다면 전환 직전 쓰기 작업을 잠깐 막는 편이 낫습니다.
백업은 저장보다 복구 테스트가 먼저입니다
백업이 있다고 말하는 사이트 중에 실제로 복구해 본 곳은 절반도 안 됩니다. 파일 백업만 있고 DB가 빠졌거나, DB는 있는데 업로드 폴더가 빠진 경우가 흔합니다. 더 난감한 건 백업 파일이 같은 서버 안에만 있는 경우입니다. 디스크가 깨지면 원본과 백업이 같이 사라집니다.
운영 기준으로는 최소한 일 단위 DB 백업, 주 단위 전체 파일 백업, 외부 저장소 보관이 필요합니다. 변경이 잦은 쇼핑몰이나 예약 사이트는 DB 백업 주기를 더 짧게 잡아야 합니다. 백업 보관 기간은 7일, 14일, 30일처럼 여러 세대를 두는 게 좋습니다. 해킹이나 실수 삭제는 바로 발견되지 않는 경우가 많기 때문입니다.
- DB 백업: 자동화하고 압축 후 외부 보관
- 파일 백업: 업로드 폴더와 설정 파일 포함
- 복구 테스트: 별도 경로에 풀어서 로그인과 주요 화면 확인
- 알림: 백업 실패 시 메일이나 메시지로 받기
백업 시간도 중요합니다. 새벽 3시에 트래픽이 적다고 해도 크롤러나 배치 작업과 겹치면 CPU와 디스크 I/O가 튈 수 있습니다. 서버가 작은 경우 백업 압축 때문에 웹 응답이 밀립니다. 이럴 때는 백업을 분리하거나, DB 덤프와 파일 압축 시간을 나눠야 합니다.
장애가 났을 때는 순서를 고정하는 게 빠릅니다
사이트가 안 열린다고 바로 서버 재부팅부터 하면 원인을 잃어버립니다. 물론 급한 상황에서는 살리는 게 먼저지만, 운영자는 확인 순서를 몸에 붙여야 합니다. 저는 보통 네트워크, 웹서버, 애플리케이션, DB, 디스크 순서로 봅니다.
- 서버 접속 가능 여부 확인
- 웹서버 프로세스와 80, 443 포트 확인
- 최근 에러 로그에서 500, 502, 504 패턴 확인
- DB 접속 수와 느린 쿼리 확인
- 디스크 사용률, inode 사용률, 메모리 스왑 확인
502는 PHP-FPM이나 백엔드 프로세스 문제인 경우가 많고, 504는 응답 지연을 의심합니다. 500은 코드나 권한, 설정 파일 오류가 흔합니다. 디스크가 꽉 차면 로그인도 안 되고 세션도 저장되지 않아 증상이 복잡해집니다. inode가 다 차는 경우도 있어서 사용률 퍼센트만 보면 놓칩니다.
클라우드서버는 비싼 요금제를 고르는 기술이 아니라, 필요한 만큼 쓰고 장애 날 지점을 줄이는 운영 방식에 가깝습니다. 처음에는 작게 시작해도 됩니다. 대신 모니터링, 백업, 복구 테스트, 설정 관리만큼은 처음부터 제대로 잡아야 합니다. 서버 비용은 한 달에 몇 만 원 아낄 수 있지만, 복구 불가능한 데이터는 돈으로도 바로 돌아오지 않습니다. 저는 그래서 사양보다 절차를 먼저 봅니다.
