초록
"홈페이지 유지보수 월 얼마가 적정한가"라는 질문에는 단일한 답이 없습니다. 금액이 아니라 범위가 정해지지 않았기 때문입니다. 유지보수라는 한 단어 안에는 장애 대응, 보안·의존성 갱신, 콘텐츠 수정, 소규모 기능 개선, 인프라 관리라는 성격이 전혀 다른 다섯 가지 작업이 들어 있고, 각각은 발생 빈도도 필요 역량도 원가 구조도 다릅니다. 이 글은 먼저 다섯 작업을 분해한 뒤, 계약 전에 반드시 갈라야 할 무상 하자보수와 유상 유지보수의 경계를 다룹니다. 이어서 "간단한 수정"이 왜 분쟁의 단골이 되는지를 원가 구조로 설명하고, 정액·시간제·건당이라는 세 가지 과금 방식이 각각 어떤 상황에서 유리한지 비교합니다. 그 다음 응답시간·복구 기준을 실제로 적을 수 있는 문장 형태로 제시하고, 마지막에 계약 종료 시 돌려받아야 할 것들을 목록으로 정리합니다. 특정 업체의 요율표는 다루지 않습니다.
1. 서론
구축이 끝나면 이 대화가 옵니다.
"유지보수는 월 얼마로 하시나요?"
이 질문에 바로 숫자를 답하는 업체가 있다면, 그 숫자는 대개 두 가지 중 하나입니다. 아무것도 포함되지 않은 최소 금액이거나, 나중에 안 될 것을 알면서 부른 금액이거나.
문제는 이 질문이 가격 질문의 형태를 하고 있지만 실제로는 범위 질문이라는 데 있습니다. 그리고 양쪽이 서로 다른 것을 떠올린 채 계약합니다.
의뢰인이 떠올리는 유지보수:
"사이트에 문제 생기면 고쳐 주고, 배너 바꿔 달라고 하면 바꿔 주고, 페이지 하나쯤 추가해 주는 것."
업체가 떠올리는 유지보수:
"장애가 나면 복구하고, 보안 패치를 하고, 서버가 살아 있게 하는 것. 화면 수정은 별건."
이 간극이 3개월쯤 지나서 드러납니다. 그리고 그때는 이미 관계가 시작된 뒤라 조정이 어렵습니다. 계약 전에 문장으로 고정해야 하는 이유입니다.
2. 유지보수가 뭉뚱그리는 다섯 가지
먼저 분해합니다. 이 다섯은 성격이 서로 아주 다릅니다.
① 장애 대응
사이트가 안 열리거나, 기능이 동작하지 않거나, 데이터가 잘못 나오는 상황을 정상으로 되돌리는 일입니다.
- 빈도: 낮음. 잘 만든 사이트는 몇 달에 한 번도 없습니다
- 필요 역량: 높음. 원인을 찾아야 합니다
- 성격: 대기 비용입니다. 아무 일이 없어도 대응할 수 있는 상태를 유지하는 값
이 항목의 성격을 이해하는 것이 중요합니다. "이번 달에 아무 일도 안 했는데 왜 돈을 내느냐"는 질문이 여기서 나오는데, 소방서가 화재가 없는 달에도 유지되는 것과 같은 구조입니다. 아무 일도 없었다는 것이 성과인 항목입니다.
② 보안·의존성 갱신
외부 패키지, 프레임워크, 서버 소프트웨어를 최신 상태로 유지하는 일입니다.
- 빈도: 정기적. 월 1회 또는 분기 1회
- 필요 역량: 중간~높음. 올리면 깨지는 것을 확인해야 합니다
- 성격: 미루면 이자가 붙습니다. 2년을 미루면 한 번에 올리기 어려워집니다
이 항목이 계약에서 자주 빠집니다. 그리고 안 해도 당장은 아무 일이 없어서, 빠졌다는 사실도 몇 년간 드러나지 않습니다. 드러날 때는 대개 사고입니다.
③ 콘텐츠 수정
배너 교체, 문구 변경, 게시물 등록, 이미지 교체, 담당자 정보 수정.
- 빈도: 높음. 매주 있을 수도 있습니다
- 필요 역량: 낮음
- 성격: 작업량에 비례합니다. 위 두 항목과 완전히 다른 성격
여기서 분쟁의 대부분이 나옵니다. 뒤에서 따로 다룹니다.
그리고 이 항목은 애초에 발생하지 않게 만들 수 있습니다. 관리자 화면을 통해 담당자가 직접 바꿀 수 있게 해 두면 됩니다. 구축 단계에서 결정할 일이고, 이 결정이 유지보수 비용을 가장 크게 좌우합니다.
④ 소규모 기능 개선
페이지 추가, 폼 항목 변경, 목록에 필터 추가, 통계 화면 하나 만들기.
- 빈도: 사업 변화에 따라
- 필요 역량: 높음. 개발입니다
- 성격: 이건 유지보수가 아니라 개발입니다. 규모가 작을 뿐
가장 자주 다투는 경계선입니다. 의뢰인은 "간단한 거니까 유지보수에 포함"이라고 보고, 업체는 "새로 만드는 것이니 별건"이라고 봅니다. 둘 다 일리가 있어서 사전에 정하지 않으면 매번 협상하게 됩니다.
⑤ 인프라 관리·비용
서버, 도메인, 인증서, 스토리지, 외부 서비스 요금.
- 빈도: 상시
- 성격: 실비 + 관리 시간
여기서 확인할 것은 누구 명의로 가입되어 있고 누구 카드로 결제되는가입니다. 업체 계정으로 묶여 있으면 나갈 때 문제가 됩니다. 가능하면 우리 명의, 우리 결제로 두고 업체에 권한을 주는 형태가 낫습니다.
정리
| 항목 | 빈도 | 성격 | 안 하면 |
|---|---|---|---|
| ① 장애 대응 | 낮음 | 대기 비용 | 멈췄을 때 아무도 없음 |
| ② 보안·갱신 | 정기 | 예방 비용 | 몇 년 뒤 사고 또는 대공사 |
| ③ 콘텐츠 수정 | 높음 | 작업량 비례 | 사이트가 낡아 감 |
| ④ 기능 개선 | 부정기 | 개발 | 사업 변화를 못 따라감 |
| ⑤ 인프라 | 상시 | 실비+관리 | 어느 날 서비스 정지 |
계약서에는 이 다섯 줄이 각각 들어가야 합니다. "유지보수 월 OO원"이라는 한 줄로는 어떤 것도 정해지지 않습니다.
3. 무상 하자보수와 유상 유지보수는 다른 것이다
이 구분을 안 하고 시작하면 초기 몇 달이 계속 어색합니다.
하자보수는 납품한 것이 계약한 대로 동작하지 않을 때 고치는 것입니다. 처음부터 잘못 만든 것을 바로잡는 일이므로 원칙적으로 무상입니다.
유지보수는 정상적으로 동작하는 것을 계속 정상으로 유지하고, 변화에 맞춰 손보는 일입니다. 유상입니다.
경계가 애매한 예를 몇 개 놓고 보면 감이 잡힙니다.
| 상황 | 통상 분류 |
|---|---|
| 문의 폼이 처음부터 메일을 안 보냈다 | 하자 |
| 잘 되던 문의 폼이 6개월 뒤 메일 서비스 정책 변경으로 멈췄다 | 유지보수 |
| 특정 브라우저에서 레이아웃이 깨진다 (지원 대상 브라우저였다면) | 하자 |
| 새로 나온 브라우저 버전에서 깨진다 | 유지보수 |
| 요청한 기능이 구현되지 않았다 | 하자 |
| 요청하지 않았던 기능이 필요해졌다 | 신규 개발 |
| 트래픽이 늘어 느려졌다 | 사안별 (설계 문제면 하자, 성장이면 개선) |
계약서에 넣을 것은 두 가지입니다.
첫째, 무상 하자보수 기간. 공공 부문 계약에는 별도의 기준이 적용되는 경우가 있으나, 민간 계약에서는 당사자가 정하는 것이 원칙입니다. 국내 실무에서는 검수 완료 후 3개월에서 12개월 사이가 흔하고, 6개월이 가장 자주 보입니다. 짧게 잡는 대신 그 기간에 확실히 대응받는 편이 나을 수도 있으니, 기간의 길이보다 그 기간에 무엇이 포함되는지를 더 신경 쓰십시오.
둘째, 하자의 정의. "계약서와 요구사항 정의서에 기재된 동작과 다른 경우"처럼 기준 문서를 명시합니다. 기준 문서가 없으면 하자 판정이 매번 말싸움이 됩니다. 이 지점은 요구사항 정의가 애초에 얼마나 촘촘했는지에 달려 있고, 그래서 개발 외주를 처음 맡길 때 단계의 문서가 나중에 여기서 쓰입니다.
하자보수 기간에도 유지보수 계약이 필요한가라는 질문이 자주 나옵니다. 답은 "①②⑤는 필요하고 ③④는 필요 없을 수 있다"입니다. 하자보수는 잘못 만든 것을 고쳐 줄 뿐, 서버가 살아 있게 하거나 보안 패치를 해 주지는 않습니다.
4. "간단한 수정"이 분쟁이 되는 이유
가장 자주 부딪히는 지점이라 따로 다룹니다.
의뢰인이 "배너 이미지 하나 바꿔 주세요"라고 할 때 떠올리는 시간은 5분입니다. 실제로 이미지 교체 자체는 5분이 맞습니다.
그런데 실제로 일어나는 일은 이렇습니다.
- 요청 접수, 무엇을 어디로 바꾸는지 확인 — 10분
- 파일 받기. 크기가 안 맞아 다시 요청 — 10분
- 개발 환경 띄우기 — 5분
- 교체, 모바일 확인 — 10분
- 배포, 확인 — 10분
- 완료 회신, 확인 요청 — 5분
- "조금만 더 위로 올려 주세요" — 처음부터 다시
5분짜리 작업의 실제 소요는 대개 40분에서 1시간입니다. 그리고 이 구조는 업체가 비효율적이어서가 아니라, 작은 작업일수록 부대 시간의 비중이 커지기 때문입니다.
그래서 이런 방식들이 씁니다.
방식 A — 건수 제한. "월 5건 이내 포함, 초과 시 건당 OO원." 명확하지만 "이게 1건이냐 2건이냐"로 다시 다툽니다. 건의 정의를 붙여야 작동합니다. 예: "한 번의 요청으로 접수되어 한 번의 배포로 반영되는 단위".
방식 B — 시간 제한. "월 4시간 포함, 초과 시 시간당 OO원." 건수보다 공정합니다. 대신 투입 시간을 공유하는 절차가 필요합니다. 안 보이면 의심이 생깁니다.
방식 C — 묶어서 처리. "수정 요청은 모아서 격주 화요일에 반영." 부대 시간이 크게 줄어서 같은 값에 더 많이 처리됩니다. 급한 것만 예외로 두면 실무에서 가장 잘 굴러갑니다.
방식 D — 애초에 안 맡김. 관리자 화면에서 담당자가 직접 바꿉니다. 가장 싸고 가장 빠릅니다.
D가 가능한 범위를 구축 때 정해 두는 것이 유지보수 비용을 줄이는 가장 확실한 방법입니다. 다만 모든 것을 관리 가능하게 만들면 구축비가 올라가므로, 자주 바뀌는 것만 골라야 합니다. 배너·공지·담당자 연락처·가격표처럼요.
구축 견적을 받을 때 "무엇을 우리가 직접 바꿀 수 있습니까"를 묻고, 그 목록을 계약에 넣으십시오. 이 질문 하나가 3년치 유지보수비를 바꿉니다.
5. 과금 방식 세 가지
| 방식 | 유리한 상황 | 주의할 점 |
|---|---|---|
| 월 정액 | 변경이 꾸준히 있고 예산을 고정하고 싶을 때 | 아무 일 없는 달의 불만. 포함 범위를 명시해야 함 |
| 시간제(사용한 만큼) | 변경이 드물 때 | 급할 때 대응 순위가 밀릴 수 있음. 시간 기록 공유 필요 |
| 건당 | 요청이 명확하고 드물 때 | 매번 견적·승인 절차. 잔손질에 부적합 |
실무에서 가장 흔한 형태는 혼합입니다.
①②⑤는 월 정액으로 묶고, ③은 월 정액 안에 일정 시간(예: 4시간)을 포함하고, ④는 건별 견적.
이 구조가 양쪽에 안정적인 이유는, 고정비 성격의 항목과 변동비 성격의 항목을 분리하기 때문입니다. 2장의 표를 그대로 계약 구조로 옮긴 것입니다.
금액 감각은 어디서 오는가
정확한 요율은 업체 규모, 기술 스택, 대응 수준에 따라 갈립니다. 다만 계산 구조는 공통이라 감을 잡을 수 있습니다.
월 정액 ≈ (대기 비용) + (정기 작업 시간 × 요율) + (포함 작업 시간 × 요율) + (인프라 실비)
- 대기 비용은 "얼마나 빨리 응답하기로 했는가"에 비례합니다. 24시간 대응과 영업시간 대응은 몇 배 차이 납니다
- 정기 작업은 보안 갱신 주기에 비례합니다. 월 1회와 분기 1회는 다릅니다
- 포함 작업 시간이 실제로 협상되는 부분입니다
- 인프라 실비는 원가이므로 여기서 마진을 붙이는지 확인하십시오
견적을 받을 때 이 네 덩어리로 나눠 달라고 요청하면, 금액이 왜 그런지 읽힙니다. 그리고 비교 가능한 형태가 됩니다. 견적 자체를 비교 가능하게 정규화하는 방법은 같은 요구사항인데 견적이 세 배로 갈리는 이유에서 다룬 것과 같은 접근입니다.
주의할 신호: 월 정액이 비정상적으로 낮은데 포함 범위가 넓게 적혀 있는 견적입니다. 실제로는 대응이 느리거나, 초과 청구가 붙거나, 몇 달 뒤 계약이 조정됩니다.
6. 대응 수준을 문장으로 적기
"빠르게 대응하겠습니다"는 계약 문장이 아닙니다. 아래 네 가지를 숫자로 적습니다.
첫째, 접수 경로. 어디로 요청하면 접수된 것인가. 담당자 개인 카카오톡은 경로가 아닙니다. 그 사람이 자리를 비우면 접수가 안 됩니다. 메일 주소나 이슈 시스템처럼 여러 명이 보는 곳을 지정하십시오.
둘째, 응답 시간. 요청을 확인하고 회신하기까지의 시간입니다. 해결 시간이 아닙니다.
셋째, 착수·복구 목표 시간. 등급별로 나누는 편이 현실적입니다.
| 등급 | 정의 | 응답 | 착수 |
|---|---|---|---|
| 긴급 | 사이트 전체 접속 불가, 결제 불가 | 영업시간 내 1시간 | 즉시 |
| 높음 | 주요 기능 하나가 동작하지 않음 | 영업시간 내 4시간 | 당일 |
| 보통 | 일부 화면 오류, 표시 이상 | 1영업일 | 3영업일 내 |
| 낮음 | 문구·이미지 수정 요청 | 1영업일 | 정기 반영일 |
넷째, 대응 시간대. 평일 9~18시인지, 주말·공휴일이 포함되는지, 야간 긴급 연락 경로가 있는지. 24시간 대응은 비쌉니다. 정말 필요한지 따져 보십시오. 밤에 사이트가 멈추면 다음 날 아침까지 기다려도 되는 사업이 대부분입니다.
여기에 하나 더. 복구 목표를 "달성 보장"으로 적을 것인지 "노력 목표"로 적을 것인지를 정해야 합니다. 보장으로 적으면 미달성 시 감액 같은 조항이 따라붙어야 의미가 있고, 그러면 금액이 올라갑니다. 대부분의 중소 규모 사이트에서는 노력 목표로 적고 대신 등급 정의를 촘촘히 하는 편이 실용적입니다.
7. 계약서에서 확인할 목록
받은 유지보수 계약서를 아래 항목으로 훑어보십시오. 없는 항목이 나중에 문제가 됩니다. 계약 전에 업체에 그대로 물어볼 수 있는 질문 문장이 필요하다면 유지보수 계약서 8줄 체크리스트에 복사용으로 정리해 두었습니다.
범위
- 2장의 다섯 항목이 각각 포함/제외로 명시되어 있는가
- 포함되는 작업 시간 또는 건수가 숫자로 있는가
- 초과분의 단가가 적혀 있는가
- "기능 개선"과 "신규 개발"의 경계 기준이 있는가
대응
- 접수 경로가 개인이 아닌 곳으로 지정되어 있는가
- 등급별 응답·착수 시간이 있는가
- 대응 시간대와 휴일 처리가 있는가
- 담당자가 바뀔 때의 인수인계 규정이 있는가
보고
- 월 단위로 무엇을 했는지 보고받는가
- 사용한 시간이 공유되는가
- 장애가 났을 때 원인과 조치를 문서로 받는가
인프라
- 서버·도메인 명의가 우리인가
- 인프라 요금이 실비인가 마진이 붙는가
- 인증서·결제 수단 만료를 누가 관리하는가
데이터
- 백업 주기와 보관 기간이 있는가
- 우리가 데이터를 내려받을 수 있는가
- 개인정보 처리위탁 계약이 함께 되어 있는가
종료
- 계약 기간과 갱신 방식 (자동 갱신인지)
- 해지 통보 기간
- 종료 시 인계 범위 (다음 장)
마지막 묶음이 가장 자주 빠지고, 가장 아쉬울 때 필요합니다.
8. 끝날 때 돌려받아야 할 것
유지보수 계약은 언젠가 끝납니다. 업체를 바꾸든, 내부로 가져오든, 사이트를 새로 만들든.
그때 받아야 할 목록입니다. 계약서에 미리 적어 두지 않으면 협상 대상이 됩니다.
- 소스 코드 전체와 최신 상태의 저장소 접근 권한
- 배포에 필요한 설정 목록 — 환경변수의 이름 목록(값은 재발급 대상)
- 인프라 계정 소유권 — 서버, 도메인, DNS, 인증서, 외부 서비스
- 데이터베이스 전체 내보내기 — 표준 형식으로
- 업로드된 파일 일체 — 이미지, 첨부문서
- 관리자 계정 및 권한 체계 설명
- 운영 문서 — 배포 절차, 정기 작업 목록, 알려진 이슈
- 최근 1년치 장애·조치 이력
여기에 조항 하나를 더 넣기를 권합니다.
"계약 종료 시 수급인은 인계 목록을 제공하고, 도급인이 별도 환경에서 서비스를 기동할 수 있음을 확인하는 데 협조한다. 협조 기간은 종료일로부터 OO일로 한다."
**"기동할 수 있음을 확인"**이 핵심입니다. 파일만 받고 끝내면 나중에 못 띄웁니다. 실제로 한 번 띄워 보는 것까지가 인계입니다.
9. 그런데 유지보수 계약을 꼭 해야 하나
안 하는 선택지도 있습니다. 조건이 맞으면 합리적입니다.
안 해도 되는 경우
- 소개용 정적 사이트이고, 내용이 거의 안 바뀌며, 로그인·결제가 없다
- 사내에 코드를 읽을 수 있는 사람이 있다
- 멈춰도 하루 이틀은 견딜 수 있는 사업이다
이 경우 ②(보안 갱신)만 연 1~2회 별도 발주하는 형태로도 굴러갑니다.
해야 하는 경우
- 결제나 회원 기능이 있다
- 사이트가 멈추면 매출이 멈춘다
- 외부 서비스 연동이 여럿이다 (한쪽이 바뀌면 우리 쪽이 깨집니다)
- 사내에 코드를 볼 사람이 없다
특히 마지막 항목이 실질적인 기준입니다. 문제가 생겼을 때 "누구에게 전화하는가"에 이름이 없다면, 그 자리를 채우는 값이 유지보수비입니다.
그리고 유지보수를 안 하기로 했다면, 8장의 인계 목록만큼은 구축이 끝나는 시점에 받아 두십시오. 나중에 필요해졌을 때 연락이 닿지 않는 경우가 실제로 있습니다.
10. 결론
세 문장으로 정리합니다.
첫째, "월 얼마"는 범위를 정한 다음에 나오는 숫자입니다. 장애 대응, 보안 갱신, 콘텐츠 수정, 기능 개선, 인프라 관리는 성격이 다른 다섯 가지 일이고, 계약서에 다섯 줄로 들어가야 합니다. 한 줄로 적힌 유지보수 계약은 나중에 다섯 번 다툽니다.
둘째, 유지보수비를 가장 크게 줄이는 결정은 구축 단계에서 내려집니다. 자주 바뀌는 것을 담당자가 직접 바꿀 수 있게 만들어 두면, 매달 나가던 잔손질 비용이 사라집니다. 견적 단계에서 "무엇을 우리가 직접 바꿀 수 있습니까"를 묻는 것이 값을 깎는 것보다 효과가 큽니다.
셋째, 끝날 때를 시작할 때 적으십시오. 인계 목록과 협조 기간은 관계가 좋을 때만 쓸 수 있는 조항입니다. 계약이 잘 끝난다는 보장이 있어서 적는 것이 아니라, 그 보장이 없기 때문에 적는 것입니다.
유지보수를 포함한 3년 관점의 총비용이 방식별로 어떻게 갈리는지는 외주 개발의 총소유비용에 곡선으로 정리해 두었고, 대략의 구간을 직접 계산해 보고 싶다면 TCO 계산기에서 조건을 넣어 확인할 수 있습니다.