BI에서 좀 더 많은 아웃풋을 얻기 위한 방법

홍정기 한국HP Consulting
수석 컨설턴트, 부장
(jeong-ki_hong@hp.com)

필자는 지난해 외국 유수 트레이너의 ‘커뮤니케이션 향상’ 과정에 참석한 적이 있다. 그때 배운 3P를 참고로 소개하면, 직원과 회의할 때 회의 목적(Purpose), 목표점과 목표를 달성했을 경우의 모습(Picture), 계획(Plan)을 항시 염두에 두고 커뮤니케이션을 할 것을 권고받았다. BI 분야 역시 마찬가지이다.

좀 더 많은 아웃풋을 얻기 위한 방법을 소개하면 첫째, 큰 그림을 보여 주어야 한다. 유명한 비유로서 대성당 건축 작업에 참여하고 있는 석공이 그저 자신은 돌만 쪼는 사람으로 인지할 경우와, 대성당 건축이라는 소명 의식을 수행하고 있는 사람임을 인지하고 있을 경우의 차이는 매우 크다. 금융권의 예를 들면, 고객을 세분화하여 핵심 로열 고객을 찾아내어 집중적으로 이들에게 투자하는 것이 큰 그림이라면, 영업점 창구 일선에서는 그저 고객 만족도 향상을 최고 임무로 근무하는 것이 작은 그림이다. 만일 수익성 낮은 고객이 서비스에 대하여 불만을 표출할 경우 그저 고객만족을 위하여 그 고객에게 초점을 맞추다가 상대적으로 불이익을 받은 로열 고객이 떠나는 우를 범하지 말아야 한다.

둘째, 임금 보상 체계와 연계되어 있어야 한다. 외국의 유명 운수 회사는 운전 기사들의 운전 성과, 즉 갤론당 운행 거리, 부품의 마모나 손상 정도 등의 비용 효율성 개선 수준에 따라서 인센티브를 받는다. 또한 항공 업계도 유사한 제도를 운영하고 있다. 처음에는 성과 모니터링 시스템을 반기지 않겠지만, 목표를 달성하게 되면 인센티브와 보상이 주어지기 때문에 해당 직원들은 곧 제도의 지지자가 된다.

셋째, 정보를 아낌없이 공개한다. 정보의 효율성은 ‘나누는 기쁨’에 정비례한다. 정보의 획득/공유를 위해 직원들이 필요로 하는 툴을 제공한다. 그 툴은 단순히 사전에 정의된 쿼리뿐 아니라 임의의 쿼리(Ad-hoc)도 가능하여야 한다. 통계에 의하면, 사용자들은 80% 시간을 표준 리포트를 읽는 데 사용한다. 나머지 20%는 원래의 보고서에는 없는 정보를 찾는 데 사용한다. 또한 사용자의 요구는 시간의 흐름에 따라서 증가하는 경향이 있다. 이를 ‘컨베이어 벨트(Conveyor belt)’ 효과라고 부른다. 즉, 사용자들이 일련의 기능을 계속 활용하면 곧 편안함을 느끼고 더 많은 기능을 요구하게 되어 기존에 정적인 리포트를 받는 기능을 익힌 사람은 신규 리포트를 스스로 만드는 일이 가능하기를 바란다.

데이터 웨어하우스와 ODS 구축시 유의 사항

비유를 하나 해본다. 만일 용도 변경이 자주 일어나는 땅에 건물을 지을 때, 어떤 점을 중심으로 지을까 아마도 50년, 100년 동안 끄덕없이 버틸 건물보다는 쉽게 그 용도를 바꿀 수 있는 건물을 원할 것이다. 21세기 기업 환경 역시 마찬가지이다. 비즈니스 환경과 유저 요구 사항이 언제나 자주 변하는 환경에서 어느 특정 ‘애플리케이션’ 중심적이거나, 어느 특정 ‘기술’ 중심적인 구조는 그 쓸모가 쉽고 빠르게 없어져 버린다. 따라서 유연한 구조가 첫 번째 중요도를 가진다. DW에 관하여서도 마찬가지이다. 유연한 인프라가 뒷받침되지 않는다면, 이미 구축된 DW는 향후 변화 요구가 발생시 매우 많은 재작업을 해야만 할 것이다.

