여행사홈페이지제작 서버 사양부터 잡는 방법

얼마 전 여행사 사이트 이전을 도왔는데, 서버 용량보다 예약 문의 메일이 빠진 게 더 큰 문제였다. 기존 업체가 보관하던 메일 설정을 옮기지 않은 채 서버만 바꾼 탓이었다. 여행사홈페이지제작을 준비할 때도 비슷하다. 먼저 상품을 어떻게 보여주고, 고객 문의를 어디서 받고, 장애가 나면 무엇을 복구해야 하는지부터 적어야 필요한 서버가 보인다.

예약 기능의 범위부터 정한다

여행 상품을 소개하고 전화나 문의 양식으로 상담을 받는 사이트라면 구조가 단순하다. 상품 목록, 상세 페이지, 검색, 문의 접수 정도가 주된 기능이다. 반면 날짜별 잔여 좌석을 보여주고 결제까지 받는다면 재고와 예약 상태를 맞추는 작업이 추가된다. 화면이 비슷해 보여도 운영 난도는 꽤 다르다.

특히 예약 버튼의 의미를 명확히 해야 한다. 버튼을 눌렀을 때 상담 요청만 남는지, 좌석이 실제로 확보되는지, 결제가 끝나야 확정되는지에 따라 데이터 구조와 장애 대응이 달라진다. 좌석이 한 자리 남았을 때 두 사람이 동시에 신청하는 상황도 생각해야 한다. 재고를 실시간으로 관리할 준비가 없다면 처음부터 ‘예약 확정’이라고 표시하지 않는 편이 안전하다.

상품 정보도 운영자가 직접 수정할 수 있어야 한다. 출발일, 포함 사항, 취소 조건이 바뀔 때마다 개발자에게 수정을 맡기면 오래된 정보가 남기 쉽다. 대신 관리자 계정은 사람별로 나누고 권한을 필요한 범위로 제한한다. 퇴사자 계정을 바로 끊을 수 있는 구조가 실제 운영에서는 화려한 관리자 화면보다 중요하다.

방문자 수를 동시 요청으로 바꿔 계산한다

하루 방문자 3천 명이라는 숫자만으로 비싼 클라우드 서버를 고를 이유는 없다. 예를 들어 방문자의 20%가 가장 바쁜 한 시간에 몰리고, 한 방문자가 서버 처리가 필요한 요청을 네 번 보낸다면 시간당 요청은 2,400건이다. 초당 평균 약 0.7건이고, 순간적으로 다섯 배 몰려도 초당 3~4건 수준이다. 이미지를 별도 저장소에서 제공하고 페이지를 캐시한다면 작은 구성으로도 감당할 여지가 있다.

이 수치는 출발점일 뿐이다. 검색 조건이 복잡하거나 외부 예약 시스템 응답을 기다리는 페이지는 같은 방문자 수에서도 느려질 수 있다. 반대로 상품 소개 중심의 사이트는 공유 웹호스팅으로 충분한 구간이 길다. 처음에는 월 방문 수, 가장 바쁜 시간대의 요청 수, 페이지 응답 시간, 메모리 사용량을 측정할 수 있는 상품을 고르는 편이 낫다. 사용량을 확인한 뒤 서버를 올려도 늦지 않다.

직접 운영하는 VPS가 필요하다면 소규모 사이트는 가상 CPU 2개와 메모리 2~4GB 정도에서 부하를 확인해 볼 수 있다. 다만 이 수치는 예약 처리와 이미지 보관 방식에 따라 달라진다. 서버 비용만 비교해서는 안 된다. 운영체제 업데이트, 데이터베이스 관리, 장애 알림까지 직접 맡을 사람이 없다면 관리형 호스팅이 총비용 면에서 나을 수 있다.

이전 전에는 문의와 백업을 먼저 점검한다

사이트 이전 때 자주 빠지는 것은 눈에 보이지 않는 연결이다. 문의 양식이 보낸 메일, 예약 알림을 받는 담당자 주소, 검색 엔진에 등록된 기존 페이지 경로, SSL 인증서 갱신 방식까지 목록으로 적는다. 화면을 옮긴 뒤 실제 고객처럼 문의를 한 건 보내 보고, 관리자 알림과 고객 확인 메시지가 각각 도착하는지 확인해야 한다.

백업은 파일과 데이터베이스를 함께 보관한다. 상품 사진만 살아 있고 예약 기록이 없으면 복구가 끝난 게 아니다. 하루 한 번 백업하더라도 복구 직전 하루치 문의가 사라질 수 있으니, 문의·예약 데이터의 허용 손실 시간을 먼저 정한다. 접수가 잦다면 더 짧은 간격의 데이터베이스 백업이나 별도 접수 기록이 필요하다. 백업 파일은 운영 서버와 분리해 두고, 분기마다 한 번은 임시 환경에서 실제로 복원해 보는 게 좋다.

서버를 바꾸기 전에는 DNS 설정의 유효 시간을 짧게 조정하고, 새 서버에서 관리자 로그인과 상품 수정까지 시험한다. 전환 직후에는 이전 서버를 바로 없애지 말고 일정 기간 유지한다. 방문자마다 새 서버를 보는 시점이 다를 수 있어서다. 이 기간에 양쪽으로 문의가 나뉘어 들어오지 않는지도 살펴야 한다.

장애가 나면 확인할 순서를 정해 둔다

사이트가 안 열린다는 연락을 받으면 먼저 전체 접속 장애인지, 특정 페이지나 예약 기능만 실패하는지 구분한다. 전체가 안 열리면 도메인 갱신 상태, DNS 응답, 서버 상태, 웹서버 오류 기록, SSL 인증서 만료 순으로 확인한다. 첫 화면은 열리는데 문의만 실패한다면 메일 발송 설정과 외부 서비스 연결 기록을 먼저 본다. 원인을 찾기 전에 서버를 여러 번 재시작하면 오류 기록이 끊겨 판단이 늦어진다.

운영 알림도 사용자 행동을 기준으로 잡는다. 서버가 켜져 있다는 알림만으로는 문의 양식 고장을 알 수 없다. 첫 화면 접속과 함께 예약 또는 문의의 핵심 단계를 주기적으로 시험하고, 실패했을 때 담당자에게 알려야 한다. 고객 정보가 들어 있는 오류 기록은 접근 권한과 보관 기간도 제한한다.

여행사 사이트는 성수기 광고를 시작한 뒤에야 문제가 드러나는 경우가 많다. 그래서 저는 처음부터 큰 서버를 사기보다 문의 한 건이 접수되고 보관되고 복구되는 흐름을 먼저 확인한다. 그 흐름이 안정적이면 실제 사용량에 맞춰 사양을 올리는 일은 훨씬 쉽다.