유지보수는 어디까지가 유지보수입니까?

사이트가 문을 열어도 손이 가는 일은 계속 생깁니다. 어디까지가 유지보수이고 어디서부터 새 일인지, 그 경계가 계약서에 어떻게 적히는지 정리했습니다.

사이트가 문을 열면 계약서 대부분은 끝난 상태가 됩니다. 그런데 손이 가는 일은 그때부터 새로 생깁니다.

이 일이 원래 계약 안에 있는지 새 일인지, 요청하실 때마다 판단하기 어렵습니다. 그래서 개발사와 다툼이 생기기 쉬운 부분입니다.

고치는 일과 만드는 일은 다릅니다

「유지보수」는 원래 약속한 대로 돌아오게 하는 일입니다. 눌리지 않던 버튼을 다시 눌리게 만들고 깨졌던 화면을 원래 모습으로 되돌립니다.

「새 일」은 원래 없던 것을 넣는 일입니다. 로그인 화면에 소셜 로그인 버튼을 추가해 달라고 하시면 여기에 들어갑니다. 없던 결제 수단을 붙이는 일도 마찬가지입니다.

이 구분에 따라 고객이 받으실 견적과 처리 순서가 달라집니다. 고치는 일은 계약에 이미 포함된 대응으로 처리됩니다. 만드는 일은 별도 견적과 일정을 다시 잡습니다.

경계가 애매한 자리도 있습니다. 있던 기능을 개선해 달라고 하실 때입니다.

검색 결과를 더 빠르게 보여 달라는 요청은 고치는 쪽에 가깝습니다. 검색 항목을 새로 추가해 달라는 요청은 만드는 쪽에 가깝습니다. 둘 다 「검색을 손봐 달라」는 한마디로 나가기 때문에 미리 나눠 두시는 편이 낫습니다.

계약서는 이 경계를 범주로 적습니다

이 경계를 「범주」로 나눠 적는 계약서가 있습니다. 오류 대응, 콘텐츠 수정, 보안 패치처럼 항목을 나눠 범위를 정하고 항목마다 포함 여부를 표시합니다.

건수나 시간 단위로 상한을 두는 곳도 있습니다. 상한을 넘는 요청은 별도 협의로 넘어갑니다. 이 기준이 계약서에 없으면 요청하실 때마다 처음부터 이야기하시게 됩니다.

대응 범위를 화면 단위로 적는 계약서도 있습니다. 메인 화면과 상세 화면은 포함하고 관리자 화면은 빼는 식입니다. 화면 하나가 통째로 빠져 있으면 그 화면에서 난 오류는 유지보수 밖의 일이 됩니다.

범주를 미리 정해 두시면 다툴 일이 줄어듭니다. 요청이 들어올 때 계약서를 펼쳐 이 항목이 포함인지 보시면 됩니다.

가만히 둬도 생기는 일이 있습니다

고객이 아무것도 요청하지 않으셔도 손이 가는 일이 있습니다.

브라우저가 버전을 올리면 화면 일부가 다르게 나타날 때가 있습니다. 손댄 적 없는 코드인데 결과만 달라집니다.

라이브러리도 마찬가지입니다. 사이트를 만들 때 가져다 쓴 부품에서 보안 구멍이 발견되면 그 부품을 새 버전으로 바꿔야 합니다. 화면은 그대로인데 안쪽만 바뀌는 일이라 고객 눈에는 아무 변화가 없습니다.

결제, 지도, 로그인처럼 바깥 서비스와 연결된 기능은 그쪽이 규격을 바꾸면 따라 바뀝니다. 카드사가 인증 방식을 바꾸면 연결된 코드도 맞춰 고쳐야 합니다. 고객 쪽에서 먼저 손댄 일이 아닌데도 대응은 그 사이트의 몫입니다.

인증서 만료와 호스팅 요금제 변경도 이 목록에 들어갑니다. 보안 인증서는 정해진 시점마다 다시 발급받아야 주소창의 잠금 표시가 유지됩니다. 호스팅 회사가 요금제 구성을 바꾸면 계약을 다시 확인하셔야 할 때도 있습니다.

이런 일은 고객이 먼저 알아채기 어렵습니다. 화면을 눌러 보시는 정도로는 안쪽에서 무엇이 낡아가는지 안 보입니다. 정기적으로 들여다보는 쪽이 있어야 미리 잡힙니다.

