유지보수 계약은 왜 필요한가?

유지보수 계약은 왜 필요한가?

외주 개발 프로젝트가 완료되면 웹사이트나 앱이 정상적으로 배포됩니다. 클라이언트가 최종 결과물을 검수하고 개발사가 소스코드와 운영 자료를 전달하면 프로젝트가 끝났다고 생각하기 쉽습니다.

하지만 서비스 운영은 이때부터 시작됩니다. 실제 사용자가 서비스를 이용하면 개발 과정에서는 발견되지 않았던 오류가 나타날 수 있습니다. 운영 정책이 바뀌거나 외부 서비스가 업데이트되고, 브라우저와 운영체제의 새로운 버전에 대응해야 할 수도 있습니다.

결제, 문자, 이메일, 지도처럼 서비스와 연결된 외부 시스템의 정책이나 API가 변경될 수도 있습니다. 보안 취약점이 발견되거나 서버 용량을 확인해야 하는 상황도 생깁니다.

이런 문제를 누가, 언제, 어떤 비용으로 처리할지 정하지 않으면 클라이언트와 개발사는 서로 다른 기대를 갖게 됩니다. 클라이언트는 개발 완료 후 발생한 문제이므로 무상으로 처리해야 한다고 생각할 수 있습니다. 개발사는 검수와 하자보수 기간이 끝났으므로 별도 작업이라고 판단할 수 있습니다.

유지보수 계약은 단순히 매달 개발비를 지급하는 계약이 아닙니다. 서비스 운영 중 발생할 수 있는 요청의 범위, 대응 우선순위, 응답 시간, 비용과 책임을 미리 정하는 운영 기준입니다.

이번 글에서는 유지보수 계약이 필요한 이유와 계약 전에 반드시 합의해야 할 항목을 알아보겠습니다.

1. 개발 완료와 서비스 운영은 다른 단계입니다

개발 프로젝트의 목표는 합의한 요구사항에 맞는 결과물을 만드는 것입니다. 반면 서비스 운영의 목표는 완성된 결과물이 실제 환경에서 계속 안정적으로 작동하도록 관리하는 것입니다.

개발 기간에는 정해진 테스트 환경과 시나리오를 기준으로 기능을 확인합니다. 서비스가 공개된 뒤에는 다양한 기기, 브라우저, 네트워크 환경과 예상하지 못한 사용자 행동이 추가됩니다.

운영 단계에서는 다음과 같은 일이 생길 수 있습니다.

• 특정 기기나 브라우저에서만 발생하는 오류
• 사용자 증가에 따른 서버 성능 저하
• 결제, 문자, 이메일 등 외부 API의 정책 변경
• 운영체제 또는 라이브러리 업데이트
• 보안 취약점과 개인정보 관련 대응
• 운영 과정에서 발견된 경미한 수정 요청
• 관리자 기능 사용 중 발생하는 문의

따라서 개발 프로젝트가 완료되었다고 해서 서비스에 더 이상 기술적인 작업이 필요하지 않은 것은 아닙니다.

2. 하자보수와 유지보수는 구분해야 합니다

유지보수 계약을 논의할 때 가장 먼저 구분해야 할 것은 하자보수와 유지보수입니다. 두 업무를 같은 의미로 사용하면 비용과 책임 범위에서 갈등이 생길 수 있습니다.

하자보수는 일반적으로 계약된 요구사항과 다르게 구현되었거나 정상적으로 작동하지 않는 부분을 수정하는 것입니다. 개발사의 구현 오류에 해당한다면 정해진 하자보수 기간 동안 무상으로 처리할 수 있습니다.

유지보수는 배포 이후 서비스를 안정적으로 운영하기 위해 필요한 지속적인 업무를 의미합니다. 환경 변화 대응, 운영 문의, 경미한 개선, 모니터링과 같은 작업이 포함될 수 있습니다.

