레거시 시스템

레거시 시스템(Legacy System)은 과거로부터 물려 내려온 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어 등으로 새로이 대체가 가능한 기존의 기술이다. 레거시란 영어로 자산 혹은 유산이라는 의미를 갖고 있다. 새로운 시스템에 대비해 기존 시스템을 의미하지만, 이전의 시스템을 모두 기존 시스템이라 하지 않고 새로운 시스템과 특정 관계를 주고받거나 영향을 주는 시스템을 의미한다. 기존 시스템이라고도 불린다.

개요

레거시란 영어로 자산 혹은 유산이라는 의미를 갖고 있다. 새로운 시스템에 대비해 기존 시스템을 의미하지만, 이전의 시스템을 모두 기존 시스템이라 하지 않고 새로운 시스템과 특정 관계를 주고받거나 영향을 주는 시스템을 의미한다. 일부에서는 기존 시스템을 노후화된 하드웨어, 복잡하고 비대해진 애플리케이션, 특정 공급 업체에 의존도가 높은 시스템 등과 같이, 보수 또는 교체가 불가피한 시스템이라는 의미로도 사용한다. 많은 소프트웨어 개발자들이 레거시 시스템을 사용하는 것에 잠재적 문제가 있다고 생각하고 있다. 예를 들면, 오래된 하드웨어를 위해 설계된 소프트웨어의 경우, 새로운 하드웨어에서 실행되도록 하기 위해서 에뮬레이션이나 하위 호환성을 구현해줘야한다. 기존 시스템을 클라우드 시스템으로 대체 전환하는 기업도 있다.

정보기술에서 레거시 프로그램과 데이터는 프로그래밍 언어와 플랫폼 및 기술 등에 있어, 과거로부터 물려 내려온 것들을 의미한다. 컴퓨터를 사용하는 대부분의 기업은 중요한 업무를 처리하는 레거시 응용프로그램들과 데이터베이스를 가지고 있다. 문제는, 대체로 새로운 기술과 프로그래머의 솜씨를 사용한 새롭고 보다 효율적인 코드로 변환하는 동안, 레거시 프로그램을 계속 운영시켜야 하는 데 있다. 과거에는, 많은 프로그램이 특정 업체의 운영체계에 맞게 작성되어왔다. 많은 회사가 자신들의 레거시 프로그램들을 개방형이나, 표준 프로그래밍 인터페이스를 따르는 새로운 프로그래밍 언어와 운영체계에 맞게 변환하고 있다. 미래에는 응용프로그램들을 재작성하지 않고 새롭게 갱신하는 일이 보다 쉬워질 것이며, 기업들은 어떤 회사의 운영체계에서도 자신들의 응용프로그램을 그대로 사용할 수 있게 될 것이다. 새로운 언어로 바꾸는 것 외에도, 기업들은 응용프로그램과 데이터의 위치를 재배치하고 있다. 일반적으로 레거시 시스템들은 그것들을 개발했던 플랫폼에서만 운영될 수 있었다. 대체로 새로운 개발환경은 레거시 시스템과 데이터를 계속 지원해야 할 필요에 대한 책임을 진다. 많은 새로운 도구들을 이용하여, 새로운 프로그램이 레거시 데이터베이스들을 액세스할 수 있다.

역사

• 1970년대 : 개발된 시스템을 지칭하기 위해 처음으로 '레거시 시스템'이라는 용어가 사용됐다.
• 1980년대 : 컴퓨터 제품이 고밀도 및 소형화 되기 시작한 다운사이징(Down Sizing) 시대 이후, 오픈시스템(Open System)에 대한 반대 개념으로 메인프레임이나 일괄 처리 응용 프로그램을 부정적인 의미로 부르는 경우에 사용됐다.
• 2000년대 : 인터넷 기술이 발전하면서 1990년대의 대중적인 서버-클라이언트 소프트웨어 및 시스템을 지칭하는 경우가 늘었다.

특징

