서론

소프트웨어 시스템의 수명과 진화

• 소프트웨어 시스템 수명: 대형 소프트웨어 시스템은 긴 수명을 가짐. 예: 군사 및 인프라 시스템 (항공 교통 관제 시스템) 30년 이상, 비즈니스 시스템 10년 이상.
• 운영 소프트웨어의 진화: 시스템은 비즈니스 변화, 사용자 기대 변화에 따라 진화해야 함. 오류 수정, 하드웨어 및 소프트웨어 플랫폼 변경에 맞추어 수정 필요.
• 소프트웨어 진화 비용: 대부분의 기업은 기존 시스템 유지보수에 더 많은 비용을 지출. 진화 비용은 전체 소프트웨어 비용의 60%에서 90%를 차지할 수 있음.
• 브라운필드 소프트웨어 개발: 기존 시스템들이 상호 의존하는 환경에서 소프트웨어를 개발하고 관리하는 상황. 하나의 시스템 변경은 다른 시스템에도 영향을 미침.

소프트웨어 개발 및 진화 모델

1. 초기 개발: 릴리스 1을 생성하고 배포 후 변경 사항 제안, 릴리스 2 개발.
2. 나선형 프로세스: 요구사항, 설계, 구현, 테스트가 시스템 수명 동안 지속적으로 진행.
3. 진화 주기 단축: 최근 10년간 반복 주기 단축, 앱 및 웹 시스템은 사용자 피드백에 빠르게 반응.
4. 소프트웨어 유지보수: 외부 업체와의 계약, 개발 및 유지보수 간 불연속성 발생. 진화가 아닌 유지보수 단계에서는 작은 변경만 이루어짐.

소프트웨어 진화 단계

• 진화 단계: 요구사항 변경 및 시스템 변경이 자주 발생, 시스템 구조가 악화됨.
• 유지보수 단계: 주요 변경 없이 작은 변경만 발생. 시스템 교체를 고려하는 단계.
• 퇴출 단계: 시스템이 더 이상 사용되지 않으며, 데이터는 새 시스템으로 이전됨.

---

9.1 Evolution processes

소프트웨어 진화 프로세스

• 소프트웨어 진화 프로세스: 소프트웨어 진화 과정은 시스템 유형, 조직의 개발 프로세스, 참여자의 기술에 따라 다름.
  • 비공식적 진화: 모바일 앱처럼 사용자의 피드백을 통해 진화.
  • 공식적 진화: 임베디드 시스템처럼 문서화가 철저한 진화.

변경 제안

• 변경 제안: 개인 또는 그룹이 기존 소프트웨어 시스템에 대한 변경 및 업데이트를 제안.
  • 기존 요구사항, 새로운 요구사항, 버그 리포트, 개선 아이디어 등이 제안의 기반이 됨.
• 변경 제안 분석: 변경이 필요한 시스템 구성 요소 분석 후 비용과 영향을 평가.
  • 변경이 승인되면 새로운 릴리스 계획 수립.

소프트웨어 진화 과정

1. 변경 분석: 변경이 필요한 구성 요소 식별.
2. 릴리스 계획: 제안된 변경 사항(버그 수정, 기능 추가 등)을 다음 버전에서 적용할 것인지 결정.
3. 시스템 구현 및 배포: 새로운 버전 구현 후 고객에게 배포.
4. 반복 과정: 변경 제안이 반복적으로 이루어짐.

개발과 진화의 차이점

• 개발과 진화의 차이:
  • 개발: 새로운 시스템을 처음부터 설계하고 구현.
  • 진화: 기존 시스템에 대해 새로운 피드백을 반영하여 변경.
• 프로그램 이해: 새로운 개발자가 시스템을 이해하는 단계가 진화에서 중요함. 기존 시스템에서 변경 사항을 추가할 때 기존 시스템 구조에 미치는 영향을 분석해야 함.

긴급 수정 및 애자일 방법

• 긴급 수정 필요 시:

  • 시스템 장애나 보안 취약점 해결을 위한 빠른 수정.
  • 문서화 문제: 변경 사항을 급하게 적용하면 요구사항 및 설계 문서와 코드가 일치하지 않을 위험 있음. 이는 문서화가 적은 애자일 방식에서 문제가 될 수 있음.
  • 코드 리팩토링: 긴급 수정 후에는 코드 리팩토링을 통해 프로그램 악화 방지.
  • 긴급 수정 시: 시스템 구조에 맞지 않는 빠른 해결책을 선택할 수 있으며, 이는 미래 변경을 어렵게 만듦.

