Cover Story - BI(Business Intelligence) 시장분석
상태바
Cover Story - BI(Business Intelligence) 시장분석
  • 승인 2006.01.16 00:00
  • 댓글 0
이 기사를 공유합니다

리포팅·통합 기술 확보로 제품 향상 … 시장 상승세

OLAP·리포팅·경보 등 통합 뷰로 제시 … 최신 동향 추적에 결정적 역할

사용자들은 여러 개의 데이터 저장소를 하나로 묶어주는 하나의 BI(Business Intelligence) 소스를 원하고 있다. 마침내 이들은 원하던 것을 얻게 되었을까? 오늘날의 BI 스위트들은 OLAP(online analytical processing), 보고, 경보, 스코어보드 및 대시보드를 모든 사람에게로 로우 레벨 애널리스트에서부터 CEO까지 하나의 통합 뷰로 지원한다. 그리고 최고의 제품들은 고되고 단조로운 보고서 작성 업무에서부터 IT를 해방시키고, 데이터를 조작해 소중한 콘텐츠로 만들 수 있도록 비즈니스 사용자들을 자유롭게 해주고 있다.

보고서를 쓰겠어요!” 프로도가 잔뜩 격앙된 목소리로 말했다. “IT로 가서 툴을 찾아서 내가 직접 보고서를 직접 쓰겠어요.” 보로미르는 머리를 흔들며 젊은 비즈니스 애널리스트를 가엾은 눈으로 쳐다보았다.
“아무나 IT에 들어갈 수 있는 게 아니라네. 그 곳의 문은 생체인식 보안 장비 외에도 다른 지키는 것들이 많아. 잠 안자는 개발자들도 있고, 관리자들도 언제나 지켜보고 있지. BI 툴은 비즈니스 사용자들은 알 수가 없는 언어로 된 이상한 기호가 필요하다네. 알 수 없는 배치의 필요조건 투성이에 통합 어댑터(Integration Adapter)라는 것들도 있어. 키보드에는 건드리면 안 되는 독이 묻어 있을걸. 비즈니스 애널리스트 1만 명이 붙어도 할 수 없는 일이야. 소용이 없다고.”

