빅데이터 거버넌스(Data Governance)의 정의 및 목적, 그리고 고려사항(및 도구)들

데이터 팀에서 데이터를 다루다보면, 데이터와 관련된 다양한 이해관계자들(데이터 분석가, 데이터 사이언티스트, 기획자, BI 개발자 등) 사이에서 기술적인 것 외에도 '데이터 접근 관리', '개인정보 데이터 관리', '데이터 품질' 등의 경영이나 문과적(?)인 사항들이 자주 이슈화되는 부분을 경험할 수 있습니다. 이러한 부분이 잘 관리되지 않았을 때, 많은 비용으로 발생하고 업무 시에 많은 시간을 탕진하게 하기도 합니다.

 

저 개인적으로도 데이터플랫폼팀의 '데이터 거버넌스 파트'의 일원으로 '데이터 분석팀', '추천팀', 'BI팀', 'DB개발팀'의 팀 단위의 이해관계자들 사이에서 (기존 데이터 이해관계자가 대부분 한 팀에 뭉쳐있던 구조와 달라) 팀 단위의 커뮤니케이션으로 인해 잦은 병목이 발생하는 상황을 경험하였는데요.

 

그러한 문제들은 흔히 '데이터 거버넌스'라는 명칭으로 광범위하게 정의되었으나, 정확히 어떤 부분들이 존재하고 관리해야하는지 알기 어렵고, 실무를 바라볼 때 의미있을 정도의 문서를 찾기가 쉽지 않았습니다. 

 

이 글에서는 위의 문제를 해결하기 위해 '데이터 거버넌스'에 대한 정의와 목적을 알아보고, 목적을 이루기 위한 고려사항들을 전달하려 합니다.

 

 

글에서 말하는 거버넌스의 범위

 

먼저 범위(scope)을 살펴보면, DG는 크게 매크로(Macro) 및 마이크(Micro)로 레벨 2가지로 구분됩니다: 전자는 국제관계와 인터넷 거버넌스의 정치적 개념이나 규정을 의미하고 후자는 기업 거버넌스에서의 경영 개념이나 규정을 의미합니다 [1].

   

  또한, DG의 실행을 어떠한 도구의 도입 또는 팀의 형성으로 보는 부류도 있지만 [2], [3]에서는 DG는 무언가를 축적해가는 작업이 아니며, DG를 담당하는 거대한 팀이 있어야 하는 것이 아니라 모든 부서에서 업무 프로세스 문화처럼 자리 잡아야 한다고 말합니다. 

 

 아래와 같은 범위와 관점으로 글을 기술하였습니다:

 

• 범위: 기업 거버넌스의에서의 경영 개념이나 규정
• 중점: 개별 기업의 데이터 관리와 그것을 통해 최종적으로 데이터 라이프사이클 전체 과정에서 높은 데이터 품질을 보장하기 위한 활동
• 목적: '데이터 신뢰성'을 제공하는 것 [4]
• 실행: 도구의 도입 및 업무 프로세스 문화 모두 포함하여 '데이터 신뢰성' 개선을 이루는 모든 활동

그렇기에, 아래 글에서 언급되는 DG는 모두 위의 범위와 관점에 한정되어 전개되었습니다.

 

정의와 목적

 DG는 새롭게 탄생한 개념이 아니라, 데이터 분석이 그렇듯, 기업정보관리(Enterprise Information Management)와 같은 기업 경영에 있어 오랜 역사를 가지고 있는 개념에 뿌리를 두고 있습니다 [1]. 그렇기에 자칫 그 개념이 '관리'에 포함되는 많은 것과 혼용되거나, 기술적인 부분과 섞이는 경우가 흔합니다. 시중에 있는 많은 정의들 중에서, 아래에서는 다음과 같은 정의를 사용합니다:

 

Data governance is to provide trust to data. [4]
Data governance is the organization and implementation of policies, procedures, structure, roles, and responsibilities which outline and enforce rules of engagement, decision rights, and accountabilities for the effective management of information assets.

 

먼저, DG는 '데이터를 신뢰'할 수 있도록 개선해가는 활동입니다. 그렇기에 정의 자체에 '데이터 신뢰성(trust to data)'를 제공한다는 목적이 포함되어 있습니다.

 

