월 유지보수 계약을 맺은 회사에서 “배너 문구 하나 바꿔달라”고 요청했는데, 견적서가 날아왔습니다. 반대의 사례도 있습니다. “회원 등급 기능을 새로 추가해달라”는 요청에 개발사가 “유지보수 범위 안에서 처리하겠다”고 답했다가 몇 주째 진행이 안 되는 경우도 봤습니다. 두 상황 모두 원인은 같습니다. 계약서에 “단순 수정”과 “기능 추가”의 경계가 없었기 때문입니다.
유지보수 분쟁이 생기는 근본 원인
대부분의 유지보수 계약서에는 “월 O회 수정 지원”이라고만 적혀 있습니다. 여기서 “수정”이 무엇을 의미하는지 정의가 없다 보니, 발주사는 “돈을 내고 있으니 뭐든 되는 것”으로 이해하고, 개발사는 “간단한 것만 포함”이라고 이해합니다. 이 간극은 아래 상황에서 특히 자주 터집니다.
- 텍스트·이미지 교체 요청이 실제로는 레이아웃 구조를 바꿔야 하는 경우
- “간단한 기능 추가”라고 요청했지만 실제로는 새로운 데이터 구조가 필요한 경우
- 디자인 톤을 바꾸고 싶다는 요청이 전체 페이지 재작업으로 이어지는 경우
이 문제를 해결하려면 “수정”을 감정적으로 판단하지 않고, 아래처럼 작업 유형별로 명확히 구분해야 합니다.
단순 수정 vs 기능 추가, 구분 기준표
| 구분 | 단순 수정(유지보수 포함) | 기능 추가(별도 견적) |
|---|---|---|
| 텍스트 | 기존 문구를 다른 문구로 교체 | 새로운 섹션·페이지 신설 |
| 이미지 | 기존 위치의 이미지 교체(동일 규격) | 새로운 이미지 갤러리·업로드 기능 신설 |
| 배치 | 기존 구조 내 순서 변경 | 레이아웃 구조 자체를 새로 설계 |
| 폼 | 기존 입력 필드의 문구·필수 여부 변경 | 새로운 입력 필드·검증 로직 추가 |
| 데이터 | 기존 데이터 값 수정(오타, 가격 변경) | 새로운 데이터 항목·테이블 추가 |
| 연동 | 기존 연동 설정값 변경 | 신규 외부 서비스 연동 |
핵심 판단 기준은 “기존에 있던 것을 바꾸는가” vs “새로운 것을 만드는가”입니다. 이 기준을 계약서에 표로 명시해두면 매번 다투지 않고 바로 확인할 수 있습니다.
계약서에 넣어야 할 유지보수 범위 조항
실제 계약서에는 아래와 같은 문장을 포함하는 것을 권장합니다.
- “월 유지보수는 기존 화면·기능의 문구, 이미지, 값 수정을 포함하며, 신규 화면·기능·데이터 구조 추가는 별도 견적 대상이다”
- “건당 소요 시간이 O시간을 초과하는 작업은 사전 협의 후 진행한다”
- “월 수정 요청은 최대 O건까지 포함하며, 초과 시 건당 비용을 적용한다”
- “긴급 장애(사이트 다운, 결제 오류 등)는 유지보수 범위와 별개로 우선 대응한다”
애매한 요청이 들어왔을 때는 “이건 단순 수정인가, 기능 추가인가”를 계약서 조항 기준으로 판단하면 감정적 갈등을 줄일 수 있습니다.
월 유지보수비, 무엇을 기준으로 정해야 하는가
유지보수 비용은 흔히 “한 달에 얼마”로만 논의되지만, 실제로는 아래 요소에 따라 적정 범위가 달라집니다.
| 요소 | 영향 |
|---|---|
| 월 평균 수정 요청 건수 | 건수가 많을수록 정액제보다 시간 기준제가 유리할 수 있음 |
| 사이트 복잡도(연동 수, 기능 수) | 복잡할수록 장애 대응·점검에 걸리는 시간이 늘어남 |
| 응답 시간 요구 수준 | 당일 처리를 요구할수록 비용이 높아짐 |
| 보안·백업 관리 포함 여부 | 서버 관리까지 포함되면 별도 항목으로 산정해야 함 |
단순히 “다른 곳보다 싼가 비싼가”로 비교하기보다, 위 요소를 기준으로 우리 상황에 맞는 범위를 먼저 정하는 것이 합리적입니다.
유지보수 요청, 이렇게 전달하면 처리가 빨라진다
발주사가 요청을 명확하게 전달할수록 처리 속도와 정확도가 올라갑니다. 아래 형식을 활용하세요.
- 대상 위치 — 어느 페이지, 어느 영역인지 URL과 함께 명시
- 현재 상태 — 지금 어떻게 되어 있는지 캡처 첨부
- 원하는 상태 — 어떻게 바뀌어야 하는지 구체적으로 서술
- 희망 처리 기한 — 긴급 여부와 희망 완료일
“이거 좀 바꿔주세요”라는 요청은 개발사가 다시 질문해야 해서 오히려 처리가 늦어집니다. 요청 양식을 정해두면 주차별 스코프 검수와도 자연스럽게 연결됩니다.
기능 추가로 이어질 때 확인할 것
단순 수정 요청이 논의 중에 기능 추가로 커지는 경우가 흔합니다. 이때는 아래를 확인하세요.
- 추가되는 기능이 기존 데이터 구조에 새로운 항목을 필요로 하는가
- 추가 기능이 다른 화면·기능에 영향을 주는가(예: 등급 기능 추가 시 결제 로직 영향)
- 별도 견적이 필요하다면 정식 견적서를 받아 유지보수비와 분리해 처리
애매하게 “서비스로 해주다가” 시작된 기능 추가는 이후 비슷한 요청이 반복될 때마다 “저번엔 해줬잖아요”라는 마찰로 이어집니다. 처음부터 선을 명확히 하는 것이 장기적으로 양쪽 모두에게 유리합니다.
유지보수사를 바꿀 때 범위 기준도 함께 확인하라
유지보수 업체를 변경할 때는 이전 업체와의 범위 기준이 새 업체에도 그대로 이어지지 않을 수 있습니다. 다음을 반드시 재확인하세요.
- 이전에 “서비스로” 처리되던 작업이 새 업체에서는 유상일 수 있음
- 월 처리 건수·응답 시간 기준이 이전과 동일한지
- 기존에 구축된 커스텀 기능에 대한 이해도가 충분한지(인수인계 문서 필요)
담당자 교체와 함께 유지보수사도 바뀌는 상황이라면 소스코드 인수 및 관리자 권한 이관 방법을 함께 참고하시고, 새로운 유지보수 범위는 무료 견적요청을 통해 사전에 명확히 정의해두는 것을 권장합니다.
자주 묻는 질문 (FAQ)
월 유지보수 계약 없이 건별로 처리해도 괜찮나요? +
수정 요청이 드물다면 건별 처리도 가능합니다. 다만 매달 반복적으로 수정이 발생한다면 정액 유지보수 계약이 장기적으로 비용 효율이 높고, 응답 속도도 더 빠른 경우가 많습니다.
단순 수정인지 기능 추가인지 애매할 때는 누가 판단하나요? +
계약서에 기준표가 있다면 그 기준으로 우선 판단하고, 애매한 경우 개발사가 예상 소요 시간을 먼저 안내하도록 하는 것이 좋습니다. 판단이 계속 갈린다면 사전에 사례를 몇 가지 정리해 기준표에 추가하는 방법도 있습니다.
유지보수 건수를 다 못 채우면 다음 달로 이월되나요? +
계약 조건에 따라 다릅니다. 이월 가능 여부는 계약 시점에 명확히 협의하는 것이 좋으며, 이월이 안 되는 조건이라면 그만큼 초기 계약 건수를 실제 필요량에 맞게 조정하는 것이 합리적입니다.
긴급 장애도 유지보수 건수에 포함되나요? +
포함되지 않도록 계약서에 별도로 명시하는 것이 일반적입니다. 사이트 다운이나 결제 오류처럼 매출에 직접 영향을 주는 장애는 건수 소진과 무관하게 최우선으로 대응하는 조항을 두는 것이 안전합니다.
기능 추가 견적이 너무 비싸게 느껴질 때는 어떻게 하나요? +
견적에 포함된 작업 범위를 항목별로 요청해 확인하는 것이 우선입니다. 데이터 구조 변경이나 테스트 범위가 넓어 비용이 커지는 경우도 있으므로, 기능을 축소하거나 단계적으로 나눠 진행하는 대안도 함께 논의해볼 수 있습니다.