개요

사실상 모든 트랜잭션과 엄청나게 많은 인스트루먼트화된 개체에서 생성되는 데이터를 기록하고 저장할 수 있는 기술에 많은 시간과 자본이 투자되었지만, 고객은 이러한 정보로부터 더 많은 것을 얻으려고 한다. 기업은 더욱 시기적절하고 유용한 정보를 원하며, 특히 정보가 성장과 수익에 직접적이고 긍정적인 영향을 미치는 경우에는 더 그러하다.

데이터 분석에는 소매 판매업, 사기, 고객/클라이언트 확보 및 유지, 보안, 금융 서비스 및 기타 여러 가지 기술을 포함한 다양한 문제점 도메인이 포함된다. 다양한 문제점 도메인에 대한 솔루션 작성을 지원하는 데 사용되는 주요 표준과 기술에는 이러한 것들이 제공하는 가치가 수반된다.

수년 동안, IT 산업은 데이터와 트랜잭션을 기록할 시스템을 개발하는 데 막대한 시간과 비용을 소비했다. 게다가 수집되는 데이터를 생성하는 디바이스의 수가 기하급수적으로 증가하고 있다. 또한, 이러한 데이터를 저장할 방대한 데이터 저장 시스템이 사용 가능하고 데이터를 처리할 시스템과 데이터 센터 간에 데이터를 전송할 빠른 네트워크가 존재한다. 기업은 사용 가능한 데이터에 투자된 비용을 활용하여 성장과 수익을 견인하는 데 도움이 되는 시기적절하고 유용한 정보를 얻으려고 한다.

위로

비즈니스 분석이란?

비즈니스 분석은 비즈니스가 수행되고 있는 과정을 즉시 파악하여 적절한 조치를 취할 수 있게 하는 기술이다. 이 기술을 이용하면 경향, 패턴 및 이상 신호를 파악하고 분석할 수 있기 때문에 사용자는 자원을 예측하고 계획하여 예산을 세울 수 있다. 목표는 더 유리한 결과를 이끌어낼 수 있도록 현명한 의사결정을 하는 데 있다. 데이터를 통해 비즈니스 가치를 창출할 수 있는 기회는 사용 가능한 데이터의 엄청난 양에 의해 더욱 증가한다. 문제는 이러한 가치를 창출하는 분석 결과를 비용 면에서 효과적인 방식으로 산출하는 데 있다. 비즈니스 분석이란 데이터를 분석하고 체계화하여 적시에 편리한 형식으로 의미 있는 비즈니스 정보를 제공하는 것이다. 예를 들면, 실시간 경보나 임원용 대시보드는 기업의 성과를 상위 레벨에서 평가한 결과가 표시되는 프리젠테이션의 형태로 되어 있다. 비즈니스 분석 도구는 정보를 정적 보고서로 제공하는 대신에 온라인으로 제공함으로써 사용자가 관련된 비즈니스 정보를 바로 알 수 있게 하고 동시에 "드릴 다운"(차트를 클릭하여 그 이면에 있는 숫자를 확인)하는 과정을 통해 세부사항을 조사할 수 있게 한다.

비즈니스 분석은 단일 제품이나 기술이 아니라 여러 가지 제품이 상호 운용되어야 하는 기술 도메인이다. 분석 시스템은 본질적으로 다른 데이터베이스와 웨어하우스에 다양한 데이터 형식으로 저장되어 있는 데이터를 분석한다. 이외에도 히스토리 데이터와 함께 분석하기 위해 시스템에서 실시간 데이터 피드를 통합할 수도 있다. 데이터가 분석되는 과정에서 규칙이 적용되고 예측 또는 최적화 모델이 통합되며 해결 중인 문제점이나 시나리오에 따라 다양한 형태의 결과물이 생성된다.

기존 고객을 유지하려고 노력하고 있는 소매 상점을 생각해 보자. 고객의 제품 구매 기록은 하나의 데이터베이스에 저장되지만, 고객의 트랜잭션 기록은 다른 곳에 저장된다. 소매 상점은 어떤 제품이 판매되었고, 특정 고객이 해당 년도의 다양한 시점에서 이러한 제품에 얼마나 많은 비용을 소비했는지 그리고 구입 제안이 구매 의사를 결정하는 데 어떻게 영향을 주었는지에 대한 정보를 수집할 수 있다. 또한, 소매 상점에는 앞에서 언급한 데이터베이스에 저장되지 않은 실시간 데이터(예: 실시간 판매 데이터를 기반으로 상점 선반에 제품을 올리고 내리는 것)가 있다. 이러한 데이터를 모두 사용하여 특정 고객이 반입 제품이나 기존 제품을 상점에서 구입할 가능성이 얼마나 되는지를 신뢰성 있게 결정할 수 있는 예측 모델을 빌드할 수 있다. 이와 같은 다양한 요소를 기반으로 이 모델을 비즈니스 규칙, 고객 인구 통계, 과거의 구매 패턴 및 선택과 결합하여 현명한 의사결정을 할 수 있다. 예를 들면, 상점은 판매 시점에서 특정 제안을 통해 실시간으로 조치를 취하거나 인센티브와 특판을 제안하고 광고할 최적의 시기와 목표 대상을 결정할 수 있다. 분석을 하면 고객의 경향과 행동을 이해하고 고객이 목표가 설정된 특정 제안을 알고 있다고 확신하는 데 도움이 되는 흥미롭고 유용한 고객 정보를 얻을 수 있다.