• 애자일 방법 사용:

  • 애자일 개발 방법은 시스템 진화에도 적용 가능.
  • 개발팀에서 진화팀으로 넘어갈 때 문제 발생:
    1. 개발팀이 애자일 방식을 사용했지만 진화팀은 계획 기반 방법을 선호.
    2. 계획 기반 개발 후 애자일 방법을 사용하는 경우 새로운 테스트 코드 개발을 시작해야 하거나, 리팩토링이 필요할 수 있음.

---

9.2 Legacy systems

레거시 시스템

• 기존의 시스템이지만, 새로운 시스템 개발에 사용되지 않는 오래된 기술과 언어에 의존하는 시스템. 많은 경우, 시간이 지나면서 유지 관리가 되었고, 그 구조는 여러 번의 변경으로 인해 악화될 수 있음.
• 레거시 시스템은 단순한 소프트웨어 시스템이 아니라 하드웨어, 소프트웨어, 라이브러리, 지원 소프트웨어 및 비즈니스 프로세스를 포함하는 더 넓은 사회 기술적 시스템임.

주요 구성 요소

1. 시스템 하드웨어:

   • 더 이상 사용되지 않거나 비싸게 유지 관리되어 현재 조직의 IT 구매 정책과 호환되지 않는 하드웨어.

2. 지원 소프트웨어:

   • 운영 체제, 유틸리티 등과 같은 레거시 시스템에서 사용하는 지원 소프트웨어. 이 소프트웨어는 더 이상 원래 제공업체에 의해 지원되지 않을 수 있음.

3. 애플리케이션 소프트웨어:

   • 비즈니스 서비스를 제공하는 애플리케이션 시스템으로, 여러 번 개발된 다양한 애플리케이션 프로그램으로 구성됨.

4. 애플리케이션 데이터:

   • 시스템에서 처리되는 데이터. 많은 레거시 시스템에서는 데이터가 비일관적이고 중복되어 있으며 여러 데이터베이스에 분산되어 있음.

5. 비즈니스 프로세스:

   • 비즈니스 목표를 달성하기 위해 사용되는 프로세스. 예를 들어, 보험 회사에서는 보험 증권을 발급하는 프로세스가 비즈니스 프로세스에 해당.

6. 비즈니스 정책과 규칙:

   • 비즈니스가 어떻게 수행되어야 하는지와 비즈니스에 대한 제약 조건을 정의한 규칙들. 레거시 시스템은 이러한 정책과 규칙에 포함될 수 있음.

레거시 시스템의 구성 요소를 레이어로 나누어 보기

• 각 층은 바로 아래 층에 의존하고 해당 층과 인터페이스를 가짐.
• 변경된 한 층이 다른 층에 영향을 미칠 수 있는 경우:

1. 새로운 기능 추가:
   • 시스템의 한 층을 변경하면 새로운 기능이 도입될 수 있으며, 이에 따라 상위 층도 이 기능을 활용하기 위해 수정될 수 있음.
2. 성능 저하로 인한 하드웨어 필요:
   • 소프트웨어를 변경하면 시스템 성능이 저하될 수 있으며, 이로 인해 하드웨어 성능 향상이 필요하게 될 수 있음.
3. 하드웨어 인터페이스 유지의 어려움:
   • 새로운 하드웨어가 도입되면 하드웨어 인터페이스를 유지하는 것이 불가능할 수 있으며, 특히 임베디드 시스템에서는 소프트웨어와 하드웨어의 결합이 강하기 때문에 하드웨어 변경에 맞춰 소프트웨어 변경이 필요할 수 있음.

레거시 시스템 관리

새로운 소프트웨어 시스템 개발

• 현대의 소프트웨어 엔지니어링 프로세스(애자일 개발, 소프트웨어 제품 라인 등)를 사용한 새로운 시스템 개발은 시스템 개발과 진화를 계획적으로 통합할 수 있음.
• 많은 기업들이 시스템 개발 프로세스를 전체 생애 주기 관점에서 이해하고 있으며, 소프트웨어 개발과 진화를 분리하는 것은 비효율적이고 비용이 더 많이 들 수 있음.

레거시 시스템의 진화 전략

1. 시스템 완전 폐기:
   • 시스템이 비즈니스 프로세스에 효과적으로 기여하지 않는 경우 선택. 비즈니스 프로세스가 변경되어 시스템이 더 이상 필요 없는 경우.
2. 시스템 변경 없이 정기적인 유지보수:
   • 시스템이 여전히 필요하지만 안정적이며 사용자의 변경 요청이 적을 경우 선택.