대체로 새로운 개발환경은 레거시 시스템과 데이터를 계속 지원해야할 필요에 대한 책임을 지기 때문에, 많은 새로운 도구들을 이용하여 새로운 프로그램이 레거시 데이터베이스들을 액세스 할 수 있게 만든다. 영국의 중대형 기업체 중 약 100명 가량의 IT 리더들을 대상으로 실시된 조사에 따르면, 레거시 기반 설비가 디지털 전환에 가장 직접적인 장애물이라고 밝혔으며, 추가로 유연하지 못한 조직의 특성과 지속적인 관리, 자원의 필요성, 시스템 간 커스터마이징 기법과 통합이 개선되어야 할 과제로 나타났다고 한다. 뿐만 아니라 다수의 중요한 애플리케이션들이 고유의 목적을 지닌 채 기반 설비와 맞물려 제작이 되어버린 탓에 최신 사양의 환경에 맞춰 변화하기가 어렵다는 점, 제한적인 예산 문제, 소극적인 사고와 내부구조도 문제로 야기됐다. 비전과 관리 능력의 부재를 최우선 과제로 보고 이를 해결하기 위해 일부 혁신적인 기업 및 조직들은 최고 디지털 관리자라는 직책자를 고용해 디지털 전환에 대한 중요성을 계속 상기시키는 역할을 맡겼다고 한다. 가장 대표적인 레거시 시스템으로는 통합 도서관 시스템(ILS) 표준을 사용하는 도서관 시스템이 있다.

레거시 시스템 관리

레거시 시스템은 과거에 개발되어 사용되고 있으며 아직 중요한 역할을 하는 시스템이다. 따라서 기업은 레거시 시스템의 진화 전략을 수립해야 한다. 비즈니스 가치 평가로, 레거시 시스템의 비즈니스 가치를 평가할 때는 여러 이해 관계자들과의 인터뷰해야 하고 결과를 수집 및 분석해야 한다. 시스템의 사용으로, 시스템이 가끔 이용되거나 적은 수의 사람들에 의해 이용된다면 비즈니스 가치는 적다고 볼 수 있다. 비즈니스 프로세스의 지원은 상응하는 비즈니스 프로세스를 수정해야 하나 시스템을 수정하기 어렵다면, 비효율적 비즈니스 프로세스를 계속 사용해야 하므로 시스템의 비즈니스 가치는 낮다고 할 수 있다. 또한, 시스템의 신뢰성이 낮아 문제가 발생했을 때 고객에게 직접적으로 타격을 주면 시스템의 비즈니스 가치는 낮아지며, 비즈니스가 시스템의 출력 결과에 의존한다면 시스템은 높은 비즈니스 가치를 가진다.

레거시 시스템의 분류로는 어떤 관리 전략을 사용하느냐가 시스템의 품질과 비즈니스적 가치에 달려 있다. 낮은 품질과 낮은 비즈니스 가치일 때 이 시스템들은 폐기되어야 한다. 낮은 품질과 높은 비즈니스 가치일 경우에는, 비즈니스적으로는 중요하지만 관리하기가 힘들다. 따라서 재공학 과정을 거치거나, 적당한 대체 시스템으로 교체되어야 한다. 높은 품질과 낮은 비즈니스 가치일 때는 변경 비용이 많이 들지 않다면 유지보수를 지속하고, 그렇지 않으면 폐기한다. 또한, 높은 품질과 높은 비즈니스 가치일 경우에는 일반적 유지보수를 통해 계속 사용되어야 한다. 레거시 시스템의 관리 전략은 레거시 시스템을 평가하여 제한된 예산으로 할 수 있는 최선의 전략을 선택 해야 한다. 네 전략 중 하나를 선택할 수 있으며, 네 전략은 다음과 같다.

1. 시스템이 비즈니스 수행에 효과적인 도움을 주지 못할 때 시스템을 폐기하고, 비즈니스 프로세스를 수정한다.
2. 시스템이 매우 안정적이며 변경 요구가 적을 때 시스템 유지보수를 지속한다.
3. 변경으로 인해 시스템의 품질이 떨어질 때 재공학을 통해 시스템을 보수한다.
4. 타당한 비용으로 시스템 전체 또는 일부를 교체할 수 있을 때 새로운 시스템으로 대체한다.

문제점

빠르게 변하는 인터넷 속도와 정보통신기술(IT) 환경으로 인해, 정보통신기술 시스템 또한 빠르게 교체되어 가고 있다. 그렇다고 모든 시스템을 일시에 교체할 수만은 없는 실정이다 보니, 기존 시스템과 최첨단 시스템이 공존하게 되는 경우가 종종 발생하고 있다. 이러한 레거시 시스템은 보안정책의 통제에서 벗어난 섀도 정보통신기술이 되거나, 싱글 사인 온(SSO), 오동작 경보(MFA) 등 새로운 보안기술을 적용하기에 적합하지 않은 하드웨어 또는 소프트웨어로 인해 개선된 보안정책 적용이 곤란한 경우가 있다. 이로 인한 보안 허점은 해킹 및 데이터 유출 등 조직의 보안 위협의 요인이 되기도 한다. 따라서, 레거시 시스템은 교체되기 전까지 최소한의 적절한 보안 대책을 통해 관리될 필요가 있다. 또, 적용되는 보안 패치의 부족으로 랜섬웨어, 맬웨어 등의 위험에 직면하여 이전 운영체제 또는 응용 프로그램 내에 취약성을 일으킬 수 있고, 새로운 기술의 적용에 제한이 있음으로 전사적인 시스템 통합을 어렵게 할 수 있다.

