[소프트웨어공학] - 유지보수

1. 유지 보수 개념

소프트웨어 유지보수는 소프트웨어가 개발된 이후에 이루어지는 변경 작업이다. 소프트웨어는 한 번 개발되었다고 끝나는 것이 아니라 운영 환경의 변화, 사용자 요구사항의 변화, 비즈니스 절차의 변화 등에 따라 계속 수정되고 개선된다.

 

따라서 유지보수는 단순히 오류를 고치는 작업만을 의미하지 않는다. 소프트웨어가 계속 유용하게 사용될 수 있도로 기능을 수정하고, 환경 변화에 적응시키며, 성능과 유지보수성을 개선하는 전반적인 활동이다.

 

특히 오래된 시스템인 레거시 시스템은 대체 비용이 크고, 기존 업무 지식과 경험이 많이 반영되어 있기 때문에 쉽게 폐기하기 어렵다. 그래서 기존 시스템을 유지하면서 필요한 부분을 수정하거나 개선하는 유지보수 작업이 중요하다.

 

유지보수가 필요한 대표적인 이유는 다음과 같다.

• 발견된 버그 제거
• 운영 환경 변화에 대응하기 위해
• 비즈니스 절차 변화에 맞추기 위해
• 미래에 발생할 수 있는 문제를 예방하기 위해

즉, 유지보수는 소프트웨어를 현재 상황에 맞게 계속 사용할 수 있도록 만드는 작업이다.

1.1. 유지보수 유형

유지보수는 목적에 따라 여러 유형으로 나눌 수 있다.

1.1.1. 수정형 유지보수

수정형 유지보수는 소프트웨어에서 발견된 결함을 고치기 위해 수행하는 유지보수이다. 프로그램 실행 중 오류가 발생하거나, 요구사항과 다르게 동작하는 부분이 발견되었을 때 이를 수정하는 작업이 여기에 해당한다.

1.1.2. 적응형 유지보수

적응형 유지보수는 변경된 환경에서도 소프트웨어가 계속 동작할 수 있도록 수정하는 작업이다. 예를 들어 운영체제, 하드웨어, 데이터베이스, 외부 API 등이 변경되었을 때 기존 소프트웨어를 새로운 환경에 맞게 변경하는 것이다.

1.1.3. 완전형 유지보수

완전형 유지보수는 소프트웨어의 성능이나 유지보수성을 개선하기 위해 수행하는 유지보수이다. 새로운 기능을 추가하거나, 기존 기능을 더 편리하게 개선하거나, 코드 구조를 정리하여 유지보수를 쉽게 만드는 작업이 포함된다.

1.1.4. 예방형 유지보수

예방형 유지보수는 앞으로 발생할 수 있는 오류를 미리 방지하기 위해 수행하는 유지보수이다. 코드 구조를 개선하거나 잠재적인 오류 가능성을 제거하거나 시스템의 안정성을 높이는 작업이 이에 해당한다.

1.1.5. 완전형 유지보수

응급형 유지보수는 긴급한 문제가 발생했을 때 즉시 임시로 조치하는 유지보수이다. 시스템 장애나 서비스 중단처럼 빠르게 대응해야 하는 상황에서 수행된다.

1.2. Lehman의 법칙

Lehman의 법칙은 소프트웨어가 운영되는 동안 계속 변화하고 진화한다는 점을 설명하는 법칙이다. 소프트웨어는 한 번 개발되었다고 끝나는 것이 아니라 사용자의 요구, 운영 환경, 비즈니스 절차 등이 바뀌면서 지속적으로 수정된다.

 

Lehman은 시스템을 크게 다음과 같은 두 가지 유형으로 구분한다.

• E타입: 실제 환경에서 사용되며 계속 변화하는 시스템이다. 대부분의 업무용 소프트웨어, 웹 서비스, 기업 시스템이 해당된다.
• S 타입: 한 번 정확하게 구현되면 이후 큰 변화 없이 사용할 수 있다.

