▲ 정인호 인포매티카코리아 기술본부 본부장

데이터 통합의 범위와 역할(1)
차세대 데이터웨어하우스와 ETL(2)
SOA속에 숨어있는 데이터 통합(3)
인포메이션 허브와 마스터데이터관리(4)
메타 데이터 관리와 데이터품질(5)

정인호
인포매티카코리아 기술본부 본부장 

몇 년 전까지만 해도 ERP, SCM, CRM, SEM 등 애플리케이션 중심의 솔루션이 IT의 트렌드의 주류를 이뤘지만 최근에는 기존의 시스템을 유지하면서 다양한 사용자의 요구사항을 만족시킬 수 있는 방안이 중요한 화두로 자리잡고 있다. EP(enterprise portal), BPM(business process management), BAM(business activity monitoring), SOA(service oriented architecture) 등의 기본 사상이 현재 사용중인 시스템을 최대한 활용해 새로운 변화에 적응하기 위한 솔루션이란 점은 이러한 트렌드를 잘 보여주고 있다.

이러한 솔루션들이 정확한 역할을 수행하기 위해 필요한 사항이 있다. 바로 데이터 통합이 그것이다. 기존 시스템간의 데이터 통합이 이루어져야만 모든 업무가 유기적으로 흐를 수가 있기 때문이다. 기업 내에서도 이제 서서히 데이터 통합에 대한 인식이 높아지고 있으며, 그 대응 방안을 준비 중이다. 이번 호부터 5회에 걸쳐 데이터 통합에 관련된 전반적인 환경 및 구현 방안 등을 살펴보고 기업 내에서 어떻게 적용 할 것인지를 살펴보겠다.

데이터 통합의 범위와 역할
모든 사람들이 알고 있는 이야기가 있다. 호수 위에 우아하게 떠있는 백조가 그러한 자태를 유지하기 위해서는 물 밑에서 쉬지 않고 다리가 움직여야 한다는 이야기다. 유유자적하게 떠있는 백조, 모든 사람들이 보기에는 평화롭고 아름답고 여유스러움을 느끼게 하지만 보이지 않는 곳에서는 쉬지 못하는 다리가 있다.

물의 흐름이 안정적인 곳에서는 천천히 힘들이지 않고 다리를 저어 자태를 유지하겠지만 갑작스런 물살의 변화가 생기면 현재의 상태를 유지하기 위하여 더욱 빠르고 힘들게 다리를 움직여야만 할 것이다. 이렇게 백조의 다리는 쉼 없이 움직이기도 하지만 다양한 변화에도 적응을 해야 하는 어려움이 있다.

우리의 이야기로 다시 돌아오자. BI(business intelligence)의 화면에 전일의 매출이 지역별로 상품별로 분석되어 누구나 편하게 볼 수 있게 만들어 사용자가 편리하고 정확하게 업무에 적용 할 수 있도록 하기 위해서는 어디에선가 밤새워 모든 관련되는 운용계 시스템에서 필요한 데이터를 모아서 BI의 화면에 표현하기 위한 작업을 수행한다.

업무계가 마감이 된 이후부터 BI 마트에 데이터가 모이기까지는 작게는 수십 개의 프로세스에서 많게는 수백 개의 프로세스가 순차적으로 한치의 오류도 없이 완벽하게 작업이 이뤄져야 한다. 전체 프로세스 중 어느 하나라도 문제가 생기면 다음날 아침에는 IT 부서의 전화가 불이 나게 될 것이다. 모든 사람들이 필요한 정보를 제공하기 위해서는 운용계 시스템도 완벽하게 작업되어야 하지만 운영계의 데이터가 필요로 하는 모든 시스템에 완벽하게 통합되어야 정보계나 기타 데이터 웨어하우스가 정확한 성능을 발휘하게 된다.

이러한 작업을 수행하기 위하여 밤새워 작업을 진행해 전혀 문제가 없을 때는 ‘너무 당연한 일’이지만 문제가 발생해 업무의 수행이 원활하지 못할 경우 모든 비난을 한 몸에 받는 조직이 IT 부서의 데이터 통합 관련 담당자이다.

새벽에 운전을 하다 보면 어두운 새벽부터 빗자루를 들고 묵묵히 길거리를 쓸고 있는 누군가가 있다. 언제나 무심히 지나가지만 그 누군가가 없다면 매일매일 넘쳐나는 지저분함에 숨막히는 출근길이 될 것이다. 눈에 띄지는 않지만 누군가가 해야만 하는 일 그리고 누군가가 하지 않으면 아무것도 할 수 없는 일이기에 반드시 해야만 하는 것이 데이터 통합 관련 업무라는 얘기다.

데이터 통합의 정의
과거 메인프레임 시절, 모든 업무는 하나의 시스템, 하나의 데이터베이스에 통합적으로 구성되어 이미 데이터의 통합이 이루어진 시스템 구축 형태였다. 그러나 개방 시스템이 도입되면서 하나의 시스템에서 하던 업무를 여러 개의 시스템으로 분산하여 업무를 개발하고, 새로운 업무가 추가될 때 마다 새로운 시스템을 도입하여 설치하게 되었다.

그런데 문제가 생겼다. 새로 도입되는 시스템은 다른 시스템으로부터 데이터 수신이 필요했으며, 마찬가지로 기존 시스템도 새로운 시스템에게 데이터의 요청이 필요했다. 이러한 일이 처음에는 단순히 필요한 정보를 한두 시스템간에 자료를 교환하는 형태로 이루어 졌다. 또한 이러한 대부분의 업무는 일 마감, 주, 월 마감이 완료된 이후에 간간히 발생하는 업무로 이루어져 있었다. 이것이 데이터 통합의 초기 구성이라고 볼 수 있다.

다운사이징에 힘입어 확산된 개방 시스템은 기업에서 새로운 업무가 발생할 때마다, 새로운 트렌드에 따른 시스템 구축 붐이 일어날 때마다 하나씩 하나씩 늘어났다. 금융기관이나 대형 제조업체의 경우 많으면 100여개의 유닉스 서버가 도입되어 운용되고 있는 것이 현실이다.

