
얼마 전 작은 회사 사이트 이전을 도왔는데, 새 홈페이지는 잘 만들어졌어도 도메인 관리 계정과 백업 파일을 아무도 갖고 있지 않았습니다. 제작 업체에 연락이 닿지 않는 주말에 장애가 나면 손쓸 방법이 없는 상태였죠. 홈페이지 제작 업체 추천을 받을 때 디자인 사례부터 보는 분이 많지만, 저는 사이트를 넘겨받은 뒤 누가 무엇을 관리할 수 있는지 먼저 확인합니다.
업체를 찾기 전에 사이트 규모부터 적기
견적을 요청하기 전에 필요한 기능을 한 장으로 적어두면 업체별 제안을 비교하기 쉬워집니다. 회사 소개와 문의 양식만 필요한지, 예약·결제·회원 기능이 필요한지에 따라 개발 범위가 크게 달라집니다. 관리자가 직접 바꿔야 할 문구와 사진이 얼마나 자주 생기는지도 적으세요. 월 한 번 수정하는 사이트와 매일 상품을 올리는 사이트에 같은 관리 화면을 만들 이유는 없습니다.
트래픽은 막연히 ‘방문자가 많을 예정’이라고 쓰기보다 현재 수치와 예상치를 나눠 전달하는 편이 낫습니다. 예를 들어 월 3만 페이지 조회, 페이지당 전송량 2MB라면 단순 계산으로 월 전송량은 약 60GB입니다. 이미지 최적화나 캐시 적용 여부에 따라 실제 사용량은 달라집니다. 이 정도의 소개 사이트에 처음부터 큰 VPS나 복잡한 클라우드 구성을 넣은 견적이라면, 왜 필요한지 설명을 요구할 만합니다.
반대로 예약이 특정 시간에 몰리거나 관리자와 고객이 동시에 데이터를 자주 갱신한다면 월간 조회 수만으로 서버를 정할 수 없습니다. 피크 시간의 동시 요청, 외부 서비스 연동, 장애 시 허용 가능한 중단 시간을 함께 알려줘야 합니다. 제작 범위와 운영 조건이 적혀 있어야 저렴한 견적이 정말 저렴한지도 보입니다.
포트폴리오보다 인수인계 범위를 확인하기
화면이 마음에 드는 업체 두세 곳을 추렸다면 같은 질문을 보내 답을 비교합니다. 도메인 등록자와 관리 계정은 누구 명의인지, 서버와 저장소에 발주자가 접근할 수 있는지, 계약 종료 시 어떤 파일과 자료를 넘겨주는지부터 물어보면 됩니다. ‘관리해드립니다’라는 답만으로는 부족합니다. 계정, 소스코드, 데이터베이스 내보내기 파일, 이미지 원본, 사용한 유료 자료의 이용 조건이 인수인계 목록에 들어가는지 확인해야 합니다.
특히 도메인을 업체 명의로 등록하면 나중에 이전할 때 예상보다 오래 걸릴 수 있습니다. 발주자 명의 계정에서 등록하고 업체에는 필요한 권한만 주는 방식이 관리하기 편합니다. 서버도 마찬가지입니다. 업체가 운영을 맡더라도 요금 청구 주체, 관리자 권한, 계약 해지 후 이전 절차는 계약서에 남겨두는 편이 안전합니다.
포트폴리오를 볼 때는 예쁜 첫 화면 외에 휴대전화에서의 메뉴 사용, 문의 제출 후 동작, 페이지 수정 난이도를 확인합니다. 가능하면 실제 관리 화면 시연을 요청하세요. 담당자가 바뀌어도 글 한 건과 사진 한 장을 직접 고칠 수 있다면 매번 수정 비용을 내지 않아도 됩니다. 다만 예약·결제처럼 오류의 영향이 큰 기능은 누가 수정하고 검수할지 따로 정해야 합니다.
견적서는 제작비와 운영비를 나눠 비교하기
예를 들어 A 업체는 제작비 200만 원에 월 관리비 15만 원, B 업체는 제작비 300만 원에 월 관리비 5만 원을 제시했다고 합시다. 단순 합계는 1년 차에 A가 380만 원, B가 360만 원입니다. 여기서 끝내면 안 됩니다. 관리비에 서버 비용, 보안 업데이트, 백업, 콘텐츠 수정이 각각 얼마나 포함되는지에 따라 실제 비용이 다시 달라집니다. 이 숫자는 비교 방법을 보여주는 예시일 뿐, 적정 시세를 뜻하지는 않습니다.
견적 항목에는 페이지 수만 적지 말고 기능별 산출물과 수정 횟수를 적는 것이 좋습니다. 문의 양식 하나라도 입력 항목, 알림 방식, 스팸 방지, 접수 내역 보관 여부에 따라 일이 달라집니다. 사진과 문구를 누가 제공하는지, 검색 엔진에 노출될 기본 설정을 누가 하는지, 출시 후 발견된 오류는 언제까지 무상으로 고치는지도 확인하세요. ‘유지보수 포함’이라는 한 줄은 해석이 제각각입니다.
작은 소개 사이트라면 템플릿이나 직접 수정할 수 있는 제작 도구가 비용과 운영 면에서 더 나을 수 있습니다. 업체가 필요한 구간은 복잡한 업무 흐름을 구현하거나, 담당자 없이 운영할 수 없어 지속적인 기술 지원이 필요한 경우입니다. 요구사항이 단순한데도 맞춤 개발과 고사양 서버가 기본으로 들어간다면 다른 방식의 견적도 받아보는 게 좋습니다.
백업과 장애 대응을 계약서 문장으로 남기기
운영에서 자주 빠지는 항목이 백업입니다. ‘매일 백업’이라고만 적으면 같은 서버 안에 파일을 복사해두는 것도 백업으로 취급될 수 있습니다. 무엇을 백업하는지, 어디에 보관하는지, 몇 세대를 남기는지, 복구 요청 후 누가 얼마나 빨리 작업하는지까지 적어야 합니다. 데이터베이스를 사용하는 사이트라면 화면 파일만 받아서는 문의 내역이나 예약 정보를 되살릴 수 없습니다.
예를 들어 하루치 접수 내역을 잃어도 되는 사이트와 한 시간치 예약만 사라져도 곤란한 사이트는 백업 주기가 달라야 합니다. ‘언제 시점까지 되돌릴 수 있는가’와 ‘다시 열기까지 얼마나 걸리는가’를 각각 정해 업체에 물어보세요. 실제 복구를 해본 적이 있는지도 중요합니다. 백업 파일이 존재해도 복원 과정에서 설정값이나 외부 연동 정보가 빠져 있으면 서비스는 바로 살아나지 않습니다.
문의나 회원 정보를 다룬다면 개인정보를 누가 볼 수 있는지, 업체가 맡는 작업 범위와 계약 종료 후 자료 처리 방법도 확인해야 합니다. 개인정보 포털 역시 처리 위탁 사항을 개인정보처리방침에 포함해 공개하도록 안내합니다. 사이트를 만든 뒤에 이 문제를 뒤늦게 맞추려면 계정 권한부터 다시 손봐야 할 수 있습니다.
제가 업체를 고를 때 가장 신뢰하는 답은 ‘다 해드립니다’가 아닙니다. 현재 규모에서는 싼 호스팅으로 충분하고, 어느 수준을 넘으면 구성을 바꿔야 하는지 설명하는 답입니다. 그 기준과 함께 계정, 백업, 복구 절차까지 문서로 남겨주는 업체라면 사이트를 오래 운영하기가 훨씬 수월합니다.
