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

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

이번 호에서 주로 다룰 내용은 ‘데이터 품질관리의 성공적인 수행’ 부문이다. 데이터 품질관리에 대해서는 많은 자료에서 찾아볼 수 있지만 ‘데이터 품질관리가 왜 필요한지’, ‘데이터 품질관리를 성공적으로 수행하기 위해 필요한 사항’ 등에 대한 내용은 많지 않기 때문이다.

누구나 숨기고 싶어하는 무엇
속이는 것과 숨기는 것. 어떠한 차이가 있을까? 남들도 잘못되어 있는 것을 알 수 있는데 아니라고 한다면 속이는 것이다. 그러나 나는 잘못되어 있는 것을 알고 있지만, 남들이 모르고 있어 알리지 않는다면 그것은 숨기는 것이다. 또한 숨기고 싶은 것은 남들에게 부끄러운 무엇인가 있을 때 누구나 그러한 사실을 숨기고 싶을 것이다.

우리는 누구나 중요한 사실 몇 가지를 알고 있다. 누구도 현재 우리 회사의 데이터베이스의 테이블 정보를 모두 알고 있는 사람이 없으며, 어디에도 누구나 알 수 있도록 정보를 관리하고 있는 어떠한 서류도 없다. 본인이 관리하고 있지 않은 다른 업무에서 발생되는 데이터가 필요할 때 해당 업무의 담당자가 없다면 아마도 담당자가 돌아올 때까지 기다려야 할 것이다.

매일 잘 수행되던 ETL 업무가 어느 날 갑자기 오류가 발생하였을 때 누구에 의하여 어떤 테이블이 변경되었는지 일일이 담당자들에게 확인하지 않으면 안 된다는 것을 알고 있다. 데이터웨어하우스 담당자는 매일 ETL 작업이 잘 되었는지 확인을 위하여 작업 결과를 확인하지만 단지 작업의 수행 여부에 관련된 것이지, 데이터의 완전성에 대해서는 잘 모르고 있는 것이 대부분이다.

초창기 전산에 의하여 작성된 자료는 무조건적인 신뢰를 보였다. 당연히 사람들의 손으로 계산한 것 보다는 확실하다고 생각했었고 누구도 의심하지 않았다. 그러나 IT 부서에는 정보의 신뢰에 대한 고민을 항시 하고 있지만 외부에는 결코 이러한 고민을 이야기하고 싶지 않은 것이 현실이다.

열심히 했지만 제대로 하지 못하는 무엇
프로그래밍 언어(COBOL, FORTRAN, PL/1…) 로 프로그램을 작성하는 과정에서부터 많은 부분을 데이터 검증에 할애하고 있다. 입력되는 게 숫자인지 문자인지, 부서 코드는 맞는지, 자리수가 맞는지 등등. 하나의 데이터를 입력하거나 파일이나 데이터베이스로부터 데이터를 가지고 올 때 마다 상당 부분의 프로그램 소스 라인을 할애하여 데이터 검증 작업을 하고 있다. 분명 입력 작업에서는 오류를 발생시킬 수 없는 상태로 프로그램을 개발하지만 어디에서인지 모르지만 집계를 낼 때 보면 때때로 일일 집계 금액과 월 집계 금액에서 오차가 발생하는 것을 볼 수 있다.

	▲ 데이터 품질관리의 효과

심지어는 억 단위의 금액에서 몇 만원의 차이가 발생하는 경우 담당자는 이 금액을 확인하기 위하여 검증을 위한 또 다른 몇 개의 프로그램을 작성하고 또 며칠 간의 데이터 검증을 통하여 문제가 되는 금액을 찾곤 한다. 그러나 이러한 작업은 누구에게도 이야기 하고 싶지 않은 일이기도 하다.

