서론

이 포스트에서는 현재까지 얻은 데이터 거버넌스에 대한 이해와 실무에서 AD-HOC 업무를 수행하며 겪는 어려움을 기반으로 데이터 거버넌스가 무엇인지 정리하고 거버넌스 내의 데이터 카탈로그를 통해 데이터를 자산(상품)화하는 것으로 어떻게 AD-HOC성 업무를 최적화 할 수 있는지 알아봅니다.

처음으로 데이터 거버넌스에 대해 연구하고, 현재 재직중인 회사에서 이러한 이론을 적용하고자 하는 상황에서 많은 어려움 겪고 기존 레거시 환경에 대해 우선순위를 혼동하며 조금씩이나마 개념을 확립해나가며 적는 글로써 부족한 글 일지라도 많은 엔지니어분들께 도움이 되고자 합니다.

데이터 거버넌스

데이터 거버넌스를 정의하는 글은 많습니다. 하지만 공통적으로 포함 된 키워드는 바로 “데이터 보안, 개인정보 보호, 사용성, 가용성, 정확성” 입니다. 데이터 거버넌스란 이러한 키워드를 보장하기 위해 수행하는 모든 작업을 일컫습니다.

문제점은 이러한 영역이 너무나 광범위하다는 점입니다. 설명으로 알 수 있지만, 데이터 거버넌스는 단순히 어떠한 데이터를 어떻게 생성하고 어떻게 제공 할 것인지를 넘어서 해당 데이터가 얼마나 사용되는지, 얼마나 정확한지, 포함되지 않아야 하는 데이터가 포함되어 있는지, 얼마나 오랫동안 저장 될 것인지 등을 모두 포함합니다.

데이터 거버넌스는 즉 데이터의 생성부터 제거까지 모든 과정에 대한 거버넌스(= 관리 방식)이라고 생각 할 수 있습니다. 이러한 거버넌스를 잘 정리해놓으면 마치 숙련된 직원이 소비자가 원하는 상품을 빠르게 찾아주고, 문제가 발생했을 때 침착하고 정확하게 대처 할 수 있듯이 데이터 팀의 팀원들도 사용자인 비즈니스 관계자가 원하는 데이터를 빠르게 찾아주고, 문제가 발생했을 때 침착하고 정확하게 대처 할 수 있게 됩니다.

저는 여기에서 더 나아가 데이터 팀에서 가장 어려움을 겪는 AD-HOC 성 업무의 효율로 문제의 범위를 줄여서 이야기를 하고자 합니다. 최근 많은 AD-HOC성 업무가 발생하는데에 있어서, 거버넌스의 미흡으로 인해 많은 리소스 낭비가 발생 한 경험이 있습니다. 그 문제에 대한 앞으로의 방향성을 짚어보기 위해 AD-HOC 업무를 바탕으로 글을 적어보겠습니다.

숙련된 직원이 찾아주는 상품과 같이 앞으로 데이터를 초콜릿이라는 특정한 상품으로 생각하고 비유를 통해 이해도를 높여보도록 하겠습니다.

AD-HOC 성 업무란

흔히 특정 상황만을 위한 업무를 AD-HOC 업무라고 부르고 있습니다. 예를들면 모회사에 자회사의 성과를 표현하기 위한 목적만을 위해 만드는 리포트가 이러한 AD-HOC 업무라고 볼 수 있습니다.

이렇듯 특정 목적만을 위한 업무이기에 AD-HOC 업무가 가진 문제점이 있습니다. 그 문제점은 다음과 같습니다.

• 특정 목적만을 위해 만들어지기에 재사용이 거의 불가능합니다. 혹은 재사용해서는 안됩니다.
• 특정 목적에만 정답인 경우가 있습니다.
• 목적의 변화에 따라 업무의 방향성이 쉽게 바뀝니다.

이 외에도 많은 AD-HOC성 업무의 문제점이 있습니다.

데이터에 관련한 용어가 아닌 다양한 업종에서 사용되는 용어이면서 동시에 그리 긍정적이지 않은 용어로 사용되고 있습니다만 사실 AD-HOC 업무 자체가 무조건적으로 좋지 않은 방향성은 아닙니다. 오히려 BI 측면에서 AD-HOC 업무는 빠른 의사결정을 위해 가장 중요하다고 생각되어지기도 합니다. 이 내용을 잘 짚어주는 글이 있습니다.

