유지보수 계약은 두 가지 방식으로 실패합니다. 하나는 계약이 아예 없어서 문제가 생길 때마다 매번 새로 협의하는 경우이고, 다른 하나는 월 정액을 내고 있는데 무엇을 받고 있는지 아무도 설명하지 못하는 경우입니다. 두 번째가 더 흔하고 더 오래갑니다.
고칠 방법은 네 가지 항목을 문장으로 적는 것입니다. 범위 · 응답 시간 · 보고 · 종료.
1. 범위 — 포함과 불포함
유지보수의 범위는 대체로 세 층으로 나뉩니다. 이 층을 계약서에 그대로 옮기면 대화가 훨씬 빨라집니다.
유지는 정기적으로 반복되는 일이라 정액에 적합합니다. 대응은 예측할 수 없지만 계약에 포함하는 것이 서로에게 낫습니다 — 장애 시점에 견적을 협의하는 것은 최악의 타이밍이기 때문입니다. 변경은 별도로 두는 것이 정직합니다. 새 기능을 정액에 밀어 넣으면 결국 어느 쪽이든 손해를 봅니다.
여기서 흔한 오해를 하나 짚습니다. 워드프레스는 업데이트가 잦아서 불안한 도구가 아닙니다. 업데이트가 활발하다는 것은 문제가 발견되면 고쳐진다는 뜻이고, 그것이 오래 살아남은 소프트웨어의 특징입니다. 위험은 도구가 아니라 업데이트를 따라가지 않는 상태에 있습니다. 유지보수 계약은 정확히 그 상태를 막기 위한 장치입니다.
2. 응답 시간 — 무엇에 대한 시간인가
“빠르게 대응합니다” 는 계약이 아닙니다. 두 개의 시간을 나누어 적습니다. 응답 시간(연락을 받고 확인했다고 알려주기까지)과 복구 목표(정상으로 되돌리기까지)입니다. 이 둘은 성격이 완전히 다릅니다.
그리고 등급을 나눕니다. 사이트가 통째로 열리지 않는 상황과 특정 페이지의 오탈자는 같은 시간을 약속할 수 없습니다. 보통 세 등급이면 충분합니다.
연락 창구도 함께 적습니다. 어디로 연락하는지, 근무 시간이 언제인지, 그 시간 밖의 긴급 상황은 어떻게 되는지. 근무 시간 외 대응이 없다면 없다고 적는 편이 낫습니다 — 없는 것을 있다고 기대하는 상태가 가장 나쁩니다.
3. 보고 — 무엇을 했는지 남는가
이 항목이 있으면 계약의 성격이 완전히 달라집니다. 월 1회, 한 장짜리라도 좋으니 무엇을 업데이트했고 무엇을 확인했는지가 기록으로 남아야 합니다. 기록이 있으면 나중에 문제가 생겼을 때 원인을 좁힐 수 있고, 무엇보다 정액의 대가가 눈에 보입니다.
보고서에 들어갈 최소 항목은 이렇습니다 — 이번 달에 적용한 업데이트 목록, 백업이 정상 생성되고 있는지, 발견했지만 아직 처리하지 않은 것과 그 이유.
4. 종료 — 끝날 때 무엇을 받는가
계약서에서 가장 적기 싫은 조항이지만 가장 필요한 조항입니다. 계약이 끝날 때 인수인계 범위를 미리 적어 둡니다. 백업 · 접속 정보 · 문서를 며칠 안에 전달하는지, 그 작업에 별도 비용이 있는지. 앞 회차의 인수 목록을 그대로 옮겨 적으면 됩니다.
이 조항을 먼저 제안하는 업체는 신뢰할 만합니다. 떠날 때의 절차를 미리 적는다는 것은 붙잡아 두는 방식으로 관계를 유지하지 않겠다는 선언이기 때문입니다.
지속적인 관제와 업데이트를 어떤 항목으로 구성하는지는 InfraGuard 이용권 페이지에서 실제 예시로 보실 수 있고, 일회성 정비가 먼저 필요한 상태라면 최적화 지원 사업이 그 역할을 합니다.
다음 회차
계약의 형태를 정했다면 상대를 고를 차례입니다. 다음 회차는 프리랜서와 에이전시의 차이인데, 기준은 비용이 아닙니다.