[SW Engineering] 09. 유지보수와 레거시 전략(Software Evolution)

소프트웨어 개발이 끝났다고 프로젝트가 끝난 것이 아닙니다. 오히려 배포 후(Post-delivery)가 진정한 시작입니다. 비즈니스 환경은 끊임없이 변하고, 그에 맞춰 소프트웨어도 계속 진화해야 하기 때문입니다.

이번 포스팅에서는 소프트웨어 진화의 중요성, 레거시 시스템 관리 전략, 그리고 코드 품질을 위한 리팩터링에 대해 다루어 보겠습니다.

1. 소프트웨어 진화의 중요성 (Importance of Evolution)

1) 변화는 피할 수 없다 (Inevitable)

소프트웨어는 한번 만들어지면 끝이 아니라, 계속해서 변해야 합니다.

• 새로운 요구사항이 생겨나고, 비즈니스 환경이 변하며, 에러를 수정해야 하고, 장비가 업그레이드되기 때문입니다.

2) 시스템의 분류 (Lehman's Law)

• S-타입 시스템 (Static-type): 스펙이 한번 정해지면 절대 변하지 않는 시스템입니다. (현실 세계에 거의 존재하지 않음).
• E-타입 시스템 (Embedded-type): 실제 세계 환경에 포함되어 있어, 환경이 변함에 따라 지속적으로 진화해야 하는 시스템입니다. (대부분의 소프트웨어가 여기에 해당).

3) 유지보수 비용의 현실

• 대부분의 소프트웨어 예산은 새로운 개발보다 기존 시스템을 진화(유지보수)시키는 데 사용됩니다.
• 개발자 시간의 35%~50%가 디버깅과 유지보수에 쓰입니다.

---

2. 진화 프로세스 (Evolution Processes)

소프트웨어 수명 주기는 크게 3단계로 구분됩니다.

1) 진화 단계 (Evolution)

• 시스템이 운영 중이며, 새로운 요구사항에 맞춰 기능 추가와 변경이 활발히 일어나는 단계입니다.

2) 서비스 단계 (Servicing)

• 더 이상 대규모 기능 추가는 하지 않습니다. 시스템이 계속 작동하도록 버그 수정이나 환경 변화(OS 패치 등)에 대한 대응만 수행합니다.

3) 폐기 단계 (Phase-out)

• 시스템이 더 이상 유용하지 않아 사용을 중단하거나 교체하는 단계입니다.

---

3. 레거시 시스템 (Legacy Systems)

"오래된 기술로 만들어졌지만, 비즈니스에 너무 중요해서 버리지 못하고 계속 쓰는 시스템"을 말합니다.

1) 레거시 시스템의 구성 요소

단순히 코드만 낡은 것이 아니라, 모든 것이 얽혀 있습니다.

• 시스템 하드웨어: 더 이상 생산되지 않는 구형 장비 (메인프레임 등).
• 지원 소프트웨어: 업데이트가 끊긴 구버전 OS나 컴파일러.
• 응용 소프트웨어: 비즈니스 로직을 담고 있는 낡은 프로그램.
• 응용 데이터: 오랫동안 쌓여 일관성이 없고 중복된 데이터.
• 비즈니스 프로세스: 시스템의 제약 때문에 굳어진 비효율적인 업무 방식.

2) 레거시 시스템 평가 및 전략 (Assessment Strategy)

시스템의 비즈니스 가치(Business Value)와 시스템 품질(System Quality)을 평가하여 4분면 매트릭스로 전략을 결정합니다.

비즈니스 가치 (Business Value)	시스템 품질 (System Quality)	전략 (Strategy)	설명
낮음 (Low)	낮음 (Low)	폐기 (Scrap)	쓸모도 없고 품질도 나쁘므로 완전히 폐기합니다.
높음 (High)	낮음 (Low)	개조/재공학 (Transform/Re-engineer)	중요하지만 품질이 낮으므로, 재공학을 통해 품질을 개선하거나 교체합니다.
낮음 (Low)	높음 (High)	교체/유지 (Replace/Maintain)	품질은 좋지만 가치가 낮으므로, COTS(상용 제품)로 교체하거나 현상 유지합니다.
높음 (High)	높음 (High)	유지보수 (Maintain)	가장 이상적인 상태. 현재 상태로 계속 유지보수하며 사용합니다.

