요즘 서울 강남 집값 상승의 요인은 아파트 재건축이 주도하고 있다고 한다. 그 만큼 아파트 재건축은 효용성이나 재산적 가치 면에서 많은 이들이 관심을 갖고 있다. 과거 20년 전에 건축된 저층의 아파트는 당시에는 새로운 형태의 대단위 주거지역 이었고 구조나 시설 면에서 당시에는 최첨단의 아파트였다.

그러나 세월이 지나면서 더 좋은 자재가 개발되고 새로운 디자인의 아파트가 등장하면서 이들 오래된 아파트는 재건축의 이슈로 인해 다시 초미의 관심사로 대두 되고 있다. 최근 재건축되어 입주를 기다리는 아파트를 보면 과거 아파트 구조와는 비교도 되지 않을 정도로 새로운 형태로 재탄생한 것을 볼 수 있다. 이번에 재건축된 아파트는 상당기간 많은 사람들의 관심권내에서 부러움의 대상이 될 것이다.

BI, DW, 각종 데이터마트 등의 프로젝트는 대부분 90년대 중반에 시작하여 90년대 말까지  IT 산업의 주요 프로젝트로 자리잡아왔다. 당시의 DW나 BI는 획기적인 방법론이었고 이들 시스템은 기업 내에서도 핵심 분야로 자리 잡았다. 많은 사람들의 중심에서 관심을 받게 되었고 심지어는 BI나 DW를 구축하지 않으면 IT 분야에서 뒤 처지는 것으로 인식되던 시기도 있었다.

그러나 그때 프로젝트 당시의 상황으로 돌아가 보면 단지 사용되는 툴(Tool)이라고 하는 것은 데이터를 관리하는 데이터베이스와 사용자 UI를 담당하는 OLAP Tool이 전부였고, 나머지 분야는 프로그래밍 언어를 통한 개발로 시스템이 구축되었다. 그때 당시로 보면 OLAP 툴 하나만도 획기적인 툴로 인식되어 사용자들에게 사랑을 받던 시대였다.

세월이 흘러 10여년이 지난 지금 시점에서 당시를 돌아보면 너무나도 노동 집약적인 방법이었고 자동화나 모니터링 등의 기능은 찾아보기 어려운 형태였다. 이제 BI나 DW도 아파트의 재건축과 같이 새로운 형태의 기술과 방법론, 툴 등을 통하여 그간의 불편한 부분을 제거하고 새로운 시스템으로 다시 탄생시킬 시기가 왔다고 생각된다. 이러한 재구축을 고도화란 표현으로 재조명 해 보기로 하자.

다시 10년 전의 BI, DW의 프로젝트로 돌아가 보자. 물론 모든 프로젝트가 같았었다고 생각하지는 않지만 본인이 겪었던 많은 프로젝트에서 유사한 경향이 나타났다. IT 관련 부서는 BI 프로젝트를 기획하여 예산을 확보하고 프로젝트를 추진하면서, 경영층이나 현업의 협조를 위하여 약간의 무리수를 두어 필요한 부분은 모두가 가능하다는 인식을 심어 기대감을 조성했다. 또 다른 경우는 현업이나 경영층의 커다란 관심 없이 정확한 요건 사항조차 만들지 않은 상태에서 프로젝트를 진행하는 경우도 있었다. 두 경우 모두 프로젝트를 진행하는데 많은 어려움을 만들어낼 소지를 내포하고 있는 것이다.

당시의 신기술을 적용한 프로젝트는 사소한 부분에서부터 시행착오를 겪는다. 분석이나 설계를 하는 컨설턴트들은 다차원 모델링에 대한 이해 부족으로 OLAP 툴에서 적용 할 수 없는 상태로 모델링을 하는 경우가 종종 있었고, 개발자 역시 기존에 사용하던 개발 툴과는 다른 사상을 갖는 OLAP 툴에 적응 하지 못하여 쉽게 구현이 가능한 부분도 수많은 코딩을 통하여 화면을 구성할 수밖에 없는 상황을 초래했다.