지속성

고질적인 레거시 시스템의 주된 원인은 계약을 맺고 있는 정부 관계기관과 기업이다. 원격 컴퓨팅 회사에서 사용 중인 업무에 중요한 레거시 애플리케이션 중 다수는 클라우드는 고사하고 웹조차 전혀 염두에 두지 않고 설계됐다는 것이 기본 사실이라고 했다. 한 가지 예를 들면, 코이오스(Koios) 라이브러리 소프트웨어에서 찾아볼 수 있는데, 이 회사는 도서관 인쇄물을 디지털화하는 사업 모델 하에서 운영하고 있다. 코이오스의 주요 당면 과제는 수천 곳의 도서관들과 인터페이스로 연결하는 것이지만, 모든 도서관이 레거시 플랫폼에 머물러 있으며 업그레이드할 생각이 전혀 없다는 것이 문제이다. 코이오스의 최고경영자(CEO)인 트레이 고드너(Trey Godner)는 무수히 많은 레거시 도서관 시스템이 대체 불가능한 동시에 해롭다는 것이 입증됐다고 말했다. 대다수의 도서관이 통합 도서관 시스템이라 부르는 낡아빠진 표준을 사용해서 카탈로그와 대출 정보를 저장하고 있다. 기계가독형 목록(MARC) 서지정보라 알려진 기계 판독 가능 카탈로그 서지정보는 도서관들을 위한 클라우드 기반 플랫폼까지 지원하지만, 트레이 고드너에 따르면 채택한 기관은 소수에 불과하다고 한다. 트레이 고드너는 모든 공공 그리고 학교 도서관은 여전히 구식 표준에 의존하고 있으며 그 결과 복잡하고, 거의 차별화되어 있지 않으며, 유지보수가 어렵고, 점점 더 가격이 높아지는 소수 레거시 데이터베이스로 제한되어 있다고 강조했다.

변화는 느리게 단편적으로 진행되고 있다. 트레이 고드너는 도서관에 도서, 전자책, 또는 오디오 북을 판매하는 공급업체 시스템을 기존 통합 도서관 시스템과 기계가독형 목록 포맷과 호환되게 만들어야 한다고 주장한다. 트레이 고드너는 일부 출판사가 자신들의 서지정보를 비브 프레임(Bib Frame) 같은 새로운 포맷으로 전환하려 시도했지만, 결국에는 어떤 도서관도 자력으로 기존 포맷을 벗어나서 전환할 수 없었다. 기술적 요구 조건이 너무나 압도적이었다. 많은 차세대 공급업체가 데이터베이스를 긁어오기나 통합 도서관 시스템에 대한 API 액세스를 요구하고 있다. 두 가지 접근방식 모두 필요사항에 맞게 데이터를 재구성하는 방법이지만, 처리에 시간이 너무 많이 걸리고 오류 발생 가능성도 높다. 10년간의 진척은 극히 미미했으며 비슷한 다른 기업도 이런 레거시 밀착형 데이터에 대한 액세스를 확보하기 위해서 복잡한 해결 방법을 고안해낼 수밖에 없다.

해결방안

레거시 시스템을 관리하기 위해서는 이를 평가하여 제한된 예산 내에서 가능한 최선의 전략을 선택해야 한다. 또한 새로운 디지털 전화 프로그램의 개시 이전에 다양한 측면을 고려하여 이를 보완할 수 있는 대비책을 마련하는 것이 보다 중요하다는 의견도 있다.

• 모든 레거시 서버를 위한 보안 관리

보안 위협 분석 및 보안 대책 마련을 위한 보안취약점을 분석하고, 레거시 시스템에 대한 위치와 운영환경을 조사한다. 레거시 시스템이 관리하는 데이터의 유형에 대해 조사하고, 조사한 결과를 기반으로 레거시 시스템을 목록화한다. 데이터 및 시스템의 중요도에 따라 대체 가능한 우선순위를 정하고, 각 서버와 응용서비스에 대한 담당자를 지정하여 관리한다.

