소프트웨어 유지보수 비용: 아무도 잡지 않는 예산

소프트웨어 유지보수 비용은 성공한 프로젝트를 열여덟 달 뒤 껄끄러운 대화로 바꿔 놓는 숫자입니다. 구축은 예산이 잡혔고 승인이 났고 납품까지 끝났습니다. 그런데 서비스가 가동된 다음에 벌어지는 일은 그냥 “지원"이라는 한마디로 정리되었고, 누군가 감으로 찍은 금액이 붙었으며, 그 금액은 거의 언제나 너무 적었습니다.

이유는 부주의가 아니라 구조에 있습니다. 구축에는 값을 매길 수 있는 범위가 있습니다. 유지보수에는 범위가 없습니다. 아직 일어나지 않은 일들이 그 범위를 정하기 때문입니다. 취약점이 발견되는 라이브러리, API를 바꾸는 공급업체, 아무도 예상하지 못한 상황에 부딪히는 사용자가 그런 일들입니다.

모두가 인용하는 경험칙은 연간 구축 비용의 15에서 20 퍼센트이고, 정답에 충분히 가깝다는 점이 바로 위험한 지점입니다. 안심할 만큼 자주 들어맞고, 빗나갈 때는 예측 가능한 방향으로 빗나갑니다. 결함이 드러나는 첫해를 과소평가하고, 규제 의무가 있거나 외부 연동이 많은 시스템에서는 아예 무너집니다. 그런 시스템에서 일을 만들어 내는 것은 여러분의 코드베이스가 아니라 바깥에서 벌어지는 사건들이기 때문입니다.

소프트웨어 유지보수 비용이 실제로 포함하는 것

뚜렷하게 구분되는 다섯 가지 범주가 있고, 이것들을 뒤섞는 순간 잘못된 숫자가 나옵니다.

교정 작업. 결함을 고치는 일입니다. 앞쪽에 몰립니다. 대부분의 버그는 실제 사용이 시작된 뒤 첫 몇 달 안에 드러나기 때문이며, 백분율 규칙이 그나마 가장 잘 설명하는 범주도 이것입니다. 다만 한 건의 무게는 미리 알 수 없어서, 작은 수정인 줄 알았던 것이 설계 재검토까지 번지기도 합니다.

적응 작업. 여러분이 통제할 수 없는 변화를 따라가는 일입니다. 의존성이 보안 패치를 냅니다. 결제 대행사가 API 버전을 종료합니다. 브라우저가 동작을 바꿉니다. 어느 것도 기능을 더해 주지 않지만 전부 의무입니다.

예방 작업. 강제되기 전에 미리 올리는 일입니다. 건너뛴다고 비용이 사라지지 않습니다. 미뤄지면서 불어날 뿐이고, 평범한 프레임워크 업그레이드가 석 달짜리 프로젝트로 변하는 경로가 바로 이것입니다.

운영. 호스팅, 모니터링, 백업, 인증서, 그리고 그것들을 지켜보는 사람의 시간입니다. 별도 항목으로 잡는 경우가 많은데, 누군가 잡기만 한다면 그래도 괜찮습니다.

작은 변경. 실제 사용자가 들어온 뒤 운영 시스템이 꾸준히 만들어 내는 조정 요청의 흐름입니다. 하나씩 보면 사소하지만, 모아 놓으면 대부분의 해에 가장 큰 범주가 됩니다.

사람들이 보통 유지보수라고 부르는 것은 첫 번째 범주뿐입니다. 예산이 바닥나는 이유는 나머지 넷에 있습니다.

백분율 규칙이 어긋나는 이유

잘못된 기준에 닻을 내리기 때문입니다. 유지보수 공수는 움직이는 부품의 수와 바깥세상이 그것들을 바꾸는 속도를 따라가지, 구축에 우연히 들어간 금액을 따라가지 않습니다.

같은 돈으로 만든 두 시스템이 세 배까지 차이 날 수 있습니다. 의존성이 둘뿐이고 규제 노출이 없는 자족적인 애플리케이션은 돌리는 비용이 쌉니다. 외부 서비스 여섯 개를 연동하고 개인정보를 다루며 업종 규정을 받는 시스템은 그렇지 않습니다. 그 연동 하나하나가 여러분이 일정을 잡지 않은 작업의 발원지이기 때문입니다.

백분율은 또 첫해에는 존재하지 않는 정상 상태를 전제합니다. 실사용은 결함을 찾아내고, 출시 후 첫 여섯 달은 상황이 안정되기 전까지 연평균을 한참 웃도는 것이 보통입니다.

더 나은 추정은 움직이는 부품에서 출발합니다. 연동 수, 규제 의무, 지원 문의를 만들어 내는 사용자 수를 세어 보고, 그것들이 현실적으로 잡아먹는 시간에 값을 매기십시오. 맞춤형 소프트웨어 개발 비용 안내서에서 같은 셈법의 구축 쪽을 다룹니다.

팀이 빠뜨리는 항목들

의존성 업그레이드. 선택 사항이 아닙니다. 패치되지 않은 라이브러리가 시스템이 뚫리는 경로이기 때문입니다. 게다가 공수는 정말로 예측하기 어렵습니다. 상위 관리자들이 무엇을 하느냐에 달려 있기 때문입니다.

외부 API 변경. 공급업체가 버전을 종료하면서 기한을 통보합니다. 시점을 고른 것은 여러분이 아니고, 거절할 수도 없습니다.

인증서와 도메인 갱신. 사소한 일입니다. 주말에 하나가 만료되어 사이트가 멈추기 전까지는 그렇습니다.

모니터링과 그에 대한 대응. 반응할 사람이 없으면 알림은 쓸모가 없고, 그 대기 상태는 아무 일도 터지지 않아도 실제로 나가는 비용입니다.