BI 측면에서 AD-HOC 업무는 매우 중요합니다. 하지만 BI 측면의 AD-HOC 업무를 특정한 데이터 분석의 전문가만이 수행해서는 안되고, 데이터를 필요로 하는 사용자도 간단한 분석을 수행 할 수 있어야 한다고 최근 데이터 트렌드에서는 말합니다. 이러한 환경을 바로 “데이터 민주화” 그리고 “셀프서비스”라는 단어로 표현되어집니다. 이러한 환경을 구축하기 위해 우리는 데이터 거버넌스를 보장 할 수 있는 환경을 잘 만들어야 합니다.

데이터 거버넌스의 필요성

개인적인 의견으로는 데이터 거버넌스를 확립해야하는 이유는 “데이터 팀에게 데이터는 곧 상품이기 때문” 이라고 생각합니다. 흔히 대한민국의 많은 데이터 팀은 데이터를 마치 수작업(Hand-made)으로 만든 상품으로 생각합니다. 수작업 상품의 이미지는 대체로 고급스럽고 비싸며, 맞춤형이고, 희소한 이미지입니다. 하지만 대부분의 데이터는 그렇게 소비되지 않고 데이터의 범위와 양은 시간이 갈수록 커져가고 있습니다. 즉, 생산량은 늘고 있습니다. 데이터 팀은 수작업 데이터 작업을 최소화하고 가능한 범용적이고 대량 생산이 가능한 기성품으로 만드는 것을 목표로 해야 합니다.

대부분의 소비자는 초콜릿을 구입할 때 정확히 원하는 수준의 당도를 가진 초콜릿을 꼼꼼하게 따져가며 요청하지 않습니다. 마트에서 적당히 자신이 원하는 당도에 맞거나, 양이 맞거나, 조건이 맞는 초콜릿을 구매해서 편하게 소비합니다. 소비자 본인은 까다로운 소비자라고 생각할지라도 소비하는 패턴은 대체로 기성품에 가까우며 우리가 기성품을 소비하는 이유가 바로 그런 니즈를 적당히 충족시켜 줄 기성품이 있기 때문입니다. 즉, 목적에 맞는 기성품(범용적인 것)이 있다면 수작업으로 만들 상품은 많지 않다는 의미 입니다.

수작업 데이터는 다양한 별개의 사항을 가지고 있습니다. 극히 제한적인 사용 부서, 개인정보 보호 및 보안의 개별적인 레벨, 원천에 가까운 데이터의 의존관계, 제한적인 목적을 위해 만들어졌기에 파생 데이터 작성의 어려움, 작은 비즈니스 변화로 인한 세부 쿼리의 잦은 변화 및 사이드 이펙트 취약 등이 있을 수 있습니다.

보통 AD-HOC 업무가 이러한 수작업 데이터의 대표적인 예시 입니다. 물론 이러한 업무는 중요한 업무 일 수 있고 이로인해 많은 비즈니스적인 인사이트를 얻을 수 있음은 사실입니다.

하지만 저의 생각에 다음의 상황이 발생하면 데이터 거버넌스를 보장해야하는 상황이 아닐지 고려해봐야 할 것 같습니다.

• AD-HOC 업무가 너무 많이 발생한다.
• 하나의 AD-HOC 업무가 너무 오래 걸린다.
• 이전에 비슷한 AD-HOC 업무를 처리 한 경험이 있다.
• AD-HOC 업무로 얻은 지표에 대해 신뢰성이 의심된다. 혹은 검증까지 너무 오랜 시간이 걸린다.
• 이 외에도 다양한 상황

이러한 모든 상황은 결국 데이터의 사용성, 정확성이 떨어지기 떄문이라고 의심 할 수 있습니다. 데이터의 사용성과 정확성을 보장하기 위해 우리가 알아야 하는 개념은 바로 데이터 카탈로그입니다.

데이터 카탈로그로의 확장

데이터 거버넌스를 알아가다보면 데이터 카탈로그에 대한 개념이 필수적으로 등장하게 됩니다. 여기서 카탈로그는 상품에 대한 안내서, 상품 목록으로 생각하면 쉽습니다. 데이터 카탈로그를 만드는 이유를 다음의 문장으로 표현합니다. 이 문장은 대부분의 관련 논문이나 기업 내 정의 문서에서도 비슷하게 사용됩니다.

“데이터를 자산화한다.”

