2021.07.29

'앱 현대화' 필수라는데... CIO가 알아야 할 어두운 비밀 11가지

Bob Lewis | CIO
레거시 애플리케이션을 현대화하는 것은 오늘날 디지털 전략의 핵심축이다. 하지만 이는 동시에 생각보다 어렵고 비용과 시간이 많이 드는 일이기도 하다. 

컴퓨터 역사를 다루는 블로그 ‘2비트히스토리닷오알지(TwoBitHistory.org)’에 따르면 포춘 1000대 기업(Fortune 1000) 가운데 95%가 여전히 IBM의 아주 오래된 계층형 DBMS인 ‘IMS’를 사용하고 있다. 

이와는 대조적으로 (필자의) 비공식적인 설문조사에 의하면 이런 레거시 환경에서 일하고자 하는 유능한 IT 개발자는 거의 없는 것으로 나타났다. 유능한 인재 영입은 CIO가 애플리케이션 포트폴리오를 현대화해야 하는 이유 중 하나다. 이 밖에도 라이선스 및 지원 비용 절감, 유연성 및 적응성 향상 등이 있다. 

하지만 ‘현대화’는 보기보다 간단하지 않다. CIO가 의사결정 시 고려해야 하는 어두운 이면을 살펴본다. 
 
ⓒGetty Images

애플리케이션 현대화는 복합적인 문제다
애플리케이션 현대화는 매우 다양한 문제와 매우 다양한 솔루션을 다룬다. 애플리케이션과 타깃에 따라 ‘앱 현대화’는 버전 업데이트, 플랫폼 재구성, 플랫폼 교체, 언어 현대화, 리팩토링, COTS 변환 등을 의미할 수 있다. 이 모든 것을 ‘현대화’라고 부르지만 공통점은 거의 또는 전혀 없다. 각각 주의해야 할 위험이 있다. 일부는 잘 알려져 있으며 일부는 그렇지 않다.

또한 (현대화가) 매우 다양한 의미를 갖는다는 사실 자체가 특히 골치 아픈 일이다. 특정 애플리케이션을 현대화하기 전에 1) 현대화할 것인지 뿐만 아니라 2) 어떤 유형의 현대화를 필요로 하는지 결정해야 하기 때문이다. 그런 다음 포트폴리오에 있는 애플리케이션의 수를 곱해야 한다.

버전 업데이트는 자체적인 부채(debt)다
일부 IT 리더십 팀은 ‘기술을 위해 기술을 구매하지 않고’, 애플리케이션과 (이를 실행하는) 인프라 관리에 있어서 ‘고장 나지 않으면 고치지 마라’라는 접근방식을 취하기 때문에 비즈니스 관점에서 합리적이라고 생각한다. 

그리고 이 논리를 상용 애플리케이션과 그리고 모든 애플리케이션(예: 서버 OS, DBMS, CMS, 개발 환경, 데스크톱 OS, 브라우저 등)이 실행되는 모든 플랫폼에 적용해 새로운 특정 기능이 새로운 특정 ROI를 제공하는 경우에만 업데이트한다. 

안타깝게도, ‘지금 지불하지 않아도 나중에 지불하게 된다(Pay-It-Now or Pay-It-Later)’라는 법칙은 여전히 유효하다. 나중에 지불하는 것은 (항상 최신 상태를 유지하는 것보다) 비용이 더 많이 들고 더 혼란스러울 뿐이다. 

플랫폼 재구성(Replatforming)은 하나의 변수만 해결한다
레거시 애플리케이션을 개방형 환경으로 이전하는 것은 또 다른 인기 있는 현대화 접근법이다. 플랫폼 재구성이란 메인프레임에서 호스팅된 z/OS+COBOL+CICS+DB2을 x85에서 호스팅된 Linux+COBOL+CICS+DB2로 마이그레이션하는 것을 의미한다. 클라우드 마이그레이션에서는 이를 ‘리프트 앤 시프트(Lift & Shift)’라고 부른다.

이렇게 하면 라이선스 및 제공업체 지원 비용을 절감할 수 있다. 어두운 비밀은? 그것이 전부다.