두 번째의 긴 정의를 살펴보면 정책, 절차, 역할, 책임 등을 조직하고 실행해나가는 활동으로 의사결정, 책임 등의 규정을 적용하여 효율적인 '정보자산' 관리를 위한다고 기술되어 있습니다.

 

(인용한) 2가지 정의가 얼핏 차이가 있어보이나, 그 하위 목적에 유사한 것들로 이뤄져 있습니다. 이 글에서는 [4]에서 언급된 Discoverability, Security, Accountability 3가지로 구분하였습니다:

 

• Discoverability(또는 Transparency): 데이터는 효율적으로 '발견 가능'하고 투명해야 합니다. 좀 더 구체적인 사항들로는 Metadata 제공, Data Lineage, Global Glossary, Data Quality 등이 해당됩니다. 과거의 DG는 아래의 Security와 Accountability에 초점이 많이 맞춰졌다면, 점점 '데이터 상품'이 고도화되면서 이 부분에 있어 많이 요구되고 발전해나가고 있습니다
• Security: 보안은 크게 2가지로 구성되어 있습니다. '개인정보(Personal Information)가 GDPR 등의 규정에 맞게 구분되어 관리되는가(Privacy)?'라는 부분과 '데이터 접근이 권한에 따라 적절히 관리되는가?'라는 2가지 부분인데요. 2번째 항목이 기존의 대부분에 시스템에도 적용되며 일관된 반면에, 전자는 데이터 관련 법률이 많이 추가되고 변경되는 상황이 발생하며 조금 유동적인 특징을 가집니다. 

위 2가지 사항에 해당되는 공통되며 중요한 부분은 '데이터의 분류(Classification)'와 그에 따른 '접근권한관리(Access Control)'를 다루는 Policy의 존재여부입니다(기술적으로 예를 들자면 Apache Ranger에서 그 개념을 잘 구현해두고 있습니다).

 

• Accountability: 위 2가지 사항들을 Accountable하도록 하는 일련의 활동들을 포함하는 활동으로 Data Life Cycle Management, Data Acquisition 프로세스 정립(또는 도구의 도입), User-Policy-Resource 간의 시스템 도입, Audit 등과 같은 사항들이 해당됩니다. 

업무 프로세스, 업무문화, 도구의 도입 등 다양한 범위와 개념이 혼합된 DG는 실제로 실무에서 지속가능한 수준까지 확립되기 위해서는 정말 많은 노력이 필요합니다. 하지만, 데이터 사이즈도 점차 커지며, 기업 내 운영용 또는 판매용 등등 다양한 종류의 데이터가 생기고, 다양한 데이터 관련 이해관계자 직군이 탄생하면서 점차 이러한 DG에 대한 필요성이 커지고 있습니다. 또한, 여러 벤더사가 모인 ODPi(Open Data Platform initiative)와 같은 조직에서 거버넌스에 대한 standard를 만들어가려는 노력도 보입니다.

 

아래에서는 위에서 나열한 3가지의 상세사항들 중 중점적인 사항들을 기술적인 내용과  더불어 살펴보도록 하겠습니다. 

 

728x90

고려사항들

위에서 전달한 것과 같이,  DG에는 기술과 기술 외적인 부분도 결합되어 체계화를 많이 시도했으나 아직까지도 발전해가고 있기에 명쾌하게 정리되지 않은 것 같습니다. Defense(보안, 무결성, 정규화, 접근권한관리 등)와 Offense(분석 최적화, MVOTs(Multiple Versions of Truth) 등)의 이분법적인 관점으로 전달한 HBR 케이스, 3가지 구분(구조적, 운영적, 관계적)으로 관점을 제시한 케이스 [5] 등이 존재하지만, 이 섹션에서는 위의 3가지(Discoverability, Security, Accountability) 관점의 순서로 상세항목은 기술하나 3가지 구분도 아직 명확하지는 않기에 index 형태로 넣지는 않고 나열식으로 적어보았습니다.

 

Metadata Management

"Information about information"으로 일컬어지는 메타데이터에 대한 관리는 '권한이 있는 사용자가 필요한 데이터를 효율적으로 찾고 탐색하고 접근할 수 있도록'하도록 돕습니다. 그러한 형태의 기본적인 예시가 'Data Catalog'라고 불리는 데이터의 위치, 스키마 등을 포함하는 인덱스에 해당되는 서비스입니다(AWS Glue Catalog, Google Bigquery, Hive Data Units, Talend Catalog, Informatica).

 

