3.7 소프트웨어 유지보수

개요와 동기

대부분의 소프트웨어는 수명의 압도적 다수를 만들어지는 데가 아니라 유지보수되는 데 보냅니다. 시스템이 프로덕션에 들어가는 순간, 결함을 고치고, 변하는 환경에 적응하고, 이미 동작하는 것을 개선하고, 미래의 문제를 예방하는 단계(흔히 몇 년, 몇 십 년 지속)에 들어갑니다. 대기업, 특히 정부에서는 이 단계가 지배적입니다. 세금 엔진, 급여 시스템, 국방 플랫폼, 핵심 금융 원장은 의뢰한 사람 누구의 예상보다 훨씬 오래 일상적으로 유지보수됩니다. 소프트웨어 유지보수는 인도된 소프트웨어를 운영 수명 전체에 걸쳐 정확하고, 최신이고, 가치 있게 유지하는 규율입니다.

유지보수는 만성적으로 과소평가되고 저평가되며, 그 실수는 비쌉니다. 수십 년에 걸친 연구가 번번이 유지보수를 전체 소프트웨어 수명 비용의 절반을 훨씬 넘는 몫으로, 오래 사는 시스템에서는 흔히 60~90퍼센트 범위로 꼽습니다. 그런데도 조직은 초기 구축이 전체 사업인 것처럼 계획하고, 예산을 잡고, 인력을 대고, 축하합니다. 그러고는 그 이후 모든 것을 사후 생각으로 다루며, 줄어드는 재원에서 대고 마침 여유가 있는 사람에게 맡깁니다. 결과는 예측 가능합니다. 취약한 시스템, 사기가 꺾인 유지보수자, 올라가는 변경 비용, 그리고 결국 사실은 내내 관리되지 않은 유지보수의 문제였던 것이 “레거시 문제”(3.6장)로 틀지어진 위기입니다.

이 장은 SWEBOK(Software Engineering Body of Knowledge)의 소프트웨어 유지보수 지식 영역과 ISO/IEC 14764를 따릅니다. 유지보수의 기본과 인정된 네 가지 범주, 비용, 인력, 사기를 포함해 유지보수를 어렵게 만드는 핵심 쟁점, 유지보수 프로세스, 프로그램 이해, 재공학, 리팩터링의 핵심 기법, 유지보수 비용을 추정하는 방법, 그리고 (이 장에서 지렛대 효과가 가장 큰 아이디어인) 처음부터 유지보수성을 위해 설계하는 방법을 다룹니다. 중심 신념은 유지보수가 엔지니어링에 뒤따르는 열등한 활동이 아니라는 것입니다. 소프트웨어 엔지니어링의 가장 큰 부분이며, 그렇게 계획되고, 재원이 대어지고, 존중되어야 합니다.

핵심 원칙

유지보수는 에필로그가 아니라 수명 주기의 다수입니다. 첫날부터 계획하고 예산을 잡으십시오. 구축보다 더 많은 비용이 들 것입니다.
네 범주는 서로 다른 작업입니다. 교정, 적응, 완전, 예방 유지보수는 동인과 주기가 다르며, 대부분의 노력은 버그 수정이 아닙니다.
이해하지 못하는 것은 바꿀 수 없습니다. 프로그램 이해는 유지보수에서 가장 큰 단일 활동입니다. 코드와 그 이력을 읽을 수 있게 만드십시오.
유지보수성은 설계 속성입니다. 미래 변경의 비용은 대체로 구축 중의 결정으로 정해집니다. 그것을 위해 의도적으로 설계하십시오.
작고 안전하며 지속적인 변경이 미뤄진 큰 변경을 이깁니다. 변경 부채를 쌓는 대신 테스트 안전망 아래서 점진적으로 리팩터링하고 현대화하십시오.
소프트웨어는 가만히 있어도 늙습니다. 환경(의존성, 플랫폼, 규제)이 움직이므로 정적인 시스템은 조용히 썩습니다. 예방 유지보수는 실제 작업입니다.
유지보수자는 일급의 지위를 누릴 자격이 있습니다. 유지보수 팀의 사기, 지식 보존, 인력 구성이 장기 비용과 위험을 직접 결정합니다.

권장 사항

유지보수의 네 범주를 구분하고 모두에 인력을 댄다