어쨌거나 모델링을 하고 개발을 하여 사용자가 필요한 화면을 만들었지만 진짜 커다란 문제는 처음에는 아무도 인식하지 못하고 있던 부분에서 개발자들을 기다리고 있었다. 프로젝트 초기에는 데이터에 관련된 통합방안, 절차, 품질 등은 그냥 잘하면 된다는 생각에서 진행을 했으나 프로젝트가 진행되는 동안 점점 데이터에 대한 압박이 심하게 밀려오게 된다. 일반적인 프로젝트에서는 초기 단계에서는 기초 데이터만을 이용하여 데이터가 쌓여가는 방식이었으나, BI나 DW에서는 이미 수년간의 데이터를 쌓아놓고 시작을 해야 하는 문제점이 있었다.

가장 어려운 부분은 데이터의 품질이 많은 시간과 인력을 필요로 하는 작업으로 대두 될 지는 아무도 생각하지 못 했던 문제였던 것이다. 프로젝트 초기에 레거시 시스템에 대한 데이터의 품질을 문의해 보면 누구나가 완벽하게 구성되어 오차가 발생하지 않는다고 장담을 하지만, 실제적으로 ETL을 수행하여 결과를 조회해 보면 기존의 시스템에서 보는 값과는 항상  차이를 보이게 된다.

실제로 ETL 담당자는 데이터 이전을 위한 프로세스를 개발하는 시간보다 데이터의 품질을 확보하는데 더 많은 시간과 노력을 들이게 되고, 심지어는 그때야 비로소 기간계 시스템의 문제를 확인하여 기간계 시스템부터 변경하는 경우를 만나기도 한다. 우여곡절 끝에 데이터를 모두 옮기는 작업을 완료했는데 또 다른 복병이 기다리고 있는다. 속도의 문제이다.

수년간의 엄청난 양의 데이터를 하나의 시스템으로 통합을 하기는 했으나 그 대량의 데이터를 가지고 조회를 하는 시점에서의 수행 속도가 참을만한 수준과는 너무나 거리가 먼 경우를 초래한다. 그 때부터 데이터베이스 튜닝 전문가를 찾아서 컨설팅을 받거나 심지어는 모델링 단계부터 다시 작업을 하는 경우가  발생한다. 모든 프로젝트가 막바지에 가까워질수록 보이지 않던 문제점이 나타나게 되고 프로젝트 팀원들을 힘들게 한다. 어려운 상황을 몇 번은 넘어 결국은 프로젝트가 오픈을 하는 시점이 도래를 하게 되고 몇 일간의 밤샘 작업을 통하여 성공적인 프로젝트 완료 보고를 하게 된다.

이제 프로젝트가 오픈을 하여 매일 밤마다 ETL 작업을 수행하여 아침까지 OLAP 화면에 표시 될 데이터를 만들게 된다. 매일 매일의 ETL 작업은 매일 새로운 문제로 인하여 담당자를 힘들게 만들고 프로젝트가 완료된 이후에도 상당기간 철수하지 못하고 오류에 대한 수정 작업을 계속하게 만든다. 그래도 세월이 흐르게 되면 안정화 단계에 도달하게 되고 고객과의 합의하에 프로젝트에서 철수를 하게 된다. 지금 부터는 프로젝트가 완료된 이후의 발생하는 문제의 유형을 알아보고 고도화 작업 시 고려해야 할 사항에 대하여 정리해 보자

사용자 요구 사항 증가
이제부터의 문제는 고객 IT부서 담당자의 역할이다. 다행히 ETL 작업은 계속적인 수정 보완을 통하여 커다란 문제를 야기 시키지는 않지만, 그래도 문제가 발생하고 개발 담당자를 찾아서 물어보고 스스로 해결하기도 하게 된다.

인간이라는 동물은 계속적인 학습을 통하여 성장하고 발전을 하게 된다. 하나의 시스템이 개발된 이후, 이 시스템을 사용하는 담당자도 역시 학습을 통한 성장을 하게 된다. 처음에는 본인의 업무와는 별 관계가 없을 것이라고 생각하여 BI나 DW 시스템에 커다란 관심을 보이지 않던 일반 현업 담당자들도 언제부터인가 주위의 동료들이 이 시스템을 통하여 업무량을 줄이는 현상을 보게 되면, 그때부터는 아주 짧은 기간 동안에 교육이나 교재를 통한 스스로의 학습을 통하여 자신의 업무에 시스템을 활용하게 된다. 처음 단계에서는 10% 정도의 기능을 사용하던 담당자가 자신의 업무에 활용하여 업무량을 줄일 수 있다는 판단을 하게 되면 개발자조차 생각하지도 못한 기능을 이용하여 120%의 활용 능력을 보이게 된다.

