홈페이지 유지보수, 월 얼마가 정상인가 — 범위를 문장으로 고정하는 법

초록#

"홈페이지 유지보수 월 얼마가 적정한가"라는 질문에는 단일한 답이 없습니다. 금액이 아니라 범위가 정해지지 않았기 때문입니다. 유지보수라는 한 단어 안에는 장애 대응, 보안·의존성 갱신, 콘텐츠 수정, 소규모 기능 개선, 인프라 관리라는 성격이 전혀 다른 다섯 가지 작업이 들어 있고, 각각은 발생 빈도도 필요 역량도 원가 구조도 다릅니다. 이 글은 먼저 다섯 작업을 분해한 뒤, 계약 전에 반드시 갈라야 할 무상 하자보수와 유상 유지보수의 경계를 다룹니다. 이어서 "간단한 수정"이 왜 분쟁의 단골이 되는지를 원가 구조로 설명하고, 정액·시간제·건당이라는 세 가지 과금 방식이 각각 어떤 상황에서 유리한지 비교합니다. 그 다음 응답시간·복구 기준을 실제로 적을 수 있는 문장 형태로 제시하고, 마지막에 계약 종료 시 돌려받아야 할 것들을 목록으로 정리합니다. 특정 업체의 요율표는 다루지 않습니다.

1. 서론#

구축이 끝나면 이 대화가 옵니다.

"유지보수는 월 얼마로 하시나요?"

이 질문에 바로 숫자를 답하는 업체가 있다면, 그 숫자는 대개 두 가지 중 하나입니다. 아무것도 포함되지 않은 최소 금액이거나, 나중에 안 될 것을 알면서 부른 금액이거나.

문제는 이 질문이 가격 질문의 형태를 하고 있지만 실제로는 범위 질문이라는 데 있습니다. 그리고 양쪽이 서로 다른 것을 떠올린 채 계약합니다.

의뢰인이 떠올리는 유지보수:

"사이트에 문제 생기면 고쳐 주고, 배너 바꿔 달라고 하면 바꿔 주고, 페이지 하나쯤 추가해 주는 것."

업체가 떠올리는 유지보수:

"장애가 나면 복구하고, 보안 패치를 하고, 서버가 살아 있게 하는 것. 화면 수정은 별건."

이 간극이 3개월쯤 지나서 드러납니다. 그리고 그때는 이미 관계가 시작된 뒤라 조정이 어렵습니다. 계약 전에 문장으로 고정해야 하는 이유입니다.

2. 유지보수가 뭉뚱그리는 다섯 가지#

먼저 분해합니다. 이 다섯은 성격이 서로 아주 다릅니다.

① 장애 대응#

사이트가 안 열리거나, 기능이 동작하지 않거나, 데이터가 잘못 나오는 상황을 정상으로 되돌리는 일입니다.

• 빈도: 낮음. 잘 만든 사이트는 몇 달에 한 번도 없습니다
• 필요 역량: 높음. 원인을 찾아야 합니다
• 성격: 대기 비용입니다. 아무 일이 없어도 대응할 수 있는 상태를 유지하는 값

이 항목의 성격을 이해하는 것이 중요합니다. "이번 달에 아무 일도 안 했는데 왜 돈을 내느냐"는 질문이 여기서 나오는데, 소방서가 화재가 없는 달에도 유지되는 것과 같은 구조입니다. 아무 일도 없었다는 것이 성과인 항목입니다.

② 보안·의존성 갱신#

외부 패키지, 프레임워크, 서버 소프트웨어를 최신 상태로 유지하는 일입니다.

• 빈도: 정기적. 월 1회 또는 분기 1회
• 필요 역량: 중간~높음. 올리면 깨지는 것을 확인해야 합니다
• 성격: 미루면 이자가 붙습니다. 2년을 미루면 한 번에 올리기 어려워집니다

이 항목이 계약에서 자주 빠집니다. 그리고 안 해도 당장은 아무 일이 없어서, 빠졌다는 사실도 몇 년간 드러나지 않습니다. 드러날 때는 대개 사고입니다.