ISO/IEC 14764와 SWEBOK은 네 범주를 인정하며, 이를 혼동하는 것은 흔한 계획 오류입니다. 교정 유지보수는 운영 중 발견된 결함을 고칩니다. 적응 유지보수는 환경이 변함에 따라 소프트웨어가 계속 동작하게 합니다. 새 운영체제, 브라우저, 의존성, 하드웨어, 규제, 연동 시스템입니다. 완전 유지보수는 새 기능, 더 나은 성능, 개선된 사용성, 강화된 유지보수성을 통해 사용자와 유지보수자를 위해 소프트웨어를 개선합니다. 예방 유지보수는 잠재 결함을 바로잡고, 취약한 영역의 강화, 정리, 현대화를 통해 미래 위험이 드러나기 전에 줄입니다. 유용한 추가 구분은 교정과 예방을 수정(결함을 다룸)으로, 적응과 완전을 개선(새 요구 사항을 다룸)으로 묶는 것입니다. 결정적으로, 경험적 연구는 유지보수의 대부분이 교정이 아님을 일관되게 발견합니다. 개선과 적응이 지배합니다. 그에 맞게 예산과 인력을 잡고, 노력이 실제로 어느 범주에 속하는지 추적하여 관리할 수 있게 하십시오.

프로그램 이해에 투자한다

유지보수에서 가장 큰 단일 활동은 기존 시스템을 안전하게 바꿀 수 있을 만큼 이해하는 것입니다. 유지보수자는 코드를 수정하는 것보다 읽고 추론하는 데 일상적으로 더 많은 시간을 씁니다. 이를 의도적으로 더 싸게 만드십시오. 문서를 코드 가까이에 최신으로 유지하십시오(2.7장). 아키텍처 결정 기록(1.6장)과 깨끗한 커밋 이력(2.6장)으로 결정 이력을 보존하십시오. 정적 분석, 의존성 그래프, 코드 탐색 도구로 낯선 영역을 지도화하십시오. 특성화 테스트(괴팍함을 포함한 현재 동작을 못 박는 테스트)는 암묵적 이해를 실행 가능하고 내구성 있는 지식으로 바꿉니다. 이해가 비싸면 모든 변경이 느리고 위험합니다. 이해가 싸면 유지보수는 일상이 됩니다.

테스트 안전망 아래서 지속적으로 리팩터링한다

리팩터링은 외부 동작을 바꾸지 않고 코드의 내부 품질을 개선하는 규율 있는 재구조화입니다. 지속적으로 작은 단계로 하면 복잡성으로의 자연스러운 표류를 상쇄하고 변경 비용을 오르게 두지 않고 평평하게 유지합니다. 협상할 수 없는 전제 조건은 신뢰할 수 있는 자동화된 테스트 스위트(2.4장)입니다. 그것이 없으면 “리팩터링”은 위험한 재작성일 뿐입니다. 리팩터링을 일상 업무에 접어 넣으십시오. 드물고 크고 위험한 정리를 위해 아껴 두는 대신 각 모듈을 찾았을 때보다 조금 더 깨끗하게 남기십시오. 이것이 실천으로서의 예방 유지보수이며, 가장 싼 유지보수입니다.

점진적 변경이 더는 충분하지 않을 때 재공학한다

구성 요소가 일상적 변경이 너무 비싸거나 위험할 만큼 저하되었을 때, 재공학(시스템을 검토하고 변경해 새로운 형태로 재구성하는 것)이 더 무거운 도구입니다. 재공학은 보통 리버스 엔지니어링(구현에서 설계와 의도를 복원)과 순방향 재공학(동작을 보존하며 더 나은 구조로 재구축)을 결합합니다. 전면 재작성보다 교살자 무화과와 추상화에 의한 분기(3.6장) 같은 패턴을 써서 한정된 점진적 조각으로 재공학하는 것을 선호하십시오. 재공학은 유지보수-현대화 연속선 위에 놓입니다. 작고 지역적인 것에는 리팩터링, 구조적인 것에는 재공학, 플랫폼 수준에는 현대화입니다.

정의된 유지보수 프로세스를 운영한다

유지보수는 ISO/IEC 14764에 기술된 명시적이고 반복 가능한 프로세스의 혜택을 봅니다. 프로세스 구현(계획과 절차 수립), 문제 및 수정 분석(분류, 재현, 영향과 비용 평가), 수정 구현, 유지보수 검토와 인수, 이전, 퇴역입니다. 이를 규율 있는 변경 관리로 감싸십시오. 모든 유지보수 요청(결함 보고든 개선이든)은 기록되고, 범주별로 분류되고, 영향이 평가되고, 우선순위가 매겨지고, 테스트와 함께 버전 관리 아래서 구현되고, 리뷰되고, 일반 파이프라인(11.2장)을 통해 릴리스되어야 합니다. 영향 분석, 즉 제안된 변경이 건드릴 수 있는 모든 것을 이해하는 것은 핵심이며 진지한 노력을 받을 만합니다. 퇴역도 프로세스의 일부입니다. 시스템을 안전하게 폐기하고, 데이터와 사용자를 이전하고, 기록을 보존하는 것은 즉흥이 아니라 계획되어야 하는 유지보수 작업입니다.

