모두
모두콘텐츠
얼마 전 기업 홈페이지를 새로 만들면서 월 방문자 1만 명을 예상한다는 이유로 꽤 큰 서버를 권하는 견적을 봤다. 방문자 수만으로 서버를 고르면 이런 일이 생긴다. 같은 1만 명이라도 회사 소개 페이지만 보는 사이트와 파일을 내려받고 견적을 접수하는 사이트의 부담은 다르다. 기업홈페이지제작을 시작할 때는 디자인 견적과 함께 페이지 용량, 접수 기능, 운영 절차를 적어두는 편이 좋다.
방문자 수보다 페이지 용량과 접속 패턴을 먼저 본다
서버 사양을 계산하려면 한 달 방문자 수, 방문자당 페이지 조회 수, 페이지당 전송량이 필요하다. 월 방문자 1만 명이 평균 3페이지를 보고, 페이지를 열 때마다 평균 1MB를 전송한다면 단순 계산으로 월 30GB다. 여기에 이미지 재요청, 검색 로봇, 파일 다운로드를 더해 여유를 잡는다. 이 수치는 출발점일 뿐이다. 이미지가 많은 회사 소개 페이지가 4MB라면 같은 방문자 수에서도 전송량은 월 120GB로 뛴다.
여기서 페이지 용량은 서버가 전송하는 실제 양으로 확인해야 한다. 원본 사진이 5MB여도 화면에 맞는 크기로 줄이고 브라우저 캐시를 적용하면 반복 방문 때 전송량이 달라진다. 반대로 제품 설명서를 한 번에 수십 MB씩 내려받게 하면 일반 페이지를 아무리 가볍게 만들어도 월 전송량은 늘어난다. 견적서에 적힌 저장 공간보다 월 전송량과 초과 요금 조건을 먼저 읽는 이유다.
동시접속도 별도로 봐야 한다. 평소에는 조용한 사이트라도 채용 공고가 올라오거나 홍보 문자가 발송되면 몇 분 동안 접속이 몰린다. 관리자에게 최근 캠페인이나 채용 때의 접속 기록이 있다면 그 시간대의 초당 요청 수와 응답 시간을 확인한다. 기록이 없다면 개설 후 첫 행사에서 측정할 계획을 세우면 된다. 막연히 월 방문자 수에 맞춰 CPU와 메모리를 올리는 것보다 정확하다.
웹호스팅으로 충분한 구간을 구분한다
회사 소개, 공지, 문의 접수가 중심이고 특별한 서버 프로그램이 없다면 일반 웹호스팅부터 검토할 만하다. 운영체제 패치와 웹서버 관리 범위가 정해져 있어 작은 조직이 관리하기 쉽다. 다만 상품마다 실행 환경, 데이터베이스 용량, 파일 업로드 제한, 백업 제공 범위가 다르다. 월 전송량이 맞아도 필요한 프로그램 버전이나 예약 작업을 쓸 수 없다면 적합하지 않다.
VPS는 서버 설정을 직접 바꾸거나 여러 서비스를 함께 운영할 때 의미가 있다. 대신 보안 업데이트, 방화벽, 모니터링, 장애 복구를 누가 맡을지 분명해야 한다. 월 몇 만 원 차이보다 야간 장애 때 접속할 사람이 없는 상태가 더 비싸게 돌아온다. 클라우드 서버도 처음부터 큰 사양을 고를 이유는 없다. 작은 구성으로 시작하고 실제 CPU 사용률, 메모리 부족 여부, 응답 시간, 데이터베이스 부하를 본 뒤 늘릴 수 있어야 한다.
견적을 비교할 때는 CPU와 메모리 숫자만 나란히 놓지 않는다. 저장 장치 종류와 용량, 월 전송량, 초과 과금 방식, 백업 보관 기간, 장애 지원 시간을 같은 표에 적어야 한다. 특히 관리형 서비스라는 표현만 보고 백업 복원까지 맡아준다고 생각하면 곤란하다. 제공 범위는 계약 조건에서 확인해야 한다.
도메인과 SSL보다 먼저 소유권을 확인한다
기업홈페이지제작을 외부 업체에 맡길 때 가장 자주 놓치는 부분이 계정 소유권이다. 도메인 등록자, 호스팅 계약자, SSL 인증서 관리 계정이 모두 제작 업체 명의라면 나중에 이전할 때 시간이 걸린다. 회사 명의로 계약하고, 담당자가 바뀌어도 접근할 수 있도록 계정과 복구 수단을 회사가 관리하는 편이 안전하다.
SSL 인증서는 설치 여부만 확인해서 끝나지 않는다. 자동 갱신이 작동하는지, 만료 알림이 누구에게 가는지, 갱신 후 실제 페이지가 정상으로 열리는지 확인해야 한다. 문의 양식에 이름과 연락처를 받는다면 전송 구간 보호는 기본이고, 접수 내용이 관리자 메일이나 데이터베이스에 얼마나 남는지도 정해야 한다. 쓰지 않는 개인정보를 오래 보관할 이유는 없다.
권한도 나눈다. 콘텐츠 담당자에게 서버 전체 관리 권한을 줄 필요는 없다. 게시물 수정 계정, 호스팅 관리 계정, 도메인 관리 계정의 역할을 구분하고 퇴사나 업체 변경 시 바로 회수할 수 있어야 한다. 비밀번호를 여러 사람이 공유하는 방식은 담당자가 늘어날수록 사고 원인을 찾기 어렵게 만든다.
이전 일정에는 백업 복원 시간을 넣는다
홈페이지 이전은 새 서버에 파일을 올리는 것으로 끝나지 않는다. 기존 사이트의 파일과 데이터베이스를 백업하고, 새 환경에서 문의 접수와 관리자 로그인까지 시험해야 한다. 특히 문의 양식은 화면에 성공 메시지가 떠도 실제 저장이나 메일 발송이 실패할 수 있다. 테스트 접수 한 건을 보내고 받은 기록까지 확인한다.
도메인이 새 서버를 가리키도록 바꾸기 전에는 캐시 시간을 줄일 수 있는지 확인한다. 전환 직후 일부 방문자는 이전 서버에, 일부는 새 서버에 접속할 수 있으므로 일정 기간 두 서버를 함께 유지하는 편이 안전하다. 접수 데이터가 양쪽에 나뉘지 않도록 이전 서버의 입력을 막거나 최종 데이터를 다시 옮기는 절차도 필요하다. 이전 서버를 곧바로 해지하면 이런 차이를 확인할 기회를 잃는다.
백업은 파일이 있다는 사실보다 복원할 수 있다는 사실이 중요하다. 운영 파일과 데이터베이스를 함께 보관하고, 서버와 다른 위치에도 사본을 둔다. 월 한 번 정도는 별도 환경에서 실제로 복원해 관리자 로그인과 주요 페이지를 확인하면 좋다. 장애가 나면 먼저 도메인 연결, 인증서 만료, 서버 응답, 데이터베이스 연결, 최근 배포 순서로 범위를 좁힌다. 이 순서가 있으면 무작정 서버 사양부터 올리는 일을 줄일 수 있다.
제가 기업 홈페이지 서버를 볼 때 가장 먼저 묻는 것은 예상 방문자가 아니라 누가 운영하고, 문제가 생기면 어떤 자료로 되돌릴 수 있는지다. 작은 요금제라도 그 답이 분명하면 안정적으로 운영할 수 있다. 반대로 복원 절차가 없는 큰 서버는 장애 앞에서 별 도움이 되지 않는다.
