홈페이지 유지보수 계약서에서 반드시 확인해야 할 항목

'유지보수' 한 단어에 섞여 있는 네 가지 다른 업무

첫째는 운영입니다. 서버와 호스팅이 살아 있게 하고, 소프트웨어 보안 업데이트를 적용하며, 백업이 실제로 돌아가는지 확인하는 일입니다. 눈에 보이지 않지만 빠지면 가장 큰 사고로 이어집니다.

둘째는 장애 대응입니다. 이미 만들어진 기능이 어느 날 동작하지 않을 때 원인을 찾아 되돌리는 일입니다. 이것은 제작사의 책임 범위와 맞닿아 있어, 하자 보수 기간과 유지보수 계약의 경계를 문서에서 분명히 해 두어야 합니다.

셋째는 콘텐츠 수정입니다. 문구를 바꾸고 사진을 교체하고 공지사항을 올리는 일입니다. 회사에서 직접 할 수 있는 부분이 어디까지인지에 따라 필요량이 크게 달라집니다.

넷째는 기능 추가입니다. 새 페이지를 만들거나 새로운 신청 양식을 붙이거나 외부 도구와 연동하는 일입니다. 이것은 사실상 새 개발이며, 월 정액에 뭉뚱그려 넣으면 양쪽 모두 불만이 쌓입니다.

이 네 가지를 분리해서 견적을 요청하면, 금액 차이가 어디에서 나는지가 곧바로 보입니다. 어떤 곳은 운영만 계산했고, 어떤 곳은 콘텐츠 수정 인력까지 잡아 두었을 수 있습니다.

• ●운영: 호스팅·보안 업데이트·백업 점검
• ●장애 대응: 기존 기능이 멈췄을 때의 복구
• ●콘텐츠 수정: 문구·사진·게시물 교체
• ●기능 추가: 사실상 신규 개발이며 별도 산정이 원칙

월 정액이 실제로 무엇을 몇 번까지 덮는가

월 정액 계약에서 가장 자주 다투는 지점은 '얼마나'입니다. 시간으로 정하는 방식, 요청 건수로 정하는 방식, 항목별로 정하는 방식이 있고 각각 장단점이 다릅니다. 시간제는 유연하지만 무엇이 몇 시간짜리인지에 대한 감각이 서로 다를 수 있습니다. 건수제는 명확하지만 작은 요청 하나와 반나절짜리 작업이 같은 한 건으로 계산되면 불합리해집니다.

쓰지 않은 분량이 다음 달로 넘어가는지도 미리 정해야 합니다. 넘어가지 않는다면 조용한 달에는 손해를 보고, 무제한으로 쌓인다면 제작사 쪽이 감당하기 어려워집니다. 이월 한도를 정해 두는 방식이 현실적입니다.

응답 시간에 대한 약속도 필요합니다. 다만 '몇 시간 안에 해결'이 아니라 '몇 시간 안에 접수 확인 및 상황 공유'가 현실적인 약속입니다. 원인에 따라 해결 시간은 크게 달라지기 때문입니다. 긴급 상황의 정의도 함께 적어야 합니다. 사이트 전체가 열리지 않는 상황과 문구 오타는 같은 긴급도로 다룰 수 없습니다.

• ●산정 방식(시간·건수·항목)과 그 근거를 문서에 남깁니다
• ●미사용분의 이월 여부와 한도를 명시합니다
• ●해결 시간이 아니라 접수·공유 시간을 약속 대상으로 삼습니다
• ●'긴급'의 정의와 그때의 연락 경로를 따로 적어 둡니다

계약서에 없으면 나중에 반드시 문제가 되는 항목

가장 흔한 사고는 도메인과 인증서 갱신입니다. 누가 갱신 비용을 내고 누가 만료 전에 확인하는지가 정해져 있지 않으면, 어느 날 아침 사이트가 경고 화면과 함께 열립니다. 보안 인증서는 유효 기간이 정해져 있고 자동 갱신을 쓰는 경우가 많은데, 자동 갱신이 실패해도 아무도 모르는 구조라면 위험합니다. 예컨대 Let's Encrypt는 공식 문서에서 인증서 유효 기간을 90일로 안내하고 자동 갱신을 권장합니다. 자동화가 되어 있는지, 실패 시 누구에게 알림이 가는지까지 확인해야 합니다.