플랫폼 교체 비용이 더 많이 든다
더 이상 쓸모가 없거나 시장점유율 및 인지도를 잃고 있다는 이유로 애플리케이션이 실행되는 하나의 플랫폼만 변경하는 현대화 방식이 바로 플랫폼 교체다. 예를 들면 애플리케이션의 DBMS를 사이베이스(Sybase)에서 SQL 서버로 전환하는 것이다(이를 ‘플랫폼 재구성’이라고도 하지만 위에서 설명한 플랫폼 재구성과는 관련이 없다).

이를 통해 한물간 기술 사용으로 인한 위험과 취약점을 줄이고 더 나은 인재풀에 접근할 수 있다. 하지만 비용 절감이란 이점을 얻진 못한다. 교체 플랫폼의 라이선스를 확보해야 하기 때문에 오히려 비용이 증가한다. 

언어 현대화가 나쁜 상황을 더 악화시킬 수 있다
자동화된 도구가 레거시 코볼(COBOL) 코드의 비즈니스 로직을 최신 언어로 다시 작성해준다고 말하는 세일즈 피치를 본 적 있을 것이다. 이를 달성하려면 10만 줄의 코드로 작성된 코볼 애플리케이션을 10만 줄의 코드로 구성된 자바 애플리케이션으로 대체해야 한다. 이것이 언어 현대화의 어두운 비밀이다. 언어는 단순히 어휘와 문법이 아니다. 언어에는 애플리케이션 설계 철학이 있다.

또한 언어는 일반적으로 사전에 개발된 로직 라이브러리 전체를 가져온다. 새 애플리케이션을 작성하는 개발팀은 이 라이브러리를 활용한다. 코드 변환기가 이를 수행할 수 있는 경우는 거의 없다. 즉 생성된 변환 코드를 유지하는 건 더 어렵다는 의미다. 

리팩토링이 진정한 현대화다(즉 비용과 시간이 많이 소요된다)
리팩토링(Refactoring)은 오래된 애플리케이션 구조를 검증된 관행(예: 데이터를 정규화하거나 단일 코드를 마이크로서비스 아키텍처로 재구성 등)에 맞게 변환하는 현대화 기법이다. 

일부 도구는 이러한 구조 조정의 대부분을 자동화한다고 주장한다. 물론 써보는 것도 나쁘진 않다. 단 (그렇게 주장하는) 업체가 비용을 부담할 때 몇 가지 개념증명(PoC)을 통해 도구가 광고된 대로 작동하는지 확인하는 게 좋다. 

주의해야 할 것이 또 있다. 일부 자동화된 리팩토링 버전은 애플리케이션 동작(behavior)을 정확하게 유지한다. 이는 비즈니스 중단을 최소화할 순 있지만 하룻밤 사이에 배포한 애플리케이션을 실시간 프로세싱으로 변환하진 않는다. 아키텍처 변경이 경쟁 우위를 끌어낼 가능성이 크다.

리팩토링은 향상된 적응성과 유연성으로 비즈니스 이점을 제공한다. 하지만 세상에 공짜는 없다. 맥도날드 수준으로(저렴한 비용으로) 할 수 있는 리팩토링은 없다는 이야기다. 아키텍처 현대화는 장점이 있지만 비용과 시간이 많이 든다. 

‘COTS 변환’이 현대화 기법처럼 보이지 않을 수 있지만 적절한 대안인 경우가 많다
현대화된 애플리케이션 포트폴리오로 전환하는 최선의 경로는 현 애플리케이션 생태계를 누군가 작성한 최신 애플리케이션 제품군으로 교체하는 것이다. 이는 만병통치약과는 거리가 멀다. COTS/SaaS 제품군으로의 전환을 해봤다면 이게 얼마나 어려운지 알고 있을 것이다. 

하지만 플랫폼과 아키텍처가 구식인 일련의 애플리케이션을 기업이 계획한 미래를 달성하는 데 도움이 될 수 있는 것으로 교체하는 게 가장 위험이 적고 깔끔한 방법인 경우가 많다. 

무엇을 가지고 있는지 파악하려면 자동화보다는 다른 게 필요하다
지금까지 다양한 현대화 방법의 어두운 비밀을 살펴봤다. 그렇다면 이제는 더 근본적인 부분으로 들어가 보자. 즉 애플리케이션을 현대화하려면 먼저 어떤 애플리케이션을 가지고 있는지 그리고 어떻게 개발됐는지 확인하여 (지금까지 논의한) 현대화 유형 가운데 무엇을 적용할 수 있는지 파악해야 한다. 

