Kwangmin Kim - 데이터 거버넌스란 무엇인가

1 왜 지금 데이터 거버넌스인가

데이터를 잘 관리하자는 이야기는 오래됐다. 그런데 현장에서 실제로 체감하는 문제는 달라진 게 없다. “이 컬럼이 무슨 의미인지 아는 사람이 아무도 없다”, “개발 DB와 운영 DB 스키마가 다른데 언제 어떻게 달라진 건지 모른다”, “고객 데이터를 분석팀에 줬는데 개인정보 처리 기준이 없었다”. 이 문제들은 기술의 문제가 아니다. 조직이 데이터를 어떻게 정의하고, 책임을 어떻게 배분하고, 변경을 어떻게 추적하는가의 문제다.

데이터 거버넌스는 이 질문들에 구조적인 답을 주기 위한 프레임워크다. 그러나 많은 조직에서 데이터 거버넌스를 도입한다고 하면서 실제로는 메타데이터 관리 툴 하나를 구매하거나, 표준 명명 규칙 문서 하나를 만드는 데 그친다. 그렇게 되면 2~3년 뒤 다시 똑같은 문제를 반복하게 된다.

이 글은 데이터 거버넌스를 구성하는 각 영역이 왜 그 형태로 설계되었는지, 각 요소가 서로 어떻게 연결되어 있는지, 그리고 실제 시스템으로 구현할 때 어떤 설계 결정이 필요한지를 현업 개발자와 DA(Data Architect) 수준에서 다룬다. 표면적 기능 설명이 아니라, 각 구조의 숨겨진 설계 의도를 함께 이해하는 것이 목표다.

2 데이터 거버넌스의 정의: 흔한 오해부터 정정하기

데이터 거버넌스를 “데이터 품질 관리”나 “메타데이터 관리”와 동일시하는 경우가 많다. 이것은 부분을 전체로 오해하는 것이다.

DAMA International(Data Management Association)은 데이터 거버넌스를 다음과 같이 정의한다.

데이터 거버넌스란 데이터 자산에 대한 권한과 통제(계획, 모니터링, 집행)의 행사이다. (DAMA International, 2017, Ch.3)

정의: Data Governance (DG)

데이터 거버넌스는 조직의 데이터 자산을 관리하는 모든 정책, 절차, 표준, 규칙 및 책임을 정의하고 관리하는 프레임워크다. DG는 데이터 관리를 직접 실행하는 것이 아니라, 데이터가 적절히 관리되도록 감독과 실행의 분리를 구현한다 (DAMA International, 2017, Ch.3).

범위: 전략 정의, 정책 수립, 표준/품질 관리, 스튜어드십, 규제 준수, 이슈 관리, 자산 가치 평가
핵심 원칙: 지속 가능성(Sustainable), 내재화(Embedded), 측정 가능성(Measured)

이 정의에서 핵심 단어는 세 가지다.

첫 번째는 “권한과 통제”다. 거버넌스는 데이터를 직접 다루는 것이 아니라, 데이터를 다루는 방식에 대한 의사결정 체계를 구축하는 것이다. 감사인(auditor)이 재무 프로세스를 통제하되 직접 재무 관리를 실행하지 않는 것과 같은 원리다 (DAMA International, 2017, Ch.3).

두 번째는 “정책과 절차”다. 단순한 도구나 기술이 아니라 조직의 의사결정 방식 자체를 다룬다는 뜻이다. DMBOK은 데이터 정책을 “데이터의 생성, 취득, 무결성, 보안, 품질, 사용에 대한 기본 규칙을 성문화한 것”으로 정의하며, 정책(what to do)과 표준/절차(how to do)를 명확히 구분한다 (DAMA International, 2017, Ch.3).

