홈페이지 유지보수

제작이 끝나면 비용이 끝난다고 생각했다가 1년 뒤에 문제를 겪는 경우가 많습니다. 홈페이지 유지보수는 장애 대응, 보안 업데이트, 백업, 콘텐츠 수정, 기능 추가가 서로 다른 성격의 작업인데, 계약서에 ‘유지보수’ 한 단어로 뭉뚱그려져 있는 경우가 많습니다. 이 글에서는 유지보수 계약이 실제로 무엇을 포함하고 무엇을 포함하지 않는지 계약서 문구 기준으로 구분하는 법을 정리합니다.

오픈 이후에 실제로 발생하는 일들: 담당자가 겪는 전형적 상황

성격이 다른 요청을 같은 계약 범위로 오해하지 않도록 접수 기준을 만들어 둡니다.

예를 들어 ‘사이트가 느리다’는 성능 문제, ‘이미지가 깨진다’는 표시 오류, ‘글을 올리고 싶다’는 콘텐츠 작업, ‘채용 페이지를 만들고 싶다’는 신규 개발로 성격이 다릅니다. 요청을 접수할 때 성격을 구분해 처리 경로를 정합니다.

오픈 후 실제로 발생하는 요청은 ‘사이트가 느리다’, ‘특정 화면에서 오류가 난다’, ‘공지사항을 올려야 한다’, ‘전화번호를 바꿔야 한다’, ‘새 기능을 넣고 싶다’처럼 다양합니다. 이 요청들은 모두 ‘유지보수’라고 부르지만 성격이 다릅니다.

장애 대응은 사이트가 멈춘 상황의 복구이고, 콘텐츠 수정은 글·이미지 교체이며, 기능 추가는 새로운 개발입니다. 이 셋을 같은 계약 범위로 오해하면 ‘이건 별도 견적’이라는 답변을 듣고 당황하게 됩니다.

유지보수 계약에 보통 포함되는 것과 별도 견적인 것 비교

포함 범위를 확인할 때는 ‘횟수’와 ‘분량’을 함께 봅니다. 콘텐츠 수정이 월 2회 이내로 정해져 있다면 그 이상의 요청은 별도 견적 대상이 될 수 있습니다.

계약서의 ‘포함’과 ‘별도’를 표로 정리하면 협의가 쉬워집니다. 아래 표는 일반적인 구분 예시이며, 실제 포함 범위는 계약서 문구를 기준으로 확인해야 합니다.

‘유지보수 포함’이라는 문구만 보고 모든 수정이 포함된다고 생각하면 안 됩니다. 포함 작업 목록과 횟수, 별도 견적 조건을 계약서에서 확인합니다.

과금 구조 비교: 월정액·건별·연간 계약

과금 구조보다 중요한 것은 ‘요청을 얼마나 자주 하는가’를 기준으로 구조를 고르는 일입니다.

요청 빈도가 월 1회 미만이라면 건별 과금이 합리적일 수 있고, 월 2회 이상이면 월정액이 예측 가능합니다. 계약 기간과 해지 조건도 함께 비교합니다.

유지보수 과금은 월정액, 건별 과금, 연간 계약으로 나뉩니다. 각각 비용의 예측 가능성과 대응 속도가 다릅니다.

월정액이 항상 유리한 것은 아닙니다. 포함 범위가 실제 이용량과 맞지 않으면 비효율적일 수 있습니다. 지난 1년간의 수정 요청 건수를 기준으로 구조를 선택하면 합리적입니다.

대응 시간과 응답 시간: 계약서에서 확인할 SLA 항목

장애 등급이 명시된 계약은 긴급 상황에서 우선순위를 정할 수 있습니다. 예를 들어 사이트 전체 중단은 긴급, 특정 화면 오류는 일반으로 구분하는 방식입니다.

유지보수 만족도를 좌우하는 것은 ‘얼마나 빨리 답변이 오는가’와 ‘얼마나 빨리 해결되는가’입니다. 계약서에서는 응답 시간(요청 후 첫 답변까지)과 처리 시간(문제 해결까지)을 구분해 확인해야 합니다.

• 대응 시간이 업무시간 기준인지, 24시간 기준인지 확인합니다.
• 응답 시간과 처리 시간이 각각 명시돼 있는지 확인합니다.
• 요청 채널(전화·메일·메신저)과 이력 관리 방식을 확인합니다.
• 장애 등급(긴급·일반)별 대응 기준이 있는지 확인합니다.

이 항목이 계약서에 없으면 장애가 났을 때 ‘언제까지 답변받을 수 있는지’를 보장받기 어렵습니다.

백업 정책 점검: 주기·보관 기간·복구 테스트

백업은 만들어 두는 것만으로는 의미가 없습니다. 주기적으로 복구가 되는지 테스트했을 때 비로소 ‘백업이 있다’고 말할 수 있습니다.

백업본은 운영 서버와 분리된 위치에 보관하는 것이 일반적인 안전 기준입니다.

복구 테스트는 장애가 발생하기 전에 해야 의미가 있으므로 정기 점검 항목에 포함합니다.

