[Programming] Legacy System: Replacement(Risk, Expensive)

Legacy System Replacement

---

포스트 난이도: HOO_Junior

[Notice] 포스트 난이도에 대한 설명

---

 

# Legacy System 

 

Legacy system이란 software에 있어서 오래된 구조나 방식을 가진 소프트웨어를 의미한다.

Legacy라는 단어를 살펴보면, 유산이라는 의미로 검색이 된다.

한국식으로 Legacy system에 대한 표현을 해보자면, 오래되었지만 그렇다고 쓸 수 없는 것이 아니라는 것이다.

물론 새로운 구조나 방식을 채택한 소프트웨어보다는 효율성이 떨어질 수는 있지만 기능적으로 사용하는데 문제가 없는 소프트웨어가 바로 Legacy system이다.

따라서 Legacy system에서도 복합적으로 비교 분석해 보았을 때 새로운 시스템을 도입하는 게 더 손해라면 오래된 소프트웨어라도 계속 사용하기도 한다.

예를 들어, 오래된 모델의 차와 신차가 있을때, 기능적인 면에서는 신차가 좋다.

하지만 현실적인 측면에서 자동차를 이용하는 횟수가 적거나 굳이 신차가 필요 없다면 오래된 모델의 자동차가 더 효율적일 수도 있다.

Legacy system도 마찬가지이다.

따라서 이론적으로는 무조건 바뀌어야될 존재가 Legacy system이지만 현실에서는 변화 없이 사용하는 경우가 종종 있다.

예시를 하나 들자면 최근 코로나 바이러스로 인해 40년간 사용 중인 데이터베이스에 에러가 발생하였고 이를 수정할 Cobol 전문 개발자를 급하게 찾던 뉴저지의 케이스도 Legacy system의 한 사례이다.

https://nymag.com/intelligencer/2020/04/what-is-cobol-what-does-it-have-to-do-with-the-coronavirus.html

NJ Governor Requests Expertise of 6 People Who Still Know COBOL

 

# Legacy system을 바꾸지 않는 이유?

Legacy system을 바꾸지 않는 이유는 복합적인 효율성 문제 때문이다.

프로그래밍적 또는 소프트웨어 측면에서의 효율성은 Legacy system을 새로운 구조나 방식으로 바꾸는 게 대부분 이점이 많은 편이다.

하지만 우리는 자본주의 사회에서 살아가고 있기 때문에 비용적인 측면을 무시할 수 없다.

또한 새로운 방식을 도입할때까지 걸리는 시간이나 새로운 방식을 도입함으로써 기존에 없던 에러가 발생한다는 위험성도 고려를 해야 한다.

이런 복합적인 측면에서 소프트웨어 사용에 지장이 없다면 기존 소프트웨어를 지속적으로 오랫동안 사용하는 경우가 꽤 많다.

특히 오래된 기업이나 공공기관에서는 Legacy system을 많이 사용하고 있다.

 

# Legacy system을 굳이 바꿔야 하는 이유?

Legacy system을 바꾸지 않아도 기능적으로 사용하는데 지장이 없을 수도 있다.

예를 들면 위의 뉴저지 사례도 40년 동안 사용하는데 문제가 없었으니 계속 해당 소프트웨어를 사용해왔던 것이다.

Legacy system을 새로운 방식으로 바꿔야 한다는 대표적인 이유에 프로그래밍적 효율성은 당연하다.

하지만 현실적인 이유는 유지 관리가 어렵다는 점도 있다.

인공지능이 웹 프로그래밍을 하고는 있지만 데이터 기반 인공지능은 사람의 손이 필요하다.

소프트웨어의 유지 관리나 개발에 있어서도 전문 개발자가 필요하다.

하지만 Legacy system은 오래된 언어나 구조를 사용한다.

그렇다보니 Legacy system을 유지 관리하거나 다룰 수 있는 개발자가 점차적으로 없어진다.

그렇게 되면 당장 문제가 발생했을때에는 해당 소프트웨어의 문제를 해결해 줄 수 없는 사람이 없을 수도 있다는 것이다.

이를 방지하기 위해서는 사전에 미리 Legacy system에 대한 효율성을 비교 분석하여 새로운 방식의 소프트웨어 도입을 미리 준비해야 한다는 것이다.

Legacy system이 기능적으로 작동을 안 하거나 프로그래밍적 효율성이 떨어져서 바꾸는 것이 아니라 관리할 수 있는 인력이 없을 경우에도 Legacy system의 새로운 방식 도입을 고려해야 한다는 것이다.

 

# Replacement: Risk vs Expensive

Legacy system을 바꿀 것인가에 대한 비교 분석을 할 때 크게 2가지 측면을 기준으로 판단한다.

Risk와 Expensive이다.

Legacy system replacement한다는 건 위험성과 비용 두 가지 문제점을 가져올 수 있다.

첫 번째로 Risk는 위험성을 의미한다.

예를 들어, 새로운 방식을 도입했을 때 기존 시스템보다 구체적인 측면에서 완성도가 떨어질 수 있다.

또한 Legacy system을 새롭게 바꿀려다보니 오래된 해당 소프트웨어에 대한 자료가 없는 경우도 있다.

마지막으로 실질적으로 기존 소프트웨어를 기반으로 새로운 소프트웨어를 개발하다 보니 비용이 예상보다 증가할 수 있고 개발 기간도 길어질 수 있다.

두 번째로는 expensive이다.

Legacy system을 바꾸기 위해서는 기존에 사용된 computing style을 이해해야 하는데, 개발자들 사이에서 모르는 경우가 있다.

너무 오래된 방식을 채택하다 보니 현직 개발자들 사이에서는 모르는 스타일을 이해하고 수정하기가 어렵다.

또한 프로그래밍 언어적 측면도 있다.

위의 뉴저지 사례와 같이 코볼과 같은 이전에 대중적으로 사용되던 언어 기반으로 소프트웨어가 개발이 되었다면 현직 개발자가 해당 언어를 새롭게 배워 Legacy system을 바꾸는 것은 쉽지 않은 일이다.

그렇다면 기존 프로그래밍 언어 개발자를 찾아서 시스템 구조 변화에 대한 요청을 해야 하지만 Legacy system이 의미하는 "오래된" 기준은 현직에서 해당 언어 개발자를 찾기 힘들 정도로 오래된 시스템을 의미하기에 현실적인 측면에서 쉽지 않은 부분이다.

시스템에 대한 불충분하고 적절하지 않은 문서 자료나 코딩에 대한 자료도 비용적인 측면을 증대시킨다.

이 외에도 오래된 시스템 구조적 문제, 시스템을 최적화하는데 개발자가 이해하기 어렵다는 점, 데이터 에러, 중복된 값, 데이터의 부재 등 Legacy system에서 발생할 수 있는 다양한 문제들은 결과적으로 비용적인 측면이 증가할 수밖에 없다.

---

# In conclusion, 3줄 요약

1. Legacy system이란 software에 있어서 오래된 구조나 방식을 가진 소프트웨어를 의미한다.

2. Legacy system을 바꿀려고 한다면 복합적인 측면에서 효율성을 고려해야 한다.

3. Legacy system replacement에는 risk과 expensive 측면을 고려해야 한다.

---