세 번째는 “책임”이다. 데이터의 오너십, 즉 누가 이 데이터에 대해 최종 책임을 지는가를 명확히 하는 것이 거버넌스의 출발점이다. DMBOK은 Data Steward를 Chief, Executive, Enterprise, Business, Technical, Coordinating 등으로 분화하여, 조직 내 모든 수준에서 데이터 책임 구조가 작동하도록 설계했다 (DAMA International, 2017, Ch.3).

이 정의를 다시 보면 데이터 거버넌스가 IT 부서의 프로젝트가 아니라 조직 전체의 전략 인프라라는 것이 분명해진다. 툴을 도입한다고 거버넌스가 생기는 게 아니고, 조직이 데이터를 다루는 방식 자체가 바뀌어야 한다. DMBOK은 이를 “데이터 거버넌스는 비즈니스 프로그램이며, IT 의사결정뿐 아니라 비즈니스의 데이터 상호작용까지 거버넌스해야 한다”고 명시한다 (DAMA International, 2017, Ch.3).

3 DAMA DMBOK: 지식 영역의 구조와 상호 의존성

DAMA는 DMBOK(Data Management Body of Knowledge)을 통해 데이터 관리를 구성하는 11개의 지식 영역을 정의했다. 이 영역들은 독립적인 모듈이 아니라 서로 강하게 연결된 생태계다. Data Governance가 중심에 위치하여 나머지 10개 영역을 조율한다 (DAMA International, 2017, Ch.1).

                    Data Governance (중심)
                          |
        +-----------------+-----------------+
        |                 |                 |
   [구조 영역]        [관리 영역]       [활용 영역]
        |                 |                 |
Data Architecture    Metadata          Data Warehousing
Data Modeling        Data Quality      & BI
Data Storage &       Data Security
Operations           Reference &
Data Integration     Master Data
& Interoperability   Document &
                     Content Mgmt

이 구조에서 주목할 점은 Sue Geuens의 프레임워크가 보여주는 의존 관계다. BI와 분석 기능은 다른 모든 데이터 관리 기능에 의존한다. 즉 활용 영역이 잘 작동하려면 구조 영역과 관리 영역이 먼저 갖춰져야 한다 (DAMA International, 2017, Ch.1). 각 영역이 어떤 문제를 해결하기 위해 존재하는지, 왜 이 구조로 설계되었는지를 하나씩 살펴본다.

3.1 Data Architecture: 데이터의 청사진

데이터 아키텍처는 조직의 데이터가 어떻게 구성되어야 하는지에 대한 설계 청사진이다. 어떤 데이터를 어디에 저장하고, 어떤 시스템이 어떤 데이터를 소유하며, 시스템 간에 데이터가 어떻게 흐르는가를 정의한다.

현실에서 데이터 아키텍처가 없는 조직의 전형적인 증상은 다음과 같다. 동일한 고객 정보가 CRM, ERP, 마케팅 플랫폼 세 군데에 각각 다른 형태로 저장되어 있다. 어느 것이 정본인지 아무도 모른다. 분석팀이 데이터를 요청하면 어느 시스템에서 뽑아야 하는지가 매번 논쟁이 된다. 이것이 아키텍처 부재의 결과다.

데이터 아키텍처가 존재한다는 것은 “고객 마스터 데이터는 CRM이 원천이고, 다른 시스템은 CRM에서 동기화해서 사용한다”는 규칙이 문서화되고, 실제 시스템이 그 규칙을 따른다는 것을 의미한다.

3.2 Data Modeling and Design: 정밀도의 문제

데이터 모델링은 데이터 아키텍처의 청사진을 실제 DB 스키마로 변환하는 과정이다. 개념 모델(Conceptual Model), 논리 모델(Logical Model), 물리 모델(Physical Model)의 3단계로 구분된다 (DAMA International, 2017, Ch.5).

모델 수준	표현 대상	예시
개념 모델	비즈니스 개념과 관계	“고객이 주문을 한다”
논리 모델	엔티티의 속성과 관계	고객(이름, 이메일, 가입일) - 주문(주문번호, 일자, 금액)
물리 모델	DBMS 구현 명세	테이블명, 칼럼명, 데이터 타입, 인덱스