먼저 DW와 데이터 마트의 차이점에 대하여 알아본다. DW에 관련된 기술의 진보가 예상외로 더디게 되자, 데이터 마트를 향한 아우성이 더 커지게 되었다. 그런데 사실 데이터 마트 그 자체에는 기술적으로 새로운 것은 없다. 차이점이 있다면, DW는 애플리케이션 중립적이며, 중앙에 놓이고, 공유 환경이며, 여러 LOB를 지원한다. 반면에 데이터 마트는 특정 애플리케이션 중심적이고, 어느 특정 LOB 또는 부서 중심적이며, 특정 비즈니스 프로세스 중심적이다. 이를 요약하면 데이터 마트는 특정 유저군이 어느 특정 애플리케이션 수행을 ‘빠르게’ 그리고 사전에 규정된 바대로 정적(static)으로 수행하게 하고 싶을 때는 매우 효과적이다.

최근의 동향을 살펴보면, 이전의 논쟁은 “DW냐 데이터 마트냐” 혹은 “하나의 DW를 두겠느냐 아니면 여러 개의 데이터 마트를 둘까”로서 서로 우세를 주장하던 것이, 이제는 서로의 필요성·중요성을 인지하고 있다.

통계에 의하면, 2006년 미국 유수 기업의 50%가 필요한 규모의 10배 이상으로 BI(CRM 포함)에 리소스를 부여할 것으로 예측되고 있다. 이는 효과적인 내부 코디네이션이 부재하기 때문에 발생한다고 지적되고 있다. 예를 들어보자. 미국의 유명한 대형 보험 회사의 경우 내부 IT 부서의 정치적인 이유 때문에 미국 내에 5개의 서로 다른 DW를 구축하였으며, 서로 다른 데이터 모델 및 서로 다른 툴로 구현이 되었다. 경영진이 후에 통합 필요성을 느끼고 2년 동안 노력하였으나 진척이 거의 없다.

데이터, 정보, 지식의 구분 또는 밸류 데이터에 대한 좋은 비유가 있다. 데이터 아키텍처는 마치 석유 산업과도 유사하다. 데이터가 하나의 서버에서 다른 서버로 이동할 때마다, 밸류 애딩(Value adding) 프로세스를 겪게 되는 것이다. 즉, 데이터는 단순하게 이동 그 자체만을 위하여 이동을 하는 것이 아니다.

비록 중앙에서 ‘공유’되는 데이터 모델이 바람직하다고 모두들 생각하지만, 이는 제대로 관리가 될 경우에만 국한되는 얘기다. 다시 말해, 보안이나 정확도, 감사 등을 포괄하는 정책이 제대로 지켜져야만 된다.

ODS 구축 시의 유의 사항을 살펴보자. ODS가 기존의 DW와 다른 점은 “Day-to-Day 의사 결정을 위한 아키텍처 컨셉”이라는 것이다. 즉, DW가 장기적 흐름에 중점을 둔 것이라면 ODS는 매일 매일의 의사 결정을 도와주는 것이다. ODS의 특징은 ▷주제 중심적이다 ▷인티그레이티드된 모델이다 ▷불변 데이터가 아니다. 즉, 휘발성(Volatile)이다 ▷데이터 내용이 거의 현재성을 반영한다. 즉, Current, 또는 Near Current이다 ▷상세 데이터를 갖는다. 즉, 디테일 데이터이다 ▷IT구조는 ‘성능’을 겨냥한 데이터베이스 디자인을 한다. 위의 ODS 특징에 반대되는 DW의 특징은 ▷Nightly 업데이트이기에 현재성이 부족하다 ▷Normalized 스키마이기에 주제 중심적이 아니다 ▷요약 데이터이기에 상세 데이터가 부족하다 등이다.

ODS는 시간에 민감한 의사 결정을 위한 것이다. ODS는 특정 비즈니스 프로세스와 애플리케이션 중심적으로 구축되어야 한다. ODS 속의 데이터는 비교적 최신의 데이터이며, 중소 기업의 경우 ODS는 애플리케이션, 데이터 인티그레이션의 수단으로 이용될 수 있다.

그리고 중요한 점은, 사과는 사과 바구니에, 귤은 귤 상자에 담듯이, ODS와 DW는 서로 분리하여 구축해야 한다. 해외 모 금융 기관은 “트랜잭션과 분석형 데이터는 서로 분리·저장해 운용한다”는 원칙을 지키지 않고 ODS와 DW를 하나의 DB 속에 구현한 결과 매우 곤란한 상황에 빠졌다. 선진 리포트에서는 2004년까지 대기업의 80%가 ODS용 또는 DW용으로서 전용 DBMS를 둔다고 예측하고 있다. 그리고 평균적으로 대기업은 5~7개의 서로 다른 DBMS를 보유하며 50개 이상의 DB에서 데이터를 추출해야 한다고 밝히고 있다. 사과/귤의 비유에 관련되어 DW/DM/ODS 구축에 관련된 유의 사항은 ‘인티그레이션 툴’과 ‘ETL툴’은 서로 성격이로 다른 것의 영역을 커버하면 안 된다는 것이다. 참고로 ETL 구현 과정의 50%는 커스텀 프로그래밍이고, 나머지 30%는 DBMS-독립적 툴로 작성되며, 오직 20%만이 DBMS 벤더가 제공하는 툴로 만들어진다.