당연히 현업 담당자는 IT 시스템에 대하여 감사하는 마음을 갖고 즐거운 마음으로 시스템을 활용하게 된다. 감사하고 즐거운 마음도 잠시 일정 기간이 지나게 되면 사용자는 점점 요구 사항을 늘어놓게 된다. 아이러니 하게도 시스템 구축 당시 별 관심이 없던 사람들이 오히려 많은 요구를 해와 IT 담당자를 당혹하게 만든다.

그러나 사용자의 성장에 맞추어 시스템이 계속적으로 성장을 하는 것은 불가능한 현실이다. 사용자의 요구 사항을 반영하기 위하여 화면의 일부를 수정하거나 몇 가지 계산 공식을 추가하는 사항은 커다란 작업 없이도 개선이 가능하다. 하지만 현재 시스템에는 존재하지 않는 자료를 보여 달라고 하는 경우는 레거시 시스템으로부터 처음부터 데이터를 다시 가져다가 데이터베이스를 만들어서 보여 주어야 하는 대대적인 기능 개선 사업이 필요한 상황이 된다.

당연히 IT 담당자로부터는 부정적인 대답을 하게 될 것이고 그 이후부터는 사용자 측면에서는 지금까지 보여주던 화면은 당연한 것이고 새로운 요구를 받아들이지 못한 IT 부서에 대하여 점점 불만이 발생하는 상황을 직면하게 된다. 그래도 현업 담당자는 자신의 업무량을 최소화하기 위하여 계속적인 새로운 요구를 요청하게 되고 IT 담당자는 이러한 요구 사항이 스트레스로 쌓이게 된다.

프로세스 개선
새로운 요구 사항이 항시 무시되는 것은 아니고 조금씩 계속적인 수정 작업은 진행하게 된다. 문제는 최적의 방법을 찾아서 가장 적절하게 수정 작업이나 보완 작업을 진행해야 하지만 현재 구축된 내용에 대한 정확한 문서를 찾기도 어려울 뿐 아니라 문서가 존재 한다고 하더라도 대부분이 버전 관리가 되고 있지 않아 과거의 정보만을 기록한 문서가 대부분이다. 아마도 IT 담당자는 많은 고민과 검토를 거쳐 수정작업을 진행하거나 보완 작업을 수행하지만 오히려 이 부분은 더 많은 고민거리를 만들게 되는 경우가 된다.

기존에 수행되던 작업조차 수행이 안 되는 경우가 생기는 것이다. 예를 들어 영업 시스템에서 데이터를 매일 만들어 스테이지 데이터베이스로 넘기는 작업의 프로그램이 있다고 가정을 하자. 이 경우 새로운 상품 개발로 인하여 추가로 데이터를 가지고 와야 하는데 작업된 프로그램의 문서가 정확하지 않는 상태에서 프로그램의 소스만으로 수정 및 보완 작업을 하는 것은 심하게 표현하면 미로를 하나하나 찾아가는 경우가 될 수도 있다. IT 담당자는 며칠의 고민과 테스트를 통해 프로그램을 수정하여 등록을 했는데 문제는 그 다음날 매출과 관련된 모든 데이터에서 오류가 발생하는 경우를 만날 수도 있다.

당연히 IT 부서는 긴급 사항으로 모든 수정된 부분을 복귀하고 재작업을 수행하여 원래의 상태로 환원할 수 있지만 그 동안 IT 부서는 많은 신뢰성 하락을 겪게 될 것이고 심한 경우 IT 부서의 책임자에 대한 문책을 당하는 경우도 발생 할 수 있다. 이후 IT 담당자는 절대로 프로그램 수정을 통한 보완 작업을 수행하지 않을 것이다. 그러다 보면 이 문제를 해결하기 위하여 새로운 프로그램을 작성하여 기존의 작업과 별도로 새로운 프로세스를 수행하게 된다. 물론 레거시 시스템의 부하는 증가 될 수 있으나 기존의 프로세스에는 영향을 미치지 않으므로 안정적으로 작업이 수행되는 것 같이 보이게 된다.