• 인터넷이 연결되지 않은 레거시 서버 보안 관리

가능한 적용할 수 있는 최신의 보안패치를 진행하고, 불필요한 응용프로그램 및 서비스 제거, 접근통제 정책 적용, 운영체제 업데이트 등을 통해 운영체제에 대한 보안을 강화한다. 접근이 필요한 인원과 접근 권한 및 등급을 주기적으로 점검하여 조정한다. 시스템을 지원할 수 있는 컴퓨터 백신을 설치하여 운영하고, 가능하면, 파일 무결성 보호 솔루션이나 호스트 기반 방화벽(F/W) 또는 실내 위치 추적 서비스 및 침입 탐지 시스템(IPS/IDS) 등을 설치하여 운영한다. 주기적으로 데이터 백업을 한다.

• 인터넷이 연결된 레거시 서버 보안 관리

즉시 서버를 교체하고, 단기적인 교체가 불가능한 경우에는 다음 사항의 보안 조치를 이행한다. 웹서버인 경우, 서비스의 특성을 반영한 적합한 웹 방화벽을 설치한다. 보관 중인 데이터 및 접근경로에 대한 위험관리 평가를 하고, 민감한 데이터가 있는 경우 이전을 계획한다. 주기적으로 취약점 진단을 하고 취약점을 제거한다. 운영을 최소화하여 발생할 수 있는 트래픽을 제한한다.

• 시스템상 문제

시스템이 비즈니스 수행에 효과적인 도움을 주지 못할 때 시스템을 폐기하고 비즈니스 프로세스를 수정하고, 시스템이 매우 안정적이며 변경 요구가 적은 경우에는 시스템 유지 보수를 지속한다. 변경으로 인해 시스템의 품질이 떨어지는 경우 재공학을 통해 시스템을 대체하고, 타당한 비용으로 시스템 전체 또는 일부를 교체하는 것이 가능한 경우 새로운 시스템으로 대체한다.

활용

블록체인

블록체인을 이용하면 전사적 자원관리(ERP) 시스템, 스프레드시트(spread sheet), 데이터베이스와 직접 통합되지 않고 대신 API, 기계 가독형 바코드 프로토콜(GS1) 같은 데이터 공유 표준을 이용해 레거시 데이터 시스템과 상호 운용성을 확보할 수 있다. 아마존 웹서비스(AWS), 마이크로소프트(Microsoft) 애저(Azure), 구글 클라우드로부터 클라우드 비즈니스 애플리케이션을 실행하기 때문에 실질적으로 차이가 없다고 에스피알(SPR)의 케빈 맥마헌(Kevin McMahon) 신기술 총괄이 주장했다. 이러한 특성으로 인해 블록체인이 별개이면서 서로 연결된 거래처 네트워크 안에 있는 회사에게 가장 적합하다. 반면, 내부 IT, 생산성, 운영상의 문제를 간소화하기 위해 블록체인을 이용하려 한다면, 이는 대다수 기업에게 값비싸고 시간 소모적인 선택지이다. 전통적 솔루션으로 더 적은 비용을 들여 할 수 있는데 굳이 블록체인을 이용할 이유가 없다는 것이다. 블록체인은 변경 불능의 확실한 방식으로 데이터를 통합하고 공유할 수 있게 해준다. 그러나 기업의 관점에서 볼 때 타당한 이용 사례는 공급망, 물류, 원산지 추적 등이다. 블록체인의 진정한 가치는 한 개체가 불변 원장에 데이터를 기입하는 시점인 데이터 출처를 증명하며, 거래 프로세스 로직을 네트워크 전체에 걸쳐 실행하여 스마트 계약을 가능하게 한다.

델파이 프로젝트