즉, 데이터 카탈로그를 구축하기 전까지 우리가 쌓는 데이터는 자산(상품)으로 활용되기 어렵다는 의미입니다. 저는 “자산”이라는 단어를 데이터 팀 입장에서 데이터 사용자에게 제공하는 상품이라고 생각하고 상품을 판매하는 과정에서의 사용성과 정확성을 기반으로 이후 내용을 이어나가겠습니다.

저는 데이터 거버넌스가 필요 한 이유는 데이터가 곧 상품이기 때문이라는 말을 했습니다. 상품에 대한 목록이나 안내서가 없다면, 상품은 제대로 된 가치를 가질 수 없다는 것은 직관적으로 알 수 있습니다.

예를들어 낡은 가게의 가판대 구석에 고디바 초콜릿이 놓여있을 때, 이 초콜릿이 고디바 초콜릿인지 목록에 적혀있지 않고 어떤 재료로 어떻게 만들어졌는지에 대한 안내서가 없으면 그 초콜릿은 저렴한 다른 초콜릿과 다르지 않는 가치가 낮은 초콜릿이 됩니다. 이러한 현상은 데이터를 다루는 과정에서도 자주 발생합니다.

우리는 일회성으로 사용 한 테이블과 마케팅의 성과를 명확하게 측정 할 수 있도록 정확한 조건으로 만들어진 테이블이 카탈로그가 적절히 적혀 있지 않아서, 회사의 성과를 나타내는 특정 지표를 얻어 낼 때 활용 할 데이터를 혼동합니다. 왜냐하면 두 데이터는 비슷한(정확히는 다를 수 있지만, 우리는 그 차이를 알 수 있는 정보가 부족한) 정보를 담고 있고, 어떤 데이터를 어떻게 가공했으며, 어떤 목적으로 만들어졌는지와 같은 메타데이터를 카탈로그화 하지 않았기 때문에 실제 해당 테이블을 만든 작업자의 지식 밖에서는 두 테이블은 모두 사용 가능하기 때문입니다.

데이터 카탈로그에 대한 내용은 “데이터 카탈로그 만들기”라는 책을 통해서 공부를 이어나가고 있으며 관련 내용은 블로그 포스트로 지속적으로 업데이트하고 있습니다. 이 내용은 Data Lake 환경에서 데이터 카탈로그를 구축하는 방법과 유의 할 점을 위주로 적혀있습니다.

데이터 카탈로그를 만드는 것은 단일 시점에서의 데이터들을 상품화하는 것을 말하지 않습니다. 모든 메타데이터의 적재가 “자동화”되어야 하고 심지어는 데이터의 태그와 검색 우선순위까지 자동화되어야 합니다. 그렇게 회사의 모든 데이터가 “상품”으로서 활용되도록 노력해야하고, 모든 데이터가 회사의 상품이 되면 데이터의 활용 측면(주로 BI측면)에서 더 높은 가치를 추구하는 발판이 될 수 있습니다.

데이터 카탈로그 구축을 선행

데이터 거버넌스에 대한 관심이 높아지고 심지어 관리를 시작하려는 시점이라면 거의 대부분의 경우 이미 어느정도의 카탈로그가 있는 상태라고 볼 수 있습니다.

카탈로그라는 모호함이 느껴지는 단어를 사용하지만, 결국 상품의 목록과 안내서라는 측면에서 우리가 사용하는 데이터 플랫폼 내의 스키마에 대한 정보, 테이블에 대한 정보 등이 모두 카탈로그이기 때문입니다. 그리고 개발 초기부터 거버넌스를 염두하지 않은 데이터 환경을 구축했다면 이상적인 데이터 카탈로그를 쌓고 있지 않았음을 깨달을 수 있습니다.

만약 데이터 카탈로그가 제대로 구축되지 않은 환경이라면 데이터 거버넌스를 거의 보장 할 수 없는 환경에 있을 것 입니다. 그 이유는 데이터 카탈로그를 통해 우리가 “상품화” 한 데이터가 바로 거버넌스로 관리 할 대상이기 때문입니다. 우리는 유통기한이 지난 초콜릿(현재 사용하지 않거나, 관리 할 필요가 없는 데이터)를 모두 쓰레기통에 버리고 상품으로 가치가 있는 초콜릿(데이터)을 사용자의 눈에 잘 보이는 가판대(마트나 웨어하우스)에 놓아야 합니다.

