SOA 성공전략 집중해부 … ‘방법론’으로 SOA 지속 발전

스마트 워크, 모바일 기기의 진화, 클라우드 컴퓨팅, 융합기술의 발달 등이 IT의 최대 화두가 되고 있는 상황에서 ‘SOA(Service Oriented Architecture)’라는 이슈를 던졌을 때 가장 처음 나온 반응은 ‘뜬금없다’였다. ‘SOA가 죽었나, 살았나’를 두고 펼치던 논쟁도 시들어 이미 기억 저편으로 사라져버린 지금 이 시점에 SOA를 난데없이 왜 꺼내들었는가 하는 반응이었다. 그러나 정확히 말하면 SOA가 사라진 것이 아니라 SOA가 필요한가, 그렇지 않은가에 대한 논쟁이 사라졌을 뿐이다. SOA 사망과 관련된 논쟁은 ‘SOA는 반드시 필요하다’로 결론났으며, 현재 IT 설계를 위한 기본 아키텍처가 되고 있다. 또한 SOA 사상은 기업용 애플리케이션을 설계할 때 가장 먼저 고려해야 할 사항이 됐다.

IT 자원 효율적 활용 위해 SOA 등장
SOA는 ‘애플리케이션을 레고블럭처럼 조립할 수 있도록 해주는 뼈대’라고 이해하면 쉽다. SOA와 비슷한 개념으로 EAI(Enterprise Application Integration)가 있는데, EAI는 기업의 상호 연관된 애플리케이션을 유기적으로 연동해 필요한 정보를 중앙 집중적으로 통합, 관리, 사용할 수 있는 환경을 구현한다는 사상을 담고 있다.

SOA와 EAI는 엔터프라이즈 아키텍처(EA: Enterprise Architecture)에서 시작됐다. EA는 조직의 프로세스와 정보시스템, 부서의 구조와 기능을 포괄적이고 정확한 방법으로 기술하는 방법을 말하며, 조직의 전략적 목표와 행동의 방향을 제시하는 것이다. EA가 유연성이 떨어져 시장에서 환영을 받지 못하자 SOA가 등장했다. SOA는 새로운 사상이 아니라, 이미 정립된 이론들을 잘 조합해서 기업내에 산재해 있는 분산된 IT 자원을 효과적으로 사용하자는 방법론 중 하나다.

SOA가 본격적으로 화두가 된 것은 2000년대 중반이며, 웹서비스에서 출발한 개방형 표준기술의 최종 목적지가 SOA가 될 것이라는 전망이 우세했다. 나아가 기업의 모든 서비스는 웹을 기반으로 이뤄질 것이므로, 서비스가 아니라 웹을 중심에 둔 WOA(Web Oriented Architecture)가 대세를 이룰 것이라는 주장이 나오기도 했다.

SOA가 한창 화두가 됐을 당시 많은 기업들이 SOA 기반의 IT 시스템 구축을 검토한 바 있다. 메인프레임 다운사이징 이후 개방형 시스템이 주를 이루게 되자 다양한 이종 환경으로 IT 시스템이 분산됐다. 필요에 따라 도입된 포인트 솔루션과 계열사 혹은 조직별로 달리 도입된 업무용 애플리케이션이 혼용되면서 버전관리는 커녕 보유하고 있는 IT 자산에 대한 파악도 제대로 이뤄지지 않았다. 분산된 비즈니스 조직을 정비하고, 체계적인 프로세스를 정비할 수 있도록 도와주는 SOA라는 개념이 등장하자 시스템에 대한 대대적인 업그레이드 혹은 차세대 프로젝트를 준비하는 대기업들은 SOA 파일럿 프로젝트를 시작했다. 그러나 이 중의 상당부분은 파일럿 프로젝트로 끝나고 말았다.

이상민 SAP코리아 부장은 “SOA에 대한 이해가 낮은 상태에서 과도하게 기대수준을 높였기 때문에 SOA가 파일럿 프로젝트에 그치고 말았다”며 “이는 벤더들이 과도한 마케팅으로 시장을 부풀렸기 때문”이라고 지적했다.