이러한 상태로 새로운 요구 사항이 발생 할 때 마다 IT 담당자는 새로운 테이블을 생성하고 새로운 프로그램을 작성하고 2중 3중의 작업을 수행하게 된다. 점점 시스템의 프로세스는 복잡하게 구성되어지고 도저히 개선을 할 수 없는 상태로 변하게 된다. 한 명의 담당자가 이러한 상태로 만들어 놓은 상태에서 다시 담당자가 변경되면 새로운 담당자는 이전 담당자가 했던 시행착오를 다시 겪게 되고, 역시 한 두 번의 어려운 상황을 거친 이후에는 새로운 테이블, 프로그램, 프로세스를 생성하는 것으로 문제를 해결하고자 할 것이다.

새로운 요구가 반영되기 위하여 이러한 작업이 수행되고, 새로운 업무가 추가되어 동일한 작업을 수행하고 새로운 시스템이 추가되면 대대적으로 이러한 작업을 수행하게 된다. 3년에서 5년 정도의 기간이 지난 시스템을 보게 되면 프로젝트 완료 당시에 300여개의 테이블은 1,000개를 육박하는 테이블로 증가하게 되고, 어느 누구도 왜 그렇게 테이블이 증가하게 되었는지, 각각의 테이블의 용도가 무엇인지, 무엇 때문에 수많은 프로세스가 밤새워 수행되어야 하는지를 모르게 된다. 단지 우리의 업무는 복잡하기 때문에 당연히 밤새워 돌아야 한다고 자위하고 있게 된다.

수행 속도 향상
프로젝트 완료 시점에는, 야간 ETL 작업은 3~4시간이면 완벽하게 완료되어 다음날 사용자에 의하여 이른 아침부터 업무를 처리하는데 전혀 지장을 주지 않게 설계되고 수행되어 진다. 그러나 시간이 흐름에 따라 데이터의 증가와 더불어 위에서와 같이 새로운 테이블과 새로운 프로세스가 증가되어 3~4시간이면 완료되는 ETL 작업이 아침 8시에서 9시까지 간신히 마치는 사태를 만나게 된다.

이러한 문제는 시스템의 중요도에 따라 심각성을 우려하게 된다. 기업은 가장 쉽게 해결하는 방법으로 자금이 필요로 하지만 하드웨어를 증설하는 방법을 택하게 된다. 타당한 논리로는 데이터 량의 증가, 사용자의 증가, 업무의 증가 등으로 불가피하게 시스템의 CPU나 메모리, 디스크를 증설하게 된다. 문제는 근본적인 해결 방법이라기보다는 일시적으로 해결된 것 같이 보이는 부분으로 처리 된다.

다시 기간이 흐름에 따라 하드웨어 증설시 5~6시간으로 줄었던 ETL 작업은 빠른 시간 내에 8~9시까지 근접하게 된다. IT 담당자는 나름대로 이 문제를 해결하기 위하여 남들이 쉬는 주말마다 데이터베이스의 재구성 작업을 수행하여 과거 데이터를 제거 하거나 인덱스 등을 재 생성하는 방법으로 작업의 시간을 줄이고자 노력을 하게 된다.

역시 작업을 수행 한 후 1주일 정도는 효과를 보게 되지만 역시 이전과 동일한 결과를 만나게 된다. IT 담당자는 점점 자신의 업무에 회의를 갖게 될 것이고 매일 매일이 살얼음판을 걷는 마음으로 아침을 시작하게 될 것이다.

실시간 모니터링
IT 담당자는 답답하기만 하다. 문제를 해결하기 위하여 매일 밤마다 남아서 작업이 수행되는 부분을 확인하고자 하지만 지정된 시간에 수행되는 ETL 작업은 갑자기 동시에 다수의 프로세스가 수행하면서 70~80%의 CPU 사용, 100%에 가까운 DISK I/O를 만들면서 계속적인 작업을 수행한다. 하지만 어느 프로세스에서 어떠한 작업 때문에 CPU의 사용이 과다한지 DISK의 사용이 과다하게 운용되고 있는지를 확인 할 방법이 없다.
물론 모든 작업에 대하여 각각의 프로세스마다 작업 로그 파일을 만들어 결과를 보관하지만 수많은 로그 파일을 일일이 파악하기도 어려울 뿐만 아니라 서로 영향을 받는 프로세스들이 엮여 있어 정확한 판단을 하기도 어렵게 된다. 그 보다 더욱 중요한 문제가 있다.