여기서 중요한 설계 의도가 있다. 논리 모델과 물리 모델을 분리하는 이유는 “비즈니스 개념”과 “구현 기술”을 분리하기 위해서다. “고객이 주문을 한다”는 사실은 Oracle을 쓰든 PostgreSQL을 쓰든 동일하다. 그러나 구현 방식은 DBMS마다 다르다. 이 분리가 없으면 DBMS 마이그레이션이 비즈니스 로직 전체를 다시 검토해야 하는 작업이 된다.

3.3 Data Storage and Operations: 살아있는 데이터의 운영

데이터를 저장하고 운영하는 것은 단순히 DB 서버를 유지하는 것이 아니다. 백업과 복구, 성능 모니터링, 용량 관리, 가용성 확보가 포함된다. 이 영역이 데이터 거버넌스에 포함되는 이유는 운영 방식이 데이터 품질에 직접 영향을 주기 때문이다 (DAMA International, 2017, Ch.6).

배치 작업 실패로 인한 부분 데이터 적재, 트랜잭션 롤백으로 인한 데이터 불일치, 잘못된 인덱스 설계로 인한 쿼리 성능 저하는 모두 운영 문제이지만 결과적으로 데이터 품질 문제로 나타난다. 운영 장애를 “인프라 이슈”로 분류하고 거버넌스 범위에서 제외하면, 품질 저하의 근본 원인을 놓치게 된다.

3.4 Data Security: 보안은 제약이 아니라 신뢰의 기반

데이터 보안은 단순히 해킹을 막는 것이 아니다. 누가 어떤 데이터에 접근할 수 있고, 그 접근이 어떻게 추적되며, 민감 정보는 어떻게 보호되는가를 정의하는 체계다 (DAMA International, 2017, Ch.7).

보안 통제가 없는 조직에서는 개인정보나 영업 기밀이 포함된 데이터를 분석팀에 제공할 수 없다. 그러면 분석팀은 실제 데이터 대신 가공된 샘플이나 집계 데이터만 사용할 수밖에 없고, 분석의 정확도가 떨어진다. 역설적이지만, 제대로 된 보안 체계가 있어야 “이 조건에서는 이 데이터를 이 팀에 제공할 수 있다”는 판단이 가능해진다. 보안이 데이터 활용의 전제 조건인 것이다.

3.5 Data Integration and Interoperability: 사일로 해체

여러 시스템의 데이터를 통합하는 것은 기술적 도전이기 이전에 거버넌스 도전이다. 시스템 A의 “고객번호”와 시스템 B의 “고객ID”가 같은 개념을 가리키는가? 시스템 A의 날짜 형식과 시스템 B의 날짜 형식이 일치하는가? 이 질문들은 표준(Standard)이 없으면 답할 수 없다 (DAMA International, 2017, Ch.8).

데이터 통합 영역은 표준 관리, 마스터 데이터 관리와 강하게 연결된다. 통합 대상 시스템들이 공통 표준을 따르면 통합 비용이 크게 줄어든다. 반대로 각 시스템이 자체 명명 규칙과 코드 체계를 사용하면, 통합 프로젝트마다 매핑 작업을 반복해야 한다.

3.6 Document and Content Management: 구조화되지 않은 데이터

엑셀 파일, PDF 보고서, 이메일, 계약서 같은 비정형 데이터도 조직의 데이터 자산이다. 이 영역은 정형 데이터 중심의 다른 영역들과 달리 문서 분류 체계, 버전 관리, 검색 가능성에 초점을 맞춘다 (DAMA International, 2017, Ch.9).