시나리오는 기록 정보, 실시간 데이터 피드, 예측 또는 최적화 모델, 비즈니스 규칙 및 모든 것이 서로 조화롭게 작동하는 사용자 인터페이스 대시보드로 구성되지만, 반드시 특정 문제점을 해결하기 위해 설계되거나 개발된 것은 아니다. 통신이 긴밀하게 수행되어야 하기 때문에 다양한 제품과 시스템 간의 이러한 복잡한 상호작용을 가장 잘 처리하는 표준이 필요하다. 아는 바와 같이 표준이 있으면 단일 벤더에 속박되지 않으면서도 고객의 데이터, 규칙, 예측 모델 등을 한 가지 형식으로 저장하거나 공개된 방식으로 액세스할 수 있다는 혜택을 누릴 수 있다. 또한, 고객은 특정 도구 세트나 데이터 형식 또는 프로토콜을 고수하지 않아도 되는 행동의 자유를 누릴 수 있다. 이외에도 표준이 있으면 시스템이 다른 개발자에 의해 빌드되었다는 것을 염두에 두지 않아도 본질적으로 다른 시스템이 함께 작동하도록 할 수 있다.

비즈니스 분석은 이 데이터에 적용된 통계적 방법과 분석을 기반으로 비즈니스를 새롭게 통찰하고 이해하여 더 나은 의사결정을 내리는 데 초점을 맞추고 있다. 비즈니스 분석 소프트웨어는 단기간에 대용량 데이터를 분석함으로써 이러한 문제점을 포함한 기타 문제점을 해결할 수 있는 이와 같은 실행 가능한 정보를 제공한다.

위로

데이터 분석

데이터 분석은 새로운 것은 아니지만, 오늘날에는 다음과 같은 과제가 있다.

• 정확하고 실행 가능한 결과를 생성하기 위해 사용자가 처리해야 하거나 처리할 수 있는 대용량 데이터
• 결과를 생성하기 위해 데이터를 분석해야 하는 속도
• 분석할 데이터 유형(구조화된 데이터 vs. 구조화되지 않은 데이터)

데이터 양

오늘날의 분석 시스템은 인터넷 규모의 데이터 양을 처리할 수 있어야 한다. 온라인 데이터는 급속하게 증가하고 있으며 테라바이트, 페타바이트, 엑사바이트와 같은 용어가 일반적으로 사용되고 있다. (표 1 참조)

2002에는 약 5EB의 데이터가 온라인에 있었다. 2009에는 이 데이터 양이 281EB로 증가하여 7년 간 56배나 증가했다. Forrester Research Inc.에 따르면 엔터프라이즈에서 수용하고 있는 총 데이터 양이 3년에 두 배 씩 증가한다고 한다.

인터넷 규모(Internet-scale)는 적시에 이러한 데이터 양을 처리하도록 규모를 조정하여 처리 요구사항을 만족시킬 수 있는 데이터 크기와 용량이 TB와 PB 시대에 접어들었다는 것을 의미한다. 처리될 데이터로는 저장된 데이터와 실시간 스트리밍 데이터가 있다. 사실상, 오늘날에는 비디오 및 오디오 감시, 금융 트랜잭션, 구매 트랜잭션, 이메일 트래픽, 인스턴트 메시징 트래픽, 인터넷 검색, 의료 이미지 및 기록물 등과 같은 모든 것이 전자적으로 기록된다.

예를 들어, 직장에서 집으로 운전해 가는 도중에 주유하기 위해 잠시 멈추는 간단한 시나리오를 생각해 보자. 직장에서 나와서 차로 걸어감에 따라 독자의 모습이 비디오 감시 카메라에 기록될 가능성이 있다. 운전을 할 때는 휴대전화가 기록되어 있는 GPS 위치 정보를 전송하고 있을 수도 있다. 그 다음에는 집으로 운전해 가는 도중에 텍스트 메시지를 받는다. 이러한 메시지가 전송된 시간과 그 내용은 캐리어에 의해 저장된다. 주유소에 차를 세울 때까지 응답을 기다리며, 여기에서는 또 다른 비디오 감시 카메라 세트가 활동을 기록한다. 그 다음에는 가솔린을 구입하는 트랜잭션이 주유소에서 스캔한 구매자 카드와 함께 기록된다. 주유소는 시에서 ShotSpotter(링크는 참고자료 참조)와 같은 기술을 사용하여 감시하고 있는 범죄 다발 지역에 있게 마련이다. ShotSpotter는 다양한 위치에 배치되어 있는 마이크를 사용하여 총격 소리를 기록하고 확인한다. 총격 소리를 듣게 되면 관계자가 즉시 알게 되고 해당 영역이 비디오로 감시되게 된다. 그러므로 주유소에 있는 동안에는 오디오가 분석되고 기록된다.

웨어하우스 데이터가 증가하는 이유는 대부분 EMR(Electronic Medical Record)에 기인한다. EMR을 저장해야 하는 기간과 더불어 의료 이미지 기술의 발전과 EMR 자체로 인해 웨어하우스 데이터가 계속해서 대량으로 증가하게 된다. 이 웨어하우스 데이터는 이전에는 생각할 수도 없었던 규모의 데이터를 생성한다. 이외에도 이러한 유형의 수집된 데이터는 용량이 크고 압축 특성이 나쁘기 때문에 비디오와 오디오 피드를 저장하는 데는 비용이 매우 많이 든다. 이러한 유형의 데이터는 용량이 크기 때문에 실시간으로 분석해야 하며, 이렇게 하면 적절한 부분만 선택적으로 저장할 수 있다.

거의 모든 것이 이동하지만, 그렇지 않는 것도 많기 때문에 데이터는 어디에서나 기록된다. 일반적으로 기록되는 트랜잭션 외에 주차장, 건물 및 길 모퉁이와 같이 대다수의 위험한 장소에는 감시 장치가 설치되어 있어서 대용량 데이터가 24시간 동안 계속해서 기록된다.

속도

저장된 데이터의 양이 계속해서 기하급수적으로 증가하면 관련 결과를 생성하기 위해 비즈니스 분석 시스템이 처리해야 하는 데이터의 양도 증가한다. Twitter에서는 하루에 7TB를 처리하는 반면에 Facebook에서는 매일 10TB를 처리한다는 것을 참작한다. CERN Hadron Collider는 매초 40TB를 생성한다. 이러한 데이터 양의 규모를 조정할 수 있는 분석 시스템이 없으면 수집된 데이터는 그 가치를 잃게 된다.