③ 콘텐츠 수정#

배너 교체, 문구 변경, 게시물 등록, 이미지 교체, 담당자 정보 수정.

• 빈도: 높음. 매주 있을 수도 있습니다
• 필요 역량: 낮음
• 성격: 작업량에 비례합니다. 위 두 항목과 완전히 다른 성격

여기서 분쟁의 대부분이 나옵니다. 뒤에서 따로 다룹니다.

그리고 이 항목은 애초에 발생하지 않게 만들 수 있습니다. 관리자 화면을 통해 담당자가 직접 바꿀 수 있게 해 두면 됩니다. 구축 단계에서 결정할 일이고, 이 결정이 유지보수 비용을 가장 크게 좌우합니다.

④ 소규모 기능 개선#

페이지 추가, 폼 항목 변경, 목록에 필터 추가, 통계 화면 하나 만들기.

• 빈도: 사업 변화에 따라
• 필요 역량: 높음. 개발입니다
• 성격: 이건 유지보수가 아니라 개발입니다. 규모가 작을 뿐

가장 자주 다투는 경계선입니다. 의뢰인은 "간단한 거니까 유지보수에 포함"이라고 보고, 업체는 "새로 만드는 것이니 별건"이라고 봅니다. 둘 다 일리가 있어서 사전에 정하지 않으면 매번 협상하게 됩니다.

⑤ 인프라 관리·비용#

서버, 도메인, 인증서, 스토리지, 외부 서비스 요금.

• 빈도: 상시
• 성격: 실비 + 관리 시간

여기서 확인할 것은 누구 명의로 가입되어 있고 누구 카드로 결제되는가입니다. 업체 계정으로 묶여 있으면 나갈 때 문제가 됩니다. 가능하면 우리 명의, 우리 결제로 두고 업체에 권한을 주는 형태가 낫습니다.

정리#

계약서에는 이 다섯 줄이 각각 들어가야 합니다. "유지보수 월 OO원"이라는 한 줄로는 어떤 것도 정해지지 않습니다.

3. 무상 하자보수와 유상 유지보수는 다른 것이다#

이 구분을 안 하고 시작하면 초기 몇 달이 계속 어색합니다.

하자보수는 납품한 것이 계약한 대로 동작하지 않을 때 고치는 것입니다. 처음부터 잘못 만든 것을 바로잡는 일이므로 원칙적으로 무상입니다.

유지보수는 정상적으로 동작하는 것을 계속 정상으로 유지하고, 변화에 맞춰 손보는 일입니다. 유상입니다.

경계가 애매한 예를 몇 개 놓고 보면 감이 잡힙니다.

계약서에 넣을 것은 두 가지입니다.

첫째, 무상 하자보수 기간. 공공 부문 계약에는 별도의 기준이 적용되는 경우가 있으나, 민간 계약에서는 당사자가 정하는 것이 원칙입니다. 국내 실무에서는 검수 완료 후 3개월에서 12개월 사이가 흔하고, 6개월이 가장 자주 보입니다. 짧게 잡는 대신 그 기간에 확실히 대응받는 편이 나을 수도 있으니, 기간의 길이보다 그 기간에 무엇이 포함되는지를 더 신경 쓰십시오.

둘째, 하자의 정의. "계약서와 요구사항 정의서에 기재된 동작과 다른 경우"처럼 기준 문서를 명시합니다. 기준 문서가 없으면 하자 판정이 매번 말싸움이 됩니다. 이 지점은 요구사항 정의가 애초에 얼마나 촘촘했는지에 달려 있습니다. 발주 초기에 만든 요구사항 정의서가 나중에 하자 판정의 기준 문서로 그대로 쓰입니다.

하자보수 기간에도 유지보수 계약이 필요한가라는 질문이 자주 나옵니다. 답은 "①②⑤는 필요하고 ③④는 필요 없을 수 있다"입니다. 하자보수는 잘못 만든 것을 고쳐 줄 뿐, 서버가 살아 있게 하거나 보안 패치를 해 주지는 않습니다.