문제는 이 100여개의 시스템 중 어느 하나도 독자적으로 작업되는 시스템은 없다는 것이다. 이 명제는 모든 시스템간에 어떠한 형태로든 데이터의 통합이 있어야만 해당 시스템의 역할을 수행할 수 있게 됐다는 것이다. 최근까지 가장 많이 구축된 데이터웨어하우스나 BI의 경우, 자체에서 순순하게 생성하는 정보는 없이 현재 구성되어 있는 다양한 시스템에서 필요한 데이터를 받아서 사용자에게 필요한 정보로 가공하는 시스템이다. 이 때문에 데이터 통합은 필수적인 요소이며, 이러한 데이터 통합 없이는 아무것도 할 수 없는 시대가 됐다.

데이터 통합은 한마디로 말하면 하나의 소스 시스템에서 관리하는 데이터를 목표 시스템의 데이터와 실시간이나 배치 형태로 의미를 일치시키는 역할이라고 볼 수 있다. 여기서 ‘의미’라는 것은 단순히 동일한 데이터의 형태로 일치시키는 것이 아니라 변형의 단계를 거쳐 합산이나 여러 함수 등을 통해 같은 의미를 가진 정보로의 변화를 말한다.

	▲ <그림1> 데이터 통합의 분류

데이터 통합의 분류
통합을 의미의 일치라는 형태로 간단하게 설명 할 수는 있으나 방법적인 측면에서 분류해보면 매우 다양한 형태의 데이터 통합의 유형을 볼 수 있다. 다양한 데이터 통합의 유형은 역시 과거에도 수행되었던 작업이고, 앞으로도 비중이 높아질 것다. 이번 호에서는 ETL, RTDI, 데이터 동기화(data synchronization), 데이터 이주(data migration), 메타 데이터 관리(metadata management), 데이터 정보 허브(data information hub)/데이터 통합 허브(data integration hub) 등 6가지 데이터 통합 유형의 현실과 문제점을 알아보고, 앞으로 어떠한 형태로 발전을 해야 할 것인지를 제시하겠다.

ETL (extract transportation loading) 
현재 기업들의 환경을 살펴보정보계 시스템이 탄생을 하면서 필요한 데이터를 운영계 시스템으로부터 이관해 오는 작업이 발생하게 되었다. 본격적인 ETL 작업의 시작은 데이터 웨어하우스(DW) 시스템이 도입되면서 처음에는 ETT(extract transformation transportation)이라는 형태로 방법론이 개발되었고, 절차적인 측면에서 작업이 수행되었다. 일반적으로 ETL을 수행하는 방안으로는 보통 4개의 단계로 나누어 진다.

	▲ <그림2> 일반적인 ETL 수행절차

1단계는 운영계 시스템에 완료된 데이터를 운영계의 데이터 형태와 동일하게 ETL 서버 또는 DW 서버로의 형세(stage) 영역을 이동하는 작업이다. 2단계는 형세 영역에서 이번 기간 동안 작업될 데이터를 뽑아내어 데이터웨어하우스에 저장하기 위한 형태로 변경 작업을 수행하여 운영데이터저장소(ODS;operational data store)에 저장한다. 3단계는 운영데이터저장소에 저장된 정보를 이용하여 데이터웨어하우스로 적재하는 작업을 수행하고 마지막으로 4단계에서는 데이터웨어하우스에 저장되어 있는 정보를 이용하여 업무 관점별로 구성되어 있는 데이터 마트(DM;Data Mart)로 이관해 실제적인 온라인분석프로세싱(OLAP;on-line analitycal processing) 툴에서 사용할 수 있는 정보로 저장하는 작업을 수행한다.

전통적으로 이제까지는 이 모든 작업을 툴에 의하여 작업하기 보다는 개발에 의하여 진행하는 것이 일반적인 방법이었다. 다양한 형태의 서버의 구성과 다양한 유형의 데이터베이스 구조로 이뤄져 있는 기업의 환경을 모두 지원하기 위한 솔루션의 개발이 어려운 상태였기 때문이다. 여기에다 내부 프로세스 역시 기업의 환경, 사용자의 요구 사항, 데이터웨어하우스 모델링 구조 등 복잡한 구성도 툴을 적용하기보다는 직접 개발하는 것이 편리하고 쉽다는 인식을 낳은 요인이다.

그러나 우리의 바람과는 다르게 운용계 시스템도 계속적인 변화를 거듭하게 되고, 신시스템의 구축으로 새롭게 재개발해야 하는 경우도 발생하게 되었다. 사용자의 요구 사항은 계속 증가하여 데이터웨어하우스 내에 존재하지 않는 데이터는 다시 운용계에서부터 ETL 작업을 새로 진행하여야 했다. 문제는 이러한 작업을 하기 위하여 현재 구성되어 있는 부분을 정확히 이해하고, 분석을 통하여 수정 보완을 해야하는데 대부분의 시스템에서는 이러한 작업과 관련된 현재 시점의 보고서나 자료가 존재하지 않는다는 점이다. 또한 프로그램이나 데이터가 증가되어 ETL의 수행 시간이 현저히 증가하는 현상을 초래하는 것도 문제점 중의 하나이다.

이러한 문제의 해결 방안으로 근본적인 조치를 취하기 보다는 대부분 저장한 데이터에서 필요없는 데이터를 제거하거나 데이터베이스의 인덱스의 재생성 등 부분적인 작업으로 대처하는 모습을 보였다. 이러한 대처 방안은 시간이 지나면 다시 동일한 문제점이 발생하는 현상을 낳았다.

