DW 구축 사례를 통한 데이터 통합의 이해

DW 구축 사례를 통한 데이터 통합의 이해

윤성호 | 엔코아정보컨설팅 책임 컨설턴트

정보와 데이터는 전혀 다른 의미를 갖고 있다. 현 시대를 정보의 홍수라 말하지만 사실은 자신과 전혀 상관 없는 데이터가 넘쳐 흘러난다. 이 중에서 자신에게 꼭 맞는 정보를 찾기에 많은 시간과 노력을 소모하고 있는 셈이다. 특히 기업에서는 데이터 통합이 부각되고 있으며, 데이터에 진정한 가치를 부여하기 위한 하나의 요건으로 받아들여지고 있는 데이터 웨어하우스 구축의 필요성이 높아지고 있다. 이 글에서는 데이터 통합의 필수품처럼 여겨지는 데이터 웨어하우스 구축 방법을 살펴보며, 데이터 통합의 중요성을 생각해보도록 하자.

필자는 과거 XX기업의 ‘종합 정보시스템 구축 프로젝트’에 참여한 적이 있다. 왜 XX기업은 이러한 프로젝트를 진행하려고 했을까? 이곳 역시 다음과 같은 질문과 해답의 목마름을 해소하고자 하는 많은 기업들 중 하나였다.

① 제품별로, 대리점별로 혹은 지역별로 당월 목표를 달성했는가?
② 신제품은 모든 지역에서 적절한 비율로 판매됐는가?
③ 신제품 중에 목표치에 미달한 제품이 있는가? 그렇다면 이 제품은 폐기되어야 하는가?
④ 판매 그룹 사이에 평균 할인율은 어떠한가? 이러한 평균 할인율을 반영하도록 수수료 구조가 조정되어야 하는가?
⑤ 인구 통계적 특성이 유사한 대리점들 사이에 차이가 있는가? 차이가 있다면 이러한 차이는 왜 발생했는가?

XX기업은 ‘풍요 속의 빈곤’

XX기업은 지난 수십 년 동안 축적해 온 대량의 데이터에서 사용자의 의사결정에 필요한 중요 정보를 산출하기 위해 여러 방법들을 시도해왔다. 하지만 ‘풍요 속의 빈곤’이란 말처럼 정보의 수집·공유·분석·의사결정을 원활하게 도와주기엔 데이터들이 너무나도 여러 시스템에 분산되어 있었다. 각 부서별로 수집·운영되는 데이터는 다른 부서에서는 참조할 수 없을 정도로 격리되어 있었으며, 이 때문에 중복된 데이터는 데이터의 무결성이 전부 깨져 있는 상태로 존재하고 있었다. 또한 상이한 DBMS 시스템들이 혼재되어 있었으며 데이터를 움직이고 있는 애플리케이션 플랫폼도 매우 다양했다.
XX기업에서는 지금과 같은 상황으로는 더 이상 ‘기업 지능’, 바로 정보기술을 효과적으로 사용할 수 없다는 판단에 이르렀다. 각 시스템의 호환성 문제와 저장되어 있는 과거 정보를 사용자가 원하는 상태로 바로 복구할 수 없다는 것, 그리고 다양한 시스템에 흩어져 있는 현재의 데이터를 취합하고 이 데이터들을 능숙하게 조정할 수 없었다. XX기업의 상황을 분석해보면 다음과 같다.

◆ XX기업의 현실
① XX기업의 전통적 발전과정에서 데이터는 개별적으로 프로세스를 자동화하기 위해 단위 부서들의 필요에 의해 만들어졌다. 이 때문에 데이터와 애플리케이션이 밀접하게 연계됐으며, 비효율적이고 비용이 많이 드는 다수의 중복된 데이터가 여러 시스템에 유사한 데이터 개체로 저장되어 있다.

② 각각의 부서에서 개발한 정보시스템은 단지 해당 부서 내에서만 사용되는 정보의 격리 현상이 위험 수준으로, 타 부서에서는 참조조차 못하는 상황이다.

③ 각각의 시스템들은 데이터를 수집하는 기간에 차이가 있으며, 보고서 생성 기간에서도 차이가 있다. 이로 인해 서로 다른 시기의 데이터가 공존하고 있다.

④ 시스템간에 계산 방법이 서로 상이하다.