구축 시 유의할 또 다른 사항은 DW의 구축(하드웨어 성격) 그 자체에만 신경을 쓰지 말고 데이터의 획득 과정(콘텐츠 성격)에 중점을 두어야 한다는 것이다. 국내외의 많은 DW 구축 시 데이터 획득(Data Acquisition) 업무에 소요되는 노력은 대부분 과소 설정된다. 보통 평균 필요치보다 300% 적게 설정된다. 결론적으로, DW 구축 노력의 75%는 데이터 획득과정에 초점이 맞춰져야 한다.

인티그레이션 구축시 유의 사항

애플리케이션 인티그레이션의 중요성에 대해 언급하면, 2004년까지 새로이 도입되는 산업 표준의 80%는 애플리케이션 인티그레이션에 관련된 사항이다. 이는 2000년의 경우, 새로운 표준의 80%가 애플리케이션 그 자체의 아키텍처에 관련된 것과 비교해 볼 때 매우 다른 국면임을 알 수 있다. 현재 대부분의 인티그레이션은 ‘데이터’ 정합성 중심으로 구현된다. 그런데 앞으로는 ‘멀티스텝’ 프로세스 중심으로 전이할 것이다. 이는 워크플로, 비즈니스웨어, 엔터프라이즈 워크매니저, 워크플로 브로커 등 여러 가지 이름으로 불린다.

이러한 프로세스, 어떤 면에서는 자연 과학이 아닌 사회 과학(우리 한국인이 취약한 분야이기도 하다) 면이 강한 프로세스를 잘 다루고 셋업하기 위한 첫째 요건은 무엇일까 바로 ‘프로세스의 문서화’이다. 프로세스, 투자 효과 공히 문서화를 하여 추적, 공유하여야 한다. 유명한 ISO 9000 평가단의 글귀 중에, “No Document, No Work”, “No Measurement, No Work’라는 글귀가 있다. 또한, “A Requirement is not a requirement unless it is documented and released”(CMII 프로젝트 관리 문서) 등이 그 필요성을 웅변한다. 그만큼 일에 대하여는 ‘평가’가 반드시 수반되어야 한다는 말이다.

성과 측정지표가 부재한 상태에서는 IT 조직이 지속적으로 향상하고 발전하기 위한 성과 및 애로사항을 유기적으로 평가하기가 매우 어렵다. 따라서 IT 성과 평가는 최소한 연간 1회 업데이트해야 한다. 이 때 비즈니스 스코어 카드(BSC)라는 개념을 도입하여 IT의 응용 성과를 평가해야 한다. 이 BSC의 상당 부분은 앞서 언급한 비즈니스 인텔리전스(BI)의 일부분인 OLAP을 통해서 얻을 수 있다.

참고로 인티그레이션이 만능인가에 대하여 언급해보자. 여러 국가 인물이 참석한 국제 회의석상에서는 영어로 대화하든지 서로 의사 소통이 가능한 제3의 언어로 얘기를 할 것이다. 마찬가지로 이기종 환경에서도 여러 애플리케이션이 서로 이해할 수 있는 언어를 이용해야 한다. 마치 에스페란토 언어가 필요한 것과 같다. 그런데 통계에 의하면, 2005년까지 기업 내부 애플리케이션 인티그레이션 프로젝트의 50% 미만이 규범적(canonical) 형태로 진행될 것이다. ‘canonical’의 뜻은 중간적(intermediary) 데이터 형태로서 여러 애플리케이션이 공히 이해 가능한 형태를 의미한다. 이 형태는 어떤 특정한 데이터 포맷은 아니며, 디자인 컨셉이면서 XML 또는 다른 신택스(Syntax)로 작성해도 무방하다. 그런데 이러한 형태는 아키텍처상으로는 매력적이지만 언제나 필요한 것은 아니다. 때에 따라 간단하게 구현이 필요한 경우에는 포인트간의 연결 방식(point to point)이 더 나을 수도 있다.

2005년까지 대기업 인티그레이션 프로젝트에 있어서 75% 이상은 사내 XML 표준과 사외 B2B XML 표준을 혼용하여 이용할 것으로 전망된다. 이는 국내의 경우 역시 동일하다. 때에 따라서는 여러 국제 기구, 단체에 가입 시, 여러 종류의 B2B 표준을 이용할 수도 있다. 예를 들면 로제타넷, ebXML 등이다.