우리는 집계를 계산하기 위하여 기간을 지정하여 기간 내의 금액의 합계를 계산하게 된다. 당연히 금액이 정확해야 하지만 금액이 틀린 경우도 당연하다고 생각되는 경우가 더 많다. 우리는 데이터 오류를 방지하기 위하여 많은 라인을 할애하여 프로그램을 작성하기도 하지만 예외를 처리하기 위하여 또한 많은 라인을 할애하는 경우도 있다.

예를 들어 전체 직원의 숫자와 부서별 직원의 숫자, 급여를 지급하는 직원의 숫자는 생각처럼 항시 일치하지는 않는 경우가 많다. 영업 시스템에서 집계하는 매출과 회계 시스템에서 집계하는 매출 또한 일반적으로 같지 않다. 데이터의 오류, 시스템의 오류로 볼 수도 있겠지만 예외 처리로 인한 오차나 보는 관점에 따른 오차가 발생하는 것이다. 이러한 오차는 시스템간의 데이터 전송을 하는 과정에서 예외 사항에 대한 반영을 완벽하게 처리하지 못하는 경우 더욱 큰 오차를 발생하게 된다.

최근 들어 점점 중요성이 확대되는 무엇
과거 한 개의 시스템에서 모든 업무를 수행하였던 경우 이러한 문제가 큰 불만 사항으로 나타나지는 않았다. 그러나 매년 새로운 프로젝트를 진행하면 메인 업무에서만 사용하던 정보를 타 시스템으로 제공하게 되고 다시 이 정보가 새로이 구축되는 시스템으로 이동하게 되면서 점점 오차의 범위가 커지게 되고, 맨 뒤에서 시스템을 개발하는 담당자는 몇 개의 시스템의 프로그램을 분석해야만 원인이 되는 인자를 확인하게 될 것이다. 단지 하나의 자료에 대한 정합성을 확보하기 위하여 너무나 많은 시간과 인력을 소비해야 하는 과정을 거쳐야 하는 것이다.

수작업이 많았던 시절, 대부분의 오차는 수작업자의 실수에서 발생하는 경우가 많았으므로 전산에 의한 오차는 커다란 문제가 되지 않았다. 그러나 이제는 수작업 없이 모든 작업이 자동으로 생성되고 집계되고 다음 시스템으로 전달되어 활용되는 과정을 수작업 없이 진행이 되고 사용자는 최종 시스템에서 집계만을 확인하게 된다. 많은 과정을 거치면서 아주 작은 부분의 오차가 최종 리포트에서는 아주 커다란 오차로 전혀 이해될 수 없는 정보로 변질될 수 있다.

새로운 시스템을 구축하는 개발자는 분석 단계부터 황당한 경우를 만나게 된다. 현재 시스템의 구성이나 상황에 대한 정확한 자료가 없다는 것은 어느 정도 이해할 수 있다. 그리고 현재 구성된 데이터베이스에 대한 정확한 이해를 하고 있는 사람도 많지 않다는 것도 대부분의 프로젝트에서 동일한 경우를 보았기 때문에 인정할 수 있다.

	▲ 데이터 품질관리 프로세스

그러나 새로운 시스템으로의 전환을 위한 기존 시스템의 분석은 백지 상태에서 기존 시스템의 테이블 레이아웃과 프로그램 소스를 확인해가면서 매핑 작업을 수행해야만 한다는 것은 너무나도 개발자를 힘들고 어렵게 만드는 것이다. 소스 시스템으로부터 데이터를 ETL하기 위해서도 역시 기존의 ETL 프로그램 소스를 분석해 가면서 작업을 수행하는 것이 다반사다.

더욱 황당한 경우를 만나는 경우도 있다. 기존 시스템에서 생성되어 있는 테이블의 개수는 1,000여 개가 존재하는데 모든 프로그램을 조사해도 200개만이 사용하고 있는 경우 나머지 800개의 테이블은 왜 생성이 되고 어디에서 활용되고 있는지 찾을 길이 없을 때 담당자들은 한계를 느끼곤 한다.

