‘7R’로 기억하는 클라우드 앱 현대화 방식 7가지

기존 앱을 클라우드에 그대로 이전해도 충분할 지, 아니면 처음부터 다시 만들어야 할지 모한가? 앱을 현대화할 때 반드시 고려해야 할 사업적, 기술적 요소에 대해 알아본다. 
 
 
클라우드 앱 현대화. 흔한 문구지만 그 방식은 여전히 중구난방이다. 일단 사용자 측에서 원하는 건 분명하다. 현대화된 클라우드 앱이라면 더 안정적이고, 더 빠르게 작동하며, 더 짧은 주기로 업데이트되길 기대한다. 

하지만 문제는 개발 측이다. 설계자, 소프트웨어 개발자, 데브옵스 엔지니어 등의 기술자는 클라우드 앱 현대화라는 개념을 제각각 해석한다. 클라우드 앱을 현대화하는 기술적 방법이 여러가지이기 때문이다. 특정 방법이 항상 최상의 선택이라는 보장도 없다. 

예를 들자면 수십 명의 사용자가 활용하는 워크플로우 앱이 있다고 가정해보자. 개발자들은 최신 버전의 자바와 마이SQL(MySQL)로 이 앱을 만들었다. 퍼블릭 클라우드에 ‘들어서 이식(리프트앤시프트 ; lift and shift)’, 즉 그대로 옮기기만 하면 끝이다. 구성 요소를 변경하고, CI/CD를 업데이트하고, 테스트 자동화를 재실행하는 등의 작업이 필요하지만 코딩 작업량은 적은 편이다. 

반면 같은 앱이 코볼(COBOL) 같은 프로그래밍 언어로 개발됐고 메인프레임에서 실행되는 것이라면, 클라우드로 이전하기 전 많은 코드가 전면 수정돼야 할 가능성이 크다. 

물론 리프트앤시프트과 전면 재작성이라는 선택지만 있지 않다. 클라우드 앱을 현대화하는 방식은 그 사이에 여러가지가 있다. 여기 그 중 대표적인 방법 7가지(7R’s)와 선택을 도와줄 수 있는 팁을 소개한다. 
 

선택의 기준

개발 방식을 선택하려면 어떤 요소를 고려해야 하는지부터 알아야 한다. 많은 기업은 수천가지가 넘는 레거시 애플리케이션을 떠안고 있다. 어떤 앱은 기술 부채가 상당할 수 있지만, 또 어떤 앱은 이전했을 때 사용자 혹은 기업 고객의 경험을 크게 개선할 수 있다. 현대화를 맡은 설계 및 기술 담당자는 사업적 요구사항과 기술적 제약 등을 총체적으로 결정해 접근 방식을 현명하게 골라야 한다. 

먼저 사업 운영과 사용자에게 끼치는 영향을 기준으로 보자면, 사업 의존도와 사용도가 매우 높은 앱은 가끔 사용되는 앱과 철저히 분리해야 한다. 또한 어떤 식으로 현대화를 하든 최종 사용자와 충분히 소통해야 한다. 끊임없이 테스트하고 업무 흐름에 끼칠 수 있는 영향에 대해 논의해야 한다. 

퍼시스턴트 시스템스(Persistent Systems)에서 클라우드 및 인프라 부분을 맡고 있는 니사 푸스란 부사장은 앱 현대화 접근 방식을 택할 때 중요한 비즈니스 요인에 대해  “리프트앤시프트, 리팩토링(refactoring), 전면 재작성(rewriting) 등의 선택지 중 어떤 방식을 어떤 앱에 적용해야 할지 몰라 고민에 빠진 기업이 많을 것 같다. 어떤 순서로 해야 할지도 헷갈릴 듯하다. 확장성, 비용 효율성, 잠재적 기술 부채 최소화, 운영 다운타임과 개발 기간을 비롯한 수많은 고려사항에서 최적의 절충점을 찾아야할 것이다”라고 말했다. 

스플렁크(Splunk)의 최고 제품 책임자인 가스 포트는 회사의 데브옵스 팀이 앱 현대화로 누린 장점에 대해 얘기했다. 그는 “클라우드를 이전한 결과 비용 절감과 보안 및 회복탄력성 향상이라는 장점을 경험했다. 종합적으로 소프트웨어 전달(software delivery)의 규모를 확장해 사용자 경험을 크게 개선했다”라며 “특히 데브옵스 팀의 생산성과 업무 속도가 향상돼 사용자 경험 개선에 더 집중할 수 있었다”라고 전했다. 