웹 서비스가 IT를 평정할 것인가 2007까지 항상 웹 서비스가 모든 인티그레이션에 100% 이용되지는 않을 것이다. 그러나 그 경우에도 대부분 서비스 중심적 구조(Service Oriented Architecture, SOA)로 구현될 것이다. 처음에 예상하기는 하나의 웹 서비스가 모든 인터넷 애플리케이션에 구현되리라 예상했으나, 많은 경우 하나 또는 두 개의 표준을 이용하여 ‘사내’에 구현될 것이다. 그리고 모든 서비스의 경우와 마찬가지로, 웹 서비스 역시 그 스스로가 모든 것을 갖춘 완전한 독립적 애플리케이션이 아니고, 기존에 구성된 애플리케이션을 보조하여 주는 빌딩 블록(building block)이다.

기업 신경망 구축시 유의 사항

기업 신경망, 디지털 신경망이라는 단어가 회자되고 21세기 IT에서는 그 중요성이 더 커진다고 얘기한다. 그렇다면 이 기업 신경망이란 무엇일까 결론적으로 기업 신경망은 단지 네트워킹의 일종이 아니다. 기업 신경망은 네트워크 기반의 로직과 데이터로 구현되며, 어느 특정 애플리케이션의 범주 속이 아니라 ‘밖’에 속하는 것이다. 통계에 의하면, 2006년까지 선도 기업의 80%는 실시간 기업 신경망을 사내·외에 걸쳐 구현한다. 이는 IS 구조의 근본적 변환이다. 이전의 IS 구조에서 모든 인텔리전스(데이터와 로직)는 애플리케이션 ‘속’에 존재했다. 애플리케이션은 ‘똑똑’하였으나 네트워크는 그렇지 않았다. 이전의 네트워크는 그저 데이터를 애플리케이션 사이에서 전해주는 역할을 수행하는 수준에 불과했다.

기업 신경망에서는 네트워크가 ‘똑똑’하다. 네트워크 속에 데이터 형태의 변환, 콘텐츠에 근거한 라우팅, BPM이 수행된다. 이러한 기업 신경망은 빠른 속도로 우리에게 다가오고 있으며 이의 파급 효과는 매우 크다. 따라서 기업 신경망 구현에 대한 준비를 해야 한다.

기업의 지능지수는 정보 기술 인프라가 정보를 연결하고 공유하며 체계화하는 수준에 의해 결정된다. 그 동안 기업은 수십년간 자동화에 몰입한 결과 호환성이 결여되는 시스템의 확산이라는 결과로 이어졌다. 부문 부문별, 즉 사일로별 프로세스 또는 애플리케이션은 국내 기업 역시 세계 수준에 도달하였다. 그러나 이슈는 ‘제로 레이턴시(Zero Latency) 혹은 디지털 신경망을 갖추었는가’이다. 위기나 돌발상황이 벌어질 때 조직 역량을 최대로 결집시켜 대처할 수 있는 비즈니스 반사 신경이 기업이 갖춰야 할 요소이다.

그렇다면 어떤 점에 중심을 두어서 IT 구조를 수립할 것인가 그 대답은 ‘이벤트’ 데이터에 주목하여 IT 설계를 하라는 것이다. 데이터에는 크게 나누어서 3종류가 있다. 고정 데이터, 상태 데이터, 이벤트 데이터가 그것. 그 중에서 CIO가 가장 염두에 두어야 하는 데이터는 이벤트 데이터이다. 그 처리를 위해 기업 신경망(Enterprise Nervous System)을 구축해야 한다.

그렇다면 기업 신경망이 왜 지금 이 시점에서 의미를 더해갈까 현재까지 기업 신경망을 도입한 프로젝트는 5%에 불과하다. 그런데 2007년까지 50%로 확대될 것으로 예측된다. 그렇게 될 수 있는 요인을 알아보면,

요인 1 이미 대부분의 비즈니스 기능이 ‘온라인’ 시스템으로 구현되었다. 기업 신경망으로 묶을 수 있는 기초 지반이 닦인 셈이다. 특히 비용이 꾸준히 하락하고 있다. 참고로 이더넷 창시자인 봅 메칼프가 언급했듯이 “네트워크는 접속이 늘수록, 그 효과는 지수 함수적으로 증가한다. 그런데 비용은 오로지 선형으로 증가할 뿐이다.”