레거시 시스템을 활용한 대표적인 사례로 델파이(Delphi) 프로젝트가 있다. 델파이는 델파이 클라이언트를 유치해 그 장점을 그대로 살렸으며, 세밀한 사용자 기능은 향상시켰다. 또한, 2티어로 된 시스템을 3티어로 변경하고, 새로운 운영체제 지원을 위한 델파이 버전을 업그레이드했다. 그리고, 모든 업무 모듈을 업무 로직만 서버 모듈로 분리하고 화면 수정은 최소화해서 새로 도입된 프레임워크에 맞게 수정했다. 이에 개발비용을 줄이고 완성도 높은 구 시스템의 사용자 인터페이스(UI)를 유지하는 방안을 찾았다. 또한, 서버를 빼면 기존에 유지보수를 해왔던 방식에서 벗어나지 않기 때문에 새로운 기술 습득에 필요한 시간과 공수를 줄이는 효과도 얻었다. 이 프로젝트에서 사용된 개발 프레임워크는 델파이를 크라이언트개발 툴로 하고 서버는 닷넷으로 개발되었다.

스마트메이커

모바일시대에 정보통신기술 전문가들이 직면하는 최대 애로사항은, 거의 모든 부서에 거쳐 너무나 많은 앱 프로그램과 모바일서비스의 개발요구가 동시다발적으로 발생하고 있다는 것이다. 그리고 이처럼 새롭게 개발되는 대부분 모바일시스템은 조직에서 이미 운영 중인 많은 레거시 시스템과 기능연계 및 시스템통합이 이루어져야 한다는 점이라고 할 수 있다. 세상의 모든 것들이 스마트화되고 있는 날, 모바일 통합시스템은 최상위 데이터베이스 서버 단에서부터 데이터의 범용적 활용성과 중복성 회피가 실현되어야 하고, 중간층인 애플리케이션 서버 단에도 한 번 구현한 서비스 및 프로그램 기능의 재사용성이 보장되어야 하며, 최하위 단말기 단에서는 사용자 혼선과 오조작을 방지하기 위해 메뉴 체계, 사용자 인터페이스(UI) 형식 및 조작요령까지 반드시 하나의 체계로 통일돼야 한다. 따라서 조직의 최고정보관리책임자(CIO)나 정보통신기술 전문가들은 국지 시스템이나 구체적인 앱 제품 하나를 개발하는 프로젝트를 추진하기 전에, 전사적 차원에서 통합시스템을 개발 및 구축하는데 최적화된 모바일 플랫폼을 우선 선택하는 것이 매우 중요하다. 이때 가장 중요한 착안점은 향후에 개발할 무수히 많은 앱 제품들을 빠르고 경제적으로 개발하는데 최적화된 저작솔루션과 하나의 일괄된 체계와 기술적 구조로 설계되어 전사적 통합시스템을 구축하는데 필요한 모든 서버 솔루션 제품들을 제공하는 플랫폼을 무엇보다 우선 선택해야 한다는 것이다.

그런 관점에서 스마트메이커 플랫폼은, 비즈니스용 애플리케이션 프로그램의 개발에 특화된 저작도구에서부터, 이들 애플리케이션을 구동하는 모바일 엔터프라이즈 애플리케이션 플랫폼(MEAP) 서버, 다양한 레거시시스템을 연계 및 통합해주는 게이트웨이 서버, 조직 내외부의 모든 메시지를 처리해주는 푸시 서버, 사용자 단말기의 등록과 기능을 제어 통제해주는 모바일 단말 관리(MDM) 서버, 자사 고유의 앱스토어를 구축하게 해주는 앱스토어 서버 등 전사적 통합시스템 구축에 필요한 모든 서버 솔루션을 일괄 제공한다. 특히 이 플랫폼에서 제공하는 저작도구인 스마트빌더(SmartBuilder)는 최상위의 업무 프로세스 분석 및 시스템 설계 도구인 아키텍트(Architect)부터, 프로그램 화면 및 기능 설계 도구 디자이너(Designer)와 데이터베이스 구조 설계 및 애플리케이션 서버 프로그램 개발 자동화 도구인 제네레이터(Generator)는 물론, 최하위의 검수 및 유지보수에 필요한 기술 및 사양 문서를 자동 생성해주는 도구 문서 솔루션까지 모두 일괄제공하여, 모바일시스템을 설계 및 구현하는 프로젝트의 생산성을 5배 이상 획기적으로 높여준다.

레거시 온프레미스 시스템 구축