⑤ 데이터의 원천이 서로 다르고, 이러한 결과로 추출 단계마다 문제점이 계속해 증폭되고 있다.

⑥ 필요한 데이터의 위치를 파악하기 어렵다. 여러 파일과 테이블이 검토될 필요가 있다.

⑦ 데이터 추출 및 변환시 복수개의 프로그램을 거의 매번 다시 작성해야 하며, 다양한 환경에 존재하는 데이터를 사용자가 다뤄야 하는 생산성과 관련된 문제가 있다.

⑧ 몇 년 동안 무계획적으로 이뤄진 시스템 성장의 결과, 서로 호환되지 않는 별개의 데이터베이스들과 수없이 많은 종류의 언어로 만들어진 애플리케이션 플랫폼으로 개발돼 보고서 하나 만들 때에도 엄청난 양의 프로그램 코드를 컴퓨터에 쏟아넣어야 겨우 작성할 수 있다.

XX기업의 전사적 정보 통합 작업인 ‘종합 정보시스템 구축 프로젝트’가 진행될 수밖에 없는 이유였으며, 이 중에서 데이터 통합이란 목적을 위해 ‘데이터 웨어하우스(이하 DW) 구축’이 절대절명의 과제로 떠오를 수밖에 없었다. 이 글에서는 데이터 통합의 이슈가 왜 발생하며, 그에 따른 DW 구축이 무엇을 해결하는지 DW 구축사례를 통해 이해해 보도록 하자.

데이터 웨어하우스의 정당화

XX기업이 DW 구축을 통해 얻을 수 있는 것은 많다. 특히 DW는 업무 사용자들의 의사결정 지원에 전적으로 이용되는데, 올바른 정보와 형태로 적시에 의사결정에 도움을 제공할 수 있는 엔진을 XX기업 정보시스템에 장착할 수 있었다.
기존 대부분의 운영시스템은 항상 많은 데이터가 중복됨으로써 하나의 사실에 대해 다수의 버전이 존재했다. 하나의 객체를 지칭하는 다양한 이름이 존재하거나 데이터가 갖는 의미가 서로 다르다는 것이다. 하지만 DW에서는 이러한 데이터가 전사적 관점에서 통합돼 DW는 신뢰할 수 있는 하나의 버전(One version of truth)을 사용자에게 제공할 수 있었다.
DW 내의 데이터는 주로 운영시스템으로부터 공급되지만 다양한 외부 정보의 통합 역시 매우 중요하다. 기업조직 바깥에서 일어나는 것에 대한 정보를 말하는데 경쟁사에 대한 정보, 공급사에 대한 정보·시장·정치·경제에 대한 정보 등 다양한 외부정보를 DW 내에 효과적으로 통합해 경영자의 전략적 의사결정에 많은 도움을 줄 수 있다. 또한 ‘이력 관리’가 있는데, 이력 데이터는 기업정보에 있어서 살아 움직이는 것과 같은 존재이다. 우리가 관리하고자 하는 운영시스템의 데이터는 시간의 흐름에 따라 발생한 과거와 현재의 데이터를 지속적으로 유지·관리가 필요한데 DW는 시간성 혹은 역사성을 지니고 있으므로 장기간의 데이터를 갖고 있게 되어 데이터의 이력을 정확히 관리·확인할 수 있다.
기존의 XX기업의 데이터베이스는 대부분 애플리케이션의 일부분이었다. 즉 운영시스템은 재고 관리, 영업 관리 등과 같은 기업 운영에 필요한 특화된 기능만을 지원했는데, DW를 통해 고객, 제품 등과 같은 주요한 주체를 중심으로 그 주체와 관련된 데이터들을 활용할 수 있었다.
XX기업의 관리자들과 분석가들은 즉각적이고 신속하게 자신의 PC로부터 DW에 접근할 수 있게 됨으로써 컴퓨터 시스템에 지식이 없는 사용자들이 쉽게 접근할 수 있게 됐다. XX기업 정보시스템에 다수의 DSS(Decision Support System)를 지원해 운영 데이터의 변형과 통합을 통해 의사결정자의 생산성을 향상시키고, 기업의 통일된 관점을 제공했다.

정말 DW를 구축했나요?