이러한 데이터 양을 고려하여 Yahoo!는 Hadoop을 사용하여 약 16시간 안에 1PB 데이터를 정렬한다고 보고했다. (이러한 벤치마크 결과를 자세히 확인하려면 참고자료를 참조한다.) 이러한 정렬 작업을 수행하려면 노드당 두 개의 쿼드 코어 2.5Ghz 프로세스가 있는 3,800개의 노드가 필요하다. 모든 조건이 그대로라면 동일한 클러스터에서 엑사바이트를 정렬하는 데 걸리는 시간은 약 1000배 더 길어져서 거의 2년이 된다.

또한, 비즈니스 분석 시스템은 아직 저장되지 않은 실시간 스트리밍 데이터를 처리한다. 적시에 중요한 정보를 생성하려면 대용량 데이터와 실시간 데이터를 처리하는 속도가 중요하다. 어떤 비즈니스 분석 유스 케이스에서는 올바른 정보나 해결책이 부적절한 시기에 늦게 제공되었기 때문에 잘못된 해결책으로 여겨진다. 비즈니스 분석 시스템은 대용량 데이터를 처리하고 이 데이터를 효과적으로 분석하여 그 결과를 사용자와 관련된 시간 창에 나타낼 수 있어야 한다. 예를 들면, 실시간으로 비디오 피드를 처리하는 안면 인식 시스템은 용의자가 특정 위치에 있다는 것을 사후 1분(1일이 아니라) 이내에 시스템이 표시하는 경우에 훨씬 더 가치가 있다.

구조화된 데이터 vs. 구조화되지 않은 데이터

오늘날에 생성되는 대부분의 데이터는 구조화되어 있다. 구조화되어 있지 않다는 것은 데이터에 잠재적 의미를 첨부하여 데이터가 표현하는 것을 컴퓨터 프로그램이 이해할 수 있게 하지 않았다는 것을 의미한다. 구조화된 데이터는 시맨틱 의미를 첨부하여 더 이해하기 쉽게 만든 데이터이다. 예를 들면, 다음 텍스트 메시지나 이메일에는 구조화되지 않은 데이터가 포함되어 있다.

Hi Joe, call me...my numbers are home – 919-555-1212, office – 919-555-1213, 
cell – 919-555-1213.

이 메시지를 읽으면 인간은 잠재적 의미와 데이터의 의미를 이해하여 집과 사무실과 휴대전화의 번호를 말해 줄 수 있다. 동일한 데이터를 HTML로 표현하면 데이터가 레이아웃을 통해 구조화되어 있고 HTML이 중첩 형식으로 체계화되어 있는 것처럼 보인다. 그러나 여기에는 데이터와 연관된 의미가 없기 때문에 이 데이터는 분석 시스템에 맞게 구조화된 것이 아니다. HTML, 이메일, 텍스트 메시지, 블로그, 비디오 및 오디오는 모두 구조화되지 않은 정보를 나타낸다. 관련된 전화번호 정보를 HTML에 삽입하면 다음과 같이 된다.

<h1>List of Numbers</h1>
<b>HNumber: 919-555-1212</b>
<b>ONumber: 919-555-1213</b>
<b>CNumber: 919-555-1214</b>

HTML은 여기에 기술된 것처럼 구조화되지만, 잠재적 의미를 데이터에 적용하는 구조 유형은 아니다. 분석 처리 시스템이 관련되어 있는 한, 이 데이터는 여전히 구조화되어 있지 않은 것이다. 더욱이 스키마 없이 XML을 사용한 경우에는 HTML과 마찬가지로 데이터가 구조화되지 않은 것이다.

<List of Numbers>
<HNumber>919-555-1212</HNumber>
<ONumber>919-555-1213</ONumber>
<CNumber>919-555-1214</CNumber>
</List of Numbers>

XML은 반구조화된 것이라고 한다. XML에서는 데이터의 관계가 구조화되어 있지만, 데이터의 의미와 관련해서는 데이터가 구조화되어 있지 않다. 스키마가 있으면 데이터에 의미를 부가할 수 있는 방법이 있기 때문에 위에 있는 XML이 구조화되어 있다고 말할 수 있다. 스키마가 있으면 HNumber, ONumber 및 CNumber 요소가 각각 집, 사무실 및 휴대전화의 전화번호를 나타낸다는 것을 알 수 있다. 데이터베이스에는 구조화된 데이터도 포함되어 있다. 데이터를 스키마와 함께 행과 열에 저장하면 컴퓨터 프로그램이 데이터의 의미를 이해할 수 있게 된다.

다양한 분석 제품의 가치는 구조화되지 않은 대용량 데이터를 처리하여 잠재적 의미를 발견하는 기능에 있다. 텍스트 메시지, HTML 및 스키마 없는 XML(위에 있는 예제)을 생각해 보자. 이 데이터가 세 개의 숫자 다음에 구분 기호[하이픈(-), 쉼표(.) 또는 공백( )]가 있고 그 다음에 세 개의 숫자와 구분 기호 및 네 개의 숫자가 있는 패턴과 일치하기 때문에 컴퓨터 프로그램은 이 데이터가 전화번호일 가능성이 있다고 판단한다. 노스캐롤라이나의 지역 코드가 919이므로 이 세 개의 숫자가 노스캐롤라이나의 지역 코드라는 것을 추론하기 위해 추가로 처리 작업이 수행될 수 있다. 국가 코드가 있는 국제 번호에 대해서도 비슷한 알고리즘을 생각할 수 있다.

