01운영 문제현재 흐름 확인
02판단 기준비용·보안·관리
03적용 순서작게 검증
유지보수 계약서를 열면 ‘월 정기 점검’ ‘장애 대응’ 같은 문구가 보입니다. 하지만 실제로 무엇이 포함되고 무엇이 제외되는지가 명확하지 않으면, 장애가 났을 때 ‘그건 계약 범위 밖입니다’라는 답을 듣게 됩니다.
유지보수 계약의 네 영역
- 업데이트 — 모델·프로그램·보안 패치를 언제 누가 적용하는가
- 백업 — 데이터·설정·모델을 얼마나 자주 백업하는가
- 모니터링 — 어떤 지표를 누가 보고 있는가
- 장애 대응 — 장애 접수부터 복구까지 응답 시간·복구 시간
하루·한 달·분기로 나눠 봅니다
| 주기 | 업무 예 |
|---|---|
| 하루 | 모니터링 확인, 로그 점검, 알림 응답 |
| 한 달 | 백업 검증, 패치 적용, 사용량 검토 |
| 분기 | 복구 훈련, 권한 점검, 계약 범위 재확인 |
개념 이미지: 유지보수 업무를 주기별로 나누고 책임자와 제외 사항을 명시하는 도식입니다.
계약 리스크 프레임
- 자동 갱신 조항 — 해지 통보 기한을 명시했는가
- 유지보수 범위의 문서화 — 버그 수정 vs 기능 추가가 구분되는가
- 담당자 퇴사 시 지식 소멸 — 운영 지식이 문서화되어 있는가
- 엑셀·수기 관리 한계 — 만료일·대금 일정을 능동 추적하는가
보관(Storage)과 관리(Management)는 다릅니다. 파일을 저장해 두는 것과, 만료일·자동갱신·대금 일정·비밀유지 의무를 능동 추적하는 것은 별개입니다.
SLA 준수를 측정합니다
- 알림 확인시간 = 경보 발생부터 담당자 확인까지
- 복구시험 결과 = 백업에서 실제 복구 성공 여부
- 패치 지연일 = 패치가 늦어진 일수
- SLA 준수율(%) = 약정 응답 시간을 지킨 건수 ÷ 전체 장애 건수 × 100
오늘 유지보수 계약서에서 ‘제외 사항’ 조항을 찾아 보세요. Core Company는 하루·한 달·분기 업무와 제외 사항을 명확히 분리한 유지보수 범위를 설계해 드리겠습니다.
CORE COMPANY / READINESS
이 기준을 우리 환경에 대입해 보세요
현재 운영 흐름을 먼저 확인하면 필요한 기술 범위를 줄일 수 있습니다.
출처
- 많은 기업이 놓치는 '계약 관리'의 민낯 (modusign)
- 확인일
- 자료 유형
- 네이버 블로그
변경 이력
| 날짜 | 변경 내용 | 검수자 |
|---|---|---|
| V11: 네이버 블로그 리서치 1건 기반 재작성 — 계약 리스크 프레임·보관/관리 구분 적용, 판매용 통계·고객 사례 수치 제거 | 기술 책임자 |
작성과 검수
- 작성
- Core Company
- 기술 검토
- 기술 책임자 검토 대기
- AI 활용 공개
- 초안의 구조와 문장 정리에 AI 보조를 사용했으며, 공개 전 기술 책임자가 사실·적용 조건·연락 수단을 검토해야 합니다.