예를 들어 아래는 하자보수에 가까울 수 있습니다.

• 계약된 기능이 요구사항대로 작동하지 않는 경우
• 승인된 디자인과 다르게 구현된 화면
• 검수 과정에서 확인하지 못한 기존 기능의 오류
• 개발사의 코드 문제로 발생한 서비스 장애

반면 아래는 유지보수 또는 추가 개발에 가까울 수 있습니다.

• 외부 API 변경에 따른 연동 수정
• 운영 정책 변경에 따른 문구와 조건 수정
• 새로운 브라우저나 운영체제 대응
• 관리자 사용 문의와 데이터 확인
• 새로운 기능이나 화면 추가

하자보수 기간과 유지보수 계약 기간, 각 업무의 범위를 별도로 명시해야 양쪽이 같은 기준으로 요청을 판단할 수 있습니다.

3. 장애 대응 기준을 정할 수 있습니다

서비스 장애는 발생 여부뿐 아니라 대응 속도가 중요합니다. 결제나 주문이 되지 않거나 서비스 전체에 접속할 수 없다면 사업 운영에 직접적인 피해가 생길 수 있습니다.

유지보수 계약에서는 장애의 심각도를 구분하고 단계별 대응 기준을 정할 수 있습니다.

• 긴급 장애: 서비스 전체 중단, 결제 불가, 보안 사고
• 중요 장애: 핵심 기능 일부를 다수의 사용자가 이용할 수 없는 상황
• 일반 오류: 일부 환경에서 발생하지만 우회 방법이 있는 문제
• 경미한 문제: 운영에 큰 영향을 주지 않는 표시 또는 편의성 문제

각 단계마다 접수 채널, 최초 응답 시간, 원인 파악 목표 시간, 진행 상황 공유 방식과 복구 우선순위를 정하는 것이 좋습니다.

중요한 것은 모든 장애의 해결 시간을 무조건 짧게 약속하는 것이 아닙니다. 먼저 문제를 확인하고 영향을 파악한 뒤 예상 대응 일정을 안내하는 기준을 만드는 것입니다.

4. 보안 업데이트를 지속적으로 관리할 수 있습니다

서비스에서 사용하는 운영체제, 프레임워크, 라이브러리와 외부 프로그램은 계속 업데이트됩니다. 시간이 지나면서 기존 버전에서 새로운 보안 취약점이 발견될 수도 있습니다.

유지보수 범위에는 아래와 같은 보안 관련 업무를 포함할 수 있습니다.

• 주요 라이브러리와 프레임워크의 보안 업데이트
• 서버 운영체제와 데이터베이스 업데이트 검토
• 접근 권한과 관리자 계정 점검
• SSL 인증서와 도메인 만료 확인
• 로그 및 비정상 접근 기록 점검
• 개인정보 처리와 저장 방식 확인
• 백업 상태와 복구 가능 여부 확인

모든 업데이트를 즉시 적용하는 것이 항상 안전한 것은 아닙니다. 업데이트가 기존 기능과 충돌할 수 있으므로 영향도를 확인하고 테스트한 뒤 적용해야 합니다.

정기적인 보안 점검 범위와 별도 전문 진단이 필요한 범위도 계약에서 구분하는 것이 좋습니다.

5. 경미한 수정의 범위를 명확히 할 수 있습니다

서비스를 운영하면 문구, 이미지, 링크, 노출 순서처럼 작은 수정 요청이 계속 발생할 수 있습니다. 각 요청은 짧아 보여도 요청 확인, 작업, 테스트, 배포 과정이 필요합니다.

유지보수 계약에서는 일정 범위의 경미한 수정을 포함할 수 있습니다. 다만 ‘간단한 수정’이라는 표현만으로는 포함 범위를 판단하기 어렵습니다.

경미한 수정 기준은 다음과 같이 정할 수 있습니다.

