레거시 시스템

Legacy system
2011년에도 일부 기업에서는 MS-DOS를 사용하여 이 미 해군 식품 서비스 관리 시스템과 같은 레거시 애플리케이션을 실행하고 있습니다.

컴퓨팅에서 레거시 시스템은 오래된 방법, 기술, 컴퓨터 시스템 또는 응용 프로그램이며, "이전 또는 구식 또는 구식 컴퓨터 시스템"[1] 또는 "구식 또는 구식 컴퓨터 시스템"이지만 여전히 사용되고 있습니다.종종 시스템을 "레거시"라고 지칭하는 것은 시스템을 따르는 표준을 위한 길을 닦았다는 것을 의미합니다.이는 시스템이 최신 상태가 아니거나 교체해야 함을 의미할 수도 있습니다.

레거시 코드는 오래된 컴퓨터 소스 코드입니다.이는 단순히 수년간 작성된 조직의 기존 코드 베이스를 지칭하거나, 어떤 면에서 더 이상 사용되지 않거나 더 이상 사용되지 않는 무언가를 지원하는 코드 베이스를 의미할 수 있습니다.장기간에 걸친 코드는 소프트웨어가 부패할 가능성이 있으며 런타임 환경이나 주변 소프트웨어나 하드웨어가 변경되면 계속 작동하기 위해 유지보수 또는 에뮬레이션이 필요할 수 있습니다.레거시 코드는 레거시 하드웨어, 개별 레거시 시스템 또는 오래된 기능 또는 소프트웨어 버전을 사용하는 레거시 고객을 지원하기 위해 존재할 수 있습니다.

이 용어는 보통 소스 코드를 가리키지만 더 이상 시스템의 최신 버전에서 실행되지 않거나 호환성 계층이 필요한 실행 코드에도 적용될 수 있습니다.예를 들어 MacOS에서는 네이티브로 실행되지 않지만 Classic 환경 내에서 실행되는 Classic Macintosh 응용 프로그램이나 XP의 Windows on Windows 기능을 사용하여 Windows XP에서 실행되는 Win16 응용 프로그램 등이 있습니다.

레거시 하드웨어의 예로는 PS/2나 VGA 포트 등의 레거시 포트나 오래된 호환성이 없는 명령어 세트를 탑재한 CPU(새로운 운영체제 등)가 있습니다.레거시 소프트웨어의 예로는 .swf for Adobe Shockwave 또는 .123 for Lotus 1-2-3과 같은 레거시 파일 형식과 EBCDIC과 같은 레거시 문자 인코딩으로 인코딩된 텍스트 파일이 있습니다.

개요

윈도XP는 2014년 4월부터 지원이 중단됐지만 ATM 운영체제 소프트웨어 등의 분야에서 계속 사용되고 있다.

컴퓨터 시스템을 설명하기 위해 레거시라는 용어가 처음 사용된 것은 아마도 [citation needed][2]1960년대였을 것이다.1980년대에는 기존 컴퓨터 시스템을 새로운 시스템의 설계 및 구현과 구별하기 위해 일반적으로 사용되었습니다.레거시 시스템에서 새 데이터베이스로 데이터를 이동하는 등 변환 프로세스 중에 레거시 데이터가 자주 들립니다.

이 용어는 일부 엔지니어가 시스템이 구식이라고 느낄 수 있지만 레거시 시스템은 다양한 이유로 계속 사용될 수 있습니다.단순히 시스템이 사용자의 요구를 충족시키는 것일 수 있습니다.또한 오래된 시스템을 유지하는 결정은 투자수익률이나 벤더 록인 등의 경제적 이유, 변경관리의 본질적 과제 또는 기능성 이외의 다양한 이유에 의해 영향을 받을 수 있습니다.하위 호환성(기존 파일 형식 및 문자 인코딩을 처리하는 새로운 시스템의 기능 등)은 소프트웨어 개발자가 작업에 자주 포함하는 목표입니다.

