홈페이지 제작이 끝나면 월 유지보수 계약을 검토하게 됩니다. 이때 수정 가능 횟수나 월 비용만 비교하면 실제 운영 과정에서 중요한 공백을 놓칠 수 있습니다. 장애가 발생했을 때 언제 조사를 시작하는지, 백업한 데이터를 실제로 복구할 수 있는지, 보안 업데이트와 외부 플러그인은 누가 관리하는지까지 계약서에서 확인해야 합니다.
유지보수 계약의 핵심은 작업량 자체보다 업무별 책임과 대응 기준을 분명히 정하는 데 있습니다. 계약 전 다음 8가지를 순서대로 점검하면 업체 간 제안의 차이를 더 구체적으로 비교할 수 있습니다.
1. 포함 작업과 제외 작업이 구분되어 있는가
먼저 ‘유지보수’라는 표현을 구체적인 업무 단위로 나눠야 합니다. 콘텐츠 수정뿐 아니라 장애 대응, 보안, 백업, 제3자 제공업체와 관련된 업무까지 각각 누가 담당하는지 확인해야 합니다.
계약서에는 각 업무의 책임 주체, 응답시간, 책임 범위가 명확히 드러나야 합니다. 포함 항목만 나열하기보다 제외되는 작업과 별도 협의가 필요한 작업도 함께 구분해야 계약 이후 해석 차이를 줄일 수 있습니다.
‘월 몇 회 수정’보다 먼저 확인할 것은 업무별 포함·제외 범위입니다.
2. 응답시간과 해결시간을 구분했는가
SLA에서 응답시간과 해결시간은 같은 의미가 아닙니다. 영국 국가사이버보안센터인 NCSC는 응답시간을 요청이 접수된 시점부터 담당자가 조사를 시작할 때까지의 시간으로 설명합니다. 반면 해결시간은 문제를 실제로 처리하는 데 걸리는 기준입니다.
따라서 “빠르게 대응한다”는 문구만으로는 충분하지 않습니다. 장애 심각도별로 조사 시작 기준과 해결 기준이 각각 있는지 확인해야 합니다. NCSC는 긴급 이슈의 경우 1시간 미만 응답을 일반적인 기준으로 제시하지만, 더 빠른 응답 조건은 계약비용에 영향을 줄 수 있다고 설명합니다.
응답시간은 조사 시작까지의 시간이며, 해결 완료 시간과 별도로 정해야 합니다.
3. 장애·보안사고의 통지 기준이 있는가
장애나 보안사고가 발생했을 때 담당자가 우연히 발견하거나 업체의 개별 연락을 기다리는 구조는 피해야 합니다. 계약에는 사고를 언제 알릴지, 누구에게 어떤 절차로 통지할지, 이후 사고를 어떻게 관리할지를 문서화할 필요가 있습니다.
모든 사고에 동일한 통지 시간을 적용하기보다 심각도에 맞는 기준을 정하는 것이 중요합니다. 계약 검토 시에는 심각도 분류, 최초 통지 시점, 조사 진행 상황 공유, 사고관리 절차가 서로 연결되어 있는지 살펴보는 것이 좋습니다.
4. 백업이 아니라 복구까지 검증하는가
“정기 백업 제공”이라는 한 줄만으로는 백업 체계의 실효성을 판단하기 어렵습니다. 백업 기준에는 운영 환경과 분리된 오프사이트 백업이 포함되는지, 문제가 생겼을 때 어떤 절차로 데이터를 복구하는지가 함께 담겨야 합니다.
또한 복구 절차를 정기적으로 테스트하는지도 확인해야 합니다. 백업 파일이 존재하더라도 복구 절차가 검증되지 않았다면 실제 장애 상황에서 사용할 수 있는지 확신하기 어렵기 때문입니다.
백업 여부가 아니라 오프사이트 보관과 복구 테스트까지 확인해야 합니다.
5. 관리자 권한과 계정 보안은 어떻게 관리하는가
유지보수 업체가 홈페이지를 관리하려면 시스템 접근 권한이 필요할 수 있습니다. 하지만 모든 담당자에게 광범위한 관리자 권한을 제공할 필요는 없습니다. 관리자와 유지보수 업체의 접근 권한은 업무 수행에 필요한 최소 범위로 제한하는 것이 권고됩니다.
계약 전에는 누가 어떤 계정을 사용하는지, 업무에 필요한 권한만 부여되는지, 계정에 2단계 인증을 적용하는지 확인해야 합니다. 업체와 역할이 바뀌었을 때 기존 접근 권한을 어떻게 정리할지도 운영 기준에 포함할 필요가 있습니다.
관리 권한은 필요한 사람에게 필요한 범위만 부여하고 2단계 인증을 적용해야 합니다.
6. 보안 패치와 지원 종료 관리는 누가 맡는가
홈페이지 운영에는 시스템과 소프트웨어의 보안 패치 및 업데이트가 계속 필요합니다. 계약서에는 업데이트를 누가 확인하고 적용하는지, 적용 과정에서 필요한 조치의 책임 주체가 누구인지 명시해야 합니다.
사용 중인 시스템이나 소프트웨어의 지원 종료일을 추적하는 책임도 중요합니다. 지원이 끝나면 보안 업데이트가 중단되어 취약점이 악용될 위험이 커질 수 있으므로, 교체 또는 업그레이드 조치를 누가 검토하고 실행할지 정해야 합니다.
패치 적용뿐 아니라 지원 종료일 추적과 교체·업그레이드 책임까지 정해야 합니다.
7. 외부 솔루션과 플러그인의 책임 범위가 명확한가
웹사이트는 외부 라이브러리, 플러그인 등 제3자 의존성을 사용할 수 있습니다. 이러한 구성요소도 애플리케이션의 보안 상태에 영향을 주기 때문에 홈페이지 본체와 분리해 생각해서는 안 됩니다.
계약 단계에서는 어떤 외부 구성요소가 사용되는지, 취약점 발견 여부를 누가 확인하는지, 완화 조치와 업데이트는 누가 담당하는지를 확인해야 합니다. 패치 버전을 바로 운영 환경에 적용하기 전에 테스트가 필요할 수도 있으므로 테스트 책임과 적용 절차도 함께 살펴봐야 합니다.
외부 솔루션 관련 작업이 월 유지보수 범위에 포함되는지, 별도 협의 대상인지도 포함·제외 업무 구분과 연결해 명시하는 편이 안전합니다.
8. 계약 종료 후 인수인계 기준이 있는가
유지보수 계약은 시작 조건만큼 종료 조건도 중요합니다. 업체를 변경하거나 계약을 끝낼 때 필요한 데이터와 정보가 반환되지 않거나 운영 지식이 전달되지 않으면 홈페이지 관리가 중단될 수 있습니다.
종료 및 전환 계획에는 데이터와 정보의 반환, 지식 이전, 양측의 역할과 책임, 인수인계 일정과 완료 기준을 포함하는 것이 권고됩니다. 자산, 데이터, 운영 문서가 무엇인지 정리하고 각각 어떤 방식으로 이전할지도 계약서에서 확인해야 합니다.
계약 종료 기준에는 데이터·자산·문서의 이전과 지식 인계가 포함되어야 합니다.
유지보수 제안서는 같은 기준으로 비교해야 합니다
업체마다 유지보수 상품의 명칭과 표현은 다를 수 있습니다. 따라서 수정 횟수나 비용 항목만 나란히 놓기보다 포함·제외 범위, 응답시간과 해결시간, 사고 통지, 백업과 복구, 접근 권한, 보안 업데이트, 외부 의존성, 종료 시 인수인계를 같은 항목으로 맞춰 비교해야 합니다.
좋은 유지보수 계약은 모든 문제를 막겠다는 추상적인 약속이 아니라, 문제가 생겼을 때 누가 언제 무엇을 수행하는지 확인할 수 있는 문서입니다. 홈페이지 제작이나 리뉴얼 이후의 운영 리스크를 줄이려면 계약 전에 이 기준들이 실제 문장으로 명시되어 있는지 점검해야 합니다.