가스 포트 CPO가 말한대로 성공적인 현대화를 이루려면 데브옵스 및 설계 팀은 사업, 기술, 운영, 보안 모든 측면에서 각 앱을 검토해야 한다. 그후 다음과 같은 현대화 접근방식을 고려할 수 있다. 
 

1.    소명을 다한 앱은 그만 놓아주기(Retire)

유선 전화나 팩스 같은 옛 업무 방식을 지원하는 앱을 아직 운영 중이라면, 이제 그만 놓아줄 때다. 모든 정리가 그렇듯 현대화는 버리는 것부터 시작하곤 한다.

어쩔 때는 어떤 앱을 버려할지가 분명하다. 회사 직원들이 특정 앱이 더 이상 필요하지 않다고 동의했거나, 존재 여부가 사업 운영에 전혀 영향을 끼치지 않는 경우다. 설령 오래된 앱이 조금이라도 쓰이거나 어떤 사업적 역할을 하고 있더라도, 그 가치는 현대화나 지원 비용 같은 기준에 비춰 상대적으로 평가돼야 한다. 

컨설팅 솔루션(Consulting Solutions)의 부사장 아미트 파텔은 “버리는 것 또한 전략이다. 사용자 경험을 개선할 수 있다면 말이다. 오래된 앱을 버리는 결정은 효율성과 고객 경험을 쉽게 향상하는 방법 중 하나다. 오래된 앱은 보안 위험성도 크기에 공격 표면을 줄이는 효과도 있다”라고 말했다. 
 

2.    기존 앱을 SaaS, 상용, 혹은 오픈소스 앱으로 대체하기 (Replace) 

스플렁크 CPO 포트에 따르면 독자 솔루션이 더 이상 필요하지 않을 때가 대체할 시점이다. 그는 “보통 회사가 직접 제작한 애플리케이션을 더 이상 쓰지 않기로 결정했을 때, 외주 업체가 만들어 놓은 클라우드 솔루션을 쓸 수 있을 때 대체제를 고려하기 시작한다”라고 설명했다. 

요즘 기업이 대체하려는 대표적인 앱으로는 고객 관계 관리(Customer Relationship Management), 콘텐츠 관리 시스템(Content Management System)이나 맞춤설계된 워크플로우 도구 등이 있다. 아직 이에 상응하는 SaaS, 상용, 혹은 오픈소스 대체재가 마땅하지 않았던 시절 도입하거나 개발한 솔루션이다. 하지만 오늘날은 상황이 다르다. 비용이 더 저렴하면서도 더 나은 경험을 제공하는 솔루션이 많다. 
 

3.    클라우드로 앱을 이전하기 (Relocate)

사업 요구사항에 걸맞고, 지원되는 소프트웨어 스택으로 구동되는 앱이라면 클라우드 이전 고려 대상이 된다. 이런 앱을 별도 하드웨어나 가상머신에서 구동하는 대신 클라우드로 옮겨 개선할 수 있는 기술적, 사업적 요소를 찾는 것이 아키텍처 및 데브옵스 팀의 목적이다. 예컨대 특정 앱을 프라이빗 혹은 퍼블릭 클라우드로 옮겨 개발 및 테스트 환경 구성, 프로덕션 자동 확장, 사고 복구 환경 구성 등의 작업이 훨씬 더 수월해진다면 이전을 고려할 만하다.    

그러나 브이펑션(vFunction)의 최고 생태계 책임자 밥 퀼린은 “클라우드로 이전했다고 무조건 현대화를 이뤘다고 보기는 힘들다”라며 “단 리프트앤시프트만 하더라도 데브옵스 팀이 얻을 수 있는 장점은 분명하고, 어떤 회사든 이전을 한다면 최소한 단기간 내에는 득을 볼 것이다. 하지만 이전만 하면 모두 끝이라는 생각은 문제가 될 수 있다”라고 지적했다. 

즉 클라우드 이전은 인프라 유연성, 향상된 보안, 비용 감소 등의 혜택을 가져다주지만, 결국 앱의 기반이 되는 코드와 제일 중요한 사후 지원 같은 더 중요한 문제를 해결하지 못한다는 설명이다.  

퀼린은 “클라우드로 이전한 모놀리식 앱은 더딘 개발 속도, 제한된 확장성, 어려운 유지보수 같은 온프레미스의 한계점을 그대로 안고 있다”라며 “’리프트앤시프트 후회(lift-and-shift regret)이라는 단어가 괜히 떠도는 게 아니다. 비용이 점점 느는데 비해 클라우드의 혜택은 희미해지고 있기 때문이다”라고 설명했다. 