• 기존 화면의 문구나 링크 변경
• 이미지와 배너 교체
• 기존 설정값이나 노출 순서 변경
• 기존 기능의 작은 사용성 개선
• 월별 포함 작업 시간 또는 요청 건수

새로운 화면, 데이터 구조 변경, 외부 연동, 권한 구조 변경처럼 영향이 큰 작업은 추가 개발로 분리하는 것이 좋습니다.

경미한 수정과 추가 개발의 기준이 명확하면 클라이언트는 어떤 요청이 월 유지보수 비용에 포함되는지 알 수 있고, 개발사도 반복되는 무상 작업을 줄일 수 있습니다.

6. 운영 문의를 처리할 담당자를 정할 수 있습니다

운영 담당자가 관리자 기능을 사용하다 보면 데이터 확인, 계정 설정, 결제 처리, 알림 발송과 관련된 질문이 생길 수 있습니다.

이런 문의가 모두 오류를 의미하는 것은 아닙니다. 사용 방법에 대한 안내나 현재 데이터 상태를 확인하는 작업일 수 있습니다.

유지보수 계약에서는 다음과 같은 운영 지원 기준을 정할 수 있습니다.

• 문의 접수 채널과 담당자
• 지원 가능한 영업일과 시간
• 일반 문의의 예상 응답 시간
• 관리자 사용법 안내 범위
• 데이터 조회와 추출 지원 범위
• 월별 포함 지원 시간

문의 창구를 정하면 여러 개발자에게 요청이 흩어지는 문제를 줄일 수 있습니다. 요청과 답변 기록도 남길 수 있어 비슷한 문제가 반복될 때 이전 대응 내용을 확인하기 쉽습니다.

7. 외부 서비스 변경에 대응할 수 있습니다

웹사이트와 앱은 자체 코드만으로 운영되지 않는 경우가 많습니다. 결제, 로그인, 지도, 문자, 이메일, 알림, 분석 등 여러 외부 서비스를 사용합니다.

외부 서비스는 API 버전을 종료하거나 인증 방식을 변경할 수 있습니다. 요금제와 사용 정책이 바뀌거나 기존 기능을 더 이상 지원하지 않을 수도 있습니다.

유지보수 계약이 있으면 외부 서비스의 변경 공지를 확인하고 서비스에 미치는 영향을 검토할 담당자를 명확히 할 수 있습니다.

다만 대규모 API 전환이나 새로운 서비스 교체는 기존 유지보수 범위를 넘어설 수 있습니다. 정기 점검과 단순 설정 변경은 유지보수에 포함하고, 구조를 바꾸는 작업은 별도 견적으로 처리하는 기준이 필요합니다.

8. 유지보수 비용은 여러 방식으로 정할 수 있습니다

유지보수 계약은 프로젝트 특성에 따라 다양한 방식으로 구성할 수 있습니다.

• 월 정액형: 정해진 범위와 시간을 매월 제공
• 시간 차감형: 선구매한 작업 시간에서 실제 사용 시간을 차감
• 요청별 견적형: 요청이 발생할 때마다 범위와 비용을 산정
• 모니터링 포함형: 서버와 장애 모니터링을 기본으로 제공
• 긴급 대응형: 정해진 대응 시간과 우선순위를 보장

요청이 자주 발생하고 빠른 대응이 중요한 서비스라면 월 정액형이 적합할 수 있습니다. 변경이 거의 없는 소개형 웹사이트라면 요청별 견적 방식이 더 합리적일 수 있습니다.

유지보수 비용은 단순히 수정 건수만으로 결정되지 않습니다. 대응 가능 시간을 확보하고 서비스 구조를 계속 파악하며 긴급 상황에 대비하는 비용도 포함될 수 있습니다.

9. 계약서에 반드시 포함해야 할 항목이 있습니다

유지보수 계약에서 ‘운영 지원 일체’처럼 포괄적인 표현만 사용하면 양쪽의 기대가 달라질 수 있습니다.