유감스럽게도 아주 뛰어난 자동화 검색 도구를 제공한다고 하는 업체들의 주장에도 불구하고 이러한 도구는 서버를 발견하는 데만 유용하다. 서버에서 실행되는 애플리케이션이 아니다. 

게다가 애플리케이션 인벤토리 문서가 불완전한 경우가 많다. 각 애플리케이션이 실행되는 플랫폼(개발 환경, 서버 OS, DBMS, 콘텐츠 관리 시스템 및 기타 도구)을 문서화하지 않은 경우가 많은 것이다. 이를 파악하기 전까지는 현대화 기법 중 어떤 것이 가장 큰 이점을 제공할지 선택할 수 없다.

소프트웨어는 하나의 의견이다
각 비즈니스 애플리케이션에는 조직의 어떤 측면을 운영해야 하는지에 관한 개발팀의 의견이 인코딩돼 있다. 그 의견의 구문이 코드로 작성된다. 어휘는 애플리케이션의 데이터 설계에 새겨져 있다.

예를 들어 매출채권 및 CRM 시스템 모두 고객 데이터를 유지하는 경우, 즉 2개 이상의 애플리케이션의 범위가 중복될 때 두 세트의 데이터를 동기화하기 위해 자동화가 필요하다. 

포트폴리오에 모든 중복되는 애플리케이션을 합치면 수백 개의 사용자 정의 P2P(Point to Point) 인터페이스 프로그램이 생성될 수 있으며, 개발팀은 애플리케이션을 추가하거나 변경할 때마다 이 모든 프로그램을 수정하고 회귀 테스트해야 한다. ESB 또는 이와 유사한 기술을 사용하면 각 애플리케이션의 단일 인터페이스를 정의하는 인터페이스 수를 줄이는 데 도움이 될 수 있다. 

하지만 인터페이스의 수 외에 의미론적 불일치의 문제가 있다. 매출채권과 CRM 시스템의 고객 데이터 모델이 다르기 때문이다. 동일한 엔티티에 관한 서로 다른 정의를 조정하는 것은 통합을 처음부터 까다롭게 만들고, 유지관리는 더욱더 까다롭게 만든다. 

EBS는 의미 체계가 다른 문제를 해결할 수 없다. 처음부터 기술적인 문제가 아니기 때문이다. 개발자들이 동의하지 않는다는 것이다. 

IT 인력 현대화가 애플리케이션 현대화보다 더 어려울 수 있다
현재 인력은 현재 애플리케이션 아키텍처를 구성하는 애플리케이션 및 기반 플랫폼 유지관리에는 능숙할 것이다. 또 원활한 비즈니스 운영을 위한 애플리케이션 사용 방법도 잘 알고 있을 것이다. 하지만 이들은 현대화 프로젝트에서 구축할 대체 애플리케이션과 플랫폼에는 능숙하지 않을 수 있다. 

현대화 프로젝트가 성공하려면 현재 인력이 대체(현대화)에 필요한 역량을 갖춰야 한다. 더 나아가서 사용 가능한 도구와 현재 상황을 모두 잘 알고 있는 유능한 인재만이 얻을 수 있는 비즈니스 개선 기회를 찾기 위해서도 역량을 갖춰야 한다. 

그나마 다행인 어두운 비밀은 이들을 배웅하고, 대체할 사람을 채용하는 방법은 효과가 없다는 것이다. 물론 계약을 종료해도 된다. 하지만 유능한 대체 인력을 찾는 것은 저렴하거나 쉽지 않다. 그래서 이제 언급할 마지막 어두운 비밀이 가장 어두운 이면인 것이다.

제대로 운영되고 있는 IT 조직은 현대화할 필요가 없다
잘 운영되고 있는 IT 조직은 라이프사이클 관리를 수행한다. 이러한 조직은 항상 모든 것을 최신 상태로 유지한다. 이를 통해 예산을 관리할 수 있고, 앱 현대화는 ‘대규모’ 이니셔티브 없이 꾸준히 이뤄진다. 또 애플리케이션 및 플랫폼과 함께 현대화된 인력을 유지할 수 있다는 부가 혜택이 있다. ciokr@idg.co.kr



 



