매달 빠져나가는 유지보수비가 정확히 무엇을 사 오는 돈인지 설명할 수 있는 사장님은 의외로 많지 않습니다. 배너 하나 바꾸는 데 추가 견적서가 날아오고, 정작 사이트가 멈춘 주말에는 연락이 닿지 않는 일이 겹치면 그제야 계약서를 다시 꺼내 보게 됩니다. 그런데 열어 보면 대개 월 정액 유지보수라는 한 줄과 금액만 적혀 있습니다.
이 글에서 확인할 것
- 정액에 묶이는 일과 별도 견적으로 갈리는 일의 경계
- 청구서가 슬금슬금 늘어나는 자리
- 계약서에 넣을 항목과 업체를 바꿀 때 받아 둘 자산
유지보수라는 말을 세 갈래로 나눠 본다
첫째는 죽지 않게 지키는 일입니다. 호스팅과 서버가 살아 있는지 보고, 프로그램과 보안 패치를 올리고, 백업 파일이 실제로 복구되는지 확인하는 작업입니다. 눈에 보이는 결과물이 없어서 견적에서 가장 먼저 잘려 나가는 항목인데, 사고가 터졌을 때 회사가 입는 손해는 여기서 갈립니다.
둘째는 바꿔 주는 일입니다. 배너 교체, 공지 등록, 상품 사진 교체, 대표번호 수정처럼 난이도는 낮고 건수는 많은 요청입니다. 월 몇 건까지가 정액이고 그다음부터는 어떻게 계산하는지 적어 두지 않으면 서로 얼굴을 붉히기 딱 좋은 영역입니다.
셋째는 없던 것을 만드는 일입니다. 예약 화면 추가, 결제 연동, 회원 등급 신설처럼 화면이 새로 생기는 작업은 성격상 개발이지 유지보수가 아닙니다. 이걸 정액 안으로 밀어 넣으려다 일정이 밀리고, 업체는 업체대로 손해 보는 기분이 쌓여 대응이 느려집니다.
청구서가 슬금슬금 늘어나는 자리
가장 흔한 것은 범위를 말로만 정한 경우입니다. 계약서에는 금액만 있고 포함 항목은 영업 담당자가 구두로 설명한 채 넘어갑니다. 양쪽 담당자가 한 번씩 바뀌고 나면 그 말을 기억하는 사람이 아무도 남지 않아, 같은 요청을 두고 매번 다시 협상하게 됩니다.
두 번째는 시간 단위 과금입니다. 정액 범위를 넘는 작업을 투입 시간으로 계산하는 방식 자체는 합리적입니다. 문제는 그 시간을 누가 언제 산정하는지 적어 두지 않는 것입니다. 작업 착수 전에 예상 시간을 알려 주고 담당자가 회신으로 승인한 뒤 시작한다는 한 줄만 있으면 대부분 조용히 끝납니다.
세 번째는 계정과 원본을 우리가 쥐고 있지 않은 경우입니다. 도메인이 업체 명의로 등록돼 있거나, 서버 접속 정보와 소스 원본을 업체만 가지고 있으면 금액을 따질 위치 자체가 사라집니다. 이 상태에서는 가격 협상이 아니라 이전 가능 여부가 먼저 문제가 됩니다.
요청 유형별로 비용이 갈리는 기준
아래 표는 실제로 자주 들어가는 요청과, 그 요청이 정액에 묶이는지 별도 견적으로 넘어가는지를 가르는 기준입니다. 업체마다 정책이 다르므로 금액은 넣지 않았습니다. 견적을 받을 때 이 여섯 줄을 그대로 물어보면 계약서에 무엇을 적어야 할지가 드러납니다.
| 요청 유형 | 보통의 처리 | 별도 비용으로 갈리는 기준 |
|---|---|---|
| 배너·이미지 교체 | 월 정액 범위, 건수 제한 | 이미지를 새로 디자인해야 하면 별도 |
| 공지·상품 등록 | 대행하면 건당 과금 | 관리자 화면 교육 후 직접 하면 비용 없음 |
| 보안 패치·버전 업데이트 | 정액 범위 | 업데이트로 깨진 화면 복구는 별도인 곳이 많음 |
| 예약·결제 기능 추가 | 개발 건으로 분리 | 요건 정리 문서 유무에 따라 견적 차이가 큼 |
| 사이트 정지 대응 | 정액 범위, 평일 업무시간 | 야간·주말 대응은 별도 조항이 있어야 함 |
| 도메인·인증서 갱신 | 대행 수수료 | 명의가 업체로 되어 있으면 이전 비용 발생 |
다섯째 줄이 실제 사고에서 가장 크게 갈립니다. 평일 낮에만 대응한다는 조건은 계약서에 쓰여 있지 않아도 업계 관행으로 통하기 때문에, 주말 매출이 큰 사업장이라면 대응 시간과 연락 경로를 따로 적어 두지 않으면 연휴 내내 사이트가 멈춰 있을 수 있습니다. 셋째 줄도 자주 다툽니다. 업데이트는 해 주지만 그 뒤 깨진 화면 복구는 별도라고 보는 업체가 있어, 계약 전에 복구까지 포함인지 한 문장으로 확인해 두어야 합니다.
계약서에 넣는 순서
먼저 우리 자산 목록을 만듭니다. 도메인 등록처와 명의, 호스팅 계정, 관리자 계정, 소스 원본 위치, 결제 연동 정보까지 한 장에 적습니다. 이 목록에서 우리 이름이 아닌 항목이 보이면 계약 조건을 논의하기 전에 그것부터 정리해야 합니다.
그다음 지난 일 년 동안 실제로 요청했던 일을 유형별로 세어 봅니다. 배너 몇 건, 공지 몇 건, 기능 수정 몇 건 식으로 숫자가 나오면 우리에게 필요한 정액 범위가 정해집니다. 요청이 분기에 한두 건뿐이라면 정액 계약보다 건당 계약이 싸게 끝나는 경우도 흔합니다.
세 번째로 대응 기준을 문장으로 적습니다. 접수 창구를 메일이나 메신저 중 하나로 고정하고, 단순 요청과 장애 상황의 회신 시간을 따로 정합니다. 여기까지 정해 두면 담당자가 바뀌어도 기준이 남습니다.
마지막으로 종료 조항을 봅니다. 계약이 끝날 때 무엇을 어떤 형태로 넘겨받는지, 인계 작업이 유상인지 적혀 있어야 합니다. 앱까지 함께 운영하는 회사라면 웹과 앱의 계약 주기와 인계 조건이 서로 다른 경우가 많으니, 앱 유지보수 업체와의 조건도 같은 기준으로 맞춰 두는 편이 나중에 편합니다.
업체를 바꾸기 전에 받아 둘 것
이전을 결심했다면 통보보다 목록이 먼저입니다. 소스 원본, 데이터베이스 백업 파일, 업로드된 이미지 폴더, 관리자 계정과 권한, 외부 연동 키를 받아야 새 업체가 견적을 낼 수 있습니다. 이 다섯 가지를 받지 못한 채 계약을 끝내면 새 업체는 처음부터 다시 만드는 견적을 낼 수밖에 없습니다.
받은 자산은 인수 당일에 열어 봅니다. 백업 파일이 복구되는지, 관리자 계정으로 실제 로그인이 되는지 확인하지 않으면 몇 달 뒤 빈 파일이었다는 것을 알게 됩니다. 사이트가 만들어진 지 오래되어 손볼 곳이 계속 나온다면, 이전을 기회로 오래된 사이트를 구조부터 다시 잡는 작업과 묶어 견적을 받는 편이 결국 싸게 끝납니다.
반대로 화면 수가 적고 기능도 단순한데 유지보수비만 매달 나가고 있다면 새로 만드는 비용과 비교해 볼 만합니다. 요즘 도구로 다시 만들면 관리자 화면에서 직접 수정할 수 있는 범위가 넓어져 대행 요청 자체가 줄어들기 때문에, 홈페이지 제작 견적을 한 번 받아 본 뒤 유지보수 연장 여부를 정하는 회사도 많습니다.
이전이 끝나면 도메인 명의부터 회사 이름으로 바꿉니다. 나머지를 다 챙겨도 도메인이 남의 명의로 있으면 다음 번에 같은 일이 반복됩니다.
점검 목록과 정리
아래 일곱 줄에 예, 아니오로 답해 보세요. 아니오가 나온 줄이 계약서에 추가해야 할 문장입니다.
- 도메인 명의가 회사 이름으로 되어 있는가
- 정액에 포함되는 요청 유형과 월 건수가 적혀 있는가
- 범위를 넘는 작업의 사전 승인 절차가 정해져 있는가
- 장애 발생 시 회신 시간과 야간·주말 대응 조건이 있는가
- 요청 접수 창구가 한 곳으로 고정되어 있는가
- 계약 종료 시 넘겨받을 자산 목록이 문서에 있는가
- 백업 파일이 실제로 복구되는지 확인해 본 적 있는가
유지보수 분쟁은 업체가 나빠서 생기는 경우보다 경계가 없어서 생기는 경우가 훨씬 많습니다. 포함 항목과 건수, 대응 시간, 종료 시 인계물. 이 네 가지만 계약서에 문장으로 남겨도 다음 일 년이 조용해집니다.
유지보수비는 작업의 대가가 아니라 경계의 대가입니다. 경계가 없으면 양쪽 다 손해를 봅니다.
