전용 시스템이 아닌 고객도 활용할 수 있는 시스템, 실시간 데이터 처리 필요
차세대 데이터웨어하우스와 ETL(2)
SOA속에 숨어있는 데이터 통합(3)
인포메이션 허브와 마스터데이터관리(4)
메타 데이터 관리와 데이터 품질(5)
정인호
인포매티카코리아 기술본부 본부장
어린 시절 - 아마도 70년대 초 - 동네 아저씨들이 학교에 와서 축구 시합을 하면서 쉬는 시간에 코카콜라 한 병을 따서 한 모금 마시는 장면을 보며 너무나도 부러워하던 자신을 기억한다. 누구나 음료수 하면 코카콜라를 떠 올렸고 가장 쉽게 갈증을 풀어주던 대표적인 음료였다. 당시 유일한 경쟁자로 펩시가 있었으나 코카콜라와는 비교도 되지 않는 시장 점유율과 선호도를 보였다. 하지만 30년이 지난 지금 고객의 선호도가 탄산음료에서 천연음료로 변화하면서 이 두 업체의 위상도 바뀌었다.
탄산음료를 고집한 코카콜라와 달리 펩시는 천연음료로 발빠른 변신을 시도해 코카콜라의 매출액을 능가하는 회사로 발돋음한 것이다. 누구나 자신이 갖고 있는 주력 상품을 포기하고 새로운 상품에 계속적인 도전을 하는 일은 쉬운 것이 아니다. 그러나 그러한 도전이 없이는 또한 최고로 올라가기 어렵다는 것도 당연하다고 볼 수 있다.
그럼 펩시는 왜 천연음료로 변화를 하게 되었을까? 그건 한마디로 고객의 요구를 제대로 분석한 결과라고 볼 수 있다. 건강을 중요하게 여기는 요즘 탄산음료의 한계와 이의 대안으로 천연음료의 시장성을 정확하게 분석한 것이다.
초기 데이터웨어하우스
90년대 중반 데이터웨어하우스(DW) 프로젝트를 하기 위하여 팀원들을 데리고 고객사에 투입된 적이 있었다. 유통업체의 데이터베이스 마케팅 프로젝트를 수행하기 위하여 본인을 포함한 4명의 인원이 투입됐다. 고맙게도 고객 TFT에서는 수 개월 전부터 팀을 구성하여 분석 방법 등에 대한 작업을 수행하고 있었고 팀이 투입되었을 때는 이미 100여개 이상의 화면을 그려 놓고 기다리고 있었다.
이 그려진 화면을 파워빌더와 같은 프로그램으로 개발을 한다면 훨씬 더 많은 인력이, 더 많은 기간 동안 개발을 해야만 하는 상황이었다. 고객 입장에서도 모두 다 완벽하게 개발해 주기를 원했다기 보다는 가능한 한 많은 양의 요청사항을 만들어 놓고 최대한의 효과를 얻고자 하였다. 필자 역시 모든 애플리케이션을 직접 개발해야 한다면 처음부터 포기했을지도 모른다. 그렇지만 여러 가지 부문에서 획기적인 기술인 온라인분석프로세싱(OLAP) 툴을 이용한 개발 방법에 힘입어 추진하게 되었다.
100개의 화면은 단 20개의 화면으로 축소하여 사용자가 생각한 것 이상의 효과와 편리성을 제공했으며, 다차원 모델링은 다양한 형태의 분석에서 탁월한 적용력을 보이는 방법론이었다. 고객이 요구하던 화면의 개발은 최소의 인원으로 개발되었다. 하지만 데이터를 컨버전하는 부분과 데이터의 정합성을 맞추는 부분에 많은 시간을 쏟아부어야 했다. 완성된 프로젝트는 사용자들이 상상하던 이상의 결과를 낳았으며, 관련 업계의 주요 관심사로 떠올랐다.
엑셀이라는 스프레드시트 제품은 우리가 필요로 하는 거의 모든 기능을 포함하고 있으나 합계를 내거나 일반적인 표 형태를 표현하기 위하여 사용하는 것이 거의 대부분이다. 그러나 기획 부서나 회계 부서 직원들의 엑셀 사용하는 형태를 보면 프로그램 개발자도 놀랄 정도로 그 활용도가 높은 경우가 종종 있다.
기본 화면에 필요한 데이터를 넣으면 자동으로 다양한 계산을 해서 담당자가 필요로하는 결과를 다른 쉬트에 그래프까지 포함하여 표시하는 작업을 진행한다. 그러나 이 담당자도 역시 고민이 있다. 수많은 양의 데이터를 모두 입력할 수도 없으며, IT부서를 통하여 수집된 데이터도 그 양이 과다해 PC에서는 제대로 수행되지 못하는 경우가 단적인 예이다. 가끔은 모든 작업의 수행 결과를 보기 위하여 밤새워 지켜 봐야 하는 경우도 있다.
이러한 담당자에게 데이터웨어하우스는 꿈의 시스템으로 자리를 잡게 되었다. 이제까지 몇 시간이 걸렸던 작업을 마우스 클릭 하나 만으로 단 몇 분만에 마치고, 몇 번의 재작업도 하루에 모두 완료할 수 있기 때문이다. 그러나 사용자는 새로운 요구 사항 - 많은 경우는 이제까지 해보고 싶어도 엄두가 나지 않아서 해보지 못했던 분석 - 을 지속적으로 요청하게 된다. 만일 이러한 요구 사항이 개발 프로젝트 팀이 상주하고 있는 시기에 나오면 어렵기는 하겠지만 그래도 수용하는 경우가 많으나 개발 인력이 철수한 이후에는 무척이나 고민이 되는 작업이다.
사용자는 새로운 OLAP 툴에 대하여 학습해야되고 학습의 양 이상으로 성장을 하게 된다. 많은 사용자는 교육한 내용대로 작업을 하지만 몇몇 사용자는 개발자가 생각하지도 못한 방법을 사용해 시스템에 엄청난 부하를 주는 작업을 생성하기도 한다. 사용자의 성장은 운용 인력의 마음과는 상관없이 계속 진화하게 되고 필요한 자료가 발생할 때 마다 계속적인 요구 사항으로 IT 담당자를 압박하게 된다.
▲ 실시간 데이터 통합
처음 잘못 낀 단추
일반적인 기업에서 프로젝트를 할 때 처음부터 모든 작업을 외부 직원과 같이 수행하기는 어렵다. 많은 데이터웨어하우스 프로젝트에서 사용자나 IT 부서에서는 현재의 시스템에 대한 설명이나 요구 사항의 분석에 많은 도움을 주지만 설계가 시작되면 한 발짝 물러서고, 많은 작업은 외부 인력들이 수행하는 것이 일반적이다. 모든 작업 내역은 프로젝트 완료 보고서에 포함되어 결과물로 남게 된다.
외부 인력은 철수를 하고 이제부터 모든 일은 IT 부서 직원들이 담당하게 된다. 프로젝트에 참여한 인력이 유지보수를 하면 다행이지만 전혀 관련이 없는 인력이 유지보수를 담당하는 경우도 있다. 이 업무를 담당하는 직원은 처음에는 단순히 매일매일 돌아가는 작업만 정상적이면 별 문제가 없겠구나 하는 생각으로 편하게 업무를 시작하지만 본인이 모든 업무를 이해하기도 전에 사용자들로부터 새로운 요청 사항이 발생하게 된다.
예를 들어 화면에 표시되는 정보 중 하나를 더 추가해 달라는 요청이 있다고 가정해 보자. 담당자는 당연히 화면과 관련되는 테이블을 찾아보게 될 것이다. 필요로하는 데이터가 테이블에 존재하고 있다면 다행이겠지만 그렇지 못한 경우 문제가 발생하게 된다.
담당자는 테이블간의 연결 고리를 찾아 며칠을 고생하다가 원시 데이터 테이블까지 도달하게 된다. 그때부터는 다시 모든 연관되는 작업에 하나의 컬럼을 추가하는 작업을 수행하게 되고 며칠의 테스트를 거쳐 화면에 새로운 데이터가 추가되는 결과를 보여준다.
그러나 현실은 그렇지 못하다. 몇 주간의 분석과 프로그램 수정과정, 테스트 과정을 거쳐 완벽하다고 생각되어 실 업무에 적용하지만 ETL(extract transportation loading) 작업의 결과는 참담하게도 해당 화면만의 문제가 아니라 관련되는 모든 화면에서 이상 현상이 생긴다. 바로 이 대목에서 그 담당자는 앞으로 중요한 부분은 "다시는 수정하지 않는다" 라고 결심을 하게 된다.
이때부터 소스의 데이터를 읽는 부분부터 필요로 하는 모든 작업에 대하여 새로운 테이블을 생성하고 새로운 프로세스를 만드는 일을 하게 된다. 그리고 그 담당자는 어떠한 작업 내용도 남기지 않고 계속적인 새로운 요구사항에 대한 추가 생성 작업을 진행한다. 경우에 따라서는 일반적인 ETL 절차마저 무시한 채 소스 시스템 테이블에서 바로 마트의 테이블로 데이터를 전송하기도 한다. 몇 년에 걸친 이러한 작업이 새로운 담당자로 넘어가는 순간 이제부터는 그 어느 누구도 해결할 수 없는 '블랙 박스'의 형태로 남게 된다.
호미로 막을 것 가래로 막는 격
새로운 요구 사항을 반영하기 위한 프로세스와 테이블의 추가는 처음에는 시스템에 커다란 부하로 작용되지는 않는다. 하지만 이러한 작업이 점점 늘어나면서 새벽 3~4시에 완료되던 ETL(데이터 추출, 변환, 적재) 작업이 1~2년이 지난 후에는 7시가 지나도 끝나지 않는 경우가 비일비재 하다.
IT 부서에서는 이 문제를 해결하기 위하여 많은 비용을 들여 시스템 진단 작업을 수행한다. 그러나 전문가가 수행한 시스템 진단 작업도 내부 프로세스까지 일일이 점검을 하기는 불가능하여 단순히 전체적인 운용 상태만을 진단하고, 대부분의 결과는 시스템의 자원(resource)이 부족하다는 결과를 내놓는다.
이러한 진단 결과에 따라 CPU를 추가하게 되고 메모리를 증설하게 된다. 이처럼 비용을 투자한 만큼 그 효과는 바로 나타난다. 시스템의 증설이 완료되면 바로 다음날부터 ETL 작업은 1~2 시간 정도가 줄어들게 된다. 그러나 이러한 기쁨도 잠시, 근본적인 해결 방안을 제시하지 못한 작업은 몇 번의 추가 요구 사항이 반영되고 3~4개월의 시간이 흐른 후에는 역시 똑같은 고민에 빠진다.
이제 담당자가 할 수 있는 일은 매주 주말마다 과거 데이터를 제거하거나 인덱스를 재수립하는 것이다. 더 이상의 요구 사항을 받아들이지 않는 것은 물론이다. 이는 문제를 근본적으로 해결할 수 없는 상황에 이르렀다는 점을 보여주는 대목이다. 혹자들은 "사업의 시작 시기를 잡을 때보다 사업의 접을 시기를 결정할 때가 더 어렵다" 라고 얘기한다. 이는 데이터웨어하우스(DW) 프로젝트를 접자는 이야기가 아니다. 현재 안고 있는 상황을 이 시점에서 마무리하고 새로운 차원의 시스템으로 넘어가자는 것이다. 이제부터 이 시스템을 '차세대 데이터웨어하우스'라고 하기로 하자.
이 차세대 데이터웨어하우스의 추진을 위해서는 IT 부서 및 경영진의 의사 결정을 비롯해 많은 인력과 비용 등이 필수적이다. 더욱 중요한 것은 타당성이다. 기업의 투자 대비 효과 측면에서 얼마의 비용이 투입 되는냐 보다는 그 비용을 투입했을 때 얼마의 효과를 볼 수 있느냐가 더욱 중요하다는 것이다.
차세대 DW를 구축하고자 어느 기업의 전산 기획 담당자가 "지금 ETL 수행 속도에 문제가 있다"는 점을 이유로 들고 그 효과로 "빠른 ETL 작업으로 신속하게 결과를 볼 수 있을 것"이라고 제안하면 어느 의사 결정권자도 투자 결정을 내리리가 쉽지 않을 것이다. 그러면 경영진이나 의사 결정권이 있는 임원들에게 차세대 DW는 꼭 필요한 시스템이라는 점을 인식시키려면 어떠한 기능 및 효과를 제시해야 할까?
▲ 병렬/멀티-쓰레드 프로세싱
차세대 DW, 무엇이 다른가
사용자 입장에서 가장 필요하지만 가장 어려운 부분은 바로 실시간 데이터 처리를 통한 실시간 데이터웨어하우스 분야이다. 그동안 데이터웨어하우스는 과거의 데이터를 이용하여 상황을 분석하여 미래를 예측하거나 앞으로 생길 문제에 대한 대처, 그리고 의사 결정의 기초 자료로 활용하는데 중점을 두었다.
그러나 최근 들어 경영진의 생각은 현재의 상황을 알 수 있어야 의사 결정을 할 수 있지, 이미 지난 이야기를 가지고 무슨 의사 결정을 할 수 있느냐고 말한다. 우리는 가끔 주말에 아내와 쇼핑을 하곤 한다. 늦은 저녁때 할인점이나 백화점에서 쇼핑을 하다 보면 방송으로 "고객님들의 쇼핑의 편의를 위하여 영업 시간을 30분 연장하도록 하겠습니다. 즐거운 쇼핑이 되십시오" 라는 메시지를 듣게 된다. 이는 실제로 고객을 위한 연장 영업이 아니라 실시간으로 영업 현황을 분석하여 하루의 매출 목표에 도달하기 어렵다고 판단되는 경우 점장이 매출 향상을 위해 내리는 즉각적인 의사 결정이라고 볼 수 있다.
과거 유통 업무를 관리하는 시스템에서는 10분이나 30분 단위로 매출의 현황을 집계하고, 이렇게 집계된 데이터를 일별, 월별로 분석하는 작업을 수행했다. 그리고 앞으로 남은 시간 동안 목표로 세운 매출을 달성할 수 있는지에 대한 예측을 하고, 예측된 내용을 기반으로 경영층(점주, 점장) 입장에서 즉각적인 의사 결정을 내릴 수 있도록 했다. 이러한 시스템을 BAM(business activity monitoring)이라고 한다. 현재 현장에서 발생하고 있는 정보를 모아서 실시간으로 집계하고 분석하여 즉각적인 의사 결정을 할 수 있도록 도와주는 이 시스템은 관리 또는 경영진에게 적합하다.
모 기업의 경영층 사무실에 가보면 커다란 LCD 판에 현재의 생산량, 라인의 상태 등이 실시간으로 표시되고 있다. 경영층의 실시간 정보에 대한 욕구는 강하지만 보고자 하는 정보의 내용은 단순한 경우가 많다는 점을 볼 수 있는 대목이다. 그러나 그 내용이 단순하다고 해서 이를 집계하는 일이 결코 단순한 것은 아니다. 지금 거의 모든 운영계 시스템이 여유롭게 운영되는 회사는 별로 없을 것이다. 그런데 이러한 BAM을 위하여 1분 단위나 5분 단위로 집계를 생성하는 프로세스를 수행하면 운영계 담당자는 결코 쉽게 응답할 수 없을 것이다. 이러한 단순한 업무를 위하여 많은 투자 - CPU 추가, 메모리 증설 - 를 하는 곳도 있다.
그럼 이러한 시스템의 투자에 대한 효과를 알아 보자. 과거 데이터웨어하우스 시스템이 구축되기 이전에 경영층에서 볼 수 있는 자료는 3일에서 1주일 전의 자료를 정형화된 형태로 보고받는 것이 전부였다. 새로운 자료를 요구하면 자료를 집계하여 분석하는데 많은 시간이 걸려 의사결정에 필요한 시기를 놓치는 경우가 다반사였다.
▲ 코딩없는 GUI 개발 환경
데이터웨어하우스 시스템은 이러한 문제를 한번에 해소하겠다는 것으로 어제까지의 정보를 다양한 각도에서 분석해 경영층에게 의사 결정의 기초 자료로 활용할 수 있도록 정보를 제공하는데 의미가 있다. 그런 점에서 DW는 전체적인 측면에서 이제는 없어서는 안되는 시스템으로 자리잡고 있다.
그러나 경영자 측면에서 보면 아직도 아쉬운 부분이 있다. 어느날 하나의 생산라인에서 문제가 발생하여 당일 생산을 못하는 경우가 발생했다고 가정해보자. 아마도 생산 라인에서는 정상화를 위한 엄청난 노력을 하겠지만 어느 누구도 경영층에게 즉각적으로 보고하는 경우는 드물다.
최고 경영자는 다음날 시스템이나 보고서를 통하여 매일 매일의 생산량에서 어느 날 갑자기 하나의 라인에 생산량의 현격한 차이가 생긴 것을 보고 이를 확인하고자 한다. 그래서 담당 중역이나 관리자에게 연락하여 "현재 조치는 완벽하게 되었나? 수고 많았네. 결과 보고를 만들어 주게" 정도의 이야기를 할 것이다. 이 내용에는 의사 결정을 내린 부분은 없으며 이미 의사 결정을 내리기 위한 결정적인 시기가 지났다는 사실이 담겨있다.
만일 실시간으로 현재의 문제들이 경영층에게 자동으로 보고된다면 좀더 효과적으로 문제에 대처할 수도 있을 것이다. 경영층에서 이 시스템을 통하여 현 시점에서 현장에서 발생하는 상황 정보를 볼 수 있다면 현재의 상황을 중심으로 분석이 가능하다. 또 시간 단위의 예측까지 한 화면에서 필요한 정보를 모두 볼 수 있다면 전체 상황을 실시간으로 판단할 수 있을 것이다. 더 나아가 가장 현실적으로 의사 결정을 내릴 수 있는 상황이 시스템으로 제공된다면 좀더 적극적으로 투자를 할 것이며, 차세대 데이터웨어하우스 시스템의 역할도 제 자리를 잡게 될 것이다.
차세대 DW의 바람직한 구축 방안
일반 사용자 측면에서 보면 그동안 많은 온라인분석프로세싱(OLAP) 시스템은 좋은 사양의 PC에 OLAP 클라이언트를 설치하여 일부만이 사용하는 전용 시스템 처럼 구성되었다. 그러나 차세대 시스템의 경우 좀더 많은 사용자, 좀더 다양한 사용자, 심지어는 고객까지도 활용할 수 있는 시스템으로 자리를 잡아야 한다.
▲ 실시간 모니터링
현재의 데이터웨어하우스(DW) 시스템은 분석이 필요한 업무에서만 제한된 용도로 사용되고 있다. 그러나 차세대에서는 실시간으로 중요 정보를 경영층에게까지 즉시 제공하여, 경영층에서는 현재 표시되고 있는 정보의 정확한 이해를 위해 가장 적당하다고 생각되는 관리직이나 담당자에게 직접 전화를 걸 수 있을 것이다. 그러나 담당자가 현재의 상황을 모르고 있다면 당연히 불호령이 떨어질 것이고 어려운 상황을 겪을 수 있을 것이다.
고객을 살펴보면 실시간 마케팅 업무에 활용하는 경우를 볼 수 있다. 현재까지는 몇몇 잘 갖추어진 인터넷 소핑몰에서만 활용되고 있지만 실시간 데이터웨어하우스가 잘 구성되면 현재의 트랜잭션을 대상으로 그동안 동일 고객의 구매 형태나 현재 구매 중인 상품에 대한 구매자들의 일반적인 형태를 분석하여 업-셀링, 크로스-셀링 등 추가 구매에 대한 마케팅 활동을 할 수 있는 데이터베이스 마케팅 업무에 활용 할 수 있을 것이다.
차세대 데이터웨어하우스의 구축의 목적은 위에서 열거한 좋은 기능을 접목하여 한단계 발전된 DW로서 향상된 기능을 제공하는 것이다. 그러나 좀더 근본적인 부분은 우리가 현재 당면하고 있는 문제를 효과적으로 해결하는 것이다. 이 문제의 근본적인 해결 없이 지금과 동일한 방법론으로 구성하면 새로운 시스템이라고 해도 똑같은 문제에 직면하는 것은 물론이며, 시간이 지나면 현재의 어려움이 또다시 나타날 것이다. 그럼 새로 구축될 차세대 DW 시스템이 필요로 하는 기술적 요소들은 무엇이 있는지를 살펴보자.
실시간 데이터 처리
차세대 DW시스템에서도 지금과 같이 10분 단위로 운영계 시스템에서 데이터베이스에 대량의 부하를 주면서 데이터를 취합하면 결과는 좋을지 모르나 과정은 커다란 문제를 안고 있는 시스템으로 남을 것이다.
최근에 실시간 데이터처리를 위한 가장 현명한 방법으로 운영계 시스템에서 발생하는 데이터베이스 로그를 이용하여 실시간으로 운영계 시스템에서 변경된 내용만 DW나 정보계 시스템으로 전달하는 기술이 개발되어 활용되고 있다. 거의 모든 운영계 시스템에서는 데이터베이스 로그를 관리하고 있으나 이 데이터베이스 로그는 단지 데이터베이스에 문제가 발생했을 때 복구하기 위한 자료로 활용할 뿐이다.
현재 활용되고 있는 기술은 이 데이터베이스 로그를 이용하여 변경된 정보를 확인하고, 이 정보를 데이터로 만들어 데이터웨어하우스나 정보계에서 활용할 수 있도록 해준다. 이 기술의 장점은 가장 손쉬운 방법으로 변경 정보를 바로 얻을 수 있으며, 변경 정보 취득을 위하여 데이터베이스에 다시 액세스를 하지 않아도 되므로 시스템 부하 및 데이터간의 경합을 최소화할 수 있다는 것이다. 또한 변경 정보를 위하여 현재 운용중인 어떠한 프로그램의 변경도 필요하지 않다는 것이다. 이러한 기술을 CDC(changed data capture)라고 하는데 최소의 비용으로 차세대 데이터웨어하우스의 최대의 효과를 올릴 수 있는 기술이라고 할 수 있다.
수행 속도 향상을 위한 인-하우스 개발과 전문 툴과의 가장 큰 차이점은 병렬 프로세싱(parallel processing)과 멀티-쓰레드(multi-thread) 방식의 제공으로 볼 수 있다. 오라클의 사용자라면 오라클의 병렬 프로세싱을 이용하여 질의(query)의 수행 속도가 비교되지 않을 정도로 향상되는 것을 볼 수 있다. 이러한 병렬 기능은 일반적인 애플리케이션 개발로는 불가능하지만 전용 툴에서는 단순히 정의만으로 완벽한 병렬 기능을 제공받아 CPU의 개수에 따라 폭발적인 수행 속도의 향상을 누릴 수 있다.
ETL 작업을 위하여 많은 개수의 CPU를 장착한 시스템을 보유하고 있더라도 한 순간에 이러한 자원을 충분히 활용할 수 없다면 많은 비용을 들여 시스템을 구성해야할 이유가 없을 것이며, 시스템 자원을 최대한 활용하여 가능한 한 수행 속도를 개선할 수 있는 향상된 툴의 기능이 필요할 것이다.
현재 근본적인 문제 가운데 하나는 프로그램 개발을 통한 ETL 시스템의 구축으로 볼 수 있다. 프로그램의 개발은 개발자의 숙련도와 성격, 습관에 따라 상당히 다른 프로그램 스타일로 소스가 생성될 것이고, 프로그램 내에 존재하는 50~100 라인에 해당하는 질의 문장은 개발자 자신도 3~4개월이 지나면 이해하지 못하는 경우가 생긴다.
일반적으로 1세대 ETL 툴과 2세대 ETL 툴의 차이를 프로그램 개발을 그 기준으로 삼는다. 2세대 ETL 툴에서는 프로그램 개발이 아닌 GUI 환경에서 오브젝트를 드래그 앤 드롭(drag-and-drop) 방식으로 소스와 타켓을 함수지어주는(mapping) 형태로 구성한다. 프로그램 개발 없이 GUI 환경에서의 함수처리(mapping)는 누가 개발을 하더라도 유사한 성능과 기능으로 구성이 가능하며 향후 유지보수 시 누구나 쉽게 각각의 함수(mapping) 정보를 이해하고 새로운 기능을 적용시킬 수 있다.
실시간 모니터링
어느날 아침에 출근하자마자 전화를 받게 된다. 왜 어제의 정보가 온라인분석프로세싱(OLAP)에서 보이지 않느냐고. 그때부터 담당자는 OLAP의 화면들을 확인하게 되고 각각의 화면에서 정상적으로 표시되지 않는 내용을 확인하여 ETL(extraction, transformation, and loading) 작업에서 어느 부분에 문제가 발생했는지를 확인하게 된다.
많은 ETL 작업을 수행하는 시스템의 경우 하루에 2000개 이상의 작업 로그 파일을 만들게 된다. 이 2000여개의 로그 파일을 분석하여 어디에서 문제가 발생한 것인가를 확인하는 것은 능숙하지 않은 담당자의 경우 결코 쉬운 일이 아니다. 문제를 찾아서 재 작업을 완료하는데 점심 시간을 넘기지 않는다면 다행이지만 다음날 작업에도 영향을 끼칠 정도로 문제를 해결하지 못하는 경우가 적지 않다.
이제는 모든 작업 결과의 완료 여부를 한눈에 확인할 수 있는 모니터링 기능이 절실히 필요하다는 것을 느낄 것이다. 또한 현재 작업되는 내역의 프로세스 단위뿐만 아니라 프로세스 내의 작업 순서나 In/Out 트랜잭션의 개수도 정확하게 실시간으로 확인할 수 있는 기능도 필요할 것이다.
전체적으로 잘 수행되고 있다면 수행되고 있는 상황을 모니터링 할 수 있어야 하고, 문제가 발생하면 바로 모니터링 화면에 문제를 표시하여 해당되는 프로세스를 클릭해 자동으로 로그 파일로 연계, 문제가 발생한 내역을 쉽게 찾아낼 수 있는 기능이 필요하다. 경우에 따라서는 문제가 발생한 순간 SMS나 이메일을 통하여 담당자에 전달하는 기능도 필요하다.
이러한 실시간 모니터링 기술은 누구보다도 먼저 담당자가 이해하고 확인하여 조치를 취할 경우, 문제 발생 시에 어려움 없이 복구하여 정상상태를 유지할 수 있다.
차세대 DW 구축 고려 사항
차세대 DW를 구축하고자 할 때 단지 위에 열거된 내용만을 기대하고 시작할 수는 없을 것이다. 이밖에도 수 많은 고려 사항들이 있을 것이다. 지금까지 서술한 내용은 앞으로 주요하게 다루어야 할 이슈는 무엇이며, 현재의 문제점을 해결할 수 있는 방안의 제시라고 할 수 있다.
우리는 데이터웨어하우스 초기에 데이터웨어하우스가 앞으로 어떻게 변화할 것이며, 어떠한 어려움을 겪을 것인지를 잘 모르고 시작했다. 그러다 보니 모든 문제를 몸으로 겪으며 해결할 수 밖에 없었다. 앞으로 차세대 DW를 구축하고자 하는 기업들이 고려해야할 사항을 제시해 본다.
첫째, 과거에는 단지 개발 생산성을 고려해 툴 중심에서 접근하는 것이 주류를 이뤘지만 이제는 유지보수 면에서 이점을 누릴 수 있는 기능이 제공되어야 한다. 둘째, 수작업으로 해온 일을 최대한 자동화할 수 있는 기능이 필수적이며, 또한 시스템의 자원을 최대한 활용할 수 있는 기능도 수반되어야 한다.
하지만 무엇보다 더 중요한 것이 있다면 모든 프로젝트는 사람이 한다는 사실이다. 사람이 만드는 부분이 70%이며, 시스템이나 툴이 차지하는 비중은 30%에 불과하다. 아무리 좋은 제품과 좋은 개발 방법론이 있다고 하더라도 제대로 활용하지 못하면 오히려 그러한 제품이나 툴은 장애가 되기도 한다. 아무쪼록 프로젝트에 참여하는 모든 사람들이 한마음으로 같은 목표를 위하여 같이 생각하고 고민하고 행동한다면 좋은 차세대 데이터웨어하우스가 구축될 것이라고 믿는다.