가이드라인: 레거시 전개 비전 정의
이 가이드라인은 레거시 시스템 전개를 위한 비전 문서 작성 방법을 설명합니다.
관계
관련 요소
기본 설명

레거시 시스템의 가치 평가

개념: 레거시 전개에서 설명한 대로 레거시 시스템에는 다음과 같은 두 가지 가정이 적용됩니다.

  • 오래된 대규모 시스템입니다.
  • 이 시스템은 원래 RUP로 개발하지 않았습니다.

이는 일반적으로 개발 중간 산출물이 존재하는 경우 일반 RUP 이름을 사용하지 않거나 RUP에서 예상되는 양식이 아님을 의미합니다. 대부분의 경우, 누락되거나 더 이상 사용되지 않거나 너무 오래되어 시스템과 관련된 것으로 신뢰할 수 없는 경우입니다. 이러한 경우, 객체 지향 기술을 사용하여 디자인을 수행하지 않았고, 요구사항에 유스 케이스를 사용하지 않는 등의 다른 기법이 사용된 것으로 가정할 수 있습니다.

또한 레거시 시스템이 이를 모두 폐기하는 대신 다른 양식으로 재사용할 가치가 있는 중요한 자산("레거시")을 나타내는 것으로 가정합니다. 따라서 현재 자산의 가치를 평가해야 합니다. 즉, 해당 가치가 코드, 디자인, 요구사항, 특정 알고리즘 또는 데이터, 또는 제품의 시장 점유율에 있는지 평가해야 합니다. 그러나 이전 시스템일수록 기존 자산을 활용하는 데 어려움이 있습니다. 소프트웨어 문서는 대개 더 이상 사용할 수 없으며 디자인은 경우에 따라 코드부터 리버스 엔지니어링을 수행해야 합니다. 즉, "디자인 복구"가 필요합니다.

레거시 시스템을 처리해야 하는 경우 일반적으로 부정적인 시각이 존재하지만 실제로는 "이전" 시스템 존재에 따른 비교점 설정과 정보 소스로서의 활용 가치가 매우 큽니다. 전혀 새로운 시스템은 정의 및 개발이 보다 어렵고 위험성도 큽니다.

특히 레거시 시스템에서는 다음 요소를 쉽게 식별할 수 있습니다.

  • 요구사항 및 비즈니스 규칙
  • 구조적으로 중요한 요소
  • 기본 유스 케이스
  • 사용자의 우선순위, 요구사항 및 동작

한 가지 주의할 사항은 레거시 시스템이 새로운 접근 방식의 실험과 고려를 방해하는 요인이 될 수 있다는 것입니다.

레거시 시스템의 가치를 평가한 후에는 전개 접근 방식을 정의할 수 있습니다.

레거시 시스템 전개를 위한 접근 방식

재디자인 및 재구현을 완료하기 위해서는 간단한 기능성 확장에서 근본적인 아키텍처 변경까지 다양한 범위의 발전적 변경 작업을 수행해야 합니다. 각 변경사항마다 다른 기술 솔루션과 프로세스 형식성 레벨이 적용됩니다. 다음은 레거시 시스템 전개 예제입니다.

확장

단순 케이스의 경우 일부 기능성 또는 기능만 추가하면 됩니다. 규정 변경사항, 새로운 비즈니스 요구 또는 새 기능과 같이 경쟁으로 인해 발생하는 구동 요소에 따라 기존 시스템을 전개해야 합니다. 오래된 레거시 시스템이 많을수록 간단한 추가 작업도 어려워집니다. 장기간 확장을 수행하면 결과적으로 시스템의 아키텍처 무결성이 저하되어 시스템 확장이 보다 더 어려워집니다.

외관 개선

일반적으로 전체 시스템을 폐기할 필요는 없으며 모양을 바꾸거나 새 사용자 인터페이스 또는 시스템 간 인터페이스 기술을 이용하면 됩니다. 특정 시스템 컴포넌트에 새 인터페이스를 제공하거나 재구현을 허용하기 위한 랩핑을 기반으로 하는 솔루션을 통해 최소 개발로 바람직한 결과를 얻을 수 있습니다. 예를 들어, 신속하게 "웹을 사용"할 수 있어야 하는 많은 응용프로그램의 경우가 이에 해당 합니다.

이주

