얼마 전 작은 쇼핑몰 서버 이전을 봐줬는데, 월 방문자가 많지 않은데도 처음 견적은 꽤 큰 클라우드 서버로 잡혀 있었습니다. 실제 로그를 보니 하루 방문자는 2천 명 안팎, 피크 시간 동시접속은 20명 정도였습니다. 이런 사이트는 서버를 키우는 것보다 캐시, 백업, 장애 복구 절차를 먼저 잡는 쪽이 훨씬 안전합니다.
14년 정도 웹서버와 호스팅 인프라를 운영하면서 느낀 건 단순합니다. 사이트가 죽는 이유는 트래픽 폭주보다 설정 실수, 디스크 꽉 참, 인증서 만료, 백업 부재가 더 많습니다. 그래서 저는 서버를 고를 때 요금제 이름보다 필요한 자원을 먼저 숫자로 계산합니다.
서버 사양은 방문자 수보다 동시접속으로 잡습니다
월 방문자 10만 명이라는 말만 보고 서버를 고르면 거의 빗나갑니다. 중요한 건 한순간에 몇 명이 동시에 요청을 보내는지입니다. 같은 월 10만 명이어도 뉴스형 사이트처럼 특정 시간에 몰리면 부담이 크고, 회사 소개 사이트처럼 하루 종일 퍼져 있으면 아주 작은 서버로도 버팁니다.
대략적인 감을 잡을 때는 피크 시간 방문자와 페이지당 요청 수를 봅니다. 워드프레스 기준으로 캐시가 잘 걸려 있고 이미지가 외부 스토리지나 CDN에 있다면 동시접속 20~50명 구간은 보급형 VPS로 충분한 경우가 많습니다. 반대로 로그인, 장바구니, 관리자 기능처럼 매번 PHP와 DB를 치는 요청이 많으면 같은 접속자라도 CPU와 DB 부하가 빨리 올라갑니다.
제가 먼저 보는 숫자
- 피크 시간 동시접속자 수
- 초당 요청 수와 평균 응답 시간
- DB 쿼리 시간과 느린 쿼리 비율
- 디스크 사용량과 로그 증가 속도
- 백업 파일까지 포함한 실제 저장 공간
처음부터 큰 서버를 쓰면 문제를 덮을 수는 있습니다. 그런데 비용이 계속 나갑니다. 월 1만 원대로 충분한 사이트가 월 7만 원짜리 서버를 쓰면 1년이면 차이가 꽤 납니다. 그 돈이면 백업 저장소, 모니터링, 장애 알림을 붙이는 편이 더 실용적입니다.
웹호스팅, VPS, 클라우드 서버를 이렇게 나눕니다
웹호스팅은 관리 부담이 낮습니다. 서버 설정을 직접 만지지 않아도 되고, 작은 회사 홈페이지나 포트폴리오, 트래픽이 낮은 블로그에는 아직도 충분합니다. 단점은 권한이 제한되고, 특정 플러그인이나 백그라운드 작업이 막히는 경우가 있다는 점입니다.
VPS는 가격 대비 자유도가 좋습니다. 웹서버, PHP, DB, 방화벽, 백업 스크립트를 직접 구성할 수 있습니다. 대신 운영 책임도 같이 옵니다. 업데이트를 미루거나 방화벽을 열어 둔 채 방치하면 저렴한 서버가 가장 비싼 사고로 돌아옵니다.
클라우드 서버는 확장성과 부가 기능이 장점입니다. 스냅샷, 로드밸런서, 오브젝트 스토리지, 관리형 DB 같은 선택지가 많습니다. 다만 처음부터 이것저것 붙이면 요금 구조가 복잡해집니다. 작은 사이트라면 월 고정비를 먼저 정하고, 그 안에서 CPU·메모리·스토리지·백업을 나눠 잡는 방식이 낫습니다.
규모별로 현실적인 선택
- 회사 소개 사이트, 월 방문자 1만 명 이하: 일반 웹호스팅이나 작은 VPS
- 블로그, 월 방문자 5만~20만 명: 캐시 적용 VPS 또는 관리형 웹호스팅 상위 상품
- 쇼핑몰, 예약 사이트: DB 성능과 백업 주기가 더 중요
- 이벤트성 트래픽: 서버 증설보다 CDN과 정적 캐시 우선
여기서 중요한 건 무료나 저가 구간을 무시하지 않는 태도입니다. 정적 페이지 위주의 사이트, 이미지 최적화가 된 블로그, 문의 폼 정도만 있는 회사 사이트는 비싼 클라우드 구조가 필요 없을 때가 많습니다. 비용을 아끼는 게 위험한 게 아니라, 구조를 모르고 아끼는 게 위험합니다.
장애는 대부분 사소한 곳에서 시작됩니다
서버 장애를 보면 드라마틱한 원인보다 평범한 원인이 많습니다. 로그가 쌓여 디스크가 100퍼센트가 되고, 자동 갱신이 실패해 SSL 인증서가 만료되고, 백업은 있다는데 복구 테스트를 한 번도 안 한 경우입니다. CPU가 부족해서 죽는 사이트보다 이런 관리 구멍 때문에 멈추는 사이트를 더 많이 봤습니다.
디스크는 특히 조용히 위험해집니다. 이미지 업로드, 접근 로그, 에러 로그, 백업 압축 파일이 같은 서버 안에 쌓이면 어느 날 갑자기 DB가 쓰기를 못 합니다. 운영체제는 살아 있는데 게시글 저장이 안 되거나 로그인 세션이 깨지는 식으로 나타납니다. 관리자 입장에서는 사이트가 이상하게 망가진 것처럼 보이지만 원인은 저장 공간입니다.
SSL도 자주 놓칩니다. 자동 갱신을 걸어놨더라도 방화벽, DNS 변경, 웹서버 설정 충돌 때문에 실패할 수 있습니다. 그래서 인증서는 설치보다 만료 알림이 중요합니다. 서버 운영에서는 한 번 잘 설정했다는 기억보다 지금도 정상인지 확인하는 장치가 더 믿을 만합니다.
백업은 저장보다 복구 기준으로 설계합니다
백업이 있다고 말하는 곳은 많습니다. 그런데 복구 시간을 물어보면 답이 흐려지는 경우가 많습니다. 실무에서는 백업 파일 존재보다 언제 시점으로, 몇 분 안에, 어디에 복구할 수 있는지가 중요합니다.
작은 사이트라도 최소한 DB와 업로드 파일은 분리해서 봐야 합니다. DB는 하루 1회 이상, 주문이나 회원 데이터가 있으면 더 짧은 주기로 잡습니다. 업로드 파일은 변경량이 크지 않다면 하루 1회로도 충분한 경우가 많습니다. 백업은 같은 서버 안에만 두면 의미가 약합니다. 서버 디스크가 깨지거나 계정이 잠기면 백업도 같이 묶입니다.
실무에서 쓰는 기본 백업 기준
- DB 백업은 자동화하고 최소 7일 이상 보관
- 업로드 파일은 별도 저장소나 다른 서버에 보관
- 월 1회 이상 실제 복구 테스트 진행
- 백업 실패 알림을 메일이나 메신저로 수신
- 개인정보가 포함된 백업은 접근 권한 제한
복구 테스트는 거창할 필요가 없습니다. 빈 서버나 임시 경로에 DB를 올리고, 파일을 붙여서 첫 화면과 관리자 로그인이 되는지 보면 됩니다. 이 과정을 한 번 해본 팀과 안 해본 팀은 장애가 났을 때 움직임이 다릅니다. 문서가 짧아도 괜찮습니다. 명령어, 계정 위치, 백업 경로, 담당자 연락처만 있어도 현장에서 시간을 줄입니다.
서버 이전은 DNS보다 데이터 동기화가 먼저입니다
서버 이전을 할 때 가장 흔한 실수는 새 서버를 만들자마자 DNS부터 바꾸는 겁니다. 순서는 반대에 가깝습니다. 새 서버에 동일한 웹서버 버전과 런타임을 맞추고, 파일과 DB를 복사한 뒤, 임시 접속 방식으로 화면과 기능을 먼저 확인해야 합니다.
쇼핑몰이나 회원 사이트는 이전 직전 쓰기 작업을 어떻게 막을지도 정해야 합니다. 주문이 들어오는 중에 DB를 복사하면 구 서버와 신 서버 데이터가 갈라집니다. 짧은 점검 시간을 잡거나, 마지막 증분 동기화를 하고, DNS TTL을 낮춰 전환 시간을 줄이는 방식이 안전합니다.
제가 쓰는 이전 순서
- 현재 서버의 PHP, DB, 웹서버 버전 확인
- 새 서버에 동일하거나 호환되는 환경 구성
- 파일과 DB 1차 복사 후 기능 점검
- DNS TTL을 미리 낮춰 전환 지연 축소
- 최종 데이터 동기화 후 접속 전환
- 구 서버는 며칠간 보존하고 로그 비교
이전 후에는 속도보다 에러 로그를 먼저 봅니다. 이미지 경로, 권한, 세션 저장 위치, 메일 발송 설정에서 문제가 자주 나옵니다. 첫 화면이 뜬다고 끝난 게 아닙니다. 로그인, 글쓰기, 결제, 문의 폼, 관리자 업로드까지 실제 사용 흐름을 확인해야 합니다.
서버는 크게 시작하는 것보다 작게 검증하는 편이 낫습니다
제가 보통 권하는 방식은 작은 서버로 시작하되 관측 장치를 붙이는 겁니다. CPU 사용률, 메모리, 디스크, 응답 시간, 에러 로그를 보면 언제 올려야 하는지 보입니다. 감으로 비싼 서버를 고르는 것보다 실제 수치로 한 단계씩 올리는 편이 운영비도 낮고 장애 원인도 잘 보입니다.
물론 무조건 싸게 가자는 뜻은 아닙니다. 매출이 서버에 직접 묶인 쇼핑몰, 예약 서비스, 광고 집행 중인 랜딩 페이지는 여유 자원이 필요합니다. 다만 그 여유는 막연한 고사양이 아니라 피크 시간, 복구 시간, 백업 주기, 장애 알림까지 포함해서 계산해야 합니다.
서버 비용을 잘 쓰는 사람은 비싼 상품을 고르는 사람이 아닙니다. 지금 사이트가 실제로 쓰는 자원과 멈췄을 때의 손실을 아는 사람입니다. 작은 서버라도 백업과 모니터링이 제대로 붙어 있으면 꽤 오래 버팁니다. 반대로 큰 서버라도 운영 절차가 비어 있으면 장애는 결국 같은 자리에서 납니다.