최근 들어 ETL 작업의 추이는 이러한 기존의 문제점을 최소화하고, ETL 수행 속도의 보장이나 유지 관리 측면에서 중요한 기능인 모니터링 등을 위해 툴을 사용하는 것이 일반적인 구성으로 변하고 있다. 운영계 시스템에서 데이터를 이관하기 위하여 Unload, FTP, Load의 작업에서 벗어나 툴을 통하여 모든 운용계의 데이터베이스와 직접적인 연계를 유지하여 마치 자신의 데이터베이스 테이블과 동일하게 인식하고 작업할 수 있도록 한다.

이 작업의 중요한 점은 ETL의 4단계 중 1단계 작업 자체를 제거하고 바로 2단계부터 작업을 수행할 수 있는 기능을 제공한다는 것이다. 또한 분할(分割) 기능이나 병렬(竝列) 기능을 이용하여 네트워크가 허용하는 한 가장 빠른 시간 내에 데이터를 이관할 수 있는 기능을 제공한다. 변환 작업도 비주얼한 형태의 작업으로 유지 보수 및 변경 시 직관적으로 이해하여 작업을 수행하거나 오브젝트 간의 연관 관계를 유지하여 하나의 오브젝트가 변경되었을 때 어디까지 영향을 미치는 지의 연관에 관한 분석도 이뤄진다.

마지막으로 현재 작업되고 있는 모든 현재 시점의 프로세스의 모니터링을 통하여 작업의 상태를 항시 확인할 수 있을 뿐만 아니라 오류 발생 시 로그 관리 기능 등을 통하여 빠르고 정확한 분석을 수행해 즉각적인 대처가 가능하도록 한다. 이러한 기능들이 제공되는 툴을 이용하여 작업을 수행하면 수작업이나 담당자의 능력에 의하여 좌우되던 많은 일들이 적은 노력으로도 쉽게 개선이 가능할 것이다.

실시간 데이터 통합(Real Time Data Integration)
몇 년전 가트너에서 내놓은 실시간 기업(RTE;real time enterprise)이라는 개념은 현재에도 IT 전반의 중요한 화두로 자리잡고 있다. 가트너가 말하는 RTE는 “핵심 비즈니스 프로세스의 관리 및 이행의 지연을 점진적으로 줄이기 위해 최신 정보를 사용하여 경쟁하는 기업”이라는 아주 커다란 의미를 내포하고 있다.

	▲ <그림3> RTDI (Real Time Data Integration)

가트너는 또 “실시간 기업은 성공과 직결된 명시적 사건이 발생하는 즉시 그 근본 원인과 사건 자체를 파악, 모니터링, 분석함으로써 새로운 기회를 발굴하고 불행한 사태를 미연에 방지하며 핵심 비즈니스 프로세스의 지연을 최소화한다. 그리고 실시간 기업은 그렇게 확보한 정보를 활용하여 핵심 비즈니스 프로세스의 관리 및 이행 지연을 점진적으로 줄여나감으로써 핵심적인 경쟁력 확보의 기반을 마련한다.”고 RTE에 대해 설명한다.

실시간 기업(RTE)의 파생적인 부분으로 BPM(business process management), BAM(business activity monitoring), SOA 등 새로운 개념이 창출됐다. 이 또한 의미적인 측면에서 보면 실시간으로 업무를 처리하기 위한 실체적인 부분이라고 볼 수 있다. 그러나 과거의 개념과는 많은 차이가 있다. 과거의 개념들은 현재의 시스템을 무시하고 새로운 형태의 프로세스와 새로운 시스템의 구축을 통해 성공할 수 있다고 주장하였으나 지금 만들어지는 개념들은 현재의 시스템을 최대한 활용하며, 그것도 좀더 비즈니스적으로 접근하는 개념으로 변하고 있는 것이다. 많은 IT 기업에서는 새로운 트렌드에 맞추어 BPR, BAM, SOA 등 다양한 새로운 솔루션을 적용한 제품들을 출시하고 있다.

잠시만 다시 개념으로 돌아가 보자. RTE는 모든 기업의 프로세스가 실시간으로 움직여 의사결정까지 실시간으로 처리 할 수 있도록 하자는 의미이다. 그렇게 하려면 기업내의 모든 시스템이 실시간으로 처리가 되어야 한다. 예를 들어 영업에서 계약이 이루어지면 영업시스템에 계약과 관련된 정보가 입력되는 즉시 재고 관리 시스템에서 실시간으로 재고 현황 파악을 수행하여 즉시 출고가 가능한지를 확인하여 실시간으로 영업으로 정보를 제공해야 하고, 재고가 없는 경우는 생산 시스템으로 데이터가 전달되어 생산에서는 자동으로 생산 스케줄에 포함이 되고 조달 관리 시스템에서 관련된 부품을 발주하기 위한 프로세스가 실시간으로 처리 되어야 한다.

물류관리 및 창고관리 시스템에서 실시간으로 출고 일정에 따라 배송을 하기 위한 다양한 작업을 수행 해야 한다. 마지막으로 모든 관련되는 정보는 실시간 데이터웨어하우스(DW)나 실시간 비즈니스 통합(BI)을 통하여 임원진이나 경영진에게 모든 상황의 파악이 가능하도록 정보가 제공되어야 한다. 이 시나리오는 단순히 하나의 프로세스에 불과할 뿐이며 좀더 다양하고 복잡한 프로세스는 기업 내에서 더 많이 존재할 수 있다.

이같은 사례를 보면 이미 대부분의 기업 내에는 영업 시스템에서부터 BI까지 구축되어 있는데 왜 아직까지 실시간 업무 처리가 되지 않는 것인가? 여기서 가장 핵심이 되는 것은 모든 데이터가 실시간으로 처리되어 모든 시스템으로 막힘없이 흘러가야 프로세스도 실시간으로 처리가 될 수 있다는 것이다. 물론 몇몇 기업에서는 이러한 실시간 데이터 처리를 위하여 많은 시도를 하였으며, 여기서 사용되는 중요한 솔루션이 EAI 툴과 데이터베이스에서 제공하는 2단계완료(2Phase Commit) 등이었다.