3. 시스템 리엔지니어링:
   • 시스템 품질이 저하되었고 여전히 새로운 변경이 요구될 경우 선택. 다른 시스템과의 연동을 위한 새로운 인터페이스 컴포넌트 개발 포함.
4. 전체 또는 일부 시스템 교체:
   • 새로운 하드웨어가 필요하거나, 상용 소프트웨어를 통해 비용 효율적으로 새로운 시스템을 개발할 수 있는 경우 선택. 점진적인 교체 전략을 통해 주요 시스템 부품을 상용 시스템으로 교체하고, 다른 부품은 가능한 한 재사용.

레거시 시스템 평가 관점

• 비즈니스 관점: 시스템이 정말로 필요한지 여부 결정.
• 기술 관점: 애플리케이션 소프트웨어, 지원 소프트웨어 및 하드웨어의 품질 평가.

시스템 평가 예시

1. 낮은 품질, 낮은 비즈니스 가치:
   • 이 시스템을 운영하는 것은 비용이 많이 들고 비즈니스에 대한 반환이 적음. 이러한 시스템은 폐기해야 함.
2. 낮은 품질, 높은 비즈니스 가치:
   • 중요한 비즈니스 기여를 하지만 품질이 낮아 유지보수가 비쌈. 이러한 시스템은 리엔지니어링을 통해 품질을 개선하거나 적합한 상용 시스템으로 교체해야 함.
3. 높은 품질, 낮은 비즈니스 가치:
   • 비즈니스 기여가 적지만 유지보수 비용이 크지 않은 시스템. 시스템 교체가 불필요하면 정상 유지보수를 지속하고, 비싼 변경이 필요하면 폐기해야 함.
4. 높은 품질, 높은 비즈니스 가치:
   • 이 시스템은 계속 운영해야 하며, 높은 품질 덕분에 시스템 교체나 변환에 투자할 필요 없음. 정상적인 유지보수를 계속해야 함.

비즈니스 가치 평가

1. 시스템 사용 빈도:
   • 시스템이 가끔만 사용되거나 소수의 사람만 사용하는 경우 비즈니스 가치가 낮을 수 있음. 그러나 중요한 목적에 사용된다면 비즈니스 가치가 높을 수 있음. 예를 들어, 대학의 학생 등록 시스템은 학기 초에만 사용되지만 필수적인 시스템으로 높은 비즈니스 가치를 가질 수 있음.
2. 지원하는 비즈니스 프로세스:
   • 시스템 도입으로 인해 비즈니스 프로세스가 효율화되었거나, 시스템의 제약으로 비즈니스 프로세스가 비효율적으로 변화했을 수 있음. 시스템이 변화에 유연하지 않으면 비즈니스 가치가 낮아질 수 있음.
3. 시스템의 신뢰성:
   • 시스템이 신뢰할 수 없으면 비즈니스 고객에게 직접적인 영향을 미치거나, 문제를 해결하기 위해 다른 업무에 시간을 뺏길 수 있음. 신뢰성이 낮으면 비즈니스 가치도 낮아짐.
4. 시스템 출력의 중요성:
   • 시스템 출력이 비즈니스 성공에 중요한 경우 비즈니스 가치가 높음. 반면, 출력이 다른 방법으로 쉽게 생성될 수 있거나 드물게 사용되면 비즈니스 가치가 낮음.

비즈니스 가치 평가 예시

1. 여행 주문 시스템:

   • 직원들이 여행을 예약하기 위해 사용하는 시스템이 있지만, 실제로 이 시스템은 전체 여행 주문 중 소수의 비율만 처리. 사람들은 더 저렴하고 편리한 방법으로 여행 공급업체의 웹사이트를 통해 예약을 처리. 이 경우 시스템은 여전히 사용되지만 외부 시스템에서 동일한 기능을 제공하므로 유지할 필요가 없음.

2. 고객 주문 추적 시스템:

   • 고객의 이전 주문을 추적하고 재주문 알림을 자동으로 생성하는 시스템은 반복 주문을 증가시키고 고객 만족도를 높임. 이 시스템의 출력은 비즈니스에 중요하므로 높은 비즈니스 가치를 가짐.

기술적 관점에서의 시스템 평가

• 시스템을 기술적 관점에서 평가하려면 애플리케이션 시스템 자체와 그 시스템이 운영되는 환경을 고려해야 함.
• 환경에는 하드웨어와 시스템 유지보수를 위한 컴파일러, 디버거 및 개발 환경과 같은 지원 소프트웨어가 포함됨.
• 환경은 시스템의 많은 변경 사항(하드웨어 업그레이드, 운영 체제 변경 등)을 초래할 수 있기 때문에 중요함.