유지보수 비용을 명시적으로 추정하고 재원을 댄다

유지보수를 공짜로, 또는 구축 예산의 잡음으로 다루지 마십시오. 추정하십시오. 흔한 접근에는 유지보수 노력 비율(연간 유지보수가 원래 개발 비용의 대략 15~25퍼센트라는 널리 쓰이는 경험 법칙. 다만 오래 사는 핵심 시스템은 수명 동안 훨씬 더 누적), 유지보수와 재사용 확장을 갖춘 COCOMO II(Constructive Cost Model) 같은 매개변수 모델, 결함률, 변경량, 변경 비용에 대한 자체 이력 데이터에 기반한 지표 주도 예측이 있습니다. 이 추정을 총소유비용 분석과 10.10장에서 논의한 경제성에 공급하십시오. 시스템의 구매 가격이나 구축 비용은 계약금입니다. 주택 대출은 유지보수이며, 모든 비즈니스 사례에 나타나야 합니다.

처음부터 유지보수성을 위해 설계한다

유지보수 비용에 대한 가장 큰 지렛대는 유지보수가 시작되기 전에 행사됩니다. 유지보수성(ISO/IEC 25010 어휘로 분석성, 수정성, 시험성, 모듈성)은 행복한 우연이 아니라 명시적 요구 사항이어야 하는 설계 품질입니다. 모듈식이고, 느슨하게 결합되고, 응집도 높은 설계(2.2장), 분명한 인터페이스와 관심사의 분리, 강한 자동화 테스트, 읽기 쉬운 코드와 최신 문서, 운영자와 유지보수자가 시스템이 하는 일을 볼 수 있는 풍부한 관측 가능성(9부)을 선호하십시오. 이 결정 하나하나는 지금 약간 더 많은 노력을 시스템이 실제로 살 수십 년에 걸친 크고 누적되는 절감과 맞바꿉니다. 유지보수성을 위한 구축은 전체 수명 주기에서 수익이 가장 높은 투자입니다.

장단점

접근 방식	장점	단점
지속적 리팩터링 / 예방 유지보수	변경 비용을 평평하게 유지. 위험 감소. 높은 ROI	눈에 보이는 새 기능 없는 지속적 노력. 강한 테스트 필요
유지보수 미루기 (“불만 켜 두기”)	이번 분기에 가장 쌈. 기능을 위한 역량 확보	변경 부채가 누적됨. 결국 위기와 강제된 비싼 조치
저하된 구성 요소 재공학	유지보수성을 회복하고 유효 수명을 연장	상당한 노력과 위험. 동작을 신중히 보존해야 함
선행적인 유지보수성 설계	누적되는 수명 절감. 이후 모든 변경이 더 쉬움	더 높은 초기 비용과 규율. 이점이 미뤄지고 덜 보임

유지보수에서 반복되는 트레이드오프는 현재 비용 대 미래 비용이며, 유혹은 항상 미루기 쪽으로 흐릅니다. 리팩터링을 건너뛰고, 의존성이 늙게 두고, 유지보수 팀을 굶기는 것은 모두 이번 분기에는 공짜로 보입니다. 청구서가 나중에 더 느리고, 더 위험하고, 더 비싼 시스템으로, 그리고 결국 “레거시 위기”로 오기 때문입니다. 좋은 유지보수의 규율은 크고 갑작스럽고 경력을 가를 비용을 피하려고 작고 지속적이며 눈에 보이는 비용을 지금 치르는 것입니다. 절감이 미뤄지고 보이지 않기 때문에, 이 거래에는 출시일뿐 아니라 수명 주기 경제성을 이해하는 리더십이 필요합니다.

팀과 논의할 질문