최소한 아래 항목을 구체적으로 합의하는 것이 좋습니다.

• 유지보수 계약 기간과 갱신 조건
• 지원 대상 서비스와 환경
• 포함되는 업무와 제외되는 업무
• 하자보수와 유지보수의 구분
• 장애 등급과 우선순위
• 문의 접수 채널과 운영 시간
• 최초 응답 및 처리 목표 시간
• 월별 포함 시간과 초과 비용
• 추가 개발로 전환되는 기준
• 서버, 계정, 데이터에 대한 접근 권한
• 작업 및 승인 기록 방식
• 계약 종료 시 인수인계 방법

계약 내용이 구체적일수록 모든 요청을 두고 비용 포함 여부를 다시 협상하는 일을 줄일 수 있습니다.

10. 모든 프로젝트에 같은 유지보수 계약이 필요한 것은 아닙니다

유지보수 계약이 필요하다고 해서 모든 프로젝트가 동일한 월 정액 계약을 체결해야 하는 것은 아닙니다.

서비스의 중요도와 운영 방식에 따라 필요한 지원 수준이 달라집니다.

• 결제와 주문이 발생하는 서비스는 빠른 장애 대응이 중요합니다
• 개인정보를 다루는 서비스는 보안 점검이 중요합니다
• 내부 업무 시스템은 데이터 안정성과 운영 문의 대응이 중요합니다
• 소개형 웹사이트는 정기 업데이트와 요청별 수정만 필요할 수 있습니다
• 자체 개발팀이 있는 회사는 제한적인 기술 지원만 필요할 수 있습니다

필요한 지원 수준을 먼저 정하고 그에 맞는 유지보수 방식과 비용을 선택하는 것이 좋습니다.

유지보수 계약 전 체크리스트

1. 하자보수 기간과 범위를 확인한다
2. 유지보수에 포함할 서비스와 환경을 정한다
3. 장애의 심각도와 대응 우선순위를 구분한다
4. 문의 접수 채널과 지원 시간을 정한다
5. 최초 응답과 처리 목표 시간을 합의한다
6. 보안 업데이트와 정기 점검 범위를 정한다
7. 경미한 수정과 추가 개발의 기준을 구분한다
8. 월별 포함 시간과 초과 비용을 확인한다
9. 작업 요청과 승인 기록을 남길 방법을 정한다
10. 계약 종료 시 인수인계 방법을 정한다

유지보수 계약은 서비스 운영의 기대치를 맞추는 기준입니다

유지보수 계약의 목적은 모든 문제를 개발사에 맡기는 것이 아닙니다. 운영 중 어떤 문제가 발생했을 때 누가 확인하고, 어느 범위까지 지원하며, 비용과 일정은 어떻게 결정할지 미리 합의하는 것입니다.

기준이 없으면 작은 문의도 개발사에는 예상하지 못한 작업이 되고, 클라이언트에게는 답변을 받을 수 없는 불안한 상황이 됩니다.

반대로 유지보수 범위와 응답 기준이 명확하면 클라이언트는 필요한 지원을 예상할 수 있고, 개발사는 대응 인력과 일정을 안정적으로 준비할 수 있습니다.

런칭 후 운영 이슈도 프로젝트 기록으로 남겨야 합니다

서비스 운영 중 발생한 장애, 수정 요청, 보안 업데이트와 문의가 여러 채널에 흩어지면 같은 문제가 반복될 수 있습니다.

Pronika는 개발 이후의 유지보수 요청, 담당자, 진행 상태, 작업 결과, 파일과 승인 내역을 하나의 프로젝트 기록으로 연결할 수 있도록 돕습니다.

런칭 후 이슈까지 같은 흐름에서 관리하면 클라이언트와 개발사는 어떤 요청이 접수되었고 어떻게 처리되었는지 동일한 근거를 확인할 수 있습니다.