SW 유지보수의 유형과 운영 프로세스

운영 이후부터 시작되는 소프트웨어 관리

소프트웨어는 인도 시점에 끝나지 않는다. 운영 중 발견되는 결함을 고치고, 성능과 속성을 개선하며, 운영체제·하드웨어·법규처럼 달라지는 환경에 맞춰 계속 조정해야 한다. ISO/IEC 14764도 사용자에게 전달된 뒤 오류 수정, 성능 향상, 환경 적응을 수행하는 과정을 SW 유지보수로 본다.

유지보수는 시스템 수명과 사용자 만족도, 투자 수익률(ROI)에 직접 연결된다. 소프트웨어 수명주기 비용 가운데 유지보수가 차지하는 비중은 평균 60~80%이므로, 이를 단순한 사후 지원으로 다루기 어렵다.

변경의 성격에 따라 달라지는 유지보수

운영 요청은 원인과 목적에 따라 다르게 판단해야 한다.

수정 유지보수(Corrective Maintenance)는 운영 중 확인된 오류나 결함을 바로잡는 활동이다. 사용자 보고나 시스템 모니터링에서 문제가 발견되는 경우가 많고, 긴급 대응이 필요한 상황도 생긴다. 뱅킹 시스템의 특정 거래 유형에서 발생한 계산 오류나 웹 애플리케이션의 예기치 않은 세션 종료 문제가 여기에 해당한다.

적응 유지보수(Adaptive Maintenance)는 운영체제, 하드웨어, 법규 등 외부 환경의 변화에 맞추는 작업이다. 기능 자체는 바꾸지 않으면서 새로운 운영체제 버전에 맞게 코드를 수정하거나, 새로운 개인정보보호법을 준수하도록 데이터 처리 로직을 변경하는 경우가 대표적이다.

완전 유지보수(Perfective Maintenance)는 사용자 요구를 반영해 기능이나 성능을 개선한다. 사용자 인터페이스를 개선해 사용성을 높이거나 알고리즘을 최적화해 처리 속도를 높이는 작업처럼, 기존 시스템의 가치를 확장하는 데 초점이 있다.

예방 유지보수(Preventive Maintenance)는 미래의 변경과 수정을 수월하게 만들기 위한 선제적 조치다. 리팩토링으로 코드의 가독성과 구조를 정비하고, 자동화된 테스트 케이스를 추가해 품질 보증을 강화하는 활동이 포함된다. 코드 품질과 기술 부채를 장기적으로 관리하는 수단이기도 하다.

요청부터 사후 검토까지 이어지는 흐름

유지보수는 개별 수정 작업처럼 보이지만, 운영에서는 요청을 받아 다음 변경으로 학습을 되돌리는 순환 과정으로 관리된다.

⤢✕

요청 접수 단계에서는 내부·외부 사용자의 변경 요청과 버그 리포트를 모으고, JIRA나 Bugzilla 같은 이슈 트래킹 시스템으로 관리한다. 이어 요청을 수정·적응·완전·예방 유지보수로 분류하고, 범위·복잡성·필요 자원을 평가한다.

우선순위는 비즈니스 중요도, 사용자 영향, 시급성을 기준으로 정하며 이해관계자와 협의한다. 구현 전에는 변경이 다른 부분에 미칠 영향을 살피고 의존성을 매핑하며 리스크를 평가해야 한다. 이 결과를 바탕으로 변경 설계, 구현 방법, 필요 리소스와 일정을 계획한다.

구현 과정에는 코드 작성과 수정뿐 아니라 코드 리뷰, 품질 관리 활동이 포함된다. 이후 단위 테스트, 통합 테스트, 시스템 테스트, 회귀 테스트를 수행하고 자동화를 활용해 효율을 확보한다. 릴리스 후에는 프로덕션 환경에 배포하고 사용자 교육과 문서 업데이트를 진행한다. 마지막 사후 검토에서 변경의 효과와 문제점을 평가하고, 다음 유지보수 활동에 반영할 피드백을 수집한다.

유지보수를 어렵게 만드는 운영 조건

