무상 유지보수와 기능 추가는 어떻게 구분할까?

웹사이트나 웹서비스가 공개된 뒤 수정 요청이 발생하면 의뢰사와 개발 업체 사이에 다음과 같은 의견 차이가 생길 수 있습니다.

의뢰사는 기존 기능을 제대로 사용할 수 있도록 고치는 일이므로 무상 유지보수라고 생각합니다.

반면 개발 업체는 계약에 없던 동작을 추가하거나 기존 구조를 바꾸는 일이므로 추가 개발이라고 판단할 수 있습니다.

예를 들면 다음과 같습니다.

• 모바일에서 버튼이 작으니 키워 달라.
• 관리자 검색 조건을 하나 더 넣어 달라.
• 결제 취소가 가능하도록 해 달라.
• 기존 문구를 바꿔 달라.
• 새로운 회원 등급을 추가해 달라.
• 외부 API 정책이 바뀌어 수정이 필요하다.

이 요청들이 모두 같은 종류는 아닙니다.

따라서 공개 후 지원 범위를 정할 때는 3개월 무상 유지보수라고만 쓰기보다 다음을 구분해야 합니다.

• 하자 또는 오류 수정
• 콘텐츠 변경
• 사용성 개선
• 기능 변경
• 신규 기능
• 외부 환경 변화 대응
• 서버 운영

먼저 용어를 구분해야 합니다

1. 하자보수 또는 오류 수정

합의한 기능이 요구사항과 다르게 작동하는 문제를 수정하는 것입니다.

예시:

• 로그인되지 않음
• 문의 이메일이 발송되지 않음
• 관리자에서 저장한 콘텐츠가 보이지 않음
• 결제 성공 후 권한이 지급되지 않음
• 합의한 모바일 화면이 깨짐
• 특정 버튼이 작동하지 않음

일반적으로 정해진 무상 오류 수정 기간 안에서 처리할 수 있습니다.

2. 콘텐츠 수정

기능은 정상적으로 작동하지만 들어가는 내용을 바꾸는 것입니다.

• 문구 변경
• 이미지 교체
• 팀원 추가
• 연락처 수정
• 가격표 수정
• 공지 등록

관리자에서 직접 수정할 수 있다면 의뢰사가 처리할 수 있습니다.

개발 업체가 대신 수정하면 유지보수 계약이나 건별 비용이 적용될 수 있습니다.

3. 기능 개선

기존 기능은 작동하지만 더 편리하게 바꾸는 것입니다.

• 버튼 위치 변경
• 검색 결과 정렬 개선
• 관리자 입력 단계 축소
• 오류 안내 문구 개선
• 모바일 사용성 개선
• 목록에 컬럼 추가

개선의 규모에 따라 유지보수에 포함되거나 별도 비용이 발생할 수 있습니다.

4. 기능 변경

기존에 합의한 동작을 다른 방식으로 바꾸는 것입니다.

기존 기능

운영 관리자가 모든 회원을 승인한다.

변경 요청

기업 관리자가 직원을 승인하고 운영 관리자는 기업만 승인한다.

단순 수정처럼 보이지만 권한과 데이터 구조가 달라질 수 있습니다.

기능 변경은 일반적으로 추가 개발로 보는 것이 자연스러울 수 있습니다.

5. 신규 기능

계약 범위에 없던 기능을 새로 추가하는 것입니다.

• 정기결제
• 소셜 로그인
• 알림톡
• 엑셀 업로드
• AI 기능
• 새로운 관리자 권한
• 통계 대시보드
• 외부 API

신규 기능은 별도 견적과 일정이 필요한 경우가 많습니다.

6. 운영 유지보수

서비스를 안정적으로 운영하기 위한 업무입니다.

• 서버 점검
• 백업
• SSL 갱신
• 로그 확인
• 장애 대응
• 보안 업데이트
• 플러그인 업데이트
• 모니터링

개발 하자와는 다른 종류의 업무입니다.

무상 오류 수정의 기준

다음 질문으로 판단할 수 있습니다.

1. 계약이나 요구사항에 포함된 기능인가?

포함되지 않았다면 신규 요청일 가능성이 높습니다.

2. 승인된 디자인과 다른가?

승인된 디자인에 있던 요소가 빠졌거나 다르게 구현됐다면 오류 수정에 가까울 수 있습니다.

3. 기능이 원래 정상적으로 작동해야 하는가?

정상 흐름과 일반적인 예외 처리 범위를 확인합니다.

4. 외부 환경이 바뀐 것인가?

개발 완료 후 외부 API나 브라우저 정책이 변경된 경우 개발 업체의 기존 오류라고 보기 어려울 수 있습니다.

5. 의뢰사가 운영 중 설정이나 데이터를 변경했는가?

관리자 실수나 임의 코드 수정으로 문제가 발생했다면 무상 범위에서 제외될 수 있습니다.