온프레미스는 기업이 자체 시설에서 구축, 보유하고 직접 운영, 유지 관리하는 프라이빗 데이터 센터를 가리킨다. 온프레미스 인프라를 사용하여 레거시 방식으로 시스템을 구축할 수 있으며, 퍼블릭 클라우드와 유사한 방식으로 사용할 수 있는 프라이빗 클라우드를 만들 수도 있다. 서비스를 목적에 맞게 설계한 후에 이를 실행하기 위한 인프라 시스템 아키텍처를 설계한다. 기존 시스템과 연동할 경우 신규 구축 대상을 선별하고, 트랜잭션 수나 데이터 처리량, 데이터베이스 사이즈 등에 대한 기초자료를 조사한다. 기초자료 분석을 통해 시스템 용량을 산정하고 서비스별 가중치를 적용하여 최종 규모를 산정한다. 서비스 용도에 따라 고려해야 할 점이 다르지만, 웹/웹 애플리케이션 서버의 경우 동시 사용자 수, 오퍼레이션 수, 인터페이스 부하 보정과 피크타임 부하 보정, 시스템 여유율 등의 분석이 필요하고 애플리케이션/데이터베이스 서버의 경우 TPS 보정치 및 네트워크, 이중화 구조, 시스템 여유율 등을 반영해야 한다. 레거시 시스템을 온프레미스로 구축하면 기업에서 제어할 수 있는 자체 데이터 센터에 위치한다. 데이터와 네트워크 트래픽은 물리 서버에서 네트워크 장비를 통해서 얼마든지 확보할 수 있습니다. 네트워크 장비에서 발생하는 데이터들은 스위치를 통해서 항상 보안 솔루션으로 전송할 수 있고, 이를 통해서 상세한 모니터링이 가능하다. 어떤 장비가 어디에서 어떤 역할을 담당하는지 완전한 가시성과 관리 권한을 확보할 수 있기 때문에 모니터링 환경 구축이 어렵지 않고 이를 분석하여 기업에 최적인 맞춤형 하드웨어를 정기적으로 구축하여 서비스 지연이나 성능 이슈를 예방하고 비용을 예측할 수 있다. 또한 지속적인 보안 우려에 대해 기업이 직접 대처할 수 있으며 보안 규제를 준수하고 동일한 개발 환경을 상용화하기에도 유리하다.

사업에 대한 유연성

레거시 온프레미스 시스템의 서비스 애플리케이션들은 이동하기가 어려우며, 증설이나 용도 전환을 위한 시간과 비용이 적지 않다. 더 이상 사용하지 않아 다른 용도로 서비스하고 싶거나 극적인 계절적 가변성을 경험하는 에너지 사업의 경우에는, 클라우드 아키텍처를 통해 동적 인프라를 가변성에 따라 민첩하게 움직이며 비용 절감 효과를 노릴 수 있다. 사업 자체가 서비스형 소프트웨어로서 가변성이 내재되어 있는 경우에는 더욱 그렇다. 보안에 대한 가시성 확보를 위해 클라우드에서 가시성을 제공해주는 보안 플랫폼과 연동을 할 수 있는 여러 제품이 있으며, 지속적으로 보완되고 있다. 온프레미스 보안은 심리적 안정성이 높지만 중대한 사업 이슈나 보안 이슈로 수정이 필요한 경우 클라우드가 더 빠르게 수정 가능하다. 클라우드를 지원하는 아키텍처는 잘 바뀌고 기업이 원하는 대로 배치를 변경할 수 있기 때문에 안전 조치를 제공하고, 에너지 기업뿐 아니라 대부분의 기업에서 클라우드가 확대되고 있는 이유 또한 보안 가시성 확대와 비용 및 민첩성이다.

정보통신기술의 현대화

접근방법

레거시 시스템을 분석하고 비즈니스 요구사항을 파악한 다음, 현대화를 통해 얻을 수 있는 수익과 비용 혹은 복잡성과 종속성 탈피 등의 가치를 설정하고 실행해야 한다. 다음은 현대화를 위한 몇 가지 접근 방법이다.

• 리호스트(Rehost)

리호스트 방식은 리프트 앤 시프트(Lift and shift) 모델이라 불리는 방식으로 온프레미스로 운영하던 애플리케이션을 클라우드 환경으로 옮기는 것을 의미한다. 소스 코드를 그대로 유지하면서 클라우드 리소스를 사용할 수 있는 방법으로서 주로 IaaS로 이동한다. 애플리케이션의 구조적인 변경이 없기 때문에 마이크로서비스와 클라우드 네이티브(Cloud Native) 같은 기능은 사용할 수 없다. 가장 기본적인 형태의 온프레미스 애플리케이션 현대화 방안으로 상대적으로 적은 비용과 낮은 위험 부담으로 실행할 수 있고, 기존 운영 환경 대비 비용이 적게 들고 가용성이 증가한다는 장점이 있다.

• 리팩터(Refactor)