웬만한 기업이라면 자신들도 DW를 구축해 적용하고 있다고 말한다. 하지만 그 내부를 조그만 파고들어가 보면 그저 말뿐이라는 것을 알 수 있다. 단지 다량의 데이터를 액세스해야 생성할 수 있는 분석 자료를 OLTP에서 처리하기에는 부담이 되기 때문에, 다른 서버로 혹은 테이블에 데이터를 임시로 보관한다는 의미에 지나지 않는다. 그럼 XX기업의 DW 구축과정을 살펴보며 데이터 통합이 왜 중요한가를 생각해보자.

DW 구축의 원칙은 통합, 단순, 장기

XX기업의 ‘종합 정보시스템 구축 프로젝트’의 목적은 업무 수행시 이를 이용하고 공유할 수 있는 전산 환경을 제공하고, 업무를 수행하며 생성된 각종 데이터 및 자료를 업무 담당자가 직접 가공하고 분석하며, 분석자료를 경영진과 외부기관에 제공할 수 있는 전산 환경을 구축하는 데 있었다. 이중 XX기업의 전략정보시스템에서 기업 핵심 업무를 대상으로 DW를 구축하는 것을 그 목표로 했다.
DW의 기본 원칙은 ‘통합’, ‘단순’, ‘장기’라 하겠다. 기업이 필요한 정보를 분석하기 위한 소스와 데이터를 얼마나 체계적이고 효율적으로 관리할 수 있느냐에 대한 문제는 전적으로 DW 구축의 핵심 요소이다. 그러나 다량의 정보 소스는 OLTP에 너무나 넓게 분산되어져 있었고 그들 간의 관계는 잘 드러나지 않기 때문에 이를 명확하게 분류하고 잘 배치한다는 것이 우리에게 쉽지 않은 과제였다. 또한 대용량의 데이터를 처리해야만 한다는 점과 DBMS에게 많은 것을 맡겨야 하는 DW의 특수성 때문에 최대한 단순하고 명료해야 한다는 것도 적지 않은 부담이었다.

XX기업의 DW 구축

첫 단추는 업무분석

DW를 구축함에 있어 첫 단계로 전략 정보로 이용할 만한 가치가 있는 데이터의 후보를 수집했다. 기존 운영계 시스템의 통계 정보, 업무 규정집, 각종 보고서와 같은 문서들을 취합해 검토하고 필요시 현업 부서 및 전산 담당자와의 인터뷰를 통해 기업의 전반적인 업무를 이해하고, 이 중 전략 정보로 활용할 만한 가치가 있는 데이터를 식별하는 과정이었다.
이 분석 과정에서 파악한 것은 진정한 고급 정보는 단기간이 아닌 오랜 시간에 데이터를 숙성하고 활용해야만 얻을 수가 있다는 것이다. XX기업의 일반 분석 정보는 앞으로 나타날 논리적으로 존재할 수 있는 모든 의미의 정보에 비하면 극히 일부분에 지나지 않았다. 사용자들은 시간이 흐르면서 더욱 종합적이고 고난이도의 분석 정보를 원하게 될 것은 분명한 사실이기 때문이다.
또한 스테이징 영역에 저장해 놓은 데이터를 활용한다는 접근 방식은 필요한 것만 선별해 만들었기 때문에 기업 전체적인 ‘통합’의 원칙에 위배된다. 이로 인해 날이 갈수록 새로운 요구를 반영하려는 노력의 일환으로 자꾸만 중복된 데이터 집합을 생성하게 되는데, 이로 인해 ‘단순’의 원칙도 지킬 수 없는 것이다. 또한 장시간 숙성시켜 유용하게 쓰여야 할 데이터들이 백업과 함께 사라져 버리고 있기 때문에 ‘장기’의 원칙도 무시된 것이었다. 결국 당장은 사용자들이 원하는 것들을 어렵지 않게 제공할 수는 있겠지만 나중에는 혹독한 대가를 지불해야 하는 시기가 올 것이라는 판단을 내렸다.

운영계 리버스 모델링