대부분의 담당자는 본인의 확인에 의하여 작업에 오류가 발생한 지를 확인하기 보다는 일반적으로 어제의 데이터가 나타나지 않는다는 현업 사용자의 연락에 의하여 ETL 작업의 오류 여부를 확인하게 된다. 작업의 오류를 확인하기 위해서 IT 담당자는 역시 수많은 로그 파일의 확인을 통하여 오류가 발생한 부분을 발견하게 되고 그 때부터 긴급 작업을 통하여 오류를 해결 한 후 새로이 작업을 수행하게 된다. 빠른 경우는 1~2시간 내에 작업이 완료 될 수도 있겠지만 경우에 따라서는 오전을 넘긴 시간에야 비로소 모든 작업이 완료되는 경우도 있게 된다. 그 동안 IT 담당자는 아마도 몸무게가 2,3 Kg는 빠졌을 것이다.

똑똑한 담당자라면 몇 번의 문제로 인하여 또 다른 프로세스를 만들게 될 것이다. 각각의 작업이 완료되는 시점에서 데이터베이스에 테이블을 만들어 완료 여부를 저장하는 작업을 모든 프로세스에 추가를 할 것이지만 역시 문제는 비정상적인 오류로 인하여 프로세스가 종료되는 경우는 역시 데이터베이스에 오류 발생에 대한 내용을 저장하지 못 한 상태에서 작업이 종료 될 것이다. IT 담당자는 점점 더 깊은 고민에 빠지게 될 것이고 오류의 확인을 위하여 오전의 대부분의 시간을 할애해야 할 것이다.

이러한 일상이 반복되면서 5년 또는 10년의 시간이 지난 상태의 BI 시스템, DW 시스템이 아직까지도 기업에서는 없어서는 안 되는 중요한 시스템으로 자리를 차지하고 있다. IT 분야  만큼 빠른 속도로 신기술이 개발되고 개선되는 분야도 없을 것이다. 이 시점에서 우리는 이 중요한 시스템을 새로이 재구축 하여 좀 더 변화된 기업 환경에 적절한 시스템으로 거듭나게 해야 할 것이다.

BI나 DW의 고도화 작업을 통하여 새로이 재탄생하기 위한 프로젝트를 수행하는 시점에서 보면 과거 시점의 최상의 조건보다는 많은 부분이 향상되어 오히려 이제는 서버나 S/W를 선정하는데 있어 더 복잡해지고 혼란스러워 질 것이다. 우선은 완벽한 프로젝트의 수행을 완료하기 위한 다양한 툴을 선택하여 완성도를 높이려 선정 작업을 진행해야 할 것이나 지금까지 알아본 결과와 같이 DW나 BI 프로젝트는 프로젝트를 완료하는 것이 문제가 아니라 프로젝트가 완료된 시점에서부터 오히려 해결하기 어려운 문제가 계속적으로 발생하는 것을 보았다.

그러면 새로이 구축하고자 하는 시스템에서는 프로젝트의 완성도도 중요하지만 이제까지 겪었던 시행착오를 다시 되풀이 하지 않기 위하여 프로젝트 기획 단계에서 프로젝트의 완성도뿐만 아니라 향후 5년, 10년을 유지보수 하는데 편리하고 안정적으로 운용하기 위한 사항들을 고려해야 할 것이다. 위에서 거론한 사용자의 요구사항 증가에 대한 해소 방안, 프로세스의 개선 및 보안을 쉽게 하기 위한 방안, 수행 속도를 개선하기 위한 방안, 전체적으로 모니터링을 할 수 있는 방안을 포함하여 유지보수 감소를 위한 방안, 실시간 데이터 요구에 따른 대응 등에 대하여 알아보기로 하자.

사용자 요구사항 & 프로세스 개선
우선 사용자의 요구사항 증가에 대한 해소 방안과 프로세스 개선에 대한 필요성을 검토해 보자. 두 부분을 같이 검토해 보는 이유는 사용자 측면에서는 자신들이 필요한 화면이나 리포트에 대하여 요청을 하지만 요청된 사항의 데이터가 BI나 DW 시스템에 존재하는지에 대한 사항을 검토하지는 않는다. IT 담당자는 요청된 내역을 분석하여 기존의 데이터가 확보된 사항에 대한 변경 요청이나 추가 요청은 커다란 문제없이 화면 프로그램의 개발이나 변경을 통하여 해결이 가능하다고 본다. 문제는 데이터가 확보되지 않는 정보에 대하여 요청 사항이 발생하는 경우 화면 프로그램의 개발만으로는 불가능한 문제가 될 것이다.