이처럼 시도한 기업도 있고, 솔루션도 존재하는데 발전하지 못한 이유는 무엇일까? 투입되는 비용 대비 이익이 크지 않기 때문이다. 기존의 업무에서 EAI를 도입하기 위해서는 현재 수행되고 있는 중요한 프로그램의 수정이 필요한데. 이러한 수정 작업은 기존의 프로그램의 수행 속도에 영향을 끼칠 수 있는 소지를 내포하고 있다. 데이터베이스 트리거를 이용한 2단계완료(2Phase Commit)도 유사한 문제점을 가지고 있다. 또한 시스템 자체의 문제보다도 타 시스템과의 연계 부분의 오류 등으로 인하여 본연의 업무 수행에 지장을 초래하는 경우가 발생하기도 한다.

이러한 문제점을 보완하여 개선하기 위해서는 시스템의 증설, 네트워크의 증설도 보강해야 하는데 이 역시 비용로 직결된다. 그러나 이익적인 측면에서 보면 꼭 이 연계가 실시간으로 처리해야만 하는 것인가에 대한 의문을 제기하게 되고, 실시간 처리가 되지 않더라도 현재의 업무를 처리하는데는 큰 지장을 초래하지 않는다는 판단에 따라 몇몇의 꼭 필요한 업무를 제외하고는 사실상 EAI나 2단계완료(2Phase Commit)를 적용하는 경우는 별로 없었다. 문제는 위에서 열거한 개념을 적용하기 위해서는 실시간 데이터 통합은 필수적인데 기존의 솔루션으로는 이익보다는 높은 위험성과 많은 비용이 소요 된다는 점이다.

최근 들어 많이 사용하고 있는 실시간데이터통합(RTDI;real time data integration)솔루션은 변경데이터집적(CDC;change data capture) 기능을 이용한 통합 방안이다. 모든 데이터베이스는 Insert/ Update/ Delete의 작업이 완료(Commit)되면 작업된 내역을 데이터베이스에도 변경을 하지만 필수적으로 로그 정보를 남기게 된다. 변경 데이터 집적(CDC)은 이러한 로그 정보를 이용하여 변경 내용을 확인하고 그 정보를 필요한 곳에 넘겨 주는 기능이다.

예를 들어 영업 계약 정보를 입력하면 관련되는 테이블에 Insert가 수행되고 동일한 정보가 동시에 로그에 기록된다. 변경데이터집적(CDC)은 계속적으로 로그를 감시하고 있다가 완료(Commit) 정보가 로그에 등록되는 즉시 로그에 등록된 정보를 이용하여 어느 테이블에 어느 정보가 변경되었는지를 확인하여 이 정보가 필요한 곳으로 넘겨 주게 된다.

우선 변경데이터집적(CDC) 기능의 문제점을 확인해 보면 실제적으로 실시간으로 처리하지는 못한다는 것이다. 원시 테이블에 완료(Commit) 되고 로그 작업이 완료된 이후에 처리가 가능하므로 완벽한 실시간이라고는 할 수 없다. 그러나 다시 확인해 보면 매우 많은 장점을 보유하고 있는 솔루션이다.

첫째 완벽한 실시간 처리는 아니지만 거의 실시간(Near Real Time)으로 변경 정보에 대한 데이터 통합 작업이 가능하다. 둘째로는 데이터베이스에서 완료(Commit)된 정보만을 이용하여 변경 정보에 대한 데이터 통합 작업을 수행하게 되므로 완벽한 통합이 가능하다. 셋째로 단지 로그 정보 만을 이용하여 변경 정보 통합을 수행하게 되므로 데이터베이스의 부하 및 시스템의 부하를 최소화 할 수 있다. 넷째로는 개발된 프로그램의 수정이나 변경이 필요 없이 모든 시스템간의 데이터 통합이 가능하고, 다섯째로는 기존 업무에 영향을 주지 않고 작업이 가능하다는 것이다.

종합적으로 보면 실시간으로 데이터 통합을 처리하기 위해서는 변경데이터집적(CDC) 기능을 이용하면 기존의 업무에 영향을 주지 않는 상태에서 프로그램의 수정이나 보완없이, 또 시스템이나 기타 장치에 대한 커다란 투자없이 모든 시스템간의 실시간 데이터 통합이 가능하다는 것이다. 물론 은행 계정계와 같이 완벽한 실시간 처리를 필요로 하는 시스템에는 적용할 수 없는 솔루션이라는 단점이 있지만 그런 완벽한 실시간을 필요로 하지 않는 대부분의 업무에서는 전혀 느끼지 못하는 형태에서 데이터 통합이 가능하다.

데이터 동기화와 데이터통합허브

	▲ <그림4> 데이타 동기화 형태

이제까지 데이터의 동기화는 데이터 통합의 측면에서 보기 보다는 개발 시스템간의 필요한 정보를 주고 받는 형태에서 진행을 하였으며, 소스 시스템에서는 단지 목표(target) 시스템에서 필요한 정보를 제공할 뿐이었다. 목표 시스템의 입장에서는 소스 시스템에서 제공된 정보를 이용한다는 단편적인 형태의 데이터 송수신 이상의 의미를 부여하지는 않았다. 데이터 동기화의 완전성이나 일치성에 대하여 소스 시스템과 목표 시스템간에 서로 미루고 자신의 일이 아니라는 부분만 강조하던 상황이었다.

당연히 소스와 목표간의 데이터가 완벽한 일치성을 갖지 못했고 서로간에 일치하지 못한 부분에 대하여 당연시하는 부분도 존재하였다. 필요에 따라서는 월 마감이라는 개념을 도입하여 매월 한번에 전체적인 데이터 일치성을 위한 작업을 수행하는 경우도 발생하였다. 또한 사용자 측면에서도 정확한 데이터의 보장 보다도 전반적인 형태에서 유사한 정보를 포함하고 있다면 인정을 하고 넘어가는 경우가 많이 있었다.