Lehman의 법칙은 소프트웨어 유지보수가 왜 계속 필요한지를 설명한다. 주요 내용은 다음과 같다.

• 지속적인 변경의 원칙
  • 실제 환경에서 사용되는 소프트웨어는 계속 변경되어야 한다. 만약 변화하는 요구사항이나 환경에 맞게 수정되지 않으면 점점 유용성이 떨어진다.
• 엔트로피, 복잡도 증가의 법칙
  • 소프트웨어가 계속 수정되면 내부 구조가 점점 복잡해진다. 새로운 기능이 추가되고 기존 코드가 변경되면서 구조가 흐트러질 수 있기 때문이다.
• 자기 통제의 법칙
  • 소프트웨어 변화 과정은 완전히 무작위로 이루어지는 것이 아니라 일정한 패턴과 흐름을 가진다.
  • 즉, 소프트웨어는 개발 조직, 운영 환경, 사용자 요구와 상호작용하면서 일정한 방식으로 진화한다.
• 안정성 유지의 법칙
  • 소프트웨어는 너무 급격하게 변경되면 안정성이 떨어질 수 있다.
  • 따라서 유지보수 과정에서는 변경과 안정성 사이의 균형을 유지해야 한다.
• 친근성 유지의 법칙
  • 소프트웨어는 사용자와 개발자가 이해할 수 있는 수준의 구조를 유지해야 한다.
  • 시스템이 지나치게 복잡해지면 유지보수하기 어려워지고, 결과적으로 품질이 낮아질 수 있다.
• 지속적 성장의 법칙
  • 소프트웨어가 계속 유용하게 사용되기 위해서는 기능이 지속적으로 확장되어야 한다.
  • 사용자 요구가 증가하고 환경이 변화하기 때문에 시스템도 함께 성장해야 한다.
• 품질 저하의 법칙
  • 소프트웨어를 지속적으로 관리하지 않으면 품질은 점점 저하된다.
  • 오류가 누적되고 구조가 복잡해지며, 유지보수성이 떨어질 수 있다.
• 피드백 시스템의 법칙
  • 소프트웨어 진화는 사용자, 운영 환경, 개발 조직으로부터 피드백을 통해 이루어진다.
  • 따라서 유지보수 과정에서는 피드백을 반영하여 시스템을 개선하는 것이 중요하다.

---

2. 유지보수 작업 과정

유지보수는 단순히 코드를 수정하는 작업이 아니라 기존 프로그램을 이해하고 변경사항을 분석한 뒤 실제 수정, 테스트, 설치까지 진행하는 과정이다. 개발 단계에서는 새로운 기능을 구현하는 데 초점이 맞춰지지만, 유지보수 단계에서는 기존 시스템을 정확히 이해하고 변경의 영향을 파악하는 것이 중요하다.

 

유지 보수 작업 과정은 다음과 같은 4가지 단계로 이루어진다.

• 현재 프로그램의 이해
  • 기존 프로그램 로직을 추적하고 요구사항 문서나 설계 문서를 참고하여 시스템이 어떻게 동작하는지 파악해야 한다.
• 변경 파악과 분석
  • 변경해야 할 부분을 파악하고 분석하는 것이다. 변경 요구사항을 바탕으로 변경에 필요한 비용, 시간, 리스크를 함께 분석한다.
• 변경 영향 파악
  • 변경이 시스템 전체에 어떤 영향을 주는지 파악하는 것이다. 이해당사자들에게 알리고 피드백을 얻는 과정이 필요하다.
• 변경 구현, 테스트, 설치
  • 실제로 시스템을 수정하고 테스트한 뒤 설치하는 것이다. 변경으로 인해 기존 기능에 문제가 생기지 않았는지도 함께 확인해야 한다.

2.1. 유지 보수 작업 분포