4. "간단한 수정"이 분쟁이 되는 이유#

가장 자주 부딪히는 지점이라 따로 다룹니다.

의뢰인이 "배너 이미지 하나 바꿔 주세요"라고 할 때 떠올리는 시간은 5분입니다. 실제로 이미지 교체 자체는 5분이 맞습니다.

그런데 실제로 일어나는 일은 이렇습니다.

1. 요청 접수, 무엇을 어디로 바꾸는지 확인 — 10분
2. 파일 받기. 크기가 안 맞아 다시 요청 — 10분
3. 개발 환경 띄우기 — 5분
4. 교체, 모바일 확인 — 10분
5. 배포, 확인 — 10분
6. 완료 회신, 확인 요청 — 5분
7. "조금만 더 위로 올려 주세요" — 처음부터 다시

5분짜리 작업의 실제 소요는 대개 40분에서 1시간입니다. 그리고 이 구조는 업체가 비효율적이어서가 아니라, 작은 작업일수록 부대 시간의 비중이 커지기 때문입니다.

그래서 이런 방식들이 씁니다.

방식 A — 건수 제한. "월 5건 이내 포함, 초과 시 건당 OO원." 명확하지만 "이게 1건이냐 2건이냐"로 다시 다툽니다. 건의 정의를 붙여야 작동합니다. 예: "한 번의 요청으로 접수되어 한 번의 배포로 반영되는 단위".

방식 B — 시간 제한. "월 4시간 포함, 초과 시 시간당 OO원." 건수보다 공정합니다. 대신 투입 시간을 공유하는 절차가 필요합니다. 안 보이면 의심이 생깁니다.

방식 C — 묶어서 처리. "수정 요청은 모아서 격주 화요일에 반영." 부대 시간이 크게 줄어서 같은 값에 더 많이 처리됩니다. 급한 것만 예외로 두면 실무에서 가장 잘 굴러갑니다.

방식 D — 애초에 안 맡김. 관리자 화면에서 담당자가 직접 바꿉니다. 가장 싸고 가장 빠릅니다.

D가 가능한 범위를 구축 때 정해 두는 것이 유지보수 비용을 줄이는 가장 확실한 방법입니다. 다만 모든 것을 관리 가능하게 만들면 구축비가 올라가므로, 자주 바뀌는 것만 골라야 합니다. 배너·공지·담당자 연락처·가격표처럼요.

구축 견적을 받을 때 "무엇을 우리가 직접 바꿀 수 있습니까"를 묻고, 그 목록을 계약에 넣으십시오. 이 질문 하나가 3년치 유지보수비를 바꿉니다.

5. 과금 방식 세 가지#

실무에서 가장 흔한 형태는 혼합입니다.

①②⑤는 월 정액으로 묶고, ③은 월 정액 안에 일정 시간(예: 4시간)을 포함하고, ④는 건별 견적.

이 구조가 양쪽에 안정적인 이유는, 고정비 성격의 항목과 변동비 성격의 항목을 분리하기 때문입니다. 2장의 표를 그대로 계약 구조로 옮긴 것입니다.

금액 감각은 어디서 오는가#

정확한 요율은 업체 규모, 기술 스택, 대응 수준에 따라 갈립니다. 다만 계산 구조는 공통이라 감을 잡을 수 있습니다.

월 정액 ≈ (대기 비용) + (정기 작업 시간 × 요율) + (포함 작업 시간 × 요율) + (인프라 실비)

• 대기 비용은 "얼마나 빨리 응답하기로 했는가"에 비례합니다. 24시간 대응과 영업시간 대응은 몇 배 차이 납니다
• 정기 작업은 보안 갱신 주기에 비례합니다. 월 1회와 분기 1회는 다릅니다
• 포함 작업 시간이 실제로 협상되는 부분입니다
• 인프라 실비는 원가이므로 여기서 마진을 붙이는지 확인하십시오