중요한 테이블을 발견하고 내부의 컬럼을 확인해 보면 더욱 황당한 경우가 있다. 여러 개의 컬럼 중에 금액이 들어있는 컬럼의 이름이 AMT1, AMT2, AMT3, AMT4와 같이 구성되어 있는 경우 과연 자신이 필요로 하는 컬럼이 무엇인지를 확인하기 위하여 또 다시 길고 긴 프로그램 소스를 분석해 봐야 하는 어려움을 거쳐야만 할 것이다. 

옛날 속담에 ‘대장간에 칼이 없다’는 이야기가 있다. IT 부서는 업무부서의 데이터를 관리하기 위하여 많은 비용과 인력을 들여 시스템을 개발하고 IT 담당자를 통하여 계속적인 유지 보수를 하고 있다. 그러나 IT 부서는 자신들의 업무와 관련된 정보를 어떻게 관리하고 있는지 또는 어떠한 시스템을 구축하여 관리하고 있는지 질문을 해보고 싶다. 아마도  대부분의 자료는 출력된 형태의 파일로 관리하고 있을 것이고 그것조차도 시스템 개발 완료 시에 작성한 후 한 번도 보완되지 않은 상태에서 보관되고 있는 것이 대부분일 것이다.

우리는 이러한 현상을 쉽게 찾아볼 수 있다. 아마도 IT부서 캐비닛에는 ‘XXX 시스템 완료 보고서’, ‘OOO 프로젝트 결과 보고서’ 등의 자료가 먼지에 쌓여 정연하게 진열되어 있는 것을 쉽게 확인할 수 있다. 프로젝트 완료 후에도 남아있는 개발자나 IT 담당자에 의하여 많은 부분이 수정이 되었지만 누구나 시스템의 상황에 대하여 물어보면 당연하다는 듯이 위의 보고서들을 내어놓는 것이 일반화되어 있는 실정이다.

메타 데이터의 정의
사전에서 ‘메타 데이터’라고 찾아보았다. 검색 결과는 ‘데이터에 관한 구조화된 데이터로, 다른 데이터를 설명해 주는 데이터’라고 되어 있었다. 시스템 구축 시 작성하는 문서 중 엔티티 설명서, 어트리뷰트 설명서, 테이블 설명서 등에 보면 테이블 명에도 설명이 들어있고, 컬럼 명에도 설명이 있으며, 테이블을 구성하기 위한 다양한 정보를 관리하고 있는 것을 볼 수 있다. 쉽게 풀어보면 여기서 설명되어 있는 모든 자료들이 메타 데이터의 일부라고 볼 수 있다. 해당 테이블에 저장되어 있는 정보는 데이터지만 그 테이블을 지칭하고 있는 테이블 명 역시 메타 데이터인 것이다.

우리는 기업 내에 많은 데이터베이스를 구축하여 관리하고 있으며 각각의 데이터베이스에는 수많은 테이블이 생성되어 있으며, 또한 각각의 테이블은 여러 개의 컬럼으로 구성되어 있다. 이 각각의 데이터베이스, 테이블, 컬럼에 대한 정보를 관리는 기본이고 각각의 설명, 테이블간의 연결관계, 컬럼 간의 연결관계 및 다양한 정보를 리포지토리에 저장하여 관리하는 것을 '메타 데이터 관리'라고 할 수 있다.

	▲ Master Data Management와 데이터 품질관리

메타 데이터가 정확하게 관리되고 있다면, 내가 타 시스템에서 필요한 정보가 있을 때 담당자에게 물어보는 것이 아니라 메타 데이터 관리 시스템만 찾아보면 쉽게 어디에서 어떻게 가지고 와야 하는지를 쉽게 알 수 있을 것이다. ETL 작업에서 테이블 변경에 대한 오류가 감지되었다면 누구나 쉽게 언제, 누구에 의하여, 어떻게 테이블이 변경되었는지를 알 수 있을 것이고 빠른 시간 내에 오류 작업을 복구할 수 있을 것이다.  

