처음에는 트래픽보다 구조를 봅니다
얼마 전 작은 회사 홈페이지 이전을 봤는데, 월 방문자가 3만 명도 안 되는데 클라우드 서버 3대를 쓰고 있었습니다. 느린 이유는 서버가 부족해서가 아니라 이미지 원본을 그대로 올리고, 백업 작업이 낮 시간에 돌고, 캐시 설정이 꺼져 있었기 때문입니다.
홈페이지 서버를 고를 때 먼저 봐야 할 것은 월 방문자 수 하나가 아닙니다. 페이지 크기, 동시 접속, 관리자 사용 빈도, 파일 업로드 여부, 검색 봇 유입, 백업 방식까지 같이 봐야 합니다. 트래픽 숫자만 보고 요금제를 올리면 비용은 빨리 늘고 문제는 그대로 남습니다.
일반적인 회사 소개형 홈페이지라면 페이지당 2MB 이하, 하루 방문자 1천 명 이하, 동시에 접속하는 사람이 10명 안쪽인 경우가 많습니다. 이 정도는 보통 저가 웹호스팅이나 작은 VPS로 충분합니다. PHP 기반 CMS와 데이터베이스를 같이 써도, 캐시만 제대로 켜면 CPU 1코어와 메모리 1GB급에서도 버티는 구간이 꽤 깁니다.
사양은 동시접속 기준으로 잡는 게 맞습니다
월 방문자 10만 명이라는 말은 커 보이지만, 실제로는 하루 평균 3천 명 정도입니다. 업무 시간 10시간에 몰린다고 쳐도 시간당 300명, 분당 5명입니다. 페이지 체류와 새로고침을 감안해도 동시접속 20명 안쪽이면 끝나는 경우가 많습니다.
회사 소개형 홈페이지
- 하루 방문자 500명 이하: 저가 웹호스팅 또는 관리형 호스팅
- 하루 방문자 3천 명 이하: 캐시 적용된 웹호스팅, 또는 1코어 1~2GB VPS
- 동시접속 30명 이하: 정적 캐시와 이미지 압축만으로도 체감 속도 개선 가능
이 구간에서는 서버를 키우기 전에 이미지 용량부터 줄이는 게 효과가 큽니다. 메인 배너 하나가 6MB이면 서버 사양을 올려도 첫 화면은 여전히 느립니다. 이미지 포맷을 바꾸고, 브라우저 캐시를 잡고, 필요 없는 플러그인을 걷어내면 월 5천 원대 호스팅에서도 충분한 사례가 많습니다.
예약, 게시판, 로그인 기능이 있는 홈페이지
- 로그인 사용자가 많으면 데이터베이스 부하를 따로 봐야 함
- 게시판 첨부파일이 많으면 디스크 용량보다 백업 시간이 먼저 문제가 됨
- 예약 피크가 특정 시간에 몰리면 평균 방문자 수는 큰 의미가 없음
예약 오픈 시간처럼 5분 안에 접속이 몰리는 서비스는 작은 홈페이지라도 서버 선택이 달라집니다. 이때는 월 트래픽보다 순간 요청 수가 중요합니다. 반대로 하루 종일 조금씩 들어오는 블로그형 홈페이지는 월 방문자가 많아 보여도 CDN과 캐시로 오래 버틸 수 있습니다.
웹호스팅, VPS, 클라우드 서버 선택 기준
웹호스팅은 싸고 편합니다. 서버 보안 패치, 기본 백업, 웹서버 설정을 업체가 많이 처리합니다. 대신 세부 설정을 마음대로 바꾸기 어렵고, 같은 장비를 여러 사용자가 나눠 쓰는 구조라 피크 시간 성능 편차가 있습니다. 그래도 단순 홈페이지라면 가장 합리적인 선택인 경우가 많습니다.
VPS는 자유도가 높습니다. Nginx, Apache, PHP 버전, 데이터베이스 설정을 직접 잡을 수 있습니다. 비용도 낮게 시작할 수 있습니다. 다만 운영자가 로그를 보고, 보안 업데이트를 하고, 백업 복구 테스트를 해야 합니다. 서버를 모르면 VPS가 더 싸 보이다가 장애 한 번에 더 비싸지는 일이 생깁니다.
클라우드 서버는 확장성과 부가 기능이 장점입니다. 스냅샷, 로드밸런서, 오브젝트 스토리지, 방화벽 정책을 잘 쓰면 운영이 안정됩니다. 그런데 작은 홈페이지에 처음부터 클라우드 기능을 다 붙이면 요금 구조가 복잡해집니다. 트래픽 전송량, 디스크, 백업 보관, 고정 IP 같은 항목이 따로 붙는 경우가 많습니다.
- 명함형 홈페이지: 웹호스팅 우선
- 워드프레스에 글이 많고 플러그인이 많은 경우: 관리형 호스팅 또는 작은 VPS
- 예약, 결제, 회원 기능이 있는 경우: VPS 이상에서 로그와 백업을 직접 관리
- 트래픽 피크가 예측되는 캠페인 사이트: CDN과 임시 증설 가능한 구조
도메인, SSL, 백업에서 사고가 많이 납니다
제가 본 장애 중에는 서버 다운보다 도메인 만료, DNS 오입력, SSL 인증서 만료가 훨씬 허탈한 경우가 많았습니다. 서버는 멀쩡한데 홈페이지가 안 열린다고 전화가 옵니다. 들어가 보면 도메인 갱신 결제가 실패했거나, 이전하면서 네임서버를 잘못 바꾼 상황입니다.
도메인은 자동 갱신만 믿지 말고 결제 카드 만료일을 같이 봐야 합니다. SSL은 무료 인증서를 써도 괜찮습니다. 중요한 건 자동 갱신이 실제로 되는지입니다. 인증서가 90일짜리라면 60일쯤에 갱신되는 구조인지 확인해야 합니다. 갱신 스크립트가 있어도 방화벽이나 권한 문제로 실패하는 경우가 있습니다.
백업은 보관보다 복구가 중요합니다. 백업 파일이 매일 만들어져도 복구가 안 되면 의미가 없습니다. 최소한 월 1회는 다른 경로에 내려받아 압축이 풀리는지, 데이터베이스가 정상으로 들어가는지 확인해야 합니다. 홈페이지 파일과 데이터베이스 백업 시점이 다르면 게시글이나 주문 정보가 어긋날 수 있습니다.
- 파일 백업: 이미지, 첨부파일, 테마, 업로드 폴더 포함
- DB 백업: 게시글, 회원, 주문, 설정값 포함
- 외부 보관: 같은 서버 안에만 두지 않기
- 복구 테스트: 새 폴더나 임시 서버에 실제로 올려보기
장애가 났을 때 제가 보는 순서
홈페이지가 안 열린다고 하면 저는 서버 재부팅부터 하지 않습니다. 먼저 범위를 나눕니다. 내 PC에서만 안 되는지, 모바일 데이터에서도 안 되는지, 관리자 페이지는 되는지, 정적 파일은 열리는지부터 봅니다. 이 순서를 건너뛰면 원인과 상관없는 작업을 하게 됩니다.
- 도메인 만료와 DNS 변경 여부 확인
- SSL 인증서 기간과 갱신 상태 확인
- 웹서버 프로세스와 포트 응답 확인
- 디스크 사용량과 inode 부족 확인
- 데이터베이스 접속 가능 여부 확인
- 최근 플러그인, 테마, 배포 변경 이력 확인
- 접속 로그와 오류 로그에서 시간대별 패턴 확인
디스크가 100% 찬 상태에서는 데이터베이스가 멈추고 세션 파일도 못 써서 로그인이 안 됩니다. 트래픽 폭증처럼 보여도 실제로는 백업 파일이 서버 안에 계속 쌓인 경우가 많습니다. 로그 파일 하나가 수십 GB로 커져서 장애를 만든 적도 여러 번 봤습니다.
홈페이지 운영은 큰 서버를 사는 일이 아니라 작은 위험을 줄이는 일에 가깝습니다. 방문자가 적은 구간에서는 싼 요금제가 부끄러운 선택이 아닙니다. 대신 백업 위치, SSL 갱신, 도메인 만료, 이미지 용량, 캐시 설정은 꼭 챙겨야 합니다. 서버 사양은 그다음입니다. 운영을 오래 해보면 돈을 더 쓰는 것보다 확인할 것을 빠뜨리지 않는 쪽이 훨씬 강합니다.
