얼마 전 작은 쇼핑몰 서버 상담을 했는데, 월 방문자가 3만 명 정도인데도 8코어 VPS를 쓰고 있었습니다. 느려서 올린 게 아니라 예전에 장애가 한 번 난 뒤로 겁이 나서 올렸다고 하더군요. 로그를 보니 병목은 CPU가 아니라 이미지 백업 작업이 영업시간에 돌면서 디스크 I/O를 잡아먹는 문제였습니다. 서버는 돈을 더 쓰면 편해지는 구간도 있지만, 원인을 모르고 올리면 비싼 상태로 같은 장애를 다시 만납니다.
서버는 방문자 수보다 동시접속으로 봐야 합니다
서버 사양을 잡을 때 월 방문자 수만 보면 계산이 크게 흔들립니다. 월 10만 방문자라고 해도 하루 평균으로 나누면 약 3,300명입니다. 이 중 피크 시간에 20%가 몰린다고 해도 660명이고, 그 시간이 2시간이면 분당 5~6명 수준입니다. 페이지 체류 시간이 길어도 실제 웹서버에 동시에 요청을 보내는 사용자는 생각보다 적습니다.
실무에서는 먼저 피크 시간의 요청 수를 봅니다. 예를 들어 피크에 초당 3요청 정도라면 일반적인 워드프레스나 게시판 사이트는 1~2코어, 메모리 2GB VPS로도 충분한 경우가 많습니다. 캐시가 제대로 켜져 있고 이미지가 과하게 크지 않다는 조건이 붙습니다. 반대로 초당 요청은 낮은데 관리자 화면, 검색, 주문 처리처럼 DB를 많이 쓰는 요청이 섞이면 체감 속도는 훨씬 나빠질 수 있습니다.
- 월 1만~5만 방문: 정적 캐시가 있다면 저가 웹호스팅이나 1코어 VPS도 가능
- 월 5만~30만 방문: 2코어, 메모리 2~4GB VPS부터 검토
- 월 30만 이상: 캐시 적중률, DB 부하, 이미지 전송량을 보고 분리 여부 판단
- 로그인 사용자 비중이 높음: 방문자 수보다 DB와 세션 부하를 먼저 확인
여기서 중요한 건 숫자를 외우는 게 아닙니다. 서버가 감당해야 하는 일의 종류를 나눠 보는 겁니다. 정적 페이지 100명과 상품 검색 100명은 같은 100명이 아닙니다.
CPU보다 메모리와 디스크가 먼저 터지는 경우가 많습니다
사이트가 느려졌다고 하면 CPU부터 떠올리는 분이 많습니다. 그런데 실제 운영에서는 메모리 부족, 느린 디스크, 과한 백업 압축이 더 자주 문제를 만듭니다. 특히 저가 VPS는 CPU 코어 수보다 디스크 성능 편차가 큽니다. 같은 2코어라도 스토리지 I/O가 막히면 관리자 페이지 저장 한 번에 몇 초씩 걸립니다.
메모리는 아주 단순하게 계산할 수 있습니다. 웹서버 프로세스 하나가 평균 60MB를 쓰고 동시에 20개가 뜬다면 그것만 1.2GB입니다. 여기에 PHP, DB, 캐시, 운영체제 여유분이 붙습니다. 그래서 메모리 1GB 서버에 워드프레스와 MySQL을 같이 올리면 평소에는 괜찮다가 백업이나 플러그인 업데이트 때 스왑으로 밀리면서 죽는 일이 생깁니다.
작은 서버에서 특히 조심할 작업
- 새벽이 아닌 낮 시간 전체 백업 압축
- 대용량 이미지 일괄 리사이즈
- 검색 색인 재생성
- 보안 플러그인의 전체 파일 스캔
- 트래픽 많은 시간의 로그 압축
저는 작은 서버일수록 자동 작업 시간을 먼저 봅니다. 방문자가 별로 없는데 매일 특정 시간에 죽는다면 트래픽 문제가 아닐 가능성이 큽니다. 백업, 크론, 통계 수집, 악성코드 검사 같은 작업이 겹쳐 있는지 확인해야 합니다.
웹호스팅, VPS, 클라우드 서버를 이렇게 나눠 고릅니다
초기 사이트라면 웹호스팅이 나쁜 선택은 아닙니다. 월 몇 천 원짜리 상품도 정적 캐시가 잘 먹는 블로그, 회사 소개 페이지, 작은 랜딩 페이지에는 충분합니다. 문제는 권한과 관측입니다. 웹호스팅은 서버 설정을 깊게 만질 수 없고, 장애 원인을 로그로 끝까지 따라가기 어렵습니다.
VPS는 운영 책임이 따라옵니다. Nginx, Apache, PHP-FPM, DB, 방화벽, SSL 갱신, 백업까지 직접 봐야 합니다. 대신 병목을 찾고 조정할 수 있습니다. 월 비용 대비 성능도 좋습니다. 기술 담당자가 있거나 장애 때 로그를 볼 사람이 있다면 월 방문자 5만 이상부터는 VPS가 더 편한 경우가 많습니다.
클라우드 서버는 확장성과 부가 기능이 장점입니다. 로드밸런서, 스냅샷, 오브젝트 스토리지, 관리형 DB를 붙이기 쉽습니다. 다만 작은 사이트가 처음부터 클라우드의 모든 기능을 쓰면 비용 구조가 지저분해집니다. 인스턴스 비용은 싸 보이는데 트래픽, 백업, 스토리지, 모니터링 비용이 따로 붙습니다. 비용 예측이 안 되면 운영이 불편합니다.
- 개인 블로그, 소규모 회사 사이트: 웹호스팅 또는 1코어 VPS
- 워드프레스 쇼핑몰, 예약 사이트: 2코어 4GB VPS부터 시작
- 이미지와 파일 다운로드가 많은 사이트: 서버보다 별도 스토리지와 캐시 우선
- 회원 로그인과 주문이 많은 서비스: DB 분리와 백업 복구 시간까지 계산
이전과 백업은 사양보다 먼저 설계해야 합니다
서버 이전에서 가장 많이 터지는 부분은 파일 복사가 아닙니다. DNS 전환, DB 문자셋, PHP 버전, SSL 인증서, 업로드 경로, 예약 작업입니다. 이전 전에 새 서버에서 관리자 로그인, 글 작성, 이미지 업로드, 결제 테스트, 메일 발송까지 확인해야 합니다. 화면만 뜬다고 끝난 게 아닙니다.
백업은 보관보다 복구가 중요합니다. 백업 파일이 있어도 풀어본 적이 없으면 반쪽짜리입니다. 운영 서버 안에만 백업을 쌓아두는 것도 위험합니다. 서버 디스크가 깨지거나 계정이 잠기면 백업까지 같이 묶입니다. 최소한 DB 백업과 업로드 파일은 다른 저장소에 한 벌 더 있어야 합니다.
제가 기본으로 보는 백업 기준
- DB: 하루 1회 이상, 변경이 많은 쇼핑몰은 더 짧게
- 업로드 파일: 하루 1회 또는 변경량 기준 증분 백업
- 보관 위치: 운영 서버와 분리
- 복구 테스트: 최소 월 1회, 스테이징 서버에서 확인
- 보관 기간: 최근 7일, 주간 4벌 정도부터 시작
작은 사이트라도 백업은 과한 편이 낫습니다. 다만 무작정 전체 백업을 자주 돌리면 그 백업이 장애 원인이 됩니다. DB는 덤프하고 파일은 변경분만 가져가는 식으로 나누면 작은 서버에서도 부담이 훨씬 줄어듭니다.
장애가 났을 때 확인 순서를 정해두면 덜 흔들립니다
장애 대응은 침착함보다 순서가 중요합니다. 서버가 안 열린다고 바로 재부팅하면 원인 로그가 날아가거나, 잠깐 살아난 뒤 같은 문제가 반복됩니다. 먼저 외부 접속 문제인지, 웹서버 문제인지, DB 문제인지 나눠야 합니다.
- 1단계: 도메인이 올바른 서버를 가리키는지 확인
- 2단계: 서버에 접속되는지 확인
- 3단계: 디스크 사용률과 메모리 사용률 확인
- 4단계: 웹서버와 DB 프로세스 상태 확인
- 5단계: 최근 배포, 플러그인 업데이트, 인증서 갱신 기록 확인
디스크 100%는 흔한 원인입니다. 로그 파일이 커졌거나 백업이 쌓여서 DB가 쓰기를 못 하면 사이트가 멈춥니다. 메모리가 부족하면 프로세스가 죽고, DB 연결 오류가 납니다. 인증서 갱신 실패도 생각보다 많습니다. 특히 자동 갱신은 잘 되다가 방화벽이나 웹서버 설정 변경 뒤에 실패할 수 있습니다.
서버 비용을 줄인다는 건 무조건 싼 상품을 고른다는 뜻이 아닙니다. 필요한 부하를 계산하고, 백업과 복구 흐름을 만들고, 장애 때 볼 순서를 정해두는 겁니다. 그렇게 해두면 작은 서버도 오래 버팁니다. 반대로 그 세 가지가 없으면 큰 서버도 쉽게 멈춥니다. 저는 사양표보다 운영 습관이 사이트 수명을 더 많이 좌우한다고 봅니다.