더 이상 사용되지 않더라도 레거시 시스템은 그 역사적 역할에 따라 조직에 계속 영향을 미칠 수 있습니다.이력 데이터는 새로운 시스템 포맷으로 변환되지 않고 맞춤형 스키마 횡단보도를 사용하여 새로운 시스템 내에 존재할 수도 있고 데이터 웨어하우스에만 존재할 수도 있습니다.어느 경우든 비즈니스 인텔리전스와 운영 보고에 미치는 영향은 매우 클 수 있습니다.레거시 시스템은 현재의 맥락에서 더 이상 관련이 없는 절차 또는 용어를 포함할 수 있으며, 사용된 방법 또는 기술에 대한 이해를 방해하거나 혼란시킬 수 있습니다.

조직은 다음과 같은 이유로 레거시 시스템을 유지할 수 있습니다.

  • 시스템은 정상적으로 동작하고 있으며, 소유자는 변경할 이유가 없다고 생각합니다.
  • 시스템 재설계 또는 교체 비용은 대규모, 획일적 또는 복잡하기 때문에 어마어마합니다.
  • 새로운 시스템에 대한 재교육은 교체로 예상되는 현저한 이익(제로일 수도 있음)에 비해 시간과 비용의 손실이 발생할 수 있습니다.
  • 이 시스템은 거의 일정한 가용성을 필요로 하기 때문에 서비스를 중단할 수 없으며, 유사한 가용성 수준으로 새로운 시스템을 설계하는 데 드는 비용이 높습니다.예로는 은행, 컴퓨터 예약 시스템, 항공 교통 통제, 에너지 분배(전력망), 원자력 발전소, 군사 방어 시설 및 TOPS 데이터베이스와 같은 시스템을 들 수 있다.
  • 그 시스템의 작동 방식은 잘 이해되지 않는다.이러한 상황은 시스템 설계자가 조직을 떠나 시스템이 완전히 문서화되지 않았거나 문서가 손실되었을 때 발생할 수 있습니다.
  • 사용자는 이것이 필요할 때 시스템을 쉽게 교체할 수 있기를 기대합니다.
  • 새로운 시스템에서는 바람직하지 않은(특히 개인 사용자 또는 비기관 사용자용) 세컨더리 기능(a) 사용자 액티비티의 트래킹과 보고서 작성 및/또는 자동 갱신 등)을 실행하여 "백도어" 보안 취약성을 생성하고 최종 사용자는 업데이트를 제공하는 벤더의 성실성과 정직성에 의존하게 됩니다.이 문제는 새로운 시스템의 이러한 세컨더리 기능을 비활성화할 수 없는 경우에 특히 심각합니다.

레거시 컴퓨팅에 의한 문제

