웹 개발 유지보수 계약, 장애 대응과 변경 작업을 나누는 기준

“로그인이 안 되는데, 유지보수 비용 안에서 바로 고쳐주는 건가요?”

“작은 문구 수정도 매번 별도 견적을 받아야 하나요?”

“장애가 났을 때 누가 언제까지 답하고 복구하는지 어떻게 확인하죠?”

유지보수 계약에서 먼저 정할 것은 월 비용이 아니라 기존 기능을 정상 상태로 되돌리는 일과 새 요구를 구현하는 일을 구분하는 기준입니다. 이 기준이 없으면 긴급한 복구 요청과 작은 개선 요청 모두가 비용과 책임을 다투는 일이 될 수 있습니다.

저는 개발자로 시작해 13년 이상 개발과 제품 운영을 해왔고, 법인을 운영하며 50건 이상의 SI 수탁개발을 진행했습니다. 운영 단계에서는 개발 완료 당시의 요구사항이 그대로 유지되지 않는 경우가 많았습니다. 그래서 계약 전에는 무엇이 고장인지부터 논의하기보다, 어떤 상태를 정상으로 볼지와 그 상태에서 무엇이 달라졌는지를 먼저 맞추는 편이 낫습니다.

장애 대응은 어떤 경우에 유지보수 범위가 되나요?

합의된 기존 기능이 의도한 방식으로 작동하지 않을 때 장애 대응으로 검토하는 것이 출발점입니다. 다만 초기 구축 명세와 현재 운영 환경을 함께 확인할 수 있어야 합니다.

이미 운영하던 로그인, 결제 요청, 관리자 권한, 문의 접수 기능이 이전과 달리 실패하거나 오류를 낸다면 원인 확인과 복구가 장애 대응 대상이 될 수 있습니다. 반대로 외부 서비스 정책 변경, 호스팅 인프라 장애, 운영자의 데이터 입력 오류까지 같은 방식으로 처리할지는 계약에서 따로 정해야 합니다.

장애라는 말만으로는 우선순위를 정하기 어렵습니다. 접수 채널, 최초 응답 목표, 상태 공유 방식, 복구 목표를 나누어 두면 담당자가 기대할 수 있는 범위가 분명해집니다. 여기서 응답은 문제 접수와 확인 시작을 뜻할 수 있고, 복구는 기능이 다시 동작하는 상태를 뜻할 수 있습니다. 두 기준을 한 문장에 묶지 않는 것이 중요합니다.

대규모 정보시스템 운영 사례에서도 애플리케이션, 인프라, 서비스데스크처럼 운영 대상을 나누고, 24시간 관제와 장애 대응, 재해복구 훈련을 별도 과업으로 두고 있습니다.

다만 이는 대규모 공공 금융 IT 운영 사례이므로, 일반 웹 서비스 계약의 운영 시간이나 목표 시간을 그대로 정하는 기준은 아닙니다. 소규모 서비스라면 우리 서비스에서 멈추면 안 되는 기능, 대응 가능한 시간대, 외부 인프라의 관리 주체를 먼저 정하는 방식이 현실적입니다.

변경 작업은 왜 별도 범위로 다뤄야 하나요?

기존에 합의한 동작을 복원하는 일이 아니라 화면, 규칙, 데이터, 연동 방식 중 하나를 새로 바꾸는 요청이라면 변경 작업으로 분리하는 편이 좋습니다.

버튼 하나를 추가하는 요청도 버튼 이후의 권한, 저장 데이터, 알림, 관리자 화면, 통계에 영향을 줄 수 있습니다. 따라서 작업량은 화면 수보다 바뀌는 규칙과 연결 기능의 범위로 판단해야 합니다.

유지보수 계약에 경미한 수정 시간을 포함할 수는 있습니다. 다만 경미함을 담당자의 인상으로 정하면 기준이 흔들립니다. 월 포함 시간, 수정 가능한 대상, 초과 시 견적과 승인 절차를 함께 적는 편이 낫습니다.