지식 이전. 사람은 떠납니다. 다음 사람이 시스템을 익히는 데 드는 비용은 유지보수 비용이며, 기록으로 남긴 것이 적을수록 커집니다.

데이터 증가. 저장 비용이 오르고, 빠르던 쿼리가 느려지며, 그 처리 작업은 여러분 자신의 성공이 정한 일정에 맞춰 찾아옵니다. 데이터베이스 성능 안내서에서 실제 모습을 다룹니다.

영국에서의 비용 수준

맞춤 시스템을 유지보수할 때의 대략적인 연간 구간이며, 내부 인력이 아니라 외부 업체를 쓰는 경우를 가정했습니다.

여기에는 호스팅과 라이선스가 빠져 있습니다. 별도로 청구되고 편차가 아주 큽니다. 또한 시스템이 그런대로 괜찮은 상태라는 것을 전제로 합니다. 아무도 문서를 남기지 않았고 테스트도 없으며 이해하는 사람이 한 명뿐인 시스템을 맡으면 비용은 더 들고, 어떤 계약으로도 없앨 수 없는 위험이 따라옵니다. 문서와 테스트가 없는 만큼, 손을 댈 때마다 현재 상태를 먼저 읽어 내는 시간이 앞에 붙기 때문입니다.

계약을 어떻게 짤 것인가

시간이 정해진 정액 계약은 물량이 대체로 예측될 때 잘 맞습니다. 이 계약이 사 오는 것은 대기 가능성이고, 여러분이 내는 돈의 대부분이 사실 그것입니다. 쓰지 않은 시간은 낭비가 아닙니다. 대안은 아무도 없는 상태이기 때문입니다.

시간과 자재 정산은 변경이 적은 시스템에 어울리지만, 응답 시간은 업체의 다른 약속들이 허락하는 만큼이 되고, 그것이 맞바꾸는 조건입니다.

고정가 지원 계약은 위험을 업체로 넘기고, 업체는 그 위험을 수수료에 반영합니다. 예측 가능성이 마진보다 값진 핵심 시스템에는 합리적인 선택입니다.

무엇을 고르든, 필요해지기 전에 무엇이 유지보수이고 무엇이 신규 기능인지 합의해 두십시오. 그 경계가 지원 관계에서 벌어지는 거의 모든 분쟁의 출발점이고, 시작 시점에 정의해 두는 데는 비용이 들지 않습니다.

Mecanik은 소프트웨어 개발 업무의 일부로, 우리가 만든 시스템뿐 아니라 만들지 않은 시스템도 유지보수합니다. 인수인계의 첫 달은 대개 문서화에 쓰입니다. 운영 이력, 이미 알려진 결함, 외부 연동 목록을 글로 옮기는 일이 여기에 들어갑니다. 그 문서가 이후 모든 달의 비용을 결정하기 때문입니다.

함께 읽기: 고정가 계약인가, 시간과 자재인가? , 쓸 만한 견적을 받아 내는 소프트웨어 제안요청서 쓰는 법 , 소프트웨어 에스크로: 정말 필요한 곳은 어디인가 그리고 MVP 소프트웨어 개발: 범위, 비용, 일정 .

자주 묻는 질문

소프트웨어 유지보수 비용은 연간 얼마인가요? 흔한 경험칙은 연간 구축 비용의 15에서 20 퍼센트지만, 결함이 드러나는 첫해를 과소평가하고 연동이 많거나 규제 의무가 있는 시스템에서는 완전히 무너집니다. 영국의 대략적인 구간은 소규모 내부 도구가 £6,000에서 £15,000, 규제 대상이거나 트래픽이 많은 플랫폼은 £60,000 이상이며 호스팅은 제외한 금액입니다.

소프트웨어 유지보수에는 실제로 무엇이 포함되나요? 다섯 가지입니다. 결함을 고치는 교정 작업, 의존성과 외부 API 변경을 따라가는 적응 작업, 강제되기 전에 올려 두는 예방 작업, 호스팅과 모니터링 같은 운영, 그리고 운영 시스템이 꾸준히 만들어 내는 작은 변경의 흐름입니다. 대부분의 사람이 유지보수라고 부르는 것은 첫 번째뿐입니다.

구축 비용의 백분율 규칙은 왜 믿을 수 없나요? 잘못된 기준에 닻을 내리기 때문입니다. 유지보수 공수는 움직이는 부품의 수와 바깥세상이 그것을 바꾸는 속도를 따르지 구축 비용을 따르지 않습니다. 같은 돈으로 만든 두 시스템이 연동 수, 규제 노출, 지원 문의량에 따라 세 배까지 차이 날 수 있습니다.

팀이 예산에서 빠뜨리는 유지보수 비용은 무엇인가요? 의존성 업그레이드, 여러분이 고르지 않은 기한이 붙은 외부 API 종료, 인증서와 도메인 갱신, 모니터링 알림 뒤에 있는 사람의 대기 시간, 사람이 떠날 때의 지식 이전, 그리고 데이터 증가가 저장 비용과 쿼리 속도에 미치는 영향입니다.

정액 계약이 좋을까요, 필요할 때 지불하는 편이 좋을까요? 시간이 정해진 정액 계약은 예측 가능한 물량에 맞고 대기 가능성을 사 오는데, 여러분이 내는 돈의 대부분이 그것입니다. 시간과 자재 정산은 변경이 적은 시스템에 맞지만 응답 시간은 업체의 다른 약속에 좌우됩니다. 무엇을 고르든 필요해지기 전에 무엇이 유지보수이고 무엇이 신규 기능인지 정의해 두십시오.