근본적으로는 레거시나 데이터를 보유하고 있는 타 시스템으로부터 데이터를 가지고 오는 부분부터 설계를 하고 ETL을 수행하고 화면을 개발해야 해야 하는데 현재 시스템의 문제는 새로운 프로세스를 추가하는 과정에서 어려움으로 인하여 작은 변경만으로도 가능한 작업이 새로운 커다란 프로세스의 생성 및 작업으로 변질 되는 경우를 보았다.

새로이 구축되는 시스템에서는 이러한 부분을 최소화하기 위하여 어디에 데이터가 있는지만 알고 있다면 쉽게 추가나 변경이 가능한 기술이 제공되어야 할 것이다. 또한 지금과 같이 필요한 경우마다 항시 새로운 ETL을 생성하는 것이 아니라 기존의 작업에 쉽고 정확하게 변경 할 수 있는 기능 또한 제공되어야 할 것이며 유사한 형태의 개발된 사항이 있다면 만들어진 내용을 쉽고 편리하게 재사용 할 수 있는, 재 사용성이 보장되는 제품이 선정되어야 할 것이다.

쉽고 완벽한 변경 가능성은 새로운 기능 추가에 따른 시스템부하를 최소화 시킬 수 있을 뿐만 아니라 시스템의 증설 없이도 오랜 기간 동안 시스템의 활용이 가능하도록 지원하게 된다. 이 부분은 ETL 툴에 한정된 것이 아니라 OLAP 툴 역시 유사한 기능을 제공하는 제품이 도입되어야 할 것이다.

수행 속도 향상
레거시 시스템으로부터 BI 서버까지 야간에 데이터가 이동해야 하는 작업은 여러 개의 단계를 거쳐서 이루어지게 된다. 레거시에 존재하는 당일 정보를 스테이지 영역으로 동일하게 이동해야 할 것이고, 스테이지에 넘어온 자료는 업무 규칙 및 다양한 작업을 통하여 ODS (Operational Data Store)에 다시 저장되었다가 DW로 장기간의 과거 데이터의 최신 정보로 넘어간 후 최종적으로 BI 마트에 저장되는 것이 일반적인 프로세스라고 볼 수 있다. 이러한 여러 개의 단계를 거치는 작업도 중요하지만 레거시에서 데이터를 스테이지로 넘어오는 작업이 가장 복잡하고 내부적으로 여러 개의 단계를 거쳐야 하는 단계이다.

기존에 레거시 시스템이 하나로 구성된 기업도 있겠지만 이미 수개 또는 수십 개의 레거시 시스템이 구축되어 운용되고 있고 이 시스템의 대부분에서 데이터를 받아와야 하는 것이다. 이러한 레거시 시스템의 구성 역시 복잡하여 서버의 구성의 경우 메인 프레임에서부터 다양한 UNIX 서버와 NT 서버 등의 구성은 또한 다양한 데이터베이스 IMS, DB2, Oracle, Sybase 등을 포함하고 있다. 다양한 소스에서 데이터를 가져오기 위하여 다양한 방법으로 구성하다 보니 당연히 복잡하게 될 수밖에 없고 수정이나 변경에서도 많은 어려움을 겪게 된다.

새로운 시스템을 구성하는데 있어 고려해야 할 사항은 이러한 다양한 시스템과의 연계가 완벽하게 이루어지는 기능을 제공하는 툴을 선정할 필요가 있다. 또한 연계를 하는데 필요한 작업 역시 레거시 시스템에서 프로그램을 작성하여 플랫 파일 형태를 만들고 전환작업을 수행하여 그 파일을 보내는 방식에서 벗어나 직접 다양한 데이터베이스와의 직접적인 연결을 통하여 해당 데이터베이스에서 스테이지 영역으로 바로 데이터를 전달 할 수 있는 기능이 제공되어야 할 것이다.

레거시에서 스테이지 영역까지 다단계의 작업을 하나의 프로세스에서 단순화시킴으로써 당연히 작업에 필요한 시간을 근본적으로 줄일 수 있겠고, 또한 이 작업을 병렬 프로세싱을  통하여 동시에 다중으로 작업을 수행하여 가능한 한 수행 시간을 최소화시키기 위한 기능이 제공되어야 할 것이다. 나머지 데이터의 이동은 대부분 하나의 시스템에서 주로 이루어지는 것이 일반적인 부분이므로 데이터베이스 차원의 다중 프로세스 방식을 사용 할 수도 있겠고 ETL 툴에서 제공하는 기능을 사용 할 수도 있을 것이다.

