얼마 전 작은 쇼핑몰 서버를 봤는데, 하루 방문자가 2천 명도 안 되는데 8코어 VPS를 쓰고 있었습니다. 그런데 장애 원인은 CPU가 아니라 백업 스크립트가 새벽마다 원본 이미지 폴더를 통째로 압축하면서 디스크를 꽉 채운 거였습니다. 트래픽이라는 말을 들으면 다들 서버 사양부터 올리려고 하는데, 실제 현장에서는 계산을 조금만 해도 싼 요금제로 충분한 경우가 많습니다.
트래픽은 방문자 수가 아니라 전송량과 동시접속으로 봅니다
트래픽을 말할 때 하루 방문자 수만 보면 판단이 흐려집니다. 서버 입장에서는 페이지를 몇 명이 봤는지보다, 한 페이지를 열 때 얼마나 많은 파일을 내려보내는지와 동시에 몇 명이 붙는지가 더 중요합니다.
예를 들어 한 페이지 용량이 이미지 포함 3MB이고 하루 1만 페이지뷰가 나오면 단순 전송량은 하루 30GB입니다. 한 달이면 900GB입니다. 여기에 검색봇, 관리자 접속, 이미지 직접 접근, 캐시 실패를 더하면 1TB를 넘길 수 있습니다. 반대로 페이지를 800KB로 줄이고 캐시가 잘 먹으면 같은 1만 페이지뷰라도 월 250GB 안쪽에서 끝납니다.
동시접속도 비슷합니다. 하루 방문자가 5천 명이어도 대부분 낮에 천천히 들어오면 서버는 조용합니다. 그런데 이벤트 문자 발송 뒤 5분 동안 300명이 몰리면 작은 호스팅은 바로 느려질 수 있습니다. 그래서 저는 먼저 평균이 아니라 피크를 봅니다. 로그가 있으면 시간대별 요청 수를 보고, 없으면 예상 유입 채널을 기준으로 잡습니다.
작은 사이트는 공유 웹호스팅으로 충분한 구간이 있습니다
개인 블로그, 회사 소개 사이트, 랜딩 페이지처럼 동적 기능이 적은 사이트는 월 방문자 1만에서 5만 정도까지도 저가 웹호스팅으로 버티는 경우가 많습니다. 조건은 있습니다. 이미지가 적절히 압축되어 있고, 캐시가 켜져 있고, 무거운 플러그인을 많이 쓰지 않아야 합니다.
워드프레스 기준으로 보면 글 위주 블로그는 메모리 1GB급 공유 환경에서도 꽤 오래 갑니다. 문제는 페이지 빌더, 통계 플러그인, 보안 플러그인, 관련글 플러그인이 한꺼번에 돌 때입니다. 방문자가 많지 않아도 PHP 실행 시간이 길어지고 DB 쿼리가 늘어납니다. 이때는 트래픽 문제가 아니라 애플리케이션 구조 문제입니다.
- 월 10만 페이지뷰 이하의 글 중심 사이트: 공유 웹호스팅 또는 저가형 VPS 검토
- 이미지 많은 포트폴리오 사이트: 전송량 한도와 이미지 최적화가 먼저
- 로그인, 장바구니, 게시판이 많은 사이트: CPU보다 DB 응답 시간 확인
- 광고나 SNS 유입이 순간적으로 몰리는 사이트: 동시접속 제한 확인
싼 요금제가 무조건 좋다는 뜻은 아닙니다. 다만 방문자가 적은데 관리형 클라우드, 로드밸런서, 고사양 DB까지 붙이는 건 대개 낭비입니다. 먼저 병목이 어디인지 봐야 합니다.
VPS로 넘어갈 때는 CPU보다 메모리와 디스크를 먼저 봅니다
VPS를 고를 때 2코어냐 4코어냐부터 묻는 분들이 많습니다. 실제로는 메모리 부족과 디스크 I/O가 더 자주 문제를 만듭니다. PHP-FPM, 웹서버, DB가 한 서버에 같이 있으면 메모리 1GB는 금방 답답해집니다. 작은 워드프레스라도 플러그인이 많으면 2GB부터 보는 편이 낫습니다.
트래픽이 늘면 CPU 사용률도 오르지만, 캐시가 제대로 걸리면 CPU는 생각보다 여유가 있습니다. 반대로 DB 인덱스가 없거나, 백업이 운영 시간에 돌거나, 로그 파일이 계속 쌓이면 디스크가 먼저 막힙니다. 장애 알림에는 CPU 20퍼센트라고 나오는데 사이트는 10초씩 걸리는 상황도 이런 경우가 많습니다.
제가 보통 잡는 기준은 이렇습니다. 정적 페이지나 가벼운 블로그는 1코어 1GB도 시작은 가능합니다. 워드프레스 운영 사이트는 2코어 2GB가 편합니다. 쇼핑몰이나 예약 시스템처럼 주문, 결제, 회원 기능이 있으면 2코어 4GB 이상에서 시작하고 DB 백업과 로그 보관 방식을 따로 잡습니다. 트래픽이 월 1TB를 넘기 시작하면 서버 사양보다 캐시, 이미지 전송, CDN 사용 여부를 같이 봐야 합니다.
장애는 트래픽 폭증보다 설정 실수에서 많이 납니다
사이트가 죽었다고 해서 항상 사람이 몰린 건 아닙니다. 실제로 많이 보는 원인은 디스크 가득 참, 인증서 만료, DB 접속 제한, PHP 버전 변경, 백업 실패, DNS 설정 실수입니다. 트래픽은 눈에 잘 보이는 핑계가 되지만, 원인은 운영 절차에 있는 경우가 많습니다.
특히 백업은 조용히 사고를 만듭니다. 원본과 백업을 같은 디스크에 두면 장애 때 같이 날아갑니다. 백업 파일을 매일 만들기만 하고 삭제 정책이 없으면 어느 날 디스크가 꽉 찹니다. 복구 테스트를 안 해두면 백업 파일이 있어도 쓸 수 없는 경우가 있습니다. 저는 백업을 잡을 때 최소한 보관 위치, 보관 기간, 복구 시간, 복구 담당자를 같이 정합니다.
- 디스크 사용률은 80퍼센트를 넘기기 전에 알림 설정
- SSL 인증서 만료일은 자동 갱신 여부와 별도로 확인
- DB 백업은 생성보다 복구 테스트가 중요
- 이미지 업로드 폴더는 백업 용량 증가 속도 확인
- DNS 변경 전에는 기존 레코드 값을 별도로 기록
장애가 났을 때는 순서도 중요합니다. 먼저 도메인 해석이 되는지 보고, 그다음 서버 응답, 웹서버 상태, 애플리케이션 로그, DB 연결, 디스크 용량을 봅니다. 이 순서를 건너뛰고 바로 서버 재부팅부터 하면 원인 로그를 놓치기 쉽습니다.
트래픽 비용을 줄이는 실무적인 방법
사양을 올리기 전에 페이지 무게부터 줄이는 게 빠릅니다. 대표 이미지를 5MB로 올려놓고 서버를 바꾸는 건 순서가 틀렸습니다. 이미지를 적정 해상도로 줄이고, 브라우저 캐시를 주고, 압축 전송을 켜는 것만으로도 트래픽과 응답 시간이 같이 내려갑니다.
게시글 중심 사이트라면 HTML 캐시가 가장 효과적입니다. 로그인하지 않은 방문자에게 매번 PHP와 DB를 태우지 않고 만들어진 페이지를 주면 작은 서버도 오래 버팁니다. 반대로 장바구니나 개인화 화면은 캐시를 잘못 걸면 더 큰 사고가 납니다. 모든 페이지를 캐시한다는 식으로 접근하면 안 됩니다.
CDN은 월 전송량이 크거나 해외 방문자가 있을 때 가치가 있습니다. 다만 방문자가 적은 국내 사이트라면 먼저 이미지 최적화와 캐시 설정부터 잡는 편이 낫습니다. CDN을 붙였는데 원본 서버 캐시가 엉망이면 비용만 늘고 장애 지점만 하나 더 생깁니다.
트래픽을 계산할 때는 넉넉하게 잡되 겁먹을 필요는 없습니다. 페이지당 2MB, 월 10만 페이지뷰면 단순 계산으로 200GB입니다. 여기에 여유를 붙여 300GB에서 500GB 정도를 보면 됩니다. 이 정도는 비싼 클라우드 구성이 아니라도 처리 가능한 구간입니다. 진짜 비용은 서버비보다 점검 안 된 백업, 기록 없는 설정 변경, 만료된 인증서에서 나옵니다.
서버는 큰 걸 쓰면 편해 보이지만 운영이 단단해지는 건 아닙니다. 트래픽 숫자를 전송량과 동시접속으로 나눠서 보고, 그다음 캐시와 백업을 확인하면 불필요한 업그레이드를 꽤 줄일 수 있습니다. 저는 작은 서버를 무리하게 쓰자는 쪽은 아닙니다. 다만 계산 없이 큰 서버로 가는 습관은 장애도 비용도 잘 줄여주지 못했습니다.