프로그램이 데이터의 의미를 판별하기 위해 사전에 이용할 수 있는 정보가 더 많기 때문에 구조화된 데이터는 더 단순하게 처리된다. 이러한 접근방식은 컴퓨팅 주기를 소모하지 않고도 데이터의 의미를 파악한다는 점에서 더 효과적이다. 그러나 오늘날에는 증가하는 데이터의 대부분이 구조화되지 않은 데이터이기 때문에 시스템에서 이러한 데이터를 효과적으로 처리하여 이 데이터에 내포된 의미를 정확하게 판별할 수 있어야 한다. 예를 들면, 이메일과 텍스트 메시지뿐만 아니라 오디오 및 비디오 스트림은 현재 많이 늘어나고 있는 구조화되지 않은 데이터를 대표하는 것 중 일부에 불과하다. 이러한 유형의 구조화되지 않은 데이터는 줄어들지 않고 계속해서 증가하고 있기 때문에 비즈니스 분석 처리 시스템이 계속해서 성공하려면 이러한 데이터를 효과적으로 처리하는 것이 중요하다.

데이터의 양과 유형 및 속도는 모두 비즈니스 분석 시스템이 직면해 있는 과제이지만, 이러한 문제점을 처리하는 데 커다란 진전이 이루어지고 있다. 몇 주가 걸려야 처리가 가능했던 대용량 데이터 세트를 이제는 몇 분이면 처리할 수 있게 되었다. 데이터가 여전히 사용 중인 동안에도 그리고 장애 복구 기능을 사용하여 클러스터의 용량을 확장하는 중에도 실시간 피드를 효과적으로 처리할 수 있으며, 모든 작업은 범용 시스템에서 수행된다. 이러한 처리 기능을 이용하면 수년 전에는 생각할 수도 없었던 애플리케이션을 작성할 수 있다. 이러한 컴퓨팅 분야의 장점을 극대화하는 데는 소프트웨어 표준이 중요한 역할을 한다.

위로

정의

예측 분석

예측 분석은 다양한 기록 데이터 소스를 사용하여 미래에 발생할 사건이나 행동을 소프트웨어로 예측하는 것이다. 예측에는 예측에 필요한 신뢰성 레벨이 수반된다.

사용 중인 데이터의 분석

"사용 중인" 데이터를 분석하는 것은 데이터가 하드 드라이브나 기타 저장 매체에 저장되기 전에 데이터를 분석하는 것을 말한다. 오늘날에는 수집되는 데이터의 양이 방대하기 때문에 먼저 데이터를 저장해 두었다가 나중에 데이터를 분석하는 것이 불가능한 경우가 많다. 게다가 먼저 데이터를 저장할 공간이 있는 경우에도 데이터를 저장하고 분석하려면 또 다른 시간이 필요하다. 어떤 유스 케이스에서는 이러한 시간 지연을 허용할 수 없는 경우가 많다.

저장되어 있는 데이터의 분석

저장되는 데이터의 양이 방대하기 때문에 데이터를 자세히 확인하여 그 의미를 이해하고 결과를 도출할 수 있는 기술이 필요하다. 많은 데이터가 관계형 저장소나 OLAP 저장소에 저장된다. 그러나 현재 그보다 더 많은 데이터가 구조화된 방식으로 저장되지 않고 있다. 구조화되지 않은 데이터가 폭발적으로 증가하면서 관계형 및 비관계형 데이터 소스와 구조화된 데이터 소스 및 구조화되지 않은 데이터 소스를 분석할 수 있는 기술이 필요해졌다.

비즈니스 규칙

규칙은 비즈니스의 일부 특성을 정의하거나 억제하여 더 지능적인 의사결정을 할 수 있도록 하기 위해 사용된다. 규칙은 애플리케이션 논리 밖에 저장되므로 시스템이 오프라인 상태에 있지 않는 한, 비즈니스 관련자가 이 규칙을 추가하거나 수정하기는 쉽다.

보고

보고는 복잡한 정도가 다양한 사용자 인터페이스 대시보드 형태를 취하고 있다.

위로

주요 표준

이 섹션에서는 데이터 분석을 지원하는 데 필요한 주요 표준과 이러한 표준 간의 관련성 및 가치 중 일부를 설명한다.

UIMA

UIMA(Unstructured Information Management Architecture)는 IBM이 기술위원회 의장으로 있었던 OASIS의 표준이다(참고자료 참조). UIMA는 구조화되지 않은 정보를 처리하여 데이터에 포함되어 있는 잠재적 의미와 관계 및 관련 사실을 파악하여 그 결과를 개방 및 표준 형태로 표현하기 위한 프레임워크이다. 예를 들면, 일반 텍스트를 수집하고 사람, 위치, 조직 및 관계(예: 데이터에 포함되어 있는 "is friends with" 또는 "is married to")를 판별하기 위해 UIMA를 사용할 수 있다. 이러한 결과는 UIMA 표준에 정의되어 있는 데이터 구조로 표현된다.

UIMA에는 UIMA의 역할과 목적을 이해하는 데 도움이 되는 네 가지 용어가 정의되어 있다.

• 아티팩트(Artifact) — 구조화되지 않은 컨텐츠 조각
• 분석(Analysis) — 아티팩트에 시맨틱 할당
• 분석 프로그램(Analytic) — 분석을 수행하는 소프트웨어
• 아티팩트 메타데이터(Artifact metadata) — 분석 프로그램으로 아티팩트를 분석한 결과

구조화되지 않은 텍스트가 상당히 많은 패스트 푸드 식당 설문조사로 구성된 대용량 콜렉션을 생각해 보자. 이 정보는 가장 일반적인 불만 원인을 찾아서 불만이 가장 많은 상점의 이름과 위치를 식별하고 각 불만 유형을 대상으로 가장 많은 불만을 일으킨 상점을 파악하기 위해 분석된다. UIMA를 사용하면 이러한 유형의 정보를 수집할 수 있으므로 불만 유형과 경향을 파악할 수 있다. 또한, 어떤 불만 유형이 더 줄었고 늘었는지를 파악할 수 있다.