시스템의 기본 하드웨어, 운영 체제 또는 미들웨어가 유용한 수명 주기를 지난 경우에 사용하는 방식입니다. 또한 더 이상 유지보수되지 않거나 유지 비용이 많이 소요되는 기술에 의존하는 경우입니다. 솔루션은 레거시 시스템을 새 플랫폼(하드웨어 또는 소프트웨어)으로 이주하여 기존 소프트웨어의 상당 부분을 보존하는 것입니다. 예를 들어, DEC VAX VMS 환경에 맞게 개발된 응용프로그램은 광범위한 Unix 및 Linux 기반 플랫폼에 신속하게 배치해야 합니다. 자체 플랫폼에서 Unix 기반 플랫폼 범위로 Rational Environment(2백만 행의 코드로 구성되는 제품)를 이주하여 오늘날 Rational Apex로 알려진 제품이 탄생한 경우가 이에 해당합니다. 확장이 새로운 도메인 특정 동작을 추가하는 것을 의미하는 반면 이주는 레거시 시스템을 다른 기술 플랫폼에 맞게 적응시키는 것을 의미합니다. 이주의 경우 유형의 도메인 특정 가치는 적지만 적절한 시점에 효율적인 방법으로 실행하지 못하는 경우 심각한 결과가 발생할 수 있습니다.

재개발

레거시 시스템이 업무에 중요한 시스템으로서, 전개가 어렵고 확장할 수 없으며 더 이상 사용되지 않는 하드웨어 또는 소프트웨어 기술에 의존하는 경우 해당 시스템을 다시 개발해야 합니다. 일반적으로 기존 고객 기반을 잃지 않도록 점진적으로 수행해야 합니다. 예를 들어, 오래된 하드웨어와 20년 이상된 운영 체제에서 실행된 캐나다 자동 항공 교통 시스템(Canadian Automated Air Traffic System) 사례를 들 수 있습니다. 이 옵션이 이 내용과 관련이 없다는 의견도 가능하지만 시스템을 완전히 다시 빌드하더라도 레거시 시스템을 이용하여 새 시스템의 핵심 측면을 이해해야 합니다. 긍정적 및 부정적인 측면의 다양한 경험과 지식을 포함합니다.

통합

레거시 시스템을 완전히 다시 개발하는 것은 많은 대기업에 있어 재무적으로 많은 부담이 되므로 일반적으로 새 기술을 사용하고 새 응용프로그램을 레거시 시스템과 통합하여 새 기능을 개발하는 방법을 선호합니다. 이러한 접근 방식을 EAI(Enterprise Application Integration)라고 하며 기존 레거시 자산을 활용하면서 새 기술로 이동할 수 있습니다. 이 접근 방식에 대한 자세한 정보는 개념: EAI(Enterprise Application Integration)기법: 레거시 응용프로그램을 최신 아키텍처로 통합을 참조하십시오.

"위의 사항 모두 해당"

마지막으로, 회사에서 이주, 외관 개선 및 재개발 또는 통합을 연속적으로 수행해야 하는 경우가 있습니다. 이러한 경우 레거시 시스템을 빠르게 새 플랫폼으로 이동하고 시장 요구를 충족시킬 수 있는 완전히 새로운 시스템 외형을 갖춘 후 시스템을 다시 디자인하고, 신기술(소프트웨어 컴포넌트, 새 언어 및 미들웨어)을 사용하여 이전 코드 기반을 대단위로 분할하여 바꿔야 다음 단계를 수행할 수 있습니다. 이 방법은 가장 어렵고 위험성이 많으면서도 수행 가능한 접근 방식입니다.

예를 들어, IBM AS/400 플랫폼에서 개발된 수백만 행의 RPG(Report Program Generator) 코드로 구성되는 대규모 MIS 응용프로그램을 포함하는 회사는 해당 코드를 Java로 변환하여 웹과 광범위한 Windows 및 Unix 시스템에서 실행할 수 있어야 합니다. 이러한 회사에서는 2 - 3년 동안 사용자를 거의 방해하지 않고 Java로 응용프로그램을 다시 디자인하고 구현했습니다.

비즈니스 사례 평가

비전은 올바른 비즈니스 수행을 위한 접근 방식을 반영해야 합니다. 이전부터 사용해 왔다는 이유만으로 레거시 시스템을 발전시켜서는 안됩니다. 일반적으로는 레거시 시스템을 유지하는 것이 바람직하며 시스템을 개발 또는 인수하는 경우 일반적으로 많은 비용이 소요되며 시스템 폐기에 따른 비즈니스 관점의 정당성을 찾을 수 없습니다. 그러나 레거시 시스템 유지보수에 소요된 자원을 새로운 기회에 활용할 수도 있습니다. 단순히 보존에만 관심이 있는 경우(즉, 비즈니스상의 중요한 이유가 아닌 감정적 또는 역사적 이유만으로 시스템에 자원을 투입하거나 다른 대안을 전혀 검토하지 않은 경우) 비즈니스 사례를 검토해야 합니다.

올바른 비즈니스 사례는 현재 레거시 시스템의 유지에서 다양한 발전 옵션까지, 다양한 대안의 장단기적 영향을 고려해야 합니다. 비즈니스 사례에 대한 권장사항은 전술적인 단기 비즈니스 목표와 조직의 장기 전략 목표의 균형을 맞추어야 합니다.