LIFECYCLE · 06 / 06
인도·운영
안정화·하자담보·인수인계로 끝맺는다. 점진개발보다 인도단계가 더 중요한 이유가 여기 있다.
안정화 계획
오픈 이후 시스템을 안정시키는 계획. 수행사에 명시적으로 요구해야 한다.
안정화 계획은 수행사가 자발적으로 내지 않으므로 명시적으로 요구해야 한다. 기간은 최소 한 달, 잔류 인력은 PL급으로 두고, 목표치를 근거로 통제해야 인도 단계가 흔들리지 않는다.
인도·운영 · 인도결함조치율
검수 후 남은 결함을 처리한 비율. 잔존결함 조치계획을 RFP에 명시한다.
결함조치율은 단일 백분율로 안심할 지표가 아니라 결함 등급별로 분해해 읽어야 하는 지표다. 잔존결함의 조치 기준과 처리 절차를 RFP 단계에 미리 명시해 두면, 인수 시점의 갈등이 합의된 규칙에 따른 판단으로 바뀌고 미조치 결함이 하자담보책임기간으로 떠넘겨지는 일을 막을 수 있다.
인도·운영 · 인도하자담보책임기간
발견되지 못한 결함을 무상 대응해야 하는 법정 기간.
하자담보책임기간의 분쟁은 인도 이후가 아니라 계약 시점의 모호함에서 비롯된다. 무엇이 무상 하자이고 무엇이 유상 추가 요건인지의 경계, 기간의 길이, 책임 종료 인계 조건을 계약 단계에 명시하고 인도 시점의 잔존결함 이력을 정리해 두면, 책임기간의 판단이 주관적 다툼이 아니라 합의된 기준에 따른 결정이 된다.
인도·운영 · 인도완료보고서·Wrap-up
수행기획서 기준으로 프로젝트를 결산하고 다음 계획의 근거를 남긴다.
완료보고서의 가치는 성과를 포장하는 데 있지 않고 계획과 실측의 차이를 원인별로 분리해 남기는 데 있다. 잔존 위험과 공수 결산을 정직하게 적어 두어야 안정화 계획과 다음 산정이 근거를 얻는다.
인도·운영 · 운영EOS
서비스 종료. 제품·솔루션의 지원이 끝나는 시점.
EOS는 시스템이 멈추는 순간이 아니라 보안과 책임이 조용히 비는 구간이 시작되는 시점이다. 종료 일정을 도입 단계에서 미리 생애주기에 넣고 전환 계획을 선행시켜야, 지원이 끊긴 뒤 위험을 떠안는 상황을 피할 수 있다.
인도·운영 · 운영운영자 매뉴얼
운영환경·애플리케이션 정보·장애 조치 흐름을 이벤트 단위로 담은 인계 문서.
운영자 매뉴얼은 기능을 나열한 설명서가 아니라 증상에서 출발해 조치로 이어지는 이벤트 단위 대응서일 때 장애 순간에 쓸모가 있다. 그리고 운영 변경마다 갱신되지 않는 매뉴얼은 인도된 그날부터 서서히 거짓말이 되어 간다.
인도·운영 · 운영사용자 매뉴얼
화면번호·에러코드로 바로 찾고, 접속·권한 문제를 즉시 조치하게 하는 문서.
사용자 매뉴얼의 가치는 분량이 아니라 회수율에 있다. 사용자가 막혔을 때 운영팀을 부르지 않고 화면번호·에러코드만으로 스스로 조치하게 만드는 문서라야 안정화 단계의 운영 부하를 실제로 줄인다. 기능 나열형 설명서는 있어도 문의는 줄지 않는다.
인도·운영 · 표준ITIL 4
IT 서비스를 비즈니스 가치에 정렬시키는 운영 표준.
ITIL은 절차를 늘리는 통제 장치가 아니라 운영의 예측 가능성과 복구 속도를 높이는 도구다. 급한 복구와 근본 개선을 한 흐름에 섞지 않고 분리해 다루는 것이 운영 성숙도의 첫 갈림길이다.
인도·운영 · 인도데이터 마이그레이션
기존 시스템 데이터를 신규로 이전·정제·검증하는 작업. 분쟁 다발.
마이그레이션의 성패는 전환 당일이 아니라 원천 데이터 분석과 정제, 그리고 반복 Mock 테스트의 누적에서 결정된다. 정제 책임의 경계와 검증 합격 기준을 계약 시점에 문서로 못 박지 않으면, 데이터 품질을 둘러싼 분쟁이 오픈 직전에 반드시 터진다.
인도·운영 · 운영IT 서비스 관리
IT 서비스를 비즈니스 가치에 맞춰 운영·관리하는 체계.
ITSM의 성패는 도구나 ITIL 프로세스의 도입 여부가 아니라, 처리 이력과 SLA 지표를 정기적으로 되돌아보며 개선으로 환류하는 순환이 실제로 작동하는가에 달려 있다. 비즈니스 중요도에 맞지 않는 과도한 SLA는 운영 비용만 키우므로, 서비스별로 차등화하는 것이 현실적이다.
인도·운영 · 운영장애관리
발생한 장애를 신속 복구하고 재발을 막는 운영 프로세스.
장애 발생 순간의 최우선 과제는 원인 규명이 아니라 서비스의 빠른 복구이며, 근본 원인 분석은 안정화 이후 별도로 다루는 것이 피해를 줄이는 정석이다. 같은 장애가 반복된다면 개별 사고가 아니라 구조적 결함 신호이므로, 장애 이력을 축적해 근본 원인을 제거해야 끝없는 반복 대응에서 벗어날 수 있다.
인도·운영 · 운영재해복구
재해 시 시스템·데이터를 복구하는 계획과 체계. RTO·RPO 기준.
DR의 성패는 계획서의 정교함이 아니라 정기 복구 훈련에서 RTO·RPO가 실측으로 달성되느냐에서 갈린다. 백업이 있어도 복원이 검증되지 않았다면 DR은 존재하지 않는 것과 같으며, 시스템 구성이 바뀔 때마다 계획을 갱신하지 않으면 가장 필요한 순간에 어긋난다.
인도·운영 · 운영백업·복구
데이터 손실에 대비한 백업과 복원 전략.
백업의 성공 여부는 작업 완료 메시지가 아니라 정기적인 복원 테스트로만 확인된다. 사본이 세 벌 있어도 한 장소·한 매체에 몰려 있으면 단일 사고로 전부 잃을 수 있으므로, 보관 위치 분리와 복원 검증을 함께 갖추지 못한 백업은 안심의 근거가 되지 못한다.