레거시 시스템은 문서 부족, 기술 노후화, 원 개발자 부재 때문에 다루기 어렵다. 복잡한 의존성과 파악하기 힘든 코드 구조도 변경 비용을 키운다. 기존 시스템의 구조와 동작 원리를 재구성하는 역공학(Reverse Engineering), 한 번에 교체하지 않는 점진적 현대화, 코드 분석·문서화 도구 활용이 대응 수단이 된다.

기술 부채는 단기 해결책이 누적되면서 코드 품질을 떨어뜨리고 유지보수 비용을 높이는 문제다. 정적 코드 분석 도구로 부채를 측정하고, 계획적인 리팩토링으로 상환하며, CI/CD 파이프라인에 품질 게이트를 두는 방식으로 관리할 수 있다.

개발자 이직은 시스템 지식의 유실로 이어지고, 시스템이 복잡해질수록 새 구성원의 학습 곡선도 가팔라진다. 위키와 문서 관리 시스템으로 지식 베이스를 구축하고, 페어 프로그래밍·코드 리뷰로 공유 문화를 만들며, 코드 주석을 활용한 API 문서 자동 생성으로 지식을 보존할 수 있다.

변경 범위를 파악하기 어려운 상태에서 회귀 테스트까지 수작업으로 수행하면 비용이 커진다. 단위·통합·E2E 테스트를 자동화하고, 코드 변경 전에 테스트를 작성하는 테스트 주도 개발(TDD)을 적용하며, 빌드·테스트·배포를 잇는 CI/CD 파이프라인을 갖추는 일이 품질 보증의 기반이 된다.

변경하기 쉬운 시스템으로 만드는 선택

아키텍처에서는 시스템을 독립적인 모듈로 나눠 변경의 영향 범위를 줄이는 것이 출발점이다. 대규모 시스템은 독립적으로 배포·관리할 수 있는 작은 서비스로 분리하는 마이크로서비스 아키텍처를 택할 수 있다. 비즈니스 로직, 데이터 액세스, UI처럼 관심사를 분리하는 것도 유지보수성을 높인다.

⤢✕

코드 차원에서는 가독성·단순성·명확성을 갖춘 클린 코드 원칙, 검증된 디자인 패턴, 일관된 코딩 스타일과 명명 규칙이 필요하다. 순환 복잡도(Cyclomatic Complexity)를 낮게 유지하는 일도 변경 이해와 검증의 부담을 줄인다.

프로세스 차원에서는 정기적인 리팩토링 일정을 두고, 기술 부채를 식별·추적·해결하는 계획을 운영해야 한다. 코드 품질과 유지보수성 지표를 모니터링하고, 시스템 지식을 보존·공유하는 체계를 함께 갖춰야 한다.

자동화가 바꾸는 유지보수 운영

DevOps와 CI/CD는 개발과 운영을 연결해 배포와 피드백 순환을 빠르게 만든다. 자동화된 테스트·빌드·배포 파이프라인은 유지보수 효율을 높이고, 인프라스트럭처 코드화(IaC)는 환경의 일관성을 확보한다.

클라우드 네이티브 접근에서는 클라우드 환경에 맞춘 아키텍처로 확장성과 복원력을 높인다. Docker 기반 컨테이너화와 Kubernetes 오케스트레이션은 배포 관리를 단순화하고, 서버리스 컴퓨팅은 인프라 관리 부담을 낮춘다.

AI 기반 코드 분석은 잠재적 문제를 조기에 찾는 데 활용할 수 있다. 자동화된 코드 생성과 수정은 반복 작업을 줄이며, 지능형 모니터링 시스템은 이상 징후를 미리 감지하는 역할을 한다.

품질 관리에는 SonarQube, ESLint 같은 정적 코드 분석 도구와 JaCoCo, Istanbul 같은 코드 커버리지 도구를 활용할 수 있다. Elasticsearch, Logstash, Kibana으로 구성된 ELK 스택은 로그 분석과 모니터링에 쓰인다.

유지보수는 버그 수정만으로 끝나지 않는다. 설계 단계부터 변경 가능성을 고려하고, 지속적인 리팩토링·품질 관리·지식 보존을 이어 갈 때 시스템의 복잡성을 관리하면서 장기 가치를 지킬 수 있다.