상황별 예시

애매한 사례 1: 모바일 버튼이 너무 작습니다

오류에 가까운 경우

• 승인된 모바일 디자인보다 작게 구현됨
• 버튼을 실제로 누르기 어려움
• 화면이 겹쳐 기능 사용이 불가능함
• 합의한 반응형 기준을 충족하지 못함

개선에 가까운 경우

• 기능 사용에는 문제가 없음
• 공개 후 디자인 취향이 바뀜
• 기존 승인 디자인보다 더 크게 변경 요청
• 새로운 UI 가이드 적용

승인된 디자인과 검수 기준이 중요합니다.

애매한 사례 2: 관리자 검색이 불편합니다

오류에 가까운 경우

• 합의한 이름 검색이 작동하지 않음
• 검색 결과가 잘못 나옴
• 필터 적용 시 오류 발생

기능 추가에 가까운 경우

• 회사명 검색 추가
• 여러 조건 조합 검색
• 검색 조건 저장
• 자동완성 추가
• 검색 결과 엑셀 다운로드

검색 기능이라는 한 단어만 합의했다면 해석 차이가 생길 수 있습니다.

초기에 검색 대상과 조건을 구체적으로 적어야 합니다.

애매한 사례 3: 결제 취소가 필요합니다

결제 기능이 있다고 해서 관리자 취소와 환불까지 자동으로 포함된다고 단정하기 어렵습니다.

다음 범위를 별도로 확인해야 합니다.

• 결제 성공
• 결제 실패
• 사용자 취소
• 관리자 취소
• 전체 환불
• 부분 환불
• 이용 권한 회수
• 정기결제 해지
• 환불 이력

기존 요구사항에 취소·환불이 없다면 추가 개발이 될 수 있습니다.

무상 유지보수 기간은 언제부터 시작할까?

다음 기준 중 하나로 정할 수 있습니다.

• 최종 검수 승인일
• 운영 서버 배포일
• 정식 서비스 공개일
• 잔금 지급일

기간 시작점이 불명확하면 분쟁이 생길 수 있습니다.

계약서에 날짜 기준을 명시하는 것이 좋습니다.

무상 기간에 포함할 수 있는 항목

- 계약 범위에 포함된 기능의 오류 수정
- 승인된 디자인과 다른 구현 수정
- 지원 브라우저에서 발생하는 화면 오류
- 개발 업체 코드로 인한 서버 오류
- 개발 업체 설정 오류

무상 범위에서 제외할 수 있는 항목

- 신규 기능
- 동작 방식 변경
- 콘텐츠 수정
- 의뢰사 또는 제3자의 코드 수정
- 관리자 오작동
- 외부 서비스 정책 변경
- 서버 요금 미납
- 지원 범위 밖 브라우저
- 운영 데이터 복구
- 트래픽 증가에 따른 성능 개선
- 보안 공격으로 인한 긴급 대응

프로젝트 특성에 따라 달라질 수 있습니다.

외부 서비스 변경은 누가 책임질까?

웹서비스는 다음 외부 시스템에 의존할 수 있습니다.

• 결제
• 지도
• 소셜 로그인
• 이메일
• 알림톡
• AI API
• 공공 데이터
• 클라우드
• 워드프레스 플러그인

개발 당시 정상적으로 연동됐지만 이후 외부 서비스가 API를 변경하면 코드 수정이 필요할 수 있습니다.

이 문제는 기존 개발 하자라기보다 운영 유지보수에 가까울 수 있습니다.

계약서에 외부 서비스 변경 대응의 비용과 범위를 정하는 것이 좋습니다.

브라우저와 운영체제 업데이트는 어떻게 처리할까?

서비스 공개 후 새로운 iOS, Android, Safari, Chrome 버전이 출시됩니다.

오래된 서비스에서 새 환경 문제가 발생할 수 있습니다.

다음 기준을 정할 수 있습니다.

• 공개 시점 주요 브라우저 지원
• 무상 기간 내 업데이트 대응
• 무상 기간 이후 별도 유지보수
• 지원 종료 브라우저 제외
• 대규모 구조 변경은 별도 견적

모든 기기에서 영구적으로 정상 작동 같은 조건은 현실적으로 모호합니다.

데이터 복구는 무상일까?

관리자가 실수로 데이터를 삭제하거나 사용자가 잘못 입력한 경우 개발 오류가 아닐 수 있습니다.

복구 가능 여부는 백업 구조에 따라 달라집니다.

• 소프트 삭제
• 변경 이력
• 자동 백업
• 수동 백업
• 복구 기간
• 데이터 보존 정책

데이터 복구가 중요한 서비스라면 개발 단계에서 기능과 운영 정책을 설계해야 합니다.

서버 장애는 무상일까?

서버 장애의 원인은 다양합니다.