예산의 유지보수 수치는 누가 소유하며, 일급 항목입니까 아니면 구축이 쓰지 않은 것에서 긁어모은 잔여분입니까? 유지보수는 오래 사는 시스템에서 흔히 60~90퍼센트에 이르는 수명 비용의 다수이지만, 일상적으로 사후 생각으로 재원을 받고 마침 여유 있는 사람이 맡습니다. 예산이 잔여분이면 예방 작업이 가장 먼저 잘리고, 변경 부채가 누적되며, “레거시 위기”로의 예측 가능한 미끄러짐이 따릅니다. 실제 추정(유지보수 노력 비율, 매개변수 모델, 또는 자체 이력 변경 비용 데이터)을 가져오고 시스템 수명 전반에 그것의 재원을 책임지는 사람을 지명하십시오. 해법은 모든 비즈니스 사례에 유지보수를 구매 가격 옆의 주택 대출처럼 명시적으로 예산에 넣는 것입니다. 출시만 축하하는 리더십은 돈과 위험의 대부분이 실제로 사는 단계에 계속 재원을 적게 댈 것입니다.
예방 유지보수를 위한 역량을 따로 확보합니까, 아니면 늘 다음 기능에 집니까? 예방 작업(테스트 그물 아래의 리팩터링, 의존성 최신 유지, 취약한 영역 강화)은 변경 비용 곡선이 오르지 않고 평평하게 유지되게 하므로 가장 싼 유지보수입니다. 또한 가장 미루기 쉽습니다. 건너뛰는 것이 이번 분기에는 공짜로 보이고 청구서가 나중에 더 느리고 위험한 시스템으로 오기 때문입니다. 구체적 메커니즘이 도움이 됩니다. 상시 할당이며, 많은 강한 팀은 역량의 대략 5분의 1을 매 스프린트 협상으로 빼앗기지 않고 지켜 둡니다. 증거로 변경 비용 추세를 가져오십시오. 오르고 있다면 이미 과소 투자하고 있는 것입니다. 규율은 크고 갑작스럽고 경력을 가를 비용을 피하려고 작고 눈에 보이는 비용을 지금 치르는 것이며, 출시일이 아니라 수명 주기 경제성을 읽는 리더십이 필요합니다.
시스템을 퇴역시킬 계획은 무엇이며, 마지막으로 실제로 폐기한 것은 언제입니까? 퇴역은 유지보수 프로세스의 명시적 부분(데이터 이전, 사용자 전환, 기록 보존, 안전한 종료)이지만, 폐기는 화려하지 않고 예산이 없어서 조직은 죽은 시스템과 중복 시스템을 수년간 안고 갑니다. 모든 좀비 시스템은 여전히 라이선스, 보안 패치, 통합 표면, 다른 곳에 있을 수 있는 사람들의 주의를 소비합니다. 목록을 가져와 활성 사용자가 없거나 완전한 대체물이 이미 가동 중인 시스템을 표시하고, 다른 작업처럼 종료를 계획하십시오. 데이터를 이전하고, 법령이 요구하는 것을 보존하고, 아무것도 여전히 의존하지 않는지 확인합니다. 특히 정부에서는 기록 보존법이 퇴역 방식을 형성하므로 컴플라이언스를 일찍 참여시키십시오. 추적할 가치가 있는 성숙도 신호는 조직이 마지막으로 의도적으로 무언가를 끈 것이 언제인가입니다.
모든 변경에서 건드리기 전에 시스템을 이해하는 데 얼마나 쓰며, 가장 중요한 시스템의 버스 팩터는 얼마입니까? 프로그램 이해는 유지보수에서 가장 큰 단일 활동이고, 그 비용은 코드, 이력, 동작을 얼마나 읽기 쉽게 유지했는가로 정해집니다. 이해가 오래 근속한 몇몇 머릿속에만 있으면 모든 퇴사나 은퇴가 모든 미래 변경의 가격을 올리고, 한 명의 부재가 핵심 수정을 멈출 수 있습니다. 증거를 가져오십시오. 최근 변경에서 읽고 추론하는 시간과 편집하는 시간의 비율, 각 핵심 모듈을 안전하게 수정할 수 있는 사람의 수, 비즈니스 규칙과 결정이 코드 옆에 문서화되어 있는지 매번 기억에서 재구성되는지입니다. 상충하는 고려는 문서화와 특성화 테스트가 나중에야 드러나는 절감을 위해 지금 노력이 들어 건너뛰기 쉽다는 점입니다. 시스템이 원래 저자보다 수십 년 오래 살고 법정 규칙이 아무도 완전히 기억하지 못하는 계산 엔진에 묻혀 있는 기업과 정부에서는, 포착된 이해(아키텍처 결정 기록, 특성화 테스트, 최신 문서)를 누군가 여유가 있을 때 생기는 호의가 아니라 의도적으로 재원을 대는 자산으로 다루십시오.
유지보수 일을 실제로 누가 맡으며, 그 지위와 사기가 중요성에 걸맞습니까? 유지보수는 수명 비용의 다수이고 존재하는 가장 어려운 엔지니어링(만들지 않았고 완전히 이해하지 못할 수도 있는 시스템을 안전하게 바꾸는 것)이지만, 일상적으로 가장 경험이 적은 사람에게 넘겨지고 지위가 낮은 “불 켜 두기”로 틀지어집니다. 그 신호는 부식적입니다. 최고의 엔지니어가 그 일을 피하고, 지식이 집중되었다가 문밖으로 걸어 나가며, 아무도 보지 않는 동안 변경 비용이 오릅니다. 가장 오래 사는 시스템을 누가 유지하는지의 직급 분포, 이직과 지식 보존 데이터, 조직에서 유지보수가 경력의 막다른 길인지 존중받는 전문 분야인지에 대한 정직한 판단을 가져오십시오. 긴장은 실제입니다. 야심 있는 엔지니어는 새로운 것을 만들고 싶어 하고 리더는 출시를 축하하고 싶어 하므로, 유지보수를 존중하려면 의도적인 구조가 필요합니다. 규제와 재무 위험을 수십 년 지닌 시스템을 운영하는 대기업이나 공공 기관에서, 존중받는 시니어 엔지니어로 유지보수에 인력을 대는 것은 위험 관리 결정이며, 유지보수가 징벌 보직이 되게 두는 것이 다음 레거시 위기를 제조하는 방법입니다.
노력이 실제로 네 범주 중 어디에 속하는지 추적하며, 변경 비용을 선행 지표로 측정하고 있습니까? 팀은 일상적으로 유지보수를 대부분 버그 수정인 것처럼 계획하지만, 경험적 연구는 개선과 적응이 지배함을 보여 주므로 교정 작업에만 재원을 댄 포트폴리오는 처음부터 범위가 잘못되어 있습니다. 범주 추적이 없으면 시스템이 규제 적응의 꾸준한 흐름으로 형태가 바뀌고 있음을 볼 수 없고, 변경 비용 지표(변경 리드 타임, 변경 실패율, 복잡도 추세)가 없으면 곡선이 평평한지 위기를 향해 조용히 오르는지 알 수 없습니다. 지난해의 실제 범주 분포, 있다면 변경 비용 추세, 영향 분석이 진짜 단계인지 마감 압박 아래 건너뛰는 형식인지에 대한 정직한 메모를 가져오십시오. 상충하는 끌림은 측정 자체가 노력이 들고 시스템이 아직 동작할 때는 오버헤드처럼 느껴질 수 있다는 점입니다. 많은 팀이 많은 시스템을 유지보수하고 어느 하나의 상승하는 비용 곡선이 조치할 가치가 있는 조기 경보인 기업과 정부 포트폴리오에서, 공유된 범주 추적과 변경 비용 지표가 리더십이 모듈이 공개적으로 실패한 뒤가 아니라 저하되기 전에 재공학하게 해 줍니다.