2021.07.29

'앱 현대화' 필수라는데... CIO가 알아야 할 어두운 비밀 11가지

Bob Lewis | CIO
레거시 애플리케이션을 현대화하는 것은 오늘날 디지털 전략의 핵심축이다. 하지만 이는 동시에 생각보다 어렵고 비용과 시간이 많이 드는 일이기도 하다. 

컴퓨터 역사를 다루는 블로그 ‘2비트히스토리닷오알지(TwoBitHistory.org)’에 따르면 포춘 1000대 기업(Fortune 1000) 가운데 95%가 여전히 IBM의 아주 오래된 계층형 DBMS인 ‘IMS’를 사용하고 있다. 

이와는 대조적으로 (필자의) 비공식적인 설문조사에 의하면 이런 레거시 환경에서 일하고자 하는 유능한 IT 개발자는 거의 없는 것으로 나타났다. 유능한 인재 영입은 CIO가 애플리케이션 포트폴리오를 현대화해야 하는 이유 중 하나다. 이 밖에도 라이선스 및 지원 비용 절감, 유연성 및 적응성 향상 등이 있다. 

하지만 ‘현대화’는 보기보다 간단하지 않다. CIO가 의사결정 시 고려해야 하는 어두운 이면을 살펴본다. 
 
ⓒGetty Images

애플리케이션 현대화는 복합적인 문제다
애플리케이션 현대화는 매우 다양한 문제와 매우 다양한 솔루션을 다룬다. 애플리케이션과 타깃에 따라 ‘앱 현대화’는 버전 업데이트, 플랫폼 재구성, 플랫폼 교체, 언어 현대화, 리팩토링, COTS 변환 등을 의미할 수 있다. 이 모든 것을 ‘현대화’라고 부르지만 공통점은 거의 또는 전혀 없다. 각각 주의해야 할 위험이 있다. 일부는 잘 알려져 있으며 일부는 그렇지 않다.

또한 (현대화가) 매우 다양한 의미를 갖는다는 사실 자체가 특히 골치 아픈 일이다. 특정 애플리케이션을 현대화하기 전에 1) 현대화할 것인지 뿐만 아니라 2) 어떤 유형의 현대화를 필요로 하는지 결정해야 하기 때문이다. 그런 다음 포트폴리오에 있는 애플리케이션의 수를 곱해야 한다.

버전 업데이트는 자체적인 부채(debt)다
일부 IT 리더십 팀은 ‘기술을 위해 기술을 구매하지 않고’, 애플리케이션과 (이를 실행하는) 인프라 관리에 있어서 ‘고장 나지 않으면 고치지 마라’라는 접근방식을 취하기 때문에 비즈니스 관점에서 합리적이라고 생각한다. 

그리고 이 논리를 상용 애플리케이션과 그리고 모든 애플리케이션(예: 서버 OS, DBMS, CMS, 개발 환경, 데스크톱 OS, 브라우저 등)이 실행되는 모든 플랫폼에 적용해 새로운 특정 기능이 새로운 특정 ROI를 제공하는 경우에만 업데이트한다. 

안타깝게도, ‘지금 지불하지 않아도 나중에 지불하게 된다(Pay-It-Now or Pay-It-Later)’라는 법칙은 여전히 유효하다. 나중에 지불하는 것은 (항상 최신 상태를 유지하는 것보다) 비용이 더 많이 들고 더 혼란스러울 뿐이다. 

플랫폼 재구성(Replatforming)은 하나의 변수만 해결한다
레거시 애플리케이션을 개방형 환경으로 이전하는 것은 또 다른 인기 있는 현대화 접근법이다. 플랫폼 재구성이란 메인프레임에서 호스팅된 z/OS+COBOL+CICS+DB2을 x85에서 호스팅된 Linux+COBOL+CICS+DB2로 마이그레이션하는 것을 의미한다. 클라우드 마이그레이션에서는 이를 ‘리프트 앤 시프트(Lift & Shift)’라고 부른다.

이렇게 하면 라이선스 및 제공업체 지원 비용을 절감할 수 있다. 어두운 비밀은? 그것이 전부다.

