얼마 전 작은 쇼핑몰 이전 상담을 했는데, 월 방문자 3만 명 정도인 사이트에 8코어 클라우드 서버 견적이 붙어 있었습니다. 실제 로그를 보니 피크 동시접속은 18명 안팎이었고, 이미지 용량이 큰 것 말고는 특별한 부하가 없었습니다. 이런 경우 서버를 키우는 것보다 캐시와 백업, SSL 갱신 상태를 먼저 보는 게 맞습니다.
서버는 비싼 것을 고르면 안정적일 것 같지만, 운영 현장에서는 꼭 그렇지 않습니다. 사양이 넉넉해도 설정이 엉키면 죽고, 저가형 웹호스팅이라도 트래픽 패턴이 맞으면 몇 년씩 조용히 갑니다. 그래서 저는 서버를 고를 때 브랜드나 월요금보다 먼저 숫자를 봅니다. 하루 방문자, 피크 시간대 접속자, 페이지당 요청 수, 이미지와 파일 다운로드량, 백업 방식. 이 네다섯 개만 잡아도 과한 요금제는 꽤 걸러집니다.
서버 사양은 방문자 수보다 동시접속으로 봅니다
초보자가 가장 많이 헷갈리는 부분이 하루 방문자 수입니다. 하루 1만 명이라고 해서 동시에 1만 명이 들어오는 게 아닙니다. 일반 블로그나 회사 소개 사이트는 피크 시간에도 동시접속이 전체 일 방문자의 0.5~2퍼센트 정도인 경우가 많습니다. 하루 5천 명이면 순간 동시접속 25~100명 정도를 먼저 가정합니다. 콘텐츠가 검색 유입 위주면 더 낮게 잡히고, 광고를 한 번에 태우거나 이벤트 페이지를 열면 더 높게 튑니다.
정적 페이지가 많고 캐시가 잘 먹는 사이트라면 동시접속 50명은 저가형 VPS나 중급 웹호스팅으로도 충분한 경우가 많습니다. 반대로 워드프레스에 플러그인이 30개 붙어 있고, 로그인 사용자마다 다른 화면을 보여주며, 상품 검색이 데이터베이스를 계속 때리는 구조라면 같은 50명도 버거울 수 있습니다. 숫자는 방문자가 아니라 요청이 서버에 얼마나 무겁게 닿는지를 봐야 합니다.
대략적인 출발선
- 회사 소개, 포트폴리오, 일반 블로그: 공유 웹호스팅 또는 1코어 VPS부터 시작해도 되는 경우가 많습니다.
- 워드프레스 블로그, 월 방문자 3만 명 이하: 1~2코어, 메모리 1~2GB, 캐시 적용을 기본으로 봅니다.
- 소규모 쇼핑몰, 피크 동시접속 50명 전후: 2코어, 메모리 4GB 정도를 출발점으로 잡고 DB 부하를 따로 봅니다.
- 회원 기능과 관리자 작업이 많은 서비스: CPU보다 메모리, DB I/O, 백업 시간대를 먼저 봅니다.
웹호스팅, VPS, 클라우드 서버는 용도가 다릅니다
웹호스팅은 관리 부담이 적습니다. 서버 설정을 깊게 만지지 않아도 되고, PHP와 DB, SSL, 메일 같은 기본 구성이 이미 잡혀 있습니다. 단점은 세밀한 튜닝이 어렵고, 같은 장비를 여러 사용자가 나눠 쓰기 때문에 이웃 계정 영향이 있을 수 있다는 점입니다. 그래도 트래픽이 낮고 운영자가 개발자가 아니라면 웹호스팅이 더 안정적인 선택일 때가 많습니다.
VPS는 가격 대비 자유도가 좋습니다. 직접 웹서버와 데이터베이스를 설치하고, 캐시 서버를 붙이고, 백업 스크립트도 짤 수 있습니다. 대신 운영 책임도 같이 옵니다. 방화벽을 열어놓고 잊거나, 자동 보안 업데이트를 끄거나, 디스크 알림을 안 걸어두면 장애는 조용히 쌓이다가 한 번에 터집니다. 서버 경험이 없다면 저렴한 VPS가 싼 게 아닐 수 있습니다. 시간을 같이 계산해야 합니다.
클라우드 서버는 확장성과 부가 기능이 강점입니다. 스냅샷, 로드밸런서, 오브젝트 스토리지, 관리형 DB 같은 선택지가 많습니다. 근데 작은 사이트에서 처음부터 전부 붙이면 월 비용만 복잡해집니다. 실무에서는 먼저 단일 서버로 버틸 수 있는지 보고, 병목이 확인되면 이미지 저장소 분리, DB 분리, 캐시 추가 순서로 갑니다. 구조가 단순할수록 장애 때 원인 찾기도 빠릅니다.
싼 요금제로 충분한 구간이 분명히 있습니다
트래픽이 하루 1천 명 이하이고 페이지가 대부분 글과 이미지라면, 서버보다 이미지 최적화와 캐시가 더 중요합니다. 원본 사진을 그대로 올려 한 페이지가 15MB가 되는 사이트를 자주 봅니다. 이 상태에서 서버만 올리면 첫 화면은 여전히 느립니다. 이미지 폭을 줄이고 압축하고, 브라우저 캐시를 걸면 체감 속도가 먼저 좋아집니다.
월 방문자 1만~5만 명 규모의 블로그도 캐시가 제대로 잡혀 있으면 큰 서버가 필요하지 않은 경우가 많습니다. 워드프레스라면 페이지 캐시, 객체 캐시, PHP 버전, DB 테이블 상태를 먼저 확인합니다. CPU 사용률이 항상 낮은데 응답이 느리다면 디스크 I/O나 외부 API, 플러그인 문제일 수 있습니다. 이런 상황에서 코어 수만 늘리는 건 돈으로 안개를 사는 느낌입니다.
사양을 올리기 전에 보는 항목
- 피크 시간 CPU 사용률이 70퍼센트 이상으로 지속되는지 확인합니다.
- 메모리 부족으로 스왑이 계속 발생하는지 봅니다.
- 디스크 사용률이 80퍼센트를 넘었는지, 로그가 과하게 쌓였는지 확인합니다.
- DB 쿼리 지연, 느린 플러그인, 외부 호출 대기 시간이 있는지 봅니다.
- 백업이 피크 시간에 돌면서 서버를 밀어붙이는지 확인합니다.
장애는 설정과 백업에서 많이 납니다
제가 본 장애 중에는 트래픽 폭증보다 설정 실수가 더 많았습니다. SSL 인증서 갱신 실패, 도메인 DNS 변경 후 전파 시간 착각, 방화벽 포트 누락, PHP 버전 변경으로 플러그인 오류, 디스크 꽉 참, 백업 파일이 같은 서버에만 있는 경우. 이런 문제는 서버 사양을 아무리 키워도 막히지 않습니다.
백업은 특히 냉정하게 봐야 합니다. 백업이 있다고 말하는 것과 복구가 되는 것은 다릅니다. 운영 서버 안에 압축 파일 하나 만들어두는 건 백업이라기보다 임시 복사에 가깝습니다. 최소한 다른 저장소에 보관해야 하고, DB와 업로드 파일의 시점이 맞아야 합니다. 쇼핑몰은 주문 데이터가 계속 바뀌기 때문에 하루 한 번 백업만으로는 부족할 수 있습니다.
이전 작업도 순서가 중요합니다. 새 서버에 파일과 DB를 먼저 올리고, 임시 접속으로 화면과 로그인, 주문, 문의 폼을 확인한 뒤 DNS를 바꿉니다. TTL을 미리 낮춰두면 전환 시간이 줄어듭니다. SSL은 새 서버에서 먼저 발급하거나 배포 가능한 상태로 만들어둬야 합니다. DNS부터 바꾸고 나서 인증서를 맞추면 짧게라도 보안 경고가 뜰 수 있습니다.
서버 선택은 넉넉함보다 복구 가능성이 먼저입니다
운영자는 장애가 안 나는 서버를 꿈꾸지만, 실제로는 빨리 확인하고 빨리 되돌릴 수 있는 구성이 더 현실적입니다. 모니터링 알림, 최근 백업, 복구 테스트, 설정 변경 기록이 있으면 작은 장애는 크게 번지지 않습니다. 반대로 아무 기록 없이 여러 사람이 관리자 화면을 만지는 사이트는 사양이 좋아도 위험합니다.
처음 서버를 고른다면 너무 멀리 보지 않아도 됩니다. 현재 트래픽 기준으로 3~6개월 정도 버틸 사양을 잡고, 이미지와 캐시, 백업부터 제대로 맞추는 편이 낫습니다. 방문자가 늘면 그때 로그를 보고 올리면 됩니다. 서버 비용은 매달 나가는 돈이라서 작은 차이가 오래 쌓입니다. 필요한 만큼만 쓰고, 복구 가능한 구조를 만들어두는 게 제가 오래 운영하면서 가장 덜 후회한 방식입니다.
