모두
모두콘텐츠
처음 홈페이지 만들 때 제일 많이 틀리는 지점
얼마 전 작은 학원 홈페이지 이전을 봐준 적이 있습니다. 월 방문자가 3천 명 정도였고, 상담 신청 폼과 공지 게시판이 전부였습니다. 그런데 기존 견적은 고사양 VPS에 별도 관리형 방화벽, 유료 백업 옵션까지 붙어 있었습니다. 실제로는 저가 웹호스팅이나 작은 VPS로도 충분한 구간이었죠.
홈페이지 서버를 고를 때 먼저 봐야 하는 건 브랜드나 요금제 이름이 아닙니다. 하루 방문자 수, 피크 시간대 동시접속, 페이지 용량, 관리자 작업 빈도입니다. 이 네 가지를 대충이라도 잡으면 과한 서버를 피할 수 있습니다.
예를 들어 회사 소개형 홈페이지라면 방문자 1명이 한 번에 3~5페이지를 보고 나가는 경우가 많습니다. 이미지가 최적화되어 있고 캐시가 잘 걸려 있다면 월 방문자 1만 명 수준도 일반 웹호스팅으로 버티는 일이 많습니다. 반대로 방문자는 적어도 예약, 결제, 파일 업로드, 회원 로그인 기능이 많으면 서버 부담이 빨리 올라갑니다.
방문자 수보다 동시접속을 먼저 계산하는 방법
많은 분들이 월 방문자 수만 보고 서버를 고릅니다. 그런데 서버가 힘들어지는 순간은 한 달 전체가 아니라 특정 5분입니다. 광고를 태웠거나, 문자 발송을 했거나, 신제품 공지를 올린 직후처럼 짧은 시간에 몰릴 때 문제가 납니다.
대략적인 계산은 이렇게 잡으면 됩니다. 하루 방문자 1천 명이고, 그중 30%가 점심시간 2시간에 몰린다고 해보겠습니다. 2시간 동안 300명이 들어오고, 한 명이 평균 2분 머문다면 동시접속은 평균 5명 정도입니다. 여기에 순간 피크를 3배로 잡아도 15명 안팎입니다. 이 정도면 잘 만든 정적 홈페이지나 가벼운 CMS는 낮은 사양으로도 충분합니다.
- 회사 소개형 홈페이지: 동시접속 5~20명은 일반 웹호스팅으로 시작 가능
- 블로그형 홈페이지: 캐시 적용 시 방문자 수 대비 서버 부담이 낮음
- 쇼핑몰형 홈페이지: 장바구니, 결제, 회원 기능 때문에 같은 방문자라도 부담 증가
- 예약형 홈페이지: 특정 시간대 접속이 몰리면 CPU보다 DB 병목이 먼저 올 수 있음
근데 여기서 이미지가 큽니다. 메인에 5MB짜리 배너 이미지를 여러 장 올려놓으면 서버보다 네트워크 전송량이 먼저 아깝습니다. 홈페이지가 느릴 때 서버를 키우기 전에 이미지 압축, 캐시, 불필요한 플러그인 제거부터 보는 게 맞습니다.
웹호스팅, VPS, 클라우드 서버를 나누는 기준
저는 처음 홈페이지를 올릴 때 무조건 클라우드 서버부터 권하지 않습니다. 서버를 직접 운영할 사람이 없고, 트래픽도 작고, 기능도 단순하다면 웹호스팅이 더 낫습니다. 운영체제 업데이트, 웹서버 설정, PHP 버전, 기본 보안 설정을 업체가 어느 정도 잡아주기 때문입니다.
VPS는 자유도가 올라가는 대신 책임도 같이 올라갑니다. 웹서버 설정을 잘못 만지면 사이트가 바로 죽습니다. 백업 스크립트를 안 걸어두면 장애 때 복구할 파일이 없습니다. 클라우드 서버도 마찬가지입니다. 이름은 그럴듯하지만 결국 리눅스 서버 한 대를 직접 돌리는 구조라면 운영 부담은 VPS와 크게 다르지 않습니다.
- 웹호스팅: 단순 홈페이지, 소규모 블로그, 회사 소개 사이트에 적합
- VPS: 특정 버전의 런타임, 직접 설정, 여러 사이트 운영이 필요할 때 적합
- 클라우드 서버: 증설, 로드밸런싱, 스냅샷, 사설망 구성이 필요할 때 적합
- 관리형 서비스: 서버 담당자가 없고 장애 대응 시간을 줄여야 할 때 검토
사실 월 1만~3만 원대 웹호스팅으로 충분한 홈페이지가 꽤 많습니다. 월 방문자 수가 몇만 명이어도 정적 페이지 비중이 높고 캐시가 잘 잡혀 있으면 버팁니다. 반대로 관리자 페이지에서 엑셀 업로드를 자주 하거나, 상품 수가 많거나, 검색 기능이 무겁다면 작은 VPS라도 금방 답답해집니다.
홈페이지 서버 사양은 이렇게 잡으면 현실적입니다
초기 사양을 잡을 때는 크게 CPU, 메모리, 저장공간, 트래픽을 봅니다. 작은 홈페이지라면 CPU 1~2코어, 메모리 1~2GB VPS로도 시작할 수 있습니다. 워드프레스처럼 PHP와 DB를 같이 쓰는 구조라면 메모리 2GB가 체감상 더 편합니다. 플러그인이 많고 관리자 작업이 잦다면 4GB부터 보는 편이 낫습니다.
저장공간은 의외로 홈페이지 파일보다 백업과 이미지가 잡아먹습니다. 페이지 파일만 보면 1GB도 안 되는 사이트가 많지만, 원본 이미지와 업로드 파일, DB 백업을 쌓아두면 20GB가 금방 찹니다. 그래서 저장공간은 현재 사용량의 3배 이상으로 잡고, 백업은 같은 서버 안에만 두지 않는 게 좋습니다.
- 소형 소개 홈페이지: 웹호스팅 또는 CPU 1코어, 메모리 1GB 수준
- 워드프레스 블로그: CPU 1~2코어, 메모리 2GB 권장
- 소규모 쇼핑몰: CPU 2코어, 메모리 4GB부터 검토
- 광고 유입이 잦은 사이트: 캐시와 CDN 적용 여부를 사양보다 먼저 확인
트래픽은 페이지 용량으로 계산합니다. 한 페이지가 이미지 포함 3MB이고 하루 1천 명이 4페이지씩 본다면 하루 전송량은 약 12GB입니다. 한 달이면 360GB 정도입니다. 여기에 검색봇, 관리자 접속, 이미지 재요청까지 더하면 여유를 둬야 합니다. 홈페이지 이미지 최적화만 해도 월 트래픽 비용이 줄어드는 경우가 흔합니다.
이전과 백업은 서버 선택보다 먼저 봐야 합니다
사이트 장애를 많이 봐왔지만, 진짜 무서운 건 서버 다운보다 백업 없음입니다. 서버가 죽어도 백업이 있으면 복구 시간을 계산할 수 있습니다. 그런데 백업이 없거나, 백업 파일이 깨져 있거나, DB만 있고 업로드 파일이 없으면 그때부터는 복구가 아니라 수습입니다.
홈페이지를 이전할 때는 파일, DB, 도메인 DNS, SSL 인증서, 메일 사용 여부를 따로 확인해야 합니다. 특히 도메인만 옮기면 된다고 생각하다가 메일 수신이 끊기는 일이 많습니다. 회사 대표 메일을 같은 도메인으로 쓰고 있다면 DNS 레코드를 건드리기 전에 현재 값을 반드시 기록해야 합니다.
- 이전 전: 파일 전체와 DB를 각각 백업
- 이전 중: 새 서버에서 임시 주소나 hosts 설정으로 화면 확인
- 전환 시: DNS TTL을 낮춰 전파 시간을 줄임
- 전환 후: SSL, 로그인, 폼 발송, 메일 수신, 이미지 경로 확인
백업 주기도 사이트 성격에 따라 달라야 합니다. 한 달에 한 번 글을 올리는 홈페이지라면 일 1회 백업도 충분할 수 있습니다. 주문이나 예약이 들어오는 사이트라면 DB 백업 간격을 더 짧게 잡아야 합니다. 백업은 만들어지는 것보다 복구되는지가 중요합니다. 최소 한 번은 테스트 서버나 임시 폴더에 풀어봐야 합니다.
장애가 났을 때 바로 확인할 순서
홈페이지가 안 열린다는 연락을 받으면 먼저 서버를 키우고 볼 일이 아닙니다. 순서가 있습니다. 도메인 만료, DNS 변경, SSL 만료, 웹서버 중지, DB 연결 실패, 디스크 가득 참, 권한 오류를 차례대로 봐야 합니다. 체감상 초보 운영에서 가장 자주 보는 건 디스크 용량 100%와 인증서 만료입니다.
디스크가 가득 차면 DB가 쓰기를 못 하고, 세션 파일이 생성되지 않고, 관리자 로그인이 실패합니다. 화면에는 단순히 500 오류만 보일 때가 많습니다. 그래서 모니터링은 CPU 사용률만 보면 부족합니다. 디스크 사용량, 메모리 사용량, 웹서버 상태, DB 상태, 백업 성공 여부까지 같이 봐야 합니다.
홈페이지 운영은 큰 서버를 사는 게임이 아닙니다. 필요한 만큼 작게 시작하고, 병목이 확인될 때 늘리는 쪽이 비용도 낮고 장애 원인도 선명합니다. 제 경험상 오래 버티는 사이트는 사양이 화려한 곳보다 백업이 검증되어 있고, DNS 기록이 남아 있고, 누가 봐도 이해되는 설정으로 운영되는 곳이었습니다. 서버는 커질 수 있지만, 운영 습관은 처음부터 작게라도 제대로 잡아두는 편이 훨씬 낫습니다.