원시 설문조사 데이터는 구조화되지 않은 컨텐츠이기 때문에 그림 1에서는 아티팩트(Artifact)로 표현된다(1). 분석은 아티팩트에 의미를 지정하는 과정이다(2). 예를 들면, 상점 15와 38은 디저트에 대한 불만이 가장 많은 반면에 상점 27은 마지막 설문조사 이후에 불만이 반으로 줄어들었다. 일반적으로 분석 프로그램은 이러한 분석을 수행하는 사설 소프트웨어로, 아티팩트 메타데이터를 생성한다(3). 아티팩트 메타데이터는 CAS(Common Analysis Structure)라고 하는 데이터 구조에 포함되어 있다.

UIMA는 분석 프로그램의 상호 운용성을 지원하는 데 그 목적이 있다. CAS를 이용하면 전체 분석 프로그램에서 이러한 결과를 공유할 수 있다. 이러한 접근방식에서는 고객이 UIMA를 지원하는 다양한 도구와 제품 간에 데이터 표현과 인터페이스를 공유할 수 있게 함으로써 고객을 이롭게 한다. 그림 1에 있는 예를 전제로 하면 분석 프로그램은 아티팩트를 분석하는 도구와 함께 상호 운용될 수 있다(이 두 도구에서 UIMA를 지원하는 경우). 이러한 기능을 이용하면 다양한 도구를 상호 운용할 수 있을 뿐만 아니라 고객이 자신들의 구조화되지 않은 데이터를 분석하기 위해 다양한 벤더를 선택할 수도 있다.

UIMA는 원래의 아티팩트 표현과 관계없이 아티팩트와 아티팩트 메타데이터의 공통 데이터 표현을 지원한다. 또한, UIMA를 이용하면 플랫폼과 관계없이 아티팩트와 아티팩트 메타데이터를 상호 교환할 수 있을 뿐만 아니라 독립적으로 개발된 분석 프로그램을 찾고, 재사용하고 작성할 수 있다. 게다가 UIMA는 독립적으로 개발된 분석 프로그램을 상호 운용할 수 있는 기능을 제공한다. UIMA는 이 분야에서는 첨단 기술이며 Apache 오픈 소스 구현에서 지원된다. 2009년 3월 현재 UIMA 1.0 스펙이 완료되었으며 더 이상의 작업은 계획되어 있지 않다. (UIMA 스펙을 가리키는 링크는 참고자료를 참조한다.)

PMML

PMML(Predictive Model Markup Language)은 IBM이 기여자로 있는 DMG(Data Mining Group)에서 개발한 XML 기반 마크업 언어이다. (참고자료를 참조한다.) PMML은 기록 데이터를 분석하여 다양한 정보를 얻은 후에 작성한 예측 모델을 표현한다.

예를 들어, 전자통신 회사가 고객이 이동통신 서비스를 위해 그들의 지상 통신선 서비스를 중단할지 여부를 어느 정도 확실하게 예측하기 위해 기록 데이터를 분석하려고 한다고 가정하자. 알고리즘(그림 2의 1)은 기록 데이터를 조사하여 고객이 지상 통신선 서비스를 중단할 가능성이 있는지를 가장 잘 예측할 수 있는 여러 가지 입력 필드(나이, 봉급, 결혼 여부, 집 소유 여부, 교육 수준 등)를 균등화하는 데 필요한 매개변수를 생성한다. 이 알고리즘은 평가 프로세스(3)의 입력이 되는 PMML 모델(2)을 생성한다. 평가 프로세스에서는 특정 고객이 해당 서비스를 중단할 가능성이 있는지 여부를 예측(4)하여 그 결과를 이러한 예측의 신뢰성을 나타내는 척도와 함께 출력한다. 고객을 잃게 될 것이라는 예측의 신뢰성이 높을 수록 더 공격적인 대응을 지시하게 될 것이다.

PMML은 벤더 간에 모델을 공유하는 데 필요한 모델 교환 표준이다. PMML은 독점 문제와 비호환성이 더 이상 애플리케이션 간에 모델을 교환하는 데 장애가 되지 않는다는 목표로 벤더에 독립적인 모델을 애플리케이션에 제공한다. 이러한 기능은 유용하며 사용자는 이러한 기능을 이용하여 한 벤더의 애플리케이션 내에서 모델을 개발하고 또 다른 벤더의 애플리케이션을 사용하여 이 모델을 시각화하고 분석하고 평가 및 사용할 수 있다. PMML은 XML을 기반으로 하는 표준이기 때문에 스펙은 XML 스키마의 형태로 나타난다.

현재 업계에서 PMML을 채택하고 있는 회사의 목록에서 알 수 있듯이 업계에서는 PMML을 강력하게 채택하고 있다. (웹 페이지 링크는 참고자료를 참조한다.)

• Augustus / Open Data Group
• KNIME
• MicroStrategy
• Pervasive DataRush
• Rapid-i
• R/Rattle
• Salford Systems
• SAS
• TIBCO
• Weka
• Zementis

RIF

RIF(Rule Interchange Format)는 IBM이 공동 의장으로 있었던 W3C 표준이다. RIF는 실행 가능한 형태의 비즈니스 규칙을 XML로 표현한다. 비즈니스 규칙은 비즈니스 분석 시스템에서 다양한 방식으로 사용될 수 있다. 규칙은 시스템이 다양한 조건과 입력을 기반으로 취할 수 있는 특정 조치를 판별하기 위해 사용된다. 예를 들면, 저당권 대출 회사에는 고객이 대부를 받을 만한 자격이 있는지를 판별하는 규칙이 있다. 수입, 부채 및 신용 점수와 같은 요소가 역할을 하게 된다. 이 규칙에는 대출자의 수입이 X를 초과하고 부채는 Y 미만이며 신용 점수는 Z를 초과하는 경우, 대출자는 주어진 대부 금액을 받을 수 있는 자격이 있다라고 규정되어 있을 수 있다. 규칙을 작성하는 방식은 벤더마다 다르지만, RIF를 이용하면 상호 운용이 가능한 공통의 실행 가능 형식으로 규칙을 작성할 수 있다.