그리고 다른 영역으로는 스테이지에서부터 마트에 이르는 데이터의 모델링을 데이터베이스의 기능이나 ETL 툴의 기능을 최대한 활용 할 수 있는 구조로 설계하고 좀 더 압축된 SQL 문장의 작성을 통하여 최적의 속도를 보장 받기 위한 프로젝트의 수행이 필요할 것이다.

모니터링
운영 관리를 담당하는 IT 담당자의 가장 중요한 업무 중의 하나는 현재 시스템 상태를 모니터링 하는 업무일 것이다. 항시 시스템이 정상적으로 수행되고 있는지, 문제는 없는지 등을 관리하고 문제가 발생 했을 때 모니터링 툴을 이용하여 즉시 확인을 통하여 빠른 조치를 취하는 것이 중요하다. 그러나 과거 시스템 구축 시 이러한 모니터링과 관련된 부분에 대하여 일목요연하게 구성되어 관리되어진 프로젝트는 거의 없는 실정이었고, 현재 모니터링을 하고 있다면 대부분 이후에 개발을 하였거나 새로운 툴을 도입한 형태라고 볼 수 있다.

아쉬운 부분은 초기에 ETL 작업과 관련하여 모니터링이 지원된 형태라면 아주 정확하게 모든 업무에 대하여 모니터링이 가능하겠지만 나중에 도입된 시스템의 경우 ETL 작업과 통합된 형태로 지원되지 않아 정확한 모니터링이나 즉각적인 조치를 할 수 없는 툴이 대부분이다. 가장 바람직한 방법은 도입되는 ETL 툴 내에 모니터링 기능이 통합의 형태로 구성되어 있어 시스템의 운용 상태를 확인하는 것이 아니라 현재 수행하고 있는 태스크에 대한 수행 상황을 모니터링 할 수 있어야 한다.

또한 문제가 발생 할 시 문제가 발생한 위치를 정확하게 파악하여 해당되는 로그 파일의 확인이 가능한 기능의 제공 등, 문제를 빠르게 해결하기 위한 제반 사항들이 제공되어야 할 것이다. 일반적인 상황에서 모니터링은 큰 의미가 없다.

항상 문제가 발생했을 때 가장 아쉬운 부분이 문제가 발생한 부분을 빨리 확인하여 바로 조치 할 수 있는 방안이 필요하다. 모니터링은 언제든지 쉽고 빠르게 현재의 상태를 확인 할 수 있어야 하고 문제가 발생 했을 때 즉시로 담당자에게 통보를 하거나 e-mail 등을 통하여 확인이 가능하도록 구성되어야 한다.

유지보수 감소
큰 의미에서 보자면 지금까지 거론된 요건들 모두가 유지 보수를 감소하기 위한 절대적인 기능이다. 그러나 IT 운영자 측면에서 보게 되면 유지 보수는 새로운 작은 개발 프로젝트의 계속이라는 형태로 볼 수 도 있다. 사용자의 계속되는 요구 사항을 반영해야 할 것이고 현재 구성된 기능을 계속적으로 보완을 계속해야 할 것이다. 구성되어 있는 내용을 변경하기 위해서는 현재의 구성을 쉽게 확인 할 수 있는 기능이 있어야 할 것이며 변경 작업 시 디버깅 기능을 제공하여 변경된 내용에 대하여 데이터의 정합성 검증을 할 수 있어야 한다.
특히 중요한 기능중의 하나는 영향도 분석인데 하나의 테이블이나 매핑 정보들에 대하여 서로간의 연관관계를 분석할 수 있는 기능이 있어야 하나가 변경이 된다고 하면 이 변경된 내용이 어디까지 영향을 미치는지를 알 수가 있을 것이고 변경 시에 신중을 기하여 작업 할 수 있는 환경이 제공될 것이다. 이 외에도 유지보수를 편리하게 하기 위한 다양한 기능이 요구되나 일반적인 사항에 대해서는 프로젝트 시점에서 Tool을 선정하는 과정에서 검토가 될 것이다.