DW는 데이터가 생명이다. 이 데이터들은 저절로 만들어지는 것이 아니라 OLTP를 기반으로 생성될 수밖에 없다. DW의 원천이 되는 OLTP를 완벽하게 알지 못하고 만들어진 DW는 결코 정상적인 모습을 하고 있을 수 없다. 이에 운영계 리버스 모델링을 정밀하게 모델링했다.
DW 구축을 위한 운영계 리버스 모델링은 운영계 데이터베이스의 구조 정보 및 운영계 시스템 분석ㆍ설계 산출물을 근거로 해 전형적인 데이터 모델링 산출물인 ERD(Entity Relationship Diagram)를 도출하는 작업이다. 그 목적은 운영계 데이터 모델 및 물리적 데이터베이스의 구조를 이해하고, 운영계 데이터 모델을 도출해 기업의 전반적인 업무 내용을 정확히 숙지할 수 있으며, ODS(Operational Data Store) 모델링의 방향 정립이 가능하고, DW 구축을 위한 운영계 시스템 변경 요소를 파악할 수 있기 위해서다.
XX기업의 현행 운영계 시스템의 분석ㆍ설계 산출물이 순수하게 데이터 관점보다는 객체지향적인 관점에서 이뤄져 있어 클래스 다이어그램 또는 오브젝트 다이어그램만으로는 관계형 데이터베이스 관점의 데이터 모델을 효과적으로 표현하지 못하는 부분이 존재했다. 이를 보완한다는 측면에서 리버스 모델링을 실시했다. 또한 운영계 리버스 모델링 작업의 본래의 목적은 아니지만 운영계 데이터베이스의 물리적인 테이블들간의 관계를 명확히 파악해보기 위해 RI(Referen tial Integrity) 체크를 실시하게 됐다. 이 과정을 통해 데이터베이스의 구조적 관점에서의 오류 데이터를 식별할 수 있으며, 한편으로는 운영 중에 미처 발견하지 못한 운영계 프로그램 오류를 발견할 수도 있었다.

◆ 역공학(Reverse Engineering) : 개발 단계를 역으로 거슬러 올라가 기존 개발된 시스템 코드나 데이터로부터 설계 명세서나 요구 분석서 등을 도출해내는 작업

<그림 1> 기존 운영계 시스템의 특징


<그림 2> DW 프레임워크


<그림 3> 리버스 모델링 그림

DW의 아키텍처 구축

DW의 기반이 되는 OLTP의 모든 데이터에 대해 매우 상세한 아키텍처를 수립하고 이를 바탕으로 모델링한 DW 아키텍처 또한 상세하게 수립됐다면, 이들 간에는 ‘집합과 집합’간의 매핑 룰(Mapping rule)이 존재하게 된다. 이 매핑 룰이 바로 ETL(Extraction, Transfor mation and Loading)의 알고리즘이 된다.
OLTP 집합과 DW 집합은 데이터의 집합으로써 이들 간의 전환은 ‘집합간의 매핑’으로 볼 수 있는 것이다. 이것을 DB 마이그레이션을 할 때 적용해 왔던 공식처럼 사례별(Case-by-case)로 다뤄 알고리즘을 생성한다면 그 경우의 수는 엄청나게 많이 발생하고, 오류나 누락이 증가한다. 뿐만 아니라 OLTP 설계에 변화가 발생했을 때 유지 보수를 하는 일도 매우 어려워질 것이라 판단됐다.
또한 리버스 모델링 후에 ODS 모델링 및 ETT 프로그램을 개발했는데, 운영계 시스템에 대한 리버스 모델링을 통해 확인된 운영계 데이터 모델 및 데이터베이스의 물리적 구조를 바탕으로 해 ODS(Operational Data Store)를 설계하고 운영계 데이터베이스로부터 데이터를 추출ㆍ가공해 ODS 데이터베이스화할 수 있는 기능을 갖춘 ETT(Extraction, Transformation & Transportation) 프로그램을 작성했다.
운영계 데이터베이스를 구성하는 데이터 항목들 중에서 전략정보로 활용할 만한 가치가 있는 것들, 즉 차원(Dimension)으로 활용될 항목들과 사실(Fact, 또는 Measurement. 이하 Measurement라 함)로 활용될 항목들을 선별하고 이를 전략정보로 쉽게 활용할 수 있는 데이터로 구조화한 것이 ODS이다. 그러므로 ODS는 다음과 같은 정보 요건을 만족할 수 있도록 설계해야 한다.