일부 소프트웨어 엔지니어는 레거시 시스템을 여러 [3]가지 이유로 문제가 될 수 있다고 생각합니다.

  • 레거시 소프트웨어가 구식 하드웨어에서만 실행되는 경우, 에뮬레이션이나 하위 호환성을 통해 소프트웨어를 [4]새로운 하드웨어에서 실행할 수 없는 한 시스템 유지 보수 비용이 결국 소프트웨어와 하드웨어를 모두 교체하는 데 드는 비용을 초과할 수 있습니다.
  • 이러한 시스템은 일반적으로 시스템에 대한 이해가 부족하기 때문에 유지, 개선, 확장이 어려울 수 있습니다.그에 대해 전문가였던 스탭은 퇴직하거나 알고 있던 것을 잊어버리고 있습니다.또, 「레거시」가 된 후에 이 분야에 입사한 스탭은, 애초에 이 시스템에 대해 배운 적이 없습니다.이 문제는 문서 부족 또는 손실로 인해 악화될 수 있습니다.Comair 항공사는 2004년 구식 승무원 스케줄 시스템의 실패로 인해 회사 [5]내 누구에게도 알려지지 않은 한계에 부딪혔기 때문에 CEO를 해고했다.
  • 레거시 시스템에서는 사용 가능한 보안 패치가 부족하거나 적용되지 않아 오래된 운영 체제나 애플리케이션에 취약성이 있을 수 있습니다.또, 시큐러티상의 문제를 일으키는 실가동 구성도 있습니다.이러한 문제로 인해 레거시 시스템이 공격자나 정통한 [6]내부자에 의해 손상될 위험이 있습니다.
  • 새로운 소프트웨어에서는 전혀 다른 테크놀로지를 사용할 수 있기 때문에 새로운 시스템과의 통합도 어려울 수 있습니다.테크놀로지간의 통합은 컴퓨팅에서는 매우 일반적이지만, 새로운 테크놀로지와 상당히 오래된 테크놀로지간의 통합은 일반적이지 않습니다.통합 기술을 개발하기에 충분한 수요가 없을 수 있습니다.이러한 「글루」코드의 일부는, 특정의 레거시 테크놀로지의 벤더나 애호가들에 의해서 개발되는 경우가 있습니다.
  • 예산의 제약으로 인해 기업은 레거시 시스템의 교체나 이행의 필요성에 대처하지 못하는 경우가 많습니다.그러나 기업은 종종 증가하는 지원 비용(인원, 소프트웨어 및 하드웨어, 위에서 언급한 모든 것)을 고려하지 않으며 레거시 시스템에 장애가 발생할 경우 엄청난 기능 손실이나 비즈니스 연속성을 고려하지 않습니다.이러한 고려사항을 충분히 이해한 후에는 보다 안전하고 업데이트된 새로운 기술 스택 플랫폼의 검증된 ROI를 기반으로 하는 것이 대안만큼 비용이 들지 않고 예산도 책정됩니다.
  • 대부분의 레거시 프로그래머가 정년에 접어들고 있으며 이들을 대체할 젊은 엔지니어의 수가 매우 적기 때문에 가용 인력이 심각하게 부족합니다.그 결과 레거시 시스템의 유지보수가 어려워지고 경험이 풍부한 프로그래머를 [7]조달하는 비용도 증가합니다.

레거시 소프트웨어 시스템 개선

애플리케이션 폐기를 통해 레거시 시스템을 교체할 수 없는 경우에도 이를 개선(또는 "재설계")할 수 있습니다.대부분의 개발은 레거시 시스템에 새로운 인터페이스를 추가하는 데 사용됩니다.가장 중요한 기술은 터미널 기반 메인프레임 애플리케이션에 웹 기반 인터페이스를 제공하는 것입니다.이는 느린 응답 시간과 느린 마우스 기반 오퍼레이터 작업으로 인해 직원의 생산성을 떨어뜨릴 수 있지만, 비숙련 사용자에게 인터페이스 스타일이 익숙하고 사용하기 쉽기 때문에 종종 "업그레이드"로 간주됩니다.John McCormick은 미들웨어와 [8]관련된 전략을 논의합니다.

레거시 소프트웨어 시스템에서는 포맷 명령이 추가되지 않거나 최신 PC/Windows 프린터에서는 사용할 수 없는 프로토콜을 사용하는 경우가 많기 때문에 인쇄 개선은 문제가 됩니다.프린트 서버를 사용하여 데이터를 가로채고 보다 현대적인 코드로 변환할 수 있습니다.리치 텍스트 형식(RTF) 또는 PostScript 문서를 레거시 응용프로그램에서 작성한 후 인쇄하기 전에 PC에서 해석할 수 있습니다.

바이오메트릭 보안 대책은 레거시 시스템에 구현하기 어렵습니다.실행 가능한 해결책은 사용자와 메인프레임 사이에 Telnet 또는 HTTP 프록시 서버를 사용하여 레거시 애플리케이션에 대한 안전한 액세스를 구현하는 것입니다.

