모두
모두콘텐츠
서버는 트래픽보다 사용 패턴부터 봐야 합니다
얼마 전 작은 쇼핑몰 이전 상담을 했는데, 월 방문자는 3만 명 정도인데도 8코어 VPS를 쓰고 있었습니다. 막상 로그를 보니 동시 접속은 피크 시간에도 25명 안팎이었고, 느려지는 원인은 서버 사양이 아니라 이미지 원본 업로드와 백업 작업 시간이 겹친 문제였습니다. 이런 경우 서버를 키우면 잠깐 편해 보이지만 비용만 계속 새어 나갑니다.
서버 사양을 고를 때 제일 먼저 볼 것은 월 방문자 수가 아닙니다. 동시 접속, 요청 수, 페이지 무게, DB 사용량, 백업 방식이 먼저입니다. 방문자가 하루 1만 명이어도 대부분이 짧게 보고 나가면 작은 서버로 충분할 수 있습니다. 반대로 방문자는 적어도 관리자 화면에서 엑셀 다운로드, 이미지 변환, 검색 쿼리가 자주 돌면 CPU와 메모리가 금방 막힙니다.
현장에서 대충 잡는 기준은 이렇습니다. 단순 회사 소개 사이트나 블로그는 동시 접속 20명 이하라면 1코어, 메모리 1GB로도 버팁니다. 워드프레스에 플러그인이 많고 관리자 작업이 잦으면 2코어, 메모리 2GB부터 보는 편이 낫습니다. 쇼핑몰이나 예약 사이트처럼 DB 쓰기가 많은 서비스는 트래픽이 작아도 메모리 4GB 이상이 편합니다. 근데 여기서도 캐시를 제대로 쓰면 한 단계 낮출 수 있습니다.
CPU, 메모리, 디스크를 따로 계산하는 방법
CPU는 순간 작업량을 봅니다. PHP, Node, Python 같은 애플리케이션 서버가 요청을 처리하고, 이미지 리사이즈나 압축 작업이 붙으면 CPU가 치솟습니다. 게시판형 사이트는 CPU보다 DB와 캐시가 더 중요할 때가 많고, 이미지 썸네일을 실시간으로 만드는 사이트는 방문자가 적어도 CPU가 먼저 찹니다.
메모리는 여유분이 없으면 바로 체감됩니다. 리눅스 서버에서 메모리가 부족하면 스왑을 쓰는데, 이때부터 응답 속도가 갑자기 느려집니다. 웹서버, PHP-FPM, DB, 캐시가 같은 서버에 있으면 1GB는 꽤 빡빡합니다. 운영 경험상 워드프레스 단일 사이트라도 플러그인 15개 이상, 방문자 피크가 있는 구조라면 2GB를 기본으로 잡는 게 덜 피곤했습니다.
디스크는 용량보다 I/O가 중요합니다. 로그, 세션, DB 임시 파일, 백업 압축이 동시에 돌면 용량은 남았는데 사이트가 멈춘 것처럼 보일 수 있습니다. 특히 저가형 웹호스팅에서 같은 물리 장비를 여러 계정이 나눠 쓰면 이 현상이 더 자주 보입니다. 파일 업로드가 많은 사이트라면 SSD 여부와 백업 저장 위치를 꼭 따로 봐야 합니다.
- 정적 페이지 중심: 1코어, 1GB, SSD 20GB부터 시작 가능
- 일반 블로그: 1~2코어, 2GB, SSD 30GB 권장
- 워드프레스 쇼핑몰: 2코어, 4GB, SSD 50GB 이상 권장
- 예약·결제·회원 기능 중심: 2~4코어, 4~8GB를 먼저 검토
웹호스팅과 VPS를 나누는 기준
처음부터 VPS가 답은 아닙니다. 사실 방문자가 적고 관리자 작업이 단순한 사이트는 웹호스팅이 더 낫습니다. 운영체제 패치, 웹서버 설정, 기본 보안 업데이트를 직접 챙기지 않아도 되니까요. 월 비용도 낮고 장애가 났을 때 확인 범위가 줄어듭니다.
VPS가 필요한 순간은 권한과 격리가 필요할 때입니다. 특정 PHP 확장 모듈을 써야 하거나, Node 서버를 상시 실행해야 하거나, 배치 작업과 큐 워커를 직접 돌려야 한다면 웹호스팅은 금방 답답해집니다. SSH 접근이 필요하고, Nginx 설정을 직접 만져야 하고, 방화벽 정책을 따로 잡아야 하면 VPS로 가는 게 맞습니다.
클라우드 서버는 더 큰 유연성을 주지만, 비용 구조가 복잡합니다. 서버 요금만 보고 싸다고 판단하면 안 됩니다. 트래픽 전송량, 스냅샷, 로드밸런서, 객체 스토리지, 백업 보관 비용이 붙습니다. 작은 사이트는 클라우드가 오히려 과할 수 있습니다. 저는 월 매출이나 업무 중요도가 낮은 초기 사이트라면 저가 VPS나 안정적인 웹호스팅부터 권합니다.
장애는 사양보다 설정에서 더 자주 납니다
서버가 죽었다고 하면 대부분 트래픽 폭주를 떠올리지만, 실제로는 설정 실수가 많습니다. SSL 인증서 갱신 실패, 디스크 100퍼센트, DB 커넥션 초과, PHP-FPM 프로세스 고갈, 백업 압축 중 I/O 포화 같은 것들입니다. 전부 사양 증설 없이도 예방할 수 있는 항목입니다.
가장 먼저 보는 순서는 단순해야 합니다. 서버가 살아 있는지, 디스크가 찼는지, 웹서버가 응답하는지, DB 접속이 되는지, 최근 배포나 설정 변경이 있었는지 확인합니다. 이 순서가 흐트러지면 괜히 방화벽을 건드리거나 DNS를 바꾸다가 장애 시간이 길어집니다. 솔직히 장애 때는 똑똑한 추측보다 같은 순서로 반복 확인하는 습관이 더 강합니다.
- 접속 불가: 서버 전원 상태, 방화벽, 웹서버 프로세스 확인
- 느림: CPU 사용률, 메모리, 디스크 I/O, DB 슬로우 쿼리 확인
- 간헐 장애: 동시 접속 수, 커넥션 제한, 크론 작업 시간 확인
- SSL 오류: 인증서 만료일, 중간 인증서, 자동 갱신 로그 확인
백업은 복구 시간까지 계산해야 합니다
백업이 있다고 말하는 사이트 중에 실제 복구 테스트를 해본 곳은 생각보다 적습니다. 파일만 백업하고 DB가 빠져 있거나, DB는 있는데 업로드 파일이 없거나, 백업 파일이 같은 서버 안에만 있는 경우도 많습니다. 같은 서버 디스크가 깨지면 백업도 같이 사라집니다.
운영 기준으로는 최소 3가지를 봅니다. 얼마나 자주 백업하는지, 어디에 보관하는지, 얼마나 빨리 복구할 수 있는지입니다. 하루에 주문이 몇 건 안 들어오는 쇼핑몰이라도 주문 DB는 중요합니다. 반대로 단순 소개 사이트는 매시간 백업보다 변경 후 수동 백업이 더 현실적일 수 있습니다.
백업 주기는 사이트 성격에 맞추면 됩니다. 블로그는 하루 1회 DB 백업과 주 1회 파일 백업으로 충분한 경우가 많습니다. 쇼핑몰은 DB를 하루 여러 번 나누는 게 낫습니다. 회원 가입, 결제, 예약이 있는 사이트는 백업 간격이 곧 데이터 손실 범위입니다. 여기서 비용을 아끼려면 서버 사양보다 백업 보관 정책을 먼저 조정하는 편이 낫습니다.
처음 서버를 고를 때 제가 쓰는 기준
처음에는 넉넉하게 사고 나중에 줄이는 방식보다, 필요한 기준을 잡고 한 단계 여유를 두는 쪽이 좋습니다. 예를 들어 블로그 하나라면 1코어 1GB에서 시작하되, 워드프레스 플러그인이 많으면 2GB로 올립니다. 쇼핑몰은 시작부터 2코어 4GB를 잡고, 이미지와 백업은 서버 밖으로 빼는 구성을 선호합니다.
사이트가 커질 때도 무조건 서버를 키우기 전에 캐시, 이미지 최적화, DB 인덱스, 백업 시간부터 봅니다. 이 네 가지만 손봐도 체감 성능이 좋아지는 경우가 많습니다. 서버 비용은 매달 나가는 고정비라서 한번 과하게 잡으면 줄이기 어렵습니다. 운영자는 사양을 크게 사는 사람이 아니라, 어디가 막히는지 정확히 보는 사람에 가깝습니다.
서버는 비싼 요금제를 고르는 문제가 아니라 위험을 줄이는 문제입니다. 작은 사이트는 작게 시작해도 됩니다. 다만 백업과 복구 절차, SSL 갱신, 디스크 사용량 알림은 처음부터 챙겨야 합니다. 제가 오래 운영하면서 본 사고의 대부분은 트래픽보다 이런 기본 항목을 놓친 데서 시작했습니다.