소프트웨어 개발은 새로운 기능을 구현하는 코딩 중심의 작업이 많다. 반면 유지보수는 기존 프로그램을 이해하는 작업의 비중이 크다.

 

즉, 유지보수는 단순한 코딩 작업이 아니라 기존 시스템의 구조, 요구사항, 설계, 코드, 테스트 결과를 종합적으로 이해해야 하는 통합적인 작업이다. 따라서 유지보수에서는 프로그램 이해 능력과 변경 영향 분석 능력이 중요하다.

위 그림에서 볼 수 있듯이, 문서가 정리된 시스템에서는 변경 내용을 이해하고 구현, 테스트하는 작업이 균형 있게 이루어진다. 반면 문서가 빈약한 시스템에서는 기존 문서를 통해 시스템을 이해하기 어렵기 때문에, 원시코드를 직접 분석하며 로직을 추적하는 작업의 미중이 크게 증가한다. 따라서 유지보수 비용을 줄이기 위해서는 코드뿐만 아니라 요구사항, 설계 문서, 테스트 문서 등 관련 문서를 지속적으로 관리하는 것이 중요하다.

2.2. 유지보수 프로세스 모델

유지보수 작업은 상황에 따라 여러 방식으로 진행될 수 있다. 대표적인 유지보수 프로세스 모델에는 즉시 수정 모델, 반복적 개선 모델, 재사용 중심 모델이 있다.

2.2.1. 즉시 수정 모델

즉시 수정 모델은 문제가 발생했을 때 빠르게 코드를 수정하는 방식이다. 긴급한 오류나 장애에 대응할 때 사용할 수 있다.

 

이 방식은 빠른 대응이 가능하다는 장점이 있지만, 충분한 분석 없이 수정이 이루어지면 새로운 오류가 발생하거나 시스템 구조가 더 복잡해질 수 있다.

 

위 그림에서 확인할 수 있듯이 기존 시스템은 요구분석 > 설계 > 코딩 > 테스팅의 과정을 거쳐 만들어졌다. 그런데 유지보수 상황에서 문제가 생기거나 변경 요구가 들어오면, 전체 개발 과정을 처음부터 다시 수행하지 않고 기존 시스템의 코드를 직접 수정한다.

 

즉, 기존 시스템의 코딩 단계에서 바로 코드를 수정하여 새 시스템의 코딩 단계로 넘어간 뒤 수정된 코드가 새 시스템에서 기존 요구사항, 설계, 테스트와 맞는지 확인하는 것이다.

2.2.2. 반복적 개선 모델

 

반복적 개선 모델은 유지보수 작업을 한 번에 끝내는 것이 아니라 여러 번의 반복을 통해 점진적으로 개선하는 방식이다.

 

변경 요구를 분석하고 수정한 뒤 테스트와 평가를 거치며 필요한 경우 다시 개선을 반복한다. 이 방식은 시스템을 안정적으로 개선할 수 있다는 장점이 있다.

2.2.3. 재사용 중심 모델

재사용 중심 모델은 기존에 만들어진 컴포넌트나 상용 소프트웨어를 활용하여 유지보수를 수행하는 방식이다.

 

새로운 기능을 직접 구현하기보다 이미 검증된 소프트웨어나 모듈을 활용하면 개발 비용과 시간을 줄일 수 있다. 다만 기존 시스템과의 호환성, 통합 가능성, 유지관리 비용을 함께 고려해야 한다.

2.3. 프로그램 이해

프로그램 이해는 원시코드로부터 설계나 명세를 추출하고 이를 바탕으로 개발자가 머릿속에 시스템 구조를 형성하는, 즉, 멘탈 모델로 표현하는 작업이다.

 

일반적인 개발 과정은 요구사항에서 설계로, 설계에서 코드로 내려가는 방향으로 진행된다. 반면 유지보수에서의 프로그램 이해는 원시코드에서 출발하여 설계나 명세를 추론하는 방향으로 진행된다. 즉, 개발 과정과 반대로 더 높은 추상 수준을 찾아가는 작업이다.

 

