납품 뒤에 멈춘 사이트는,
고장 난 게 아닙니다

결론부터 말씀드리면 — 납품 뒤에 방치되는 사이트는 대개 고장 난 게 아닙니다. 바꿀 일이 생겼을 때 누가, 어떤 경로로 바꾸는지가 정해지지 않은 상태입니다. 그래서 유지보수 조항에서 먼저 볼 것은 월 금액이 아니라, 무엇을 지켜 주고 무엇을 바꿔 주는지가 나뉘어 적혀 있는가입니다.

방치는 한 번에 오지 않습니다

사이트를 오픈한 날에는 바꿀 것이 없어 보입니다. 몇 주에 걸쳐 확인하고 고친 결과물이니까요. 그런데 막 시작한 브랜드는 오픈 뒤에 오히려 많이 바뀝니다. 상담을 해 보니 가격 구성을 손봐야 하고, 첫 고객이 생겨 사례를 올리고 싶고, 손님에게 가장 잘 먹힌 설명이 사이트 첫 문장과 다릅니다. 무엇을 누구에게 파는지가 실제 손님을 만나면서 다듬어지는 시기이기 때문입니다.

여기서 작은 멈춤이 시작됩니다. 문장 하나를 바꾸려는데 누구에게 말해야 하는지, 돈이 드는지, 얼마나 걸리는지를 모릅니다. 한 줄 고치자고 연락하기가 애매해서 모아서 하기로 합니다. 그 사이 대표님은 인스타그램과 상담 자리에서 새 설명을 먼저 쓰고, 사이트에는 예전 설명이 남습니다. 방문자는 사이트가 언제 수정됐는지 보지 않지만, 사이트에 적힌 말과 상담에서 듣는 말이 다르면 알아챕니다. 값이 큰 일일수록 그 어긋남은 신뢰의 문제로 읽힙니다.

보이지 않는 멈춤도 있습니다. 도메인 갱신일이 지나가고, 보안 인증서가 만료되고, 문의 폼 알림이 가던 메일 주소가 바뀌어 문의가 아무 데도 도착하지 않는 일. 이런 일은 누군가 확인하기 전까지는 조용합니다. 사이트는 멀쩡히 떠 있는데 문의만 끊긴 상태를, 대표님은 "요즘 문의가 없네"로 경험하게 됩니다.

"유지보수" 한 단어에 두 가지 일이 섞여 있습니다

계약서에 흔히 적히는 "유지보수 포함", "월 관리"라는 말 안에는 성격이 전혀 다른 두 가지 일이 들어 있습니다.

하나는 지키는 일입니다. 도메인과 호스팅 갱신, 보안 업데이트, 백업, 문의가 실제로 도착하는지 확인하는 일. 해도 티가 안 나고, 안 해도 한동안은 아무도 모릅니다. 다른 하나는 바꾸는 일입니다. 문구와 가격 교체, 사진 교체, 사례 추가, 새 페이지. 눈에 보이기 때문에 요청이 몰리고, 어디까지를 수정으로 볼지 선이 없으면 끝이 없습니다.

두 가지가 한 줄로 묶여 있으면 양쪽 모두에게 곤란한 일이 생깁니다. 대표님은 월 비용을 내니 바꾸는 일도 당연히 포함이라고 생각하고, 업체는 지키는 일의 값이라고 생각합니다. 첫 요청에서 그 차이가 드러나고, 그때부터 요청 하나하나가 협상이 됩니다. 협상이 번거로우니 요청을 미루고, 사이트는 다시 멈춥니다.

계약 전에, 이 순서로 확인합니다

전부 계약서나 견적서에서 확인하거나 상담 자리에서 한 번 물어보면 되는 것들입니다. 답이 좋고 나쁘고보다, 답이 적혀 있는지가 먼저입니다.