플랫폼 교체 비용이 더 많이 든다
더 이상 쓸모가 없거나 시장점유율 및 인지도를 잃고 있다는 이유로 애플리케이션이 실행되는 하나의 플랫폼만 변경하는 현대화 방식이 바로 플랫폼 교체다. 예를 들면 애플리케이션의 DBMS를 사이베이스(Sybase)에서 SQL 서버로 전환하는 것이다(이를 ‘플랫폼 재구성’이라고도 하지만 위에서 설명한 플랫폼 재구성과는 관련이 없다).

이를 통해 한물간 기술 사용으로 인한 위험과 취약점을 줄이고 더 나은 인재풀에 접근할 수 있다. 하지만 비용 절감이란 이점을 얻진 못한다. 교체 플랫폼의 라이선스를 확보해야 하기 때문에 오히려 비용이 증가한다. 

언어 현대화가 나쁜 상황을 더 악화시킬 수 있다
자동화된 도구가 레거시 코볼(COBOL) 코드의 비즈니스 로직을 최신 언어로 다시 작성해준다고 말하는 세일즈 피치를 본 적 있을 것이다. 이를 달성하려면 10만 줄의 코드로 작성된 코볼 애플리케이션을 10만 줄의 코드로 구성된 자바 애플리케이션으로 대체해야 한다. 이것이 언어 현대화의 어두운 비밀이다. 언어는 단순히 어휘와 문법이 아니다. 언어에는 애플리케이션 설계 철학이 있다.

또한 언어는 일반적으로 사전에 개발된 로직 라이브러리 전체를 가져온다. 새 애플리케이션을 작성하는 개발팀은 이 라이브러리를 활용한다. 코드 변환기가 이를 수행할 수 있는 경우는 거의 없다. 즉 생성된 변환 코드를 유지하는 건 더 어렵다는 의미다. 

리팩토링이 진정한 현대화다(즉 비용과 시간이 많이 소요된다)
리팩토링(Refactoring)은 오래된 애플리케이션 구조를 검증된 관행(예: 데이터를 정규화하거나 단일 코드를 마이크로서비스 아키텍처로 재구성 등)에 맞게 변환하는 현대화 기법이다. 

일부 도구는 이러한 구조 조정의 대부분을 자동화한다고 주장한다. 물론 써보는 것도 나쁘진 않다. 단 (그렇게 주장하는) 업체가 비용을 부담할 때 몇 가지 개념증명(PoC)을 통해 도구가 광고된 대로 작동하는지 확인하는 게 좋다. 

주의해야 할 것이 또 있다. 일부 자동화된 리팩토링 버전은 애플리케이션 동작(behavior)을 정확하게 유지한다. 이는 비즈니스 중단을 최소화할 순 있지만 하룻밤 사이에 배포한 애플리케이션을 실시간 프로세싱으로 변환하진 않는다. 아키텍처 변경이 경쟁 우위를 끌어낼 가능성이 크다.

리팩토링은 향상된 적응성과 유연성으로 비즈니스 이점을 제공한다. 하지만 세상에 공짜는 없다. 맥도날드 수준으로(저렴한 비용으로) 할 수 있는 리팩토링은 없다는 이야기다. 아키텍처 현대화는 장점이 있지만 비용과 시간이 많이 든다. 

‘COTS 변환’이 현대화 기법처럼 보이지 않을 수 있지만 적절한 대안인 경우가 많다
현대화된 애플리케이션 포트폴리오로 전환하는 최선의 경로는 현 애플리케이션 생태계를 누군가 작성한 최신 애플리케이션 제품군으로 교체하는 것이다. 이는 만병통치약과는 거리가 멀다. COTS/SaaS 제품군으로의 전환을 해봤다면 이게 얼마나 어려운지 알고 있을 것이다. 

하지만 플랫폼과 아키텍처가 구식인 일련의 애플리케이션을 기업이 계획한 미래를 달성하는 데 도움이 될 수 있는 것으로 교체하는 게 가장 위험이 적고 깔끔한 방법인 경우가 많다. 

무엇을 가지고 있는지 파악하려면 자동화보다는 다른 게 필요하다
지금까지 다양한 현대화 방법의 어두운 비밀을 살펴봤다. 그렇다면 이제는 더 근본적인 부분으로 들어가 보자. 즉 애플리케이션을 현대화하려면 먼저 어떤 애플리케이션을 가지고 있는지 그리고 어떻게 개발됐는지 확인하여 (지금까지 논의한) 현대화 유형 가운데 무엇을 적용할 수 있는지 파악해야 한다. 