프로그램 이해 방식에는 상향식 이해 모델이 존재하는데, 상향식 이해 모델은 코드의 작은 부분부터 분석하여 점차 큰 구조를 이해하는 방식이다. 이 과정에서 관련된 코드 조각을 묶어 의미 있는 단위로 이해하는 묶음화가 사용된다.

2.4. 변경 파악과 분석

변경 파악과 분석은 변경 요구를 바탕으로 어떤 부분을 수정해야 하는지 찾아내는 작업이다. 이 과정에서는 직접 코드를 수정하는 방법뿐만 아니라 상용 소프트웨어나 기존 컴포넌트를 활용하는 방법(COTS)도 함께 검토할 수 있다.

 

변경 분석에는 변경을 구현하고 테스트하는 데 필요한 비용과 시간을 예측하고, 변경으로 인해 발생할 수 있는 리스크를 파악한다. 또한 변경 효과 분석을 통해 수정 대상이 다른 부분에 어떤 영향을 미치는지도 확인해야 한다.

 

객체지향 소프트웨어에서는 클래스 사이의 의존관계를 통해 변경 영향을 파악할 수 있다. 예를 들어 어떤 클래스 B가 클래스 A의 서브클래스이거나 A를 포함하거나 A를 사용한다면 B는 A에 의존한다고 볼 수 있다. 이 경우 A가 변경되면 B에도 영향이 갈 수 있으므로 함께 검토해야 한다.

 

따라서 유지보수에서 변경 분석은 단순히 수정할 코드를 찾는 작업이 아니라, 변경의 범위와 영향을 예측하고 안전하게 수정하기 위한 중요한 과정이다.

---

3. 형상관리

형상관리는 소프트웨어 개발과 유지보수 과정에서 생성되는 문서, 코드, 테스트 케이스, 실행 파일 등의 결과물을 체계적으로 관리하고 소프트웨어 시스템과 컴포넌트 상태를 추적하는 작업이다.

 

소프트웨어는 개발이 진행되는 동안 계속 변경된다. 요구사항이 수정될 수도 있고, 설계가 바뀔 수도 있으며, 코드나 테스트 케이스가 변경될 수도 있다. 이때 문서와 결과물에 대한 변경이 제대로 조정되지 않으면 서로 다른 산출물 사이에 불일치가 발생한다.

 

예를 들어 어떤 클래스를 수정했는데, 그 클래스에 의존하는 다른 클래스나 관련 문서를 함께 수정하지 않으면 시스템 전체에 오류가 발생할 수 있다. 따라서 형상관리는 변경되는 소프트웨어 구성 요소를 추적하고 통제하여 프로젝트 결과물의 일관성을 유지하기 위해 필요하다.

 

형상관리는 원래 하드웨어 개발에서 적용되었던 전통적인 원리를 소프트웨어 개발에 적용한 것이다. 소프트웨어에서도 여러 사람이 동시에 작업하고 여러 버전이 존재하기 때문에, 어떤 파일이 현재 기준인지, 어떤 변경이 승인되었는지, 어떤 버전이 배포되었는지를 명확하게 관리해야 한다.

3.1. 베이스라인

베이스라인은 특정 시점에서 공식적으로 승인된 소프트웨어 형상 항목의 집합을 의미한다. 여기서 형상 항목은 요구사항 문서, 설계 문서, 원시코드, 테스트 케이스, 실행 파일 등 관리 대상이 되는 산출물을 말한다.

 

베이스라인은 프로젝트의 중요한 상태를 정의하는 기준이 된다. 예를 들어 요구사항 분석이 완료된 시점, 설계가 완료된 시점, 테스트가 완료된 시점, 정식 배포가 이루어진 시점 등이 베이스라인으로 설정될 수 있다.

 