분야별 관점

스타트업. 몇 명의 엔지니어와 짧은 런웨이로는 무거운 유지보수 프로세스를 감당할 수 없지만, 아무도 건드리지 않을 코드베이스도 감당할 수 없습니다. 예방 작업을 위해 매 주기의 작은 상시 몫(대략 5일 중 하루)을 따로 두십시오. 의존성을 패치하고, 작은 결함이 누적되기 전에 해소하고, 가진 테스트 아래서 이미 두려워하는 구석을 리팩터링하십시오. 목표는 피벗하는 동안 코드를 바꾸기 싸게 유지해, 엔지니어가 스무 명이 되어서 미뤄진 유지보수를 “레거시 문제”로 착각하며 깨어나는 일이 없게 하는 것입니다.

소기업. 전담 유지보수 전문가도 빠듯한 예산도 없으니, 적응 유지보수(보안 패치, 플랫폼과 의존성 갱신)가 대체로 다른 사람의 일이 되도록 만들기보다 사서 호스팅하는 쪽으로 기우십시오. 코드를 직접 소유하는 곳에서는 작고, 지루하고, 잘 문서화되게 유지하고, 비즈니스가 의존하는 모든 것을 적어도 두 사람이 이해하도록 하십시오. 잃을 수 없는 몇 개의 시스템을 추적하고, 유지보수가 공짜인 척하는 대신 그것들을 최신으로 유지하는 소박하고 명시적인 항목을 예산에 넣으십시오.

