서버가 느리다고 바로 증설하면 돈부터 샙니다
얼마 전 작은 쇼핑몰 서버를 봤는데, 월 방문자 3만 명 정도인데도 8코어 VPS를 쓰고 있었습니다. 그런데 실제로는 CPU 사용률이 평소 5% 안팎이고, 장애 원인은 디스크 용량 부족이었습니다. 서버 비용을 올려서 해결할 문제가 아니었던 겁니다.
서버를 고를 때 제일 흔한 실수는 트래픽 숫자만 보고 겁을 먹는 겁니다. 월 방문자 10만 명이라고 해도 하루로 나누면 3천 명 조금 넘습니다. 시간대가 몰린다고 해도 동시접속이 20명인지 200명인지에 따라 필요한 사양은 완전히 달라집니다. 운영자는 방문자 수보다 동시접속, 페이지 생성 방식, DB 부하, 이미지 용량을 먼저 봐야 합니다.
저는 새 사이트나 이전 작업을 할 때 보통 이렇게 봅니다. 정적 페이지 위주인지, 워드프레스처럼 PHP와 DB가 계속 도는지, 로그인 사용자가 많은지, 파일 다운로드가 있는지부터 나눕니다. 같은 월 100GB 트래픽이라도 이미지 CDN으로 빠지는 사이트와 매 요청마다 DB 쿼리가 80개씩 도는 사이트는 전혀 다른 서버입니다.
처음 서버 사양은 동시접속 기준으로 잡는 게 맞습니다
초기 블로그나 회사 소개 사이트라면 공유 웹호스팅이나 1코어 1GB VPS로도 충분한 경우가 많습니다. 하루 방문자 1천 명 이하, 동시접속 5명 이하, 이미지가 과하지 않은 워드프레스라면 비싼 클라우드 서버부터 갈 이유가 별로 없습니다. 오히려 백업, SSL 갱신, PHP 버전 관리가 더 중요합니다.
워드프레스 기준으로 보면 대략 이런 식으로 잡을 수 있습니다. 플러그인이 적고 캐시가 잘 켜져 있으면 1코어 1GB에서도 꽤 버팁니다. 다만 관리자 화면이 느릴 수 있고, 이미지 리사이즈나 백업 압축이 겹치면 순간적으로 메모리가 부족할 수 있습니다. 그래서 운영 중인 사이트라면 1코어 2GB 또는 2코어 2GB가 체감상 편합니다.
- 개인 블로그, 소개 페이지: 공유호스팅 또는 1코어 1GB
- 소규모 워드프레스, 일 방문자 1천~5천 명: 1코어 2GB 또는 2코어 2GB
- 쇼핑몰, 예약, 회원 기능이 있는 사이트: 2코어 4GB부터 검토
- 이미지·파일 다운로드가 많은 사이트: 서버 CPU보다 트래픽 과금과 스토리지 I/O 확인
- 순간 유입이 잦은 콘텐츠 사이트: 캐시, CDN, 웹서버 설정을 먼저 점검
근데 숫자는 어디까지나 출발점입니다. 서버가 nginx인지 Apache인지, PHP-FPM 설정이 맞는지, DB가 같은 서버에 있는지에 따라 결과가 달라집니다. 2코어 4GB인데도 느린 사이트가 있고, 1코어 1GB인데도 조용히 잘 도는 사이트가 있습니다. 차이는 대개 설정에서 납니다.
서버 비용보다 먼저 봐야 할 설정들
서버 장애의 상당수는 트래픽 폭증보다 기본 설정에서 터집니다. 디스크가 꽉 차서 DB가 멈추고, 로그 파일이 30GB까지 커지고, 자동 백업이 같은 디스크에 쌓여서 복구할 공간이 없어집니다. 이런 경우 서버를 한 단계 올려도 며칠 뒤 같은 문제가 다시 납니다.
운영 전에 최소한 디스크 사용률, 메모리 사용률, 스왑 여부, 웹서버 에러 로그, DB 슬로우 쿼리 정도는 볼 수 있어야 합니다. 어려운 모니터링 도구가 없어도 됩니다. 작은 서버라면 기본 명령어와 호스팅 패널 통계만으로도 사고 징후는 꽤 보입니다.
디스크는 70%부터 관리 대상으로 봅니다
디스크 사용률이 90%를 넘은 뒤에 움직이면 늦습니다. 특히 MySQL이나 MariaDB는 디스크가 꽉 차면 단순히 파일 업로드만 실패하는 게 아니라 테이블 쓰기 작업이 꼬일 수 있습니다. 저는 운영 서버는 70%부터 원인을 보고, 80%가 넘으면 로그 순환과 백업 보관 기간을 바로 조정합니다.
메모리는 평균보다 피크를 봐야 합니다
평균 메모리 사용률이 낮아도 새벽 백업, 이미지 변환, 검색엔진 크롤러 유입이 겹치면 서버가 버벅일 수 있습니다. PHP-FPM 프로세스 수를 너무 크게 잡아두면 동시 요청이 늘 때 메모리를 한 번에 먹습니다. 반대로 너무 작게 잡으면 대기열이 생깁니다. 작은 서버에서는 이 값 하나로 체감 속도가 크게 달라집니다.
SSL과 도메인 갱신도 장애 원인입니다
기술적으로 서버는 멀쩡한데 사이트가 죽은 것처럼 보이는 일이 있습니다. SSL 인증서가 만료됐거나 도메인 네임서버가 잘못 바뀐 경우입니다. 특히 업체 이전할 때 DNS TTL을 낮추지 않고 바로 옮기면 일부 사용자는 새 서버로 가고 일부는 옛 서버로 갑니다. 이 상태에서 주문이나 게시글이 들어가면 데이터가 갈라집니다.
이전과 백업은 서버 선택보다 더 중요합니다
서버 이전을 할 때는 새 서버 사양보다 절차가 먼저입니다. 파일을 복사하고 DB를 덤프한 뒤, 새 서버에서 PHP 버전과 확장 모듈을 맞추고, 임시 도메인이나 hosts 설정으로 먼저 확인합니다. 그다음 DNS를 바꾸는 순서가 안정적입니다. 그냥 백업 파일 하나 올리고 네임서버부터 바꾸면 장애 시간을 직접 만드는 셈입니다.
백업도 같은 서버 안에만 있으면 백업이라고 부르기 애매합니다. 디스크 장애나 계정 정지, 랜섬웨어성 감염이 생기면 원본과 백업이 같이 날아갑니다. 최소한 DB 백업은 외부 저장소나 다른 계정으로 빠져야 합니다. 작은 블로그라도 주 1회 파일 백업, 매일 DB 백업 정도는 과하지 않습니다.
- 이전 전: 현재 PHP 버전, DB 버전, 디스크 용량, 트래픽 사용량 확인
- 복사 후: 새 서버에서 관리자 로그인, 글쓰기, 이미지 업로드, 결제나 폼 전송 확인
- DNS 변경 전: 기존 서버 데이터 변경을 잠시 막거나 점검 안내 적용
- 변경 후: 양쪽 서버 로그를 함께 보면서 접속 흐름 확인
- 완료 후: 옛 서버는 최소 3~7일 보관 후 해지
사실 서버 이전에서 제일 위험한 순간은 복사가 아니라 해지입니다. 새 서버가 잘 떠 보인다고 바로 옛 서버를 지우면, 누락된 업로드 파일이나 크론 작업을 뒤늦게 발견했을 때 복구가 어렵습니다. 며칠 비용 아끼려다 더 큰 시간을 씁니다.
장애가 났을 때 확인하는 순서
사이트가 안 뜨면 먼저 증상부터 나눠야 합니다. 접속 자체가 안 되는지, 500 오류인지, DB 연결 오류인지, 특정 페이지만 느린지에 따라 봐야 할 곳이 다릅니다. 무작정 서버 재부팅부터 하면 원인을 볼 로그가 사라지거나, 잠깐 살아난 뒤 다시 죽습니다.
제가 현장에서 보는 순서는 단순합니다. 도메인 확인, 서버 응답 확인, 디스크 확인, 메모리 확인, 웹서버 로그 확인, DB 상태 확인입니다. 여기까지 보면 대부분 방향이 나옵니다. 트래픽 문제인지, 코드 문제인지, 인증서 문제인지, 저장공간 문제인지가 갈립니다.
- 브라우저 인증서 경고: SSL 만료 또는 인증서 적용 오류 가능성
- 접속 시간 초과: 서버 다운, 방화벽, DNS, 네트워크 문제 가능성
- 500 오류: PHP 오류, 권한 문제, 웹서버 설정 문제 가능성
- DB 연결 오류: DB 서비스 중지, 비밀번호 변경, 디스크 부족 가능성
- 특정 시간대만 느림: 백업, 크론, 크롤러, 피크 트래픽 확인
서버는 비싼 요금제를 쓴다고 자동으로 안정해지지 않습니다. 작은 서버라도 캐시가 맞고, 백업이 밖으로 빠지고, 로그와 디스크가 관리되면 오래 버팁니다. 반대로 큰 서버라도 백업을 같은 디스크에 쌓고, DB 설정을 기본값 그대로 두고, 갱신 일정을 아무도 안 보면 언젠가 멈춥니다. 저는 서버를 고를 때 사양표보다 운영 습관을 먼저 봅니다. 그게 실제 비용과 장애 시간을 더 많이 줄여줍니다.