이러한 부분은 IT 측면에서 데이터의 동기화는 나의 일이 아니라는 현상을 낳았으며, 사용자 측면에서는 정확하지 않을 것이라는 신뢰의 상실을 발생시키는 요인이 되었다. 소스 시스템 담당자의 측면에서 보면 데이터를 요구하는 시스템이 점점 늘어나는 것은 큰 부담으로 자리잡게 되고, 제공하는 데이터가 많아 질수록 신경질적인 반응을 보이게 된다. 새로운 목표 시스템을 개발하는 측면에서는 소스 시스템의 데이터 없이 존재하기 어려운 시스템이므로 어쩔 수 없이 계속적인 요구를 할 수 밖에 없는 상태로 진행된다.

결국 소스 시스템 관리자 측면에서 보면 동일한 정보를 한번이 아니라 2중, 3중의 형태로 각각의 시스템에 제공을 해야할 뿐만 아니라 새로운 시스템이 증가할 때마다 또 다시 한번 더 제공해야 한다는 것은 문제이다. 그렇지만 어쩔 수 없이 동일한 작업을 반복하고 있는 상태이다. 소스 시스템 담당자는 한번만 데이터를 제공하면 누군가가 타 시스템으로 제공했으면 하지만 어느 누구도 자신의 일이라고 생각하지 않고, 자신이 필요한 정보만을 요청한다.

목표 시스템을 구축하거나 개발하는 입장에서도 기업 내에 이미 구축된 데이터웨어하우스 시스템에서 데이터를 제공받는 방안도 있으나 시점이 늦다거나 일부 필요한 데이터가 데이터웨어하우스에 존재하지 않는다는 등의 이유로 인하여 데이터웨어하우스 시스템에서 제공받기 보다는 소스 시스템으로부터 직접 데이터를 받기를 원한다. 근본적인 해결 방안이 없이는 문제는 계속해서 진행될 수 밖에 없는 구조를 안고 있는 것이다.

새로운 개념으로 도입되는 것이 데이터통합허브(DIH;data integration hub)이다. 이 개념은 데이터정보허브(data informatica hub)와 유사한 의미를 갖고 있지만 구성 요소적인 측면에서 보면 전혀 다른 개념이다. 데이터정보허브의 경우는 자체적으로 데이터베이스를 구축하여 여러 소스 시스템으로부터 데이터를 제공받아 자신이 데이터를 보관하고 있다가 데이터를 필요로 하는 시스템으로 데이터를 제공하는 시스템의 역할을 수행한다. 데이터통합허브도 데이터를 제공받아 데이터를 제공하는 형태를 취하지만 데이터를 보관하지 않는 시스템으로 설계된다.

데이터통합허브(data integration hub)는 단지 데이터를 분기시켜주는 역할을 하는 시스템으로 볼 수 있다. 기업 내에서 모든 시스템의 중앙에 위치하여 모든 데이터의 흐름을 관장하게 되고 정합성과 적시성을 보장하는 시스템으로 데이터 통합의 중추적인 역할을 수행한다.

데이터통합허브(data integration hub)가 정확하게 구성되는 경우 소스 데이터를 관리하는 모든 시스템은 필요로 하는 정보를 단지 데이터통합허브 시스템으로 지정된 주기에 따라 단 1회만 제공하면 데이터통합허브가  제공받은 정보를 이용하여 필요로 하는 모든 시스템에 적절한 주기에 따라 자료를 제공한다. 목표 시스템 입장에서도 다양한 시스템에 대하여 다양한 형태로 접속을 해야 하는 어려움에서 데이터통합허브 시스템 하나에만 접속하면 필요한 모든 정보를 제공받을 수 있다.

특히 새로운 시스템을  구축할 때 다른 시스템으로부터 데이터를 받아야할 경우 데이터통합허브와의 협의를  통해 필요한 정보의 구성만 확정하면 소스 시스템의 변경이나 개발없이 대부분의 정보를 제공받을 수 있다. 논리적으로 보면 이러한 역할을 EAI가 수행 하고 있었지만 EAI의 한계점 - 단순 트랜잭션 중심, 많은 개발 비용, 소스 시스템의 변경 - 등으로 인하여 다양한 형태에서 제공하기 어려웠다. 이러한 부분은 데이터 통합 툴이 데이터통합허브의 역할을 수행하여 스케줄에 의하여 소스 시스템에서 데이터를 조회해 각각의 목표 시스템으로 데이터를 제공하는 역할을 수행한다. 변경 데이터 집적 기능을 이용하는 경우 거의 실시간 형태로 모든 데이터간의 통합 작업을 수행할 수 있다.

마이그레이션(Data Migration)

얼마 전까지 대형 기업을 중심으로 ERP나 CRM 등의 시스템 구축이 주류를 이루어왔다. 최근에는 금융계를 중심으로 차세대 시스템이나 리-호스팅 (re-hosting) 프로젝트를 다수  수행하고 있다. 대부분의 프로젝트는 사용자 애플리케이션에 가장 중점을 두고 계획을 세우고, 사용자 애플리케이션 개발에 많은 이력과 비용을 투입한다. 반면에 데이터 마이그레이션 분야는 관심에서 멀어져 있는 경우를 볼 수 있다. 누구나 당연히 해야 한다는 생각은 갖고 있지만 우선 순위에서 밀려 인력이나 예산 확보 면에서 어려움을 겪고 있다. 데이터 이주의 유형을 보면 크게 2가지 방식으로 나누어진다.

	▲ <그림5> 데이터 마이그레이션 수행 절차

첫째는 하드웨어의 구성만 바뀌고 소프트웨어와 데이터는 그대로 사용하는 방안인 리-호스팅을 위한 데이터 이주이다. 예를 들면 IBM 메인프레임을 사용하던 기업에서 개방 시스템을 도입하여 구조만 바꾸고 모든 데이터와 애플리케이션을 그대로 사용하는 방법으로 리스크를 최소화하는 방안으로 많이 선택되고 있다. 이 경우 소스 데이터베이스와 목표 데이터베이스가 거의 1대1의 상황으로 단순히 소스의 데이터를 목표 시스템으로 넘기기만 하면 된다고 생각하지만 여기에도 복병이 숨어 있다.