실무에서 이 영역은 종종 별도의 ECM(Enterprise Content Management) 시스템으로 관리되고, 데이터 거버넌스 프레임워크와 느슨하게 연결된다. 그러나 비정형 데이터에 대한 거버넌스가 없으면, 규제 대응이나 감사 시 필요한 문서를 적시에 찾지 못하는 문제가 발생한다.

3.7 Reference and Master Data: 조직의 공통 언어

레퍼런스 데이터(Reference Data)는 “성별 코드: M/F”, “주문 상태: PENDING/PROCESSING/COMPLETED/CANCELLED” 같이 고정된 분류 체계를 의미한다. 마스터 데이터(Master Data)는 고객, 제품, 공급업체처럼 조직 전체에서 공유되는 핵심 엔티티의 정본(Single Source of Truth) 데이터다 (DAMA International, 2017, Ch.10).

이 두 가지를 별도 영역으로 관리하는 이유는 이것들이 조직의 공통 언어이기 때문이다. 시스템 A에서 “완료” 상태가 시스템 B에서 “처리완료”로 불리면, 두 시스템의 데이터를 통합할 때 이 불일치를 수동으로 매핑해야 한다. 공통 레퍼런스 데이터가 있으면 이 문제가 처음부터 발생하지 않는다.

마스터 데이터 관리(MDM)는 특히 중요하다. DMBOK은 “많은 조직이 MDM 필요성에서 출발하여 데이터 거버넌스로 확장한다”고 설명한다 (DAMA International, 2017, Ch.3). 다수의 시스템에 흩어진 고객 정보 중 어느 것이 최신이고 정확한가를 결정하는 것은 기술 문제이기 이전에 “어느 시스템이 이 데이터의 오너인가”라는 거버넌스 질문이다.

3.8 Data Warehousing and Business Intelligence: 활용의 끝단

DW와 BI는 데이터를 분석하고 의사결정에 활용하는 영역이다. 이 영역이 프레임워크에 포함되는 이유는 분석 결과의 신뢰성이 앞선 모든 영역의 품질에 달려 있기 때문이다 (DAMA International, 2017, Ch.11).

원천 데이터의 품질이 나쁘면 BI 대시보드의 숫자도 신뢰할 수 없다. 표준이 없으면 부서별 보고서에서 “매출” 숫자가 다르게 나온다. 이 영역을 마지막에 배치한 것은 다른 모든 영역의 결과물을 소비하는 위치에 있기 때문이며, 이는 곧 거버넌스의 최종 산출물이 BI의 신뢰성으로 나타난다는 의미이기도 하다.

3.9 Metadata Management: 데이터에 대한 데이터

메타데이터는 단순히 “데이터에 대한 데이터”가 아니다. 메타데이터는 앞서 설명한 모든 영역을 연결하는 접착제 역할을 한다 (DAMA International, 2017, Ch.12).

DMBOK은 “데이터를 관리하려면 그 데이터에 대한 데이터(메타데이터)가 필요하다”는 것을 데이터 관리의 핵심 원칙으로 제시한다 (DAMA International, 2017, Ch.1). 메타데이터의 역할을 영역별로 정리하면 다음과 같다.

지식 영역	메타데이터의 역할
Data Architecture	아키텍처 설계를 문서화한다
Data Modeling	모델의 엔티티, 속성, 관계를 설명한다
Data Security	등급 분류에 기반하여 접근 통제를 결정한다
Data Quality	품질 규칙을 저장하고 실행한다
Data Integration	데이터 흐름(lineage)을 추적한다
Reference & Master Data	표준 코드와 용어를 정의한다

메타데이터 없이는 데이터 거버넌스의 어떤 영역도 자동화할 수 없고, 확장할 수 없고, 측정할 수 없다. 이것이 메타데이터 관리가 데이터 거버넌스의 기반 인프라로 불리는 이유다.

3.10 Data Quality: 거버넌스의 결과를 측정한다