이상민 부장은 SOA 프로젝트에 상당한 수준으로 성공한 한 기업의 예를 들었다. 이 기업의 SOA 초기 목표는 ‘Do no Harm’이었다. SOA는 전사 영역에 구축되고, 상당한 기간동안 활용돼 IT 재사용의 효과를 볼 수 있을 때 비로소 ROI를 말할 수 있다. 이 기업은 초기 파일럿 프로젝트로는 SOA 효과를 알 수 없다는 사실을 충분히 이해했기 때문에 기존 시스템에 ‘해’를 미치지 않으면 성공한 것이라고 인식했다.

제품으로 ‘오해’한 SOA 프로젝트
SOA가 한동안 사망설에 시달려야 했던 것은 너무나 이상적이기 때문이다. 기존 IT 환경은 너무 복잡하게 얽히고 설켜있기 때문에 아주 작은 변화에도 많은 문제를 일으킨다. 새로운 서비스를 추가하는 것은 어느 정도 수준까지 자동화 할 수 있을지 몰라도, 사용하지 않게 된 서비스를 빼내는 것은 매우 높은 리스크를 감수해야 한다. 따라서 반복적인 재개발, 중복투자가 이뤄질 수밖에 없다.

이론상 SOA는 비즈니스의 변화에 따라 자유롭게 IT를 움직일 수 있으며, 한 번의 개발로 여러 서비스에 재사용할 수 있고, 고도로 숙련된 전문가가 없어도 상황에 따라 수시로 변경시킬 수 있다. 비즈니스 하나 추가할 때마다 하드웨어, 소프트웨어 벤더 담당자를 소집해 복잡한 검토절차를 거치고, 다시 개발하고, 테스트해 배포하는 과정을 거듭해온 CIO 입장에서는 눈이 번쩍 뜨일 수밖에 없다. 그러나 실제로 SOA가 적용되기에 기업의 IT 환경은 너무나 열악했다. SOA를 위해서는 반드시 업무와 조직 정비, 시스템의 트랜스포메이션이 선행돼야 하는데, 기업들은 이 과정을 모두 생략한 채 ‘SOA 기능을 하는 제품’을 덜컥 사놓고 “S OA는 거품이었다”고 비판했다.

황인찬 한국레드햇 전무는 “SOA는 IT 시스템을 설계하는 방법론 중 하나일 뿐이며, SOA를 최종목표로 하는 프로젝트나 상품은 있을 수 없다. 그러나 많은 벤더들이 SOA를 또 하나의 ‘시장’으로 생각해 상업화하려 했기 때문에 호응을 받지 못했다”고 지적했다.

SOA 사상 기반의 IT 프로젝트를 실시할 때는 여기에 참여하는 설계인력 모두 SOA를 충분히 이해해야 하며, SOA 기술을 내재화하고, 플랫폼을 이해·검증할 수 있어야 한다. 이것이 이뤄지지 않으면 웹 서비스 적용 프로젝트의 하나에 그치고 만다. SOA 기술을 제공하는 벤더들이 보다 손쉽게 판매하기 위해 SOA를 미들웨어의 하나로 홍보하면서 시장을 왜곡시켜 SOA에 대한 오해와 불신을 심화시켰다. SOA를 상품으로 이해한 기업들은 SOA의 ROI가 낮다고 여길 수밖에 없었던 것이다.

이상민 SAP코리아 부장은 “SOA는 규모가 클수록, 범위가 넓을수록, 사용기간이 길수록 효과가 뚜렷하게 나타나기 때문에 ROI 도출 방식을 달리 해야 한다. 그러나 벤더들이 시장을 빠르게 확산시키기 위해 SOA를 제품화했기 때문에 오해가 발생했다”며 “SOA에 대한 바른 인식은 당장의 수익을 기대하지 않고 미래에 대한 투자라고 생각하는 것”이라고 지적했다.

기술적인 측면에서도 SOA는 상당한 한계를 갖고 있었다. 성능과 보안의 문제였다. SOA라는 뼈대에 IT 시스템을 서비스에 맞게 플러그인 해야 하는데, 뼈대가 제 기능을 하지 못했다. 또한 서비스를 재사용할 때 이전에 사용하던 서비스를 그대로 다른 서비스에 적용하면 보안 문제가 제기된다. 이전에 수행한 서비스에 접근할 수 있는 권한과 현재 서비스에 접근할 수 있는 권한이 다를 때 역시 보안 정책 위반 시비에 걸릴 수 있다.