일부 조직에서는 완전한 시스템을 생성하는 자동 비즈니스 프로세스(ABP) 소프트웨어로 전환하고 있습니다.그런 다음 이러한 시스템은 조직의 레거시 시스템에 연결하여 데이터 저장소로 사용할 수 있습니다.이 접근방식은 많은 이점을 제공할 수 있습니다.사용자는 레거시 시스템의 비효율성으로부터 격리되어 변경 사항을 ABP 소프트웨어에 빠르고 쉽게 통합할 수 있습니다.

모델 중심의 리버스 및 포워드 엔지니어링 접근방식을 레거시 [9]소프트웨어의 개선에 사용할 수도 있습니다.

NASA의 예

뮌헨 공과대학의 안드레아스 하인 교수는 우주 탐사에서 레거시 시스템의 사용을 연구했다.Hein에 따르면 조직이 검증, 검증, 테스트 및 운영 [10][11]이력을 수행할 수 있는 기능을 가지고 있다면 레거시 시스템은 재사용하기에 매력적이라고 합니다.이러한 기능은 개발, 구현, 사용 또는 유지보수 등 다양한 소프트웨어 라이프 사이클 단계에 통합되어야 합니다.소프트웨어 시스템에서는 시스템을 사용하고 유지하는 기능이 매우 중요합니다.그렇지 않으면 시스템의 이해와 유지보수가 점점 어려워집니다.

Hein에 따르면 검증, 검증, 테스트 및 운용 이력은 시스템의 신뢰성과 품질에 대한 신뢰를 높입니다.그러나 이러한 역사를 축적하는 것은 종종 비용이 많이 든다.NASA의 퇴역 우주왕복선 프로그램은 1970년대 많은 양의 기술을 사용했다.대체는 비행 인증에 비용이 많이 들기 때문에 비용이 많이 들지 않았다.원래 하드웨어는 비행에 비용이 많이 드는 통합 및 인증 요건을 완료했지만, 새로운 장비는 이 모든 과정을 다시 거쳐야 했습니다.이 길고 상세한 프로세스에서는 단일 유닛을 우주왕복선 프로그램에서 사용하기 전에 새로운 구성의 새로운 컴포넌트에 대한 광범위한 테스트가 필요했습니다.따라서 인증 과정을 시작한 모든 새로운 시스템은 비행이 승인될 때까지 사실상의 레거시 시스템이 됩니다.

또한 지상과 발사체 자산을 포함한 전체 우주왕복선 시스템은 폐쇄 시스템으로 함께 작동하도록 설계되었다.사양이 변경되지 않았기 때문에 인정된 모든 시스템 및 컴포넌트는 설계된 [12]역할에서 양호한 성능을 발휘했습니다.우주왕복선이 2010년에 퇴역하기로 예정되어 있기 전에, NASA는 이러한 시스템을 업그레이드하고 새로운 부품을 재인증하는 것보다 1970년대의 많은 기술들을 계속 사용하는 것이 유리하다는 것을 알았다.

레거시 코드에 대한 관점

소프트웨어 엔지니어링의 일부에서는 "레거시 코드"를 구식이라는 함축 없이 기술하는 것을 선호합니다.가장 일반적인 중립 개념으로는 다른 사람으로부터 상속받은 소스 코드와 이전 버전의 소프트웨어에서 상속된 소스 코드가 있습니다.Typemock의 CEO인 Elli Lopian은 이를 "개발자들이 바꾸기를 두려워하는 코드"[13]라고 정의했습니다.Michael[14] Featers는 레거시 코드를 테스트 없는 코드로 정의했습니다.이는 자동화된 회귀 테스트 부족으로 인해 레거시 코드가 부분적으로 작동하기 어렵다는 관점을 반영합니다.또, 레거시 코드를 테스트하기 위한 특성 평가 테스트도 정의했습니다.

지니 헨드리 교수는 코드 작성을 현재의 코드 제작자들이 한 세대에서 다음 세대로 소중하고 사랑스럽게 전해지는 골동품, 가보, 이야기 등 우리 삶의 다른 유산들과 같은 코드를 만들기 위한 도전으로 규정했다.레거시 코드가 우리가 자랑스러워하는 것이라면?[15]