그는 “이런 후회를 피하려면 기업은 무조건 클라우드로 이전할 게 아니라 더 큰 현대화 전략의 맥락에서 클라우드 이전을 하나의 구성요소로 여겨야 한다”라고 당부했다. 
 

4.    운영 가치가 있는 요소는 리플랫폼(Replatform)

많은 기업이 개발 자원을 최대한 아끼고자 리프트앤시프트((life-and-shift) 방식을 택한다. 코드를 재작성하거나 주요 구성요소를 바꾸지 않고도 클라우드 이전의 혜택을 맛보기 위함이다. 

하지만 때로 이는 바람직하지 않은 선택이다. 코드와 인프라 사이에 있는 데이터베이스 플랫폼, 프레임워크 및 구성요소를 리플랫포밍할 기회를 놓칠 수 있기 때문이다. 리플랫포밍을 하기 위해서 코드를 많이 바꿀 필요도 없다. 개발자가 참여해야 하지만, 이전하는 플랫폼이 이전 플랫폼과 유사한 점이 많으며 표준화되어 있다면 코드 작업량은 적은 편이다. 

드레미오(Dremio)의 공동 창립자이자 최고 제품 책임자인 토머 시란은 “데이터 관리 솔루션의 경우 클라우드로 이전 시  대신 리플랫포밍을 선택한다면 여러 이점이 있다. 예를 들어 기존 데이터 웨어하우스나 데이터 레이크를 클라우드로 이전한다고 치자. 이때 리플랫포밍을 접근 방식을 택해 오픈 레이크하우스나 데이터 메시(data mesh) 구조를 데이터 관리에 적용할 수 있다”라고 설명했다. 클라우드 설계자가 기존 데이터하우스 및 데이터 레이크를 운영 및 비용 효율성이 개선된 퍼블릭 클라우드 서비스로 현대화할 수 있다는 설명이다. 

이 외에도 리플랫포밍 사례로는 서비스 버스(service bus) 이전, 회사 표준 CI/CD 도구로의 이전, 콘텐츠 전달 네트워크(CDN) 변경 등이 있다. 
 

장기적 가치를 기준으로  재사용(Reuse), 리팩터링(Refactor) 그리고 재구축(Rebuild)하기 

오래된 앱을 버리거나, 대체하거나, 그대로 이전하거나 리플랫포밍하지 않고 코드를 직접 바꿔 앱을 현대화하기로 결정했다면 크게 3가지 선택지가 있다. 

5.    Reuse: 기존 앱의 데이터 모델, 서비스, API 등을 재사용한 채로 사용자 경험만 다시 만든다.
6.    Refactor: 기존 코드를 리팩토링해 성능, 보안, 유지보수 용이성을 개선한다. 코드를 깔끔하게 정리하는 등의 기타 목적도 달성할 수 있다. 
7.    Rebuild: 기능 개선, 결점 보완 혹은 기술적 부채 감축을 위해 모듈을 재구축한다. 모놀리식 앱을 마이크로서비스로 재설계할 수도 있다. 

어떤 방식이 가장 적합할까? 파텔은 “리팩토링하거나 재설계하는 것을 먼저 고려하길 권한다. 가장 비용이 크지만 더 민첩합 애자일 데브옵스 모델을 도입하려는 회사에게는 매우 적합한 방식이다. 특히 지속적으로 혁신하고 성능을 개선하고 싶다면 더더욱 그렇다”라고 말했다. 

데브옵스 팀은 단계적 접근 방식을 고려할 수도 있다. 예를 들어 먼저 지원가능한 플랫폼에서 실행되는 앱을 리호스트(rehost)해 프라이빗 혹은 퍼블릭 클라우드의 이점을 확보할 수 있다. 그 다음 사용량이 적어 업데이트 빈도가 드문 앱은 재사용, 종종 업데이트가 필요한 앱은 재설계를 택하는 것이 바람직하다. 

모든 변화에는 비용과 위험이 따른다. 앱 현대화도 마찬가지다. 몇 천개의 앱을 이용하는 기업이 앱 현대화를 마무리하려면 수년이 걸릴지도 모른다. 데브옵스 및 아키텍처 팀은 철저히 실용적인 시각으로 필요한 요소를 모두 따져 최적의 현대화 접근 방식을 택해야 할 것이다. ciokr@idg.co.kr