얼마 전 작은 쇼핑몰 이전 작업을 했는데, 월 방문자가 3만 명 정도인데도 8코어 VPS를 쓰고 있었습니다. 관리자분은 트래픽이 많아서 그런 줄 알았다고 했지만, 실제로는 이미지 캐시가 안 잡히고 백업 스크립트가 낮 시간에 돌면서 서버를 눌러버린 상태였습니다. 서버 비용을 올리기 전에 먼저 봐야 할 건 숫자입니다.
서버 사양은 방문자 수보다 동시접속으로 봅니다
월 방문자 10만 명이라는 말은 커 보이지만, 하루로 나누면 평균 3천 명 조금 넘습니다. 피크 시간에 10%가 몰린다고 잡아도 한 시간 300명, 분당 5명 수준입니다. 일반적인 회사 소개 사이트나 블로그라면 공유 웹호스팅이나 1코어 1GB VPS로도 버티는 경우가 많습니다.
문제는 페이지가 얼마나 무거운지입니다. 워드프레스에 플러그인이 30개 있고, 첫 화면 이미지가 5MB라면 방문자 수가 적어도 느려집니다. 반대로 정적 페이지 위주이고 캐시가 잘 걸려 있으면 낮은 사양에서도 안정적입니다. 저는 보통 먼저 피크 시간 기준 동시접속을 계산하고, 그다음 페이지 생성 방식과 DB 부하를 봅니다.
- 개인 블로그, 회사 소개: 1코어, 메모리 1GB부터 검토
- 워드프레스 소형 쇼핑몰: 2코어, 메모리 2GB 이상 권장
- 상품 수가 많고 검색이 잦은 쇼핑몰: DB 분리 또는 메모리 4GB 이상 검토
- 이미지·파일 다운로드가 많은 사이트: 서버보다 스토리지와 전송량 조건을 먼저 확인
웹호스팅, VPS, 클라우드 서버를 고르는 기준
처음부터 클라우드 서버가 정답은 아닙니다. 운영자가 리눅스 명령어와 방화벽, 웹서버 설정을 다룰 수 없다면 관리형 웹호스팅이 더 안정적일 때가 많습니다. 서버는 자유도가 높을수록 책임도 같이 올라갑니다. SSL 갱신, PHP 버전, DB 백업, 보안 패치가 전부 운영자의 일이 됩니다.
웹호스팅이 맞는 구간
트래픽이 작고 관리자 화면에서 글을 올리는 정도라면 웹호스팅이 편합니다. 월 수천 원짜리 요금제도 캐시만 제대로 쓰면 충분합니다. 다만 동시접속 제한, DB 용량, 파일 개수 제한은 꼭 봐야 합니다. 디스크 용량 10GB라고 적혀 있어도 inode 제한 때문에 파일이 많은 사이트는 막히는 일이 있습니다.
VPS가 필요한 구간
PHP 설정을 바꾸거나, Node 같은 별도 런타임을 올리거나, 배포 자동화를 쓰려면 VPS가 낫습니다. 2코어 2GB 정도면 작은 서비스 하나는 무난하게 시작할 수 있습니다. 다만 스왑 없이 메모리가 꽉 차면 DB가 죽거나 웹서버가 응답을 멈춥니다. 모니터링을 안 붙인 VPS는 싸 보이지만 장애를 늦게 알아차리는 비용이 붙습니다.
클라우드 서버가 맞는 구간
트래픽 변동이 크고, 서버를 여러 대로 나누고, 로드밸런서나 오브젝트 스토리지를 쓸 계획이 있으면 클라우드가 편합니다. 하지만 작은 사이트 하나에 클라우드 구성부터 잡으면 비용 구조가 복잡해집니다. 인스턴스 비용보다 로그 저장, 스냅샷, 전송량, 백업 보관 비용이 더 거슬릴 때도 있습니다.
서버가 죽는 흔한 원인은 과부하가 아닐 때가 많습니다
현장에서 본 장애 중 상당수는 트래픽 폭증보다 설정 실수에서 시작됐습니다. SSL 자동 갱신 실패, PHP 메모리 제한, DB 연결 수 초과, 로그 파일 폭증, 백업 파일이 같은 디스크를 가득 채운 경우가 많았습니다. 특히 백업은 한다고 끝이 아닙니다. 복구 테스트를 안 한 백업은 실제 사고 때 믿기 어렵습니다.
백업은 최소한 파일과 DB를 나눠서 봐야 합니다. 워드프레스라면 업로드 파일, 테마, 플러그인, DB가 각각 복구되어야 사이트가 살아납니다. 매일 새벽 백업을 돌린다면 그 시간대 CPU와 디스크 I/O가 튀는지도 봐야 합니다. 방문자가 적은 사이트가 새벽마다 느려지는 이유가 백업 압축 작업인 경우가 꽤 있습니다.
- 백업 파일은 운영 서버와 다른 위치에 보관
- DB 백업은 압축 전 원본 크기와 복구 시간을 기록
- 주 1회 이상 샘플 복구로 파일 손상 여부 확인
- SSL 인증서 만료일은 서버 내부 알림과 외부 알림을 같이 사용
이전 작업은 DNS보다 데이터 동기화가 먼저입니다
서버 이전을 할 때 가장 많이 놓치는 부분이 데이터 변경 시점입니다. 파일만 복사하고 DNS를 바꾸면 끝이라고 생각하기 쉬운데, 게시판이나 쇼핑몰은 이전 중에도 DB가 계속 바뀝니다. 저는 보통 새 서버를 먼저 구성하고, 테스트 도메인이나 hosts 설정으로 화면을 확인한 뒤, 최종 DB 덤프를 한 번 더 가져옵니다.
DNS TTL은 이전 하루 전쯤 낮춰두면 좋습니다. 기존 값이 3600초라면 300초 정도로 줄여 전환 지연을 줄일 수 있습니다. 단, 이미 높은 TTL로 배포된 상태라면 바로 줄인다고 즉시 반영되지는 않습니다. 그래서 서버 이전은 전날 준비가 절반입니다.
SSL도 같이 봐야 합니다. 새 서버에서 인증서가 발급되지 않았는데 DNS만 넘기면 브라우저 경고가 뜹니다. 인증 방식이 파일 업로드인지, DNS 레코드 방식인지에 따라 순서가 달라집니다. 클라우드 로드밸런서를 쓰는 경우 인증서가 서버 안이 아니라 로드밸런서 쪽에 붙는지도 확인해야 합니다.
장애가 나면 순서대로 봐야 시간이 줄어듭니다
서버 장애 때 가장 위험한 건 이것저것 동시에 만지는 겁니다. 먼저 접속 자체가 안 되는지, 접속은 되는데 느린지, 특정 기능만 안 되는지를 나눕니다. 그다음 CPU, 메모리, 디스크, 네트워크, 웹서버 로그, DB 로그 순서로 확인합니다. 디스크가 100% 찬 상태에서 웹서버 설정만 계속 고치면 시간만 갑니다.
- 1단계: 도메인 해석이 정상인지 확인
- 2단계: 서버 포트가 열려 있는지 확인
- 3단계: 웹서버와 DB 프로세스 상태 확인
- 4단계: 최근 배포, 인증서 갱신, 백업 작업 이력 확인
- 5단계: 에러 로그의 첫 발생 시각을 기준으로 원인 좁히기
운영비를 줄이고 싶다면 싼 서버를 고르는 것보다 필요 없는 불확실성을 줄이는 쪽이 낫습니다. 작은 사이트는 작은 사양으로도 충분합니다. 대신 백업 위치, 복구 절차, SSL 갱신, 모니터링 알림은 비용과 상관없이 챙겨야 합니다. 서버는 비싼 장비보다 반복 가능한 운영 습관에서 더 오래 버팁니다.