대기업. 규모에서는 많은 팀에 걸쳐 많은 장수 시스템을 유지보수하므로, 우선순위는 정의되고 반복 가능한 프로세스입니다. 기록되고 분류된 요청 파이프라인, 네 범주로의 분류, 일상적인 영향 분석, 협상으로 빼앗기지 않고 지켜지는 상시 예방 할당입니다. 유지보수를 일급 프로그램으로 재원을 대고, 포트폴리오 전반의 변경 비용 지표를 측정하고, 상승하는 곡선을 모듈이 부채가 되기 전에 재공학하는 계기로 쓰십시오. 거버넌스와 감사 기대에 따라 범주 추적과 변경 기록은 오버헤드가 아니라 자산이 통제 아래 있다는 증거입니다.

정부. 조달 규칙, 투명성, 공적 책임성이 엔지니어링만큼 유지보수를 형성합니다. 법령에 의한 적응 유지보수는 미룰 수 없는 엄격한 연간 마감일에 도착하므로, 유지보수를 무기한의 운영 비용으로 예산에 넣고 저자가 오래전에 은퇴한 규칙에 대한 지식을 유지할 안정적인 전문가 팀에 인력을 대십시오. 퇴역은 기록 보존법에 제약되므로 처음부터 컴플라이언스와 함께 폐기를 계획하고, 수십 년간 단일 벤더에 가두는 것보다 시스템을 유지보수 가능하고 이식 가능하게 유지하는 계약과 아키텍처를 선호하십시오.

사례

스타트업. MVP를 막 출시한 스타트업은 모든 시간을 새 기능에 쏟고 싶은 유혹을 받지만, 창업 엔지니어는 첫 달부터 매 스프린트의 상시 몫(대략 5일 중 하루)을 유지보수에 떼어 둡니다. 그 예산이 의존성을 패치된 상태로 유지하고, 작은 결함이 누적되기 전에 해소하고, 팀이 이미 두려워하는 구석을 리팩터링하여, 제품이 피벗하는 동안 코드베이스가 바꾸기 싸게 유지됩니다. 이를 건너뛰는 스타트업은 아무도 건드리고 싶어 하지 않는 코드베이스로 엔지니어 스무 명에 이르고, 그것이 내내 미뤄진 유지보수였는데도 “레거시 문제”로 착각합니다.

대기업. 한 글로벌 은행이 15년째 프로덕션에 있는 결제 플랫폼을 운영합니다. 유지보수를 잔여 예산 항목이 아니라 영구적이고 일급인 프로그램으로 재원을 댑니다. 작업은 네 범주로 분류됩니다. 새 규제와 파트너 은행 인터페이스 갱신을 따르는 적응 변경의 꾸준한 흐름, 기능을 더하고 처리량을 개선하는 완전 작업, 엄격한 서비스 수준 협약(SLA) 아래 결함을 해소하는 교정 작업, 그리고 포괄적인 테스트 스위트 아래의 지속적 리팩터링으로 복잡성을 갚는 상시 예방 할당(팀 역량의 대략 5분의 1)입니다. 팀은 변경 리드 타임과 변경 실패율을 측정하고, 상승하는 변경 비용을 모듈이 부채가 되기 전에 재공학하라는 조기 경보로 다룹니다. 유지보수자는 “불 켜 두기”에 배치된 주니어가 아니라 존중받는 시니어 엔지니어입니다.

정부. 한 국가 세무 당국이 30년 넘게 돌아왔고 세법이 바뀔 때마다 매년 개정되는 시스템을 유지보수합니다. 여기서 지배적인 범주는 법령이 이끄는 적응 유지보수이며, 미룰 수 없는 엄격한 연간 마감일이 있습니다. 당국은 프로그램 이해에 크게 투자합니다. 비즈니스 규칙은 코드 옆에 문서화되고, 특성화 테스트가 원래 저자가 오래전에 은퇴한 규칙의 동작을 못 박고, 영향 분석은 계산 엔진의 어떤 변경 전에도 공식 단계입니다. 환경(법)이 지속적으로 변하므로 시스템은 결코 “완성”될 수 없고, 그래서 당국은 유지보수를 무기한의 운영 비용으로 예산에 넣고, 지식을 유지할 안정적인 전문가 팀에 인력을 대고, 핵심이 지속되는 동안에도 소스 관리, 지속적 통합(CI), 자동화된 테스트 같은 주변 전달 실천을 현대화합니다.

비즈니스 사례: 동기, ROI, TCO