컴퓨팅에서 레거시라는 용어의 추가 사용

레거시 지원이라는 용어는 레거시 시스템과 함께 사용되는 경우가 많습니다.이 용어는 최신 소프트웨어의 특징을 나타낼 수 있습니다.예를 들어, "레거시 지원"을 갖춘 운영 체제는 오래된 하드웨어를 감지하여 사용할 수 있습니다.이 용어는 비즈니스 기능(예: 오래된 제품을 지원하거나 소프트웨어 유지보수를 제공하는 소프트웨어 또는 하드웨어 벤더)을 나타낼 때도 사용할 수 있습니다.

"레거시" 제품은 더 이상 판매되지 않거나, 상당한 시장 점유율을 잃었거나, 최신 버전이 아닌 제품일 수 있습니다.레거시 제품은 최신 제품보다 다소 유리할 수 있으므로 고객은 이 제품을 계속 사용할 수 있습니다.제품이 누구에게나 유리할 때, 합리적인 결정을 내리는 사람이 새로운 제품을 구입하지 않을 때, 진정한 '구식'이 되는 것입니다.

"레거시 모드"라는 용어는 특히 하위 호환성에 대해 언급하는 경우가 많습니다.자신의 이전 버전인 것처럼 실행할 수 있는 소프트웨어 제품은 "레거시 모드에서 실행 중"이라고 합니다.이러한 기능은 운영 체제 및 인터넷 브라우저에서 흔히 볼 수 있으며, 많은 응용 프로그램이 이러한 기본 구성 요소에 의존합니다.

컴퓨터 메인프레임 시대에는 많은 애플리케이션이 레거시 모드로 실행되었습니다.오늘날의 비즈니스 컴퓨팅 환경에서 n계층 또는 3계층 아키텍처는 단일 시스템을 구성하는 많은 컴포넌트를 포함하고 있기 때문에 레거시 모드로 전환하기가 더 어렵습니다.

가상화 테크놀로지는 최신의 혁신입니다.레거시 하드웨어를 에뮬레이트하는 소프트웨어 시스템에서 오래된 운영 체제와 브라우저를 실행함으로써 레거시 시스템을 최신 하드웨어에서 계속 가동시킬 수 있습니다.

브라운필드 건축

프로그래머들은 건설업계에서 브라운필드라는 용어를 빌려왔습니다. 건설업계는 이전에 개발된 토지(종종 오염되고 버려진 토지)[16]를 브라운필드라고 부릅니다.

  • 브라운필드 아키텍처는 레거시 시스템을 통합한 소프트웨어 또는 네트워크 아키텍처의 한 종류입니다.
  • 브라운필드 도입은 레거시 컴포넌트를 유지하는 기존 소프트웨어 또는 네트워크 아키텍처에 대한 업그레이드 또는 추가입니다.

대체 뷰

1999년 Dotcom 버블이 종료된 이후 레거시 시스템은 단순히 사용 중인 컴퓨터 시스템일 뿐이라는 긍정적인 견해도 있습니다.

"레거시 코드"는 실제로 작동하고 확장된다는 점에서 제안된 대안과 종종 다릅니다.

--

IT 분석가는 비즈니스 로직을 교체하는 [citation needed]비용이 재사용 비용의 약 5배에 달하며, 시스템 장애 및 보안 침해의 위험도 줄일 수 있을 것으로 추정합니다.기업은 대부분의 핵심 비즈니스 논리를 다시 작성할 필요가 없습니다. 즉, 차변 = 크레딧은 지속적인 요구사항입니다.