베이스라인이 설정되면 이후의 개발이나 유지보수 작업은 이 베이스라인 기준으로 진행된다. 따라서 변경이 필요한 경우에는 임의로 수정하는 것이 아니라 변경 요청과 승인 절차를 거쳐야 한다.

 

베이스라인의 목적은 다음과 같다.

• ㅍ프로젝트의 중요한 상태를 정의한다.
• 소프트웨어 프로덕트가 특정 상태에 도달했는지를 나타낸다.
• 이후 개발과 유지보수 작업의 기준이 된다.
• 형상 항목에 대한 변경을 제어하는 기준점 역할을 한다.

3.2. 형상관리 필요성

소수의 개발자가 한 장소에서 간단한 시스템을 개발한다면 형상관리가 크게 필요하지 않을 수 있다. 그러나 실제 소프트웨어 개발에서는 여러 개발자와 여러 팀이 함께 작업하는 경우가 많다. 이때 형상관리가 제대로 이루어지지 않으면 파일 충돌, 버전 혼동, 문서 불일치 등의 문제가 발생한다.

 

형상관리가 필요한 이유는 크게 두 가지이다.

• 시스템을 개발하는 많은 팀과 개발자들이 협력하고 동기화가 필요할 때 사용한다.
• 여러 버전을 유지하고 업데이트를 진행해야 할 경우 필요하다. 하나의 소프트웨어라도 고객이나 운영 환경에 따라 서로 다른 버전이 필요할 수 있기 때문이다.

3.3. 형상관리 절차

형상관리 절차는 일반적으로 다음 네 단계로 이루어진다.

3.3.1. 소프트웨어 형상 파악

소프트웨어 형상 파악은 관리해야 할 형상 항목을 식별하는 작업이다. 요구사항 문서, 설계 문서, 원시코드, 테스트 케이스, 실행 파일 등 프로젝트에서 관리해야 할 산출물이 무엇인지 정리한다.

 

형상 항목에는 다음과 같은 정보가 포함될 수 있다.

• 고유 식별자(고유 번호, e.g. LIS-Incl-DM)
• 이름
• 문서 종류(요구 분석서, 설계 문서, 원시 코드, 테스트 케이스)
• 문서 파일(파일 이름과 경로)
• 저자
• 생성 날짜, 목표 완성일
• 버전 번호
• 업데이트 이력
• 설명
• SQA 담당자(품질 보증 책임자)
• SCM 담당자(항목 체크 책임자)

 

형상 항목을 명확히 파악해야 이후 변경이 발생했을 때 어떤 항목이 영향을 받는지 추적할 수 있다.

3.3.2. 형상 변경 제어

형상 변경 제어는 형상 항목에 대한 변경을 체계적으로 관리하는 작업이다. 변경이 필요한 경우 변경 이유(소프트웨어 결함, 하드웨어 변경, 운영 요구 변경, 고객이나 사용자로부터 개선 요구, 예산, 프로젝트 일정, 기간 등의 변경)를 파악하고, 변경이 미치는 영향과 필요한 비용, 일정 등을 분석한 뒤 변경 여부를 결정한다.

 

이후 변경 제안을 준비한다. 변경 제안에는 변경 내용에 대한 설명, 관련 조직 및 개발자, 변경 이유, 영향을 받는 항목, 필요한 노력, 프로젝트 일정에 대한 영향 등이 포함된다.

 

마지막으로 변경 제안을 평가하고, 승인된 변경만 형상 항목에 반영한다.

 

즉, 형상 변경 제어는 아무나 임의로 산출물을 수정하지 못하게 하고, 승인된 변경만 반영되도록 통제하는 절차이다.

3.3.3. 소프트웨어 형상 감사

소프트웨어 형상 감사는 형상 항목이 올바르게 관리되고 있는지 확인하는 작업이다. 승인된 변경이 실제로 반영되었는지, 변경된 항목이 베이스라인과 일치하는지, 잘못된 문제가 해결된 것은 아닌지 등을 점검한다.

