SI 유지보수 계약서에 장애와 변경 요청을 기록하는 4가지 항목

“서비스가 멈췄는데, 이 일이 무상 장애 대응인지 추가 개발인지 어떻게 판단하죠?”

“급한 요청을 보냈는데 언제 누가 답하는지 계약서에서 찾기 어렵습니다.”

“작은 수정이 계속 쌓이는데, 어디까지 유지보수 비용에 포함되는지 모르겠습니다.”

유지보수 계약의 핵심은 장애와 변경 요청을 구분하고, 각각의 접수, 판단, 승인 절차를 문서로 남기는 데 있습니다. 넓은 표현으로 범위를 덮기보다 운영 중 실제로 생기는 요청을 어느 절차로 처리할지 정해야 비용과 일정 판단이 흔들리지 않습니다.

운영 중에는 복구가 먼저 필요한 문제와 기능 또는 정책을 바꿔야 하는 요청이 한 대화 안에서 섞이기 쉽습니다. 이 글의 기준은 하나입니다. 계약과 기능 명세에서 약속한 동작을 회복하는 일은 장애 대응으로, 그 기준 동작을 바꾸는 일은 변경 요청으로 기록합니다.

저는 개발자로 시작해 13년 이상 IT 업계에서 일했고, 2020년 설립한 법인을 통해 50건 이상의 SI 수탁개발을 수행해 왔습니다. 웹, 앱, 업무 시스템을 운영하는 과정에서 유지보수 문서는 개발사의 업무를 제한하는 장치만이 아니라, 운영 담당자가 긴급한 상황에서 판단을 미루지 않게 하는 공동 기준이라고 봅니다.

왜 장애 대응과 변경 요청을 먼저 나눠야 할까요?

장애 대응은 약속된 서비스 상태를 회복하는 일이고, 변경 요청은 현재의 동작이나 범위를 바꾸는 일로 기록해야 합니다. 같은 화면에서 생긴 요청이어도 기준 동작이 무엇인지에 따라 처리 경로와 비용 판단이 달라집니다.

예를 들어 로그인이 되지 않거나 기존에 제공하던 조회 결과가 나오지 않는 문제는 장애로 검토할 수 있습니다. 반면 로그인 방식 추가, 조회 조건 추가, 정책 변경에 따른 관리자 기능 보완은 변경 요청 검토가 필요할 수 있습니다.

다만 화면 이름이나 요청자의 긴급도만으로 구분해서는 안 됩니다. 계약 당시 합의한 기능 명세, 운영 정책, 최근 배포 이력을 함께 확인해야 합니다. 특히 외부 연동 서비스의 설정, 고객사 데이터 입력, 인프라 권한처럼 개발사가 단독으로 통제하기 어려운 조건도 문서에 남겨야 합니다.

구분을 위한 첫 질문은 기준 동작입니다

요청을 받은 담당자는 먼저 아래 질문에 답할 수 있어야 합니다.

• 계약서나 기능 명세에서 약속한 동작은 무엇인가
• 문제가 재현되는 환경과 계정 권한은 무엇인가
• 언제부터 어떤 사용자와 업무가 영향을 받는가
• 복구만 하면 되는가, 정책이나 기능을 바꿔야 하는가

기준 동작이 문서에 없다면 장애인지 변경인지 바로 단정하기 어렵습니다. 이때는 우선 서비스 영향과 임시 조치 필요 여부를 기록하고, 범위 판정은 담당자 협의 항목으로 남기는 편이 좋습니다. 복구를 지연시키지 않으면서도 추가 작업의 승인 여부를 분리할 수 있기 때문입니다.

계약서에는 어떤 장애 대응 기준을 적어야 할까요?

장애 조항에는 접수 채널, 우선순위 판단 기준, 최초 응답과 복구의 의미, 고객사의 협조 사항을 함께 적어야 합니다. “긴급 장애는 신속히 대응한다”는 문구만으로는 운영 담당자가 무엇을 기대하고 무엇을 제공해야 하는지 알기 어렵습니다.

SLA는 서비스 수준 협약을 뜻합니다. 계약서에 이 용어를 넣는 것보다 실제 연락과 작업 흐름에 맞춰 서비스 대상, 지원 시간, 응답 방식, 결과 공유 방식을 정의하는 편이 중요합니다. 목표 시간을 정한다면 그 시간이 접수 확인인지, 원인 안내인지, 임시 조치인지, 완전 복구인지를 분명히 나누어야 합니다.

다음 네 항목은 계약서 본문이나 부속 문서에서 별도로 관리할 만합니다.

특히 최초 응답 시간과 복구 시간을 같은 의미로 쓰지 않는 편이 좋습니다. 최초 응답은 요청 확인과 담당자 배정을 뜻할 수 있지만, 복구에는 원인 확인과 영향 범위 점검, 테스트가 더 필요할 수 있습니다. 운영 담당자에게 필요한 것은 짧은 숫자만이 아니라 각 단계에서 어떤 안내를 받는지입니다.

변경 요청은 어떻게 접수하고 승인해야 할까요?

변경 요청은 요청 내용, 배경, 영향 범위, 비용과 일정, 승인 기록을 하나의 단위로 남겨야 합니다. 메신저의 짧은 요청만으로 작업을 시작하면 완료 기준과 유지보수 포함 여부가 뒤늦게 달라질 수 있습니다.

