운영·유지보수 범위 정하기 가이드

시스템은 오픈한 날부터 실제 업무를 맡습니다. 그런데 운영 단계의 범위는 구축 범위보다 늦게, 문제가 생긴 뒤에야 논의되는 경우가 있습니다. 어떤 요청을 누가 언제까지 처리할지 오픈 전에 정해 두면, 운영 중의 판단이 빨라지고 서로의 기대도 맞출 수 있습니다.

01. 유지보수와 고도화를 나눠 봅니다

장애 대응, 오류 수정, 정기 점검처럼 지금의 기능을 지키는 일과, 새 기능 추가나 화면 개편처럼 서비스를 바꾸는 일은 성격이 다릅니다. 두 가지를 한 범위에 섞으면 우선순위와 일정, 비용을 판단하기 어려워집니다.

구축 직후의 무상 보완 기간이 있다면 그 범위와 끝나는 시점도 함께 확인합니다. 보완 기간 뒤에 이어질 운영 방식을 미리 정해 두면 운영 공백을 줄일 수 있습니다.

정리할 항목

전화, 메신저, 메일로 흩어져 들어온 요청은 누락되기 쉽고 처리 상태를 확인하기도 어렵습니다. 요청을 받는 창구와 양식을 정하고, 접수부터 완료까지의 상태를 요청한 쪽과 처리하는 쪽이 함께 볼 수 있게 합니다.

요청마다 영향 범위와 긴급도를 기준으로 우선순위를 정합니다. 내부 승인이 필요한 변경이라면 누가 승인하고 언제 반영하는지도 절차에 넣습니다.

서비스 전체가 멈춘 경우와 일부 화면의 표시 오류는 대응 속도가 같을 수 없습니다. 장애의 등급을 나누고, 등급마다 첫 대응과 복구 목표 시간, 보고 방식을 정합니다.

업무 시간 밖에 장애가 생겼을 때의 연락 경로와 담당자를 정해 둡니다. 연계된 외부 시스템이나 서버 운영 업체처럼 함께 대응해야 하는 곳의 연락처도 목록에 넣습니다.

정리할 항목

서버 자원, 로그, 백업 상태, 인증서와 계정의 만료일처럼 정해진 주기로 확인할 항목을 목록으로 만듭니다. 점검 결과를 기록해 두면 같은 문제가 되풀이되는지 판단하는 근거가 됩니다.

보안 업데이트와 운영 환경의 버전 변경은 서비스에 영향을 줄 수 있어 적용 전에 확인 절차가 필요합니다. 배포 시간대와 되돌리는 방법을 미리 정하고, 변경 내용은 이력으로 남깁니다.

운영 담당자는 바뀔 수 있습니다. 시스템 구성, 연계 정보, 배포 방법, 자주 생긴 문제와 해결 기록을 문서로 정리해 두면 새 담당자도 같은 기준으로 운영을 이어갈 수 있습니다.

운영 중에 쌓인 요청과 장애 기록은 다음 개선 과제를 정하는 자료가 됩니다. 기록을 정기적으로 함께 살펴보고, 되풀이되는 불편은 고도화 범위로 옮겨 계획합니다.

CONVERSATION STARTER

아래 내용을 정리해 두면 초기 논의의 범위를 더 빠르게 맞출 수 있습니다. 모두 준비되어 있지 않아도 현재 상황부터 이야기할 수 있습니다.

KPS 프로젝트 가이드 · 구체적인 기술 구성과 적용 조건은 요구사항에 따라 달라집니다.