한국 마이크로소프트 / 권오성 상무
대부분의 기업은 ERP(전사적 자원 관리) 애플리케이션, CRM(고객 관계 관리) 시스템, 웹 사이트, 타사 제품 등의 비즈니스 애플리케이션을 사용하고 있다. 시간이 지날수록 비즈니스 성장, 인수 및 합병, 비즈니스 모델 변경 등으로 애플리케이션의 한계 및 문제점이 드러난다. 과거 UI/UX, 불편한 검색 기능, 외부 시스템 연계의 제약이나 성능 부족 등을 예로 들 수 있다. 어떤 경우는 ERP가 너무 오래되어 커스터마이즈가 어려워 단순한 기능 변경이나 추가조차 불가능할 수 있다. 이런 애플리케이션을 최신의 기술로 재구성하는 작업을 ‘현대화’라고 한다. 과거 메인프레임에서 클라이언트-서버의 CS 구조로, 그리고 웹 기반으로 또는 서비스(web service) 기반 클라우드 네이티브로 점차 바뀌듯 ‘현대화’란 단어는 동일하지만 내용은 지속적으로 변하고 있다.
그럼 현재의 “애플리케이션 현대화”는 무엇일까?? 공신력을 가진 가트너 컨설팅의 말을 빌려보면 “비즈니스에 최신 기능을 제공하기 위해 신규 기능의 통합을 포함해 레거시를 새 애플리케이션 혹은 플랫폼으로 마이그레이션하는 문제에 대응하는 서비스”로 정의하고 있다(참조: Gartner Application Modernization Services). 가트너는 현대화 방법과 범위에 Replatform, Rehost, Refactor, Revise, Rebuild 및 Replace 등 6가지 전략이 있다고 이야기한다. 결론적으로 현재의 비즈니스 목표와 요건을 가장 잘 지원하는 전략으로 구형 애플리케이션을 재구성하는 작업, 다시 말해 “Cloud Native Application”으로 전환하는 것을 의미한다. 지난 몇년 동안 COVID-19 포함 세계가 경험한 급격한 변화는 기업 IT 부문에도 엄청난 영향을 주고 있다. 다른 이유도 많지만 기존 IT 인프라와 애플리케이션이 팬데믹 시대의 빠른 비즈니스 대응에 한계점을 느끼게 된 것이 주요 배경으로 꼽히고 있다. 상시가용성 (always-on world)에 대한 요구가 점점 더 커짐에 따라 IT 전략도 변화하고 있으며, 많은 조직은 이 때문에 디지털 혁신 노력을 가속화해야 하는 위치가 되었다.
애플리케이션 현대화의 흐름도 주목할 필요가 있다. COVID-19 이전에 애플리케이션 현대화를 추진한 대부분의 기업은 비용 절감이나 효율화에 중점을 두었지만, 여러 이슈와 한계로 인해Rehost와 같은 기존 수준의 현대화 작업이 대부분이었다. 하지만, 팬데믹을 거치면서 애플리케이션 현대화가 단순 비용 절감을 넘어 기업 생존의 문제라는 점을 인식하여 전면적으로 현대화를 추진하는 것이 최근 기업의 추세이다. 이처럼 변화가 심한 기업 환경에서 이익과 기회를 얻는 새로운 방법을 찾고자 시스템이나 운영을 체계적으로 관리하고 현대화하는 일이 기업에 매우 중요한 우선 과제가 되었다. 본 기고에서는 단계적이고 안전하며 경제적으로 건전한 방식으로 모던 애플리케이션을 구축하기 위한 전략과 베스트 프랙티스를 설명한다. 또한, 현대화 여정을 시작하면서 기업이 조심해야 할 함정 몇 가지를 피하는 방법에 대해 살펴본다.
애플리케이션 현대화 동인 및 이점
애플리케이션 현대화는 조직에 여러 가지 비즈니스 및 기술적 이점을 가져다준다. 기업에 애플리케이션 현대화가 필요한 이유와 이점을 정리해본다.
- 신규 비즈니스 대처 어려움: 기업의 업무용 애플리케이션은 특정 업무 프로세스 처리하기 위해서 도입되기 때문에 해당 업무의 비즈니스 로직이 포함된다. 업무 프로세스 변화에 따른 로직 변경이 쉽지 않아 노후한 애플리케이션은 업무 실행이나 신규 사업 확대에 방해물이 되기도 한다.
- 사용자 및 고객 경험 만족의 저하: 기능적인 측면과 함께 애플리케이션의 사용성도 시대 흐름에 따라 개선해야 한다. 만약 새로 입사한 MZ 세대에게 30~40년 전 흑백 화면의 텍스트 기반 앱을 사용하라고 하면 어떤 반응을 보일까? COVID-19으로 재택근무를 해야 하는데 회사 네트워크나 서버에 접속할 수 없다면 어떻게 될까? 이런 다양한 사용자 및 환경 변화의 지원을 통해 사용자가 만족하는 경험을 제공해야 한다.
- 유지 보수 인력의 수급 어려움과 비용 증가: 구형의 소프트웨어 유지 보수는 어렵고 비용도 많이 소요되다. 또한, 이를 유지 보수하기 위한 전문 인력 확보도 어렵고 인건비도 높아서 신규 기능의 추가나 대 고객 서비스 수준 향상은 감히 엄두도 못 내고 현상 유지에만 급급하게 된다.
- 타 시스템 연동 및 신기술 적용의 한계: 구형의 애플리케이션은 RESTful API 등과 같은 새로운 인터페이스 기술과 서비스를 지원 못하는 경우가 많기 때문에 신규 도입한 애플리케이션과의 연동과 데이터 교환에 많은 어려움이 생기게 된다. 이러한 상황은 기업에 많은 수작업과 업무 효율 저하 문제점으로 이어진다.
- 노후화된 시스템으로 잦은 장애 발생: 구형 시스템이 기능 및 비용 측면을 충족하더라도 노후화로 인한 잦은 장애는 기업 운영에 악영향을 줄 수 있다. 시간이 지남에 따라 구형 서버, 저장 장치, 운영체제 오류 등으로 시스템 장애가 빈번하게 발생한다.
- 허술한 보안 체계: 보안 위협이 나날이 증가함에 따라 실제로 많은 기업이 희생양이 되고 있다. 오래된 운영체제는 랜섬웨어나 악성코드 등에 의한 보안 공격에 취약하고 대응도 어렵다. 너무 오래된 아키텍처와 보안 체계를 사용하기 때문이다. 또한, 적절한 보안 패치가 제때 이뤄지지 않아 보안 위험은 점차 증가하게 된다.
?
애플리케이션 현대화 전략
현대화를 소극적으로 추진한다면 클라우드에 가상머신을 만들고 그 위에 기존 애플리케이션을 운영하는 것으로 끝낼 수도 있다. 이 방식은 IaaS 방식의 장점은 얻지만 클라우드가 제공하는 모든 이점을 누리는데 제약이 있다. 반면 클라우드뿐만 아니라 신기술의 이점을 모두 누릴 수 있는 클라우드 네이티브 애플리케이션 방법도 있다. 가트너가 위에서 정의한 애플리케이션 현대화 방법 중에서 가장 대표적인 3가지 방법은 다음과 같다.
- ?Cloud Deployed: Rehost 또는 Lift & Shift로 정의한다. 애플리케이션을 클라우드로 마이그레이션하여 효율적인 자원 활용을 먼저 경험한 다음, 대규모로 신속히 클라우드 마이그레이션을 진행하고자 할 때 유용한 방법이다. 기존 애플리케이션의 구조 변경을 최소화하면서 빠르게 클라우드로 전환하는 방법이다.
- Cloud Aware: Replatform으로 정의된다. PaaS (Platform as a Service)를 활용한 마이그레이션으로, PaaS의 개발 및 운영 환경을 활용해서 애플리케이션을 최적화하는 방법이다. 애플리케이션의 일부 UI나 데이터베이스 수정이 필요한 경우에 활용된다.
- Cloud Native: Refactor로 정의된다. 비즈니스 목적 및 환경 변화에 기존 애플리케이션으로 제대로 대처하기 어려울 경우에 애플리케이션의 기능 추가, 고도화 또는 성능 개선을 위한 방법으로 본 방법이 이용된다. Refactor는 애플리케이션 소스 코드의 단순 수정부터 마이크로서비스로의 전면적인 전환까지 기업의 현대화 전략에 따라 리팩토링 범위에서 필요한 부분만 선택해서 적용할 수 있다. 애플리케이션의 SaaS(Software as a Service) 화를 위한 구현이나 전환 목적으로 기업에서 많이 이용한다.
비즈니스를 디지털 방식으로 전환하기 위해 준비 중인 기업은 비즈니스 목적을 달성할 수 있도록 기존 애플리케이션을 현대화하는 전략과 방법을 결정해야 한다. 현대화를 수행하는 여러 경로가 있는데 어떤 방법을 선택할지는 각 기업의 상황과 비즈니스 목표에 따라 달라진다. ?예를 들어 리테일 업계는 워크로드를 클라우드로 마이그레이션하여 맞춤형 고객 쇼핑 환경을 제공할 때 혜택을 누릴 수 있다. 리테일 기업은 고객의 쇼핑 패턴을 수집 및 분석하여 추가 구매 옵션에 대한 추천을 작성할 수 있다. 현대화 전략에서 무엇을 선택할 것인지 결정하기는 쉽지 않지만 중요한 것은 비즈니스 목표 및 전략에 따라 클라우드의 이점을 극대화할 수 있도록 올바른 전략을 선택하고 이에 대한 체계적인 실행이다.
애플리케이션 현대화 실행 방안
기존 기업 애플리케이션을 현대화할 때 언제 어디서든 원하는 대로 애플리케이션을 실행할 수 있는 유연성을 갖추면 클라우드 환경으로 쉽게 전환할 수 있다. 아울러, 클라우드 네이티브 마이크로서비스 접근법을 취하면 클라우드에 내재된 확장성과 유연성을 활용할 수 있다. 성공적인 애플리케이션 현대화를 위한 4가지 실행 방안을 살펴본다.
1. 레거시(Legacy) 애플리케이션 평가
현재의 애플리케이션을 평가하는 것에서부터 앱 현대화 여정을 시작할 수 있다. 먼저, 즉시 클라우드에 배포할 수 있는 애플리케이션과 리팩토링(refactoring)이 필요한 애플리케이션을 식별한다. 이 여정은 지속적으로 진행되는 프로세스이다. 현대화 여정을 진행하면서 일련의 애플리케이션 평가를 완료해야 한다. 매번 평가를 완료한 후에는 조직의 목표와 예산을 기준으로 현재 상황을 파악하고 필요한 경우 평가를 반복한다.
1.1 기존 애플리케이션 식별
모놀리식 애플리케이션이라고도 불리는 기존의 애플리케이션은 지난 15년 이상 기업에서 사용되었다. 이러한 종류의 애플리케이션은 일반적으로 단일 유닛으로 결합 및 배포되는 여러 가지 서비스로 구성되어 있으며 이러한 서비스는 보통 가상 머신 안에서 실행된다. 예를 들어, 애플리케이션 티어가 입금, 출금, 잔액 조회 서비스를 제공하는 쓰리티어 아키텍처를 실행하는 가상의 뱅킹 애플리케이션을 생각해 보자. 프레젠테이션과 앱 티어는 일반적으로 특정 시스템에 단일 유닛의 형태로서 J2EE 런타임으로 배포 및 업데이트된다. 이러한 종류의 애플리케이션은 시간이 흐르면서 확장되고, 하나의 거대한 EAR 파일로 묶인 여러 개의 WAR 파일로 구성되어 있는 경우가 많다. 기초가 되는 데이터 티어는 가상 머신 안에서 실행되는 가용성이 뛰어난 관계형 데이터베이스가 담당하므로 수년간 검증된 신뢰성과 성능을 활용할 수 있다. 이러한 애플리케이션은 현대화에 적합한 기존 애플리케이션의 완벽한 예로 볼 수 있다.
1.2 복합 애플리케이션 식별
복합 애플리케이션이란 기존 애플리케이션과 클라우드 네이티브 애플리케이션이 결합된 것을 말한다. 즉, 가상 머신과 컨테이너를 모두 활용하는 애플리케이션이다. 이러한 형태의 애플리케이션은 모든 애플리케이션을 다시 작성하지 않고도 가치를 제공하는 새로운 현대적인 소프트웨어 개발 기법을 활용할 수 있으므로 많은 기업에게 “최적의 선택”이 될 수 있다. 복합 애플리케이션은 이전에 어떤 형태로든 현대화를 거친 것이다. 시간, 예산, 투자 수익률(ROI)이 허락한다면 이 여정에서 이를 계속 반복하는 것을 목표로 삼아야 한다. 예컨대, 엔터프라이즈 애플리케이션에 10가지의 고급 기능이 있는 경우, 처음 실시된 몇 회의 현대화 과정에서는 3가지만 클라우드 네이티브 모델로 전환한다. 이 3가지는 업데이트해야 하는 가장 중요한 서비스이고 가장 큰 비즈니스 가치를 제공하기 때문이다. 그 다음 소프트웨어 주기에서는 그 다음으로 중요한 2가지 서비스가 선택된다. 그리고, 이러한 과정을 계속 반복하면서 전체 애플리케이션이 완전한 클라우드 네이티브 모델로 전환되거나, 계속 진행하기에 충분한 ROI(또는 예산)가 보장되지 않을 때까지 계속된다.
1.3 클라우드 네이티브 애플리케이션 식별
클라우드 네이티브 애플리케이션은 “클라우드 태생”의 애플리케이션이다. 즉, 이러한 애플리케이션은 마이크로 서비스 기반 아키텍처를 충분히 활용하고, 컨테이너와 그에 상응하는 컨테이너 오케스트레이션 플랫폼 (예, 쿠버네티스, 레드햇 OpenShift)을 사용한다. ?이러한 애플리케이션은 일반적으로 데이터센터에서 온프레미스로, 또는 하나 이상의 퍼블릭 클라우드에서 오프프레미스로 어디서든 실행할 수 있다. 그러므로, 이러한 애플리케이션은 비즈니스 요구에 따라 원하는 곳에서 원하는 때에 실행할 수 있다. ?클라우드 네이티브 애플리케이션은 상당한 수준의 아키텍처 업데이트가 필요하지 않을 가능성이 크지만, 애플리케이션 배포, 구성, 업데이트를 위해 멀티 클라우드 관리 기능과 DevOps 자동화 파이프라인을 충분히 활용하는지 확인할 필요는 있다. 그렇게 하면 애플리케이션의 모든 구성 요소가 신뢰할 수 있고 반복 가능하며 안전한 방식으로 작동할 것이다.
2. 점진적 현대화
애플리케이션 현대화 여정에서 그 다음 수행해야 할 단계는 로드맵 작성이다. 이러한 방식으로 전체 엔터프라이즈 인프라를 모두 한 번에 처리하는 대신 한 번에 하나씩 현대화할 수 있다.
2.1 복잡성을 최소화하면서 혁신
애플리케이션 현대화는 많은 이점을 제공하지만 위험을 수반하는 경우도 많다. 특히, 프로젝트 소요 시간이 너무 길어지거나, 비용이 너무 많이 들거나, 프로젝트 완료 시기에 대한 분명한 정의 없이 프로젝트가 계속 진행되는 경우가 발생할 수 있다. 이러한 이점과 위험은 혁신과 비즈니스 가치가 실현됨에 따라 상대적으로 발생하는 복잡성을 관리해야 하는 공통된 과제가 존재한다. 미션 크리티컬 애플리케이션의 경우, 하이브리드 클라우드 환경 전반에 걸쳐 일관된 방식으로 앱과 워크로드를 개발, 실행 및 관리할 수 있는, 신뢰하는 컴퓨팅 플랫폼에서 엔터프라이즈 애플리케이션의 현대화를 진행할 때 중요한 이점이 실현된다. 그중 한 가지 주요 이점은 가치를 극대화하는 동시에 위험과 비용을 최소화할 수 있다는 것이다.
2.2 일반적인 현대화 패턴 및 사용 사례
1단계: 컨테이너를 도입하고 기존 엔터프라이즈 애플리케이션 둘러싸기. “컨테이너”라는 개념은 여러 가지 형태로 수년간 존재해 왔지만, 컨테이너가 널리 사용되기 시작한 지는 불과 3~5년밖에 되지 않았다. 이처럼 폭발적인 사용 증가는 에코시스템에 의해 촉진되었다. 즉, 널리 사용되는 컨테이너 레지스트리(예, Docker Hub)를, 개발자가 재사용 가능한 컨테이너 자산을 다운로드하고 공유할 수 있는 장소로 여기게 된 것이다. 컨테이너를 사용하면, 개별 구성요소를 필요에 따라 분리하여 리팩토링, 테스트, 재배포 및 확장할 수 있다. 이 모든 작업을 수행하기 위해 전체 애플리케이션을 중단하거나 업데이트할 필요도 없다. 이처럼 느슨하게 결합된 마이크로서비스가 하이브리드 클라우드 전반을 이동하면서 공통된 표준과 보안 세트를 책임진다. 가볍고 빨리 시작할 수 있으며 일관성 있고 이식 가능한 애플리케이션 런타임을 제공하는 것 등, 컨테이너에 본질적으로 내재된 기술 이점 외에도, 개발자들은 이러한 자산을 쉽게 공유할 수 있으므로, 기본적인 반복 작업을 수행하는 데 사용되는 시간이 줄어들고, 그에 따라 애플리케이션 구축 시간이 줄어드는 이점을 누릴 수 있다. 그러한 목적을 위해, 현대화 여정을 쉽게 시작하는 방법은 기존 애플리케이션을 새로운 혁신적인 클라우드 네이티브 서비스로 둘러싸는 것이다. 예를 들어, 앞서 언급한 가상의 뱅킹 애플리케이션에서 새로운 모바일 프론트엔드 인터페이스를 만들거나 가장 가까운 ATM을 찾아내는 클라우드 기반 위치 서비스를 활용하는 모습이다. 기존 애플리케이션을 클라우드 네이티브 서비스로 둘러싸면, 기존 애플리케이션을 중단하지 않으면서 Node.js, Python, Golang, CI/CD와 같은 새로운 프로그래밍 언어와 개발 방법론으로 혁신 및 스킬 개발의 길을 열 수 있는 위험도가 낮은 경로를 제공할 수 있다.
2단계: 컨테이너로의 전환. 애플리케이션 현대화 여정이 더 많이 진행되고 관련 기술, 툴, 프랙티스에 익숙해지면, 컨테이너 안의 패키징 애플리케이션을 평가할 수 있고, DevOps 프랙티스 활용을 통해 클라우드 전역에서 이식성이 향상된 애플리케이션을 구현하고 소프트웨어 업데이트를 더 자주 수행할 길을 열 수 있다. 애플리케이션이 이식 가능한 기술(예, Java) 기반인 경우 이 프로세스는 상당히 쉽다.
3단계: 클라우드 네이티브, 마이크로서비스 및 API 우선 아키텍처로 재설계. 앞서 설명했듯이, 애플리케이션 현대화 여정의 두 번째 단계는 애플리케이션을 컨테이너로 전환하는 것이다. 이는 반드시 이러한 애플리케이션이 진정한 의미의 클라우드 네이티브가 된다는 뜻은 아니다. 각 클라우드 네이티브 애플리케이션에는 저마다의 논리적 기능을 대표하는 마이크로서비스 세트가 있다. 또한, 각 마이크로 서비스에는 그 기능을 접하게 해주는 잘 정의된 API가 있다. 이 방법을 따르려면 통상 애플리케이션을 변경해야 하므로 단순히 애플리케이션을 컨테이너 안으로 옮길 때보다 완료하는 데 시간이 더 오래 걸릴 수 있다. 이를 염두에 두고, 이 프로세스에 반복적 접근법을 적용하면 작업을 감당할 수 있는 수준으로 계속 유지할 수 있을 것이다. 현대화 여정에 이러한 접근법을 활용하면 시장 출시 시간 단축, 개발자 효율성 향상, 애플리케이션 배포 유연성 향상, DevOps 자동화로 원활한 통합, 등의 이점을 누릴 수 있다.
3. DevOps 문화 수용
현대화 여정을 시작할 때 성공하려면 DevOps 및 자동화의 문화를 반드시 수용해야 한다. 애플리케이션 현대화의 주된 이점 중 한 가지는 더욱 향상된 품질의 소프트웨어를 더 자주 제공하는 것인데 효과적인 DevOps 및 자동화 전략을 채택하면 이러한 이점을 실현할 수 있다. ?예를 들면, 마이크로서비스와 컨테이너를 더 많이 활용하게 될수록 업계의 베스트 프랙티스는 구축 및 배포 파이프라인을 완전히 자동화하는 것이 된다.
애플리케이션을 애플리케이션 플랫폼 (예, 쿠버네티스)에 구축 또는 배포할 때 사람이 직접적인 개입이 필요하지 않아야 한다. Jenkins, Travis CI, Red Hat OpenShift Pipelines및 Tekton과 같은 기술을, 이러한 유형의 DevOps 스타일의 구축 및 배포 프로세스 생성에 사용할 수 있다. DevOps 문화는 반복 작업을 자동화하여 직원의 시간을 절약해줄 뿐만 아니라, 모든 것을 반복적이고 신뢰할 수 있는 방식으로 처리하여 품질을 향상한다.
4. 애플리케이션 배포 및 운영 통합 관리
애플리케이션을 원활하게 배포 및 운영 클라우드 관리 측면에서는 인프라 운영 및 관찰을 위한 효과적인 메커니즘을 갖추어야 성공할 수 있다. 현대의 하이브리드 클라우드 인프라에서 애플리케이션은 가상 머신, 컨테이너 또는 이 두 가지의 조합으로 구성된다. 이러한 환경은 유연성 극대화를 위해 다른 플랫폼(예, x86)과 통합될 수 있어야 합니다. 또한, 이러한 애플리케이션은 온프레미스 또는 하나 이상의 퍼블릭 클라우드, 또는 두 가지 모두에 배포할 수 있어야 한다. 그리고, 반드시 리소스 소비 현황과 애플리케이션 상태를 신속하게 파악하고 문제점을 해결할 수 있어야 한다. 또한, 애플리케이션 현대화 전략과 함께 기업은 클라우드 운영에 적합한 표준화된 보안 정책을 다시 마련해야 한다. 클라우드 환경은 레거시 환경보다 자동화 관리가 많아 사소한 보안 실수로 큰 피해를 입을 수 있기 때문이다. 마지막으로 모든 사용자의 계정이나 액세스 권한을 철저히 통제하여 비인가 접근을 허용되지 않도록 해야 한다.
애플리케이션 현대화 프로젝트를 시작하기 위해 비즈니스 우선순위부터 고려함으로써 달성해야 하는 비즈니스 가치를 명확하게 정의하게 되면 기술적 결과물의 우선순위와 범위를 지정하는 데 도움이 된다. 현대화 프로젝트를 올바른 방향으로 진행하기 위한 팁을 몇 가지 간단히 정리해 보면 다음과 같다.
- 애플리케이션 평가 ? 선택과 집중을 위해 애플리케이션을 기존 애플리케이션, 복합 애플리케이션 또는 클라우드 네이티브 애플리케이션 중 하나로 분류한다.
- 현실적인 범위 설정 - 비즈니스 케이스 작성을 준비하면서 통제 가능한 범위를 설정한다.
- 비즈니스 케이스 작성 - 애플리케이션 평가에 대한 내용으로 시작하여 가장 큰 ROI를 달성할 수 있는 애플리케이션에 초점을 맞춘다.
- 프로젝트 실행 및 평가 - 실행하면서 예상된 비즈니스 가치가 실현되는지 확인하고 이에 따라 비즈니스 케이스를 수정하고 학습 내용을 기록한다.
애플리케이션 현대화는 다양한 방식과 규모로 진행될 수 있으므로 어떻게 시작해야 할지 판단하기 힘들고 현대화 프로젝트를 통한 기업의 가치 실현 시간 단축, 제공 빈도 향상, 위험 감소를 얻기 위해서는 해당 전문가의 도움도 함께 받는 것이 좋다. 애플리케이션 현대화는 기업 비즈니스의 모든 측면을 최신 상태로 유지하고 급변하는 세상에서 발생하는 여러 문제에 대응할 준비를 갖출 수 있기 때문에 기업 생존을 위해서는 반드시 추진해야 할 투자이다.