응답 시간과 복구 시간은 다릅니다

문의를 받았다는 확인과 문제가 실제로 고쳐지는 시점은 다른 일입니다. 오류를 접수했다는 연락이 먼저 오고 그 오류가 고쳐지는 일은 그 뒤에 옵니다.

계약서에는 「응답 시간」과 「복구 시간」이 따로 적혀 있어야 합니다. 하나만 적혀 있으면 어느 쪽인지 확인하십시오.

접수 확인만 빠르고 실제 조치는 늦게 오는 경우가 있습니다. 연락은 받으셨는데 화면은 그대로인 상태가 며칠 이어집니다. 「두 시간 안에 대응」이라는 문구가 어느 쪽을 가리키는지에 따라 뜻이 달라집니다.

오류의 성격에 따라 순서도 달라집니다. 결제가 막히는 오류와 화면 여백이 어긋나는 오류를 같은 순서로 처리하지는 않습니다. 심각도를 나누는 기준이 있는 계약서라면 그 기준부터 보십시오.

무상 기간이 실제로 덮는 범위

프로젝트 종료 후 일정 기간을 무상으로 안내하는 계약서가 있습니다. 이 「무상 기간」이 덮는 일은 계약서에 적어 둔 범주 안의 오류 대응입니다. 범주 밖의 요청은 무상 기간 안에 넣으셔도 별도 견적으로 처리됩니다.

무상 기간과 유지보수 계약은 같은 말이 아닙니다. 무상 기간이 끝나면 그 이후를 어떻게 할지 다시 정하셔야 합니다.

그때 고르실 수 있습니다. 계약을 새로 맺으실 수도 있고 문제가 생길 때마다 건별로 부탁하실 수도 있습니다.

맡기지 않으면 고객이 직접 지는 일이 있습니다

유지보수를 맡기지 않는 선택도 있습니다. 회사 안에 화면을 만질 수 있는 분이 계시면 작은 수정은 직접 처리하실 수 있습니다. 이때는 계약 없이 지내시는 쪽이 자연스럽습니다.

다만 맡기지 않기로 하시면 가만히 생기는 일까지 고객이 챙기시게 됩니다. 라이브러리 보안 알림을 받아 보실 방법을 마련해 두십시오. 인증서 만료일을 달력에 적어 두십시오. 바깥 서비스의 규격 변경 공지를 직접 구독하십시오.

이 확인을 빠뜨리시면 화면이 멈추고 나서 아시게 됩니다.

오류가 났을 때 어디에 먼저 연락하실지도 미리 정해 두십시오. 원래 만든 곳에 건별로 의뢰하실 수도 있고 다른 곳에 새로 맡기실 수도 있습니다. 다른 곳에 맡기시면 코드를 처음부터 파악하는 시간이 먼저 듭니다.

앱은 사정이 조금 다릅니다

운영체제가 새 버전을 내놓으면 그 버전에 맞춰 코드를 다시 손보는 일이 생깁니다. 웹에는 없는 일입니다. 앱에서는 새 버전이 나올 때마다 되풀이됩니다.

화면을 고치는 일과 성격이 달라서 같은 계약서 항목으로 묶기 어렵습니다. 앱을 함께 운영하시면 이 항목을 따로 적어 두십시오.

그래서 유지보수 범위는 계약 전에 정해야 합니까?

네, 지금 계약서에 유지보수 범위를 적어 두셔야 합니다. 일이 생긴 뒤에 정하면 이미 늦습니다.

사이트를 연 뒤에는 요청이 계속 들어옵니다. 그 요청마다 포함인지 아닌지 다시 협의하면 같은 다툼이 매번 반복됩니다. 범주를 미리 적어 두신 계약서는 요청이 올 때 펼쳐 보시는 것으로 끝납니다.

가만히 둬도 생기는 일도 있습니다. 라이브러리 보안 구멍과 바깥 서비스의 규격 변경과 인증서 만료는 고객이 먼저 알아채기 어렵습니다. 계약 전에 누가 챙길지 적어 두지 않으면 화면이 멈춘 뒤에야 책임을 두고 다투게 됩니다.

결론은 하나입니다. 범주, 대응 범위, 응답 시간과 복구 시간을 계약서에 먼저 적는 것입니다.