실시간 데이터 요구
최근 들어서 비즈니스 솔루션 분야에 최대의 화두로 등장한 단어가 RTE(Real Time Enterprise)이다. RTE는 여러 가지 형태로 해석되고 표현되기도 하지만 비즈니스 적으로 간단하게 해석해 보면 모든 업무가 실시간으로 실행되어야 한다는 것이고, 시스템적으로 본다면 실시간으로 모든 업무가 수행 될 수 있도록 시스템이 구축되어야 할 것이다. 다시 이 부분을 데이터적인 측면에서 보면 시스템적으로 실시간으로 운용되기 위해서는 모든 시스템의 데이터가 실시간으로 시스템 간에 통합되어 이동이 되어야 한다고 볼 수 있다.

예를 들어 영업에서 오더를 발주하면 실시간으로 현재까지의 매출 집계에 반영이 되어야 하고 생산 시스템에 즉시로 반영되어 생산 스케줄에 반영이 되면서 부품 오더가 자동으로 발주되는 영업 시스템에서부터 발주까지, BI까지 실시간으로 데이터가 이동을 해야 업무가 실시간으로 수행 될 수가 있을 것이다. DW나 BI가 없던 시기에는 어제의 정보라도 좋으니까 한눈에 볼 수 있는 자료를 만들어 주면 좋겠다고 임원 및 경영진은 요구를 하게 되고 BI가 구축되어 익일의 정보가 화면에 일목요연하게 표시되고 분석 되어진 정보를 보고 좋아 했었을 것이다.

그러나 이제는 어제의 정보가 아니라 지금 현재의 정보를 보고자 하는 것이 경영진의 요청이 발생하기 시작을 하였다. 그러나 현재의 시스템의 구성으로는 실시간으로 데이터를 BI로 통합하기 위한 시스템 부하가 레거시 시스템에 치명적일 수 있으므로 쉽게 실시간 데이터의 구성을 하는 데는 어려움이 있다. 그러나 앞으로 늘어나게 될 실시간 요구에 대한 방안을 구축하여야 새로 구축하는 시스템의 생명 주기(Life Cycle)가 길어질 수 있는 중요한 요소로 구성 될 것이다.

최근 기술을 적용한 ETL 툴에서는 데이터베이스의 테이블을 통하지 않고 로그 파일을 이용하여 변경 정보를 만들어 타겟 시스템으로 전달을 할 수 있는 기능을 제공하고 있다. 이러한 기능을 이용한다면 시스템의 부하나 데이터베이스의 부하를 최소화 하면서 실시간으로 입력/변경 정보에 대하여 BI 시스템으로 전달하게 되고 BI 시스템에서는 실시간으로 변경된 정보를 경영진의 화면에 제공 할 수 있는 기능의 구현이 가능하다.

지금까지 우리는 BI의 고도화에 대한 필요성을 알아보았고 고도화 프로젝트가 시작된다면 일반적으로 프로젝트에서 필요한 사항을 제외하고 프로젝트가 완료된 이후에 발생 할 문제점에 대한 해결 방안을 데이터 측면에서 검토를 해 보았다. 이 글을 통해 거론된 사항이 전부 라고는 생각하지 않는다. 다만 운용자 입장에서 필요하다고 생각되는 내용을 나열하였고 이 부분을 해결하기 위해서는 프로젝트 개발 시에 좀 더 신중을 기하여 이러한 기능을 만들 수도 있을 것이고, 또한 이러한 기능이 제공되는 툴을 도입하여 프로젝트 시점부터 활용 할 수도 있을 것이다.

물론 선정된 툴이 위에서 필요로 하는 모든 기능을 제공하지 않을 수도 있을 것이다. 하지만 한 번의 시행착오를 거쳐 지금의 시점에 왔다면 다음에는 꼼꼼하게 점검하여 개발로 할 수 있는 부분, Tool로 할 수 있는 부분, 운용으로 할 수 있는 부분을 정리하여 각각의 역할에 맞게 프로젝트를 진행하고 유지보수를 한다. 좀 더 완벽한 프로젝트의 수행이 될 것이고 유지보수에서도 적은 인력과 작은 노력으로 편리하고 안정되게 운용이 될 뿐만 아니라 새로운 사용자의 요구 사항도 적극적으로 반영하여 항시 사용자가 신뢰하고 만족하며 사용할 수 있는 시스템이 되지 않을까 생각한다.

필자 ; 정인호 
인포매티카코리아 기술본부 본부장으로 재직중이다. 고려증권을 거쳐 한국오라클 CRM 팀장을 역임했다.