• 운영계 데이터베이스 항목들 중에서 전략정보로 활용되고 있거나 향후 활용될 가능성이 있는 항목들을 모두 포함
• 시계열 분석이 가능하도록 이력 데이터 관리
• 전략정보로 쉽게 활용될 수 있는 구조

이상과 같은 요건을 갖춘 ODS 모델이 설계되면 운영계 데이터베이스로부터 데이터를 추출·가공·이관해 ODS 데이터화하기 위한 ETT 프로그램을 작성했다. XX기업의 전략정보시스템을 구축하고 있는 그 시점에는 DW가 이미 기업의 보편적인 시스템으로서 자리매김하고 있었기 때문에 이를 지원하기 위한 각종 기술 및 솔루션도 발표되고 있었다. 이중 ETT 툴도 예외 없이 이미 시장에 다수 출시되어 있어 이를 활용해 ETT 프로그램을 작성할 수 있었으나 ETT 툴이 갖는 다음과 같은 단점으로 인해 이번 DW 프로젝트에서는 순수 SQL만으로 ETT 프로그램을 작성했다.

◆ 툴이 갖는 기능의 한계 : 툴은 일반적으로 특수 목적용으로 개발되므로 다양한 형태로의 응용에 제한이 있어서 ETT 로직이 복잡하거나 다중 절차에 의해 처리되는 경우에는 적용하기 어렵다.

◆ 성능 개선 여지의 한계 : ETT툴은 일반적으로 SQL을 사용하지 않고 자체 언어를 이용해 ETT 프로그램을 작성하도록 되어 있고 자체 언어를 툴이 해석해서 SQL을 생성해 데이터베이스를 접근하므로 성능에 문제가 발생할 경우 이를 제어하기에 한계가 있다

◆ 툴 자체 언어 사용으로 인한 기술 인력의 부재 : ETT 툴에서 정의하고 있는 자체 언어는 범용적인 프로그래밍 언어가 아니므로 이 언어를 습득하는 데에 시간이 소요되며 고급 기술인력 수급에도 문제가 있다

ODS 데이터는 운영계 데이터보다 늦게 반영을 하는데 운영계 데이터의 변동사항들을 실시간으로 ODS에 반영하는 것이 이상적이기는 하지만 운영계 시스템 성능에 막대한 영향을 미칠 수 있으므로 운영계 시스템 가동이 정지되고 운영계 시스템의 각종 일괄처리 프로그램까지 수행이 완료된 이후에 ODS로 데이터를 이관하는 방법을 취했다. 이와 같은 방법으로 운영계 데이터의 변동사항들을 ODS에 정확하게 반영하기 위해서는 운영계 데이터 변동사항에 대한 time-stamp 기록을 유지하고 있어야 하며, 운영계 데이터에 대한 삭제는 기본적으로 허용되어서는 안 된다는 법칙을 갖고 운영되어야 한다.

데이터 정제

XX기업의 DW 구축에서 가장 우리를 괴롭히는 것 중의 하나는 소스 데이터의 오류를 어떻게 말끔하게 정제(cleansing)할 수 있는가에 대한 문제였다. 이 때문에 우리는 DW의 데이터 원천이 되는 운영계 데이터의 문제점을 발견하고 이를 바로 잡는데 많은 정성을 기울였다. 거의 이 과정에서 프로젝트의 전체 공정 중 45% 이상의 자원이 소요됐다. 그만큼 중요하지만 프로젝트 수행자가 스스로 밝히려 하지 않으면 문제는 드러나지 않기 때문에 이 과정은 프로젝트 수행자들의 인간성, 도덕성이 그대로 나타난다고 해도 과언이 아니다. 데이터를 정보(information)로 재창출하기 위해서는 데이터가 신뢰할 만해야 한다. 수많은 데이터 중에서 단 하나의 데이터 건이라도 잘못되어 있다면 자칫 정보로서 활용할 수 없는 지경에 이르기도 한다. 그러므로 운영계 데이터 중 전략정보로 활용할 가치가 있는 후보 항목들에 대해서는 업무 처리규정이나 데이터 모델 상의 각종 정의대로 데이터가 발생되고 있는지 확인하고 잘못된 데이터에 대해서는 그 원인을 밝혀내야 한다. 원인이 단지 과거 운영계 시스템으로부터 이관하는 과정에서 발생한 것이라면 기존 데이터 수정으로 간단히 해결할 수 있지만, 현행 운영계 시스템에 의해 발생한 것이라면 데이터의 수정과 관련 프로그램의 수정은 물론 데이터 모델의 구조도 재설계해야 하는 경우도 있을 수 있다. <그림 4>는 데이터 정제의 흐름을 도식화한 것이다