RIF는 주로 규칙 엔진 간에 규칙을 교환하기 위해 설계되었다. RIF는 규칙 벤더에 속박되지 않도록 하면서 규칙 실행 시스템 간에 상호 운용성을 제공한다는 점에서 가치가 있다. 이러한 상호 운용성을 이용하면 RIF를 지원하는 다양한 규칙 실행 시스템과 상호 운용할 수 있는 고유한 비즈니스 규칙을 다양한 도구를 사용하여 작성할 수 있다.

RIF는 2010년 6월에 W3C 권장사항이 되었다. 그러므로 다음 RIF 참조 구현 목록에서 알 수 있듯이 업계에서 이 RIF를 채택하기 시작했다. (웹 페이지 링크는 참고자료를 참조한다.)

• SILK
• OntoBroker
• fuxi
• Eye
• VampirePrime
• RIFle
• Oracle (OBR)
• STI Innsbruck (IRIS)
• riftr
• WebSphere ILOG JRULES
• TIBCO
• FICO
• Drools

이러한 구현은 개발되었을 때 RIF 표준으로 되어 있었다. 이러한 회사 중 여러 곳에서 완전한 표준을 구현할 수도 있지만, 이점은 확실하지 않다.

XBRL

XBRL(eXtensible Business Reporting Language)은 XML을 기반으로 하는 표준으로 XBRL International에서 개발했으며 재무 보고를 위해 사용된다. 다양한 정부와 국가에서 XBRL을 재무 보고서를 제공하는 데 필요한 표준 형식으로 채택 및/또는 지시했다는 점에서 XBRL은 관련이 있다. XBRL을 사용하는 경우가 증가하면서 XBRL 문서와 이 문서에 포함되어 있는 데이터를 분석하는 작업이 관련된다.

전통적으로 보고서는 HTML이나 PDF로 생성되었다. 이러한 형식은 사람이 읽기는 쉽지만, 구조화되어 있지는 않다. XBRL은 잘 알려진 스키마와 함께 XML로 제공된다는 점에서 구조화되어 있는 것이지만, 사람이 읽기는 어렵다. 그러므로 컴퓨터 프로그램으로 문서를 구조화하여 더 유용하게 만드는 과정에서 데이터의 의미를 추론할 수 있다.

최근에 SEC에서는 대형 공기업 중 500개 기업으로 하여금 XBRL을 사용하여 자신들의 재무제표를 정리하도록 요구하기 시작했다. 미래에는 이러한 요구가 소형 공기업에게로 점차 확대될 것이다. 시가 총액이 50억 달러를 초과하는 기업은 2009년에 XBRL로 재무제표를 정리하기 시작했지만, 금년에는 각주를 더 자세하게 달은 재무제표를 제출해야 한다. 시가 총액이 7억 달러를 초과하는 기업은 XBRL로 제무제표를 제출해야 하며 처음에는 각주를 자세하게 달지 않아도 된다. 상장된 모든 한국 기업은 2007년 10월부터 그들의 정기적 및 비정기적 재무 보고서를 XBRL 형식을 사용하여 전자적으로 정리해야 했다. 일본에서는 TSE(Tokyo Stock Exchange)에서 XBRL로 정리하도록 요구하고 있으며, TSE에서는 모든 거래의 90%가 일본 주식 거래소에서 이루어지고 있다고 밝히고 있다. 2008년부터 TSE에서는 나열되어 있는 모든 엔티티가 TSE와 함께 그들의 재무 정보를 XBRL 형식으로 정리할 것을 요구했다.

XBRL은 전 세계에 있는 가장 발달한 경제 기구에서 채택되고 지정되었다. 표 2에는 전 세계에서 XBRL을 채택한 여러 조직이 표시되어 있다.

OWL

OWL(Web Ontology Language)은 정보나 모델의 온톨로지를 표현하는 고급 언어이다. 예를 들면, Joe는 인간이고 Jane과 결혼했으며 남성이다. Sam은 인간이고 Sue와 결혼했으며 남성이고 남편이다. 그러므로 Joe가 남편이라고 추론할 수 있다. XML 스키마에는 잘못된 시맨틱이 있는 경우가 많고 비슷한 사실을 추론하려면 인간의 상호작용이 더 많이 필요하기 때문에 이러한 상호작용이 탐구되고 있다. OWL을 사용하면 프로그래밍 방식으로 지식을 더욱 쉽게 추론할 수 있기 때문에 모델을 교환하고 규칙 기반 시스템에서 이 모델을 사용하는 데 OWL이 유용하다.

위로

시나리오

다음에는 앞에서 언급한 다양한 표준을 사용하는 소매 상점 시나리오를 설명한다.

개요

그림 3에는 이 시나리오의 상위 레벨 컴포넌트가 표시되어 있다. 컴포넌트는 다음과 같은 요소로 구성된다.

• 기록 데이터(저장된 데이터)가 있는 데이터베이스
• 실시간 데이터 피드(사용 중인 데이터)
• 해당 데이터를 분석하는 엔진
• 예측 분석
• 비즈니스 규칙
• 사용자 상호작용을 허용하면서 결과나 경보를 표시할 대시보드를 사용하는 사용자 인터페이스

그림 4에는 앞에서 언급한 다양한 표준이 상호작용하여 상호 운용성 혜택을 제공하는 다양한 컴포넌트(그림 3) 사이에 있는 현재와 미래의 주요 통합 지점이 표시되어 있다. 기록 데이터는 XML, CSV, XLS, PDF, DITA 및 XBRL과 같은 다양한 표준을 사용한다. 분석 엔진은 주로 UIMA를 사용한다. 일반적으로 예측 분석과 비즈니스 규칙은 각각 PMML과 RIF 표준을 사용한다.