데이터 품질의 정의
데이터 품질관리에 대해 살펴보자. 우선 대상을 알아보면 대상은 당연히 데이터이다. 명제는 데이터의 품질이라고 볼 수 있는데 품질의 목표는 데이터를 사용하는 사용자의 만족도를 충족시킬 수 있는 수준으로 향상 시키는 작업이라고 볼 수 있다. 또 관리라고 하는 것은 한번으로 끝나는 것이 아니라 계속적으로 유지되는 것이 필요하다는 의미로 볼 수 있다. 다시 말해서 사용하고 있는 데이터에 대하여 사용자가 만족할 수 있는 수준의 품질을 계속적으로 유지할 수 있는 방안이다.

일반적으로 기업 내에서 데이터 품질에 관련된 문제가 발생할 때마다 데이터 품질 관련 컨설팅을 받은 경험이 있을 것이다. 몇 주에 걸친 작업을 통하여 전체 데이터를 확인하고, 보고서를 통해 이런 저런 자료를 보완하고 수정하라는 결과만 도출할 뿐 더 이상의 계속적인 품질을 유지하는 방안은 별로 없었다. 결국 근본적인 해결 없이 IT 운용자의 노력에 의하여 유지가 되거나 조금씩 향상되는 정도가 대부분이었다. 품질관리는 관리를 담당하는 툴을 통하여 관리가 필요한 사항을 정의하고 정의된 내용을 기반으로 계속적으로 품질을 유지할 수 있도록 관리하게 된다.

메타 데이터와 데이터 품질의 관계
메타 데이터는 데이터에 대한 정보이고 데이터 품질은 실 데이터에 관련된 부분으로 생각하면 서로 관련이 없을 것으로 보일 수 있다. 실제로 메타 데이터 관리만 진행하는 프로젝트가 있고 메타 데이터는 설명하지 않으면서 데이터 품질관리를 하겠다는 프로젝트가 있다.

물론 기업에서 관리하는 모든 데이터에 대한 정보를 구축하기 위하여 메타 데이터 관리만 하는 프로젝트는 가능하지만 메타 데이터 없이 데이터 품질 프로젝트는 존재 할 수 없다. 데이터 품질관리를 위한 분석 단계부터 메타 데이터에 대한 정보를 수집하기 시작하여 메타 데이터를 중심으로 데이터 품질관리를 수행하게 된다.

데이터 품질을 관리하기 위한 기본적인 관리의 시작이 바로 메타 데이터 관리인 것이다. 우선 기업 내에서 존재하는 모든 데이터에 대한 정보를 하나의 리포지토리에 등록하여 관리하게 되고 각각의 테이블 별, 컬럼 별로 품질관리에 필요한 정보를 툴을 통하여 동일한 리포지토리에 저장하게 된다. 품질의 대상은 물론 데이터지만 품질관리와 데이터 간의 매개체 역할을 하는 것이 메타 데이터인 것이다.

이미 이전의 많은 자료에서 데이터 품질 저하로 인한 문제점은 많이 거론되었다. 간단하게 몇 사례만 들어보기로 하자. 몇 년 전 한국과 미국의 홈쇼핑에서 동일한 문제를 발생시킨 사건이 있었다. 두 곳에서 동일하게 판매할 상품 가격에 대하여 ‘0’ 하나는 빠뜨리는 실수를 범한 것이다. 많은 고객들이 빠르게 주문을 하였고 회사에서는 급하게 제품 판매를 중지하는 사태가 벌어졌다. 미국의 홈쇼핑 회사는 이미 주문한 고객에 대해 주문한 가격에 제품을 판매해 막대한 손실을 입었고, 한국의 홈쇼핑 회사는 제품을 판매하진 않았지만 고객에 대해 사과로 회사 이미지에 막대한 영향을 주었다.