데이터 품질은 거버넌스가 얼마나 잘 작동하고 있는지를 측정하는 지표다. 품질이 나쁘다는 것은 어딘가에서 거버넌스가 작동하지 않고 있다는 신호다 (DAMA International, 2017, Ch.13).

DMBOK은 저품질 데이터의 비용을 매출의 10~30%로 추정하며, IBM은 2016년 미국 내 저품질 데이터 비용을 3.1조 달러로 산정했다 (DAMA International, 2017, Ch.1). 이 비용은 재작업, 우회 프로세스, 조직 비효율, 고객 불만족, 혁신 기회 상실 등의 형태로 발생한다.

품질 측정이 나머지 영역의 검증 수단으로 작동하는 구조는 다음과 같다.

거버넌스 영역	품질 측정 관점
표준 관리	표준 준수율이 높은가
변경 관리	무단 스키마 변경이 없는가
접근 통제	권한 없는 데이터 접근 로그가 없는가
마스터 데이터	시스템 간 정본 불일치가 없는가

4 데이터 라이프사이클: 거버넌스가 커버해야 하는 전체 범위

데이터 거버넌스의 범위를 이해하는 가장 직관적인 방법은 데이터의 라이프사이클을 따라가는 것이다. DMBOK은 “데이터 관리는 라이프사이클 관리다”를 핵심 원칙으로 제시한다 (DAMA International, 2017, Ch.1). 데이터는 “생성”에서 “폐기”까지 명확한 단계를 거친다.

정책/표준 수립
     |
     v
모델 설계 (ERD, 논리/물리 모델)
     |
     v
메타 관리 (기술/비즈니스 메타데이터 등록)
     |
     v
데이터 보안 (중요데이터 등급, 접근 통제)
     |
     v
데이터 품질 (프로파일링, 규칙 진단)
     |
     v
데이터 활용 (조회, 분석, BI)
     |
     +----------------------+
                            | (피드백 루프)
                            v
                       정책/표준 수립 (반복)

여기서 핵심은 이것이 순환 구조라는 점이다. 데이터 활용 단계에서 발견된 품질 문제는 다시 표준으로 피드백되어 표준을 개선하거나, 모델 설계를 수정하거나, 메타데이터 정의를 보완하게 된다. 거버넌스를 한 번 구축하면 끝나는 것이 아니라 이 순환이 조직 내에서 지속적으로 돌아가도록 만드는 것이 목표다.

각 단계에서 어떤 컴포넌트가 어떤 역할을 하는지 정리하면 다음과 같다.

단계	핵심 활동	산출물
정책/표준	데이터 표준관리 (용어, 단어, 도메인 정의)	표준 사전, 명명 규칙
모델 설계	ERD 모델링, 데이터 흐름 설계	개념/논리/물리 모델, 데이터 흐름도
메타 관리	스키마 자동 수집, 비즈니스 맥락 등록	데이터 카탈로그, 비즈메타
데이터 보안	중요데이터 등급 분류, 비식별화 규칙	접근 통제 정책, 마스킹 규칙
데이터 품질	프로파일링, 도메인/업무 규칙 진단	품질 대시보드, 이슈 목록
데이터 활용	조회, DML 통제, 분석 & BI	보고서, 인사이트, 피드백

이 순환이 끊어지는 지점은 대개 피드백 루프다. 분석팀이 품질 문제를 발견했지만 표준팀에 전달할 채널이 없거나, 전달하더라도 표준 변경 프로세스가 없어서 방치되는 경우가 빈번하다. 거버넌스의 실질적 성패는 이 피드백 경로가 작동하는지에 달려 있다.

5 통합 프레임워크의 설계 철학

전통적으로 데이터 거버넌스를 구현하는 방식은 영역별로 별도 솔루션을 도입하는 것이었다. 메타데이터 툴, 데이터 품질 툴, ERD 모델링 툴, BI 툴을 각각 구매해서 운영한다.