견적을 받을 때 이 네 덩어리로 나눠 달라고 요청하면, 금액이 왜 그런지 읽힙니다. 그리고 비교 가능한 형태가 됩니다. 견적 자체를 비교 가능하게 정규화하는 방법은 같은 요구사항인데 견적이 세 배로 갈리는 이유에서 다룬 것과 같은 접근입니다.

주의할 신호: 월 정액이 비정상적으로 낮은데 포함 범위가 넓게 적혀 있는 견적입니다. 실제로는 대응이 느리거나, 초과 청구가 붙거나, 몇 달 뒤 계약이 조정됩니다.

6. 대응 수준을 문장으로 적기#

"빠르게 대응하겠습니다"는 계약 문장이 아닙니다. 아래 네 가지를 숫자로 적습니다.

첫째, 접수 경로. 어디로 요청하면 접수된 것인가. 담당자 개인 카카오톡은 경로가 아닙니다. 그 사람이 자리를 비우면 접수가 안 됩니다. 메일 주소나 이슈 시스템처럼 여러 명이 보는 곳을 지정하십시오.

둘째, 응답 시간. 요청을 확인하고 회신하기까지의 시간입니다. 해결 시간이 아닙니다.

셋째, 착수·복구 목표 시간. 등급별로 나누는 편이 현실적입니다.

넷째, 대응 시간대. 평일 9~18시인지, 주말·공휴일이 포함되는지, 야간 긴급 연락 경로가 있는지. 24시간 대응은 비쌉니다. 정말 필요한지 따져 보십시오. 밤에 사이트가 멈추면 다음 날 아침까지 기다려도 되는 사업이 대부분입니다.

여기에 하나 더. 복구 목표를 "달성 보장"으로 적을 것인지 "노력 목표"로 적을 것인지를 정해야 합니다. 보장으로 적으면 미달성 시 감액 같은 조항이 따라붙어야 의미가 있고, 그러면 금액이 올라갑니다. 대부분의 중소 규모 사이트에서는 노력 목표로 적고 대신 등급 정의를 촘촘히 하는 편이 실용적입니다.

7. 계약서에서 확인할 목록#

받은 유지보수 계약서를 아래 항목으로 훑어보십시오. 없는 항목이 나중에 문제가 됩니다. 계약 전에 업체에 그대로 물어볼 수 있는 질문 문장이 필요하다면 유지보수 계약서 8줄 체크리스트에 복사용으로 정리해 두었습니다.

범위

• 2장의 다섯 항목이 각각 포함/제외로 명시되어 있는가
• 포함되는 작업 시간 또는 건수가 숫자로 있는가
• 초과분의 단가가 적혀 있는가
• "기능 개선"과 "신규 개발"의 경계 기준이 있는가

대응

• 접수 경로가 개인이 아닌 곳으로 지정되어 있는가
• 등급별 응답·착수 시간이 있는가
• 대응 시간대와 휴일 처리가 있는가
• 담당자가 바뀔 때의 인수인계 규정이 있는가

보고

• 월 단위로 무엇을 했는지 보고받는가
• 사용한 시간이 공유되는가
• 장애가 났을 때 원인과 조치를 문서로 받는가

인프라

• 서버·도메인 명의가 우리인가
• 인프라 요금이 실비인가 마진이 붙는가
• 인증서·결제 수단 만료를 누가 관리하는가

데이터

• 백업 주기와 보관 기간이 있는가
• 우리가 데이터를 내려받을 수 있는가
• 개인정보 처리위탁 계약이 함께 되어 있는가

종료

• 계약 기간과 갱신 방식 (자동 갱신인지)
• 해지 통보 기간
• 종료 시 인계 범위 (다음 장)

마지막 묶음이 가장 자주 빠지고, 가장 아쉬울 때 필요합니다.

8. 끝날 때 돌려받아야 할 것#

유지보수 계약은 언젠가 끝납니다. 업체를 바꾸든, 내부로 가져오든, 사이트를 새로 만들든.