데이터 품질이 기업에 미치는 영향
다른 사례를 보기로 하자. 많은 기업들이 자신들의 고객에게 여러가지 목적으로 메일링을 하게 된다. 그러나 상당량의 메일이 다시 반송된다. 우리나라의 통계를 보면 일반적으로 1년 내에 이주하는 인구가 대도시를 기준으로 20%가 넘는다고 되어 있다. 그렇다면 5년을 넘는 주소의 대부분은 반송되는 것이 당연할 수도 있을 것이다. 기업에서는 많은 비용과 노력을 들여 메일링을 한다. 하지만 노력에 비해 데이터 품질의 저하로 인해 많은 문제를 야기시킨다.

마지막으로 대부분의 금융기관이 가지고 있는 커다란 문제점의 하나는 여러 상품에 걸쳐 하나의 고객에 대한 상이한 정보를 관리하고 있는 부분이다. 얼마 전 대출을 받으러 은행에 간 일이 있었다. 그때 그 은행의 시스템에 있는 본인의 정보는 전전 직장의 차장 때의 정보를 관리하고 있었고 동일 회사의 카드 시스템에는 전 직장의 정보를 관리하고 있었다. 아마 다른 은행에서도 동일한 형태로 관리하고 있을 것이다. 요즘 들어 가끔 거래은행에서 전화를 받게 되면 꼭 본인의 최신정보를 얻기 위한 질문을 하곤 한다. 아마도 최신 고객 정보 확보를 위한 노력이 아닌가 생각된다.

품질관리 프로젝트 현황
전체적인 상황의 변화로 보면 2005년부터 데이터 품질에 대한 관심 표명이 시작되었다고 볼 수 있다. 그 이전에는 컨설팅 중심의 데이터 품질점검이 주를 이뤘다. 점차 일회성 작업에는 한계가 있다는 요구가 커졌고 선진국을 중심으로 데이터 품질관리 툴을 통한 품질관리가 시작되었다.

	▲ Informatica Data Integration Platform

국내에서는 2006년 금융기관을 중심으로 데이터 품질 프로젝트가 태동했다. 금융기관을 중심으로 바젤 프로젝트와 같은 형태에서 데이터의 품질에 대한 요구사항이 증가하여, 본 프로젝트와 동시에 메타 데이터 관리나 데이터 품질관리 프로젝트가 진행되었다. 본격적인 프로젝트라기보다는 다른 프로젝트의 일부분으로 진행된 것이다. 지금은 대기업을 중심으로 데이터 품질에 대한 관심이 고조되기 시작, 2007년 이후에는 전사적인 차원에서 데이터 품질과 관련한 프로젝트가 여럿 발생할 것으로 예상된다.

데이터 품질관리가 필요한 경우
사람들 대부분은 아무리 좋은 제품이라도 필요 없으면 구매하지 않을 것이다. 데이터 품질관리 역시 아무리 좋은 생각과 필요성을 내세우지만 현재까지 필요성에 대한 욕구가 발생하지 않는다면, 많은 비용과 전사적인 노력이 필요한 프로젝트를 쉽사리 시작하지 않을 것이다. 더욱 중요한 부분은 데이터 품질관리를 통하여 일반 사용자에게 돌아가는 이익을 보면 단지 지금보다 자료가 조금 더 정확해질 뿐 큰 장점이 없다고 생각 할 수 있다. 따라서 많은 비용과 노력을 들이는데 적극적이지 않을 뿐만 아니라 그 일은 IT 부서의 고유의 일이라고만 생각하기 때문에 별 관심을 보이지 않고 있다.

하지만 바젤 프로젝트와 같이 데이터 품질관리가 필요한 경우가 발생한다면 비용과 노력에 관계없이 진행하게 될 것이다. 이제 데이터 품질이 필요한 경우를 알아보기로 하자.