소프트웨어의 핵심적인 비즈니스 사실은 돈이 가는 곳이 구축이 아니라 유지보수라는 것입니다. 업계 전반과 수십 년의 연구에 걸쳐 유지보수는 수명 비용의 압도적 다수를 차지하며, 오래 사는 시스템에서는 흔히 60~90퍼센트로 인용되고, 기업과 정부에서는 대부분이 그렇습니다. 가동 시점에서 멈추는 총소유비용 분석은 몇 배 어긋납니다. 유지보수를 진지하게 다루는 주된 비즈니스 사례는 단순히 정확성입니다. 시스템의 전 수명을 예산에 넣거나, 청구서에 거듭 놀라거나.

투자 수익은 비용 곡선을 구부리는 데서 옵니다. 방치된 시스템에서는 복잡성이 쌓이고 이해가 쇠퇴함에 따라 각 변경의 비용이 시간이 지나며 올라, 변경이 엄청나게 느리고 위험해질 때까지 갑니다. 잘 유지보수되는 시스템에서는 지속적인 예방 작업(리팩터링, 의존성 최신화, 테스트 커버리지, 문서화)이 그 곡선을 평평하게 유지해, 천 번째 변경이 열 번째와 거의 같은 비용이 듭니다. 따라서 유지보수성과 예방 유지보수에 대한 투자는 최소화할 지출이 아닙니다. 시스템이 변경에 감당할 만하게 유지되는지, 아니면 레거시 자산(3.6장)의 늘어나는 비용과 위험, 그리고 10.4장의 지속 과제로 표류하는지를 결정하는 지렛대입니다. 유지보수에 의도적으로 재원을 대고, 변경 비용을 선행 지표로 측정하고, 상승하는 곡선을 자연법칙이 아니라 조치하라는 신호로 다루십시오. 경제성은 10.10장에서 더 다룹니다.

안티패턴과 함정

유지보수를 사후 생각으로 다루기. 구축만 예산에 넣고 축하하며, 훨씬 더 크고 긴 유지보수 단계를 굶기는 것.
가장 경험 적은 사람으로 유지보수 인력 구성. 가장 어려운 일(완전히 이해하지 못하는 시스템을 안전하게 바꾸는 것)을 가장 준비가 덜 된 사람에게 맡기고 유지보수가 낮은 지위라는 신호를 주는 것.
유지보수를 버그 수정과 혼동. 적응과 개선이 노력을 실제로 지배하는데 교정 작업만 계획하는 것.
예방 유지보수의 무기한 연기. 변경 부채가 비싼 위기를 강제할 때까지 리팩터링도 의존성 갱신도 하지 않는 것.
영향 분석 없는 코드 변경. 다른 곳의 예상치 못한 실패로 파급되는 “작은 수정”을 하는 것.
테스트 안전망 없는 리팩터링. 동작이 보존되었음을 입증할 방법 없이 코드를 재구조화하는 것. 그것은 위험한 재작성일 뿐입니다.
지식이 문밖으로 걸어 나가게 두기. 비즈니스 규칙과 결정을 문서화하지 않아, 모든 은퇴나 퇴사가 모든 미래 변경의 비용을 올리는 것.
아무것도 퇴역시키지 않기. 폐기가 화려하지 않고 계획되지 않아서 죽은 시스템과 중복 시스템을 영원히 안고 가는 것.

성숙도 모델