성능이나 보안의 문제는 기술의 발달로 해결할 수 있는 부분이다. 성능 부분은 이미 세계적인 성공사례를 통해 입증한 만큼 기술적인 문제는 상당히 해소됐다고 할 수 있다. 보안은 권한관리를 비롯한 보안 기술과 정책을 통해 해결책을 찾아야 한다. 빠른 ROI를 요구하는 국내 기업의 특성이 SOA에 대한 오해를 강력하게 전파했다. SOA는 장기간의 프로젝트로 진행돼야 하기 때문에 경영진의 장기적인 안목과 강력한 의지가 없으면 어렵다. 강력한 리더십을 기반으로 성장한 국내 기업들은 리더의 의사결정에 따라 일사분란하게 움직인다. 리더들은 투자에 대한 빠른 효과를 요구하기 때문에 IT 조직은 높은 ROI가 보장되는 프로젝트만 진행하게 된다. 따라서 장기간에 걸친 투자가 필요한 SOA는 투자 순위에서 밀리게 된다.

SOA는 현업의 프로젝트
아이러니하게도 SOA의 한계로 지적되는 문제들은 그대로 SOA의 기회가 된다. 예를 들어 국내 기업의 조직 구성이 복잡하다는 문제는 SOA를 통해 개선시킬 수 있다는 얘기도 된다. 이를 통해 의사결정 과정을 단순화해 비즈니스 민첩성을 높일 수 있으며, 비용을 절감하고 경쟁력을 제고할 수 있다. 이러한 관점에서 접근할 때 중요하게 고려할 점은 SOA는IT 프로젝트가 아니라 현업의 프로젝트라는 것이다. 서비스를 정의할 때 현업의 적극적인 참여가 반드시 필요하며, 업무와 프로세스를 정확하게 파악해야 서비스 단위를 규정할 수 있다.

SAP는 이 서비스 단위를 ‘컴포짓 애플리케이션’으로 규정해 주요 업무 로직과 프로세스를 프리 빌트 형태의 서비스로 제공한다. SAP는 엔터프라이즈 애플리케이션 전문기업의 특성을 살려 30여년간 쌓은 경험을 바탕으로 서비스 단위를 미리 규정하고 자동화시켜 산업별로 그대로 적용시킬 수 있도록 했는데, 이를 컴포짓 애플리케이션이라고 한다. SAP는 ERP, CRM, SCM 등 기업 애플리케이션의 노하우를 2800여 개의 비즈니스 서비스로 정제해 엔터프라이즈 서비스 리파지토리(ESR)에 저장해 두었고, 고객들은 이들 서비스와 프로세스를 하나씩 꺼내 업무에 필요한 형태로 조립해 사용할 수 있다. 또 저장소에 없는 서비스는 자바를 이용해 개발하고 이를 다시 레파지토리에 담아 계속 재활용할 수 있도록해 SAP 기반 애플리케이션뿐만 아니라 전사 IT의 SOA 전략을 구현할 수 있도록 한다.

SOA 이념을 적용한 컴포짓 애플리케이션의 국내 대표적인 사례는 KT의 IT 자회사인 KTDS의 ERP 시스템 ‘ds1’을 들 수 있다. KTDS는 프로세스 혁신(PI)과 전사적자원관리(ERP) 구축 작업을 동시에 진행했다.
KTDS ERP 사업이 의의를 갖는 것은 불과 6개월이라는 짧은 기간 내에 전사 시스템 구축을 완성시켰기 때문이다. KTDS는 SAP BPP(Business Process Platform) 환경을 활용해 개발 생산성을 향상시켰다. 이 사업을 통해 KTDS는 자바(웹서비스)를 활용해 쉽게 MVC 모델로 웹 애플리케이션 개발이 가능했고, ESR (Enterprise Services Reposiroty) 중심으로 한 재사용성을 증가시켰다. 넷위버(Netweaver) CE 통해 자동 생성되는 코드 증대로 핵심 로직 개발에 집중할 수 있었다.