개발 코드 문제

• 무한 반복
• 메모리 누수
• 잘못된 배포
• 데이터베이스 오류

개발 업체 책임 범위가 될 수 있습니다.

운영 환경 문제

• 서버 비용 미납
• 트래픽 급증
• 클라우드 장애
• 공격
• 저장 공간 부족
• 인증서 만료

운영 유지보수 계약에 따라 달라질 수 있습니다.

개발 계약과 서버 운영 계약을 구분하는 것이 좋습니다.

유지보수 요청을 분류하는 절차

1. 요청 접수

다음 정보를 받습니다.

• 발생 화면
• 현재 현상
• 기대 결과
• 발생 환경
• 재현 방법
• 첨부 자료

2. 원인 확인

• 기존 요구사항
• 개발 오류
• 운영 데이터
• 외부 서비스
• 신규 요청

3. 분류

• 무상 오류
• 콘텐츠 수정
• 유료 유지보수
• 기능 개선
• 신규 개발

4. 처리 일정과 비용 안내

무상이라도 즉시 수정 가능한지, 일정이 필요한지 안내합니다.

5. 수정과 검수

영향받은 기존 기능도 함께 확인합니다.

유지보수 요청 양식

요청 날짜:
요청자:

서비스 주소:
발생 화면:
사용 계정:
사용 환경:

현재 현상:
기대 결과:
재현 순서:
발생 빈도:
업무 영향:

첨부:
긴급도:

계약서에 구분해서 적으면 좋은 항목

하자보수

개발 업체는 검수 완료일로부터 3개월 동안 계약 범위에 포함된 기능의 개발 오류를 무상으로 수정한다.

제외 항목

신규 기능, 기능 변경, 콘텐츠 수정, 외부 서비스 정책 변경, 의뢰사의 설정 변경과 제3자 수정은 무상 오류 수정에서 제외할 수 있다.

기능 추가

새로운 기능과 기존 동작 변경은 개발 업체가 비용과 일정 영향을 안내하고, 양측이 합의한 후 진행한다.

운영 유지보수

서버 관리, 백업, 보안 업데이트, 외부 API 변경 대응은 별도의 유지보수 계약 범위에 따른다.

실제 계약 문구는 전문가와 검토하는 것이 안전합니다.

월 유지보수에 기능 추가를 포함할 수 있을까?

가능합니다.

다음 방식이 있습니다.

시간 포함형

월 20시간까지 오류·콘텐츠·소규모 개선 처리

요청 건수형

월 소규모 수정 5건 포함

업무 범위형

서버 관리와 오류 수정 포함
기능 추가는 별도 견적

시간 포함형은 유연하지만 우선순위와 사용 시간을 기록해야 합니다.

무상과 유상 구분 체크리스트

[ ] 계약 기능에 포함되어 있는가?
[ ] 승인된 디자인과 다른가?
[ ] 정상적으로 작동하지 않는가?
[ ] 공개 후 새로 요청한 동작인가?
[ ] 데이터 구조가 변경되는가?
[ ] 새로운 화면이 필요한가?
[ ] 외부 API가 변경되었는가?
[ ] 의뢰사가 설정을 변경했는가?
[ ] 제3자가 코드를 수정했는가?
[ ] 무상 지원 기간 안인가?

의뢰사가 비용 분쟁을 줄이는 방법

• 기능을 구체적으로 정의한다.
• 정상·실패 흐름을 함께 정한다.
• 관리자 기능을 별도로 적는다.
• 디자인을 단계별로 승인한다.
• 변경 요청을 문서로 남긴다.
• 검수 기간에 충분히 테스트한다.
• 유지보수 범위를 계약서에 적는다.
• 외부 서비스 책임을 확인한다.
• 소스와 계정을 인계받는다.

개발 업체가 분쟁을 줄이는 방법

• 포함·제외 범위를 설명한다.
• 기능별 완료 기준을 작성한다.
• 추가 요청 전에 비용을 안내한다.
• 오류와 개선을 구분해 설명한다.
• 처리 예정일을 공유한다.
• 외부 서비스 변경 가능성을 고지한다.
• 수정 내역을 기록한다.

마무리

무상 유지보수와 기능 추가를 구분하는 핵심 기준은 다음과 같습니다.

이미 합의한 기능이 제대로 작동하지 않는가, 아니면 기존에 없던 동작을 새로 원하는가?

• 합의 기능의 오류라면 무상 하자보수
• 문구와 이미지 변경이라면 콘텐츠 유지보수
• 사용성 개선이라면 범위에 따라 협의
• 동작 변경과 신규 기능이라면 추가 개발
• 외부 API와 서버 문제라면 운영 유지보수

계약 전에 이 기준을 명확히 정하면 공개 후 반복되는 비용과 책임 분쟁을 크게 줄일 수 있습니다.