얼마 전 작은 쇼핑몰 서버 이전을 봐줬는데, 월 방문자 8만 명짜리 사이트에 16코어 VPS를 쓰고 있었습니다. 느린 원인은 CPU가 아니라 이미지 캐시 설정과 백업 스크립트였습니다. 새벽 3시에 전체 파일을 압축하면서 디스크 I/O를 다 먹고, 그 시간대 주문 페이지가 10초씩 밀렸습니다. 요금제를 올려도 해결되지 않는 전형적인 경우입니다.
서버는 무조건 큰 걸 쓰면 편하다고 생각하기 쉽습니다. 그런데 운영을 오래 해보면 과한 사양보다 애매한 설정이 더 무섭습니다. CPU 2코어 서버도 설정이 맞으면 꽤 오래 버티고, 8코어 서버도 백업과 로그가 엉키면 금방 죽습니다. 먼저 필요한 사양을 계산하고, 그다음 장애 지점을 줄이는 순서가 맞습니다.
서버 사양은 방문자 수보다 동시접속으로 봐야 합니다
월 방문자 10만 명이라는 숫자는 생각보다 서버 사양 계산에 직접적이지 않습니다. 중요한 건 같은 순간에 몇 명이 요청을 보내는지입니다. 예를 들어 월 10만 방문자라도 대부분 검색 유입이고 페이지뷰가 하루 종일 퍼져 있으면 동시접속은 5명 이하일 수 있습니다. 반대로 이벤트 페이지처럼 10분 안에 2천 명이 몰리면 월 방문자가 적어도 서버는 버거워집니다.
대략적인 계산은 이렇게 합니다. 하루 페이지뷰를 24시간으로 나누지 말고 피크 시간 기준으로 봅니다. 하루 3만 페이지뷰 사이트가 저녁 2시간에 40%를 처리한다면 1시간에 6천 페이지뷰입니다. 페이지 하나가 평균 3초 안에 처리된다면 단순 계산상 동시 처리 요청은 5건 안팎입니다. 여기에 이미지, CSS, API, 관리자 작업, 크롤러를 더해 여유를 잡습니다.
- 개인 블로그, 회사 소개 사이트: 1코어, 메모리 1GB도 가능한 구간이 많습니다.
- 워드프레스 블로그 월 10만~30만 페이지뷰: 캐시가 있다면 2코어, 메모리 2GB부터 봅니다.
- 소규모 쇼핑몰이나 예약 사이트: DB와 PHP 부하를 고려해 2~4코어, 메모리 4GB 정도가 현실적입니다.
- 동시접속 100명 이상이 자주 나오는 서비스: 웹서버와 DB 분리, 캐시 계층을 먼저 검토합니다.
물론 이 숫자는 출발점입니다. 실제로는 페이지 생성 시간이 더 중요합니다. 캐시 없는 워드프레스가 상품 목록을 1.5초에 만들면 CPU가 금방 찹니다. 같은 페이지를 캐시로 50ms에 내려주면 저가 VPS에서도 버팁니다. 서버 사양보다 요청당 비용을 줄이는 게 먼저입니다.
웹호스팅, VPS, 클라우드는 용도가 다릅니다
초기 사이트라면 웹호스팅이 부끄러운 선택이 아닙니다. 트래픽이 적고 서버 설정을 직접 만질 일이 없다면 월 몇 천 원짜리 웹호스팅이 VPS보다 안정적일 때도 있습니다. 특히 단순한 블로그, 랜딩 페이지, 회사 소개 사이트는 운영자가 보안 패치와 기본 백업을 챙겨주는 환경이 더 낫습니다.
VPS는 자유도가 필요한 순간부터 의미가 있습니다. Nginx 설정을 바꾸거나, Node.js 앱을 올리거나, Redis 같은 캐시를 붙이거나, 배포 자동화를 쓰려면 VPS가 편합니다. 대신 책임도 같이 옵니다. 방화벽, SSH 키, 패키지 업데이트, 로그 관리, 백업 복구 테스트를 직접 봐야 합니다. 이 부분을 안 하면 싼 서버가 싼 사고로 돌아옵니다.
클라우드 서버는 확장성과 부가 기능이 필요할 때 씁니다. 로드밸런서, 오토스케일링, 관리형 DB, 객체 스토리지, 스냅샷 정책이 필요한 서비스라면 비용이 올라가도 이유가 있습니다. 그런데 방문자 하루 500명인 블로그에 처음부터 복잡한 클라우드 구성을 얹는 건 대개 낭비입니다. 장애 대응 경험이 없다면 구성 요소가 많을수록 고장 지점도 늘어납니다.
싼 서버를 써도 되는 조건이 있습니다
무료나 저가 서버가 나쁜 게 아닙니다. 조건이 맞으면 아주 합리적입니다. 정적 페이지 위주이고, 댓글이나 장바구니처럼 실시간 DB 쓰기가 적고, 캐시를 적극적으로 쓸 수 있으면 저가 서버로도 충분합니다. 트래픽이 늘어도 CDN을 붙이고 이미지 용량을 줄이면 서버 본체 부하는 크게 줄어듭니다.
제가 보는 최소 조건은 세 가지입니다. 첫째, 백업을 서버 안에만 두지 않는 것. 둘째, 장애가 났을 때 DNS와 서버 접속 정보를 바로 찾을 수 있는 것. 셋째, 복구 절차를 한 번이라도 실제로 해본 것. 이 세 가지가 없으면 2만 원짜리 서버든 20만 원짜리 서버든 불안합니다.
저가 VPS에서 자주 나는 사고는 메모리 부족입니다. PHP-FPM 프로세스를 너무 많이 열어두거나, MySQL 버퍼를 과하게 잡거나, 백업 압축이 동시에 돌면 OOM으로 프로세스가 죽습니다. 1GB 메모리 서버라면 스왑 1~2GB를 잡고, PHP 워커 수를 보수적으로 제한하고, DB 설정도 기본값을 그대로 믿지 않는 편이 낫습니다. 성능 튜닝이라기보다 생존 설정에 가깝습니다.
백업은 저장보다 복구가 중요합니다
백업 파일이 있다는 말과 복구가 된다는 말은 다릅니다. 운영 중 가장 많이 본 실수는 백업이 매일 생성된다고 믿었는데 3개월 전부터 용량 초과로 실패하고 있던 경우입니다. 또 DB 백업은 있는데 업로드 파일이 없거나, 반대로 파일은 있는데 DB 덤프가 깨져 있는 경우도 흔합니다.
최소 백업은 파일, DB, 설정 파일 세 묶음으로 나눠야 합니다. 웹 루트만 복사하면 Nginx 가상호스트 설정, PHP 버전, 크론 작업, SSL 갱신 정보가 빠질 수 있습니다. 서버 이전을 해보면 이 빠진 조각들이 시간을 잡아먹습니다. 특히 워드프레스는 DB와 업로드 디렉터리의 시점이 너무 벌어지면 이미지나 첨부파일이 꼬입니다.
- DB 백업: 매일 1회 이상, 트랜잭션이 많은 사이트는 더 짧게 잡습니다.
- 파일 백업: 업로드가 잦은 사이트는 증분 백업을 씁니다.
- 보관 위치: 같은 서버 디스크만 믿지 말고 외부 저장소를 둡니다.
- 복구 점검: 최소 월 1회는 테스트 경로에 복원해 봅니다.
백업 시간도 조심해야 합니다. 방문자가 적은 시간에 돌리는 건 기본이고, 압축률을 무리하게 높이지 않는 게 좋습니다. CPU를 아끼려다가 디스크와 메모리를 같이 잡아먹는 경우가 있습니다. 사이트가 작을 때는 단순 압축도 괜찮지만, 용량이 커지면 증분 방식이나 스냅샷을 섞는 편이 안정적입니다.
장애가 나면 순서대로 봐야 빨리 찾습니다
사이트가 안 뜨면 많은 사람이 서버 업체 공지부터 찾습니다. 물론 장애 공지도 봐야 합니다. 다만 현장에서는 내 서버 안의 문제인 경우가 훨씬 많았습니다. 디스크 100%, 인증서 만료, 도메인 만료, 방화벽 규칙 변경, PHP 프로세스 고갈, DB 접속 실패가 단골입니다.
확인 순서는 단순해야 합니다. 도메인이 살아 있는지, 서버에 접속되는지, 웹서버 프로세스가 떠 있는지, 디스크와 메모리가 남아 있는지, 애플리케이션 로그가 무엇을 말하는지 순서대로 보면 됩니다. 이걸 건너뛰고 설정 파일부터 만지면 원인이 더 흐려집니다.
- 도메인: 만료일, 네임서버, DNS 레코드 변경 여부를 확인합니다.
- SSL: 인증서 만료와 자동 갱신 실패 로그를 봅니다.
- 서버 자원: CPU보다 디스크 사용률과 메모리 고갈을 먼저 봅니다.
- 웹서버: Nginx나 Apache 설정 테스트 후 재시작 여부를 판단합니다.
- DB: 접속 수, 느린 쿼리, 디스크 여유 공간을 확인합니다.
운영자는 장애가 안 나는 서버보다 장애가 났을 때 덜 헤매는 서버를 만들어야 합니다. 서버 메모리를 2GB에서 4GB로 올리는 건 쉽습니다. 그런데 백업 위치, 복구 순서, 로그 경로, 만료일 관리가 없으면 비용만 늘고 불안은 그대로 남습니다. 저는 새 서버를 고를 때도 사양표보다 운영 절차를 먼저 봅니다. 작은 서버라도 계산하고 관리하면 오래 갑니다. 반대로 큰 서버라도 기본을 놓치면 의외로 빨리 무너집니다.