각 시나리오를 통해 각 상황에서 어떤 전략을 사용할지 살펴봅시다.

시나리오 1: 15년 된 시스템, 개발사 지원 종료. 인사/급여 등 필수 업무 담당(High Value). 하지만 사용하기 어렵고 고장이 잦음(Low Quality).

비즈니스 가치는 높으나 시스템 품질이 낮음 (High Value, Low Quality). 따라서 이 경우에는 교체(Replace) 전략을 사용해야 합니다. 왜냐하면 유지보수 비용이 매우 높을 것으로 예상됩니다. 원래는 재공학(Re-engineering)도 고려할 수 있으나, 개발사 지원이 종료되었으므로 리스크를 감수하고 새로운 시스템으로 완전히 교체(Replace)하는 것이 적합합니다.

 

시나리오2: 10년 이상 운영, 고객 증가로 사업 성장 중(High Value). 핵심 개발 인력이 회사에 남아있어 시스템 이해도가 높음(High Maintainability/Quality). 모바일 등 신규 요구사항 증가.

이 시나리오에서는 비즈니스 가치도 높고, 핵심 인력이 있어 유지보수 품질도 확보됨. 따라서 이 경우에는 진화 및 리팩터링 (Evolution with Refactoring) 전략이 효율적입니다. 왜냐하면 시스템이 비즈니스에 기여하는 바가 크고 유지보수가 가능하므로, 전면 교체(Replace)의 리스크를 짊어질 필요가 없습니다. 현재 시스템을 유지(Maintain)하면서, 모바일 지원 등 변화하는 요구사항에 맞춰 아키텍처를 개선(Refactoring)하는 것이 최선입니다.

---

4. 소프트웨어 유지보수 (Software Maintenance)

1) 유지보수의 정의

소프트웨어가 인도(Delivery)된 이후에 발생하는 모든 변경 활동입니다.

2) 유지보수의 유형 및 비용 비중

• 기능 추가/수정 (Functionality Addition): 새로운 요구사항 반영. (58% - 비용이 제일 큼!)
• 결함 수정 (Fault Repair): 버그 수정. (24%)
• 환경 적응 (Environmental Adaptation): OS나 하드웨어 변경 대응. (19%)

---

5. 재공학 vs 리팩터링 (Re-engineering vs Refactoring)

둘 다 시스템을 개선하는 것이지만, 목적과 시기가 다릅니다.

• 재공학: 유지보수 비용이 한계에 다다랐을 때 수행하는 대규모 프로젝트입니다.
• 리팩터링: 개발과 진화 과정에서 수시로, 지속적으로 수행하는 일상적인 활동입니다.

 

6. 리팩터링: 코드의 악취 (Bad Smells)

리팩터링이 필요한 신호를 '악취(Bad Smells)'라고 부릅니다.

1. 중복 코드 (Duplicate Code): 똑같은 코드가 여러 곳에 복사되어 있음. → 메서드로 추출하여 제거.
2. 긴 메서드 (Long Methods): 함수 하나가 너무 길고 많은 일을 함. → 여러 개의 작은 메서드로 분리.
3. Switch 문 (Switch Statements): 타입에 따라 분기하는 코드가 여기저기 흩어져 있음. → 객체지향의 다형성(Polymorphism)으로 해결.
4. 데이터 뭉치 (Data Clumping): name, age, phone 처럼 항상 같이 다니는 데이터들. → 하나의 객체(Class)로 묶음.
5. 추측성 일반화 (Speculative Generality): "나중에 필요할지도 몰라"라며 미리 복잡하게 만든 구조. → 과감히 삭제 (YAGNI 원칙).

---

7. 정리

소프트웨어는 S-타입이 아니라 E-타입이므로 끊임없이 진화해야 합니다. 특히 레거시 시스템은 '가치 vs 품질' 매트릭스를 통해 교체할지 유지할지 냉철하게 판단해야 합니다. 개발 과정에서는 코드의 악취를 지속적인 리팩터링으로 제거해야 건강한 시스템을 유지할 수 있습니다.