IBM은 똑똑한 작업환경(Smart Work)을 지원하는 유연한 IT 인프라스트럭처로 정의하는 스마트 SOA 전략을 채택하고 있다. 유연한 IT 인프라스트럭처를 구축하기 위해 연결(Connectivity), 고성능 애플리케이션, SOA 어플라이언스 영역의 SOA 파운데이션(Foundation) 제품을 제공 한다. 또한 리테일, 금융, 항공, 국방, 통신 등 다양한 업계의 프레임워크 솔루션을 보유하고 있어 산업 별 베스트 프랙티스와 표준 기반 인더스트리 프레임워크 적용으로 프로젝트 기간을 단축 하고 비즈니스 운영 효율을 달성할 수 있도록 한다.
IBM은 SOA를 BPM과 결합해 더 높은 가치를 추진하며, 비즈니스의 민첩성과 프로세스의 가시성을 갖출 수 있도록 하고 있다. 사용자가 지속적으로 프로세스를 최적화할 수 있도록 비즈니스 프로세스를 모델링, 수행, 모니터링 및 변경할 수 있도록 하고, BPM으로 비즈니스 성과와 ROI 예측을 가능케 한다.

규모 따라 SOA 기대효과 달리해야
사업 규모의 문제는 SOA 확산의 걸림돌이 될 수 있다. SOA가 대규모, 장기간의 프로젝트로만 효과를 볼 수 있다면 금융권 차세대 시스템 구축과 같은 대규모 프로젝트에만 적용될 수 있을 것이다. 그러나 실제 차세대 프로젝트같은 대규모 사업에 SOA 이념을 한꺼번에 적용시키는 것은 극히 어려운 일이다. SOA는 아키텍처를 변화시키기 때문에 시스템에 어떤 영향을 미치게 될지 섣불리 예측하지 못한다.

황인찬 한국레드햇 전무는 “SOA 사상 기반의 IT 프로젝트를 빅뱅방식으로 추진하면 실패할 확률이 높다. 기존의 IT 시스템이 워낙 복잡하게 얽혀있기 때문에 설계를 바꾸면 시스템에 어떤 영향을 미칠 지 알 수 없기 때문”이라며 “작은 단위 업무에서 적용해 프로토타입을 만든 후 단계적으로 확산해야 한다”고 설명했다.

이 때문에 SOA 확산기에 기업들은 파일럿 프로젝트를 수행했지만, 대부분 ROI가 낮다고 판단해 중단하고 말았다. 비교적 성공적으로 SOA 기반 프로젝트를 끝냈지만, 정작 재사용할 서비스가 없어 ‘레고블럭’의 효과를 얻지 못한다고 토로하는 경우도 많다. 이러한 문제는 SOA가 해결해야 할 장기적인 숙제로 남겨져 있지만, 그렇다고 SOA가 가져올 막대한 가치까지 부정해서는 안된다. 긴 안목으로 봤을 때 기업의 IT 시스템은 SOA의 이념을 채택하게 될 것이기 때문이다. 만일 SOA를 단계적으로 적용한다면, 어떤 과정을 밟는 것이 가장 이상적일까? 오라클은 ▲정보 관리 ▲비즈니스 애플리케이션 ▲퓨전 미들웨어의 세 단계를 제안한다.

기업의 SOA 구현 전략은 XML, SOAP, JCA, JMS 등을 통한 IT 합리화 및 기존 시스템 효율의 극대화, BPEL, XSLT, XQuery 등을 이용한 프로세스 플로우 형성과 생산성, 재사용성의 향상, 또한 마지막으로는 포털이나 J2EE 애플리케이션 등을 통해 멀티-채널의 확장성이 높고 통합된 애플리케이션 단계 구축으로 나눌 수 있다.

오라클 SOA 스위트 11g는 시스템, 사람 및 문서 중심의 프로세스를 통합하는 단일한 프로세스 플랫폼 및 개발부터 보안, 거버넌스에 이르기까지 SOA 기능을 갖춘 이벤트 지향 아키텍처(Event Driven Architecture)를 제공한다. 오라클 SOA 스위트 11g는 오라클 애플리케이션 그리드 인프라스트럭처 상에서 구축되며 클라우드상에서 서비스를 구축하고 통합하는데 최적화됐다. 특히 오라클에 인수된 BEA가 쌓아왔던 국내 많은 기업의 경험을 바탕으로 오라클은 보다 높은 수준의 SOA 이념을 구현시킬 수 있다고 강조한다.

SOA는 IT 시스템이 복잡한 대기업에서만 필요하다고 여기는 것이 일반적이지만, 반드시 그러한 것은 아니라는 설명도 나온다. 이상민 SAP코리아 부장은 “대기업은 기존의 IT를 바꿔야 하기 때문에 복잡한 요구사항이 제기되지만, 중소·중견기업은 깨끗한 종이 위에 새롭게 설계를 할 수 있기 때문에 SOA 이념을 보다 잘 반영할 수 있다”고 말했다.