IT업계는 "레거시 현대화"와 "레거시 혁신"으로 대응하고 있습니다. 즉, 기존 비즈니스 로직을 새로운 사용자 인터페이스로 재정비하고 때로는 웹 서비스를 통한 스크린 스크랩 및 서비스 지원 액세스를 사용합니다.이러한 기술을 통해 조직은 기존 코드 자산을 이해하고(검출 툴을 사용하여), 기존 코드에 새로운 사용자 및 애플리케이션 인터페이스를 제공하며, 워크플로우를 개선하고, 비용을 억제하고, 위험을 최소화하며, 기존 서비스 품질(업타임, 보안, 확장성 등)[citation needed]을 누릴 수 있습니다.

이러한 경향은 레거시 시스템의 내구성에 대한 반성도 불러옵니다.기술자들은 비용이 많이 들고 위험한 개서를 피하기 위해 처음부터 건전한 아키텍처의 중요성을 다시 배우고 있습니다.가장 일반적인 레거시 시스템은 구현 시 세심한 계획과 엄격한 방법론을 갖춘 잘 알려진 IT 아키텍처 원칙을 채택한 시스템인 경우가 많습니다.부실하게 설계된 시스템은 오래가지 못하는 경우가 많습니다. 마모된 시스템과 고유의 결함으로 인해 교체가 필요하기 때문입니다.따라서 많은 조직이 레거시 시스템의 가치와 그 시스템의 이론적 토대를 재발견하고 있습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Merriam-Webster". Retrieved June 22, 2013.
  2. ^ Tawde, Swati. "Legacy System". educba.{{cite web}}: CS1 maint :url-status (링크)
  3. ^ (예를 들어 Bisbal et al., 1999 참조).
  4. ^ Lamb, John (June 2008). "Legacy systems continue to have a place in the enterprise". Computer Weekly. Retrieved 27 October 2014.
  5. ^ Stephanie Overby (2005-05-01). "Comair's Christmas Disaster: Bound To Fail - CIO.com - Business Technology Leadership". CIO.com. Retrieved 2012-04-29.
  6. ^ Razermouse (2011-05-03). "The Danger of Legacy Systems". Mousesecurity.com. Archived from the original on March 23, 2012. Retrieved 2012-04-29.
  7. ^ "Benefits of Mainframe Modernization". Modernization Hub. Retrieved 2017-08-23.
  8. ^ McCormick, John (2000-06-02). "Mainframe-web middleware". Gcn.com. Retrieved 2012-04-29.
  9. ^ Menychtas, Andreas; Konstanteli, Kleopatra; Alonso, Juncal; Orue-Echevarria, Leire; Gorronogoitia, Jesus; Kousiouris, George; Santzaridou, Christina; Bruneliere, Hugo; Pellens, Bram; Stuer, Peter; Strauss, Oliver; Senkova, Tatiana; Varvarigou, Theodora (2014), "Software modernization and cloudification using the ARTIST migration methodology and framework", Scalable Computing: Practice and Experience, 15 (2), doi:10.12694/scpe.v15i2.980
  10. ^ A.M. Hein (2014), How to Assess Heritage Systems in the Early Phases?, 6th International Systems & Concurrent Engineering for Space Applications Conference 2014, ESA
  11. ^ A.M. Hein (2016), Heritage Technologies in Space Programs - Assessment Methodology and Statistical Analysis, PhD thesis Faculty of Mechanical Engineering, Technical University of Munich
  12. ^ A.M. Hein (2014), How to Assess Heritage Systems in the Early Phases?, 6th International Systems & Concurrent Engineering for Space Applications Conference 2014, ESA, p. 3
  13. ^ Lopian, Eli (May 15, 2018). "Defining Legacy Code". Retrieved June 10, 2019.
  14. ^ Michael Featers의 레거시 코드(ISBN 0-13-117705-2)로 효과적으로 작업
  15. ^ Ginny Hendry (11 Jul 2014). "Take Pride in Your Legacy (Code)". Retrieved 2021-10-07.
  16. ^ "Definition of greenfield and brownfield deployment". Searchunifiedcommunications.techtarget.com. Retrieved 2012-04-29.

추가 정보

외부 링크