요즈음 금융기관에서 많이 수행하고 있는 차세대 시스템 구축에 데이터 품질 프로젝트가 동시에 수행되고 있다. 두 가지 이유가 있다. 첫째는 새로운 시스템이 시작되는 단계에서부터 데이터 품질관리를 수행하게 되면 새로운 시스템의 안정적인 관리를 하는데 많은 도움을 주게 될 것이다. 두 번째 이유로는 기존의 데이터에 대한 이관 작업을 수행하는데 있어 새로운 시스템의 데이터 품질관리가 많은 도움을 주게 될 것이다.

다음으로는 바젤과 같은 경우겠지만 정보시스템 구축 시에 데이터 품질관리 프로젝트를 동시에 수행하게 된다. 일반적으로 현재의 운용계 시스템에서 데이터 품질의 문제가 발생했다면 신뢰성 있는 시스템으로의 자리를 잡을 수 없었을 것이다. 그러나 데이터 품질 문제 발생은 타 시스템으로 전이를 하는 과정에서 생각하지 못하는 문제점들이 나타나게 되어 새로 구축되는 정보시스템의 신뢰도를 무너뜨리는 효과를 발생한다.

정보시스템의 경우 품질관리가 꼭 필요한 이유 중의 하나는 데이터의 성질이 자신이 발생한 정보가 아니라 외부에서 전달 받은 정보이기 때문에 데이터의 품질에 대한 확신이 없을 경우 ETL 작업의 완전성을 보장받을 수 없을 것이다. 또한 정보시스템 대부분은 하나의 시스템에서 데이터를 추출하는 것이 아니라 다수의 시스템에서 여러 형태로 데이터를 ETL 하고 있기 때문에 일반적인 상태에서 작업을 수행하게 된다면 근본적인 데이터의 품질 보장에 한계를 느끼게 될 것이다.

마지막으로 지금도 기업 내에서는 새로운 프로젝트에 대한 계획을 세우거나 수행을 하고 있다. 대부분의 시스템은 자체적으로 데이터를 발생하고 소멸시키는 경우는 거의 없이 외부에서 데이터를 추출하거나 외부로 데이터를 전이하는 작업을 수행하게 된다. 우선은 작은 부분부터 데이터 품질관리 프로젝트를 수행하는 것이 접근적인 방법에서 쉬운 방법이며 또한 새로이 구축되는 시스템과 해당 시스템과의 연계가 되는 시스템부터 시작하는 것이 좋을 것이다.

이러한 부분은 데이터 통합 측면에서 데이터의 품질관리 프로젝트 형태로 시작하는 것이 바람직해 보인다. 시스템 구축 방법의 한 축인 상향식(bottom-up) 방식으로 작은 부분에서 시작하여 효과를 확인하고 다시 전사적인 측면에서 차츰 프로젝트를 확대하는 것이 적응력을 키우는데도 효과적인 것이다.

데이터 품질 프로젝트 방안
우리는 많은 기업에서 ERP 프로젝트를 수행하는 것을 보았다. 대부분의 프로젝트가 성공이었다고 하고는 있지만 실제적으로 성공적이지 못한 프로젝트도 있었다. 동일한 산업군의 기업이 동일한 ERP 패키지를 이용하여 프로젝트를 수행하였는데 성공과 실패가 나뉘는 경우가 있는 것이다.

프로젝트가 실패하는 데는 많은 요인과 원인이 있다. 가장 큰 원인으로 꼽을 수 있는 것은 전사적 자원관리(ERP) 프로젝트의 성격을 해당 기업의 업무를 패키지에 적용시키는 방향으로 추진한 경우와, 컨설팅을 통해 기업의 프로세스를 최적화하고 최적화된 결과를 패키지에 적용시킨 경우의 차이가 가장 많았을 것이다.