첫째는 IBM의 경우 EBCDIC 코드를 사용하고 있고, 개방 시스템의 경우 ASCII 코드를 사용하고 있으므로 우선 코드 전환(code conversion) 작업이 선행되어야 하는 어려움이 있다. 두 번째로는 사용되는 코드가 틀린 부분은 한글에도 같이 적용이 되므로 한글 코드도 변경을 해야 하는데 한글의 경우 소스 데이터에 문제를 갖고 있는 상태에서 전환 역시 더 큰 어려움으로 대두된다. 실제로 IBM의 한글 데이터를 전환해 보면 종종 한글이 깨진 현상이 발생을 하는데 소스에서 한글이 정확한 SOSI - 한글 on, 한글 off - 작업이 이루어지지 않은 경우가 대부분이다. 문제를 이해하면 해결할 방법을 찾기가 쉬운데 불규칙적으로 데이터가 깨지거나 이러한 데이터를 찾기 위해 일일이 데이터를 검색하여 확인해야 하는 어려움이 발생 할 수도 있다.

세번째는 과거 데이터 - 10년 이상 지난 데이터 - 의 경우 어디에서도 데이터의 구조를 설명하는 자료를 찾기가 어렵다는 것이다. 데이터 이주의 두번째 방법은 차세대 시스템과 같이 과거 시스템의 구조와는 상관없이 새로운 비즈니스 구조에 맞추어 새로운 데이터베이스를 구축하고 새로운 애플리케이션을 개발하는 것이다. 현재 사용 중인 시스템을 완벽하게 이해하고 새로운 시스템의 데이터베이스 구조도 정확하게 이해한 후 서로간의 함수(mapping)를 만들어 데이터를 넘기는 작업을 수행해야 한다. 결코 쉽지 않은 작업이라는 것을 알 수 있다. 여기에다 현재 사용중인 시스템이 IBM 메인프레임인 경우는 더욱 작업이 심각해 진다.

첫 번째 현재 사용중인 시스템을 이해하기 위한 어떠한 문서도 찾기가 어렵다는 것이다. 물론 모든 기업이 다 그렇다고는 것은 아니다. 그러나 대부분의 기업에서는 프로젝트가 완료된 이후에 발생하는 변경이나 추가에 대하여 실제적으로 사용할 수 있는 문서를 만들어 관리하고 보관하는 곳을 찾기는 쉽지 않다. 결국 현행 시스템의 ER-Diagram을 그리는 것부터 프로젝트를 시작하는 경우가 많다.

두 번째, 어렵게 현행 시스템의 구조를 이행했다고 해도 다시 남은 숙제는 신시스템에 대한 이해를 다시 해야 한다는 점이다. 물론 업무를 이해하고 있어 빠르게 진행할 수는 있으나 새로 설계되는 시스템은 새로운 비즈니스를 중심으로 설계되므로 현 시스템을 알고 있는 사람은 오히려 더 이해를 못하는 경우도 발생한다. 가끔은 마이그레이션 팀에서 신시스템의 문제점을 찾아 주기도 한다.

세 번째, 현행과 신시스템간의 함수를 만들어야 하는데 1대1의 함수는 아주 쉽지만 거의 찾아 볼 수 없는 구조이다. 많은 부분이 1대N의 구조를 보이거나 N대1의 구조를 나타내는 경우도 종종 있다. 가장 큰 문제는 N대N의 구조로 여러 개의 소스의 데이터를 모아서 여러 개의 목표로 보내야 하는데 이런 경우 설계하거나 구현하는 작업에 많은 어려움이 따른다.

그래도 이주를 해야 한다. 이주가 완료되지 않은 상태에서는 신시스템이 아무리 잘 구축되었다고 하더라도 절대 시스템을 사용할 수 없다. 그러다 보면 시스템 구축 기간의 후반부로 넘어 오면서부터 데이터 이주가 가장 큰 일로 자리잡게 된다. 과연 주어진 시간 - 예를 들면 48시간, 72시간 - 동안에 완벽하게 이주를 완료할 수 있는가? 이주된 데이터의 완전성은 보장 받을 수 있는가? 각각의 단계별 문제 발생 시 해결 대책은 강구 하고 있는가? 프로젝트가 막바지에 이르면서 프로젝트 담당자 왈 “이 프로젝트의 성패는 데이터 이주에 있다”는 이야기까지 하게 된다.

만일 주어진 시간 동안에 데이터 이주를 완료하지 못했거나 또는 완료를 했지만 데이터의 완성도가 떨어져 사용하기 어렵다고 판단되는 경우, 모든 비난은 데이터 이주 팀으로 몰리게 되고 다음 일정이 수행될 때까지 작업의 어려움과 함께 정신적 스트레스도 받아야 한다. 이 어려움은 과거에도 있어 왔고 현재에도 계속되고 있다. 그럼 앞으로도 계속되어야 할 것인가?

여기서 한가지 방안을 제시해 보기로 하자. 과거에 몇몇의 사례에서 - 데이터베이스 업그레이드, 하드 디스크 업그레이드 - 사용을 하기는 했지만 많은 준비를 해야 하고 완벽하지 않으면 현행 시스템과 시스템 모두에서 문제가 발생할 소지가 있는 작업이다. 그렇지만 개발의 형태가 아닌 시스템 차원에서 지원을 한다면 좀더 안정적으로 데이터 이주를 수행할 수 있다.

또 다른 몇몇 사례에서는 사용자가 현행 시스템과 신시스템에 두 번의 입력을 수행하는 경우도 비일비재하게 발생했다. 기존의 데이터 이주 방식은 현 시스템이 OFF된 시점에서부터 모든 데이터를 옮기기 시작해서 주어진 시간 동안 모든 데이터를 넘겨야 하는 시간 제약이 있는 업무이다. 이 시간 제약을 분산해 보자는 방안이다.