BI 리포팅·분석 툴 ‘인기’
수많은 보고서 옵션들로 보강된 다중 BI(Business Intelligence) 툴을 지원해야 하는 것 때문에 여러 기업들이 파멸의 길로 걷고 있다. 이러한 정보 저장고들은 ‘한 가지 버전의 진실’을 찾는 의사결정자를 방해하고, 최신 판매 동향을 따라잡기 불가능하게 한다. 해결책은 OLAP(OnLine Analytical Processing), 리포팅, 경보, 스코어보드 및 대시보드 등 여러 가지 서로 다른 데이터 저장소들을 지원하며 하나의 엔터프라이즈 뷰를 제공하는 표준화된 BI 스위트가 될 수 있다.
하지만 여기서 중단해서는 안 된다. 회사들은 또한 자신들의 비즈니스 데이터를 분석할 수 있는 표준화된 플랫폼도 원하고 있으며, 이러한 플랫폼이 부서 수준에서만 아니라 전체 조직에서 작동하기를 원한다. 이러한 단일 엔터프라이즈 뷰는 비즈니스 사용자가 동향에 뒤쳐지지 않고 최신 데이터를 이용해 실시간으로 의사결정을 하는 데 있어 결정적으로 중요한 역할을 한다.
가트너에서 실시한 CIO 설문조사 결과 BI는 기술 우선순위에서 2004년도 10위에서부터 올해는 2위로 뛰어 올랐다. BI 보고 및 분석 툴 시장은 계속 상승세를 타고 있기에 놀라운 현상은 아니다. 포레스터리서치는 이 시장이 지난 해 55억달러에서 2008년에는 73억 달러에 달할 것으로 전망한 바 있다.
비즈니스 인텔리전스 업체들은 리포팅 및 통합 기술을 확보함으로써 제품을 향상시키고 있다. 예를 들어 비즈니스 오브젝트(Business Objects)는 엔트프라이즈급 보고 툴을 위해 2003년 크리스탈 디씨전스(Crystal Decisions)를 인수했다. 코그너스(Cognos)는 비즈니스 사용자 중심의 보고 툴인 리포트넷(ReportNet)을 개발했는데, 이것은 전통적인 BI 제품과도 잘 작동한다. 그리고 마이크로소프트와 오라클은 피봇 테이블(pivot tables)과 같은 BI 기능들을 자신들의 데이터베이스 제품에 계속해서 집어 넣고 있다.
단일 보고 플랫폼이 있으면 모두가 같은 데이터를 기반으로 이용을 하고 의사결정을 할 수가 있으며, 이는 제시되는 데이터가 현실에 기반을 둔 게 아닐 때도 마찬가지다.
표준화는 단순히 보고에 대한 것만은 아니다. 몇몇 BI 업체들은 EII(Enterprise Information Integration) 사업자를 인수하거나 이들과 협력 관계를 맺고 데이터 소스 통합을 개선하는 동시에 관리비를 줄이고 있다. 사용자는 관계형 데이터베이스와 같은 전통적인 데이터 소스뿐만 아니라 OLAP 큐브, XML 등과 같은 다른 플랫 파일과 웹 서비스도 포함되기를 원한다.
액추에이트(Actuate)는 2003년 왕성한 BI 쇼핑 활동을 하며 님블 테크놀로지즈(Nimble Technologies)를 인수했고, 그 이후 님블의 EII 기술 대부분을 자사의 BI 스위트에 통합시켰다. 코그너스는 EII 업체인 컴포지트 소프트웨어(Composite Software)와 협력관계를 맺고 웹 서비스, XML과 같은 비구조화 데이터 및 플랫 파일과, 엑셀 및 관계형 데이터베이스 등을 지원하고 있다. 한 마디로 싱크대만 빼고 모두 다 지원이 된다.
하지만 비즈니스 인텔리전스 스위트에 대한 평가들에서는 보통 표준화를 이끄는 동력, 즉 아키텍처와 통합은 너무도 많이 무시되고 있다. BI 스위트의 아키텍처는 생성되는 보고서의 폭과 질에 영향을 미치며, 이행을 만들 수도 파괴할 수도 있다.
IT로 도달하려는 목표는 보고서 작성자가 되는 부담을 덜어주고, 사용자들이 비즈니스 애널리스트만이 꿈꿀 수 있었던 방식으로 데이터를 조사할 수 있도록 하는 것이다. 진실을 회피하지 말자. IT가 언제나 사용자의 데이터를 분석 방법과 이것을 가시화하고자 하는 방식을 알고 있는 것은 아니다. 이러한 새로운 아키텍처는 애널리스트가 그런 결정을 내릴 수 있게 도와줄 것이다.

데이터 품질
전체 조직에서 데이터 품질은 데이터 소스가 변경되는 방식에 따라 다양하다. 고객접촉 웹 애플리케이션도 우편번호나 주 약어 등을 요구하는 등 초보적인 데이터 품질 검증을 해주겠지만, 일부 ‘질 나쁜(bad)’ 데이터는 아무리 신중하게 만들어진 필터라도 통과해서 들어올 것이다. 예를 들어 NWC의 웹 애플리케이션은 주 약어를 요구하지만 우리 코드에서는 그 유효성을 검증하지 못한다. BI 스위트라면 이런 더티 데이터를 처리할 수 있어야 할 것이다.
대부분의 BI 스위트는 분실한 데이터를 무시하는 체크박스(check-box) 기능을 제공한다. 이 기능은 엔드유저의 분석을 왜곡시킬 수 있는 불완전한 데이터를 걸러내 주긴 하지만, 데이터는 유효하나 정보가 유효하지 않은 입력은 책임지지 못한다. 예를 들어 우리는 BI 스위트를 테스트하면서 ‘MB’라는 약어로 된 주의 고객들에게 상당량의 NWC 위젯 주문이 전달되고 있음을 발견했다. 이들의 주문은 어떻게 전달되었을까?
이 경우 고객 서비스 대리점에서는 고객에게 전화를 해서 배송 시스템에 있는 약어를 수정했다. 하지만 우리의 배송 및 주문 시스템은 통합되지 않았으며, 따라서 우리 주문 시스템에는 여전히 더티 데이터가 포함돼 있을 것이다(우리 애플리케이션과 데이터베이스, 그리고 비즈니스 인텔리전스 스위트에 관한 한 유효했다).