공공 금융기관의 통합 IT 운영 사례에서도 기존 시스템 운영과 함께 기능 개선이 별도 과업에 포함됩니다. 계약 전에는 애플리케이션 운영, 장애 대응, 기능 개선의 범위를 과업 목록으로 나누어 확인할 필요가 있습니다.

이 사례는 변경 요청의 영향 분석이나 승인 절차를 정해 주지는 않습니다. 그 절차는 서비스 구조와 계약 당사자의 권한에 맞춰 별도로 정해야 합니다.

다음 표는 계약서나 운영 가이드에 넣을 수 있는 분류 예시입니다. 실제 적용 전에는 구축 명세와 서비스 구조에 맞춰 조정해야 합니다.

계약서에는 어떤 문장을 남겨야 하나요?

유지보수 범위는 ‘수정한다’는 표현보다 접수, 판정, 승인, 배포, 확인의 순서로 적어야 운영에서 판단 기준으로 쓸 수 있습니다.

계약서가 모든 상황을 예측할 필요는 없습니다. 대신 애매한 요청이 들어왔을 때 누가 어떤 자료를 보고 판단하는지는 정해 두어야 합니다. 저는 프로젝트를 관리할 때 구현할 것과 구현하지 않을 것을 먼저 적는 브리프를 중요하게 봅니다. 유지보수에서도 같은 원칙이 적용됩니다.

특히 아래 다섯 가지는 한 문장씩이라도 남겨 두는 것이 좋습니다.

1. 기준 시점: 검수 완료 시점의 기능 명세, 화면, 연동 범위를 기준으로 삼습니다.
2. 접수 정보: 발생 시각, 재현 절차, 영향받는 사용자 범위, 오류 화면을 요청자가 전달합니다.
3. 분류 절차: 개발사는 장애, 운영 문의, 변경 작업, 외부 요인 여부를 확인해 결과를 알립니다.
4. 승인 방식: 변경 작업은 예상 범위, 일정, 비용을 확인받은 뒤 착수합니다.
5. 배포 확인: 수정 또는 변경 후 누가 어떤 환경에서 확인하는지 정합니다.

이 구조는 개발사의 책임을 피하기 위한 장치가 아닙니다. 기업 담당자가 요청에 필요한 정보를 준비하고, 대표가 월 유지비에 무엇이 포함되는지 관리하기 위한 운영 장치입니다.

다만 모든 요청을 개발사에 보내야 하는 것은 아닙니다. 관리자 페이지에서 담당자가 직접 바꾸도록 설계된 문구나 이미지라면 개발 유지보수보다 내부 운영 절차가 먼저입니다. 계약 전에는 관리자 권한으로 처리할 일과 개발사에 접수할 일을 함께 나누어 두는 것이 좋습니다.

장애 등급은 어떻게 현실적으로 정하나요?

장애 등급은 기술 난이도보다 사업 영향으로 나누고, 각 등급에 연락 방식과 임시 조치 기준을 연결해야 합니다.

모든 오류를 즉시 복구 대상으로 두면 서비스 전체가 멈췄을 때 대응 역량이 분산될 수 있습니다. 반대로 모든 문제를 다음 영업일 처리로 두면 운영 위험을 감당하기 어렵습니다. 중요한 것은 오류의 기술적 이름보다 매출, 고객 응대, 핵심 업무 처리에 미치는 영향입니다.

처음에는 세 단계로 시작할 수 있습니다.

• 긴급: 핵심 서비스 이용이 넓은 범위에서 불가능한 상태
• 높음: 일부 핵심 기능에 오류가 있으나 우회 방법이 있거나 영향 범위가 제한된 상태
• 일반: 기능 개선 요청, 사용 문의, 재현 조건이 불분명한 오류 제보

등급에는 고정된 정답이 없습니다. 제가 진행한 업무 시스템과 플랫폼 프로젝트에서도 같은 기능이라도 운영 주체와 이용 흐름에 따라 우선순위가 달랐습니다. 병원 예약처럼 이용자가 정해진 시간에 서비스를 써야 하는 경우와 사내 업무 시스템처럼 대체 절차가 있는 경우의 기준도 같을 수 없습니다. 업체의 등급표를 그대로 받기보다 우리 서비스에서 멈추면 안 되는 기능부터 표시하는 것이 먼저입니다.