데이터 카탈로그를 구축하기 위해, 즉 데이터를 상품으로서 사용하기 위해서 관리해야 할 데이터들이 있습니다. 이러한 내용에 대해서는 데이터 민주화와 셀프서비스에 대한 책을 읽으며 정리한 포스트가 도움이 될 것 같습니다. 포스트에 있는 내용 뿐만 아니라 특정 데이터에 대해 적절한 메타데이터를 적어놓아야 합니다.

하지만 이 주제에 대해 첫 문장처럼 대부분의 경우 이미 어느 정도의 카탈로그가 있는 상황입니다. 이러한 카탈로그를 새로운 정책에 맞추어 자동으로 구축해주는 시스템을 처음부터 만드는 것과 이미 만들어진 개별의 카탈로그를 특정 정책에 맞추어 변경하는 것은 크게 다를 수 있습니다. Redshift의 pg_catalog 스키마에 자동으로 적재되는 카탈로그들과 RDB에 자체적으로 관리되어지는 스키마 정보, HDFS 또는 S3에서 관리하는 파일에 대한 정보 등은 모두 다른 형식으로 가지고 있고 개별의 키(버킷 등) 정책, 분류체계, 목적등을 가지고 있을 가능성이 있습니다.

이 경우 하나하나 모든 데이터에 대한 의존성을 찾아가기에는 어렵습니다. 시간이 흐를수록 그 어려움이 더욱 커지는 것 또한 당연합니다. 그러면 어떻게 기존에 어느 정도의 메타데이터가 각 데이터 플랫폼에 분산되어 저장되어 있을 때 제대로 된 카탈로그를 구축 및 관리 할 수 있을까요?

저는 이러한 어려움을 데이터 디스커버리의 구축을 선행하면서 어느정도 해소 할 수 있다고 생각합니다.

데이터 디스커버리 구축의 선행

일반적으로 데이터 디스커버리 툴은 빠른 데이터의 검색을 위해 존재합니다. 그로인해 비즈니스 관계자들은 자신이 원하는 데이터가 이미 있는지, 혹은 어떻게 쿼리 할 수 있는지를 검색을 통해서 얻을 수 있으며 해당 데이터가 만들어지기까지의 계보(Lineage)를 제공하기에 특정 테이블의 변화로 인해 발생 할 수 있는 영향을 빠르게 추적 할 수 있습니다.

우리는 이러한 데이터 디스커버리 툴을 선행하여 적용하는 것으로 많은 이점을 가져 갈 수 있습니다.

• 데이터 현황 파악
• 기존 데이터의 계보를 통한 플랫폼 이전 시 안정성 확보
• 메타데이터의 중앙 집중적 관리
• 오너십을 통한 데이터 관리 주체 설정
• 데이터 사용자 경험 최적화
• 도메인 및 태그를 통한 데이터 속성 분리
• 관련 히스토리 및 쿼리 등의 기록

이 외에도 많은 장단점이 있지만 생각나는 내용에 대해서 적으면 위와 같습니다. 보통 데이터 카탈로그가 적절히 적재 된 뒤에 데이터 디스커버리 플랫폼을 구축하는 것이라고 생각 할 수 있지만, 제가 데이터 디스커버리 플랫폼을 먼저 구축하는 것이 좋다고 생각 한 이유는 바로 “데이터 현황 파악” 과 “계보에 대한 파악” 이 가능하기 때문입니다.

우리는 데이터 카탈로그를 구축하는 과정에서 다양한 데이터 플랫폼을 함께 적용 할 가능성이 높습니다. HDFS를 사용하면 HIVE 기반의 개별적인 메타데이터 스토리지를 구축 할 수 있고, Glue Catalog와 같은 클라우드 플랫폼을 활용 할 수 있습니다. 이 과정에서 몇몇 데이터의 경우에는 더 적절한 플랫폼으로 이전 할 수 있고, 필요 없는 데이터를 파악하고 삭제하거나 더 이상 사용되지 않음을 표시 할 수 있습니다. 이 때 데이터 디스커버리를 활용하면 이러한 데이터를 보다 쉽게 파악 할 수 있습니다.

우리는 다양한 환경에서 만들어진 카탈로그를 한 디스커버리 플랫폼에서 시각화함으로써 어떤 데이터가 필요 없는지를 빠르게 판단하여 데이터를 제거하거나, 메타데이터를 하나의 플랫폼에서 동일한 환경에서 제공 및 시각화 할 수 있습니다.

AD-HOC 업무에 대한 데이터 카탈로그의 영향