에러성 정보 처리 방식 제한적
더티(dirty) 데이터는 몇 가지 방식으로 처리될 수가 있는데, 우선은 소스 데이터를 수정할 수가 있다. 이 방식의 가치는 서로 다른 소스들이 얼마나 자주 업데이트돼야 하느냐에 따라 달라진다. 두 번째는 큐브와 데이터 소스를 만들어 에러 소지가 있는 데이터를 걸러냄으로써 엔드유저에게 접근 불가능하게 하는 것이다. 우리 경우 데이터를 무시하면 재앙이 닥칠 수가 있다. ‘MB’ 주에서는 큰 매출이 창출되기 때문에 이것을 걸러낼 경우 우리의 제조쪽 통계는 말할 것도 없고 다른 모든 주의 데이터가 역으로 왜곡될 수 있다.
세 번째 방법은 데이터를 무시하고 엔드유저로 하여금 이것을 수동으로 걸러내게 하는 것이다. 단 이 방법은 비즈니스쪽 사람들을 고문하고 싶지 않다면 별로 추천하고 싶지 않으며, BI 스위트의 아키텍처에 의존하는 두 번째 방법은 거의 불가능할 것이다. 소스 데이터를 수정하는 게 거의 유일한 선택이 될 것이며, 이것이 바로 데이터 웨어하우스와 ETL(Extract, Transform, Load) 툴이 존재하는 이유이기도 하다.
BI 스위트가 배드 데이터는 걸러내고 유효 데이터만을 돌려보내 주는 모델을 만들 수 있는 능력은 순전히 이 스위트의 아키텍처에 달려 있다. 어떤 것들은 엔드유저와 소스 데이터 사이의 간단한 프록시 이상의 역할을 전혀 하지 않기 때문에, 생성되는 보고서에 더티 데이터가 포함될 수가 있어 비즈니스 사용자 쪽에서는 애드혹 보고서를 만드는 일이 고통스럽다. 인포베이션 빌즈나 코그너스와 같이 보다 똑똑한 프록시를 만드는 스위트들은 배드 데이터를 걸러내고 엔드유저에게 보고용으로 준비된 깨끗한 데이터를 줄 수 있으며, 이 메타데이터 레이어 아래서는 정보의 질에 대해 걱정할 필요가 없다.
BI 업체들이 우리를 위해 이 문제를 해결해 주리라고 기대해서는 안 된다. 테스트 결과 우리는 BI 스위트가 에러성 정보를 처리하는 방식에 있어서 제한적이라는 사실을 발견했다. 우리 예에서 보면 데이터가 잘못 입력됐을 경우에도 스위트는 모든 경우에 ‘MB’를 ‘MD’로 자동 변경하는 것 외에는 할 수 있는 게 아무 것도 없었다. 아마도 이것은 당신이 원하는 게 아닐 것이다. ‘MB’ 엔트리들 가운데는 ‘MN’으로 바뀌어야 하는 것들도 있다. 일단 이것이 데이터베이스 안에 있거나, 이것을 수정하기 위해 데이터 검증 서비스를 이용하는 ETL 프로세스를 돌린다면 정보를 수동으로 검증해야 한다. BI 스위트는 데이터를 제시만 해줄 뿐이고, 이것이 유효한지는 당신이 직접 밝혀내야 한다는 얘기다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.