백업도 마찬가지입니다. 백업을 '한다'는 문장만으로는 부족합니다. 얼마나 자주 하는지, 며칠치를 보관하는지, 그리고 실제로 복구가 되는지 시험해 본 적이 있는지가 중요합니다. 복구해 본 적 없는 백업은 백업이라고 부르기 어렵습니다.

마지막은 종료 조항입니다. 계약이 끝날 때 무엇을 어떤 형태로 넘겨받는지 적혀 있지 않으면, 업체를 바꾸는 시점에 협상력이 사라집니다. 소스코드, 데이터베이스, 계정 접근 권한, 문서까지 인수인계 대상에 포함시켜 두어야 합니다.

• ●도메인·인증서 갱신의 비용 부담자와 확인 책임자를 지정합니다
• ●백업 주기·보관 기간·복구 시험 여부를 문서화합니다
• ●계약 종료 시 인계 대상 목록과 인계 기한을 미리 정합니다
• ●작업 이력과 접속 계정 목록을 어디에 보관할지 정합니다

월 유지보수 계약이 필요하지 않은 경우도 있습니다

모든 사이트에 매달 고정비가 필요한 것은 아닙니다. 몇 개의 소개 페이지로 구성되고 내용이 거의 바뀌지 않으며, 신청 양식 하나 정도만 있는 사이트라면 월 정액 콘텐츠 수정 계약은 대부분 낭비됩니다. 이 경우에는 호스팅과 보안 업데이트만 확실히 챙기고, 수정이 필요할 때 건별로 요청하는 방식이 합리적입니다.

반대로 반드시 계약이 필요한 경우도 분명합니다. 결제가 오가는 사이트, 신청 정보가 계속 들어오는 사이트, 여러 사람이 매주 내용을 고치는 사이트, 외부 도구와 연동되어 있는 사이트는 손을 놓는 순간 문제가 조용히 쌓입니다. 특히 결제나 개인정보가 관련된 곳은 방치 자체가 위험입니다.

판단 기준은 간단합니다. 사이트가 멈췄을 때 회사가 잃는 것이 무엇인지 계산해 보는 것입니다. 잃을 것이 크지 않다면 가벼운 계약으로 충분하고, 잃을 것이 크다면 응답 약속이 있는 계약이 필요합니다.

• ●내용이 거의 바뀌지 않는 소개형 사이트는 운영 중심의 최소 계약으로 충분합니다
• ●결제·신청 정보·외부 연동이 있는 사이트는 방치 위험이 큽니다
• ●기준은 '사이트가 멈추면 무엇을 잃는가'입니다
• ●필요 이상으로 큰 계약을 권하는 제안은 근거를 물어보시기 바랍니다

견적을 비교할 때 금액보다 먼저 맞춰야 할 것

세 곳에서 받은 견적을 바로 비교하면 거의 항상 잘못된 결론이 나옵니다. 먼저 우리 쪽에서 조건표를 만들어 같은 질문지를 보내야 합니다. 월 몇 시간 또는 몇 건인지, 이월 여부, 접수 응답 시간, 긴급 정의, 백업 주기, 도메인과 인증서 책임, 종료 시 인계 범위, 기능 추가의 단가 기준까지 같은 항목으로 답을 받으면 비교가 가능해집니다.

이렇게 맞춰 놓고 보면 저렴해 보이던 견적이 사실은 운영만 포함한 것이었거나, 비싸 보이던 견적에 담당자 대응 시간이 들어 있었다는 사실이 드러납니다. 원화 기준 금액 자체보다 그 금액이 무엇을 사는 돈인지가 훨씬 중요합니다.

한 가지 덧붙이면, 유지보수 담당자가 실제로 우리 사이트를 만든 구조를 이해하고 있는지도 확인할 만합니다. 만든 곳과 관리하는 곳이 다를 때는 초기에 구조를 파악하는 시간이 필요하며, 그 시간을 누가 부담하는지도 미리 이야기해 두는 편이 낫습니다.

• ●같은 항목의 질문지를 만들어 모든 업체에 동일하게 보냅니다
• ●금액이 아니라 '그 금액이 무엇을 포함하는가'를 비교합니다
• ●기능 추가 단가 기준을 계약 시점에 미리 받아 둡니다
• ●제작사와 관리사가 다를 경우 초기 구조 파악 비용을 사전에 정리합니다

자주 묻는 질문