시간 간격을 두고 업무 별로 데이터 이주를 수행하고 이후에 발생하는 변경 정보는 실시간 데이터 통합(RTDI)에서 설명한 변경 데이터 집적(CDC) 기능을 이용하여 신시스템의 데이터와 동기화를 수행하게 된다. 이러한 방안을 순차적으로 수행하면 이주 작업을 수행하기 전에 모든 데이터의 이주를 완료할 수 있다. 또한 미리 미리 체크를 통한 완전성 확보로 데이터의 무결성도 보장할 수 있다.

예를 들어 보자. 현 시스템은 상당히 많은 업무를 포함하고 있다. 인사, 회계, 영업, 물류 등을 포함하고 있는 경우 한 주에 한 업무씩 이관을 하는 것이다. 이번 주말에는 인사 시스템 데이터를 이주한다. 이주가 끝나게 되면 그 이후부터 변경되는 정보는 변경데이터집적(CDC) 기능을 통하여 현 시스템의 변경 데이터를 신시스템으로 트랜단위로 작업을 수행한다.

누구도 모르고 있지만 현 시스템의 데이터를 변경할 때 마다 신시스템의 데이터도 자동으로 변경된다. 개발자들은 그동안 데이터의 검증이나 프로그램의 검증 작업을 수행하게 된다. 다음 주에는 다른 업무, 그 다음 주에는 또 다른 업무….. 이러한 형태로 작업이 수행되는 경우 최종적으로 전체적인 이주 작업을 수행하기도 전에 모든 데이터에 대한 이주 작업이 완료될 수 있는 환경을 만들 수 있다.

메타 데이터 관리
모든 기업의 IT 부서에 상존하고 있는 문제이지만 어느 누구도 해결하기 어려운 분야가 있다. 바로 메타 데이터다. 메타 데이터에 대한 정의를 간단하게 해보자. 메타데이터는 데이터를 구성하고 있는 구성(Object)들에 대한 정보라고 볼 수 있다. 데이터베이스, 테이블, 뷰, 인덱스, 각종 오브젝트, 컬럼 명, 컬럼 타입, 계산식, Relationship, 데이터의 논리적 정의, 변경 이력 등 수많은 정보들을 메타 데이터라고 부른다.

이들 대부분의 정보는 프로젝트 단위의 작업을 수행하고, 완료 보고서에 포함된다. 이들 정보는 완벽하지는 않다고 해도 최악의 경우 이들 정보의 보고서가 없다고 해도 업무를 수행하거나 시스템을 관리하는데는 전혀 문제가 되지 않을 수 있다. 이러한 이유 때문에 관리가 소홀하거나 전혀 관리되지 않는 상황을 초래하기도 한다.

문제는 이후에 발생한다. 유지 보수를 위한 변경 작업이나 새로운 업무를 추가하는 작업을 수행하는데 커다란 문제에 봉착하는 것이다. 데이터 이주의 경우에 볼 수 있듯 이러한 메타 데이터 정보를 정확하게 관리하고 있다면 현 시스템을 분석하고 함수를 만드는데 시간을 소비할 필요가 없다. 모든 테이블의 데이터가 각각의 논리적(logical)적인 의미에서 어떠한 의미를 갖고 있고 어떠한 역할을 수행하고 있으며, 이 데이터는 어디까지 영향을 미치는지를 알기 위해 우리는 처음부터 새로 분석 작업을 수행해야 한다.

이러한 모든 상황을 정확하게 이해하고 있지 않은 상태에서 테이블이나 프로세스의 수정은 우리가 상상하지 못하는 시스템적 오류를 발생시킬 수 있다. 예를 들어 영업 마트에서 새로운 정보를 필요로 하는데 데이터웨어하우스에 존재하지 않는 정보일 경우, 운영계 시스템부터 데이터를 가지고 와야 하는 작업이 필요하다. 담당자는 여러 테이블과 ETL 프로세스를 분석하게 되고 작업의 최소화를 통해  현행 프로세스를 수정하고자 할 것이다.

그러나 이렇게 수정된 프로세스는 본인의 의도와는 상관없이 다른 프로세스나 마트에 치명적인 영향을 끼쳐 다음날 화면에서 데이터가 사라지거나 전혀 의미없는 자료가 나타날 수 있다. 담당자가 다시 이전의 상태로 복구를 하는 것은 자명한 일이다. 자신의 작업을 완료하기 위해서 새로운 프로세스를 만들어 운영계 시스템에서부터 데이터 웨어하우스에 이르기까지 전체적인 새로운 작업이 증가하게 된다. 시간이 흐르게 됨에 따라 ETL 작업을 수행하기 위하여 운영계의 하나의 테이블을 매일 4~5차례 읽어야 하는 중복이 발생하고, 결국은 업무 시작 시간까지 ETL 작업이 완료되지 못하는 경우가 발생하는 것이다.

언뜻 보면 데이터 통합과 메타 데이터 관리와는 별로 의미없이 보일 수도 있지만 완벽한 데이터 통합을 위해서는 기업 전반의 메타 데이터가 관리가 되어야 한다. 그래야만 데이터 통합의 완성도도 높아진다. 이러한 의미에서 최근의 데이터 통합 프로젝트에서 메타 데이터 관리 프로젝트를 같이 수행하기도 하고, 데이터 통합 툴 역시 메타 데이터 통합을 위한 저장소(repository) 관리를 직ㆍ간접적으로 포함하고 있다.

현행의 테이블의 내역을 변경하지는 못하더라도 현재 존재하고 있는 컬럼 중 amt1, amt2, amt3의 의미를 모르던 상태에서 논리적으로 각각의 의미를 정확하게 정의하고, 모든 IT 부서 인력이 이해하고 있다면 현재 업무의 개선이라는 효과는 없을 수도 있다. 하지만 앞으로 변화되는 모든 환경에서 최소 비용으로 최대 효과를 볼 수 있는 가장 근본적인 장치를 구축하는 것이 메타 데이터 관리이다.