<그림 4> 데이터 정체의 흐름

목적 시스템의 구축

이제 많은 노력을 기울여 체계적인 모습으로 잘 정비된 DW는 이 데이터 소스로부터 생성하는 다양한 목적 시스템(Data Mart, 각종 전문가 시스템 등)으로 데이터를 공급하게 된다. 일반적으로 이런 유형의 시스템은 매우 다양하게 존재하고, 앞으로도 계속적으로 증가하는 특성을 갖고 있다. 물론 이러한 시스템을 제대로 활용하도록 하는 것이 바로 DW를 구축하는 본래의 목적인만큼 갈수록 확대되어야 하는 것은 당연하다. 물론 데이터 마트를 설계하기에 앞서 XX 기업의 전략정보를 구성하는 dimension과 measurement를 확정해야 한다. Dimension과 measurement는 DW 시스템을 통해 보고자 하는 사용자 관점의 정보이기 때문에 이를 확정하기 위해서는 XX기업의 정보관리실 및 관련 현업의 역할이 중요했다. 관련 현업의 의견을 최대한 수렴해 dimension과 measurement를 확정하고 이 둘 간의 연관성을 결정해야 한다.
결국 데이터 마트는 관련 현업의 의견이 집약된 dimension과 measurement, 그리고 이 둘간의 연관 관계를 데이터베이스로 표현하는 것이다.
앞에서 데이터 통합의 관점에서 살펴본 DW의 주요 구축사례를 살펴봤다. 기업의 미래가 어떻게 될 것인가는 경영자들, 관리자들 그리고 많은 현업의 업무 담당자들이 매순간마다 내리고 있는 ‘결정과 선택’에 달려 있는 것이다. 이 구축사례에서 강조한 것처럼 DW는 결국 데이터를 다루고자 하는 시스템이므로 OLTP와는 달리 유능한 데이터 전문 인력 위주로 구축하고, 관리하는 것이 바람직하다고 생각한다. 대용량의 데이터를 다양하고 복잡한 가공을 통해 높은 가치의 정보를 생성해야 하기 때문인 것이다.

XX기업의 DW를 구축하면서 고민했던 점

XX기업의 DW 프로젝트에서 고민했던 점은 무척 많았다. 그것을 정리하면 다음과 같다.

① 전사적인 통합 데이터 모델
- 모든 부문을 통합한 데이터 인프라 구축이다.
- 전략적이고 장기적인 차원에서 최대의 자원인 데이터를 보존해야 한다.

② 정보 활용 측면에서 새로운 집합을 창조
- 버릴 것과 취할 것을 어떻게 결정할 것인가?
- 어디까지가 정보 활용 차원에서 데이터 소스인가?

③ 무한한 사용자 요구를 만족
- 정보 활용에 대한 사용자 요구는 미리 다 찾아낼 수 없다.
- 정보 활용 사용자는 매우 넓게 산재하며 이를 종합적으로 예측하고 설계할 수 있는 사람은 극소수이다.

④ 대용량 데이터를 관리
- DW 데이터는 천문학적 용량이다.
- 대용량 데이터를 완벽하게 다룰 수 있는 사람은 극소수에 불과하다.

⑤ 정보 요구가 증가하면서 데이터 모델은 점차 복잡해지고, 데이터 량은 천문학적으로 증가하고 있다.

또한 프로젝트의 장애요인을 정리해보면 다음과 같다. 하나는 기술적인 요인, 다른 하나는 기업 문화적인 요인이다. 특히 기업 문화적, 정치적 이슈로 인한 장애요인은 데이터 통합 관점에서 바라본 DW 구축을 힘들게 하는 요인이었다. 왜 여기에서 이런 문제를 짚고 넘어가야 하는지 필자도 고민을 많이 했지만 한 기업의 DW 구축뿐만 아니라 우리나라의 IT 프로젝트의 전체적인 문제점이라 생각했기 때문이다. 또한 이 장애요소는 우리가 애타게 구축하려 노력했던 데이터의 통합이 쉽지 않은 이유도 포함되어 있는 것이다.

