소프트웨어 유지보수 및 지원: 적절한 모델 선택하기

워런티(Warranty), AMC, 보유 시간(retained hours) 또는 매니지드 서비스(managed service)? 올바른 선택은 빌드 팀이 떠난 후에 무슨 일이 일어나는지에 따라 달라집니다.

맞춤형 소프트웨어 프로젝트에서 가장 위험한 지점은 출시일이 아닐 수 있습니다. 7개월 차일 수 있습니다.

워런티가 끝났습니다. 납품 팀은 다른 프로젝트로 이동했습니다. 아직 아무것도 고장 난 것처럼 보이지 않지만, 누가 시스템의 소유자인지 명확하지 않습니다. 바로 이때 알림이 읽히지 않거나, 자격 증명이 만료되거나, 백업이 테스트되지 않고, 문서화가 코드보다 느리게 뒤처집니다.

소프트웨어 유지보수는 단순한 버그 수정 그 이상입니다

소프트웨어 유지보수 서비스는 작동하는 시스템을 계속 작동하게 합니다. 원본 기사는 지속적인 작업을 발견된 문제에 대한 교정적 유지보수(corrective maintenance), 주변 환경의 변화에 대한 적응적 유지보수(adaptive maintenance), 그리고 시스템을 개선하거나 확장하는 작업을 포함하여 여러 범주로 분리합니다.

실용적인 지원 계약을 위해서는 네 가지 영역이 명확하게 구분되어야 합니다:

• 워런티(Warranty) — 고정된 출시 후 기간 동안 합의된 범위에 대한 결함.
• 교정적 유지보수(Corrective maintenance) — 워런티 이후 발견되는 오류.
• 적응적 유지보수(Adaptive maintenance) — 브라우저, 운영 체제, SDK, 결제 게이트웨이, 인증서 또는 종속성(dependencies) 변경으로 인해 필요한 업데이트.
• 신규 기능(New features) — 원래 인계 범위에 포함되지 않았던 기능성.

이 모든 것을 모호한 '지원' 예산 아래 두는 곳에서 의견 불일치가 시작됩니다.

워런티 대 AMC 대 보유 시간 대 매니지드 서비스

모든 애플리케이션에 맞는 단 하나의 지원 모델은 없습니다.

• **워런티(Warranty)**는 다운타임이 제한적인 비즈니스 영향을 미치는 단순하고 안정적인 내부 시스템에만 적용될 수 있습니다.
• AMC는 예측 가능한 교정적 및 적응적 유지보수가 필요한 확립된 비즈니스 시스템에 적합합니다.
• **보유 시간(Retained hours)**은 애플리케이션이 여전히 발전하고 있고, 약속된 엔지니어링 역량 블록을 원하는 경우 잘 작동합니다.

서비스 수준 협약(SLA)이 포함된 관리형 서비스는 시스템 다운타임이 중요한 비즈니스 프로세스를 중단시키고, 모니터링, 사고 대응 및 정의된 복구 목표가 중요할 때 설계됩니다. 붙여넣은 텍스트

가장 간단한 질문은 다음과 같습니다:
당신의 비즈니스는 얼마나 많은 다운타임을 감수할 수 있습니까?
만약 4시간 동안 오프라인인 것이 불편하다면, 연간 유지보수 계약(AMC)으로 충분할 수 있습니다.
하지만 4시간이 인보이싱, 운영 또는 현장 팀을 중단시킨다면, AMC 수준의 기대치보다는 계약상의 서비스 수준이 필요할 가능성이 높습니다.

유용한 SLA의 예시
SLA는 엔지니어뿐만 아니라 비즈니스 문제를 경험하는 사람도 이해할 수 있어야 합니다.
실용적인 구조는 다음과 같을 수 있습니다:
S1 중요(Critical): 핵심 시스템 또는 프로세스가 완전히 사용 불가능함.
첫 응답: 24시간 연중무휴, 30분
복구/임시 해결책: 4시간
S2 높음(High): 핵심 프로세스가 저하되거나 부서/사이트가 차단됨.
첫 응답: 근무 시간 내 2시간
복구/임시 해결책: 영업일 기준 1일
S3 보통(Medium): 보조 기능이 사용 불가능하지만 작업은 계속할 수 있음.
첫 응답: 영업일 기준 1일
복구/임시 해결책: 영업일 기준 5일
S4 낮음(Low): 미관상의 문제, 사용성 문제 또는 사소한 요청.
첫 응답: 영업일 기준 3일
해결: 다음 예정된 릴리스까지

그리고 기억하세요: 응답 시간이 해결 시간을 의미하지는 않습니다.
벤더가 당신의 S1 티켓을 빠르게 인지했다고 해서 서비스가 복구되었다는 것을 의미하지는 않습니다. 두 목표 모두 계약서에 명시되어야 합니다. 붙여넣은 텍스트

지식 연속성(Knowledge Continuity)이 중요합니다
지원 품질은 종종 하나의 질문으로 귀결됩니다:
출시 후 6개월이 지나도 누가 시스템을 이해하고 있는가?
좋은 연속성을 위해서는 최신 아키텍처 문서, 통합 세부 정보, 환경 정보, 예약 작업 문서 및 실질적인 사고 대응 매뉴얼(runbooks)이 필요합니다.
또한 코드베이스를 알고 있는 지정된 엔지니어와 실제로 시스템 작업을 해본 백업 인력이 있어야 합니다. 붙여넣은 텍스트

탈출 계획을 잊지 마세요
좋은 지원 계약은 관계가 끝날 때 무슨 일이 일어나는지를 설명해야 합니다.

여기에는 현재의 문서화 자료(documentation), 운영 매뉴얼(runbooks), 자격 증명 인계(credential handover), 지식 전달 시간(knowledge-transfer time), 그리고 귀하의 조직이 독립적으로 복원할 수 있는 최종 백업이 포함됩니다. 이러한 조건들은 합의서에 서명할 때보다 포기할 때 협상하기가 훨씬 쉽습니다. 붙여넣은 텍스트
결론적으로
소프트웨어 지원은 “월간 유지보수 비용이 얼마인가요?”라는 질문으로 시작해서는 안 됩니다.
다음과 같이 시작해야 합니다:
무엇을 계속 작동 상태로 유지해야 하나요? 누가 소유하고 있나요? 얼마나 빨리 복구되어야 하나요? 그리고 원래 구축 팀이 떠난 후에도 여전히 누가 이해하고 있나요?
이러한 답변들이 명확해지면, 보증(warranty), 연간 유지보수 계약(AMC), 유지 인력 시간(retained hours), 관리형 서비스(managed service) 중 무엇을 선택할지 훨씬 쉬워집니다.

전체 블로그 읽기