마찬가지로 데이터 품질관리 프로젝트의 성격을 보면 우선은 컨설팅을 통한 데이터 품질의 방향과 만족할 수 있는 수준을 확정하는 것이 가장 중요한 성공의 요소라고 볼 수 있으며 이 결과를 기준으로 툴의 기능을 최대한 활용해 프로젝트를 진행하는 것이 방안이다.

우리는 여기서 기장 기본적인 이야기인 윗선의 전폭적인 지지가 필요하다든가, 프로젝트의 성공을 위해 조직의 구성이 잘되어야 한다는 이야기는 필요 없을 것이다.

데이터 품질관리 이전에 해야 할 사항
데이터 품질관리 프로젝트를 수행하는데 꼭 필요한 사항과 품질 향상에 도움이 되는 몇 개의 프로젝트가 있다. 우선 꼭 필요한 사항으로는 앞에서 이야기한 데이터 품질관리를 위한 컨설팅을 수행하는 것이다. 우리는 이 컨설팅을 통해 몇 가지 사실을 확인하게 될 것이다.

우선은 몇 주에 걸친 실사 확인을 통하여 기업 내에서 존재하는 데이터 품질의 수준을 짐작하게 될 것이다. 많은 경우 우리가 생각하지 못한 심각한 판정을 받을 수도 있을 것이고 많지는 않지만 좋은 결과를 얻을 수도 있을 것이다. 우리는 이 결과를 기초로 앞으로 수행하게 될 데이터 품질의 목표를 설정할 수 있을 것이다. 우리의 현실과 목표의 차이가 우리가 수행할 프로젝트의 범위인 것이다. 그렇기 때문에 목표의 설정은 현실적인 상황으로 주어진 기간, 비용, 인력을 고려하여 설정해야 할 것이다. 역시 목표가 너무 높으면 구현 시점에서 많은 어려움을 겪게 될 것이다.

데이터 품질과 관련한 컨설팅 업무의 범위를 대부분 여기까지로 생각하는 경우가 있지만 또 하나 중요한 임무가 남아 있다. 설정된 목표에 해당하는 데이터를 중심으로 표준화를 만드는 부분이다. 차세대 시스템으로의 이전과 같은 경우는 표준화를 구축하는 것이 시스템 구축의 목적과도 일치하여 쉽게(?) 진행할 수 있겠다. 하지만 작은 시스템에서 시작하는 경우나, 정보계 시스템 구축에서 표준화를 하는 것은 결코 쉬운 일이 아니다.

그러나 데이터 품질관리는 처음에는 작게 시작할 수 있지만, 전사적인 관점에서 접근하여 방향을 세우고 표준화를 구축하는 것이 이후 프로젝트를 수월하게 진행할 수 있는 기준점이 될 것이다. 이러한 표준화를 구축하는 시점까지가 중점적으로 데이터 품질 관리 프로젝트를 수행하기 이전에 필요로 하는 컨설팅의 요소가 될 것이다.

데이터 품질관리와는 별 관계가 없을 것으로 보이지만 아주 중요한 프로젝트가 있다. ‘컴퓨터월드’ 9월호에서 자세하게 설명하겠지만 최근 들어 중요한 프로젝트로 인식되고 있는 MDM(master data management) 프로젝트가 데이터 품질관리 프로젝트를 위해서는 기반이 되는 중요한 프로젝트다.

MDM 프로젝트는 꼭 필요한 프로젝트는 아닐지라도 MDM 프로젝트가 잘 구축되어 있다면 데이터 품질 관리 프로젝트를 수행하는데 아주 중요한 역할을 수행하게 될 것이다. MDM 프로젝트의 중요 요소는 기업 내에서 관리되는 정보 중에서 공통적으로 사용되고 관리되는 모든 정보를 통합하여 관리하는 프로젝트다.

예를 들어 고객 정보의 경우 대부분의 시스템에서 관리되고 사용되고 있을 것이다. 그러나 이러한 고객의 정보가 다수의 시스템에서 관리되고 있으므로 데이터의 정합성을 관리하는 것에 한계가 있을 것이고 이 한계는 데이터 품질 관리의 성공적인 완료에 많은 어려움을 야기시킬 수 있다.