환경 평가 요소

• 시스템 하드웨어와 지원 소프트웨어 유지 관리 비용
• 일정 기간 동안 발생한 하드웨어 고장 횟수
• 시스템 지원 소프트웨어에 적용된 패치 및 수정 빈도
• 하드웨어 및 지원 소프트웨어 공급자의 신뢰성(공급자가 사업을 종료하면 시스템 지원이 중단될 수 있음)

애플리케이션 시스템의 기술적 품질 평가

1. 시스템 변경 요청의 수:
   • 시스템 변경은 시스템 구조를 망가뜨리고, 이후 변경을 더 어렵게 만듦. 이 값이 높을수록 시스템 품질이 낮다고 평가됨.
2. 사용자 인터페이스 수:
   • 양식 기반 시스템에서 각 양식은 별개의 사용자 인터페이스로 간주될 수 있음. 인터페이스가 많을수록 불일치와 중복이 발생할 가능성이 높음.
3. 시스템이 처리하는 데이터의 양:
   • 데이터의 양이 많아질수록 데이터의 불일치와 오류가 증가함. 오랜 기간 동안 수집된 데이터는 오류와 불일치를 포함할 수 있음. 오래된 데이터를 정리하는 것은 비용이 많이 들고 시간이 걸리는 작업임.

---

9.3 Software maintenance

소프트웨어 유지보수의 유형

1. 결함 수리:

   • 버그 및 취약점 수정: 코딩 오류 < 설계 오류 < 요구 사항 오류 순의 비용이 듦.

2. 환경 적응:

   • 새로운 플랫폼과 환경에 맞게 소프트웨어를 조정: 시스템의 환경(하드웨어, 운영체제, 기타 지원 소프트웨어 등)이 변경될 때 필요.

3. 기능 추가:

   • 새로운 기능을 추가하고 새로운 요구 사항을 지원: 시스템 요구 사항이 조직이나 비즈니스 변화에 따라 변경될 때 필요. 이 경우 요구되는 변경 규모가 다른 유형의 유지보수보다 클 수 있음.

유지보수가 더 비싼 이유

1. 새로운 팀이 시스템을 이해해야 함:

   • 시스템 유지보수를 담당하는 새로운 팀은 기존 시스템과 시스템 설계 결정을 이해하는 데 시간을 소비해야 함.

2. 유지보수와 개발 분리:

   • 시스템 개발 계약과 유지보수 계약이 분리되면, 개발 팀은 유지보수의 용이성을 고려하여 소프트웨어를 작성할 유인이 없음.
   • 개발팀은 미래의 유지보수 문제를 고려하지 않고 개발을 진행할 수 있음.

3. 유지보수 작업의 인식 부족:

   • 유지보수는 시스템 개발보다 덜 숙련된 과정으로 여겨지며, 종종 경험이 적은 직원에게 할당됨.
   • 오래된 시스템은 구식 프로그래밍 언어로 작성되었을 수 있고, 유지보수를 담당하는 개발자는 이러한 언어에 대한 경험이 부족할 수 있음.

4. 시스템 구조의 악화:

   • 시간이 지나면서 프로그램의 구조가 점차 악화되고, 이해하고 변경하기 어려워짐.

문제점과 해결책

1. 개발과 유지보수의 분리

   • 문제: 유지보수가 개발의 부차적인 활동으로 여겨지고, 시스템 변경을 용이하게 만들기 위한 개발 단계에서의 비용 절감 노력 부족.
   • 해결책: 시스템은 수명 주기 동안 계속해서 발전해야 하며, 유지보수는 새로운 소프트웨어 개발과 동등한 중요성을 가져야 함.

2. 시스템 구조의 악화

   • 문제: 시간이 지남에 따라 시스템의 구조가 악화되어 유지보수와 변경이 어려워짐.
   • 해결책: 소프트웨어 재구성 기법을 적용하여 시스템 구조와 이해도를 개선하고, 아키텍처 변환과 리팩토링을 통해 시스템 품질을 향상시킬 수 있음.

3. 미래 변경 비용 절감

   • 문제: 시스템에 새로운 기능을 추가하는 데 드는 비용이 높음.
   • 해결책: 명확한 명세, 테스트 우선 개발, 객체 지향 개발 및 구성 관리와 같은 좋은 소프트웨어 엔지니어링 기법들이 유지보수 비용을 줄이는 데 도움을 줌.

