[웹개발] 운영이 흔들리지 않는 홈페이지 유지보수 분류 기준

사이트를 운영하다 보면 긴급한 고장과 가벼운 변경이 한 요청 목록에 섞이기 쉽습니다. 구분선이 없으면 처리 일정도 매번 새로 협의하게 됩니다. 서비스가 멈춘 뒤 범위를 조율하면 복구는 더 늦어질 수 있습니다.

저희 CodeLune은 유지보수 협의 초기에 업무 유형과 대응 순서를 문서로 맞춥니다. 아래에서는 장애와 일상 변경과 별도 개발을 나누는 기준을 일곱 단계로 살펴봅니다.

1단계. 관리 범위와 책임자 정리하기

현재 사이트를 이루는 요소부터 적습니다. 사용자에게 보이는 화면은 물론 운영 서버도 범위에 넣습니다. 데이터베이스와 연결 도메인과 제3자 서비스 연동도 빠뜨리지 않습니다. 항목별 관리 주체를 표시하면 이상이 생겼을 때 확인할 담당자가 명확해집니다.

2단계. 운영 장애와 보통 변경 가르기

사이트 접속이 되지 않거나 결제가 실패해 운영이 멈추면 장애로 분류합니다. 글과 사진 교체는 일반 변경에 둡니다. 새 기능이나 페이지 구조 변경은 유지관리에서 빼고 추가 개발로 산정합니다.

> 분류명 자체보다 실제 운영 중단 여부와 원래 기능의 변화 유무를 먼저 확인합니다.

3단계. 심각도별 응답 약속 세우기

모든 일을 곧바로 해결하겠다는 약속은 긴급 건과 일상 건의 순서를 흐립니다. 접속 중단과 기능 오작동과 표시 이상을 세 등급으로 구분합니다. 등급마다 최초 확인 기한과 진행 공유 방법과 임시 복구 여부를 정합니다.

4단계. 접수 양식과 창구 단일화하기

신고 양식에는 페이지 주소와 발생 시간과 사용 기기와 재현 절차를 넣습니다. 화면 캡처와 기대한 정상 결과도 받습니다. 전화와 메신저로 내용이 흩어지지 않게 공식 접수처를 하나만 둡니다.

5단계. 정액 업무와 별도 견적 구획하기

정기 점검과 백업 검증과 보안 패치는 월 계약 범위에 묶습니다. 글이나 배너 교체는 허용 횟수 또는 투입 시간으로 한도를 정합니다. 신규 기능과 외부 서비스 연결과 전체 화면 개편은 별도로 산정합니다. 포함 항목을 표로 명확히 하면 작은 변경이 누적되어 운영 계획을 밀어내는 상황을 줄일 수 있습니다.

6단계. 조치 이력과 배포 내역 보관하기

장애 원인과 조치와 확인 결과를 한곳에 남깁니다. 일상 변경도 요청자와 대상 화면과 배포 시점을 기록합니다. 이력이 쌓이면 반복 문제를 찾고 새 담당자에게 운영 맥락을 전하기 쉽습니다. 비밀번호 같은 민감 정보는 작업 문서와 분리된 안전한 저장소에 보관합니다.

7단계. 계약 종료 뒤 넘길 항목 확정하기

계약 종료 때 넘길 자료도 미리 합의합니다. 최신 코드와 배포 절차와 환경 설정 목록과 최근 백업본과 남은 요청이 기본입니다. 회사 계정에서 기존 담당자의 권한을 회수한 뒤 새 담당자가 배포와 복구 과정을 직접 확인합니다. 종료 절차가 있어야 관리 주체가 달라져도 서비스 운영이 이어집니다.

> 유지보수의 품질은 처리 건수가 아니라 모두가 동일한 판단 기준을 사용하는 운영 방식에서 결정됩니다.

핵심 요약

사이트 자산별 관리 범위와 책임 주체 문서화하기

운영 장애와 일상 변경과 신규 개발 분류하기

심각도에 따른 최초 응답 시점과 진행 공유 규칙 마련하기

필수 신고 항목을 정하고 공식 접수처 통합하기

조치 이력과 계약 종료 시 인계 자료 보존하기

유지보수 파트너의 연락처만 정한다고 안정적인 운영이 만들어지지는 않습니다. 장애 판단과 요청 양식과 월 범위를 먼저 합의해야 합니다. 기록과 인계 방식까지 실제 업무 흐름에 맞춰 비교하면 긴급한 순간에도 팀이 같은 순서로 움직일 수 있습니다.

[CodeLune 개발 사례 살펴보기](https://codelune.dev/ko/portfolio)