유감스럽게도 아주 뛰어난 자동화 검색 도구를 제공한다고 하는 업체들의 주장에도 불구하고 이러한 도구는 서버를 발견하는 데만 유용하다. 서버에서 실행되는 애플리케이션이 아니다. 

게다가 애플리케이션 인벤토리 문서가 불완전한 경우가 많다. 각 애플리케이션이 실행되는 플랫폼(개발 환경, 서버 OS, DBMS, 콘텐츠 관리 시스템 및 기타 도구)을 문서화하지 않은 경우가 많은 것이다. 이를 파악하기 전까지는 현대화 기법 중 어떤 것이 가장 큰 이점을 제공할지 선택할 수 없다.

소프트웨어는 하나의 의견이다
각 비즈니스 애플리케이션에는 조직의 어떤 측면을 운영해야 하는지에 관한 개발팀의 의견이 인코딩돼 있다. 그 의견의 구문이 코드로 작성된다. 어휘는 애플리케이션의 데이터 설계에 새겨져 있다.

예를 들어 매출채권 및 CRM 시스템 모두 고객 데이터를 유지하는 경우, 즉 2개 이상의 애플리케이션의 범위가 중복될 때 두 세트의 데이터를 동기화하기 위해 자동화가 필요하다. 

포트폴리오에 모든 중복되는 애플리케이션을 합치면 수백 개의 사용자 정의 P2P(Point to Point) 인터페이스 프로그램이 생성될 수 있으며, 개발팀은 애플리케이션을 추가하거나 변경할 때마다 이 모든 프로그램을 수정하고 회귀 테스트해야 한다. ESB 또는 이와 유사한 기술을 사용하면 각 애플리케이션의 단일 인터페이스를 정의하는 인터페이스 수를 줄이는 데 도움이 될 수 있다. 

하지만 인터페이스의 수 외에 의미론적 불일치의 문제가 있다. 매출채권과 CRM 시스템의 고객 데이터 모델이 다르기 때문이다. 동일한 엔티티에 관한 서로 다른 정의를 조정하는 것은 통합을 처음부터 까다롭게 만들고, 유지관리는 더욱더 까다롭게 만든다. 

EBS는 의미 체계가 다른 문제를 해결할 수 없다. 처음부터 기술적인 문제가 아니기 때문이다. 개발자들이 동의하지 않는다는 것이다. 

IT 인력 현대화가 애플리케이션 현대화보다 더 어려울 수 있다
현재 인력은 현재 애플리케이션 아키텍처를 구성하는 애플리케이션 및 기반 플랫폼 유지관리에는 능숙할 것이다. 또 원활한 비즈니스 운영을 위한 애플리케이션 사용 방법도 잘 알고 있을 것이다. 하지만 이들은 현대화 프로젝트에서 구축할 대체 애플리케이션과 플랫폼에는 능숙하지 않을 수 있다. 

현대화 프로젝트가 성공하려면 현재 인력이 대체(현대화)에 필요한 역량을 갖춰야 한다. 더 나아가서 사용 가능한 도구와 현재 상황을 모두 잘 알고 있는 유능한 인재만이 얻을 수 있는 비즈니스 개선 기회를 찾기 위해서도 역량을 갖춰야 한다. 

그나마 다행인 어두운 비밀은 이들을 배웅하고, 대체할 사람을 채용하는 방법은 효과가 없다는 것이다. 물론 계약을 종료해도 된다. 하지만 유능한 대체 인력을 찾는 것은 저렴하거나 쉽지 않다. 그래서 이제 언급할 마지막 어두운 비밀이 가장 어두운 이면인 것이다.

제대로 운영되고 있는 IT 조직은 현대화할 필요가 없다
잘 운영되고 있는 IT 조직은 라이프사이클 관리를 수행한다. 이러한 조직은 항상 모든 것을 최신 상태로 유지한다. 이를 통해 예산을 관리할 수 있고, 앱 현대화는 ‘대규모’ 이니셔티브 없이 꾸준히 이뤄진다. 또 애플리케이션 및 플랫폼과 함께 현대화된 인력을 유지할 수 있다는 부가 혜택이 있다. ciokr@idg.co.kr



 

X