Apache Hive의 카탈로그의 역할 부분을 대체하며 다른 기능과 함께 통합된 거버넌스 도구로 등장한 Apache Atlas의 특징을 살펴보면, 유연한 설계로 하둡 외의 메타데이터도 지원하며 데이터 타입도 custom 가능한 부분과 UI 제공 등 다양한 거버넌스 기능이 추가된 것을 확인할 수 있습니다. 또한, Lyft의 Amundsen도 스키마 검색 및 페이지 랭킹 기능, 하둡 외의 확장성, Workflow Management 도구와의 연동 등을 추가하며 탐색(discovery)과 각종 이해관계자(데이터 사이언티스트, 데이터 엔지니어, 분석가 등)의 협업 효율화를 강조했음을 알 수 있습니다. Dataframe도 통합된 Data Discovery & Observability를 목적으로 카탈로그에 더한 Data Quality 등의 부분을 더해가는 추세로 보입니다. 

 

위에서 전달드린 기본적 Catalog 외의 고려할 기능들을 나열하자면:

• Data Lineage: Apache Atlas, Amundsen 등 많은 데이터 거버닝을 목적으로 탄생되는 도구들은 대부분 가지고 있는 기능으로, 데이터가 어떤 소스로부터 생성되었는지를 나타내주는 기능입니다. 한눈에 어떤 데이터가 어느 소스를 사용하여 생성되었는지 알 수 있을 뿐만 아니라, 데이터의 오염이 발생했을 때 빠르게 원인을 찾거나(Netflix) 데이터의 사용여부, 데이터 의존관계 등을 파악하는 데에도 큰 역할을 합니다. 어떻게 가공되는지 시스템에서 파악할 수 있어야하기 때문에, 이 부분에서 데이터 거버넌스에 Workflow Management 도구가 포함되거나 연동되는 경우가 많습니다. 예로, Amundsen의 경우 Apache Airflow의 어떤 작업이 해당 테이블을 생성하는지 연동하는 기능이 존재합니다. 

Data Lineage - Image from EWSolutions

• Glossary: 각종 용어에 대한 정의가 Catalog의 코멘트에 기록되기도, 추가적인 시스템에 따로 기록되기도 합니다. 대표적인 Glossary 기능을 강조하는 거버넌스 도구로 Collibra를 볼 수 있습니다.  Clickstream 수집을 위한 '로그정의서' 같은 경우도 많은 용어의 정의가 필요한데, 이러한 서비스들도 통합적인 거버닝 요구가 커지면서 합쳐지는 양상을 보이는 것 같습니다.

Business Glossary in Governing UI - Image from Collibra

• Data Quality [6, 7]: 개인적으로 볼 때, 데이터 퀄리티는 1) 초반에 데이터 수집이 시작되거나, 2) 다루는 데이터가 커지고 복잡해지며 파악이 점점 어려워져 갈 때 많이 이슈화 되는 것 같습니다. 많은 자료조사에서도 데이터 품질이 데이터 상품의 성공을 가르는 중요한 요인 중 하나라고 꼽습니다. AWS Deequ, Apache Griffin, GreatExpectations 등의 DQ 관련 오픈소스도 많이 사용되고 위에서 언급된 바와 같이 Catalog Web UI에 데이터 Profile이 기본적인 기능으로 더해지며 Validation(또는 Check) 등도 점점 시스템으로 편입되어 가고 있는 것 같습니다. 

Data Sentinel - Image from LinkedIn Blog

 

Data Classification and Access Control with Policies

데이터는 잘 구조화 되어 있어야 합니다. 함께 다룰 '접근권한관리' 및 '개인정보보호' 차원에서도 그렇지만 데이터 종류가 다양해지고(운영용, 판매용, 교환용 등) 다양한 데이터 사용자 직군이 효율적이고 편리하게 이용할 수 있도록 하기 위해서도 필요합니다(예로 Databricks의 Bronze, Silver, Gold Tiering).

Data Lake - Image from Databricks

크게 분류할 수 있는 몇 가지 주요 차원을 나열하면:

 