요인 2 인티그레이션 미들웨어 기능이 향상되었다. 예를 들면, MOM, Publish-Subscribe, BPM, 이벤트 매니저 등의 기능 구현이 쉬워졌다.

요인 3 표준이 보편화되었다. XML, 웹 서비스 등이 해당된다. 통계에 의하면, 2003년 신규 프로젝트의 90% 이상이 애플리케이션 인티그레이션을 포함한다. 그리고 2003년에 새로이 배치되는 신규 애플리케이션의 30% 이상이 웹 서비스를 이용한다.

요인 4 하드웨어, 즉 서버, 네트워크 대역폭 등이 꾸준히 향상되었다. 이를 요약하면, 기업 신경망은 온라인상에 구현된 비즈니스가 인티그레이션이 쉽게 되고, 보편적 표준이 준수되고 하드웨어 가격이 저렴해져서 더욱 가능해지고 있다는 것이다.

이러한 경구가 있다. “많은 트랜잭션을 빠르게 처리하는 기업은 강한 경쟁력을 갖춘 기업이다. 그런데 변화하는 환경에 맞추어서 프로세스를 빠르게 변경할 수 있는 기업은 더욱 강한 경쟁력을 가진 기업이다.” 이제 기업은 자동화 관점에서 벗어나서 ‘비즈니스 프로세스’와 ‘정보의 공유’로 눈을 돌려야 한다. 즉, 앞서 얘기한 BAM의 중요성이 더욱 크다.

이를 위해 1) 더욱 일관성 있는 데이터(Data Consistency)가 필요하며, 2) 여러 단계 수작업 또는 반복 작업이 불필요한 STP(Straight Through Processing)가 필요하다. STP는 바꿔 말하면, 막힘 없이 원활함, 종이 없는 처리 환경, 수작업이 불필요함 등으로 표현할 수 있다. STP는 트랙잭션이 데이터의 재입력 없이 일사천리로 자동화되어 수행됨을 의미한다. 이에 처리 시간이 단축되고 에러를 미연에 방지한다. 즉, 주스에서 공기를 뽑아내듯 프로세스에서 공기를 걷어내는 것이다.

3) 여러 애플리케이션의 결과물을 받아서 새로운 애플리케이션으로 전달하는 합성(composite) 애플리케이션 방식이 요구된다. 여기서 합성 애플리케이션은 여러 세미 자동화 애플리케이션이 어울려져서 비즈니스 프로세스 레벨에서는 하나의 스텝을 행하게 되는 애플리케이션을 의미하며 포털이 그 예제다.

21세기 버추얼 기업의 IT는 ‘하나의 시스템’으로 볼 수 있다. 이는 기업의 ‘내부’ 또는 기업의 ‘외부’를 모두 포함한다. 다시 말하면 어느 기업이 합병 등을 통해 아무리 여러 회사의 IT 구조를 흡수하였다 할지라도, 소비자/고객은 그 회사의 IT를 하나로 간주하고 일관성 있는 반응을 보여줄 것을 기대한다. 국내 최대의 은행으로 떠오른 K은행의 경우에도 이는 마찬가지이다. 기존에는 서로 다른 벤더의 HW, 솔루션을 운영하던 것을 올해 초 하나로 통합하는 작업을 성공리에 마무리하여 고객에게 일관성 있는 서비스를 제공하고 있다. 이렇듯 인티그레이션은 21세기 버추얼 기업의 IT에 있어서 핵심 요소로 부상하고 있다.

IT 예산의 35%가 애플리케이션 인티그레이션에 소요된다는 통계가 나와 있다. 그러면 그 비용을 쏟아 부으면, 하나의 정보 아키텍처를 꾸미고 운영할 수 있을까 유감스럽지만 그렇지 못하다. 21세기 기업의 IT는 그 다양성이 넓은 스코프를 가진다. 옛날의 메인프레임에서 C/S, 웹 환경 모두를 갖추고 있다. 항공사로 치면 프로펠러 기, 비행선, 제트기 등 여러 기종을 보유하고 있는 셈이다. 어떤 기업도 IS 시스템의 40% 이상이 하나의 ‘전사 정보 아키텍처 표준’을 준수하도록 할 수는 없다. 예를 들면, 아무리 J2EE를 신봉하는 CIO도 J2EE에 근간한 IT 표준으로는 전사 IT 표준의 40% 수준만 커버할 수 있다는 것이다. 이는 제조업 부문에서도 마찬가지여서 ERP의 예를 들면, ERP는 기껏 해봐야 기업의 비즈니스 기능의 35%만을 커버할 뿐이다. 서드파티 솔루션을 더 쓰더라도 커버 범위는 40% 수준이다.

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