① 의사결정용 부서 단위 시스템에 이미 투자한 사업부서에서는 DW가 단지 시스템을 다시 중앙집중화하는 것으로 간주한다.
② 부서 내의 데이터를 자신의 책임 하에 관리했던 부서장은 영역을 침해당하는 기분을 느낀다.
③ 전통적인(한국적 관습) 측정 방법은 DW의 효과를 측정하기가 어렵다.
④ 경험적·육감적이며 직관적인 의사결정을 해왔던 경영진에게 DW로 인한 변화는 거부감을 줄 수 있다.
⑤ 운영시스템 데이터의 소유자들(관리 책임자)은 그들이 보유한 소스 데이터 부분에 대하여 절대적인 주인행사를 하려한다.
⑥ 운영시스템의 개발자는 DW가 그들이 제공할 수 없는 기술 유연성을 요구하는 괴물이라고 생각한다.

DW는 어느 방향으로 가야하는가?

왜 기업에서 이러한 DW를 구축하는 일이 일어나는가? “DW는 하나의 과정이며 목적이 아니다.”라는 말이 있다. 일반적으로 경영진의 의사결정 과정을 도와주도록 주관적이고 시기에 따라 변화하는 종합적인 비휘발성(Non-Volatile) 데이터 수집이라고 정의하고 있다. DW는 수집된 데이터 항목과 정보 사항으로부터 의미를 얻어내려는 오랜 연속된 과정이 필요하다. 지금의 경향은 “데이터가 우리가 알고 있는 의미를 이미 앞지르고 있다”고 말한다. 엄청난 양의 데이터 항목을 계속 산출하므로 정보의 홍수가 발생했고, 우리로 하여금 이러한 데이터의 바다를 항해하는 법(적시 정보의 취득)을 배워야 한다고 말하고 있다. 기업이 갖고 있는 데이터 중에서 기업정보의 본질적인 것이 아닌 것을 발견해내고 데이터 분석을 통해 기업의 현실이나 미래에 대해 더 나은 이해를 제공한다는 측면이다.
앞으로 몇 년간은 분명히 정보 집약적인 산업에 종사하는 기업들에게는 더욱 중요한 시기가 될 것이다. 좁아진 시장과 새로운 기술은 이러한 기업들이 어쩔 수 없이 새로운 정보 영역으로 이동하지 않을 수 없게 만들 것이다. 경쟁의 중요한 우위는 역시 고객들을 잡아두기 위해 고객들과 결속을 유지할 수 있는 회사의 능력에서 나올 것이며, 그 열쇠는 관리자들과 분석가들 그리고 최종사용자들이 필요로 할 때 곧바로 사용할 수 있는 관련성 있는 정확한 가치 정보의 확보이다.
오랜 경쟁자 또는 새로운 경쟁자들의 공격을 받는 현 시장은 매우 세밀한 마케팅, 숨겨진 사업 기회의 파악, 시장의 새로운 조류를 빠르게 탐지해야 한다. 그리고 조직체 내에 주요 정보에 신속히 반응할 수 있는 정보지원 시스템을 갖춤으로써 자체 정보 자원에서 최대한의 가치를 뽑아낼 수 있어야 한다. 조직체가 확고한 시스템 설비를 갖출 때, 비로소 대상 정보 자원을 이용하는 최종 사용자들의 의사 결정 지원능력을 향상시키게 되는 것이다.
또한 기업은 그 DW에 무엇을 넣을 것인지 충분히 생각할 필요가 있다. 기업의 정보가치의 부가가치의 창출을 위해서는 새로운 내부 데이터뿐만 아니라 외부 데이터의 확보도 중요하게 바라보는 것이 좋다. 기업의 성장 전망을 충분히 생각하고 DW를 항해한다는 것은 최종 사용자의 관점에서 프로젝트의 성공 또는 실패로 이어지는 가장 중요한 요인이다. 탁월한 구조와 훌륭한 반응 시간이 갖춰져 있다 해도 자신들이 원하는 바를 찾을 수 없다면 DW가 무슨 소용인가? 그래서 이미 시장은 메타데이터 저장소(Metadata repository) 정보에 관한 중요성이 크게 나타나고 있다.
DW 구축은 지식노동자들로 하여금 특정 주제 분야를 선택하고 DW라는 정보의 금광으로부터 과거에는 캐낼 수 없었던 귀중한 정보를 끄집어낼 수 있게 해준다. DW는 지식의 생산 기지라는 것을 DW 항해 중에 항상 생각하길 바란다.