• 개인정보여부: 구현체로는 Google Cloud Data Loss Prevention 또는 AWS Macie 같이 서비스로 제공되는 형태도 있고 일부 오픈소스도 진행되고 있는 것으로 보입니다. 기업의 규모가 커지며 정보보안팀과 같은 역할이 생기고, 개인정보 데이터 관리는 가장 중요하고 필수적인 것이 됩니다. 보통 개인정보컬럼을 아예 분리하거나, 개인정보컬럼을 가진 테이블에 대한 접근권한을 관리하거나(컬럼 레벨 관리가 된다면 컬럼레벨), 개인정보컬럼을 암호화하여 사용하거나하여 관리를 하게 됩니다. Data Lifecycle과 관련이 깊게 일정 기간이상 보관이 불가능하게 되는 경우도 있습니다.

 

• 가공의 정도(또는 정련도): 위 예시와 같이 Bronze, Silver, Gold로 나누어 어떤 그룹은 어떤 정도로 가공되고 완성도가 높은지 나누고 사용할 때의 우선순위, 목적부합성 등에 대한 standard를 제시할 수 있습니다.

 

• 데이터의 용도: 데이터는 내부적으로 사용되기도, 외부 데이터와 교환목적으로 송신되기도, 거래용으로 업로드되기도 합니다. 그에 따라, 데이터 그룹을 나누고 추후 Policy와 연동하여 권한을 관리하거나, Data Lifecycle 적용 시 일정한 디폴트 조건을 적용할 수 있습니다.

위의 '데이터 분류화'는 유저 또는 그룹과 'Policy'를 통해 연결됩니다. Policy는 어떤 주체(유저 또는 그룹)가 어떤 Resource(데이터 그룹) 에 어떠한 형태(읽기, 쓰기 등)로 접근할 수 있는지 나타냅니다(Apache Ranger의 개념 차용). AWS IAM(데이터 접근과 관련), Apache Ranger의 개념들을 참고하시면 실무에 적용할 수 있을 정도의 기반을 배우실 수 있으실 듯 합니다. 

 

[Hands On] 아파치 레인저(Apache Ranger) 도커(Docker) 환경에서 하둡(Hadoop) 서비스(HDFS, Hive, Presto) 연동

 

Data Lifecycle Management(DLM) and Data Procedure

데이터는 생명체와 같이 새로 생성되고, 활동적으로 쓰이고, 점점 쓰임새가 줄어들다가 필요없어지게 되는 라이프사이클을 갖습니다. 데이터 환경은 수많은 데이터가 변화에 따라 라이프사이클의 단계가 변하게 됩니다.

Data Lifecycle Management - Image from Asia Data Destruction

 

데이터의 라이프사이클에서 어떠한 단계로 데이터의 상태를 나눌지, 그리고 그 상태별로 어떻게 관리할지는 데이터 운영자와 데이터 사용자들 간의 구체적인 협의를 통해서 정해집니다. 이 부분에서 데이터 운영자 - 데이터 사용자 간의 업무수행 절차를 말하는 Data Procedure 측면이 가까워지게 됩니다. 상황에 따라 다르겠으나 라이프사이클을 대략적으로 기술하자면 다음과 같습니다:

 

사전

• 요청: 사용자의 필요에 따라 데이터 수집 또는 생성이 요청되고 반영되는 단계입니다. 
• 검토 및 테스트: 사용자의 요청이 적절한지 검토하고(권한, 개인정보여부, 보관주기 등) 수집을 위해 테스트를 해보는 단계입니다.

운영

데이터 수집 이후의 운영을 하게되면서 요청한 데이터 전체(예, 하나의 Hive 테이블) 또는 부분별(예, Hive 테이블의 날짜별 파티션에 따라 다른 단계)로 사용 및 필요에 따라 단계가 결정됩니다. 

• Active: 수집된 데이터가 활발하게 사용되는 단계입니다. 다른 가공을 거치지 못하고 접근하여 raw 형태이거나, 활발하게 접근하기에 최적화한 Parquet, ORC 등의 형태일 수 있습니다. 또한, latency를 위해 데이터가 조금 크더라도 압축율을 조금 손해봐도 좋을 단계입니다.
• Archive: 데이터에 대한 접근 및 사용이 뜸해지면서 archive되는 단계입니다. S3보다 싸면서 접근 속도가 매우 느린 AWS Glacier를 사용하거나, HDFS에서 Erasure Coding을 적용하거나, 자주 접근되지 않기에 높은 압축율을 적용한 파일로 변형하여 보관할 수 있습니다. 
• Deprecated: 데이터가 더이상 사용되지 않거나, 보관주기(데이터 이해관계자 간의 합의를 통해 정하거나 개인정보데이터의 경우 일정 기간 보관만이 가능하여 적용되는)가 지난 폐기되는 단계의 데이터입니다. 