4. 유지보수 투자 필요성

   • 문제: 유지보수 투자에 대한 실질적 데이터를 수집하기 어려움. 기업은 측정하기 어려운 지출을 소비하려 하지 않고, 개발자는 자신이 담당하지 않는 유지보수를 책임지려 하지 않음.
   • 해결책: 시스템의 수명 동안 원래의 개발 팀이 계속해서 소프트웨어에 책임을 지도록 개발과 유지보수를 통합함.

유지보수 예측

예측 항목

1. 시스템 인터페이스 수와 복잡성: 인터페이스가 많고 복잡할수록 변경 필요성 증가
2. 변동성이 큰 시스템 요구사항: 조직의 정책과 절차에 따른 요구사항은 변동성이 클 수 있음
3. 시스템 사용 비즈니스 프로세스: 시스템 통합된 비즈니스 프로세스가 늘어날수록 변경 요구 증가

프로세스 데이터 활용

1. 수정 유지보수 요청 수: 증가하면 오류가 고쳐지지 않고 축적될 수 있음
2. 영향 분석 소요 시간: 영향 분석 시간이 늘어나면 유지보수 어려움
3. 변경 요청 처리 시간: 처리 시간이 길어지면 유지보수 효율성 저하
4. 미결 변경 요청 수: 미결 변경 요청이 많아지면 유지보수 상태 악화 가능성

소프트웨어 리엔지니어링

리엔지니어링(Reengineering)

• 목적: 레거시 시스템의 구조와 이해도를 개선.
• 기능: 기능 변경 없이 시스템 아키텍처나 데이터 구조를 수정하여 시스템을 개선.
• 장점:
  1. 위험 감소: 새로운 시스템을 개발하는 것보다 리엔지니어링이 실패 확률이 낮음.
  2. 비용 절감: 재개발 비용보다 리엔지니어링 비용이 적음.
• 한계: 기능적 접근을 객체 지향으로 변환하는 등의 큰 변화는 불가능하며, 데이터 관리 구조의 재조직은 자동화되지 않음.

리엔지니어링 과정

1. 소스 코드 번역: 구식 언어를 최신 언어로 변환.
2. 리버스 엔지니어링: 프로그램 분석 후, 문서화 작업.
3. 프로그램 구조 개선: 읽기 쉬운 구조로 개선.
4. 프로그램 모듈화: 관련 코드 그룹화 및 중복 제거.
5. 데이터 리엔지니어링: 데이터 구조 변경 및 데이터 정리.

소프트웨어 리팩토링

리팩토링(Refactoring)

• 목적: 프로그램의 구조를 개선하고 복잡도를 줄이며 이해하기 쉽게 만듦. 기능 추가가 아니라 프로그램 개선에 집중.
• 종류: 예방적 유지보수로서, 미래의 변경에 대한 문제를 줄이는 역할.
• 중요성:
  • 애자일 방법론: 변화 기반의 개발 방식으로, 리팩토링은 코드 품질 저하를 방지하고 유지보수를 쉽게 만듦.
  • 회귀 테스트: 리팩토링 시 새로운 오류 발생을 방지하고 기존 테스트가 실패하면 오류를 탐지할 수 있음.
• 한계:
  • 구조가 크게 손상된 프로그램: 리팩토링만으로는 개선이 어려운 경우가 있음.
  • 디자인 리팩토링: 기존 코드를 디자인 패턴으로 교체하는 더 어려운 작업이 필요할 수 있음.

리팩토링 vs 리엔지니어링

• 리엔지니어링: 시스템 유지보수 후, 비용 증가로 더 나은 시스템을 만들기 위한 과정.
• 리팩토링: 개발 및 진화 과정에서 지속적인 개선으로 시스템 유지보수 비용을 줄이는 과정.

코드 개선을 위한 "Bad Smells" 예시

1. 중복 코드: 유사한 코드가 여러 곳에 있을 때, 이를 하나의 메소드로 통합.
2. 긴 메소드: 너무 긴 메소드는 여러 개의 짧은 메소드로 분리.
3. Switch (case) 문: 조건문 중복을 없애고 다형성을 활용.
4. 데이터 클럼핑: 반복적으로 나타나는 데이터 그룹을 객체로 대체.
5. 추측적 일반화: 미래를 대비해 불필요한 일반화를 제거.

리팩토링 변환

• 추출 메소드(Extract Method): 중복을 제거하고 새로운 메소드로 분리.
• 조건식 통합(Consolidate Conditional Expression): 여러 조건식을 하나로 통합.
• 상위 클래스 메소드 올리기(Pull Up Method): 하위 클래스의 유사한 메소드를 상위 클래스에서 하나로 통합.

출처: Ian Sommerville - Software Engineering