대기업의 SOA는 기존에 구축된 IT 시스템을 표준 기반 플랫폼으로 바꿔 보다 용이하게 관리하기 위해 채택된다면, 중소·중견기업은 앞으로 구축할 IT 시스템을 확장성·유연성 있게 하기 위해 SOA를 고려할 수 있다는 설명이다. 예를 들어 SOA 개념을 기업 내에 충분히 인지시키고 있다가 ERP를 도입할 때 SOA 원칙을 충실히 따른 것을 선택하고, 다른 시스템을 추가할 때도 별도로 개발하는 것이 아니라 ERP가 제공하는 서비스를 통해 확장할 수 있다.

황인찬 한국레드햇 전무는 “SOA를 적용하면 초기 투자비용이 더 높아진다는 인식 때문에 중소·중견기업에서는 쉽게 결정하지 못할 수 있다. 그러나 SOA를 위해 반드시 어떤 제품을 구입해야 하는 것이 아니라 조직과 업무를 정비하고, 여기에 참여하는 직원들의 인식 교육을 통해 충분히 기반을 마련한 다음 IT 시스템이나 솔루션을 확장할 때 이러한 사상을 바탕으로 사업을 진행하면 충분한 효과를 얻을 수 있을 것”이라고 말했다.

클라우드-SOA, 불가분의 관계
클라우드 컴퓨팅은 SOA 사상을 비즈니스로 현실화시킨 것이라고 할 수 있다. IT 자원이든, 솔루션이든, 서비스든 필요한대로 가져다 쓰고 비용을 지불하는 클라우드 모델은 비즈니스 변화에 따라 IT를 자유롭게 재구성할 수 있는 SOA 사상과 정확히 일치한다. 특히 하이브리드 클라우드 컴퓨팅에서 SOA 사상은 필수적이다. 기업 내에 구축된 프라이빗 클라우드와 외부 전문기관을 통해 서비스를 받는 퍼블릭 클라우드가 하나의 업무에 연동될 때 데이터의 정합성이나 보안 문제를 해결하기 위해서는 반드시 동일하거나 호환이 가능한 아키텍처를 기반으로 해야 한다. 즉 SOA를 기반으로 설계된 아키텍처가 필요하다는 뜻이다.

IT 담당자가 SaaS를 이용하기 위해 클라우드에 있는 서비스를 조합한다고 했을 때 기업의 레거시 시스템, 다른 서비스와의 상호작용 등 고려해야 하는 것이 매우 많다. 하드웨어 측면에서도 시스템이 클라우드로 이동하면 장애가 발생할 수 있다. SOA 기반 설계는 하드웨어 및 소프트웨어 변경시에도 가용성과 확장성을 보장할 수 있기 때문에 이러한 문제를 상당히 개선할 수 있다.

한국IBM 관계자는 “전문가들은 SOA 없이 클라우드로 전환해서는 안된다고 지적한다. 외부로 노출되지 않은 레거시 시스템을 재설계하는 데에는 많은 비용이 들기 때문”이라며 “ESB가 클라우드 컴퓨팅을 레버리지(Leverage)하는 IT 인프라의 중대한 구성요소로 자리잡을 것”이라고 말했다.

만일 복수의 클라우드가 사용되는 경우라면, 사용자는 원격 서비스를 임의의 클라우드로 연결, 사용하더라도 연결이나 상호호환성의 이슈 없이 사용하기 위해 서비스 통신을 위한 백본이 필요하다. SOA를 활용해 기업은 전체 오퍼링에서 어떤 부분을 클라우드로 옮기고 어떤 부분은 그대로 남겨둘 것인지 조망해볼 수 있다.

클라우드 사업에 가장 앞장서고 있는 IBM은 클라우드 환경에서 SOA 기반의 빠른 통합을 보장하는 캐스트아이언(Cast Iron)을 인수하면서 발빠르게 대처하고 있다. 캐스트아이언은 클라우드 기반 통합 소프트웨어, 어플라이언스 및 서비스를 제공했던 인터넷 서비스 소프트웨어 업체로, 기존 기업에서 구축된 엔터프라이즈 애플리케이션과 SaaS 형태로 제공하는 외부 서비스(Salesforce.com, NETSUITE 등)를 빠른 속도로 통합할 수 있는 기능을 제공한다.

