시스템ㆍ애플리케이션ㆍ데이터 통합 등 인프라 구축에 필요한 전사 관점의 아키텍처
차세대 데이터웨어하우스와 ETL(2)
SOA속에 숨어있는 데이터 통합(3)
인포메이션 허브와 마스터데이터관리(4)
메타 데이터 관리와 데이터 품질(5)
정인호
인포매티카코리아 기술본부 본부장
처음 상용화된 컴퓨터가 IBM으로부터 나온 이후 수십 년간 IBM의 전략은 '트렌드'였고 'IT 표준'이었다. 감히 어느 누구도 난공불락의 이 성을 넘볼 엄두도 못 내던 시절이었다. 70년대 말, 그때 당시 중소기업 수준이던 (IBM 입장에서 보면) 몇몇 회사가 모여 운영체제를 통일하자는 논의를 하게 되었고 상용 운영체제가 아닌 AT&T 연구소에서 개발된 유닉스가 표준으로 선정되어 모두가 통일된 운영체제를 이용하여 마케팅을 하기로 약속을 하게 되었다.
IT 트렌드 변화의 주역
그 당시 어느 누구도 거대한 공룡이 무너질 정도의 대단한 결정이라고 생각한 사람들은 없었다. 그 동안 IBM의 독주는 시스템적인 측면도 강한 부분이었으나 더 중요한 부분은 기업 내에서 필요한 모든 솔루션은 IBM에 의하여 개발 되었으며 IBM에 요청을 하면 필요로 하는 모든 것을 얻을 수 있다는 확신이 있었다.
합의를 이룬 후 몇 년의 기간 동안 커다란 변화는 없었지만 소프트웨어 분야에서 변화를 추구하기 시작하게 되었다. 그동안은 각각의 운영체계에 따라 다른 버전(포팅)을 만들어야 했으나 이후에는 유닉스에 기본이 되는 제품만 만들게 되면 모든 하드웨어 제품에 적용이 가능하기 때문에 새로운 소프트웨어 개발이 용이하게 되었고 많은 회사들이 이러한 대열에 참여하게 되었다.
그래픽, 데이터베이스, 통신, 프로그래밍 언어 및 각종 비즈니스 솔루션 등 다양한 형태의 소프트웨어가 개발되어 다양한 업무에 적용되기 시작하였다. 이러한 변화는 트렌드의 주역이 하드웨어에서 소프트웨어로 넘어가게 되는 계기가 되었다. 각각의 소프트웨어 회사는 하드웨어 회사보다 더욱 치열한 경쟁을 하게 되고 주도권을 확보하기 위한 싸움은 치열하게 펼쳐졌다.
IT 중심의 새로운 솔루션의 대부분이 소프트웨어 회사들 중심으로 개발되어 하드웨어 회사와 함께 IBM을 공략하게 된다. 클라이언트-서버, 다운사이징, 네트워크 분산 등의 솔루션은 IBM을 집중 공략하는 핵심 전략이었으며, 결국에는 거대한 공룡이 흔들릴 수 밖에 없는 환경까지 도달하게 되었다.
이후에도 소프트웨어 중심의 IT 트렌드의 개발은 계속되어 데이터 웨어하우스, ERP와 같은 전사적인 솔루션에서 각 산업별 솔루션에 이르기까지 산업내에서 필요한 솔루션들이 계속해서 발표되었다. 기존의 소프트웨어 기업의 역할은 기업에 필요한 기술을 제품화시켜 고객에게 전달하는 것이 대부분이었다. 이러다보니 산업의 미래를 위한 트렌드를 만드는데는 뚜렷한 한계를 보여줬다.
이러한 새로운 IT 트렌드를 만드는 주역으로 떠오른 곳은 컨설팅 회사였다. 컨설팅 회사를 중심으로 새로운 트렌드를 만들면 소프트웨어 업계에서는 새로 정의된 트렌드에 따라 제품을 개발해 제공하는 형태로 협력하게 되었다. 컨설팅 회사를 중심으로 마켓 플레이스, CRM, RTE, BPM, SOA 등 새로운 IT 기반의 트렌드를 만들고 IBM, 오라클, MS, CA 등의 기업에서 이러한 트렌드에 적합한 제품을 개발하게 되었다.
최근에 새로 나타난 트렌드의 특징은 과거 트렌드와 비교해 경계가 불분명해졌다는 것이다. 기존의 솔루션들은 IT 중심적으로 쉽고 명확하게 설명되었지만 새로운 트렌드는 비즈니스 중심인지 IT 중심인지에 대한 경계가 모호하며 실제적으로 어떠한 형태로 적용이 가능한지에 대한 실체가 없는 상태에서 트렌드가 만들어지게 된다.
RTE(real-time enterprise)나 BPM(business performance management) 같은 것은 IT 중심적이기 보다는 비즈니스 중심적인 솔루션이며, SOA도 IT 중심적인 요소보다는 비즈니스 중심적으로 표현되고 있는 것이 현실이다.
어떻게 생각해 보면 컨설팅 회사 입장에서는 IT 중심 보다는 비즈니스 중심으로 포장을 하는 것이 시장을 더욱 확대하며, 자신들의 입지를 확고히 할 수 있다는 점에서 좋은 방법이 될 수 있을 것이다. 그러나 IT 업계 종사자의 입장에서 보면 이는 매우 혼란스러운 대목이다. 새로운 트렌드에 대해 설명하면서 많은 기업이 자기 중심적으로 표현하고 자신들이 진짜 새로운 트렌드라고 주장하는 경우를 종종 볼 수 있다. 심지어는 기업의 이익에 따라 전혀 다른 형태로 표현해 더욱 혼란을 가중시키는 경우도 있다.
새로운 트렌드 SOA의 태동
이 시점에서 SOA(service oriented architecture)에 대해 다시 한번 조명해 보자. 이미 많은 서적이나 전문지 등에서 SOA를 주제로 광범위하게 다뤘으며, 관련 기업들은 다양한 형태의 컨셉과 솔루션을 내놓았다. 여기서는 간단하게 SOA를 정의하고 그 특징들을 살펴보기로 하자. 과거로 돌아가서 SOA 가 나타나게 된 동기를 먼저 알아보자.
▲ SOA 아키텍처
앞에서 지적한 것처럼 소프트웨어 업계는 새로운 IT 트렌드를 만드는데 한계를 안고 있으며, 그 역할은 컨설팅 회사가 수행하고 있다. 컨설팅 회사들은 새로운 비즈니스 트렌드를 지속적으로 만들어 내는데 최근에 RTE에 의한 BPM이라는 형태까지 발전하게 되었다. 이처럼 비즈니스에 필요한 IT의 요구 사항이 거의 모두 거론된 상황에서 새로운 돌파구가 필요하게 됐다.
그동안 등안시 했던 IT 분야로 다시 눈을 돌려 새로운 트렌드의 방향을 찾거나 엄청나 비용이 들어가는 IT의 현실을 들먹이며 비용 절감 차원의 솔루션을 모색하는 것은 바로 새로운 돌파구를 찾으려는 모습으로 볼 수 있다. 컨설팅 회사들은 이처럼 비용 절감의 솔루션을 강조하면서도 기업의 비전을 달성하기 위해서는 IT 투자는 계속되어져야 한다는 모순에 빠지기도 한다.
시스템은 갈수록 늘어나고 다양한 개발환경으로 인해 유지보수 비용도 증가하면서 통합의 필요성이 대두되고 있다. 이러한 문제점을 해결할 수 있는 최적의 방안으로 바로 SOA가 부각되고 있는 것이다.
SOA의 정의
SOA를 한 마디로 설명하면 "애플리케이션의 기반을 통합하는 가장 잘 만들어진 방법론"이다. 기존의 시스템 구축에 대해 분석해 보면 대부분이 업무 기능 중심의 개발 환경에서 타 시스템과의 통합에 관계없이 구축되었다. 예를 들어 회계 시스템은 ERP 패키지를 이용하여 구축했으며 영업 시스템은 클라이언트서버 환경에서 개발 툴의 언어로 만들었으며 고객 관련 시스템은 웹 환경에서 자바 언어로 개발했다.
이처럼 서로 다른 기술을 이용하여 만들어진 각 시스템에 어떠한 기능을 적용하기 위해서는 각 시스템 마다 별도로 구현 작업을 수행해야 한다. 예를 들면 고객 정보 조회와 같은 기능은 모든 시스템에 똑같이 필요한 기능이지만 각각의 시스템에서 각각의 언어를 이용하여 개발할 수 밖에 없다. 심지어는 각각의 시스템에서 각각의 고객 정보를 관리하게 되어 서로 일치하지 않는 고객 정보도 조회하는 일이 발생하기도 한다.
기존의 시스템은 비즈니스 중심의 개발 환경이므로 동일한 서비스도 비즈니스 영역에 따라 다르게 개발 되어야 하는 것이다. SOA는 이러한 부분을 통합하여 개발하기 위한 기반 환경으로 애플리케이션 로직들을 서비스 또는 구성요소화한 서비스 중심으로 접근하는 방법이라고 할 수 있다. 이러한 방법론은 한번 개발된 고객 정보 서비스를 모든 시스템에서 동일한 방법으로 접근하여 원하는 서비스를 제공 받을 수 있게 한다. 또한 고객 데이터 역시 하나의 시스템에서 관리하면 일치된 정보를 모든 시스템에서 공유할 수 있는 기능도 제공한다.
SOA가 확장되면 내부 서비스를 기업 내부 뿐만 아니라 외부 기업까지 통합할 수 있기 때문에 궁극적으로 협력사 뿐만 아니라 연계가 가능한 모든 시스템에서 서비스를 공유할 수 있는 기반을 구축하게 된다. SOA의 가장 큰 특징 중의 하나가 이기종 시스템간의 통합 요구에 가장 완벽한 환경을 제공하고 있다는 점이다. 정보 공유와 통합 환경을 제공하는 인프라는 기업적인 측면에서 보면 동일한 서비스를 한번의 개발로 여러 시스템에서 공유를 할 수 있다는 이점이 있다.
또 서비스의 통합이나 데이터의 통합 측면에서 비용 절감의 효과를 기대할 수 있으며, 새로운 시스템으로의 이전이나 업그레이드 시에도 적은 비용으로 빠른 시간내에 완벽하게 수행 할 수 있는 기반을 제공해 IT 트렌드의 변화에 적절하게 대응할 수 있다.
기업내 SOA의 기본 사상
SOA의 내용을 차분히 살펴보면 어디에선가 들어본 것 같은 내용을 확인할 수 있을 것이다. 사실 SOA는 아주 획기적으로 개발된 방법론은 아니고 이미 우리가 알고 있는 방법론을 확장된 개념으로 발전시킨 것이라고 할 수 있다. 대표적인 방법론이 자바 개발 방법론인 MVC(model view control)로 이는 객체지향적 측면에서 데이터 처리 부분과 화면에 보여지는 부분과 프로세스를 제어하는 부분을 분리하여 구성한다. SOA에서는 이러한 부분을 확장하여 기존 아키텍처의 장점을 살리고 이질적인 환경에서의 통합 요구 사항을 충족시킬 수 있도록 문제점을 보완한 진화된 방법론이라고 볼 수 있다.
▲ 데이터 서비스 컴포넌트
하나의 시스템 내에서는 MVC 방법론과 같이 분리하여 구축할 수 있겠지만 여러 시스템과의 통합적인 측면에서 보면 MVC 모델로는 한계가 있다. 만일 하나의 시스템을 구축하면서 해당 시스템과 통합이 필요한 모든 요소들을 예측해 개발하면 모든 시스템간의 통합은 문제가 되지 않을 것이다. 그러나 이는 현실적으로 실현 불가능한 가정이다. 그렇다면 이러한 문제를 해결할 수 있는 방법은 무엇일까? 그 대답은 바로 전사적인 측면에서 애플리케이션을 통합할 수 있는 인프라를 구축하는 것이며, 이의 가장 적합한 방법론이 SOA라는 것이다.
SOA에서의 현실적인 어려움
최근 새로 출시되고 있는 많은 소프트웨어들이 SOA를 표방하고 있다. 하지만 넓은 의미에서의 SOA 가운데 일부만 채택하고도 SOA를 적용한 제품이라고 주장하는 업체들이 적지 않다. 요즘 새로운 프로젝트의 제안요청서를 보면 SOA 기반으로 구축해야 한다는 요구사항이 들어 있는 경우가 종종 있다.
그러나 현 시점에서 이러한 SOA를 적용함으로써 애플리케이션의 통합이나 비용 절감이 현실적으로 가능한지 의문이 든다. 예를 들어 기업내의 모든 시스템을 재개발할 경우 전체적으로 SOA 기반으로 개발하면 당연히 SOA가 내세우는 모든 이점을 누릴 수 있을 것이다. 그러나 모든 시스템을 한번에 재개발하는 것은 쉬운 일이 아니다.
일반적으로 고객들은 새로 구축되는 시스템을 중심으로 SOA를 적용하려고 한다. SOA 적용 방안을 고객 부분을 중심으로 분석해 보자. 이미 기업 내에는 많은 시스템이 존재하고 있으며 각 시스템별로 고객이 따로 구성되어 있다. 새로운 시스템을 개발할 때 이러한 고객에 대한 문제를 SOA 측면에서 어떻게 처리해야 할 것인가?
새로 개발되는 시스템에서는 SOA를 충실히 따르기 위하여 고객 정보 데이터나 서비스를 개발하지 않고 기존의 시스템에서 고객 정보를 가져오고 싶어한다. 하지만 이미 구축되어 있는 기존의 시스템은 당연히 SOA 구조를 따르지 않았기 때문에 신 시스템에 고객 정보를 제공하는데는 어려움이 있다.
어쩔 수 없이 신 시스템에서도 고객 정보를 관리하기 위한 데이터베이스가 존재하게 될 것이고 그러한 고객 정보를 제공할 서비스를 개발해야 할 것이다. 또한 이 고객 정보를 다른 시스템으로부터 제공받아야 한다면 데이터 통합을 위한 서비스, 즉 소스 시스템에서 데이터를 제공해 주는 서비스와 소스 시스템으로부터 고객 정보를 제공받기 위한 서비스를 개발해야 할 것이다.
여기까지만 본다면 SOA를 적용할 때 누릴 수 있는 최대 이점인 애플리케이션 통합의 효과를 찾아보기 힘들다. 또한 점차적으로 모든 시스템을 SOA 기반으로 변경하게 되면 결과적으로 SOA의 혜택을 보겠지만 그 시기가 언제일지는 누구도 장담할 수 없을 것이다. 물론 전혀 이점이 없다고는 할 수 없다. 가장 큰 이점을 꼽는다면 향후 모든 시스템의 통합을 위한 표준을 마련했다는 점을 들 수 있을 것이다.
SOA 적용을 위한 준비
현재 기업들의 환경을 살펴보자. 이미 우리는 다양한 시스템에서 동일한 정보를 관리하고 있는 것을 알고 있다. 고객 정보, 제품 정보, 직원 정보 등 일반 정보와 각종 기초 정보에 대하여 영업 시스템, 회계 시스템, 물류 시스템, EIS, DW 등 다양한 시스템에서 보관하고 관리 및 서비스를 수행하고 있다.
기업 내에서 표준화된 인터페이스를 구축하고 표준화된 서비스를 제공하려면 당연히 관련된 데이터도 표준화되어야 하며 일치화되어야 한다. 그러나 이렇게 다양한 시스템에 분산되어 있는 정보를 이용하여 표준화된 데이터를 관리하는 일 또한 쉽지 않다. 만일 공통적으로 사용되는 데이터만이라도 통합된 환경으로 관리되고 있다면 모든 시스템에서 필요로 하는 기본 정보 서비스의 표준화된 인터페이스를 구축할 수 있을 것이다. 그리고 이것을 기반으로 신시스템부터라도 SOA를 적용하는 것이 좀 더 용이할 것이다.
최근 들어 많은 기업에서 인포메이션 허브나 마스터데이터관리(MDM : master data management)와 같은 형태의 프로젝트를 수행하여 기업 내에서 관리되는 데이터 중 공통적으로 사용되는 정보를 통합된 환경에서 관리할 수 있는 환경을 갖추고 있다. - 인포메이션 허브나 마스터데이터관리는 다음 호에서 상세히 거론할 계획이다. 이러한 시스템들이 미리 구축되어 있고 이 시스템 구축 역시 SOA 기반으로 구축된다면 향후 모든 시스템에서 데이터의 이중 관리가 사라질 것이며, 이 시스템에서 개발된 서비스를 이용하는 모든 시스템에서 새로운 서비스 구축없이 자유롭게 데이터와 서비스를 활용할 수 있을 것이다.
▲ SOA 기반의 기업통합 아키텍처
SOA 적용을 위한 준비
재미있는 사실은 SOA에 대한 이론을 장황하게 늘어놓고, 또 SOA가 적용된 소프트웨어를 출시하는 대부분의 업체들이 전사적인 측면에서 애플리케이션의 통합만을 거론할 뿐 데이터의 통합에 대해서는 거의 말하고 있지 않는다는 점이다.
예를 들어 SOA의 대표적인 프로세스인 BPM의 영업에서 출하까지의 프로세스를 분석해 보자. 외부 거래처로부터 주문이 발생하면 영업 시스템에 데이터가 발생하고, 재고관리 시스템에서 재고가 생기면 단순히 재고를 감소하고 출하 시스템으로 데이터를 넘긴게 된다. 재고가 부족하면 생산계획 시스템으로 생산을 의뢰하게 되며, 경우에 따라서는 자재관리 시스템으로 자재 구매 요청이 발생할 수도 있다.
이러한 데이터는 흐르고 흘러 회계 시스템이나 데이터웨어하우스를 거쳐 EIS까지 넘어가게 된다. 문제는 이 모든 시스템이 전부 SOA 기반으로 구축되었다면 모든 시스템을 SOA로 통일된 인터페이스에서 서비스의 통합이 가능하겠지만 현실적인 어려움이 있다.
만일 SOA가 적용되지 않는 시스템은 무시하고, 신시스템 만으로 SOA를 구성해 다른 시스템과의 데이터 통합을 기존의 방식대로 구축한다면 어떠한 의미에서는 영원히 SOA를 적용하기 어려운 환경에 처할지도 모른다.
그렇다면 이를 해결할 수 있는 방안은 무엇일까? 새로운 시스템의 비즈니스와 관련된 부분은 SOA를 기반으로 구축하며, 이미 SOA 기반으로 구축되어 있는 시스템이 존재하면 당연히 연계되는 부분도 통합된 SOA 기반으로 구축하면 된다.
그리고 SOA가 적용되지 않는 시스템과의 연계는 기존 시스템의 데이터베이스와 신시스템의 데이터베이스 간의 통합 방식으로 구축하고, 향후 기존 시스템도 SOA 환경으로 재구축할 경우 이 시스템과 SOA 기반의 서비스 통합이 가능하다.
BPM 및 BAM과 데이터 통합
특히 최근 들어 SOA 기반에서 구축되는 중요한 솔루션으로 BPM과 BAM(business activity monitoring)이 주목을 받고 있다. 이 두 가지 경우는 데이터 통합의 필요성에 따라 부각된 솔루션으로 볼 수 있다. BPM은 기존에 존재하고 있는 시스템을 기반으로 시스템 중심의 흐름에서 비즈니스 프로세스 중심의 흐름으로 재구성하여 필요에 따라 각각의 시스템을 호출하게 된다. 사용자는 시스템의 구성에 관계없이 자신의 업무 흐름에 맞게 업무를 수행하고, BPM 프로세스가 정보를 각각의 시스템으로 전달하는 역할을 수행하게 된다.
그러나 위의 사례에서 보면 이미 모든 시스템에서 각각의 고객 정보를 관리하고 있는 상태에서 새로운 고객이 등록되는 경우 BPM 프로세스는 모든 시스템의 고객 정보를 등록하는 작업을 수행해야 한다. 다양한 시스템이 구성되어 있는 경우 이 프로세스는 하나의 고객을 등록하기 위하여 수 십초의 시간이 걸릴 수도 있다. 또한 각각의 시스템간의 연계 작업을 완료하기 위하여 대부분의 프로세스는 하나 이상의 시스템에서 수행되어야 하며, 연계되는 시스템의 문제로 인해 기존의 작업까지 실패로 처리될 수도 있다.
이러한 모든 부분을 애플리케이션 단위에서 수행하고 완료하기 위해서 BPM 프로세스는 복잡하게 구성되어야 하며, 본질적인 작업 외에도 많은 작업을 수행해야 한다. 만일 사용자 서비스 측면과 데이터 통합을 분리하면 좀더 간단한 형태의 BPM 프로세스를 구성할 수 있다.
▲ 실시간 통합-PowerExchange
BPM 프로세스의 경우, 하나의 시스템에서 서비스를 호출하여 데이터를 제공하고, 저장만으로 자신의 프로세스를 완료하면 속도나 안정성 측면에서 사용자의 만족도는 높아지게 된다. 해당 시스템과 다른 시스템과의 데이터 통합의 경우 실시간으로 데이터베이스 측면에서 타깃 데이터베이스로 변경된 데이터의 통합을 수행하면 다양한 측면에서 좋은 효과를 볼 수 있다.
또한 변경 데이터를 처리하는 방식이 데이터베이스를 매번 검색하여 작업을 수행하는 부담을 최소화하여 데이터베이스의 로그를 통해 변경 데이터를 취득하여 개발된 애플리케이션이 아닌 데이터 통합 툴을 이용해 자동으로 목표 시스템의 데이터베이스까지 데이터가 이관되어 거의 실시간으로 데이터의 통합을 수행하면 최적의 방안이라고 볼 수 있을 것이다.
또한 BAM의 환경에서도 데이터베이스 로그를 통한 실시간 데이터 통합은 아주 중요한 역할을 수행한다. 이미 과거에 많은 기업에서 대쉬보드나 상황판 형태로 현 시점의 매출 현황, 고객 클레임 현황, 생산 현황들을 표시하고 있다. 그러나 이 시스템은 운용계 시스템에 불필요하게 많은 부하를 주고 있다.
시간 단위마다 다양한 운용계 시스템의 데이터베이스를 검색하여 필요한 정보를 BAM 시스템으로 제공하기 위해 다량의 검색 작업을 수행하기 때문이다. 경우에 따라서는 락(Lock)의 경합으로 인해 운용계 업무에 지장을 초래하는 경우도 발생한다.
▲ 고객 데이터 통합
BAM 시스템에 필요한 데이터 제공을 위해 필요할 때마다 운용계 데이터베이스를 검색하는 것이 아니라 운용계 데이터베이스에서 BAM 시스템에서 필요한 정보가 변경(입력/ 수정/ 삭제) 될때 데이터베이스에 생성되는 로그 정보를 이용해 실시간으로 BAM 시스템에 정보가 제공되면 운용계 시스템에서는 BAM 시스템 데이터 제공을 위한 부하를 최소화할 수 있다. 그리고 BAM 시스템에서는 기존 시스템 보다 짧은 간격으로 현재 기업 내에 운용되는 정보를 경영진에게 제공할 수 있다.
SOA의 혜택
기존의 아키텍처의 경우 MVC, CBD- 개별적인 시스템의 구축에 필요한 요구 사항을 충족시키기 위한 것이라면 SOA는 단일 시스템, 시스템간의 통합, 애플리케이션 간의 통합, 데이터간의 통합 등 인프라를 구축하기 위한 좀 더 전사적인 관점에서의 아키텍처라고 할 수 있다. SOA의 중심이 되는 부분은 단일 시스템에서 보다는 다양한 이기종 시스템에서 애플리케이션 단위의 통합 측면에서 고려해야 한다는 점이다.
개발자들은 애플리케이션을 연결하는 새로운 코드를 작성하기 위해 과도한 시간을 낭비할 필요가 없으며, 대신 표준 인프라를 이용할 수 있다. 또한 잘 구축된 SOA 코드는 상당 부분 재사용이 가능하기 때문에 개발 비용도 줄어든다. 공유 및 재사용이 가능하기 때문에 새로운 기능 추가 또는 통합이 용이하다는 것 역시 장점으로 꼽을 수 있다.
다시 한번 강조하지만 SOA는 단순히 도입만으로 바로 커다란 효과를 볼 수 있는 애플리케이션이 아닌 인프라 관점으로의 접근이 필요하다. 기업 내에 존재하는 IT 전반에 대한 충분한 고려가 선행되고, SOA에 대한 충분한 이해가 있어야 하며, 전략적인 차원에도 차근차근 진행할 때 성공할 수 있다는 사실을 반드시 명심해야 한다.