시스템 대통합은 기술적인 문제가 아니다

이 글에서는 데이터 통합, 그중 DW 관점에서 여러 이야기들을 해봤다. 정보는 자원(resource)이다. 이러한 정보 자원을 효율적으로 사용함으로써 조직의 성공을 도모할 수 있는 것이다. 다른 여러 자원들이 계획적으로 관리되는 것과 마찬가지로 정보도 계획적으로 관리되어야 한다. 기업의 정보요구를 평가하고, 정보 요구를 충족시키는 정보 체계를 구축하며, 이 정보 체계의 구현을 지원하는 업무 시스템 체계를 구축하는 모든 것이 최고 경영진과 사용자들이 쉽게 이해·평가·조치할 수 있도록 구축되어져야 한다.
2000년대의 중요 경영 주체는 ‘통합’이라고 할 수 있으며 IT 기획 부서에서는 반드시 전체 시스템에 대한 통합의 밑그림을 그려야 한다. 각 회사의 경영환경과 목표에 대한 분석부터 IT의 주요 성공요소를 도출하고 이에 대한 미래지향적인 전체 시스템에 대한 통합 모델을 완성해야 한다. 또한 이로부터 각각의 개별 시스템을 통합시켜 주는 방향으로 가야 할 것이다.
IT의 대통합을 구현하는 기술은 이미 언급한 것처럼 많은 분야가 현재 완성된 형태로 존재하고 있으며, 앞으로 빠른 속도로 성장해나갈 것이다. 시스템 대통합은 기술적인 문제가 아니라 그것에 대한 시대적 요청을 얼마나 깊게 인식하느냐가 성공의 관건이라고 할 수 있다.

[ 데이터 웨어하우스란? ]

오늘의 기업 환경에는 전과는 사뭇 다르게 많은 변화가 감지되고 있다. 다음의 표현은 어떤가?
“모든 주요 사업들과 마찬가지로 우리의 기업 추진력은 경쟁 우위를 획득하고 적은 자본으로 많은 것을 달성하기 위한 새로운 방법과 기술을 개발하는 데 집중되어 있다.”

DW의 정의
DW에 대해서는 많은 사람들이 다양한 정의를 내려왔다. 하지만 너무 학문적이고 추상적이어서 이해하기 어려울 뿐 아니라 현재의 DW가 처음의 태생 그것과는 많은 변화가 있었기 때문에 기본적 정의를 따라가지 않는 경우가 되어버렸다. 필자는 DW 구축에는 많은 조건을 만족시켜야 하지만 다음과 같은 조건이 필수요건이라 생각한다.

　 - 과거의 데이터를 보관하고 이를 분석한다(Historical data).
- 기업에서 운영계 시스템을 구축하고 여기에서 기업 내부의 데이터가 발생해야 한다(Internal data).
- 내부 데이터뿐만 아니라 외부 데이터(타 경쟁사 정보, 날씨, 해외정보)를 참조한다(External data).
- 운영계 시스템이 여러 개로 분산되어 있는 경우 각 시스템에서 모델별로 데이터를 추출하여 주제별로 통합하게 되어 모델 별 통합 보고서가 나올 수 있게 한다(Subject-Oriented).
- OLAP 도구 등을 이용하여 프로그래밍 작업 없이 최종 사용자가 원하는 데이터를 처리, 가공할 수 있도록 해야 한다(End user computing).
- 온라인 방식으로 정보를 처리 분석하여 즉시 데이터를 처리할 수 있게 한다(On-Line analysis).
- 데이터를 분석하는 방식으로 다차원 분석이 가능해야 한다(Multi Dimensional analysis).
- DW는 기존의 운영계 시스템과 연결 구축하게 된다. 이에 인터페이스 부분의 중요성은 더 이상 언급할 필요가 없다. 특히 데이터의 추출과 로딩 부분을 자동화해 시스템의 운영을 용이하게 만들어야 한다(Integrated System).

제공 : DB포탈사이트 DBguide.net

http://blog.naver.com/mshouse71/7291334