시나리오 세부사항

다음에 나오는 여러 가지 그림에는 이 시나리오가 단계별로 묘사되어 있으며 표준을 통해 얻을 수 있는 가치가 잘 기술되어 있다. 표준은 중요한 역할을 하며 특히 이러한 솔루션을 기존의 이기종 고객 환경에 전개할 때는 더욱 그러하다. 이러한 시나리오에서는 기록 데이터와 실시간 데이터를 사용하여 판매를 증대하고 기존 고객을 유지하면서 신규 고객을 끌어들이려고 하는 대형 소매 상점을 위한 솔루션이 묘사되어 있다.

그림 5에는 다양한 데이터베이스에 다양한 데이터 형식으로 저장되어 있는 소매 체인의 기록 데이터가 표시되어 있다. 이 시나리오에는 고객 트랜잭션 데이터, 구매 선호도, 구매 히스토리, 인구통계학 정보, 설문조사 데이터, 고객 콜센터 기록 등과 같은 데이터가 포함되어 있다. 이외에도 실시간 데이터 피드가 제공된다. 이 피드에는 각 상점이나 지역의 최신 트랜잭션, 각 고객이나 고객 그룹의 실시간 트랜잭션 데이터, 실시간 고객 콜센터 피드, 비디오 감시 피드, 다양한 상점의 위치로 발송 중인 제품 등과 같은 데이터가 포함된다.

연속된 각 그림에서는 음영 효과를 사용하여 새로 추가된 그림의 부분을 표시한다. 그림 6에는 기록 데이터를 분석하여 분석 결과를 구조화된 데이터와 구조화되지 않은 데이터로 제공하기 위해 사용되는 Hadoop이 표시되어 있다. 예를 들어, 이 기록 데이터를 분석하면 특정 고객의 구매 패턴, 구매 선호도, 경쟁업체에 대한 의견 등과 관련된 정보를 얻을 수 있다. 분석 결과를 다른 시스템과 공유하여 상호 운영할 수 있게 하려면 UIMA 표준에 대한 소개 자료를 참고한다.

그림 7에는 실시간 분석 엔진이 소개되어 있다. 이러한 엔진은 사용 중인 실시간 데이터(구조화된 데이터 또는 구조화되지 않은 데이터)를 수집하여 처리한다. 또한, 기록 분석 결과를 실시간 엔진에 제공하여 추가 정보를 찾을 수 있게 도움을 준다. 예를 들어, 기록을 분석한 결과 특정 제품의 판매량이 주말에는 양호하지만, 그렇지 않은 경우에는 저조한 것으로 나타났다고 하자. 게다가 실시간 데이터를 분석한 결과, 특정 제품의 재고가 적어서 주말에는 재고가 바닥날 것으로 보인다. 이러한 상황에서는 재고를 확보하라는 경보가 발생할 수 있다.

또한, 그림 7에는 실시간 분석 엔진과 데이터베이스의 기록 데이터 사이에 양방향 연결이 표시되어 있다. 분석 엔진은 실시간 데이터와 연관시킬 기록 데이터를 사용하며 주기적으로 데이터를 저장하기도 한다. 예를 들어, 실시간 데이터에 고객 콜센터의 오디오 피드가 포함되어 있다고 가정하자. 모든 호출을 1분마다 저장하고 싶지는 않지만, 나중에 품질을 검토하기 위해 무작위로 호출을 저장하고 싶다. 시스템이 화가 난 고객을 발견하는 호출은 나중에 검토하고 분석하기 위해 기록된다.

그림 8에는 이 시나리오에 포함된 예측 분석이 표시되어 있다. (그림 8의 확대 이미지 보기) 모델링 도구는 PMML로 예측 모델을 작성하는 데 사용된다. 이 PMML 모델은 데이터베이스에 저장될 수 있으며 실시간 분석 엔진에 의해 인식된다. 예를 들면, 이 경우에는 실시간 및 기록 데이터에 있는 일련의 특정 사실이 고객의 충성도에 변화를 일으켜서 고객이 경쟁사에서 제품을 구매하게 될 가능성이 있는지를 예측 PMML 모델을 사용하여 판별할 수 있다. 실시간 분석 엔진은 데이터를 처리하므로 밝히려고 하는 사실을 이 모델을 사용하여 평가한다. 이러한 평가를 통해 분석 엔진은 처리 중인 데이터에 관한 추가적이고 자세한 정보를 제공할 수 있다.

새로운 PMML 모델을 분석 엔진에 실시간으로 주입할 수 있다는 사실을 그림 9에서 확인할 수 있다. (그림 9의 확대 이미지 보기) 새로운 모델을 작성하여 시스템이 실행 중인 동안에 현재 수집되고 있는 데이터를 기반으로 이 모델을 배치할 수 있다는 점에서 이러한 주입은 강력한 개념이라고 할 수 있다.

그림 10에는 비즈니스 규칙을 해당 시나리오에 배치하는 과정이 소개되어 있다. (그림 10의 확대 이미지 보기) 실시간 분석 엔진이 유입 데이터와 기록 데이터를 처리하여 판매 경향을 찾으려고 하는 중이므로, 추가로 지능적인 의사결정을 하기 위해 비즈니스 규칙 관리 시스템에서 작성된 규칙을 분석 엔진이 호출한다. 예를 들면, 규칙에 "고객 A, B 또는 C(Gold 고객의 일부)가 최근 N일 동안 제품을 구매한 적이 없고 설문조사 데이터에 이 고객들이 경쟁사로 이동할 가능성이 있는 것으로 나타나면 이 고객들에게 특별한 할인을 제안한다"라고 규정되어 있을 수 있다.