3.3.4. 소프트웨어 형상 상태 보관

소프트웨어 형상 상태 보관은 형상 항목의 상태와 변경 이력을 기록하고 관리하는 작업이다. 어떤 항목이 언제 생성되었고, 누가 수정했으며, 어떤 버전으로 변경되었는지를 보관한다.

 

이러한 기록은 나중에 문제가 발생했을 때 원인을 추적하거나 이전 상태로 되돌리는 데 도움이 된다.

 

 

형상 관리 절차를 그림으로 표현은 위와 같다.

---

4. 역공학

역공학은 이미 만들어진 소프트웨어 시스템을 분석하여 시스템의 구성 요소와 그들 사이의 관계를 찾아내는 작업이다. 이를 통해 기존 시스템을 같은 수준의 다른 표현으로 나타내거나 더 높은 수준의 추상적인 표현으로 복구할 수 있다.

 

일반적인 개발 과정은 요구사항 분석에서 시작하여 설계, 코딩, 테스트로 내려가는 방향으로 진행된다. 반면 역공학은 이미 존재하는 원시코드나 실행 시스템에서 출발하여 설계와 명세와 같은 상위 수준의 정보를 추출하는 방향으로 진행된다.

 

즉, 역공학은 프로그램의 추상 수준을 점진적으로 북구해 나가는 과정이라고 볼 수 있다.

4.1. 역공학 작업 순서

역공학은 주로 원시코드에서 소프트웨어 결과물을 추출하는 방식으로 진행된다. 즉, 코드에 포함된 구조와 관계를 분석하여 설계 정보나 문서화 자료를 만들어낸다.

 

역공학 작업은 다음과 같은 흐름으로 이해할 수 있다.

1. 기존 시스템의 원시코드 또는 실행코드를 수집한다.
2. 원시코드의 구조와 흐름을 분석한다.
3. 함수, 클래스, 모듈, 데이터 구조와 같은 구성 요소를 식별한다.
4. 구성 요소 사이의 호출 관계, 의존 관계, 데이터 흐름 등을 파악한다.
5. 분석 결과를 바탕으로 다이어그램이나 문서와 같은 소프트웨어 산출물을 생성한다.

이 과정에서 역공학 도구를 사용할 수 있는데, 원시코드를 분석하여 클래스 다이어그램, 호출 그래프, 흐름도 등을 자동으로 생성하는 데 도움을 준다.

4.2. 역공학의 용도

역공학을 통해 복원된 다이어그램이나 문서는 다음과 같이 여러 방면에서 사용될 수 있다.

• 프로그램 이해
  • 기존 프로그램의 구조, 기능, 동작을 이해하는 데 도움을 주고 유지보수 대상 시스템의 문서가 부족할 때 중요한 수단이 된다.
• 정형적 분석
  • 소프트웨어에 존재할 수 있는 문제를 감지하는 데에도 활용된다.
• 테스트 케이스 생성
  • 흐름드의 경로를 복원하면 가능한 실행 경로를 파악할 수 있고, 경로 테스트 케이스를 설계할 수 있다.
• 리엔지니어링
  • 기존 시스템을 개선하거나 재구조화하려면 현재 시스템 구조와 문제점을 정확히 이해해야 하므로 역공학을 통해 분석하는 과정이 필요하다.

4.3. 재문서화

재문서화는 의미적으로 같은 추상 수준을 가진 표현을 생성하는 작업이다. 즉, 기존 시스템의 내용을 새로운 문서나 다이어그램으로 다시 정리하는 것을 의미한다.

 

재문서화의 목적은 다음과 같다.

• 소프트웨어의 이해를 증진시키기 위하여 시스템의 다른 관점에서 이해하고자 할 때 필요하다.
• 현재 보유한 문서를 개선할 때 필요하다
• 새로 수정된 프로그램을 문서화할 때 필요하다.