결론

좋은 유지보수 계약은 월 비용에 많은 일을 넣는 계약이 아니라, 장애 복구와 변경 작업을 같은 기준으로 판정할 수 있게 적어 둔 계약입니다.

계약 전에는 아래 순서로 확인해 보세요.

1. 현재 정상으로 간주하는 기능과 화면은 무엇인가
2. 서비스가 멈췄다고 판단할 핵심 기능은 무엇인가
3. 장애 접수 때 전달할 정보와 응답 기준은 무엇인가
4. 새 기능이나 규칙 변경은 누가 어떤 방식으로 승인하는가
5. 관리자에서 직접 처리할 일과 개발사에 요청할 일을 어떻게 나눌 것인가

이 다섯 가지가 정리되면 장애가 발생했을 때는 복구에 집중하고, 개선이 필요할 때는 범위와 비용을 예측하며 대화할 수 있습니다. 유지보수 계약의 핵심은 모든 요청을 포함시키는 데 있지 않습니다. 운영 중 생기는 요청을 흔들리지 않고 분류하는 데 있습니다.

자주 묻는 질문

월 유지보수 비용에 기능 수정도 포함할 수 있나요?

포함할 수 있지만, 포함 시간과 수정 가능한 범위를 함께 정해야 합니다. 문구, 이미지, 단순 설정처럼 영향 범위가 작은 작업만 포함할지, 작은 화면 수정까지 포함할지를 명시하고 초과 작업의 승인 절차를 정하는 편이 좋습니다.

외부 솔루션 문제도 개발사가 고쳐야 하나요?

외부 솔루션의 장애나 정책 변경은 원인 확인과 대응 지원 범위를 별도로 정하는 것이 좋습니다. 개발사가 연동 상태를 확인하거나 대체 방안을 검토할 수는 있지만, 외부 사업자의 복구 시간까지 같은 조건으로 약속할 수 있는지는 계약 조건과 권한을 확인해야 합니다.

버그인지 변경 요청인지 바로 판단하기 어려우면 어떻게 하나요?

기존 검수 범위에서 기대한 동작과 실제 동작을 먼저 비교하면 됩니다. 이전에 합의한 동작이 깨졌다면 장애를 검토하고, 요구 자체가 새로 추가되거나 규칙이 바뀐다면 변경 작업으로 검토합니다. 재현 절차와 화면 기록을 함께 전달하면 판단에 도움이 됩니다.

유지보수 업체를 바꾸기 전에는 무엇을 받아야 하나요?

소스 코드, 배포 절차, 인프라 접근 권한, 도메인과 외부 서비스 계정의 관리 주체를 먼저 확인해야 합니다. 이 자료가 정리되지 않으면 새 업체도 장애 원인 파악과 변경 범위 산정에 시간이 더 필요할 수 있습니다.

제 도움이 필요하시다면

크로플은 웹과 앱, 업무 시스템 수탁개발과 프로젝트 관리를 수행해 왔습니다. 기존 서비스의 유지보수 범위를 정리하거나, 장애 대응 기준과 변경 요청 절차를 운영 문서로 정리해야 하는 경우 현재 기능 명세와 운영 흐름을 기준으로 함께 검토할 수 있습니다.

다음 상황이라면 문의 기능을 통해 현재 자료와 고민을 남겨 주세요.

• 개발 완료 뒤 운영 담당자와 개발사 사이의 요청 기준이 없는 경우
• 월 유지보수 비용에 포함할 업무와 별도 견적 업무를 정해야 하는 경우
• 새 기능 요청이 누적되어 우선순위와 릴리스 계획을 다시 나눠야 하는 경우

현재 계약서가 있어도 모든 조항을 한 번에 바꿀 필요는 없습니다. 실제로 자주 발생하는 요청 하나부터 분류 기준을 정리하는 방식으로 시작할 수 있습니다.