1. 지키는 일을 항목 이름으로 적어 달라고 합니다. "관리 포함"은 항목이 아닙니다. 도메인 갱신, 호스팅, 보안 업데이트, 백업, 문의 도착 확인 — 각각을 누가 맡는지 한 줄씩 적혀 있어야 합니다. 사이트 구조에 따라 필요 없는 항목도 있습니다. 그럴 때는 빠진 항목이 왜 필요 없는지 설명을 들으면 됩니다. 설명이 되면 빠진 게 아니라 정리된 겁니다.
2. 바꾸는 일은 예시로 선을 확인합니다. "수정은 어디까지인가요"라고 물으면 답이 추상적으로 돌아옵니다. 대신 구체적인 요청 세 개를 들고 물어보세요. 가격표의 한 줄을 바꾸는 것, 사례 하나를 추가하는 것, 새 서비스 페이지를 만드는 것. 셋 중 어디까지가 관리 범위이고 어디부터 새 작업인지 들으면, 그 업체가 긋는 선이 보입니다.
3. 요청하는 곳과 반영되는 시점을 확인합니다. 어디로 요청하면 되는지, 요청하고 나서 언제쯤 반영되는지. 적정한 기간에 정답은 없습니다. 중요한 건 약속이 적혀 있는가이고, 지킬 수 있는 약속인가입니다. 지키지 못하는 응답 약속이 차라리 없는 것보다 나쁜 이유는 카톡·전화·폼, 무엇을 열지는 업종으로 안 정해집니다에서 문의 채널을 두고 적은 것과 같은 원리입니다.
4. 대표님이 직접 바꿀 수 있는 자리를 정합니다. 자주 바뀌는 것 — 가격, 사례, 공지 같은 것 — 은 직접 바꿀 수 있으면 요청이 필요 없어집니다. 다만 모든 자리를 여는 것이 답은 아닙니다. 첫 화면 구성이나 페이지 순서까지 열어 두면 급하게 고치다가 설계가 무너집니다. 직접 바꾸는 자리와 요청해야 하는 자리가 어디서 나뉘는지를 계약 전에 합의해 두시면 됩니다.
5. 관리 계약이 끝나면 사이트가 어떻게 되는지 묻습니다. 관리를 끊는 순간 사이트도 같이 내려가는 구조인지, 계속 떠 있는 채로 넘겨받을 수 있는지. 도메인과 호스팅 계정이 누구 이름으로 남는지는 견적 금액이 갈리는 자리는, 견적서 밖입니다에서 다뤘는데, 유지보수 계약에서는 같은 질문이 "그만둘 수 있는가"의 형태로 돌아옵니다. 그만둘 수 있는 계약이어야 계속할지를 대표님이 고를 수 있습니다.

월 관리 계약이 늘 필요한 건 아닙니다

오해를 하나 걷어 두겠습니다. 매달 관리비를 내는 계약이 꼭 필요하다는 이야기가 아닙니다. 서버 프로그램이나 데이터베이스가 없는 가벼운 구조의 사이트라면 지키는 일 자체가 적습니다. 내용이 바뀔 일도 드물다면, 필요할 때마다 건별로 요청하는 편이 맞을 수 있습니다.

반대 방향도 확인해 볼 만합니다. 매달 관리비를 내고 있는데 한 번도 요청한 적이 없다면, 두 가지 중 하나입니다. 정말 바뀔 일이 없었거나, 바꿀 일은 있었는데 요청하는 방법을 몰라 미뤄 왔거나. 뒤쪽이라면 문제는 금액이 아니라 경로입니다.

그리고 이 확인의 진짜 소득은 계약서 밖에 있습니다. 위의 다섯 가지를 따지다 보면 결국 한 가지 질문으로 모입니다. 오픈 뒤에 우리 사이트에서 무엇이 자주 바뀔 것인가. 그 목록을 오픈 전에 적어 두면, 어느 자리를 직접 바꿀 수 있게 만들지와 관리 계약에 무엇을 넣을지가 함께 정해집니다. 목록이 안 나온다면 사이트보다 먼저 정할 것이 남아 있다는 뜻이고, 그 이야기는 브랜드 런칭, 디자인보다 먼저 정해야 하는 것에 정리해 뒀습니다.

지금 바로 확인해 보세요

받아 둔 유지보수 조항이나 지금 쓰는 사이트의 계약을 열고 이 다섯 줄만 짚어 보시면 됩니다.

• 도메인·호스팅·보안·백업을 누가 맡는지 항목별로 적혀 있는가?
• 문의 폼으로 들어온 문의가 실제로 도착하는지, 누가 언제 확인하는지 정해져 있는가?
• "수정"과 "새 작업"의 경계를 예시로 설명 들은 적이 있는가?
• 가격·사례처럼 자주 바뀌는 자리를 대표님이 직접 바꿀 수 있는가?
• 관리 계약을 끝내도 사이트가 떠 있는 채로 넘어오는가?

"아니오"가 나온 줄은 업체의 잘못이라기보다, 아직 아무도 맡지 않은 일입니다. 계약 전이라면 조항 한 줄로 정리되고, 이미 운영 중이라면 오늘 연락 한 번으로 정리됩니다. 아무도 안 맡은 일은 사이트가 멈춘 뒤에야 누구 일이었는지 드러납니다.