그때 받아야 할 목록입니다. 계약서에 미리 적어 두지 않으면 협상 대상이 됩니다.

• 소스 코드 전체와 최신 상태의 저장소 접근 권한
• 배포에 필요한 설정 목록 — 환경변수의 이름 목록(값은 재발급 대상)
• 인프라 계정 소유권 — 서버, 도메인, DNS, 인증서, 외부 서비스
• 데이터베이스 전체 내보내기 — 표준 형식으로
• 업로드된 파일 일체 — 이미지, 첨부문서
• 관리자 계정 및 권한 체계 설명
• 운영 문서 — 배포 절차, 정기 작업 목록, 알려진 이슈
• 최근 1년치 장애·조치 이력

여기에 조항 하나를 더 넣기를 권합니다.

"계약 종료 시 수급인은 인계 목록을 제공하고, 도급인이 별도 환경에서 서비스를 기동할 수 있음을 확인하는 데 협조한다. 협조 기간은 종료일로부터 OO일로 한다."

"기동할 수 있음을 확인"이 핵심입니다. 파일만 받고 끝내면 나중에 못 띄웁니다. 실제로 한 번 띄워 보는 것까지가 인계입니다.

9. 그런데 유지보수 계약을 꼭 해야 하나#

안 하는 선택지도 있습니다. 조건이 맞으면 합리적입니다.

안 해도 되는 경우

• 소개용 정적 사이트이고, 내용이 거의 안 바뀌며, 로그인·결제가 없다
• 사내에 코드를 읽을 수 있는 사람이 있다
• 멈춰도 하루 이틀은 견딜 수 있는 사업이다

이 경우 ②(보안 갱신)만 연 1~2회 별도 발주하는 형태로도 굴러갑니다.

해야 하는 경우

• 결제나 회원 기능이 있다
• 사이트가 멈추면 매출이 멈춘다
• 외부 서비스 연동이 여럿이다 (한쪽이 바뀌면 우리 쪽이 깨집니다)
• 사내에 코드를 볼 사람이 없다

특히 마지막 항목이 실질적인 기준입니다. 문제가 생겼을 때 "누구에게 전화하는가"에 이름이 없다면, 그 자리를 채우는 값이 유지보수비입니다.

그리고 유지보수를 안 하기로 했다면, 8장의 인계 목록만큼은 구축이 끝나는 시점에 받아 두십시오. 나중에 필요해졌을 때 연락이 닿지 않는 경우가 실제로 있습니다.

10. 결론#

세 문장으로 정리합니다.

첫째, "월 얼마"는 범위를 정한 다음에 나오는 숫자입니다. 장애 대응, 보안 갱신, 콘텐츠 수정, 기능 개선, 인프라 관리는 성격이 다른 다섯 가지 일이고, 계약서에 다섯 줄로 들어가야 합니다. 한 줄로 적힌 유지보수 계약은 나중에 다섯 번 다툽니다.

둘째, 유지보수비를 가장 크게 줄이는 결정은 구축 단계에서 내려집니다. 자주 바뀌는 것을 담당자가 직접 바꿀 수 있게 만들어 두면, 매달 나가던 잔손질 비용이 사라집니다. 견적 단계에서 "무엇을 우리가 직접 바꿀 수 있습니까"를 묻는 것이 값을 깎는 것보다 효과가 큽니다.

셋째, 끝날 때를 시작할 때 적으십시오. 인계 목록과 협조 기간은 관계가 좋을 때만 쓸 수 있는 조항입니다. 계약이 잘 끝난다는 보장이 있어서 적는 것이 아니라, 그 보장이 없기 때문에 적는 것입니다.

유지보수를 포함한 3년 관점의 총비용이 방식별로 어떻게 갈리는지는 외주 개발의 총소유비용에 곡선으로 정리해 두었고, 대략의 구간을 직접 계산해 보고 싶다면 TCO 계산기에서 조건을 넣어 확인할 수 있습니다.