그러면 이전에 알아본 AD-HOC 업무에 대한 문제를 기반으로 데이터 카탈로그 구축 및 거버넌스를 보장함으로써 어떻게 문제를 해결 할 수 있는지 알아보도록 하겠습니다.

AD-HOC 업무가 너무 많이 발생한다.

이 경우 BI 데이터의 소비가 많아지는 상황이기 때문에 사업이 확장되거나 회사 내 부서들의 다양한 측면으로 KPI를 설정했다는 좋은 영향일 수 있습니다. 하지만 확실한 것은 “데이터 사용자가 간단한 쿼리도 스스로 할 수 없는 상황”임이 확실해보입니다.

간단한 초콜릿은 소비자도 만들 수 있습니다. 우리는 발렌타인데이에 초콜릿을 만들 수 있는 중간 재료인 카카오 매스 혹은 조금 더 가공 된 커버춰 초콜릿 등이 실제 마트에서 파는 초콜릿의 판매 비중을 어느정도 줄인다는 것을 알고 있습니다. 이렇듯 우리가 데이터를 만들기 위한 중간 데이터를 잘 갖추어놓으면 이러한 문제를 해결 할 수 있습니다.

갖추어진 중간 데이터로 사용자가 직접 만든 데이터는 정확히 사용자가 원하는 수작업 데이터입니다. 이러한 환경이 갖추어진 경우 데이터 팀에서는 이러한 수작업 데이터를 직접 만들기 위해 사용자와의 불필요하게 길고 모호한(심지어 자신이 어떤 데이터를 원하는지 제대로 인지하지 못하는 상황에서의) 커뮤니케이션이 필요하지 않게 됩니다. 이러한 작업이 가능한 환경이 데이터 민주화이며, 이러한 작업을 셀프서비스라고 합니다. 데이터 민주화를 위해서는 데이터 카탈로그가 필수적으로 보장되어야 합니다.

하나의 AD-HOC 업무가 너무 오래 걸린다.

이러한 문제도 많은 AD-HOC 업무 발생과 비슷하게 “사용성” 문제 일 가능성이 높습니다. “우리는 하나의 카카오를 하나의 공정을 통해 곧바로 하나의 초콜릿을 만들고 있는 것이 아닐까?” 하는 의심이 필요합니다. 사실은 이미 만들어진 카카오 매스와 커버춰 초콜릿을 녹여서 만들면 해결 될 수 있을지 모릅니다.

카카오(원천 데이터)에서 하나의 초콜릿(대시보드에 가까운 데이터)을 만드는 과정을 하나의 공정으로 작업하는 것이 좋은 방식이 아니라는 것은 알고 있을 것이라 생각합니다.

데이터 카탈로그가 구축되어 있으면, 우리는 결과(AD-HOC 업무를 통해 추출 될 대시보드 및 보고서를 위한) 데이터가 어떻게 만들어지는지 과정을 명확하게 알 수 있습니다. 만약 원천 데이터를 활용하여 즉시 AD-HOC 성 데이터를 추출하고 있다면 중간 데이터로 추출하여 저장해놓을 수 있습니다.

단순히 쿼리 및 전처리의 범위가 커서 효율이 떨어지는 문제가 아니라 활용 데이터에 대한 이해도 부족으로 인해 이러한 문제가 발생 할 수 있습니다. 아마 대부분의 경우가 이 문제라고 생각합니다.

활용 데이터의 이해도 부족은 데이터 카탈로그가 구축되어 있다면 쉽게 해결이 가능합니다. 물론 데이터 카탈로그에 해당 데이터의 메타데이터(히스토리, 컬럼 설명, 카테고리 데이터의 분류 등)이 잘 적혀있다면 말입니다. 여기에는 빠른 작업을 위해 사용했던 하드코딩 된 이력또한 마찬가지입니다.

이전에 비슷한 AD-HOC 업무를 처리 한 경험이 있다.

마트에서 초콜릿을 보면 카카오의 함량은 체계화 되어 있습니다. 예를 들면 카카오 56%가 포함 된 초콜릿 옆에 카카오 함량이 57%인 초콜릿이 놓여있지 않습니다. 그리고 56% 함량의 초콜릿이 조금 달다고해서 57% 함량의 초콜릿을 만들지 않습니다.