데이터정보허브
어느 날 은행에서 연락이 온다. 나의 정보를 확인하기 위하여 여러 가지를 물어보고 확인을 한다. 그러데 나의 직장 정보는 3년전의 상태였다. 그래서 변경된 정보를 알려주었는데 며칠 후 콜센터에서 연락이 왔을때 아직도 내 직장정보가 변경되지 않는 것에 놀랐다. 과연 한 은행에 나의 정보가 몇가지 형태로 분리되어 운영되고 있는지가 궁금했다.

최근 들어 많은 기업에서 시스템 구축의 기본 사상을 상품 중심에서 고객 중심으로 변경하여 설계하고 구축하는 경우를 자주 볼 수 있다. 그렇다고 기존의 시스템에 존재하고 있는 고객까지 포함해 구축하는 경우는 드물다. 이러한 문제를 해결하는 방안으로 나온 개념들이 고객정보허브(CIH;customer information hub), 마스터데이터관리(MDM;master data management) 등이며, 이러한 프로젝트가 최근 점차 늘어나고 있다. 두 개념의 중요한 요소는 기업내에서 중요하게 여기는 정보를 하나의 시스템에 통합하고, 필요에 따라 각각의 시스템에서 검색해 사용하는 방안을 제시한다는 점이다.

기본적으로 자체 시스템에서 관리하는 고객은 현 상태를 유지하는 상태에서 여러 시스템에 분산되어 있는 고객의 형태를 하나의 통합된 형태로 구성하고, 실시간으로 개별 시스템과 고객정보허브(CIH) 시스템과의 데이터 통합으로 고객 정보에 대한 정합성을 유지할 수 있도록 구축한다. 이렇게 구축된 시스템의 활용 방안으로 -특히 금융기관의 경우 - 새로운 상품을 개발하여 판매하고자 하는 경우 해당 금융기관과 거래하는 모든 고객을 대상으로 마케팅을 추진하거나 상품 판매와 연계했을 때 좀더 효과적으로 활용이 가능하다. 모든 시스템에서 동일한 상태의 고객 조회를 수행해 고객에게 좀더 근접한 서비스를 제공할 수 있는 기반이 되는 셈이다.

고객정보허브(CIH)는 고객을 중심으로 통합을 추진하는 방안을 제시하는 시스템인 반면 마스터데이터관리(MDM)는 기업 내에 존재하는 중요한 -대부분의 시스템에서 필요로하는 -정보에 대하여 통합 관리를 할 수 있도록 구성하는 부문이다. MDM에 포함할 수 있는 정보는 고객, 상품, 조직, 영업현황, 회계현황, 물류 등이다.

고객정보허브(CIH)나 마스터데이터관리(MDM)를 구성하기 위해서는 기존에 데이터를 발생시키는 운용계 시스템의 변화가 필요하지만 이는 매우 어려운 프로젝트이다. 개별 운영계 시스템과 CIH와의 데이터를 일치시키기 위한 방법은 1일 1회 처리를 기준으로 야간 시간에 작업하는 것이 가장 보편적이다. 그렇지 않은 경우 실시간으로 처리하기 위하여 EAI 등의 툴을 이용해 처리를 하지만 많은 비용과 노력이 필요하다. CIH 프로젝트에서 데이터 통합 방법보다는 통합 프로세스의 정의가 오히려 더욱 어려운 부문이다.

모든 상품에 대하여 다양한 형태의 고객 정보를 구성해야 하는데 어떠한 형태로 통합을 할 것인지가 모델링의 핵심이다. 또한 데이터 품질의 우선 순위 또한 중요한 부분이다. 고객과의 접점에 의한 주소 정보와 콜센터에서 접수한 주소정보, 메일 수신에 의한 주소 정보, 고객이 웹에서 입력한 주소 정보가 일치하지 않을 경우 어떠한 주소를 사용할 것인지의 우선 순위 결정이 실제적인 데이터의 품질과 직결되는 사항이다.

이러한 비즈니스 모델이 확정된 이후에 모델에 따른 가장 적절한 솔루션을 찾아서 적용하는 것이 성공적인 프로젝트의 토대가 된다. 여기서 우려할 사항은 잘못 설계를 하면 데이터웨어하우스의 모델과 유사한 형태로 구성될 수도 있다는 것이다. 데이터웨어하우스는 기업내의 모든 정보를 모아 놓은 장소이기 때문에 고객정보허브(CIH)나 마스터데이터관리(MDM)에 구성되는 정보 역시 데이터 웨어하우스와 유사한 형태로 이뤄질 수도 있다.

그러다 보면 유사한 모델을 만들 수도 있고, IT적인 측면에서 보면 동일한 정보를 2중 3중으로 관리하는 형태를 빚을 수 있다. 분명히 고객정보허브와 데이터웨어하우스는 목적이 다른 시스템이다. 그러므로 목적에 맞도록 설계하는 것이 중요하며, 또 목적에 맞도록 활용하는 방향 또한 절대 무시할 수 없는 요소라는 점을 명심해야할 것이다.

맺음말
데이터 통합의 기존 현황과 향후 발전 방향을 살펴봤다. 과거에는 데이터 통합을 위한 전문 제품이 부재했으며, 있더라도 일부 기능만을 제공한 탓에 어쩔 수 없이 수작업 방식으로 프로젝트를 진행할 수 밖에 없었다. 하지만 언제까지 이러한 형태로 프로젝트를 진행 할 수는 없는 노릇이다. 새로운 기술을 접목시켜 좀더 적은 비용으로 빨리 개발할 수 있는 방안을 모색해야 할 것이다. 앞으로 4회에 걸쳐 현재 쟁점이 되고 있는 내용들을 세부적으로 살펴볼 것이다. 특히 각각의 쟁점과 어제와 오늘을 분석하고 미래를 조명해 효과적인 적용 방안을 모색하고자 한다.