또한, 그림 10에는 표준 RIF가 표시되어 있다. RIF는 실행 가능한 형태의 규칙을 표현하기 위해 사용된다. 이러한 형식을 이용하면 벤더의 규칙 시스템이 규칙을 공유할 수 있어서 고객이 특정 규칙 벤더에 속박되지 않게 된다.

새로운 예측 PMML 모델을 실시간으로 주입하는 과정이 그림 9에 묘사되어 있듯이 그림 10에서는 새로운 규칙을 실시간으로 주입하는 과정이 표시되어 있다.

그림 11에는 대시보드와 시각화 기능이 어떻게 활용되는지가 표시되어 있다. (그림 11의 확대 이미지 보기) 처리 중인 실시간 정보와 전통적인 데이터베이스나 OLAP 데이터베이스에 저장되어 있는 기록 데이터를 결합하여 실시간 경보나 정보 대시보드로 표시함으로써 이러한 기능을 작성할 수 있다.

위로

요약

수집된 데이터와 사용 가능한 데이터가 폭발적으로 증가하고 이러한 데이터에서 새롭고 추가적인 정보를 얻으려는 기대가 생겨나면서 이전에는 상상할 수도 없었던 정도의 데이터를 효과적으로 처리하고 분석하여 이해하려는 활동이 진행되고 있다. 이러한 목표를 달성하려면 다양한 시스템과 기술이 레거시 및 새 시스템에서 함께 작동하도록 해야 한다. 기술을 서로 통합하려면 데이터, 제품 및 기술을 통합하여 기업과 고객이 기대하는 목표를 효과적으로 달성하는 데 필요한 상호 운용성을 가능하게 하는 표준이 있어야 한다.

참고자료

교육

• ShotSpotter: ShotSpotter 웹 사이트를 방문하자.
  
  
• PMML Powered: Data Mining Group의 호의로 PMML을 채택한 회사의 목록을 확인하자.
  
  
• Hadoop Sorts a Petabyte in 16.25 Hours and a Terabyte in 62 Seconds: 정렬을 벤치마크한 결과와 규칙을 자세히 읽어보자.
  
  
• Implementations - RIF: W3C에서 받은 구현 보고서를 요약한 내용을 확인하자.
  
  
• OASIS Unstructured Information Management Architecture(UIMA) TC: OASIS에서 UIMA 프로젝트와 스펙으로 시맨틱 검색과 컨텐츠 분석을 표준화하는 방법을 자세히 읽어보자.
  
  
• Apache UIMA: 문서와 소스 코드를 통해 Apache UIMA 프로젝트에 관해 배우자.
  
  
• PMML 4.0 - General Structure of a PMML Document: Data Mining Group에서 XML을 사용하여 PMML 프로젝트와 스펙으로 마이닝 모델을 표현하는방법을 탐구하자.
  
  
• RIF: W3C에서 RIF 프로젝트와 스펙을 확인하자.
  
  
• XBRL: 비즈니스 데이터와 재무 데이터가 전자적으로 통신하는 데 필요한 언어를 자세히 배우려면 XBRL International에 있는 XBRL 프로젝트와 스펙을 확인한다.
  
  
• Apache Hadoop 프로젝트: 전체 클러스터에 있는 대용량 데이터 세트를 분산 처리할 수 있는 Hadoop 프레임워크를 배우자.
  
  
• OWL Web Ontology Language Overview: W3C에서 웹 온톨로지 언어를 자세히 읽어보자.
  
  
• XML 입문 XML을 배우는 데 필요한 참고자료를 얻자.
  
  
• developerWorks의 XML 영역: XML 분야의 기술을 향상시키는 데 도움이 되는 참고자료를 확인하자. XML 기술 자료에서 다양한 기술 관련 기사와 팁, 튜토리얼, 표준 및 IBM Redbook을 볼 수 있다.
  
  
• IBM XML 인증: XML 및 관련 기술에 대한 IBM 인증 개발자가 되는 방법을 찾아볼 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트: 이러한 세션에 참가하여 최신 기술에 대한 정보를 얻을 수 있다.
  
  
• Twitter의 developerWorks 페이지: 오늘 가입하여 developerWorks 트윗을 팔로우하자.
  
  
• developerWorks 팟캐스트: 소프트웨어 개발자의 흥미로운 인터뷰와 토론을 확인할 수 있다.
  
  
• developerWorks on-demand demos: 입문자를 위한 제품 설치 및 설정 과정에서 숙련된 개발자를 위한 고급 기능의 활용에 이르기까지 다양한 데모를 제공한다.
  
  

제품 및 기술

• IBM 제품 시험판: IBM SQA Sandbox의 온라인 시험판을 다운로드하거나 살펴보고 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다.
  
  

토론

• XML 영역 토론 포럼: 여러 XML 관련 토론에 참여해 볼 수 있다.
  
  
• developerWorks 커뮤니티: 개발자가 운영하고 있는 블로그, 포럼, 그룹 및 위키를 살펴보면서 다른 developerWorks 사용자와 의견을 나눌 수 있다.
  
  

필자소개

Peter Haggar는 노스캐롤라이나주 RTP(Research Triangle Park)에 있는 IBM에서 수석 기술원으로 근무한다. 최근에는 비즈니스 분석, 새롭게 부각되는 소프트웨어 표준, XML, 2진 XML 및 웹 서비스 관련 작업을 수행했다. 현재는 Watson과 DeepQA에 초점을 맞춘 신흥 인터넷 기술과 관련된 작업을 수행한다. 그는 IBM에서 20년 넘게 근무했다. 이메일 주소는 haggar@us.ibm.com이다.

아티클 순위

의견

위로

목차

• 개요
• 비즈니스 분석이란?
• 데이터 분석
• 정의
• 주요 표준
• 시나리오
• 개요
• 요약
• 참고자료
• 필자소개
• 의견