예를 들어 코드에는 변경이 많이 이루어졌지만 설계 문서가 예전 상태로 남아 있다면, 유지보수자는 문서를 신뢰하기 어렵다. 따라서 재문서화를 통해 현재 코드에 맞는 문서를 다시 작성하면 이후 유지보수 작업이 쉬워진다.

4.4. 설계 복구

설계 복누는 원시코드를 자세히 검토하여 의미 있는 추상성 높은 표현을 찾아내고 추출하는 작업이다. 단순히 코드 구조를 문서로 바꾸는 것을 넘어서, 코드 안에 숨어 있는 설계 의도와 의사결정을 파악하는 과정이라고 볼 수 있다.

 

복구된 설계는 다음과 같이 사용된다.

• 원시코드를 이해하는 데 도움이 된다.
• 향후 유지보수나 리엔지니어링을 위한 베이스라인으로 사용될 수 있다.
• 유사한 다른 애플리케이션을 개발할 때 참고 자료로 사용될 수 있다.

설계 복구는 프로그래밍 언어 구조에 영향을 많이 받는다. 객체지향 프로그램의 경우 클래스, 상속, 연관, 의존 관계 등이 코드에 비교적 명확하게 나타나므로 UML 도구를 통해 어느 정도 자동화할 수 있다.

 

하지만 설계 복구가 완전히 자동으로 이루어지는 것은 아니다. 원시코드에 내재된 설계의 의미나 의사결정은 단순한 코드 구조만으로 파악하기 어려울 수 있다. 이 경우 해당 업무 분야에 대한 도메인 지식이 필요할 수도 있다.

 

따라서 설계 복구는 단순히 코드 분석이 아니라 코드 구조와 도메인 지식을 함께 활용하여 시스템의 설계 의도를 복원하는 작업이다.

---

5. 리엔지니어링

리엔지니어링은 기존 소프트웨어 시스템이나 컴포넌트를 분석하고, 이를 더 나은 구조로 재구성하는 과정이다. 기존 시스템을 완전히 새로 개발하는 것이 아니라, 이미 존재하는 시스템의 구조를 개선하여 유지보수성과 확장성을 높이는 데 목적이 있다.

 

오래된 소프트웨어는 시간이 지나면서 여러 번 수정되고 기능이 추가되기 때문에 내부 구조가 복잡해질 수 있으며 이러한 복잡성은 유지보수를 어렵게 만들고 새로운 기능을 추가할 때 오류가 발생할 가능성이 높다.

 

리엔지니어링의 목적은 다음과 같다.

• 소프트웨어 아키택터를 개선할 수 있다.
• 소프트웨어 복잡도를 줄일 수 있다.
• 변경에 대한 적응성을 개선할 수 있다.
• 성능, 효율성, 자원 유용성을 개선할 수 있다.
• 소프트웨어 시스템의 유지보수성을 개선할 수 있다.

5.1. 리엔지니어링 과정

리엔지니어링 과정은 일반적으로 다음과 같은 과정으로 진행된다.

1. 개선이 필요한 위치를 파악한다.
   1. 기존 시스템을 분석하여 구조가 복잡한 부분, 변경이 자주 발생하는 부분 등을 찾아낸다.
2. 개선 전략을 선택한다.
3. 제안된 개선을 구현한다.
   1. 기존 기능을 유지하면서 내부 구조를 개선하는 것이 중요하다.
4. 목표를 기준으로 시스템을 평가한다.
   1. 복잡도가 줄어들었는지, 유지보수가 쉬워졌는지 등을 평가한다.

정리하면 리엔지니어링은 기존 시스템을 더 좋은 구조로 바꾸기 위한 개선활동이다. 역공학이 기존 시스템을 이해하기 위한 작업이라면 리엔지니어링은 그 이해를 바탕으로 시스템을 실제로 개선하는 작업이라고 볼 수 있다.