리팩터 방식은 레거시 시스템의 기능만으로 고객 요구사항에 대응하기 힘들 경우 기능을 추가하거나 성능을 개선하는 방법이다. 소스 코드의 부분 수정부터 마이크로서비스 전환을 위한 기능별 구조적인 변화까지 모두 해당한다. 포괄적으로는 레거시 시스템의 재사용을 의미하기도 하는데 일례로 레거시 시스템을 API화해서 클라우드 환경이나 타 시스템과 연동하는 경우가 있다. 애플리케이션 아키텍처를 마이크로서비스로 바꾸는 구조적인 변화와 더불어 기능의 서버리스화, 컨테이너화와 같은 사례를 포함한다.

• 리플레이스(Replace)

리플레이스 방식은 말 그대로 새로운 시스템으로 교체하는 방법으로 요구사항에 맞게 시스템의 기능과 구성 요소를 새로 작성하거나 새 제품으로 바꾸는 것을 의미한다. 기존 시스템으로 제공할 수 없는 기능과 더 많은 요구사항을 해결하기 위해 사용할 수 있는 방법이다. 하지만 이는 매우 과감한 변화로 큰 비용과 위험 부담을 수반한다. 따라서 레거시 시스템의 유지 보수나 다른 방안의 적용으로 발생하는 비용이 더 클 경우에 고려하는 것이 좋다.

현대화 사례

기업마다 필요한 요구사항과 레거시 시스템의 구조에 맞는 최신화 작업을 통해 비즈니스 가치를 높이는 것이 바람직한 정보통신기술 현대화 방향이다. 다음은 각 기업 상황에 적합한 현대화를 수행한 사례이다.

• 운영비 절감 사례

미디어 기업 A사는 영상을 업로드하고 시청자들이 이를 볼 수 있도록 하는 동영상 서비스를 회사 내부의 가상기계를 기반으로 하는 프라이빗 클라우드(Private Cloud)에서 운영 중이었다. 그러나 트래픽 증감에 따른 탄력적인 운영이 불가능했고 사용량 대비 지출이 큰 네트워크 비용과 서버 유지 비용이 발생하고 있었다. 이에 프라이빗 클라우드를 포기하기로 하고 클라우드 서비스 제공업체의 서버리스로 이전했다. 그 결과 트래픽에 따른 탄력적인 확장이 가능해져 원활한 서비스를 제공할 수 있게 됨은 물론 기존 대비 40%의 운영 비용을 절감할 수 있었다. 통신 서비스기업 B사는 레거시 시스템에 마이크로서비스를 도입하고 서버리스로 이전한 결과, 사물인터넷(IOT) 플랫폼 개발과 구축 관리 비용을 80% 절약했으며, 자동차 제조기업 C사는 온프레미스 환경에서 클라우드 환경으로 이전하여 기존 대비 60%의 운영 비용을 절감했다.

• 서비스 속도 향상 사례

항공회사 D사는 레거시 시스템을 서버리스로 이전하여 성수기 하루 1,000만 건 이상의 요청을 원활하게 처리할 수 있게 되었다. 교육기업 E사는 기존 데이터 센터에서 클라우드 환경으로 전환한 결과, 소스 코드 배포, 빅데이터 저장 및 아키텍처 구축 소요 시간이 14배 이상 빨라졌다.

참고자료

• 〈레거시 시스템〉, 《위키백과》
• 〈레거시〉, 《두산백과》
• 〈기존 시스템, 旣存-, Legacy system〉, 《정보통신용어사전》, 한국정보통신기술협회
• 〈legacy;레거시〉, 《텀즈》, 2000-02-11
• 관리자, 〈마소 커버 스토리, 델파이 프로젝트 사례로 본 레거시 시스템 활용 스토리〉, 《뎁기어》, 2013-07-05
• 스마트메이커(인공지능 기반 앱 제작 프로그램), 〈ERP, CRM, GW 등 레거시시스템과의 데이터공유 및 기능연동을 쉽고 빠르게 해결하는 솔루션〉, 《티스토리》, 2017-02-08
• HPE, 〈레거시 시스템과 함께 하이브리드 IT 환경에서 살아남는 방법〉, 《아이티월드》, 2017-03-31
• Stuart Sumner, 〈Research: Legacy systems the biggest challenge in digital transformation〉, 《컴퓨팅》, 2017-06-12
• Lucas Mearian, 〈블록체인을 레거시 시스템과 통합하기··· ‘어떻게 그리고 언제’〉, 《씨아이오코리아》, 2019-01-16
• 〈ICT 서비스 구축을 위한 인프라 구성 방식에 대한 조언〉, 《엔텔스》, 2019-04-17
• 김지명 프로, 〈레거시 시스템의 새로운 비즈니스 가치 창출: IT 현대화(Modernization) 방안과 사례〉, 《삼성 에스디에스》, 2020-05-11
• 주말마다 커피숍 가는 남자 Cappuccino sapiens, 〈레거시 시스템 보안강화 방안〉, 《티스토리》, 2020-07-14