현재 많은 비즈니스 관계자는 기존에 거의 동일한 지표가 있음에도 1% 추가 함량을 위해 새로운 지표를 만들기를 바라는 경우가 있습니다. 그 이유는 대체로 팀의 성과를 최대화 할 수 있는 방향으로 대시보드를 보고 싶기에 요청 한 것일 가능성이 있습니다.

우리는 초기에 56% 함량의 초콜릿을 만들기 위한 중간 결과물을 만들 때 확실하게 짚고 넘어 갈 점이 있습니다. 바로 “이 함량이 가장 대중적으로 잘 팔릴 수 있는 비율” 이라는 의사결정입니다. 이 결정은 곧 “동일한 정보라면 그 목적이 어떻든 이 데이터를 바라보겠다”는 말입니다.

예를들면 어떠한 게임에 대한 데이터를 얻을 때 현재 해당 게임에서 이탈하지 않은 유저(Active User)에 대한 테이블을 만든다면 우리는 “최근 2주 이내에 접속 한 이력이 있거나, 한 달 내 결제 한 이력이 있는 유저”를 기준으로 정할 수 있습니다. 이러한 유저 군집을 이용하여 마케팅 전략들이 사용 할 수 있습니다. 그런데 갑자기 마케팅 팀에서 다음의 요청을 합니다. “최근 1주 내로 기준을 바꿔주세요.”

이러한 요청을 수락한 경우 이전에 수행 한 마케팅의 성과 지표들은 모두 변경되게 됩니다. 그 모든 작업은 AD-HOC 업무로 전환되어 우리의 일감에 등록 될 가능성이 매우 높습니다. 이러한 문제를 방지하기 위해서 우리는 대중적으로 잘 팔릴 수 있는 의사결정, 즉 해당 지표에 대한 확실한 의사결정을 통해 최대한 고정적인 데이터를 만들어야 합니다. 그리고 의사결정을 통해 정해진 정보를 해당 데이터의 메타데이터에 잘 적재해야 이후 데이터의 정당성을 보장 할 수 있습니다.

AD-HOC 업무의 검증과 신뢰성

초콜릿 공장에서 만들어진 초콜릿이 정확히 원하는 카카오가 사용되었는지, 함량이 정확한지, 무게가 적절한지, 맛이 동일한지에 대해서 검증하기 위해서는 초콜릿이 만들어지는 각 공정에 대한 신뢰성이 필요합니다.

카카오로 카카오 매스를 만드는 과정에서 발생하는 발효, 블랜딩, 기타 공정에서 발생하는 장애를 명확하게 확인 할 수 있어야 합니다. 또한 카카오 매스를 가공해서 시판 초콜릿을 만드는 공정에서 발생하는 장애도 명확하게 확인 할 수 있어야 합니다. 이렇듯 각 공정에서 장애가 발생 했을 때 즉시 이 사실을 알 수 있는 환경을 구축해야합니다.

만약 이 사실을 알 수 있는 환경을 구축하는 것이 어렵다면 “현재 하나의 공정에서 너무 많은 작업을 하는게 아닌가?” 라는 의심을 할 필요가 있습니다. 카카오를 초콜릿으로 만드는 공정을 하나로 만들어버린다면, 우리는 각 공정에서 나온 결과물에 대한 검증을 할 수 있는 시간과 공간이 없습니다. 데이터를 다루는 사람들이 흔히 듣는 말로 “한 번의 변환이 크면 클수록 데이터의 신뢰성은 떨어진다.” 를 염두하여 한 번의 변환에 대한 규모를 쪼개어 계층화하는 것도 좋을 것 같습니다.

위 예시와 마찬가지로 데이터도 각 변환 과정이 명확히 분리되어야하고, 각 과정에서 발생 한 장애등을 정확하게 확인 할 수 있어야 합니다.

정리

1. 의사결정을 위한 BI 데이터를 제공하는 AD-HOC 업무는 필수적이며, 그 업무를 최적화 하기 위해서는 데이터의 사용성과 정확성을 보장해야 합니다.

2. 적절한 중간 데이터를 구축하고 데이터 카탈로그를 통해 자산(상품)화하는 것은 데이터 사용성과 정확성을 크게 향상 시킬 수 있다.

3. 데이터 카탈로그를 통해 데이터를 자산(상품)화 하는 도중 현재 데이터에 대한 현황 파악 및 각 데이터에 대한 영향도를 추정 할 필요가 있으며, 이 경우 데이터 디스커버리 툴은 좋은 길잡이가 될 수 있다.