이러한 데이터 라이프사이클에서 중요한 2가지 사항은 1) 자동화 와 2) 데이터 뿐만이 아닌 메타데이터, 데이터 수집 작업 또는 가공 작업 등 또한 라이프사이클 관점에서 관리하기 입니다. 

 

데이터 라이프사이클(함께 고려될 데이터 프로시져)은 처음엔 수작업을 동반할지 몰라도, 고도화되면서 점진적으로 자동화되어야 합니다. 많은 사용자의 요청과 복잡한 데이터를 일일히 검토할 수 없기에(실수도 있을 수 있기에) 기본적인 사항부터 단계별(아래의 자율주행차가 도도화 되듯이)로 자동화를 계획하고 설계되어야 합니다.

  Different levels of automation in a self-driving car - Image from 'The Self-Service Data Roadmap'

두 번째로, 데이터만이 아닌 데이터와 연관되는 모든 리소스들의 라이프사이클이 관리되어야 합니다.

 

개인적인 경험을 전달드리면, 처음 11번가의 데이터 플랫폼에 입사했을 때 마주한 것은 사용하지 않는 1000개가 넘는 Hive 데이터베이스와 100,000개가 넘는 Hive 테이블이었습니다. 수동으로 수많은 리소스를 정리하는 작업은 시스템 부하, 사용여부 파악 등 어려운 점이 많았습니다.

 

그렇기에 데이터 시스템이 고도화되는 시점에는 선제적으로 라이프사이클과 업무 프로시져를 정해서 깨끗하고 건강한 문화와 시스템을 만드는 것이 매우 중요하다는 사실을 절실하게 느꼈습니다.

 

데이터 업무 프로세스는 위에서와 같이 라이프사이클과 관련이 깊으면서, 또 팀 간 RNR, 팀 간의 업무 진행 시 Input과 Output 정하기, 역할 등 넓은 주제가 포함되기도 합니다. 데이터 생성 및 소비 측면의 환경은 이 글에서 자세히 전달드렸고, 이곳에서 데이터 라이프사이클과 관련해서 강조할 부분은 업무 진행에도 interface와 같이 input과 output을 명시하고 어떤 기능이 있고 어떻게 사용할 수 있는지에 대한 명확한 가이드가 제시되어야 한다는 사실입니다. 

 

기업 내의 데이터 환경은 어떤 모습인가: 데이터 생성과 소비

 

 

마치며...

데이터 환경에서 데이터 상품을 만들기 위해 데이터를 찾고, 수집하고, 정제하고, 관리하는 데에 많은 비용이 들어갑니다 [7]. 빅데이터가 존재하기 이전부터 기업 경영에 있어 '정보관리'라는 개념이 존재하였고, IT 환경에서 데이터 환경이 커지고 복잡해지면서 도구가 발달하고 데이터 상품(분석, ML 등)이 다양해지면서 통합적인 거버넌스를 '잘하는' 부분에 대한 관심이 점점 커져가는 듯 합니다. 

 

추후에는 이러한 도구 뿐만 아니라, 이 부분을 중점적으로 담당하는 직무가 생겨 점차 전문화되어 갈지도 모르겠습니다.

 

 

Reference

[1] en.wikipedia.org/wiki/Data_governance

[2] ciowatercooler.co.uk/resources/DataGovernanceSurvey2017.pdf

[3] www.google.com/books/edition/Data_Governance/CpeAYWaTScYC?hl=en

[4] learning.oreilly.com/library/view/data-governance-the/9781492063483/

[5] www.researchgate.net/publication/260584434_Corporate_Governance_of_Big_Data_Perspectives_on_Value_Risk_and_Cost

[6] web.mit.edu/tdqm/www/winter/StrongLeeWangCACMMay97.pdf

[7] engineering.linkedin.com/blog/2020/data-sentinel-automating-data-validation 

[8] medium.com/selectstar/the-evolution-of-data-catalogs-the-data-discovery-platform-1627772ca760

[9] https://info.algorithmia.com/ml-governance-framework