데이터 품질관리의 성공적인 완료를 위한다면 미연에 위험 요소를 방지하기 위한 작업이 필요할 수도 있을 것이다. 우선은 컨설팅을 통한 데이터의 표준화 방안이 설정되었다면 이 방안을 기반으로 공통적으로 관리되고 있는 정보에 대한 통합 방안을 마련하는 것이 필요할 것이다.

경우에 따라서는 이 프로젝트만으로도 많은 기간이 필요한 프로젝트일 수 있을 것이다. 그러나 가능하다면 대체적인 형태로 표준화된 통합 방안을 마련하고 완벽한 MDM 프로젝트는 아니더라도 전체 통합된 공통 데이터를 관리하는 방안을 수립하는 것이 데이터 품질관리의 완전성을 높이게 될 것이다.

인포매티카의 데이터 품질 방안
본격적인 프로젝트를 수행하기 위하여 우리는 우선 앞에서도 설명한 바와 같이 현재 시스템에서 관리하고 있는 모든 데이터 관련 정보를 수집하고 툴을 통하여 관련되는 모든 메타 데이터를 저장공간에 저장하는 작업을 수행해야 한다. 데이터 품질 관리를 위하여 메타 데이터를 관리해야 한다는 것은 아주 중요한 일이다. 여기에서부터 본격적인 데이터 품질관리가 시작되는 것이다.

	▲ 데이터 품질관리 프로세스 Diagram

인포매티카는 데이터 통합의 모든 단계, 데이터를 추출하는 과정에서부터 목표에 데이터를 저장하는 단계 가운데 데이터를 검증하는 과정과 크린징하는 과정을 포함하여 데이터 품질관리 기능을 제공하고 있다. 데이터를 추출하는 과정에서는 파워익스체인지와 파워센터를 통하여 소스 시스템의 형태에 관계없이 소스 시스템으로부터 메타 데이터를 자동으로 추출하여 통합 리포지토리에 저장 관리하게 된다.

통합 리포지토리에 관리되는 정보를 기반으로 데이터를 추출하게 되면 데이터 익스플로러를 통하여 데이터의 프로파일링 작업을 수행하게 된다. 이 과정에서 데이터의 유의 수준을 점검할 수 있으며 데이터 퀄리티를 통하여 문제가 발생한 데이터의 크린징 작업을 수행한다. 우리가 원하는 수준에 도달한 데이터는 파워센터를 통하여 목표 시스템의 데이터베이스로 안전하게 저장될 것이다.

이제까지 데이터 품질관리의 필요성과 성공적인 프로젝트를 위하여 우선적으로 해야 할 일을 점검해 보았다. 프로젝트 수행을 위한 상세한 방법론은 프로젝트에 참여하는 컨설팅 회사나 개발회사에서 그들의 방법론을 통하여 성공적인 데이터 품질관리 프로젝트가 성공적으로 수행될 수 있도록 최선을 다할 것이다.

후기; 이번 글을 쓰면서 스스로를 많이 돌아보고 더 겸손해져야겠다는 것이 필자가 얻은 큰 소득이다. 연재를 시작할 당시엔 그냥 필자가 알고 있는 부분을 정리만 하면 될 것으로 생각했다. 하지만 매달 돌아오는 마감 일자의 부담감은 한 회가 완료되는 시점부터 다가왔다. 아직도 부족한 것이 너무 많구나 하는 생각이 들기도 하며 필자의 글을 읽는 독자에게 혹시나 잘못된 정보가 제공되는 것은 아닌지, 단지 시간 낭비를 하는 것이 아닌지 걱정이 되기도 했다. 이글이 IT 세계에서 같이 살아가고 있는 모든 분들에게 조금이나마 도움이 되었다면 그간의 고통은 커다란 보람으로 남을 것이다.