변경은 큰 기능 추가만 뜻하지 않습니다. 화면 문구 수정도 다른 화면, 알림, 관리자 기능, 데이터 처리 규칙에 영향을 줄 수 있습니다. 반대로 데이터 수정이나 운영자 안내처럼 개발 작업 없이 해결되는 요청도 있습니다. 그래서 접수 단계에서는 구현 방법을 먼저 확정하기보다 요청의 목적과 원하는 완료 상태를 받는 것이 좋습니다.

제가 SI 프로젝트를 관리할 때 변경 요청은 다음 순서로 정리합니다.

1. 요청 등록: 바꾸려는 대상, 요청 배경, 원하는 완료 상태를 적습니다.
2. 영향 확인: 화면, 데이터, 권한, 외부 연동, 테스트 범위를 검토합니다.
3. 처리안 제시: 유지보수 포함 여부, 별도 견적 여부, 일정과 전제 조건을 제안합니다.
4. 승인 기록: 승인자, 비용, 일정, 완료 기준을 남긴 뒤 작업을 시작합니다.

변경 요청은 구현 지시가 아니라 완료 기준과 승인 기록으로 관리해야 합니다.

모든 문구 수정에 긴 결재 절차를 만들자는 뜻은 아닙니다. 경미한 수정의 범위와 월간 처리 한도를 계약에서 따로 정하면 반복 운영 요청은 짧은 절차로 처리할 수 있습니다. 반대로 권한, 결제, 개인정보 처리, 외부 연동처럼 영향이 큰 변경은 별도 검토와 테스트 조건을 두는 편이 낫습니다.

문서가 있어도 범위 다툼이 생기는 이유는 무엇일까요?

문서가 추상적이거나 최신 상태가 아니면 계약 조항보다 구두 합의와 메신저 기록이 앞서게 됩니다. 범위 다툼을 줄이려면 문서의 양보다 기준 문서의 우선순위와 갱신 책임을 정해야 합니다.

계약서 본문에는 큰 원칙을, 부속 문서에는 서비스 목록과 지원 시간을, 요청 관리 도구에는 개별 이력을 두는 방식이 실무에서 관리하기 좋습니다. 하나의 기준 문서를 정하고 계약서, 요청서, 운영 기록이 이를 참조하게 하면 같은 요청을 서로 다르게 해석할 가능성을 줄일 수 있습니다.

운영을 시작한 뒤에는 미해결 요청과 반복 장애를 정기적으로 함께 검토할 수 있습니다. 이때 목적은 책임을 가리는 것이 아니라, 기존 유지보수 범위에 넣을 일을 늘릴지 별도 개선 과제로 전환할지를 판단하는 데 있어야 합니다.

범위가 계속 불명확하다면 계약 조항부터 늘리기보다 현재 운영 중인 시스템의 기능 목록을 다시 정리하는 편이 빠를 수 있습니다. 무엇이 정상 동작인지 합의되지 않은 상태에서는 장애 대응 기준도 변경 요청 기준도 작동하기 어렵습니다.

결론

유지보수 계약은 모든 상황을 예측하는 문서가 아니라, 예상하지 못한 요청도 같은 기준으로 판단하게 하는 문서여야 합니다. 장애는 기준 동작의 회복으로, 변경은 승인된 범위의 수정으로 기록하고 접수부터 완료까지 남길 항목을 미리 합의하세요.

계약 전에는 현재 시스템에서 멈추면 안 되는 기능을 먼저 적어 보세요. 다음으로 자주 발생하는 운영 요청을 모아 유지보수에 포함할 일과 별도 협의할 일을 나눕니다. 마지막으로 그 판단을 누가 승인하고 어디에 남길지 정하면 계약서는 실제 운영 도구가 됩니다.

자주 묻는 질문

오류처럼 보이는 요청은 모두 장애로 처리해야 하나요?

아닙니다. 약속된 동작이 작동하지 않는지부터 확인해야 합니다. 정책 변경, 신규 조건 추가, 외부 서비스 설정 변경 때문에 예상과 다른 결과가 난 경우에는 변경 요청 또는 별도 확인 절차가 필요할 수 있습니다.

장애 우선순위는 누가 정하나요?

계약에서 정한 기준에 따라 고객사와 유지보수 담당자가 영향 범위를 확인해 정하는 방식이 좋습니다. 요청자가 느끼는 긴급도만 보지 말고 서비스 중단 여부, 영향 사용자, 대체 업무 가능 여부를 함께 봐야 합니다.

경미한 수정도 매번 견적을 받아야 하나요?

반드시 그렇지는 않습니다. 월간 작업 시간이나 수정 건수 안에 포함할 경미한 요청의 기준을 계약서에 두면 반복 업무의 승인 절차를 줄일 수 있습니다.

계약 이후 추가된 기능은 어떻게 관리하나요?

추가 기능의 완료와 승인 기록을 서비스 목록에 반영해야 합니다. 기록하지 않으면 다음 계약 갱신 때 무엇이 유지보수 대상인지 다시 판단해야 합니다.

제 도움이 필요하시다면

크로플은 웹, 앱, 업무 시스템의 SI 수탁개발과 프로젝트 관리를 수행합니다. 유지보수 계약을 앞두고 있다면 현재 기능 목록을 기준으로 장애 대응 범위와 변경 요청 절차를 나누고, 요청서와 완료 기준을 정리하는 작업을 함께 검토할 수 있습니다.

이미 운영 중인 시스템에서 요청이 메신저에 흩어져 있거나 장애와 개선 작업의 비용 판단이 반복해서 엇갈린다면, 현재 운영 방식과 요청 흐름을 먼저 정리해 보세요. 기능 목록, 장애 기록, 변경 요청 기록 가운데 무엇부터 문서화할지 판단하는 데 도움이 됩니다.