같이 보기

시스템 하드웨어 애플리케이션 에뮬레이션 다운사이징 오픈 시스템 메인 프레임 클라이언트 서버 소프트웨어 데이터베이스

API GS1 AWS 정보통신기술 랜섬웨어 맬웨어 블록체인 스프레드시트 모바일 솔루션 사용자 인터페이스

이 레거시 시스템 문서는 소프트웨어에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.

개발 : 프로그래밍, 소프트웨어 □■⊕, 데이터, 솔루션, 보안, 하드웨어, 컴퓨터, 사무자동화, 인터넷, 모바일, 사물인터넷, 게임, 메타버스, 디자인 운영체제(OS) 데비안 • 도스(DOS) • 레드햇 리눅스(RHEL) • 리눅스 • 맥OS • 붉은별 • 비에스디(BSD) • 센트오에스(CentOS) • 솔라리스 • 아이오에스(iOS) • 안드로이드 • 에이아이엑스(AIX) • 엑스윈도우 • 엠에스도스(MS-DOS) • 오에스투(OS/2) • 우분투 • 운영체제(OS) • 윈도우 • 유닉스 • 유오에스(UOS) • 지엔유(GNU) • 타이젠 • 티맥스오에스 • 페도라 • 프리비에스디(FreeBSD) 웹서버 구글 웹서버 • 아이아이에스(IIS) • 아이플래닛 • 아파치 웹서버 • 엔진엑스 • 웹투비 • 웹티어 와스(WAS) 글래스피시 • 레진 • 와스서버 • 와일드플라이(제이보스) • 웹로직 • 웹스피어 • 제우스 • 톰캣 소프트웨어 개발 도구 JDK • SDK • 나모 웹에디터 • 넷빈즈 • 델파이 • 드림위버 • 메이븐 • 비주얼 스튜디오 • 안드로이드 스튜디오 • 알스튜디오 • 앱타나 스튜디오 • 엑스코드 • 이알윈(ERWin) • 이클립스 • 인텔리제이 아이디어 • 코드블럭스 • 통합개발환경(IDE) • 파워빌더 • 파이참 버전관리 도구 깃 • 깃허브 • 버전 • 버전관리 • 분산버전관리 • 서브버전(SVN) • 서브클립스 • 젠킨스 • 토터스SVN • 형상관리(구성관리) 성능관리 솔루션 로드러너 • 밸리데이터 • 스트로버스 • 시스마스터 • 엔그라인더 • 제니퍼 • 제이미터 • 지티메트릭스 • 쿨체크 소프트웨어 BaaS • CaaS • DaaS • FaaS • IaaS • NaaS • OaaS • PaaS • QaaS • RaaS • SaaS • SECaaS • UaaS • XaaS • 가상머신 • 개발 툴 • 내그웨어 • 다운그레이드 • 도네이션웨어 • 도커 • 레거시 시스템 • 레지스트리 • 로컬호스트 • 리팩토링 • 미들웨어 • 상용 소프트웨어 • 서버 • 셰어웨어 • 셸 • 소프트웨어 • 소프트웨어 개발 • 소프트웨어 툴 • 시스템 • 시스템 소프트웨어 • 실서버 • 업그레이드 • 업데이트 • 에뮬레이션 • 에뮬레이터 • 오픈소스 • 응용 소프트웨어 • 자바 가상머신 • 자유 소프트웨어 • 커널 • 컴퓨터과학 • 크로스 플랫폼 • 크리플웨어 • 테스트 툴 • 툴 • 툴킷 • 트라이얼웨어 • 패치 • 패키지 소프트웨어 • 프로세스 • 플랫폼 • 플러그인 • 프리웨어 위키 : 자동차, 교통, 지역, 산업, 기업, 단체, 업무, 쇼핑, 블록체인, 암호화폐, 인공지능, 개발, 인물, 행사, 일반