1단계: 시작. 유지보수가 계획도 재원도 없이 마침 여유 있는 사람이 반응적으로 처리합니다. 버그 수정으로 여겨지고 지위가 낮은 일로 취급됩니다. 범주 추적도, 비용 추정도 없고, 지식은 몇몇 머릿속에 있습니다. 변경 비용은 수정이 멈추거나 위기가 주의를 강제할 때까지 눈치채지 못한 채 오릅니다.
2단계: 발전. 일부 팀이 유지보수 요청을 기록하고 분류하기 시작했고 예산 항목을 지니지만, 실천은 조직 전체에서 일관되지 않으며 예산은 대개 잔여분입니다. 교정 작업은 추적되지만 적응과 완전 노력은 분명히 구별되지 않습니다. 일부 테스트와 문서가 구석구석 있어 변경은 부분적으로 통제되지만 이해는 팀마다 비싸고 고르지 않습니다.
3단계: 표준화. 정의된 유지보수 프로세스(ISO/IEC 14764에 따라)가 문서화되어 조직 전체에서 시행됩니다. 작업은 네 범주로 분류되고, 영향 분석과 변경 관리가 일상이며, 유지보수는 모든 비즈니스 사례에서 명시적으로 추정되고 재원이 댑니다. 예방 유지보수와 리팩터링은 탄탄한 테스트 스위트 아래의 표준 실천이고, 유지보수성(분석성, 수정성, 시험성, 모듈성)은 지역적 습관이 아니라 명시적 설계 요구 사항입니다.
4단계: 관리. 유지보수가 기준선에 대한 데이터로 측정되고 통제됩니다. 변경 비용 지표(변경 리드 타임, 변경 실패율, 복잡도와 결함 추세)가 시스템별로 추적되고, 네 범주의 노력 구성이 기대에 대해 정량화되며, 유지보수 노력 비율과 매개변수 추정이 실제 이력 변경 비용에 대해 점검됩니다. 상승하는 비용 곡선이 선행 지표로 탐지되어 조치를 촉발하고, 예방 할당은 추측이 아닌 증거로 크기가 정해집니다. 리팩터링, 재공학, 퇴역 결정은 직관이 아니라 측정된 임계값으로 내려집니다.
5단계: 오케스트레이션. 유지보수가 조직과 수명 주기 경제성 전반에 걸쳐 지속적으로 개선되고 통합됩니다. 수명 주기 TCO가 포트폴리오 투자를 이끌고, 재공학은 구성 요소가 저하되기 전에 의도적으로 적용되며, 지식이 적극 유지되고, 퇴역이 계획되어 일상적으로 실행됩니다. 조직은 환경(규제, 플랫폼, 의존성)이 이동함에 따라 유지보수 노력을 재균형하고, 유지보수자는 존중받는 시니어 엔지니어이며, 자산 전체가 적응하여 수십 년 사는 시스템 전반에서 변경 비용이 평평하게 유지됩니다.

논의를 위한 아이디어

엔지니어링 노력의 얼마가 실제로 유지보수에 가며, 예산과 인력 구성이 그 현실을 반영합니까?
유지보수 작업을 네 범주로 나눌 수 있으며, 그 구성이 가정과 맞습니까?
전형적인 변경에서 시스템을 이해하는 데 쓰는 시간과 수정하는 데 쓰는 시간의 비율은 어떠하며, 이해를 더 싸게 만들 것은 무엇입니까?
변경 비용이 시간에 따라 오르고 있습니까, 평평합니까, 내리고 있습니까, 그리고 측정은 하고 있습니까?
팀에 지속적 리팩터링을 안전하게 해 주는 신뢰할 수 있는 테스트 안전망이 있습니까, 아니면 재구조화가 시도하기에 너무 위험합니까?
가장 오래 사는 시스템을 누가 유지보수하며, 그들의 지식은 어떻게 포착되고, 그 일의 지위와 사기는 어떠합니까?

핵심 요점

유지보수는 소프트웨어 수명 비용의 다수(오래 사는 시스템에서 흔히 60~90퍼센트)이며 일급 활동으로 계획되고, 예산이 잡히고, 인력이 구성되어야 합니다.
네 범주(교정, 적응, 완전, 예방)는 구별되는 작업이며, 버그 수정이 아니라 개선과 적응이 대개 지배합니다.
프로그램 이해는 가장 큰 단일 유지보수 활동입니다. 모든 변경이 싸게 유지되도록 코드, 이력, 동작을 읽을 수 있게 만드십시오.
테스트 안전망 아래서 지속적으로 리팩터링하고 저하된 구성 요소를 점진적으로 재공학해 변경 비용을 평평하게 유지하십시오.
유지보수 비용을 명시적으로 추정하고 총소유비용과 경제적 결정에 공급하십시오.
처음부터 유지보수성을 위해 설계하고(전체 수명 주기에서 수익이 가장 높은 투자입니다) 유지보수자를 그들이 되어야 할 시니어 전문가로 대우하십시오.

참고 문헌과 더 읽을거리

IEEE Computer Society, SWEBOK Guide (Software Engineering Body of Knowledge), Software Maintenance knowledge area
ISO/IEC 14764 / IEEE 14764, Software Engineering: Software Life Cycle Processes, Maintenance
ISO/IEC 25010, Systems and software Quality Requirements and Evaluation (SQuaRE): maintainability quality characteristics
Martin Fowler, Refactoring: Improving the Design of Existing Code
Michael Feathers, Working Effectively with Legacy Code
Thomas M. Pigoski, Practical Software Maintenance
Penny Grubb and Armstrong A. Takang, Software Maintenance: Concepts and Practice
Barry Boehm et al., Software Cost Estimation with COCOMO II (maintenance and reuse models)
Meir M. Lehman, “Laws of Software Evolution” (on why software must continually change or become less useful)
Robert C. Seacord, Daniel Plakosh, and Grace A. Lewis, Modernising Legacy Systems