모두
모두콘텐츠
트래픽보다 먼저 봐야 할 건 구조입니다
얼마 전 작은 쇼핑몰 이전을 도와줬는데, 월 방문자가 3만 명도 안 되는 사이트에 8코어 VPS를 쓰고 있었습니다. 사장님은 트래픽 때문에 비싼 서버가 필요한 줄 알았다고 하더군요. 그런데 실제 병목은 서버 사양이 아니라 이미지 원본 업로드, 캐시 미적용, 백업 파일을 같은 디스크에 쌓아둔 운영 방식이었습니다.
서버호스팅을 고를 때 많은 분들이 CPU 코어 수와 메모리부터 봅니다. 물론 중요합니다. 다만 순서가 조금 다릅니다. 먼저 사이트 성격, 동시접속, DB 사용량, 파일 업로드 패턴, 백업 방식부터 봐야 합니다. 이걸 건너뛰면 작은 사이트도 큰 요금제를 쓰게 되고, 반대로 필요한 곳에 돈을 안 써서 장애가 납니다.
제가 실무에서 자주 쓰는 기준은 동시접속입니다. 월 방문자 수는 참고값이고, 실제 서버 부담은 특정 시간대에 몇 명이 동시에 붙느냐로 갈립니다. 월 10만 방문자라도 하루 종일 고르게 들어오면 저가 VPS로 충분할 수 있습니다. 반대로 이벤트 문자 한 번에 5분 동안 500명이 몰리면 같은 방문자 수라도 서버 반응이 바로 무너질 수 있습니다.
초기 사이트라면 싼 서버호스팅으로도 충분한 구간이 있습니다
신규 블로그, 회사 소개 사이트, 작은 랜딩페이지는 대개 고사양 서버가 필요하지 않습니다. 정적 페이지 중심이고 관리자 로그인도 적다면 공유 웹호스팅이나 저가 VPS로 시작해도 됩니다. 하루 방문자 1천 명 이하, 동시접속 10명 안팎, 이미지가 과하게 크지 않은 사이트라면 월 몇 천 원대 서비스에서도 버티는 경우가 많습니다.
워드프레스라고 해서 무조건 고사양이 필요한 것도 아닙니다. 테마가 가볍고 플러그인이 적고 페이지 캐시가 켜져 있으면 생각보다 오래 갑니다. 반대로 플러그인 40개, 빌더 테마, 외부 스크립트 다수, 원본 이미지 업로드 조합이면 방문자가 적어도 느려집니다. 이건 서버호스팅 문제가 아니라 운영 습관 문제에 가깝습니다.
- 회사 소개 사이트: 공유 웹호스팅 또는 1코어 VPS로 시작 가능
- 개인 블로그: 캐시 적용 시 저가 서버로 충분한 경우가 많음
- 소형 쇼핑몰: 상품 수와 결제 피크 시간대를 보고 결정
- 예약·접수 사이트: 순간 동시접속을 따로 계산해야 함
여기서 중요한 건 처음부터 크게 사지 않는 겁니다. 서버는 집처럼 한 번 사면 끝나는 물건이 아닙니다. 모니터링을 보면서 올리면 됩니다. CPU 사용률이 평소 10~20%인데 4코어에서 8코어로 올리는 건 대부분 체감이 없습니다. 오히려 캐시, 이미지 리사이즈, DB 인덱스가 훨씬 큰 효과를 냅니다.
서버호스팅 사양은 이렇게 계산합니다
간단하게 시작하면 됩니다. 먼저 페이지 하나가 서버에서 얼마나 무거운지 봅니다. 캐시가 없는 동적 페이지인지, 캐시된 HTML인지, DB 조회가 많은지에 따라 필요한 사양이 달라집니다. 일반적인 블로그 글 페이지가 캐시되어 있다면 요청 하나는 아주 가볍습니다. 그런데 상품 검색, 회원 등급 계산, 장바구니, 재고 조회가 얽히면 요청 하나의 무게가 확 올라갑니다.
초기 기준으로는 1코어 1GB 메모리 VPS도 쓸 수 있습니다. 다만 워드프레스와 DB를 같은 서버에 올리고, 관리자 작업을 자주 하고, 이미지 처리까지 한다면 2GB 메모리를 권합니다. 메모리는 부족하면 바로 스왑이 생기고, 스왑이 생기면 사이트가 갑자기 멈춘 것처럼 느려집니다. CPU보다 메모리 부족이 더 흔한 사고 원인입니다.
제가 보는 최소 기준
- 정적 사이트: 1코어, 512MB~1GB 메모리도 가능
- 가벼운 워드프레스: 1코어, 1~2GB 메모리
- 소형 쇼핑몰: 2코어, 2~4GB 메모리부터 검토
- 동시접속 100명 이상 이벤트형 사이트: 캐시와 분산 구조를 먼저 설계
디스크는 용량보다 종류와 백업 위치가 중요합니다. SSD 기반이면 대부분의 소형 사이트에는 충분합니다. 문제는 업로드 파일과 백업 파일을 같은 서버 안에 계속 쌓는 방식입니다. 실제로 장애가 난 현장을 보면 트래픽보다 디스크 100%가 원인인 경우가 꽤 있습니다. 로그 파일, 자동 백업 압축 파일, 원본 이미지가 조용히 디스크를 채웁니다.
웹호스팅, VPS, 클라우드 서버는 용도가 다릅니다
웹호스팅은 관리가 편합니다. 서버 보안 패치, 기본 웹서버 설정, 메일 같은 부가 기능을 업체가 어느 정도 잡아줍니다. 대신 자유도가 낮습니다. 특정 모듈 설치, 서버 튜닝, 백그라운드 작업이 필요하면 답답해집니다. 초보자나 작은 회사 소개 사이트라면 이 편함이 장점입니다.
VPS는 가성비가 좋습니다. 루트 권한을 받고 직접 운영합니다. Nginx, Apache, PHP-FPM, MariaDB, Redis 같은 구성을 마음대로 잡을 수 있습니다. 대신 책임도 같이 옵니다. 방화벽, 업데이트, SSL 갱신, 로그 관리, 백업 검증을 직접 챙겨야 합니다. 서버호스팅 경험이 없다면 처음 한 달은 설정 실수로 시간을 꽤 씁니다.
클라우드 서버는 확장성과 부가 서비스가 강점입니다. 로드밸런서, 오브젝트 스토리지, 관리형 DB, 스냅샷, 보안 그룹 같은 기능을 조합할 수 있습니다. 근데 비용 구조가 복잡합니다. 서버 요금만 보고 들어갔다가 트래픽, 디스크, 백업, 부가 서비스 비용이 붙어 예상보다 커질 수 있습니다. 월 1만 원짜리 VPS로 충분한 사이트를 클라우드 구조로 만들면 운영비와 관리 난도가 같이 올라갑니다.
- 운영 지식이 적고 사이트가 작다: 웹호스팅
- 비용을 낮추고 직접 튜닝하고 싶다: VPS
- 트래픽 변동이 크고 서비스 조합이 필요하다: 클라우드 서버
장애를 줄이는 건 사양보다 백업과 점검 순서입니다
사이트가 죽으면 대부분 먼저 서버를 올리려고 합니다. 그런데 원인을 모른 채 사양만 올리면 같은 문제가 다시 옵니다. CPU가 100%인지, 메모리가 부족한지, DB 커넥션이 꽉 찼는지, 디스크가 찼는지, DNS가 틀어졌는지 순서대로 봐야 합니다. 특히 이전 작업 뒤에는 DNS, SSL, 파일 권한, DB 접속 정보에서 사고가 많이 납니다.
이전 전에 꼭 확인할 항목
- 현재 서버의 PHP, DB 버전
- 전체 파일 용량과 DB 용량
- 업로드 폴더 권한
- SSL 인증서 적용 방식
- DNS TTL 값과 변경 예정 시간
- 백업 파일을 복원해 본 기록
백업은 만들어졌다는 사실보다 복원되는지가 중요합니다. 자동 백업이 매일 돈다고 해도 복원 테스트를 한 번도 안 했다면 아직 백업이라고 보기 어렵습니다. 최소한 월 1회는 별도 위치에 내려받아 압축이 풀리는지, DB가 import 되는지 확인해야 합니다. 쇼핑몰이나 예약 사이트라면 파일 백업과 DB 백업 주기도 다르게 잡아야 합니다. 이미지는 하루 한 번이어도 되지만 주문 DB는 더 짧은 간격이 필요할 수 있습니다.
저는 서버호스팅을 고를 때 스펙표보다 백업 정책을 먼저 봅니다. 스냅샷을 제공하는지, 별도 보관인지, 보관 기간은 며칠인지, 사용자가 직접 내려받을 수 있는지 확인합니다. 장애가 났을 때 30분 안에 복구할 수 있는 구조라면 조금 낮은 사양도 운영 가능합니다. 반대로 8코어 서버라도 백업이 같은 디스크에만 있으면 디스크 장애 한 번에 끝입니다.
처음 선택할 때는 업그레이드 경로까지 같이 봐야 합니다
서버호스팅은 현재 비용만 보면 안 됩니다. 나중에 상위 요금제로 올릴 때 IP가 유지되는지, 디스크 확장이 가능한지, 스냅샷으로 이전할 수 있는지 봐야 합니다. 작은 사이트는 싸게 시작하되, 커질 때 옮길 수 있어야 합니다. 이 경로가 막혀 있으면 저렴하게 시작한 비용보다 이전 비용이 더 커집니다.
도메인과 SSL도 같은 맥락입니다. 도메인은 소유권과 관리 계정이 중요하고, SSL은 자동 갱신이 안정적으로 돌아가는지가 중요합니다. 사이트 운영자가 도메인 계정도 모르고, SSL 만료 알림도 못 받는 상태면 언젠가 한 번은 멈춥니다. 실제 장애 접수 중에는 서버가 멀쩡한데 도메인 만료나 SSL 만료로 접속이 안 되는 경우가 꾸준히 있습니다.
처음 서버호스팅을 고른다면 비싼 상품명보다 내 사이트가 어떤 부하를 만드는지부터 적어보는 편이 낫습니다. 방문자 수, 피크 시간, 동시접속 예상, DB 용량, 업로드 파일 증가량, 백업 위치를 적으면 필요한 사양이 꽤 선명해집니다. 서버는 크게 사는 것보다 맞게 사는 쪽이 오래 갑니다. 남는 돈은 모니터링과 백업에 쓰는 게 실제 운영에서는 더 든든합니다.