IBM은 캐스트아이언 인수를 통해 클라우드 환경에서 더 신속한 대응력을 제공하고, 고객들이 온 프레미스(On Premise) 컴퓨터 체계를 인터넷상에서 서비스로 제공되는 애플리케이션들과 신속하게 융합될 수 있도록 한다.

최근 클라우드 전략을 강력하게 펼치고 있는 레드햇은 SOA 사상을 기반으로 설계된 ‘EAP(Enterprise Applica tion Platform)’를 제안하고 있다. 황인찬 한국레드햇 전무는 “오픈소스의 유연성은 SOA가 추구하는 이념에 가장 적합하다. 집단지성이 만들어내는 기술과 레드햇의 안정적인 지원을 통해 SOA 사상을 기업 IT에 최적화시킬 수 있다”며 “현재 레드햇의 미들웨어 제품군은 국내 대표적인 기업의 클라우드 사업에 적용, 구축되고 있다”고 말했다.

클라우드 컴퓨팅에서 출발한 백그라운드가 웹서비스이며, 웹서비스는 SOA의 대표적인 구현사례다. 클라우드 컴퓨팅을 통해 인프라와 미들웨어, 애플리케이션을 서비스할 때 SOA가 그 과정에서 매우 중요한 역할을 할 수 있다.  레드햇은 오픈소스 OS와 미들웨어를 갖고 있기 때문에 클라우드 시장에서 매우 좋은 위치에 있다고 강조한다. 레드햇은 제이보스 엔터프라이즈 미들웨어(JBoss Enterprise Middleware)를 기반으로 하는 PaaS 솔루션과 전략을 발표했으며, 여기에 SOA 사상이 적용됐다.

제이보스의 SOA 플랫폼은 애플리케이션과 조합된 서비스를 자동화된 비즈니스 프로세스로 통합시킨다. ESB에서 구축되며, 룰 엔진, 비즈니스 프로세스 자동화와 제이보스 엔터프라이즈 애플리케이션 플랫폼을 하나로의 구현체로 통합시킨다.

목적 아니라 수단으로 활용
‘SOA 사망’과 관련된 논쟁을 들여다보면 SOA가 현실성이 있느냐, 없느냐를 두고 양쪽이 같은 이야기를 반복한다는 사실을 알 수 있다. SOA는 이상적이지만 현실적이지 않다는 것이 주요 내용이며, SOA는 일종의 방법론의 하나이지 기술적인 우위를 다툴 수 있는 것은 아니라는 점이다.

SOA는 IT 벤더들에 의해 부풀려져 왔으며, 이에 대한 논쟁도 벤더들만의 것이었다고 해도 과언은 아니다. 기업이 원하는 것은 SOA 사상에서 크게 벗어나지 않는다. SOA이든, EA이든, 혹은 다른 어떤 이름이든, 기업이 원하는대로 설계할 수 있으며, 비용효율적이며 관리가 수월한 IT를 구현하는 것이 SOA의 사상이며, 기업이 요구하는 바다. 시장조사기관에서는 SOA 시장이 20% 이상 성장한다고 전망하고 있지만, 엄밀히 말해서 ‘SOA’라는 이름의 프로젝트는 없으므로 SOA를 단독시장으로 전망하는 것 자체가 무의미하다.

김영훈 한국오라클 상무는 “그동안 SOA는 상용화가 어렵다는 이유 때문에 ‘사망설’ ‘거품’ 등의 비판이 나왔다. 그러나 이제 SOA는 분명히 대세가 됐다. 모든 IT는 SOA가 기반이 되며, SOA를 지원하지 않는 애플리케이션이나 서비스는 시장에서 채택되지 못할 것”이라고 강조했다.

이상민 SAP코리아 부장은 “SOA 자체를 목적으로 접근하는 것은 위험하다. SOA는 수단으로 활용돼야 하며, 플랫폼·기술중심의 접근보다 프로세스 중심의 접근이 필요하다”며 “기존 IT 자산을 최대한 재활용해 비즈니스 가치를 높이고 민첩성 확보할 것인가를 고민해야 한다”고 조언했다.

저작권자 © 데이터넷 무단전재 및 재배포 금지