백업 주기가 하루 1회인지, 보관 기간이 30일인지 90일인지에 따라 복구 가능 시점이 달라집니다. 계약서에 백업 주기와 보관 기간을 명시하고, 연 1회 이상 복구 테스트 결과를 요청합니다.

백업은 ‘해 두는 것’보다 ‘복구할 수 있는 것’이 중요합니다. 백업 주기, 보관 기간, 복구 테스트 여부를 확인해야 합니다. 백업 파일이 있어도 복구 절차를 테스트하지 않으면 실제 장애 때 복구가 안 되는 경우가 있습니다.

계약서에 백업 주기와 보관 기간이 명시됐는지 확인하고, 연 1회 이상 복구 테스트를 요청하는 것이 안전합니다. 사내에서 직접 백업을 관리한다면 파일과 데이터베이스를 함께 보관해야 합니다.

도메인 만료, SSL 갱신, 호스팅 결제 실패로 사이트가 멈추는 사고 예방

세 가지 만료일을 한곳에 모아 관리하면 점검 누락을 줄일 수 있습니다.

도메인 만료 후에는 짧은 유예 기간 안에 갱신해야 하며, 유예 기간이 지나면 다른 사람이 등록할 수 있습니다. SSL 인증서는 만료 1개월 전부터 경고가 뜨므로 알림을 설정해 둡니다.

사이트가 갑자기 멈추는 사고의 상당수는 해킹이 아니라 도메인 만료, SSL 인증서 갱신 누락, 호스팅 결제 실패입니다. 이 세 가지는 정기 점검으로 예방할 수 있습니다.

• 도메인 만료일을 달력에 기록하고 갱신 1~2개월 전 알림을 설정합니다.
• SSL 인증서 유효기간을 확인하고 갱신 절차를 정합니다.
• 호스팅 결제 수단을 유효하게 유지하고 결제 알림을 확인합니다.

도메인과 호스팅 소유권이 발주사 명의인지도 확인해야 합니다. 명의가 제작사에 있으면 계약 종료 후 사이트 운영이 어려워질 수 있습니다.

유지보수를 맡기지 않을 때 사내 최소 점검표

점검 항목은 회사의 환경(호스팅·CMS 사용 여부)에 맞게 조정해 사용합니다.

점검표는 월 1회 실행을 기본으로 하고, 담당자 변경 시 인수인계 자료로도 사용합니다.

점검 결과는 간단한 표로 기록해 두면 다음 점검 때 비교할 수 있습니다. 특히 보안 업데이트는 발표된 취약점이 악용되기 전에 적용하는 것이 중요합니다.

유지보수 계약을 하지 않는다면 사내에서 최소한 아래 항목을 주기적으로 점검해야 합니다.

1. 백업이 최근 날짜 기준으로 정상 생성되고 있는가
2. SSL 인증서 만료일이 임박하지 않았는가
3. 도메인 갱신일이 지나지 않았는가
4. CMS(워드프레스 등)라면 코어·플러그인 업데이트가 필요한지
5. 보안 플러그인의 로그인 시도 차단이 동작하는지
6. 콘텐츠 수정 요청을 처리할 담당자가 정해져 있는가

점검 주기는 월 1회를 기본으로 하고, 발견된 문제는 바로 처리하는 것이 좋습니다.

업체 변경 시 인계받아야 할 자산 목록

인계 자료는 계약 종료 전에 받아 두는 것이 원칙입니다.

인계가 끝난 뒤에는 기존 업체의 접근 권한을 해제했는지 확인하는 절차도 필요합니다.

자산 목록은 계약서에 첨부해 두면 업체 변경 시 ‘무엇을 받아야 하는지’가 명확해집니다.

인계받은 계정은 비밀번호를 변경하고, 더 이상 사용하지 않는 계정은 정리합니다. 인계 목록과 실제 인계 여부를 대조하는 체크리스트를 만들어 두면 업체 변경이 매끄럽게 진행됩니다.

유지보수 업체를 바꾸거나 사내 운영으로 전환할 때는 아래 자산을 인계받아야 합니다.

• 도메인·호스팅·DB 계정과 소유권(발주사 명의 확인)
• 관리자 계정과 권한 목록
• 소스 파일과 데이터베이스 백업본
• 사용 중인 테마·플러그인·라이선스 목록
• 변경 이력과 운영 매뉴얼

인계 항목은 계약서에 명시해 두면 업체 변경 시 분쟁을 줄일 수 있습니다.

자주 묻는 질문(FAQ)

Q. 유지보수 계약은 필수인가요?
필수는 아니지만, 사내 운영 인력이 없으면 보안·백업 관리를 놓치기 쉽습니다. 포함 범위와 비용을 비교해 결정합니다.

Q. 콘텐츠 수정도 유지보수에 포함되나요?
계약에 따라 다릅니다. 월 수정 횟수와 분량이 정해진 경우가 많으므로 계약서를 확인합니다.

Q. 장애가 나면 얼마나 빨리 고쳐지나요?
계약서의 응답 시간과 처리 시간, 장애 등급별 기준에 따라 다릅니다. 계약 전에 SLA 항목을 확인합니다.

이 글은 AI(인공지능)의 도움을 받아 작성되었습니다.