이 방식의 문제는 통합이다. 메타데이터 툴에 정의된 도메인 규칙을 데이터 품질 툴에서 참조하려면 별도의 연동 개발이 필요하다. ERD 모델링 툴의 변경사항이 메타데이터 시스템에 자동으로 반영되지 않는다. 품질 진단 결과에서 발견된 오류를 변경 요청으로 연결하는 워크플로가 없다.

이 “통합 비용”은 단순히 개발 비용만이 아니다. 각 도구에서 생성된 메타데이터가 불일치하기 시작하면 유지보수 비용이 기하급수적으로 늘어난다. 어느 쪽이 정본인지 확인하는 시간, 불일치를 수동으로 동기화하는 시간이 계속 발생한다.

통합 프레임워크(Integrated Framework)는 이 문제를 아키텍처 수준에서 해결한다.

구분	개별 솔루션 방식	통합 프레임워크 방식
메타데이터 저장	도구별 개별 저장소	단일 공유 저장소
도메인 규칙 관리	표준 툴에서 정의, 품질 툴에 수동 복제	표준 관리에서 한 번 정의, 품질 엔진이 직접 참조
ERD 변경 반영	모델링 툴 → 수동 동기화 → 메타 시스템	구조관리 모듈이 즉시 반영
중요데이터 마스킹	각 도구에서 개별 설정	한 곳에서 등급 관리, 전체 기능에서 일관 적용

이 통합성이 “현행화 비용 최소화”라는 특성으로 나타난다. 각 컴포넌트가 동일한 저장소를 참조하기 때문에 한 곳에서 수정하면 전체가 즉시 반영된다.

6 데이터를 자산으로 보는 관점의 전환

마지막으로, 데이터 거버넌스를 도입하는 조직이 가져야 하는 근본적인 인식의 전환을 짚고 넘어간다.

DMBOK은 데이터 자산의 고유한 특성을 다음과 같이 설명한다 (DAMA International, 2017, Ch.1).

데이터는 사용해도 소모되지 않는다 (물리적, 재무적 자산과의 근본적 차이)
데이터는 복제와 이동이 쉽지만, 손실되면 재생산이 극히 어렵다
데이터는 동시에 여러 사람이 사용할 수 있다
데이터의 대부분의 사용은 더 많은 데이터를 만들어낸다

데이터를 “부산물”로 보는 관점에서는, 데이터는 업무 시스템이 동작하면서 자연스럽게 쌓이는 것이다. 관리 대상이 아니라 그냥 생기는 것이다. 이 관점에서 DBA의 역할은 DB가 죽지 않게 유지하는 것이고, 개발자의 역할은 서비스가 동작하게 코드를 짜는 것이다. 데이터 품질은 아무도 책임지지 않는다.

데이터를 “자산”으로 보는 관점에서는, 데이터는 관리하고 투자해야 하는 기업의 핵심 자원이다. DMBOK은 이를 GAIP(Generally Accepted Information Principles)로 체계화했다 (DAMA International, 2017, Ch.3).

GAIP 원칙	의미
Accountability	모든 데이터에 최종 책임자가 있어야 한다
Asset	데이터는 재무/물리 자산과 동일하게 관리, 보호, 회계 처리해야 한다
Audit	데이터의 정확성은 독립 기관의 주기적 감사 대상이다
Going Concern	데이터는 일시적 수단이 아니라 지속적 사업 운영의 핵심이다
Quality	데이터의 의미, 정확성, 라이프사이클이 재무 상태에 영향을 준다
Risk	데이터에는 리스크가 내재하며, 이를 공식적으로 인식하고 관리해야 한다

이 관점의 전환 없이는 아무리 좋은 툴을 도입해도 형식에 그친다. 조직 내 누군가가 “이 데이터의 품질은 내 책임이다”라고 말할 수 있어야 한다. 그 책임 구조를 만드는 것이 데이터 거버넌스의 핵심이다.

7 관련 주제

카테고리 내 연결