소프트웨어 유지보수의 유형과 변경 관리

배포 뒤에 시작되는 소프트웨어의 관리

소프트웨어는 사용자에게 전달된 뒤부터 폐기될 때까지 계속 바뀐다. 이 기간의 수정, 환경 적응, 기능 개선을 다루는 활동이 소프트웨어 유지보수다. 전체 소프트웨어 생명주기(SDLC) 비용 가운데 유지보수가 차지하는 비중은 약 70~80%에 이른다.

유지보수는 버그를 고치는 업무만 뜻하지 않는다. 발견된 결함을 제거하고, 운영 환경 변화에 맞춰 시스템을 조정하며, 새로운 요구에 따라 기능이나 성능을 개선하는 일이 함께 포함된다. 시스템의 생명주기를 늘리고 운영 효율을 유지하기 위한 관리 활동에 가깝다.

기능이 복잡해질수록 문서화와 변경 이력 관리도 기하급수적으로 늘어난다. 이를 통제하지 못하면 시스템은 관리하기 어려운 스파게티 코드가 될 수 있다. 초기 개발비보다 운영 중 비용이 더 커질 수 있다는 점에서, 유지보수 전략은 TCO(Total Cost of Ownership)와도 직접 연결된다.

변경의 목적에 따라 달라지는 유지보수

ISO/IEC 14764는 유지보수를 변경 목적에 따라 구분한다. 각각은 시스템 안정성과 변화 수용력을 다른 방식으로 다룬다.

수정 유지보수

수정 유지보수(Corrective Maintenance)는 배포 후 드러난 오류나 설계 결함을 바로잡는 활동이다. 사용자가 신고한 버그를 해결하거나 비정상 종료 문제를 수정하는 작업이 여기에 속한다.

적응 유지보수

적응 유지보수(Adaptive Maintenance)는 외부 환경이 변했을 때 소프트웨어가 계속 동작하도록 조정하는 일이다. 운영체제(OS) 업그레이드, 하드웨어 교체, 데이터베이스 마이그레이션, 법규와 정책의 변화가 대표적인 계기다.

완전화 유지보수

완전화 유지보수(Perfective Maintenance)는 성능을 높이거나 기능을 추가해 소프트웨어의 가치를 높이는 활동이다. 기존 기능의 처리 속도를 개선하거나 유지보수성을 높이기 위한 코드 리팩토링이 포함되며, 전체 유지보수 활동 중 가장 큰 비중을 차지한다.

예방 유지보수

예방 유지보수(Preventive Maintenance)는 앞으로 발생할 수 있는 문제를 미리 찾아 수정하는 방식이다. 결함을 사전에 막고 신뢰성을 높이며, 이후의 유지보수가 쉬워지도록 구조를 개선한다.

요청을 운영 반영까지 추적하는 흐름

유지보수에서 변경은 기록과 승인 없이 진행되어서는 안 된다. 요청의 배경과 영향 범위를 남기고, 우선순위를 정한 뒤 구현과 테스트를 거쳐 운영 환경에 반영해야 변경 이력을 추적할 수 있다.

변경 관리에는 다음과 같은 양식이 사용된다.

CR (Change Request): 사용자가 시스템 변경을 공식 요청하는 서류
MRF (Modification Request Form): 필요한 수정 내용을 구체적으로 기록하는 양식
SCR (Software Change Report): 변경 요청 분석 결과와 수정 완료 내용을 남기는 보고서

요청이 접수되면 영향도 분석(Impact Analysis)을 수행해 변경의 우선순위와 비용을 검토한다. 승인된 변경은 구현과 리그레션 테스트를 거쳐 보고서에 기록한 뒤 운영 환경에 반영한다.

⤢✕

변화가 누적될 때 나타나는 성질

리먼(Lehman)은 시간이 흐르며 소프트웨어가 변화하는 과정을 다음 원리로 설명했다.

계속적 변화(Continuing Change): 환경에 적응하려면 소프트웨어는 지속적으로 변경되어야 한다.
복잡도 증가(Increasing Complexity): 변경이 반복될수록 구조는 복잡해지므로 이를 억제하려는 노력이 필요하다.
자기 조절(Self Regulation): 소프트웨어 진화 과정은 통계적으로 유의미한 결정론적 추세를 보인다.
조직적 안정성(Organizational Stability): 프로젝트 리소스와 관계없이 개발 속도는 일정 수준을 유지한다.
친숙도 유지(Conservation of Familiarity): 사용자와 개발자가 이해할 수 있도록 변경량은 시스템 전체 크기에 비례해 일정하게 유지되어야 한다.

이 원리는 유지보수를 단순한 수정 작업으로 볼 수 없는 이유를 보여준다. 변경 자체는 피할 수 없지만, 축적되는 복잡도와 이해 비용은 관리 대상이 된다.

레거시 시스템을 다루는 3R 기법

노후화된 시스템의 유지보수성을 높이고 현대화를 추진할 때는 역공학, 재구조화, 재공학이 활용된다.

역공학

역공학(Reverse Engineering)은 완성된 제품이나 코드를 분석해 설계 사양서, 요구 분석 명세서 같은 상위 단계 산출물을 추출하는 과정이다. 문서가 유실된 레거시 시스템의 구조와 동작을 파악하는 데 쓰인다.

재구조화

재구조화(Restructuring)는 외부 기능을 유지한 채 내부 논리 구조를 개선하는 활동이다. 코드 가독성을 높이고 복잡도를 낮추는 리팩토링이 대표적이며, 유지보수성을 높이는 데 목적이 있다.

재공학

재공학(Re-engineering)은 기존 시스템을 바탕으로 새로운 기술을 도입해 시스템을 다시 구축하는 과정이다. 역공학으로 얻은 정보를 바탕으로 데이터 모델이나 기능을 개선해 더 나은 품질의 시스템으로 전환한다.

유지보수는 시스템의 가치를 계속 만들어 내고 비즈니스 연속성을 뒷받침하는 활동이다. 수정·적응·완전화·예방의 관점을 함께 적용하고, 변화 과정에서 생기는 복잡도를 관리해야 한다. 3R 기법은 기술 부채를 다루고 전체 생명주기 비용을 최적화하는 수단이 된다.

Sources

ISO/IEC 14764: Software Engineering — Software Life Cycle Processes — Maintenance
Lehman, M. M., "Programs, Cities and Laws: Limits to Determinism," 1980
Roger S. Pressman, "Software Engineering: A Practitioner's Approach"
국가직무능력표준(NCS) 정보기술 개발 - 소프트웨어 유지보수 가이드라인